Как и зачем защищать доступ в Интернет на предприятии — часть 2

    В первой части я рассказал почему стоит защищать доступ в Интернет и что должны уметь технические решения. В этой же расскажу, что есть в арсенале Cisco и типовых способах решения задачи.

    Как правило выбор делается между решениями классов «прокси-сервер» и «межсетевой экран нового поколения». Также существуют и облачные сценарии, но их мы коснёмся лишь вскользь.

    Прокси-серверы – Cisco Web Security Appliance (WSA)


    Самый консервативный и проверенный десятилетиями способ решения задачи. Прокси-сервер или дословно «сервер-посредник» принимает на себя запросы от пользователей, проверяет их на соответствие политике и уже от своего имени устанавливает соединение с Интернет-ресурсом. Обычно прокси-сервер устанавливается в демилитаризованной зоне (ДМЗ), а прямой маршрутизируемый доступ в Интернет запрещается.



    Вполне естественно, что рабочие станции пользователей не подозревают о существовании прокси-сервера. Существует несколько способов рассказать им об этом:

    • Скрипт автонастройки в виде PAC-файла, размещаемого на сервере в локальной сети. Адрес сервера анонсируется по DHCP. Данный вариант прост и работает даже на станциях не в домене. Эта же простота его и губит — существует несколько атак с подменой сервера, позволяющих направить трафик пользователей через атакующего
    • Изменение ключей системного реестра на каждом хосте — может выполняться с помощью доменных политик, средств централизованного управления или вручную

    Все филиалы можно выпускать через один прокси-сервер, главное, чтобы пользователи могли установить с ним TCP-соединение. Если же в каждом филиале есть широкополосный доступ в Интернет, а каналы между офисами подкачали, то лучше установить прокси-сервер в каждый филиал и централизованно ими управлять. В случае с WSA лицензии приобретаются по количеству пользователей, а виртуальные машины WSA бесплатны, так что их легко и просто развернуть в каждом филиале.

    Конечно же все мы не любим настраивать что-либо сразу на всех рабочих станциях и к счастью есть вариант внедрения с WCCP. WCCP — открытый протокол перенаправления трафика, разработанный компанией Cisco. С его помощью можно отдать на проверку весь веб-трафик, проходящий через маршрутизатор, коммутатор или Cisco ASA, а остальной трафик пойдёт как раньше. На сетевом оборудовании производятся минимальные настройки, а на хостах ничего не настраивается. Ниже схематично изображён принцип работы WCCP



    А теперь о грустном. О существовании прокси-серверов знают только приложения, написанные прямыми руками, и они подхватывают настройки прокси-сервера из ОС. Если приложение писали просто руками, то в самом приложении или его конфиге есть возможность явно задать прокси-сервер. Во всех остальных случаях приходится «ковырять дырки» в межсетевых экранах и настраивать исключения. То же самое приходится делать если приложение работает по портам или протоколам, которые прокси-сервер не обрабатывает, для WSA это всё кроме HTTP/S, FTP/S, SOCKS.

    Само собой, создание исключений по портам или станциям/пользователям это упадочный вариант, который ведёт к лишней нагрузке на персонал и избыточным правам доступа. Неправильных приложений окажется больше, чем вы ожидаете, например, банк-клиенты, приложения собственной разработки, серверные приложения, приложения для работы с налоговой, пенсионными фондами, тендерными площадками, партнёрами и т.п.

    Управлять нестандартными приложениями нужно с помощью межсетевых экранов следующего поколения. Альтернативный вариант — это использование прокси-серверов некоторых производителей, которые можно устанавливать «в разрыв» и которые могут маршрутизировать весь трафик через себя. Основным минусом здесь является добавление дополнительной точки отказа в инфраструктуру.

    Межсетевые экраны нового поколения — Cisco Sourcefire NGFW


    Про NGFW и Sourcefire на Хабре уже писали, так что повторятся не буду. NGFW устанавливаются в разрыв, зачастую вместо старых межсетевых экранов, и пропускают через себя весь трафик, понимая и контролируя любые протоколы. Каких-либо настроек на хостах не требуется.

    *Рекламная пауза*
    Помните, что Sourcefire это лучший в мире NGIPS с функциональностью NGFW. Sourcefire NGIPS/NGFW может быть внедрён как в виде отдельного устройства FirePOWER, так и запущен в виде программного модуля на вашей существующей Cisco ASA. ASA должна быть серии 5500-Х и иметь SSD-диск. Для 5585-Х дополнительно потребуется замена модуля SSP. ASA будет работать как обычно, выполняя роль фильтра грубой очистки, а Sourcefire заниматься самыми интеллектуальными задачами для уже разрешённых соединений.

    Прокси-сервер или NGFW — что выбрать?


    Очевидно, что функциональность двух решений пересекается, и вы не сразу можете определить, что нужно именно Вам.

    Если перед Вами стоит только задача по сложной фильтрации доступа в Интернет и уменьшению счёта от провайдера, то ваш выбор — Cisco WSA.
    Если достаточно базовой фильтрации, есть множество нестандартных приложений и пора обновить ваши средства сетевой безопасности, то стоит смотреть в сторону Sourcefire NGIPS/NGFW.

    Самый правильный вариант — это использование обоих решений.
    особенно с точки зрения выполнения моей квоты
    Его как правило выбирают наиболее требовательные организации и выглядит он следующим образом:

    • В ядро сети или на периметре устанавливается NGIPS/NGFW, который фильтрует доступ пользователей по группам в AD, протоколам, приложениям и т.д.
    • Разрешённый веб-трафик перенаправляется по WCCP на Cisco WSA, который расшифровывает трафик SSL, кэширует запросы, передаёт отдельные файлы в систему DLP, сканирует вложения антивирусом и многое другое
    • Так как предварительную фильтрацию выполняет NGFW, то нагрузка на WSA существенно снижается и можно разворачивать его в виде ВМ. В свою очередь NGFW освобождается от задач по URL-фильтрации и перехвату SSL –трафика, что позволяет сэкономить на лицензиях и выбрать модель с меньшей производительностью

    В таблице ниже приведены ключевые отличия решений и она поможет Вам определиться с выбором
    WSA NGFW
    Фильтрация по URL-категориям + +
    Фильтрация по репутации + +
    Разграничение доступа по группам AD и приложениям + +
    Кэширование данных + -
    Квотирование трафика по времени и объёму + -
    Система обнаружения вторжений Только обнаружение компьютеров-зомби +
    Отраслевой лидер
    Сканирование загружаемых файлов антивирусными
    движками
    +
    Webroot, Sophos, McAfee
    -
    Поддержка протоколов HTTP/S, FTP/S, SOCKS Любые
    Возможность создавать собственные профили для приложений - +
    OpenAppID
    AMP — защита от уязвимостей нулевого дня + +
    Перехват и проверка SSL трафика + На отдельном устройстве
    В ближайших планах on-box decryption
    Экспорт файлов по ICAP + -
    Доступность в виде ВМ + +
    Централизованное управление + +

    Облачные решения — Cisco Cloud Web Security (CWS)


    Данный класс решений пока не набрал популярности в России и не факт, что когда-либо наберёт. Весь трафик от пользователей к Интернет-ресурсам шифруется и отправляется в облачный сервис. После проверки на соответствие политикам трафик перенаправляется к Интернет-ресурсам и запрошенные данные возвращаются пользователю. Данное решение проще всего рассматривать как Cisco WSA, размещённый в облаке и немного ограниченный по функциональности.

    Как и с традиционными прокси-серверами есть два варианта перенаправления пользователей в облачный сервис

    • «Хостовый» — на хостах производятся настройки реестра или устанавливается агент или используется Cisco Anyconnect
    • «WCCP-like» — агент на маршрутизаторах Cisco или межсетевых экранах Cisco ASA перенаправляет весь веб-трафик в CWS

    Облачные решения больше всего востребованы в розничной торговле, финансовой индустрии и любых других территориально распределённых компаниях или компаниях с большим количеством мобильных сотрудников.

    На сегодня пожалуй всё. Буду благодарен за обратную связь и участие в опросе!
    Stay tuned ;)

    Как и зачем защищать доступ в Интернет на предприятии — часть 1
    Обзор межсетевого экрана и системы предотвращения вторжений нового поколения SourceFire FirePower
    Что к чему в “NGFW | NGIPS | UTM” и UTM против NGFW – один оттенок серого

    Only registered users can participate in poll. Log in, please.

    Какую тему вы бы хотели видеть в следующей статье?

    • 69.6%• Аутентификация и авторизация пользователей для получения доступа в Интернет – AD, ISE, пассивные и активные веб-формы, NTLM103
    • 49.3%• Проверка членства в домене, наличия антивируса и обновлений ОС перед предоставлением пользователю доступа в Интернет73
    • 41.2%• Сложности при защите веб-трафика виртуальных рабочих станций (VDI), планшетов и смартфонов, рабочих станций с сотрудниками, работающим по сменам61
    Cisco
    Cisco – мировой лидер в области сетевых технологий

    Comments 6

      0
      День добрый! Смутило пару моментов в вашем обзоре.
      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. Пока их функционал частично перекрывается.
        0
        Добрый!
        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 на русском есть здесь, свежую информацию можно найти здесь
        0
        NTLM же уже давно obsolete, да ещё и с уязвимостями, верно? Т. е. сейчас Kerberos.
          0
          Совершенно верно! Но к сожалению не все решения умеют Kerberos, а некоторые из них не умеют даже NTLMv2)
          0
          •Скрипт автонастройки в виде PAC-файла, размещаемого на сервере в локальной сети. Адрес сервера анонсируется по DHCP.
          Кстати, раздачу WPAD через option 252 по-прежнему понимает только IE?

        Only users with full accounts can post comments. Log in, please.