Из свободы в неволю или проникновение извне
Пакетные фильтры, работающие на уровне IP протокола или ниже, а так же все аппаратные брандмауэры, встроенные в материнские платы или DSL-модемы, не могут самостоятельно определить порт назначения, поскольку в IP-протоколе никаких портов отродят не было и они присутствуют только в протоколах TCP и UDP. Но ведь как-то же брандамауэры все-таки работают! Как?! Да очень просто — анализируют TCP-заголовки. Казалось бы, все просто. Сложности начинаются тогда, когда хакер посылает сильно фрагментированный TCP-пакет, настолько сильно, что в первом IP-пакете конца TCP-заголовка уже не оказывается, и порт назначения переходит в следующий IP-пакет. Что может сделать с таким пакетов брандмауэр? Собирать TCP-пакеты вручную он не в состоянии, поскольку это вообще-то не его задача, а если он все-таки соберет, ему придется задерживать IP-пакеты, накапливая их в очередях. Как следствие — потребности в памяти возрастут, а скорость работы канала упадет. Пользователь начнет матерится как мартовский кот и снесет такой брандмауэр на хрен. К тому же собрать TCP-пакет не так-то просто! Малейшая небрежность мгновенно оборачивается огромными дырами и голубыми экранами!
Рисунок 8 материнская плата с аппаратным брандмауэром это настоящая огненная стена, боящаяся только одного — огнетушителя
Хорошо! Раз TCP-пакет нельзя собрать, то, может быть, лучше прибить его от греха подальше? Ведь в нормальных условиях такие пакеты не встречаются. Проблема в том, что порядок получения IP-пакетов чаще всего не совпадает с порядком следования TCP-фрагментов, поэтому, пакетный фильтр опять-таки должен вести учет пакетов, хотя бы частично реализуя протокол TCP, а это — безнадежное дело. Несмотря на почетный возраст "фрагментной" атаки, она остается актуальной даже по сегодняшний день и многие брандмауэры легко пробиваются фрагментированным TCP-пакетом. Подробности можно найти в моей статье "обход брандмауэров снаружи и изнутри", опубликованной в таком-то номере "хакера", так что не будем лишний раз повторяться, а лучше рассмотрим еще одну популярную атаку, нацеленную на пакетные фильтры уровня IP.
Казалось бы — ну и что тут такого? Ведь вероятность атаки ничтожно мала… Да как бы не так! В разгар эпидемии червя MS Blast (так же называемый Love San) он ломился на порт чуть ли не через каждые полчаса и проникновение из маловероятного становилось вполне реальным! К тому же, хакер может уронить атакуемую системы в синий экран, склоняя ее к перезагрузке, и тут же обрушить на нее шторм пакетов, ломящихся на заблокированный порт. К тому времени, когда брандмауэр завершит свою загрузку, атака будет завершена.
Брандмауэр может и сам стать объектом атаки, особенно если представляет собой NDIS-драйвер, реализующий часть функций TCP/IP. Специально подготовленным пакетом можно свалить его в синий экран или передать управление на shell-код. В частности, Jetico падает при сканировании машины утилитой XSpider (правда, последние версии Jetico не проверял). Кроме того, никакой брандмауэр не спасает от атак на драйвер tcpip.sys, а ведь в нем ошибки тоже содержатся! В частности, техническая заметка KB893066, датируемая 17 июня 2005 (http://www.microsoft.com/technet/security/bulletin/ms05-019.mspx), сообщает о дыре в tcpip.sys, способной выполнять shell-код или вызывать синий экран. Пакетные фильтры, работающие на NDIS-уровне, от этой проблемы не спасают, поскольку внешне хакерские пакеты выглядят вполне нормально. Конечно, такие дыры появляются далеко не каждый день, но ведь и заплатки устанавливаются не сразу!
Рисунок 10 они преодолевают брандмауэры
