Как работает аутентификация файлов cookie zScaler?
Я внедряю веб-фильтр для своей организации и рассматриваю возможность использования zScaler. Я не хочу использовать PAC-файл прокси. Я только что разговаривал по телефону с отделом продаж zScaler, и они утверждают, что могут дифференцировать моих пользователей после NAT с помощью файлов cookie. Они не объяснили, как это работает, но показали мне демо. Моя топология следующая:
RFC 1918 Space -> FW -> 1.1.1.1 --- 1.1.1.2 -> Router -> Internet
По сути, на маршрутизаторе выше я буду туннелировать GRE к их узлу ZEN. ZEN будет видеть только мой общедоступный IP-адрес 1.1.1.1.
При первом посещении Интернета мне придется пройти аутентификацию. После этого сеансы пользователя отслеживаются с помощью файлов cookie. Для меня это не имеет смысла, потому что:
- Два сайта, cnn.com и reddit.com, например, будут иметь совершенно разные файлы cookie, установленные моим браузером. zScaler увидит что-то вроде:
- 1.1.1.1:23883 -> cnn.com:80 + HTTP-заголовки и потенциально файлы cookie, отправленные браузером, которые являются уникальными для cnn.com и не обязательно идентифицируют меня как joeDomainUser.
- 1.1.1.1:26364 -> reddit.com:80 + HTTP-заголовки и потенциально файлы cookie, отправляемые браузером, которые являются уникальными для reddit.com и не обязательно идентифицируют меня как joeDomainUser.
Конечно, если я буду аутентифицирован на cnn.com он может вставить файл cookie в ответ, но как он будет отслеживать меня при переходе на reddit.com? Браузер будет отправлять разные файлы cookie.
Вы должны помнить, что в качестве прокси они находятся на пути для всех веб-запросов (или, по крайней мере, для всех запросов без SSL, если вы не используете расшифровку SSL).
Первый когда вы зайдете на cnn.com, они увидят, что у вас нет ни одного из их файлов cookie аутентификации для этого сайта. Вместо обслуживания сайта они временно перенаправят вас на свой сайт аутентификации.
Как только вы попадете на этот сайт аутентификации, произойдет одно из двух. Если вы уже аутентифицированы в Zscaler (что они могут узнать с помощью файлов cookie, которые в данном случае предназначены для их сайта авторизации), то они перенаправят вас обратно на cnn.com со строкой запроса (? Xxx = yyy, добавленной к URL-адресу. ), который однозначно идентифицирует вас. Когда ваш браузер следует за этим перенаправлением, он снова перехватит запрос, снова перенаправит вас - на этот раз обратно на исходный URL (cnn.com без дополнительной строки запроса), И они установят файл cookie аутентификации zscaler для домена cnn.com, что они могут сделать, потому что, насколько ваш браузер заинтересован, ответ исходит от реального cnn.com, поэтому он позволяет установить cookie (даже если ответ действительно исходит от Zscaler).
После этого каждый запрос to cnn.com будет включать их cookie аутентификации для этого домена, чтобы они знали, что это вы делаете запрос. Через некоторое время (я думаю, 24 часа) этот cookie истечет, и они снова пройдут весь процесс перенаправления.
Если вы еще не были аутентифицированы в Zscaler во время первого перенаправления, описанного выше, они заставят вас войти в систему , а затем выполните тот же процесс.
Если вы просмотрите свой список файлов cookie после включения такой аутентификации, вы обнаружите, что на каждом сайте установлен новый файл cookie - это файл cookie аутентификации Zscaler для этого домена.
Несмотря на то, что они могут утверждать, способ, которым они это делают, не так уж уникален - различные другие продукты веб-безопасности используют точно такой же механизм. Существует небольшое влияние на производительность из-за всех перенаправлений (которые происходят по крайней мере один раз для каждого домена каждые 24 часа), но в целом это не так существенно, чтобы быть заметным.