Как работает брандмауэр

nezumi

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

Проблемы пакетных фильтров

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

Тем не менее, у пакетных фильтров тоже есть проблемы. Большинство персональных брандмауэров, построенных по этой схеме, серьезно тормозят даже на модемных соединениях, не говоря уже о DSL-подключении. На простом web-серфинге задержка практически незаметна, но при активной работе с несколькими десятками TCP/IP-соединений она может "отъедать" чуть ли не половину пропускной способности канала, а это уже нехорошо. Конечно, разработчики брандмауэров могут возразить, что, мол, на персональных компьютерах такое количество соединений никому не нужно, но это будет наглая ложь. Осел требует от трехсот до пятисот соединений, то же самое относится к другим файлообменным клиентам. К тому же при организации локальной сети на компьютер, смотрящий в интернет, ложится довольно-таки приличная нагрузка.

Для нормальной фильтрации трафика требуется колоссальное количество памяти и нехилые процессорные ресурсы. Все дело в том, что данные передаются по сети не сплошным потоком, а расщепляются на многоуровневую иерархию пакетов. В грубом приближении: Ethernet-> IP-> TCP/UDP. Один TCP/UDP-пакет разбивается на множество IP-пакетов, которые "вываливаются " в сеть настоящей "горстью риса", то есть в разупорядоченном состоянии. Порядок доставки IP-пакетов может не совпадать с порядком их "нарезки" в TCP-пакете, причем некоторые IP-пакеты могут теряться и тогда отправляющая сторона передает их вновь и вновь... Да и сама установка TCP-соединения представляет собой многостадийную операцию. Пакетный фильтр, работающий на IP-уровне, будет просто нефункционален! Достаточно сказать, что в IP-протоколе нет понятия "порта" и "закрыть" порт с IP уровня невозможно. Упрощенно это выглядит так: отправитель посылает получателю книгу, разрезанную на мелкие куски, произвольным образом перемешанные между собой, а получатель тем или иным образом собирает этот puzzle в исходный вид. Допустим, между ними сидит злой цензор, который внимательно просматривает каждый кусочек на предмет "политкорректности" и либо уничтожает его, либо передает "наверх". Очевидно, если цензор (он же брандмауэр) не будет выполнять полной сборки TCP-пакетов: он не заметит ничего подозрительного. Теоретически, можно посадить брандмауэр на TCP/UDP-уровень и фильтровать уже собранные пакеты, но тогда хакер сможет передать "сырой" IP-пакет и брандмауэр будет в шляпе :).

Максимальная защита обеспечивается при фильтрации пакетов на Ethernet-уровне. При условии, что брандмауэр сконструирован без ошибок, никакой хакер не сможет его обойти. Большинство разработчиков именно так и поступают. Типичный персональный брандмауэр встраивается в "разрыв" между драйвером сетевой платы и TCPIP.SYS-драйвером, который, как и следует из его названия, реализует протокол TCP/IP. При этом брандмауэр должен самостоятельно собирать TCP-пакеты, фактически полностью повторяя собой TCPIP.SYS, реализация которого является весьма нетривиальной задачей. Но это еще цветочки. Попробуем рассчитать пиковую потребность в оперативной памяти. Возьмем гигабитный Ethernet , тайм-аут в 30 секунд и 100 соединений. Получаем: 1.073.741.824 х 30 х 100 / 8 = 402.653.184.000 байт или 375 Гб. Какая там оперативная память - даже винчестеров такого объема в персональных компьютерах еще не встречается! На самом деле это проблема не брандмауэра, а самого протокола TCP/IP (именно на этом и основана известная SYN-атака), но брандмауэр удваивает потребности TCP/IP-стека в оперативной памяти, что не есть хорошо. Но это еще полбеды: хуже всего, что брандмауэр не может отдавать IP-пакеты "наверх" до тех пор, пока он не соберет весь TCP-сегмент целиком и не проверит его на "вшивость". Пакетный фильтр вынужден накапливать поступающие данные в своих собственных очередях и либо "прибивать" неправильный TCP, либо отдавать накопленные IP всем скопом. А вот от этого операционной системе может очень сильно поплохеть. Процессор будет просто не успевать обрабатывать такую ораву, и возникнут неизбежные тормоза. К тому же все настройки операционной системы, касающиеся TCP/IP, окажутся бесполезными, поскольку такой брандмауэр фактически уподобляется прокси-северу, отрезающему его от внешнего мира.