Тестирование решений Palo Alto Networks: как запретить доступ к социальным сетям и приложениям

    Тестирование Palo Alto Здравствуйте, дорогие любители высоких технологий. Продолжаем наш цикл статей про продвинутые железяки.

    Сегодня я расскажу о решениях компании Palo-Alto Networks и покажу, как настроить различные политики, в частности запрещающие пользоваться социальной сетью или приложением иного рода конкретному пользователю.




    Palo Alto Networks производит довольно неплохие межсетевые экраны, контент-фильтры и т.п. вещи в одном устройстве. Насколько я понял со слов представителя компании – основные разработчики ушли из Juniper networks, где они трудились при создании серии SSG устройств.

    Ну да ладно. Большинству это не интересно, и все ждут скриншотов. Поехали:

    1. Главная страница и dashboard. В принципе тут все понятно (я надеюсь).

    Palo Alto Dashboard


    2. ACC (или Application Command Center). Здесь мы можем посмотреть, какой тип трафика был замечен в тот или иной промежуток времени, кто был генератором или инициатором трафика и т.п.

    Palo Alto Application Command Center


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

    image


    3. Идем дальше – вкладка Monitoring. Думаю, бессмысленно объяснять ее значение. Отмечу лишь, что ей очень удобно пользоваться при отладке, т.к. среди общей вакханалии IP пакетов мы можем отфильтровать лишь необходимые нам.

    Palo Alto Monitoring


    4. Политики. Здесь задаются политики взаимоотношений между зонами безопасности (которые описываются дальше), пулы и правила NAT и другие штуки, которые, несомненно, важны в нашей жизни: QoS, Captive portal, DoS protection и т.п.

    Palo Alto Politics


    5. Объекты. На этой вкладке представлены различные сущности, которые мы можем группировать по различным признакам, задавать новые и т.д. В дальнейшем мы можем использовать эти вновь созданные параметры в различных политиках доступа.

    Palo Alto Objects

    Помимо всего прочего здесь определены сигнатуры приложений (а так как Palo Alto умеет их распознавать, то мы можем отдельно фильтровать трафик того или иного приложения. Об этом более подробно в конце статьи).

    6. Network. Назначение этой вкладки – настройка всего, что касается сети в нашем девайсе. Начиная от выдачи адресов интерфейсам и заканчивая настройкой IPSec туннелей (Да! Palo Alto поддерживает IPSec туннели).

    Palo Alto Network


    7. Device. Здесь хранятся различные глобальные настройки устройства. Все, что можно настроить, находится слева на скрине.

    Palo Alto Device


    Попробуем написать политику, запрещающую пользоваться социальной сетью для школьников одному компьютеру (так как пользователь этого компьютера себя плохо вел):

    1.

    Palo Alto Security Policy Rule


    2.

    image

    3.

    image

    4.

    image


    5.

    image


    Пользователь пытается попасть на Вконтакте и тут – БАЦ! Не работает. А мы с вами победно наблюдаем бесполезные его попытки:

    image

    С другой стороны, такой фильтрацией никого сейчас не удивишь. Я вас отчасти понимаю, поэтому немного усложним задачу. Попробуем отфильтровать приложение, которое используется для доступа к другой социальной сети, но в то же время оставим доступ туда через WEB.

    Итак, представим себе, что у нас строится еще один этаж нашего 18-этажного офиса. Везде по зданию есть wifi точки доступа с открытым SSID (да, мы не жадные до интернета). На 18 этаже заканчивают ремонт рабочие. Один из них (назовем его Ашотом) вместо того, чтобы закончить класть 30 квадратных метров кафельной плитки, подключился к сети и при помощи мессенджера ведет активную переписку с очередной “дамой сердца”. При этом предположим, что нам по каким-то причинам необходимо запретить всем пользоваться мессенджером, оставив при этом доступной работу через браузер.

    Настроим политику:

    image

    Затем укажем security зону, откуда будет инициироваться соединение (заодно запретим всем с любого адреса пользоваться данным клиентом).

    image


    Укажем, в какую зону будет идти трафик (чтобы не париться – укажем в любую зону):

    image

    Теперь нам нужно запретить этот самый мессенджер. Ищем его в базе сигнатур и выставляем:

    image

    Заключительное правило – блокируем весь трафик от приложения:

    image

    Применяем и сохраняем конфигурацию. Смотрим, что мы имеем:

    image

    Собственно, заблокировать приложение у нас получилось. Теперь смотрим, есть ли доступ к сайту с web-браузера:

    image


    В принципе реализовалось всё, что было задумано. Вопросы?
    IT-GRAD
    Виртуальная инфраструктура IaaS

    Комментарии 27

      0
      Если я по https запустил canvas VNC на своём сервере и мило там сижу в любимой социальной сети, что делать будете и как обнаруживать?
        +1
        Если у Вас есть свой сервер, к которому можно подключится по VNC, думаю Вы в любом случае найдете путь.
        А вот 90% пользователей крупных компаний не найдут.
          0
          То есть, в HTTPS-трафик этот продукт заглядывать не умеет?
            0
            А разве кто-то умеет?
            Как вариант в домене это конечно можно обойти, подписывая сессию заново автогенерируемым сертификатом, но без домена. Я думаю никак. Ну либо сессию даунгрейдить до http :)
              0
              Ну, начну с любимого — Squid =) Это из OpenSource. Причем, третий squid мониторит уже по-умному (см. ssl-bump).
              Palo-Alto-like — Websense =)

              Да и вообще, без этого современный мониторинг использования интернета представить нельзя.

              Собственно, продукт интересный, но я считаю, что если шлюз доступа в интернет не может смотреть в https, то все эти плюшки типа блокирования приложений не нужны, потому что админу надо сидеть и мониторить аномалии трафика для выявления анонимайзеров, приложений типа как в родительском посте ветки и т.п.
                +1
                Так я и написал, без генерации сертификата на лету — никак. Для пользователя это будет выглядеть как неверный сертификат.
                  0
                  Нет, вы написали «А разве кто-то умеет?»
                  Согласитесь, это не тождественно фразе «без генерации сертификата на лету — никак» =)

                  Если у нас задача контролировать зашифрованный трафик для предотвращения каких-то последствий, то пусть будет неправильный сертификат. Грамотный юзер поймет, что его просматривают и не полезет. Мы выиграли — не лезут. Неграмотный полезет. Мы выиграли — мониторим.
                    0
                    Ну в моем понимании мониторить — это не менять :)
                    А тут явное вмешательство в трафик.

                    Хотя конечно признаю, написал неоднозначно.
                    0
                    Ну, в общем, я так понимаю, что могут, раз это заявлено в фичах =)

                    Так что задача из начала ветки сводится к получению или разработке нужной сигнатуры ;)
                      0
                      ну почему же неправильный?
                      сертификат будет выдан CA самой компании
                      если у клиентов сертификат корпоративного CA в Trusted Root — что и просходит в домене windows — цепочка сертикатов будет валидной
                      а про «кто-то умеет?» — Microsoft TMG это умеет из коробки
                      да еще и уведомление сотруднику в трее показывать — дескать «ваш https трафик инспектируется работодателем»
                        0
                        Выше написал про домен, если внимательнее почитаете :)

                        И по схеме man-in-middle умеет работать целая гора софта, никто и не спорит.
                        Но без импорта сертификата CA ничего работать не будет.
                          0
                          TMG, увы, более не купить.
                    0
                    В https сейчас умеют заглядывать все основные вендоры безопасности. Осуществляется это путем классической схемы Man-in-the-middle и для корректной работы на рабочих станциях пользователя необходимо добавить сертификат шлюза в список доверенных. Схема испекции https не лишена недостатков, но это вытекает из главного свойства Secure-протокола: обеспечивать сокрытие передаваемых данных.
                      0
                      При чем не просто сертификат шлюза, а сертификат CA шлюза. Дабы он мог подписывать на лету.
                        0
                        Да, согласен — всю цепочку сертификатов, включая коренной, т.е. сертификат CA (Certificate Authority). Если используется самоподписной сертификат (встроенные СА в продукты безопасности либо просто локальный СА заказчика), то важно не забыть про коррень. Если же для внутреннего интерфейса шлюза заказчик приобрел платный сертификат известных СА (Verisign, Entrust etc), то данный шаг можно пропустить, корень уже присутствует в браузере по умолчанию.
                          0
                          Именно так.
                          В домене это решается довольно просто, локальным CA.
                          А вот в общем случае, без доступа к машине, путь только один — покупка CA сертификата. Боюсь представить сколько это стоит :)
                    0
                    Я не знаю про «крупные компании», но когда я работал в небольшой компании (50-80 человек), занятой торговлей, то я точно знаю, что большинство из тех, кому хотелось на забаненные на свиде сайты, находили туда путь. Лучшее, что я видел — это чей-то релей из вконтактика в почту и обратно. В шифрованных вложениях.
                      0
                      К слову, это вопрос политики компании.
                      Если нужно — всегда можно вычислить. Периодический просмотр потребления трафика, выявление перечня популярных направлений, определение цели посещения ресурса. На крайний случай всегда можно тихо поставить VNC и посмотреть, что же там происходит.
                      Ну и запрещение, соответственно.

                      А если надо просто чтобы было, то никто и заморачиваться не станет: поставил проксю, отчитался, забыл.
                        0
                        Тихо поставить VNC и посмотреть не получится, потому что VNC через websockets через https. Мой опыт говорит, что в практическом применении это ну совсем невозможно.

                        Потому что на тот же сервер, где вебсокетные vnc кладётся банальная копия рабочего сайта (имеется в виду, новостного сайта по теме работы), а vnc отдают после авторизации по https. И что вы там увидите?
                  0
                  Как реализовано определение программ? По сигнатурам DPI или тупо порты?
                  В посте так и не нашел однозначного ответа.
                    0
                    Определение программ осуществляется с использованием сигнатур, которые постоянно обновляются. Также есть возможность добавлять свои, если в этом есть необходимость. В этом как раз вся суть: не надо прописывать IP адреса и порты — достаточно просто указать приложение!

                      0
                      То есть DPI?
                        0
                        Можно сказать, что да. Palo Alto называет эту фичу App-ID
                        0
                        Спасибо за небольшой обзор интерфейса PaloAlto (и кликабельные картинки). А есть ли у данного вендора публично доступная база приложений, чтоб можно было оценить ее качество? Например, как это сделано у Check Point appwiki.checkpoint.com/
                    0
                    Базу можете посмотреть здесь: applipedia.paloaltonetworks.com/
                      +1
                      Собственно о чем статья? Скриншоты интерфейса и пример создания правила даже без использования ssl decryption и фирменной технологии User-ID и собственно Content-ID.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое