Перекуем мечи на орала!

Курт Воннегут. Сирены Титана

В последнее время количество различных решений в области обеспечения информационной безопасности экстенсивно растет. При чем развиваются как привычные технологии, такие как аутентификация, антивирусные системы, межсетевые экраны, так и относительно новые - сканеры защищенности, системы обнаружения атак, honeypot (устоявшийся русский термин уже появился?).

Если проанализировать различные продукты, то можно выявить две антагонизирующие тенденции. Одна предполагает анализ обрабатываемых в автоматизированной системе данных с целью определить попытки нарушения политики безопасности и соответствующим образом отреагировать на это безобразие. Подобный подход реализуют системы обнаружения атак (мне больше импонирует термин "Системы активного аудита", он ближе к истине), различные системы анализа содержимого (Content Filters, CF) и антивирусные системы. В противоположность этому, другие технологии целью своей ставят сокрытие различными, обычно криптографическими, методами данных от посторонних глаз, в том числе и от зоркого ока IDS, CF, AVIR, etc.

И действительно, что будет делать IDS с искореженным IPSec пакетом, антивирус с письмом в формате S/MIME или Content Filter с HTTPS сессией (sic!).

Несомненно, причина этого конфликта лежит в различии склада ума людей занимающихся сетевой безопасностью, и криптографической защитой информации. И действительно, много ли вы видели криптографов, которые могли насладиться трейсом сетевой активности свежего червя, или сетевика, который бы виде фразы гаммирования с обратной связью издавал что-то членораздельное (если перевести, конечно, на цензурный русский язык). Хотя этот конфликт скорее кастовой природы, ведь и в тех и в других много общего. И те, и другие жить не могут без компьютеров и сетей, обожат произносить слова из трех букв (PKI, например… или CMS… или TCP, наконец!). Да и вообще - больные люди.

Так к чему это я? Помню я одного типа, он администратор-сетевик, у него в голове один SSL. Он поставил себе контент-фильтр и теперь скулит и льет слезы, и причитает: "Ох, asu4ka, трафик забит туннелями, ICQ и прочим и все через SSL",- и он говорит "Ох, asu4ka, теперь никому не нужны контент-фильтры, потому что у всех уже есть SSL по два, по три, по четыре".

Ужель так все плохо, и зашифрованный трафик наш межсетевой экран (я отношу контент-фильтры к межсетевым экранам уровня приложения) не в состоянии как следует обрабатывать?

Вообще-то проблема не стоит выеденного яйца, особенно если вспомнить про наши завывания в космосе. Поставьте себе на машину любой продвинутый сетевой анализатор, типа ettercap, dsniff или cain (merde!) . И обратите внимание, что эти инструменты давно имеют возможность внедряться в сессию SSL. Дело в том, что использование ARP-spoofing дает злоумышленнику осуществлять атаку man-in-the-middle, которой подвержены все протоколы, использующие асимметричную криптографическую схему (это не я, это Брюс Шнайер сказал). При чем, как ни забавно, использование коммутаторов только облегчают задачу злоумышленнику.

"Глупости!", - воскликнет изумленный читатель, - "Все эти снифферы просто перехватывают ответ сервера, и вместо его сертификата X.509 возвращают клиенту свой собственный. И у пользователя в отображается диалоговое окно, в котором предупреждается, что имя узла, для которого выдан сертификат не соответствует имени узла, к которому направлен запрос. Кто на это попадется? И, кроме того, при нормальной настройке сети у пользователя не должно быть возможности работы с подобными не доверенными сертификатами!"

Не могу не согласится с мнением уважаемого читателя, за исключением одного пункта: у нас, как администраторов, гораздо больше возможностей, чем у самого хитрого злодея.

Рассмотрим идею систему фильтрации содержимого протокола HTTP с возможностью обработки HTTPS трафика.

Предположим, что в нашей сети существуют инфраструктура открытых ключей, и все пользовательские компьютеры доверяют корневому серверу сертификации (ROOT-CA). Мы получаем у этого центра сертификат для подчиненного сервера сертификации (CF-CA), который будет затем использоваться для расшифровки пользовательских сессий. Поскольку сертификат подчиненного центра выдан доверенным центром сертификации, пользовательские программы будут доверять всем сертификатам, выданным подчиненным центром CF-CA (ну, по крайней мере, пока он не загремит в список отозванных сертификатов, CRL).

При обнаружении попытки установления сессии по протоколу HTTPS, система анализа содержимого кэширует запрос и перенаправляет его на сервер - получатель. После получения ответа, содержащего сертификат сервера, CF генерирует запрос на получение сертификата для использования SSL к CF-CA, в качестве subject, или адреса компьютера указывая FQDN или IP сервера, с которым клиент устанавливал сессию. Сервер сертификатов CF-CA настроен таким образом, что бы не мудрствуя лукаво выдавать любые сертификаты нашему CF. Сервер фильтрации сохраняет полученный сертификат и отсылает его пользователю. Поскольку пришедший сертификат является действительным сертификатом, выданным центром сертификации (CF-CA), сертификат которому был выдан доверенным корневым центром сертификации (ROOT-CA) и содержит в поле Subject FQDN/IP, к которому он посылал запрос, клиент генерирует сессионный ключ, зашифровывает его на открытом ключе из сертификата и пересылает серверу - посреднику. Фильтр CF в свою очередь расшифровывает сессионный ключ с использованием ключа закрытого ключа, выданного ему CF-CA вместе с сертификатом, зашифровывает на открытом ключе сервера, к которому обращался клиент и пересылает серверу.

Вуаля, имея секретный сессионный ключ, мы спокойно расшифровываем и анализируем содержимое клиентской сессии, клиентам не выдаются страшные предупреждения, данные передаются по сети в зашифрованном виде, и все счастливы!

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

10x 4 U @tenzen. asu4ka.