Полоса препятствий

Крис Касперски

Спецвыпуск: Хакер, номер #058, стр. 058-058-1

ака мыщъх (no-email)

Преодоление файрволов снаружи и изнутри

Понатыкали тут брандмауэров! Житья от них никакого. Даже в XP появилось какое-то подобие, но никак не работающее :). Народ только и спорит, насколько эта штука нужна и можно ли ее обойти. Можно!

Из свободы в неволю

Пакетные фильтры, работающие на уровне IP-протокола или ниже, а также все аппаратные брандмауэры, встроенные в материнские платы или DSL-модемы, не могут самостоятельно определить порт назначения, поскольку в IP-протоколе никаких портов отродясь не было и они присутствуют только в протоколах TCP и UDP. Но как-то же брандмауэры работают. Как?! Анализируют TCP-заголовки. Казалось бы, все просто. Но сложности начинаются тогда, когда хакер посылает сильно фрагментированный TCP-пакет. Настолько сильно, что в первом IP-пакете уже не оказывается конца TCP-заголовка и порт назначения переходит в следующий IP-пакет. Что может сделать с таким пакетом брандмауэр? Он не в состоянии собирать TCP-пакеты вручную, поскольку это вообще-то не его задача, а если он все-таки соберет, ему придется задерживать IP-пакеты, накапливая их в очередях. Как следствие, потребности в памяти возросли, а скорость работы канала упала. Пользователь начнет материться и снесет такой брандмауэр. К тому же собрать TCP-пакет не так-то просто. Малейшая небрежность мгновенно оборачивается огромными дырами и голубыми экранами :).

Раз TCP-пакет нельзя собрать, то, может быть, лучше прибить его от греха подальше? В нормальных условиях такие пакеты не встречаются. Проблема в том, что порядок получения IP-пакетов чаще всего не совпадает с порядком следования TCP-фрагментов, поэтому пакетный фильтр опять-таки должен вести учет пакетов, хотя бы частично реализуя протокол TCP. А это безнадежное дело. Несмотря на почетный возраст "фрагментной" атаки, она остается актуальной даже на сегодняшний день, и многие брандмауэры легко пробиваются фрагментированным TCP-пакетом.

Рассмотрим еще одну популярную атаку, нацеленную на пакетные фильтры уровня IP. Среди прочих TCP-полей притаилось поле контрольной суммы. Как оказалось, брандмауэры не контролируют его, поскольку для этого им потребовалось бы собирать весь TCP-пакет целиком, к тому же расчет CRC – достаточно "прожорливая" операция, а загружать процессор нехорошо :).

Если tcpip.sys драйвер получает "битый" TCP-пакет, он молчаливо прибивает его, независимо от того, открыт данный порт или закрыт. Пакетные фильтры ведут себя иначе, и, если заданный порт закрыт, отправителю посылается "честный" RST, дескать, не ломись туда, куда тебя не просят. Конечно, пакет все равно будет прибит, но, по крайней мере, мы узнаем, что здесь присутствует агрессивный firewall. Впрочем, при некотором стечении обстоятельств проникнуть через брандмауэр все-таки можно, о чем советую прочитать в статье "Firewall spotting and networks analisys with a broken CRC" в журнале Phrack (www.phrack.org/phrack/60/p60-0x0c.txt).

Еще проще проникнуть через NAT, который ретранслирует сетевые адреса в обход брандмауэров, висящих выше уровня tcpip.sys. Достаточно установить легальное соединение с атакуемым портом. Брандмауэр даже не пикнет. Но от сканирования портов лучше воздержаться. Брандмауэр может легко распознать эту ситуацию, забанив твой IP.