Как стать автором
Обновить

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

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

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

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

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

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

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

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

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

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

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