Назад в раздел
Понимание принципов работы файрвола (firewall).
ПОНИМАНИЕ ПРИНЦИПОВ РАБОТЫ ФАЙРВОЛА
|
|
ПОНИМАНИЕ ПРИНЦИПОВ РАБОТЫ ФАЙРВОЛА
NoWell представляют Вам очередную
статью американского аналитика безопасности Lance Spitzner'a, в которой он
описывает основные принципы работы файрвола на примере FW-1, и описывает
распространённые ошибки при его конфигурировании, а так же то, как их
избежать. Статья ориентирована на системных администраторов среднего
уровня подготовленности.
Назначение этой статьи- помочь вам понять, как работает
таблица состояний соединений файрвола FW-1. Эта таблица то как FW-1
поддерживает кто делает какие содинения и какие разрешены в полиси. Статья
основывается на исследования кторые я проводил последние пару месяцев. Для
того что бы помочь вам лучше понять таблицу состояний вашего FW-1 и
проверить мои данные, я поместил все исходники в конце этой страницы.
МОНИТОРИНГ СОСТОЯНИЙ
Эта статья начинается с вопроса: "Если у вас есть файрвол с
policy (полиси) которая разрешает все, разрешит ли файрвол создать новое
ТСР соединение АСК пакетом?" Часть меня говорит да. Если файрвол разрешает
все значит любой пакет пожет пройти. Однако часть меня говорила нет.
Учитывая, как работает мониторинг состояний, пакет должен быть отброшен.
Вы
можете подумать - какой чудак устанавливает соединение АСК пакетом
? Думаю, что этот чудак хочет понять, как работает таблица состояний. С
полиси которая позволяет все вы можете подумать что этот пакет пройдет. Но
после того как вы лучше поймете как работает мониторинг состояний вы
можете изменить ваше мнение…
Мое
первоначальное представление мониторинга состояний (по крайней мере на
Check Point FireWall-1) было таким: как только фв получает SYN пакет
устанавливающий соединение, он сверяется с полиси. Так же, как в
маршрутизаторе, этот пакет сравнивается с правилами последовательно
(начиная с нулевого правила). Если пакет прошел все правила и не был
принят, он отвергается. Затем соединение разрывается или
отбрасывается(удаленному хосту посылается RST). Однако, если пакет принят,
сессия заносится в таблицу состояний соединений файрвола, которая
находится в ядре. Затем любой последующий пакет (который не имеет
SYN-флага) сравнивается с таблицей мониторинга состояний. Если сессия в
таблице, и пакет часть этой сессии, то пакет принимается. Если пакет не
является частью сессии - он отбрасывается. Это увеличивает
производительность системы, т.к. каждый отдельный пакет не сравнивается с
полиси, а только SYN пакеты которые устанавливают соединие. Все другие
TCP-пакеты сравниваются только с таблицей состояний в ядре ( это очень
быстро)
Теперь вернемся к нашему вопросу. Если вы инициируете сессию
АСК-пакетом, примет ли FW пакет, даже если полиси разрешает все ? Как
говорилось ранее, вы подумаете что да. Теперь когда мы лучше понимаем
таблицу соединений, возможно стоит сказать "нет" =). Когда FW получает АСК
пакет, он сравнивает его с таблицей состояний в ядре, а не с полиси.
Однако если у файрвола не будет этой сессии в таблице состояний (он
никогда не получал SYN пакета), то он отбросит пакет, т.к. для него нет
записи в таблице состояний.
РЕЗУЛЬТАТ - КАК FW-1 СТРОИТ СОЕДИНЕНИЕ
Результат был весьма интересный. АСК-пакет не только
был принят , но и был добавлен в таблицу состояний. Мое
понимание работы FW было неправильным. Я узнал, что когда файрвол получает
пакет, который не является частью таблицы состояний соединений, он
сверяется с полиси вне зависимости от того, является ли он SYN, ACK
или еще каким-либо пакетом. Если полиси разрешает сессию, она (сессия)
добавляется в таблицу состояний. Все последующие пакеты сессии
сравниваются с таблицей состояний и принимаются. Т.к. в таблице состояний
есть запись для этой сессии, пакеты принимаются без проверки полиси. Внизу
приведены данные из утилиты fwtable.pl
(ver 1.0) которая конвертрует данные из 'fw tab -t connections'. В этой
таблице хранятся все текущие(?) соединения FW-1 в памяти. Записи, которые
вы видите внизу, есть часть таблицы состояний соединений, создание которых
было инициировано АСК пакетами. mozart #fwtable
---- FW-1 CONNECTIONS TABLE ---
Src_IP Src_Prt Dst_IP Dst_Prt
192.168.7.131 10003 207.229.143.8 25
192.168.7.131 10002 207.229.143.8 24
192.168.7.131 10001 207.229.143.8 23
IP_prot Kbuf Type Flags Timeout
6 0 16385 02ffff00 2845/3600
6 0 16385 02ffff00 2845/3600
6 0 16385 02ffff00 2845/3600
Здесь вы видите три принятых и добавленных в таблицу состояний
файрвола соединения. Однако эти три соединения были инициированы
АСК-пакетами. (это также справедливо для Null, SYN/ACK и многих других
пакетов, например FIN/ACK). Если пакет не является частью сессии из
таблицы состояний, он сверяется с полиси. И если он принят, сессия
добавляется в таблицу состояний. Если пакет не соответствует полиси, он
отбрасывается, а сессия закрывается. Вот как файрвол поддерживает
соединения: вы делаете 'fwstop;fwstart'. Когда вы перезаупскаете
файрвол, таблица соединений очищается и не одно соединение там не
присутсвует. Однако любое текущее соединение скорее всего будет посылать
АСКи. Файрвол их видит, сверяет с полиси и востанавливает таблицу
соединений. Все это прозрачно для конечного пользователя. Вот почему вы
теряете аутентифицированные и шифрованые сессии, у файрвола нет этих
соединений в ‘начальном состоянии’. Так же заметьте, таймаут в
правой колонке = 3600 секунд. После того как сессия добавлена в
таблицу состояний, файрвол сохраняет это соединение. Это значит что у вас
есть 60 минут чтобы создать и послать другой пакет что бы обновить таймер.
Параметры таймаута можно установить в меню control properties.
ЗАМЕТЬТЕ: Правильные FIN или RST пакеты не могут
создать сессию, т.к. они служат для разрыва соединения. Так же
единственный пакет, который не был добавлен с таблицу состояний был пакет
'Xmas' созданый с помощью сканера nmap (с опцией -sX), однако они были
приняты и занесены в логи.
Еще
одна вещь, которую я узнал - это то, что монитор состояний на FW-1 смотрит
только на IP адреса и номера портов отправителя и получателя для
определения сессии. Он не заботится опорядковых номерах, т.к. я создавал
различные порядковые номера которые файрвол принемал. Так же он не
заботится о типе пакета для создания соединения. Когда вы посылаете пакет
SYN создавая сессию, файрвол проверяет его по полиси. Если он подходит, он
добаляет сессию в таблицу состояний, как мы уже обсуждали ранее. В этот
момент таймаут сначала устанавливается на 60 секунд. Потом файрвол
ждет ответного пакета и таймаут устанавливается на 3600 секунд (60 минут).
Однако файрвол не заботится о том, какой тип пакета приходит. Я
инициировал соединение SYN пакетом и послал только АСК, который
файрвол удачно принял как часть соединения (если IP и порты совпадали).
Так что у файрвола нет интеллектуальности ждать SYN/ACK ответа, так же как
нет проверки порядковых номеров (TCP sequence numbers).
Потенциальный отказ в обслуживании (Bugtraq ID 549): Когда создается соединение,
если соединение инициируется АСК пакетом (или почти любым другим не SYN
пакетом таким как Null, FIN/ACK, SYN/ACK и т.д.) таймаут автоматически
устанавливается на 3600 секунд (по умолчанию), смотрите пример выше. В
этом есть потенциальная угроза отказа в обслуживании. Инициируя много
соединений АСК пакетами с системой, которая не существует, вы быстро
заполните таблицу состояний. Т.к. удаленной системы нет, не приходит ни
одного RST или FIN пакета чтобы сбросить соединение, оставляя
мертвое соединение в таблице на час. (помните, таймаут для не SYN пакетов
3600 секунд) Вы можете очень быстро заполнить таблицу соединений создавая
сессии АСК пакетами. К счастью эта DoS отака намного сложнее с внешней
стороны файрвола, чем с внутренней. К несчстью, легко самому заполнить
таблицу, делая сканирование из-за файрвола (как узнал я сам). Посмотрите
мнение, высказанное в ответе на эту
статью. А чтобы обойти вышеупомянутые грабли, можно предпринять
следующие шаги:
-Уменьшите TCP соединение до 15 минут (900 секунд). Это
уменьшает ‘окно возможностей’, которое может быть использовано для
заполнения вашей таблицы.
-Увеличьте вашу таблицу состояний.
Это усложнит ее заполнение.
-Установите строгие правила которые
ограничивают что может входить и выходить.
-Jason Rhoads сделал
скрипт fwconwatch.pl,
который будет отслеживать вашу таблицу соединений и предупреждать
Вас.
-Установите Fastpath (for ver 3.0) or FastMode (for ver
4.0), которые удаляют соединения из таблицы.
Фича FW-1, которая мне очень нравится - это обработка
SYN-пакетов. Если вы пытаетесь создать новую сессию, которая эмулирует
существующую, файрвол всё равно сравнивает ее с полиси. Скажем, вы
пытаетесь сделать следующее:
A --- FW --
B # Система A соединяется с B
Теперь система В может посылать любые пакеты системе А, если IP и
порты совпадают (т.е. пакеты есть часть одной сессии). Однако если система
В пытается установить новое соединение (при помощи стандартного SYN
пакета), даже если он использует те же порты, что и существующая сессия,
файрвол всё равно считает SYN-пакет частью новой сессии и сравнивает с
полиси. По моему, это хорошая возможность. Давайте представим, что в
предыдущем примере файрвол разрешает весь исходящий трафик от системы А и
не разрешает входящий от В. Единственный путь, когда В может общаться с А
- когда соединение было установленно ранее.
Когда система А соединяется с системой В, соединение
добавляется в таблицу состояний файрвола (см.предыдущий пример).
Теперь система В может отвечать посылая пакеты системе А. Одако файрвол не
создал большой дыры. Система В не может послать SYN пакета системе А,
устанавливая новое соединение, даже если порты и IP адреса совпадают.
Когда файрвол получит SYN пакет он сверит его с полиси. В приведенном
сценарии этот пакет будет отброшен, несмотря на то, что есть установленное
соединение.
FASTPATH
Если
fastpath установлен, то сессия не добавляется в таблицу соединений, т.е.
таблица соединений не создается. Причина в том что fastpath отслеживает
только SYN пакеты, так что нет нужды добавлять сессию в таблицу
соединений. Если пакет имеет любой другой флаг - пакет не фильтруется и
пропускается по умолчанию. Обычно fastpath используется для улучшения
производительности (или в редких случаях маршрутизации). Идея в том что
если пакет не имеет SYN флага он является частью соединения, т.к. только
SYN пакет может создать соединение. Так как отслеживаются только
SYN пакеты, производительность значительно увеличивается. Однако
использование fastpath обычно плохое решение т.к. это открывает
возможность большого количества других атак. Fastpath есть только в
FW-1 вер. 3.0 и является глобальным свойством, применяемым ко всем
TCP пакетам. В версии 4.0 это свойство называется Fastmode и может
выборочно применяться к различным сервисам.
ЗАКРЫТИЕ СОЕДИНЕНИЯ
Основываясь на поверхностных тестах, скажу, что FW-1 закрывает
соединения по таймауту. Когда модуль мониторинга видит сессию, которая
обменивается FIN или RST пакетами, он изменяет таймаут с 3600 секунд до
50. Если нет обмена другими пакетами в течении 50-секундного
интервала, то соединение удаляется из таблицы соединений. Если
пересылается любой пакет в этот период, то таймер переустанавливается на
50 секунд. Постоянно посылая пакеты после закрытия соединения, вы можете
вновь устанавливать таймер на 50 секунд. Это исключает возможность DoS
атаки, когда кто-то послыает левые RST или FIN пакеты. Поведение
этого таймаута может быть представлено как состояние TIME_WAIT в TCP
соединении после подтверждения (ACK) воторого FIN пакета в закрытии
сессии.
ЗАКЛЮЧЕНИЕ
Мое
первое впечатление, основанное на предварительных тестах таково, что
мониторинг состояний CheckPoint FW-1 есть полу-интеллектульный, но
только полу- =). Если FW-1 получает пакет, который не является частью
соединения из таблицы состояний, он сверяется с полиси. Если он принят, то
сессия добаляется в таблицу состояний, с которой сверяются все последующие
пакеты(Известными исключениями являются Xmas, FIN и RST пакеты). Это
хорошо т.к. файрвол будет иметь адекватную таблицу состояний которая будет
поддерживать соединения. Меня беспокоит то что когда соединение создается
АСК пакетом таймаут автоматически устанавливается на 3600 секунд и не
важно ответила система или нет. Это опасная возможность DoS атаки. Что мне
нравится так это то что SYN пакеты сравниваются с полиси даже если они
являются частью установленного соединения(это исключает 'tunneling' или
'piggybacking'). Однако таблица мониторинга не содержит информации о
порядковых номерах и SYN - SYN/ACK – ACK последовательностях. Все что он
знает это то что SYN пакет – первый пакет сессии и принемает все остальное
(если SYN был принят). Что касается закрытия соединения используемый метод
кажется достаточно понятным, похожим на TIME_WAIT состояние TCP. Надеюсь
после дальнейшего тестирования и дополнений со стороны firewall
community(?) эта статья станет начальным документом который ответит на
многие основные вопросы касающиеся того что такое мониторинг состояний и
насколько состоятелна таблица состояний.
Дальнейшие исследования
Все,
о чём я написал, было тестировано на Check Point FireWall-1 вер. 4.0 SP3
на Solaris x86 2.6. Утилиты, которые я использовал для того, чтобы читать
таблицу состояний и создавать мои собственные пакеты, могут быть найдены
ниже. Я бы хотел продолжить свои тестирования что бы узнать как файрвол
интерпретирует колонки ‘Type’ и ‘Flags’ в таблице состояний
соединений. А так же, как файрвол ‘сбрасывает’ соединение. Я ищу
кого-нибудь кто подтвердит или опровергнет то, что я привел здесь. Так же
любая дополнительная информация очень полезна.
DOWNLOAD
fwtable.pl
поможет вам лучше понять таблицы мониторинга состояний ваших файрфолов
(работает только для Check Point FW-1). Этот скрипт может быть запущен
локально на модуле файрвола, удаленно с любой станции обслуживания или
отдельно на системе где есть Перл.
lego.pl
позваляет создавть собственные TCP пакеты включая флаги, порты, порядковые
номера и т.д. Там нет интерфейса командной строки, надо править код, но он
очень простой. Написано miff’ом.
libnet для
низкоуровневой генерации ethernet-траффика.
|
|
|
|
 |
|
