Комментарии 6
День добрый! Смутило пару моментов в вашем обзоре.
1)«Обычно прокси-сервер устанавливается в демилитаризованной зоне (ДМЗ)» — уже давно не рекомендуется подобная практика. Во всех последних документах Cisco SBA прокси сервер (Cisco WSA) устанавливается в локальной сети (не в DMZ) в сегменте локальных серверов. Поместив прокси сервер в DMZ не получится использовать WCCP, т.к. Cisco WSA должен сидеть за inside интерфейсом межсетевого экрана или роутера (т.е. за тем же интерфейсом что и пользователи).
2)«В ядро сети или на периметре устанавливается NGIPS/NGFW, который фильтрует доступ пользователей по группам в AD, протоколам, приложениям и т.д.
Разрешённый веб-трафик перенаправляется по WCCP на Cisco WSA,» — это все хорошо, до тех пор пока пользователь не начинает использовать ресурсы с микроприложениями. Например в facebook-е или vk-те, используется один порт, однако доступно куча микроприложений (сообщения, видео, игры, музыка). Если вы этот трафик (HTTP/HTTPS) перенаправляете на WSA, то соответственно разграничить доступ к микроприложениям у вас не получится… А в современном мире это довольно частая задача. С это задачей прекрасно справляется NGFW, собственно для этого он и предназначен.
На данный момент Cisco WSA подходит только для грубой обработки web трафика, где можно рубить доступ к ресурсам по категориям. Однако для тонкой настройки доступа пользователей к различным ресурсам уже требуется NGFW. Пока их функционал частично перекрывается.
1)«Обычно прокси-сервер устанавливается в демилитаризованной зоне (ДМЗ)» — уже давно не рекомендуется подобная практика. Во всех последних документах Cisco SBA прокси сервер (Cisco WSA) устанавливается в локальной сети (не в DMZ) в сегменте локальных серверов. Поместив прокси сервер в DMZ не получится использовать WCCP, т.к. Cisco WSA должен сидеть за inside интерфейсом межсетевого экрана или роутера (т.е. за тем же интерфейсом что и пользователи).
2)«В ядро сети или на периметре устанавливается NGIPS/NGFW, который фильтрует доступ пользователей по группам в AD, протоколам, приложениям и т.д.
Разрешённый веб-трафик перенаправляется по WCCP на Cisco WSA,» — это все хорошо, до тех пор пока пользователь не начинает использовать ресурсы с микроприложениями. Например в facebook-е или vk-те, используется один порт, однако доступно куча микроприложений (сообщения, видео, игры, музыка). Если вы этот трафик (HTTP/HTTPS) перенаправляете на WSA, то соответственно разграничить доступ к микроприложениям у вас не получится… А в современном мире это довольно частая задача. С это задачей прекрасно справляется NGFW, собственно для этого он и предназначен.
На данный момент Cisco WSA подходит только для грубой обработки web трафика, где можно рубить доступ к ресурсам по категориям. Однако для тонкой настройки доступа пользователей к различным ресурсам уже требуется NGFW. Пока их функционал частично перекрывается.
Добрый!
1) С WCCP + ASA согласен, есть ограничения. Классический же вариант прокси прекрасно будет работать в ДМЗ. Крайне полезно его туда вынести в случае если решение сделано на базе ОС, которую постоянно нужно патчить или если к этому прокси подключаются не внушающие доверия пользователи из филиалов/партнёров
2) WSA и другие proxy-like решения понимают микроприложения в протоколах, с которыми могут работать. К примеру вот материал про компоненты Facebook www.cisco.com/c/dam/en/us/td/docs/security/wsa/AVC/Controlling_Facebook_Activity.pdf
Функциональность перекрывается, это очевидно. По поводу «WSA = грубая фильтрация = только URL-категории» совершенно не согласен.
Старая брошюра по WSA на русском есть здесь, свежую информацию можно найти здесь
1) С WCCP + ASA согласен, есть ограничения. Классический же вариант прокси прекрасно будет работать в ДМЗ. Крайне полезно его туда вынести в случае если решение сделано на базе ОС, которую постоянно нужно патчить или если к этому прокси подключаются не внушающие доверия пользователи из филиалов/партнёров
2) WSA и другие proxy-like решения понимают микроприложения в протоколах, с которыми могут работать. К примеру вот материал про компоненты Facebook www.cisco.com/c/dam/en/us/td/docs/security/wsa/AVC/Controlling_Facebook_Activity.pdf
Функциональность перекрывается, это очевидно. По поводу «WSA = грубая фильтрация = только URL-категории» совершенно не согласен.
Старая брошюра по WSA на русском есть здесь, свежую информацию можно найти здесь
NTLM же уже давно obsolete, да ещё и с уязвимостями, верно? Т. е. сейчас Kerberos.
•Скрипт автонастройки в виде PAC-файла, размещаемого на сервере в локальной сети. Адрес сервера анонсируется по DHCP.
Кстати, раздачу WPAD через option 252 по-прежнему понимает только IE?
Кстати, раздачу WPAD через option 252 по-прежнему понимает только IE?
Mozilla и Chrome точно не умеют, вот здесь есть линки на баги, которые открыты уже много-много лет
en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol#References
en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol#References
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как и зачем защищать доступ в Интернет на предприятии — часть 2