Персональные файрволы: проблемы безопасности сетевой инфраструктуры

СЕЙЧАС НАИБОЛЕЕ ВАЖНОЙ ЗАДАЧЕЙ ДЛЯ СОЗДАТЕЛЕЙ ЛЮБЫХ СРЕДСТВ БЕЗОПАСНОСТИ ЯВЛЯЕТСЯ ЦЕЛЫЙ РЯД МЕР ПО ИЗМЕНЕНИЮ СВОЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, НАЧИНАЯ ОТ ПРОСТОЙ ЕГО АДАПТАЦИИ И ЗАКАНЧИВАЯ ЗНАЧИТЕЛЬНЫМИ ПЕРЕДЕЛКАМИ ВСЕЙ АРХИТЕКТУРЫ СРЕДСТВ ЗАЩИТЫ.

Firewall для Windows Vista

Разработка Windows Vista стала одним из самых значительных проектов, реализованных в Microsoft. Одна из целей, поставленных перед разработчиками — адаптация сетевых технологий платформы Windows NT к меняющимся требованиям окружающего мира. Довольно часто можно услышать о том, что, в общем-то, ничего менять не нужно, и на текущий момент платформа Windows NT является достаточно стабильной, быстрой и отвечает многим современным требованиям. Системные администраторы в этом отношении — люди достаточно консервативные, и любые изменения в продукте, только было приобретшем стабильность и надежность, вызывают у них обоснованную настороженность. Стоило ли вообще что-то менять? Давайте попытаемся сформулировать ответы на эти вопросы.
Одна из наиболее сложных проблем, с которой столкнулась команда разработчиков Windows – недостаточно хорошая масштабируемость сетевой инфраструктуры платформы Windows NT. К сожалению, возможности Windows NT по обработке все возрастающих объемов сетевых данных серьезно ограничены не очень хорошей масштабируемостью на мультипроцессорных системах. Если для клиентской версии операционной системы это не самое нужное нововведение, то для разрабатываемой на ее основе серверной версии — один из наиболее критичных параметров. Довольно сложно говорить о масштабируемости Windows-серверов, если учесть, что драйверы сетевых протоколов до Windows Vista получали и обрабатывали поступающие данные, используя только один процессор. Любые неверные алгоритмы в драйвере протокола или неэффективно написанный код могли привести к тому, что внутри стека образовывалось узкое место, ограничивающее пропускную способность сервера, и он был не в состоянии эффективно обрабатывать поступающие данные.

Внедрение IPv6 многим не кажется актуальной задачей, - для нее еще нет практического применения. Однако, делая такие выводы, было бы полезно подумать не столько о том, что срок жизни конкретной операционной системы ограничен, сколько о необходимости постепенно готовить и администраторов, и разработчиков к тому, что IPv6 станет неотъемлемой частью сетевой инфраструктуры. Если уже сейчас не начать разработку программных продуктов для IPv6, то, когда в нем появится необходимость, очень многое окажется неготовым. Кроме того, очень тяжело поддерживать две совершенно независимые версии протоколов и сделать это полностью прозрачным для клиентских приложений.

Зачем Microsoft потребовалась возможность интеграции firewall’ов сторонних разработчиков? Этому существует несколько объяснений. Во-первых, нужно было что-то делать с тем, как в настоящее время разрабатываются драйверы для firewall’ов. К сожалению, сейчас построение полноценного firewall’а без значительной интеграции в работу ядра Windows NT не представляется возможным. Проблема в том, что вся программная основа, сделанная Microsoft для того, чтобы безболезненно интегрировать сторонние средства, была или малофункциональной, или слишком сложной и, как следствие, довольно ненадежной.

Достаточно ли устойчива сейчас Windows к сетевым атакам, направленным на стек протоколов TCP/IP? С каждой версией операционная система становилась все лучше и стабильнее. Например, Windows Server 2003 на момент своего выпуска была значительно надежнее, чем Windows NT 4.0. Прогресс налицо, особенно это касается работы с фрагментированными пакетами и их аномалиями. Вполне логично было бы ожидать, что Windows Vista будет еще надежнее. К сожалению, в ее случае оправдались не самые оптимистичные прогнозы и, хотя на сегодняшний день можно упомянуть очень небольшое количество известных уязвимостей, некоторые особенности работы стека дают основания считать, что они еще могут появиться.

Перед обсуждением риторического вопроса «а нужен ли firewall?» рассмотрим некоторые особенности реализации стека протоколов Windows NT.

ARP-протокол

Довольно интересным примером для рассмотрения является работа с протоколом ARP в платформе Windows NT. Протокол ARP (Address Resolution Protocol) предназначен для получения MAC-адресов сетевых устройств, сопоставленных с определенным IP-адресом. Как и многие другие протоколы, созданный на заре появления сетей, он является очень простым и в то же время невероятно опасным для локальной сети. Когда Windows требуется отправить IPv4-пакет определенному узлу, подключенному к тому же самому Ethernet-сегменту, что и узел отправителя, то сначала требуется узнать MAC-адрес узла-получателя. Для решения этой задачи сетевой стек отправляет широковещательный ARP-пакет, в котором указано, что узлу-отправителю требуется получить MAC-адрес, соответствующий IP-адресу узла-получателя. Узел, IP-адрес которого пытаются узнать, должен при получении такого ARP-запроса ответить узконаправленным ARP-ответом, в котором будет записан нужный MAC-адрес.

Данная схема не учитывает случай, когда два или более узла сообщают о том, что искомому IP-адресу соответствует их MAC-адрес. В Windows NT используется очень спорный механизм для выхода из такой ситуации — «правильный MAC-адрес содержится в последнем полученном ответе». Следствием принятия подобного решения является возможность парализовать Windows-машины в одном сегменте сети довольно простым способом – с помощью отправки специально сформированных ARP-ответов, в которых с известным IP-адресам сопоставляются заведомо неверные MAC-адреса. Этой проблеме, пожалуй, столько же лет, сколько и реализации IP-стека в платформе Windows NT, но Microsoft так ничего и не предприняла для ее решения. Особенно удручающе это выглядит на фоне других реализаций IP-стека, в которых используется несколько иной алгоритм – «правильный ответ — первый, до тех пор, пока взаимодействие по IP-протоколу с указанным узлом осуществляется успешно». Сейчас эта проблема перешла и на Windows Vista, а подробности о ней можно поискать по ее названию «CVE-2007-1531».
Кроме того, довольно простым и, в то же время, изящным решением является «принимать только один ARP-ответ на каждый отправленный запрос» и не принимать ответы, если запросы не отправлялись.

Благодаря этой особенности реализации TCP/IP-стека в Windows NT, разработчики «активных сетевых анализаторов» или sniffer’ов имеют возможность осуществлять перехват сетевого трафика, используя тактику «Man-In-The-Middle» — с помощью специально сформированных ARP-ответов пропускать весь Ethernet-трафик через себя.

Другая интересная особенность, некогда описанная в статье «Core Protocol Stack Components» на сайте Microsoft Technet (http://technet2.microsoft.com/WindowsServer/f/?en/library/823ca085-8b46-4870-a83e-8032637a87c81033.mspx), «Duplicate IP Address Detection», имеет не менее разрушительные побочные эффекты. Узел Windows NT, получив запрос, в котором удаленный узел с помощью ARP-запроса проверяет, не занят ли его IP-адрес, выполняет два довольно опасных действия: выдает сообщение интерактивному пользователю (если он есть) и производит запись о событии в EventLog.

По каждому полученному ARP-запросу производится запись в журнал. Учитывая малый размер ARP-запроса, через 100 Мбитную сеть можно отправить довольно большое количество таких запросов, тем самым вынуждая узел получателя расходовать процессорные ресурсы и память на запись их в EventLog.

Эта проблема также известна очень давно, но она до сих пор не имеет решения. От Windows Vista ожидалось решение, в частности, и этих проблем, но, к сожалению, команда разработчиков Microsoft преподнесла очень неприятный сюрприз всем пользователям Windows. Теперь при получении ARP-сообщения о том, что IP-адрес уже занят, Windows Vista отключает использование «конфликтующего» IP-адреса и начинает использовать либо адрес из диапазона 169.254.*.*, либо спрашивает у DHCP-сервера новый адрес. Пользователю же выдается не всплывающее из system tray сообщение, как это было раньше, а внушительных размеров диалоговое окно с описанием проблемы и кнопкой, позволяющей ее «исправить».

В настоящий момент таким злоумышленникам можно противопоставить только лишь сторонние firewall’ы, имеющие в своем составе модуль, называемый Ethernet или ARP protection (например, Outpost Firewall Pro или Zone Alarm Pro).

Работа с фрагментированными пакетами

Одна из наиболее сложных задач для любой реализации стека TCP/IP — это корректная сборка фрагментов при получении. Windows NT в этом отношении не является исключением. Реализации TCP/IP-стеков, которые присутствовали в Windows NT 3.51 и Windows NT 4.0, печально известны целыми группами проблем, позволявшими использовать аномалии фрагментации для DoS-атак на эти системы.

Даже Windows 2000 SP4 обладает некоторым количеством проблем в сетевом стеке при сборке фрагментированных пакетов, которые могут приводить к DoS-атакам. К счастью, для их воспроизведения нужен достаточно большой объем данных и их проявление не так заметно – это не «синий экран», а просто полная потеря возможности работать с сетью до перезагрузки системы. Windows Server 2003 уже при своем выпуске была лишена этих проблем и является значительно более устойчивой к DoS-атакам.

Сейчас можно утверждать, что качество написанного «с нуля» стека Windows Vista значительно выше. Windows Vista не только легко переносит разнообразные аномалии IPv4-фрагментации, но и значительно лучше принимает IP-пакеты, пришедшие в произвольном порядке, что должно положительным образом отразиться на качестве работы в условиях ненадежных или медленных каналов связи. Единственным исключением является реализация печально известного протокола IGMP. По невыясненным причинам, сборка фрагментированных пакетов IGMP-протокола происходит довольно тяжело для системы, поэтому иллюстрации приходится делать с помощью фотографирования монитора. В этом случае может радовать только то, что протокол IGMP блокируется многими маршрутизаторами.

С реализацией IPv6, к сожалению, тоже пока еще не все в порядке. Элементарное добавление специально сформированного «Fragmentation Header» может приводить к серьезным проблемам быстродействия системы в случае большого потока данных, изобилующего такими заголовками. К чести разработчиков сетевого стека Windows Vista, в реализации IPv6 нет лежащих на поверхности проблем, которые могли бы приводить к более серьезным последствиям.

Как можно заметить, проблеме обработки фрагментированных IP-пакетов столько же лет, сколько и самой реализации IP-протокола. Практически до настоящего времени многие производители персональных firewall’ов совершенно не обращали на нее внимание. Продукт Outpost Firewall с момента своего появления уже обладал модулем, который занимался анализом пакетов еще до того, как они начинали обрабатываться сетевым стеком Windows, и не пропускал ошибочно или заведомо неверно сформированные пакеты. Задача грамотно созданного firewall’а — помочь стеку операционной системы корректно справиться с любыми ситуациями, которые могут произойти в ходе работы в интернете. Однако в последнее время среди производителей firewall’ов начали встречаться довольно «дикие» методы борьбы с этой проблемой, такие как отбрасывание любых фрагментированных пакетов или отбрасывание фрагментированных пакетов в случае, если был нарушен порядок приема фрагментов (например, второй фрагмент пришел раньше, чем первый). К счастью, в большинстве случаев включаются они опционально.
Собирая эти данные воедино, можно утверждать, что производители high-end firewall’ов отчасти занимаются тем, на что не хватает времени команде разработчиков Microsoft. А конечным пользователям остается надеяться на низкую квалификацию злоумышленников, которых может заинтересовать работоспособность их систем, или искать сторонние средства для обеспечения безопасности.

Есть ли прогресс?

Безусловно, Windows Vista по сравнению с предыдущими версиями операционных систем Windows NT показывает очень значительный прогресс в безопасности и качестве реализации сетевой инфраструктуры. Как и любая другая сложная система, она не лишена определенных недостатков, которые уже длительное время игнорируются производителем. Практика разработки операционной системы показала, что даже значительное время на ее создание не позволило появиться на свет системе, которая могла бы свободно обходиться без сторонних средств защиты.

Скорее всего, стандартные средства защиты вряд ли когда-нибудь будут действительно серьезной линией обороны на пути опытного злоумышленника.

Комплексный подход от Agnitum

В мае 2007 года официально появился Outpost Security Suite Pro — первое комплексное проактивное решение для Windows XP, основанное на сочетании персонального брандмауэра Outpost Firewall Pro с антишпионом, антивирусом и антиспамом. Преимущество при использовании комплексного решения заключается в том, что все компоненты будут хорошо работать вместе. А иначе всегда существует риск, что хотя бы одна из установленных на ПК программ (если пользоваться набором специализированных утилит, пусть даже лучших в своем классе) вступит в конфликт с другими приложениями — просто потому, что они не были спроектированы для совместной работы.

Среди технологических нововведений — технология SmartScan. Вы можете выбрать опцию быстрого сканирования с помощью технологии кэширования SmartScan. В процессе начального сканирования система Suite создает скрытые файлы, индексирующие файлы и папки. Если файл изменяется или база данных вредоносного ПО обновляется, Suite может быть сконфигурирован так, чтобы сканировать только эти измененные файлы. Файлы, остающиеся неизмененными, не сканируются заново, что ускоряет процесс проверки и улучшает производительность.

Так же в Outpost Security Suite Pro реализована технология внутренней защиты — «защитник» обнаруживает, когда какое-либо приложение пытается вмешаться в его собственные процессы. Это предохраняет защиту от деактивации или иного способа остановки брандмауэра вредоносным кодом.

Обсуждение статьи