Проверить файрвол и систему на уязвимость онлайн. Набор правил, реализующий политику

В этой второй статье описывается разрешение проблем, связанных с пакетным фильтром. Вместо приведения готовой таблицы в виде «проблема»-«решение» приводятся методы системного подхода для решения возникших проблем.

В этой второй статье (в серии из трёх) описывается разрешение проблем, связанных с пакетным фильтром. Вместо приведения готовой таблицы в виде «проблема»-«решение» приводятся методы системного подхода для решения возникших проблем.

Введение

Пакетный фильтр осуществляет выполнение политики фильтрации, обходя набор правил и, соответственно, блокирует либо пропускает пакеты. В главе даётся объяснение, как проверить, что политика фильтрации выполняется корректно, и как найти ошибки, если это не так.

В общем, в курсе этой главы мы будем сравнивать задачу написания набора правил фильтрации с программированием. Если же у вас нет навыков программирования, то это сравнение покажется вам скорее усложняющим задачу. Но ведь само по себе написание правил не требует наличия учёной степени по «computer science» или опыта программирования, не так ли?

Ответом будет «нет», этого вам наверняка не нужно. Язык, используемый для конфигурации пакетного фильтра, сделан похожим на человеческие языки. Например:

block all

pass out all keep state

pass in proto tcp to any port www keep state

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

К сожалению, компьютеры делают только то, что вы просите их сделать, а не то, что вы хотите сами. Хуже того, они не смогут отличить желаемое от действительного, если таковая разница есть. Значит, если компьютер неверно выполняет то, чего хотите вы, даже если считаете, что описали инструкции чётко - в ваших руках найти различия и изменить инструкции. А так как это и является общей проблемой в программировании, мы можем посмотреть, как же справляются с этим программисты. Тут и выходит, что навыки и методы, использующиеся для проверки и отладки программ и правил фильтрации очень похожи. И всё же тут вам не понадобится знание, какого бы то ни было языка программирования, для того чтобы понять implications для проверки и отладки.

Хорошая политика фильтрации.

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

Таким образом, первым шагом в конфигурации файрвола будет неформальное задание того, чего необходимо добиться. Какие соединения нужно блокировать либо пропускать?

Примером будет:

Есть три сети, которые должны быть отделены друг от друга файрволом. Любые соединения из одной сети в другую проходить через файрвол. У файрвола 3 интерфейса, каждый из которых, подключён к соответствующей сети:

$ext_if - во внешнюю сеть.

$dmz_if - DMZ с серверами.

$lan_if - LAN с рабочими станциями.

Хосты в LAN должны свободно соединяться с любыми хостами в DMZ или во внешней сети.

Серверы в DMZ должны свободно соединяться с хостами во внешней сети. Хосты внешней сети могут соединяться только к следующим серверам в DMZ:

Web-сервер 10.1.1.1 порт 80

Mail-сервер 10.2.2.2 порт 25

Все остальные соединения должны быть запрещены (к примеру, от машин во внешней сети к машинам в LAN).

Эта политика выражена неформально, так, чтобы любой читающий мог её понять. Она должна быть настолько конкретизирована, чтобы у читающего легко формулировались ответы на вопрос вида ‘Должно ли пропускаться соединение от хоста X к хосту Y входящее (или исходящее) на интерфейсе Z?’. Если вы задумались о тех случаях, когда ваша политика не отвечает такому требованию, значит она недостаточно чётко задана.

«Туманные» политики типа «разрешать только всё, что жизненно необходимо» или «блокировать атаки», необходимо уточнять, или у вас не получиться применить либо проверить их. Как и в разработке программного обеспечения, недостаточно формализованные задачи редко приводят к оправданным или корректным их реализациям. («Почему бы вам не пойти уже начать писать код, а я пока выясню, что нужно заказчику»).

Набор правил, реализующий политику

Набор правил записывается в виде текстового файла, содержащего предложения на формальном языке. Также как исходный код обрабатывается и переводится в инструкции машинного кода компилятором, «исходный текст» набора правил обрабатывается pfctl и результат интерпретируется pf в ядре.

Когда исходный код нарушает правила формального языка, анализатор рапортует о синтаксической ошибке и отказывается от дальнейшей обработки файла. Эта ошибка относится к ошибкам во время компиляции и обычно быстро исправляется. Когда pfctl не может разобрать ваш файл набора правил, он выдаёт строку, в которой обнаружена ошибка и более или менее информативное сообщение о том, что он не смог разобрать. До тех пор, пока весь файл не будет обработан без единой ошибки, pfctl не изменит предыдущий набор правил в ядре. А поскольку файл содержит одну или более синтаксических ошибок, не будет той «программы», которую pf может выполнить.

Второй тип ошибок называется «ошибки времени выполнения» (run-time errors), так как возникает при в синтаксически корректно записанной программе, которая успешно транслирована и выполняется. В общем случае, в языках программирования, такое может случиться, когда программой выполняется деление на нуль, делается попытка обратиться к недопустимым областям памяти или возникает нехватка памяти. Но так как наборы правил лишь отдалённо напоминают функционал языков программирования, большинство из подобных ошибок не может возникнуть во время применения правил, так например, правила не могут вызвать т.н. «падение системы», как это делают обычные программы. Однако набор правил может вызвать подобные ошибки, в виде блокирования или наоборот, пропускания пакетов, не соответствующих политике. Это иногда называется логической ошибкой, ошибкой которая не вызывает исключения и останова, а попросту выдаёт неверные результаты.

Итак, перед тем, как мы можем начать проверять, насколько корректно файрвол реализует нашу политику безопасности, необходимо сначала успешно загрузить набор правил.

Ошибки анализатора

Ошибки анализатора возникают при попытке загрузки списка правил с использованием pfctl, например:

# pfctl - f / etc/ pf. conf

/ etc/ pf. conf:3: syntax error

Это сообщение говорит о том, что в строке 3 файла /etc/pf.conf синтаксическая ошибка и pfctl не может загрузить правила. Набор в ядре не изменился, он остался таким же, как и до попытки загрузить новый.

Есть много разновидностей ошибок, выдаваемых pfctl. Для начала знакомства с pfctl необходимо просто внимательно их читать. Возможно, не все части сообщения откроют свой смысл для вас сразу, но необходимо прочесть их все, т.к. впоследствии это облегчит понимание того, что же пошло не так. Если в сообщении есть часть вида «имя файла:число: текст», оно ссылается на сточку с соответствующим номером в указанном файле.

Следующим шагом посмотрим на выданную строку, используя текстовый редактор (в vi вы можете перейти к 3 строке введя 3G в режиме beep), или так:

# cat -n /etc/pf.conf

1 int_if = "fxp 0"

2 block all

3 pass out on $int_if inet all kep state

pass out inet on $int_if all kep state

Проблема может быть в простой опечатке, как в этом случае (“kep” вместо “keep”). После исправления попробуйте перезагрузить файл:

# pfctl - f / etc/ pf. conf

/ etc/ pf. conf:3: syntax error

# head -n 3 /etc/pf.conf | tail -n 1

pass out inet on $int_if all keep state

Теперь все ключевые слова верны, но, при ближайшем рассмотрении, мы замечаем, что расположение ключевого слова “inet” перед “on $int_if” неверно. Это иллюстрирует то, что одна и также строка может содержать более одной ошибки. Pfctl выводит сообщение о первой найденной ошибке и прекращает свое выполнение. Если при повторном запуске был выдан тот же номер строки, значит в ней есть еще ошибки, либо предыдущие не были корректно устранены.

Неправильно расположенные ключевые слова также являются распространенной ошибкой. Это может быть выявлено при сравнении правила с эталонным BNF-синтаксисом в конце файла справки man pf.conf(5), которая содержит:

pf-rule= action [ ("in" | "out") ]

[ "log" | "log-all" ] [ "quick" ]

[ "on" ifspec ] [ route ] [ af ] [ protospec ]

hosts [ filteropt-list ]

ifspec = ([ "!" ] interface-name) | "{" interface-list "}"

af = " inet" | " inet6"

Что означает, что ключевое слово “inet” должно следовать за “on $int_if”

Подправим и попробуем ещё раз:

# pfctl - f / etc/ pf. conf

/ etc/ pf. conf:3: syntax error

# head -n 3 /etc/pf.conf | tail -n 1

pass out on $int_if inet all keep state

Никаких очевидных ошибок теперь не осталось. Но нам не видны все сопутствующие детали! Строка зависит от макроопределения $inf_if. Что же может быть неправильно определено?

# pfctl -vf /etc/pf.conf

int_if = "fxp 0"

block drop all

/etc/pf.conf:3: syntax error

После исправления опечатки «fxp 0» на «fxp0» пробуем ещё раз:

# pfctl - f / etc/ pf. conf

Отсутствие сообщений свидетельствует о том, что файл был успешно загружен.

В некоторых случаях pfctl может выдавать более специфичные сообщения об ошибках, нежели просто «syntax error»:

# pfctl -f /etc/pf.conf

/etc/pf.conf:3: port only applies to tcp/udp

/etc/pf.conf:3: skipping rule due to errors

/etc/pf.conf:3: rule expands to no valid combination

# head -n 3 /etc/pf.conf | tail -n 1

pass out on $int_if to port ssh keep state

Первая строка сообщения об ошибке наиболее информативна по сравнению с остальными. В этом случае проблема в том, что правило, указывая порт, не определяет протокол - tcp либо udp.

В редких случаях pfctl бывает обескуражен наличием непечатных символов или ненужных пробелов в файле, такие ошибки нелегко обнаружить без специальной обработки файла:

# pfctl -f /etc/pf.conf

/etc/pf.conf:2: whitespace after \

/etc/pf.conf:2: syntax error

# cat -ent /etc/pf.conf

1 block all$

2 pass out on gem0 from any to any \ $

3 ^ Ikeep state$

Здесь проблемой является символ пробела, после «бэкслэша» но перед концом второй строки, обозначенным знаком “$” в выводе cat -e.

После того, как набор правил успешно загружен, неплохо бы посмотреть на результат:

$ cat /etc/pf.conf

block all

# pass from any to any \

pass from 10.1.2.3 to any

$ pfctl -f /etc/pf.conf

$ pfctl - sr

block drop all

«Бэкслэш» в конце строки комментария на самом деле обозначает, что строка комментария будет продолжена ниже.

Разворачивание списков заключённых в фигурные скобки {} может выдать результат, который возможно вас удивит, а заодно и покажет обработанный анализатором набор правил:

$ cat /etc/pf.conf

pass from { !10.1.2.3, !10.2.3.4 } to any

$ pfctl -nvf /etc/pf.conf

pass inet from ! 10.1.2.3 to any

pass inet from ! 10.2.3.4 to any

Здесь загвоздка в том, что выражение "{ !10.1.2.3, !10.2.3.4 }" не будет означать «все адреса, за исключением 10.1.2.3 и 10.2.3.4», развёрнутое выражение само по себе означает совпадение с любым возможным адресом.

Вы должны перезагрузить свой набор правил после перманентных изменений, для того, чтобы убедиться, что и pfctl сможет загрузить его при перезагрузке машины. В OpenBSD стартовый rc-скрипт из /etc/rc первым делом загружает небольшой набор правил, установленный по умолчанию, который блокирует весь трафик, за исключением необходимого на этапе загрузки (такого как dhcp или ntp). Если же скрипт не сможет загрузить реальный набор правил из /etc/pf.conf из-за синтаксических ошибок, внесённых до перезагрузки машины без проверки, то набор «по-умолчанию» останется активным. К счастью, в этом наборе разрешены входящие ssh соединения, поэтому проблему можно будет решить удалённо.

Тестирование

Так как мы имеем предельно точно определённую политику, и набор правил, который должен её реализовывать, тогда термин тестирование будет означать в нашем случае соответствие получившегося набора заданной политике.

Есть всего два пути неправильного срабатывания правил: блокирование соединений, которые должны пропускаться и наоборот, пропускание тех соединений, которые должны блокироваться.

Тестирование в общем случае подразумевает под собой системный подход к упорядоченному созданию различных видов соединений. Невозможно проверить все возможные комбинации источника/приёмника и соответствующих портов на интерфейсах, т.к. файрвол может теоретически столкнуться с огромным количеством таких комбинаций. Обеспечение изначальной правильности набора правил может быть обеспечено только для очень простых случаев. На практике, наилучшим решением будет создание списка тестовых соединений, основанного на политике безопасности, такого, чтобы каждый пункт политики был бы затронут. Так, для нашего примера политики, список тестов будет следующим:

Соединение из LAN в DMZ (должно пропускаться)

из LAN во внешнюю сеть (должно пропускаться)

из DMZ в LAN (должно блокироваться)

из DMZ во внешнюю сеть (должно пропускаться)

из внешней сети в DMZ к 10.1.1.1 на порт 80 (должно пропускаться)

из внешней сети в DMZ к 10.1.1.1 на порт 25 (должно блокироваться)

из внешней сети в DMZ к 10.2.2.2 на порт 80 (должно блокироваться)

из внешней сети в DMZ к 10.2.2.2 на порт 25 (должно пропускаться)

из внешней сети в LAN (должно блокироваться)

Ожидаемый результат должен быть определён в этом списке до начала тестирования.

Это может звучать странно, но цель каждого теста - найти ошибки в реализации набора правил файрвола, а не просто констатировать их отсутствие. А высшая цель процесса, это построение набора правил без ошибок, поэтому, если вы предполагаете, что здесь вероятно могут содержаться ошибки, вам будет лучше их найти, чем пропустить. И если уж вы берёте на себя роль тестера, вы должны придерживаться деструктивного стиля мышления и пробовать обойти ограничения файрвола. И только факт, что ограничения нельзя сломать, станет аргументированным подтверждением того, что набор правил не содержит ошибок.

TCP и UDP соединения могут быть проверены с помощью nc. nc может использоваться как клиентская и серверная часть (используя опцию -l). А для ICMP запросов и ответов, наилучшим клиентом для проверки будет ping.

Для проверки факта блокирования соединения можно использовать любые средства, которые будут пытаться создавать соединения с сервером.

Используя инструменты из коллекции портов, такие как nmap, вы легко сможете просканировать множество портов даже на нескольких хостах. Если результаты выглядят не совсем ясно, не поленитесь заглянуть в man-страницу. К примеру, для TCP порта сканер возвращает значение ‘unfiltered’, когда nmap получает RST от pf. Также pf, установленный на одной машине со сканером, может привносить своё влияние на корректность работы nmap.

Более сложные инструменты проведения сканирования могут включать в себя средства для создания фрагментированных или посылки некорректных ip пакетов.

Для проверки того, что фильтром пропускаются соединения заданные в политике, наилучшим методом будет проверка с использованием тех приложений, которые впоследствии и будут использоваться клиентами. Так, проверка прохождения http-соединений с разных машин-клиентов веб-сервера, а также из разных браузеров и выборка различного контента будет лучше, чем просто подтверждение установления TCP сессии к nc, работающего в качестве серверной части. Различные факторы, такие, как операционная система хоста, также могут вызвать ошибки - проблемы с масштабированием TCP-окна (TCP window scaling) или ответами TCP SACK между определёнными операционными системами.

Когда очередной пункт тестирования пройден, результаты его могут быть не всегда одинаковыми. Может обрываться связь в процессе установления соединения, в случае, если файрвол возвращает RST. Установление соединения может просто оборваться по таймауту. Соединение может полностью устанавливаться, работать, но через некоторое время зависать или обрываться. Соединение может держаться, но пропускная способность или задержки могут отличаться от ожидаемых, быть выше или ниже (в случае если вы используете AltQ для ограничения пропускной способности).

В качестве ожидаемых результатов, помимо пропуска/блокирования соединения, можно также отметить то, логируются ли пакеты, как они транслируются, маршрутизируются, увеличивают ли нужные счётчики, если это необходимо. Если для вас важны эти аспекты, то их также необходимо включить в методику тестирования.

Ваша политика может включать требования, касающиеся производительности, реакции на перегрузки, отказоустойчивость. А они могут потребовать отдельных тестов. Если настраиваете отказоустойчивую систему с использованием CARP, вероятно вы захотите узнать, что произойдёт при различного рода отказах.

Когда вы наблюдаете результат, отличный от ожидаемого, пошагово отметьте ваши шаги во время теста, чего вы ожидали, почему вы этого ожидали, полученный результат и как результат отличается от ваших ожиданий. Повторите тест, чтобы увидеть, воспроизводится ли ситуация, либо отличается раз от раза. Попробуйте изменять входные параметры проверки (адрес источника/приёмника либо порты).

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

Этот же принцип относится и к другим изменениям, вносимым в набор. Такая формальная процедура проверки поможет сделать процесс менее подверженным к внесению ошибок. Возможно, для мелких изменений и не потребуется повторять всю процедуру, но сумма нескольких мелких изменений может повлиять на общий результат обработки набора. Вы можете использовать систему контроля версий, такую как cvs, для работы с вашим конфигурационным файлом, т.к. это поможет в исследовании изменений, которые привели к появлению ошибки. Если вы знаете, что ошибка не возникала неделю назад, но сейчас она есть, просмотр всех сделанных изменений за последнюю неделю поможет заметить проблему, или, по меньшей мере, откатиться до момента её отсутствия.

Нетривиальные наборы правил можно рассматривать как программы, они редко бывают идеальны в своей первой версии, и требуется время, для того чтобы с уверенностью утверждать, что в них нет ошибок. Однако, в отличие от обычных программ, которые большинством программистов никогда не считаются свободными от ошибок, наборы правил всё же достаточно просты, чтобы быть близкими к этому определению.

Отладка

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

Перед тем, как вы начнёте поиск причины, вызвавшей проблему, вы должны чётко представить себе суть этой проблемы. Если вы сами заметили ошибку во время тестирования, это очень просто. Но если другой человек сообщает вам об ошибке, постановка чёткой задачи из неточного сообщения об ошибке может быть непростой задачей. Лучше всего начать с того, что вы сами воспроизведёте ошибку.

Не всегда проблемы сети могут быть вызваны пакетным фильтром. Перед тем, как сфокусировать своё внимание на отладке конфигурации pf, необходимо удостовериться, что проблема вызвана пакетным фильтром. Это легко сделать, а также поможет сэкономить время на поиск неисправности в другом месте. Просто выключите pf командой pfctl -d и проверьте, проявляется ли проблема снова. Если это так, включите pf командой pfctl -e и посмотрите, что происходит. Этот метод не пройдёт в некоторых случаях, например, если pf не делает правильную трансляцию сетевых адресов (NAT), то выключение pf очевидно не избавит вас от ошибки. Но в тех случаях, когда это возможно, постарайтесь убедиться, что виновен именно пакетный фильтр.

Соответственно, если проблема в пакетном фильтре, первое, что необходимо сделать, это убедиться в том, pf действительно работает и успешно загружен нужный набор правил:

# pfctl -si | grep Status

Status: Enabled for 4 days 13:47:32Debug: Urgent

# pfctl -sr

pass quick on lo0 all

pass quick on enc0 all

Отладка по протоколам

Следующим шагом отладки будет отражение проблемы в конкретных сетевых соединениях. Если вы имеете посылку: «не работает обмен мгновенными сообщениями в приложении X», нужно выяснить, какие сетевые соединения используются. Заключение может быть в виде «хост А не может установить соединение с хостом B на порту С». Иногда эта задача представляет наибольшую сложность, но если у вас есть информация о нужных соединениях и вы знаете, что файрвол их не пропустит, нужно будет всего лишь изменить правила для разрешения данной проблемы.

Есть несколько путей для выяснения используемых приложением протоколов или соединений. Tcpdump может отобразить пакеты прибывающие или покидающие, как реальный сетевой интерфейс, так и виртуальные, такие как pflog и pfsync. Вы можете задать выражение для фильтрации, чтобы задать пакеты для отображения и исключить побочный сетевой «шум». Попытайтесь установить сетевое соединение в нужном приложении и посмотрите на отсылаемые пакеты. Например:

# tcpdump -nvvvpi fxp0 tcp and not port ssh and not port smtp

23:55:59.072513 10.1.2.3.65123 > 10.2.3.4.6667: S

4093655771:4093655771(0) win 5840

1039287798 0,nop,wscale 0> (DF)

Это пакет TCP SYN , первый пакет из устанавливаемого TCP соединения (TCP handshake).

Отправитель - 10.1.2.3 порт 65123 (выглядит как случайный непривилегированный порт) а получатель 10.2.3.4 порт 6667. Детальное объяснение формата вывода tcpdump вы найдёте на страницах руководства по утилите. Tcpdump - наиболее важный инструмент для отладки проблем, связанных с pf, и очень важно познакомиться с ним поближе.

Другой метод - использование функции ведения лог-файлов в pf. Полагая, что вы используйте опцию ‘log’ во всех правилах с ‘block’, тогда все пакеты, заблокированные pf будут отражены в логе. Можно удалить опцию ‘log’ из правил, которые имеют дело с известными протоколами, т.е. записываться в лог будут только те пакеты, которые идут на неизвестные порты. Попробуйте использовать приложение, которое не может установить связь и загляните в pflog:

# ifconfig pflog0 up

# tcpdump -nettti pflog0

Nov 26 00:02:26.723219 rule 41/0(match): block in on kue0:

195.234.187.87.34482 > 62.65.145.30.6667: S 3537828346:3537828346(0) win

16384 (DF)

Если вы используете pflog - демона, который постоянно прослушивает pflog0 и сохраняет полученную информацию в /var/log/pflog, сохранённую информацию можно увидеть так:

# tcpdump - netttr / var/ log/ pflog

Когда выводите сохраненные pf пакеты, вы можете использовать дополнительные выражения для фильтрации, например, просмотреть пакеты, которые были заблокированы на входе на интерфейсе wi0:

# tcpdump -netttr /var/log/pflog inbound and action block and on wi0

Некоторые протоколы, такие как FTP, не так легко отследить, так как они не используют фиксированные номера портов, либо используют несколько сосуществующих соединений. Возможно, будет невозможно пропустить их через файрвол без открытия широкого диапазона портов. Для отдельных протоколов существуют решения, подобные ftp-proxy.

Отладка правил

Если ваш набор правил блокирует конкретный протокол потому что вы не открыли нужный порт, это больше проблема стадии проектировки нежели баг в правилах. Но что если вы видите, что блокируется соединение для которого у вас есть пропускающее его правило?

Например ваш набор содержит правило

block in return-rst on $ext_if proto tcp from any to $ext_if port ssh

Но когда вы пытаетесь подсоединиться к TCP порту 22, соединение принимается! Похоже, что файрвол игнорирует ваше правило. Как и в сборке «паззлов», в этих случаях, когда с ними сталкиваешься первые несколько раз, существует простое логическое и, как правило, тривиальное объяснение.

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

# pfctl -si | grep Status

Status: Enabled for 4 days 14:03:13Debug: Urgent

# pfctl -gsr | grep "port = ssh"

@14 block return-rst in on kue0 inet proto tcp from any to 62.65.145.30 port = ssh

Следующее, что мы имеем: принимаются соединения TCP на порт 22 на kue0. Можно подумать, что это и так очевидно, но нелишним будет проверить. Запустите tcpdump:

# tcpdump -nvvvi kue0 tcp and port 22 and dst 62.65.145.30

Теперь повторите SSH соединение. Вы должны увидеть пакеты из вашего соединения в выводе tcpdump. Возможно вы их не видите, а это может быть из за того, что соединение на самом деле не проходит через kue0, а проходит через другой интерфейс, что объясняет, почему не срабатывает правило. Или вы возможно соединяетесь с другим адресом. Если вкратце, то если вы не видите ssh пакеты, то pf их также не увидит возможно не может их заблокировать используя правило, приведённое в нашей задаче.

Но если вы видите пакеты с помощью tcpdump, pf их тоже «увидит» и будет их фильтровать. Следующим предположением будет то, что блокирующее правило должно не просто присутствовать в наборе (что мы уже выяснили), а быть последним совпадающим правилом для нужных пакетов. Если же это не последнее правило, очевидно, согласно этому не принимается решение о задержании пакетов.

В каких случаях правило может быть не последним совпадающим правилом? Возможны три причины:

А) правило не срабатывает, так как просмотр правил не доходит до нужного нам.

Ранее присутствующее правило также срабатывает и вызывает прекращение выполнения опцией ‘quick’;

Б) обработка правила производится, но правило не срабатывает из за несовпадения отдельных критериев.

В) обработка правила производится, правило срабатывает, но обработка продолжается и последующие правила также срабатывают для пакета.

Чтобы отвергнуть эти три случая вы можете, глядя на загруженный набор правил мысленно представить себе обработку гипотетического TCP пакета, приходящего на интерфейс kue0 и порт 22. Выделите отлаживаемый блок. Начните обход с первого правила. Совпадает? Если да - пометьте его. Имеет ли оно опцию ‘quick’? Если так, то прекращаем обход. Если же нет, продолжаем со следующим правилом. Повторяйте проверку, до нахождения совпадения с опцией ‘quick’ или достижения конца набора правил. Какое правило совпало последним? Если это не правило номер 14, вы нашли объяснение проблемы.

Обход правил вручную может показаться забавным, тем не менее, он, при наличии достаточного опыта может быть проделан достаточно быстро и большой степенью надёжности. Если набор достаточно большой, вы можете временно его сократить. Сохраните копию реального списка правил и удалите те записи, которые, на ваш взгляд, не повлияют на результат. Загрузите этот набор и повторите проверку. Если теперь соединение блокируется, следовательно, казавшиеся несвязанными с искомыми пакетами правила ответственны за случаи А либо Б. Добавляйте правила одно за другим, повторяя тест, до тех пор, пока не найдёте нужное. Если соединение всё еще пропускается после удаления не влияющих на него правил - повторите мысленный обход уменьшенного набора.

Другой метод, это использование способности pf вести логи для идентификации случаев А или С. Добавьте ‘log’ ко всем правилам с ‘pass quick‘ перед 14ым правилом. Добавьте ‘log’ ко всем правилам с ‘pass’, стоящим после 14ого правила. Запустите tcpdump для интерфейса pflog0 и устанавливайте ssh соединение. Вы увидите, какие правила помимо 14ого срабатывают на ваших пакетах последним. Если в логе ничего нет, значит имеет место случай Б.

Отслеживание соединений через файрвол

Когда соединение проходит через файрвол, пакеты приходят на один интерфейс, а передаются наружу через второй. Ответы приходят на второй интерфейс, а уходят в первый. Соединения, таким образом, могут обрываться в каждом из этих четырёх случаев.

Первое, вы должны выяснить, в каком из четырёх случаев проблема. Если вы попытаетесь установить соединение, вы должны будете увидеть пакет TCP SYN на первом интерфейсе, используя tcpdump. Вы должны также увидеть тот же TCP SYN пакет на выходе со второго интерфейса. Если вы его не видите, следовательно, заключаем, что pf блокирует входящий пакет на первом интерфейсе, либо исходящий на втором.

Если же SYN посылка не блокируется, вы должны будете видеть SYN+ACK, приходящий на второй интерфейс и выходящий с первого. Если нет - pf блокирует SYN+ACK на каком-то интерфейсе.

Добавьте опцию ‘log’ к правилам, которые должны пропускать SYN и SYN+ACK на обоих интерфейсах, также к правилам, которые должны их блокировать. Повторите попытку соединения и проверьте pflog. Он должен прояснить, в каком случае происходит блокировка и каким правилом.

Отладка состояний соединений

Наиболее распространённая причина блокирования пакетов pf состоит в том, что в наборе существует избыточное блокирующее правило. Соответствующее правило, срабатывающее по последнему совпадению, может быть найдено добавлением опции ‘log’ во все потенциально влияющие на результат правила и прослушиванием интерфейса pflog.

В меньшем количестве случаев случается так, что pf «молча» отбрасывает пакеты основываясь не на правилах, и здесь добавление ‘log’ во все правила не приведёт к попаданию сброшенных пакетов в pflog. Часто пакет почти, но не полностью подпадает под запись в таблице состояний (state entry).

Помните, что для каждого обрабатываемого пакета, пакетный фильтр производит просмотр таблицы состояний. Если найдена совпадающая запись, пакет немедленно пропускается, не вызывая для себя обработки набора правил.

Запись в таблице состояний содержит информацию, относящуюся к одному соединению.

Каждая запись имеет уникальный ключ. Этот ключ состоит из нескольких значений, которые ограничивают constant throughout время жизни соединения. Вот они:

Тип адреса (Ipv4 или Ipv6)
Адрес источника
Адрес приёмника
Протокол (TCP UDP)
Порт источника
Порт приёмника

Этот ключ используется для всех пакетов, относящимися к одному и тому же соединению, и пакеты разных соединений будут всегда иметь разные ключи.

Когда опцией ‘keep state’ из правила создаётся запись в таблице состояний, запись о соединении сохраняется с использованием ключа данного соединения. Важное ограничение для таблицы состояний - все ключи должны быть уникальными. Т.е. не может быть двух записей с одинаковыми ключами.

Возможно сразу не очевидно то, что те же два хоста не могут установить несколько сосуществующих соединений используя те же адреса, протоколы и порты, но это есть фундаментальное свойство как TCP так и UDP. Фактически, стеки TCP/IP всего лишь могут ассоциировать отдельные пакеты с их сокетами выполняя выборку, основанную на адресах и портах.

Даже если соединение закрыто, та же пара адресов и портов не может быть заново задействована сразу же. Сетевым оборудованием могут позднее доставляться повторно переданные пакеты, и если стеком TCP/IP получателя они будут ошибочно приняты за пакеты вновь созданного соединения, это помешает или вовсе разорвёт новое соединение. По этой причине оба хоста должны выждать определённый промежуток времени, называемый 2MSL («двойное время жизни сегмента», «twice the maximum segment lifetime») перед тем, как снова иметь возможность использовать те же адреса и порты для нового соединения.

Вы можете пронаблюдать это свойство, вручную устанавливая несколько соединений к одному и тому же хосту. К примеру, имея веб-сервер работающий на 10.1.1.1 и порту 80, и дважды подсоединяясь с 10.2.2.2. используя nc:

$ nc -v 10.1.1.1 80 & nc -v 10.1.1.1 80

Connection to 10.1.1.1 80 port succeeded!

Во то время, пока соединения открыты, можете с помощью netstat на клиенте или сервере вывести информацию об этих соединениях:

$ netstat -n | grep 10.1.1.1.80

tcp 0 0 10.2.2.6.28054 10.1.1.1.80 ESTABLISHED

tcp 0 0 10.2.2.6.43204 10.1.1.1.80 ESTABLISHED

Как видите, клиент выбрал два различных (случайных) порта-источника, поэтому это не нарушает требования к уникальности ключей.

Вы можете указать nc использовать определённый порт-источник опцией -p:

$ nc -v -p 31234 10.1.1.1 80 & nc -v -p 31234 10.1.1.1 80

Connection to 10.1.1.1 80 port succeeded!

nc: bind failed: Address already in use

TCP/IP стек клиента предотвратил нарушение уникальности ключей. Некоторые редкие и ошибочные реализации TCP/IP стеков не отвечали этому правилу, и поэтому, как мы скоро увидим, pf заблокирует их соединения при нарушении уникальности ключей.

Вернёмся назад к тому месту, когда pf делает запрос в таблицу состояний, в то время когда пакет начинает отфильтровываться. Запрос состоит из двух шагов. Первый запрос делается для поиска вхождения в таблицу записи с ключом, соответствующим протоколу, адресам, и порту пакета. Поиск будет вестись для пакетов, идущих в любом направлениях. Предположим, что приведённый ниже пакет создал запись в таблице состояний:

incoming TCP from 10.2.2.2:28054 to 10.1.1.1:80

Запрос к таблице обнаружит следующие записи в таблице состояний:

incoming TCP from 10.2.2.2:28054 to 10.1.1.1:80

outgoing TCP from 10.1.1.1:80 to 10.2.2.2:28054

Запись в таблице включает информацию о направлении (входящий или исходящий) первого пакета, создавшего запись. Например следующие записи не вызовут совпадения:

outgoing TCP from 10.2.2.2:28054 to 10.1.1.1:80

incoming TCP from 10.1.1.1:80 to 10.2.2.2:28054

Причина этих ограничений неочевидна, но довольно проста. Представьте, что у вас всего один интерфейс с адресом 10.1.1.1, где веб-сервер осуществляет прослушивание порта 80. Когда клиент 10.2.2.2 подсоединяется, используя случайно выбранный исходящий порт 28054, первый пакет соединения приходит на ваш интерфейс и все ваши исходящие ответы должны будут идти с 10.1.1.1:80 на 10.2.2.2:28054. Вы же не будете пропускать исходящие пакеты с 10.2.2.2:28054 к 10.1.1.1:80, так как такие пакеты не имеют смысла.

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

Когда попытка отыскать пакет среди записей в таблице состояний терпит неудачу, производится обход списка правил фильтра. Вы должны специально разрешить прохождение пакета наружу через второй интерфейс отдельным правилом. Наверняка вы используете ‘keep state’ в этом правиле, чтобы вторая запись в таблице состояний охватывала всё соединение и на втором интерфейсе.

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

Теперь мы также сможем объяснить разницу между свободным соединением и соединением, привязанным к интерфейсу. По умолчанию pf создаёт записи, которые не привязаны ни к какому интерфейсу. Поэтому, если вы разрешаете соединения на одном интерфейсе, пакеты относящиеся к соединению и подпадающие под запись в таблице (включая информацию о направлении пакета!) проходят через любой интерфейс. В простых инсталляциях со статической маршрутизацией это больше теоретические выкладки. В принципе, вы не должны видеть пакеты одного соединения, прибывающие через несколько интерфейсов и ответные пакеты, уходящие также на несколько интерфейсов. Однако при динамической маршрутизации такое возможное. Вы можете привязать записи о состояниях к конкретному интерфейсу используя глобальную установку ‘set state-policy if-bound’ или опцией для каждого правила ‘keep state (if-bound)’. Так вы будете уверены, что пакеты будут подпадать под записи только с интерфейса, который эти записи создал.

Если используется интерфейсы для туннелей, то одно и то же соединение проходит через файрвол несколько раз. Например первый пакет соединения сначала может пройти через интерфейс A, затем через B, потом С и наконец покинуть нас через интерфейс D. Обычно пакеты будут инкапсулированы на интерфейсах A и D и декапсулируется на B и C, поэтому pf видит пакеты разных протоколов и вы можете создать 4 различных записи в таблице состояний. Без инкапсуляции пакет будет неизменен на всех четырёх интерфейсах и вы не сможете использовать некоторые возможности, как трансляцию адреса или модуляцию номера tcp последовательности, потому что это приведёт к появлению в таблице состояний конфликтующих ключей. До тех пор, пока у вас не будет законченной установки включающей интерфейсы с туннелированием и отлаженными ошибкми вида "pf: src_tree insert failed", вы не сможете считать свою инталяцию достаточно успешной. Вернёмся к запросу к таблице состояний, производящемуся для каждого пакета перед проверкой правил. Запрос должен вернуть единственную запись с подходящим ключом, либо не вернуть ничего. Если запрос ничего не возвращает, производится обход списка правил.

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

Есть большое количество TCP атак, в которых атакующий пытается управлять соединением между двумя хостами. В большинстве случаев, атакующий не находится на пути маршрутов между хостами, поэтому не может прослушать легитимные пакеты пересылаемые хостами. Однако он может отсылать пакеты любому из хостов, имитирующие пакеты его собеседника, путём спуфинга(“spoofing”) - подделки адреса отправителя. Целью атакующего может являться предотвращение возможности создания соединений между хостами или обрыв уже установленных соединений (чтобы вызвать отказ в обслуживании) или для создания вредоносной загрузки на соединения.

Для успешной атаки атакующему необходимо верно «угадать» несколько параметров соединения, таких как адрес/порт источника и приёмника. И для широко распространённых протоколов это может быть не так уж сложно, как может показаться. Если атакующий знает адреса хостов и один из портов (поскольку речь идёт о распространённом сервисе), ему будет нужно только «угадать» один порт. Даже если клиент использует по-настоящему случайный порт-источник (что на самом деле не всегда верно), атакующему нужно всего лишь перебрать 65536 портов за короткий промежуток времени. (В большинстве случаев даже (65536-1024) портов, т.е. только непривилегированные порты - прим. переводчика))

Но вот что по настоящему трудно угадать для нападающего, так это верный номер последовательности (и его подтверждение). Если оба хоста выбирают начальный номер последовательности случайным образом (или вы используете модуляцию номера последовательности для хостов, которые имеют «слабый» генератор ISN (Initial Sequence Number)), то атакующему не удастся подобрать соответствующее значение в нужный момент соединения.

Во время существования валидного TCP соединения номера последовательностей (и подтверждения) для отдельных пакетов изменяются согласно определенным правилам.

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

pf использует правила, чтобы определить наименьший диапазон для легитимных номеров последовательностей. В общем случае, pf может точно определить подлинность только 30000 из 4294967296 возможных номеров последовательности в любой момент соедиения. Только если номер последовательности и подтверждение входит в это окно, pf убедится в том, что пакет легитимный и пропустит его.

Если во время проведения запроса к таблице состояний найдена подходящая запись, на следующем шаге номера последовательностей пакетов, сохранённых в таблице, проверяются на вхождение в диапазон возможных значений. В случае неудачи при сравнении pf сгенерирует сообщение "BAD state" и отбросит пакет без вычисления набора правил. Есть две причины, по которым может не произойти сравнения с правилами: почти наверняка будет являтся ошибкой пропуск пакета, т.к. если вычисление набора приведёт к попаданию в правиле на опцию "keep state" и pf не сможет вынести решение и создать новую запись потому что это приведёт к появлению кнфликтующих ключей в таблице.

Для того чтобы видеть и записывать в лог сообщения "BAD state", вам необходимо включить отладочный режим используя команду:

$ pfctl - xm

Отладочные сообщения по умолчанию попадают на консоль,также syslogd записывает их в /var/log/messages. Ищите сообщения начинающиеся на "pf":

pf: BAD state: TCP 192.168.1.10:20 192.168.1.10:20 192.168.1.200:64828

[ lo=1185380879 high=1185380879 win=33304 modulator=0 wscale=1]

4:4 A seq=1185380879 ack=1046638749 len=1448 ackskew=0 pkts=940:631

dir=out,fwd

pf: State failure on: 1 |

Эти сообщения всегда идут парами. Первое сообщение показывает запись в таблице состояний в момент, когда пакет был заблокирован и номера последовательности пакета, который привел к ошибке. Вторая запись отображает условия, которые были нарушены.

В конце первого сообщения вы увидите, была ли создана запись состояния на входящий (dir=in) или исходящий (dir=out) пакет, и шел ли заблокированный пакет в том же напрвлении (dir=,fwd) или противоположном (dir=,rev) направлении.

Запись в таблице содержит три адреса: пары портов, два из которых всегда равны между собой, в случае если соединение не подверглось преобразованию nat,rdr или bnat. Для исходящих соединений источник выводится слева, а приёмник пакета - справа. Если исходящее соединение задействует преобразование адреса источника, пара в середине показывает источник после преобразования. Для входящих соединений источник находится справа в выводе, а адрес назначения посередине. Если входящее соединение подвергается преобразованию адреса назначения, пара ip/port слева показывает приёмник после проведённого преобразования. Этот формат соответствует выводу pfctl -ss, ч той лишь разницей, что pfctl показывает направление пакета используя стрелки.

В выводе вы можете видеть текущие номера последовательности у хостов в квадратных скобках. Так значение "4:4" означает, что соедиенение установлено полностью (меньшие значения более вероятны на этапе установления соединения, большие - к моменту закрытия соедиения). "A" означает, что заблокированный пакет имел установленный флаг ACK (также как и в выводе флагов у tcpdump), далее идут значения номеров последовательностей (seq=) и (ack=) в заблокированных пакетах и длина полезной нагрузки пакета - длина данных (len=). askskew это часть внутреннего представления данных в таблице, задействующаяся только при значениях не равных нулю.

Запись "pkts=930:631" обзначает, что с ней совпало 940 пакетов, шедших напрвлении, совпадающим с пакетом, вызвавшим создание данной записи, и 631 пакет в противоположном напрвлении. Эти счётчики будут особенно полезны при поиске проблем на этапе установления соединения, если один из них равен нулю, это будет противоречить вашему ожиданию того, что с данной записью совпадают пакеты, идущие в обоих напрвлениях.

Следующее сообщение собдержит список из одной или нескольких цифр. Каждая цифра представляет собой проверку, на которой произошла ошибка:

размер окна пакета превышает максимальный размер у получателя (seq + len > high)
пакет содержит уже переданные данные (seq< lo - win)
ackskew меньше минимального значения
ackskew больше максимального значения
то же, что и в (1), но с разницей (seq + len > high + win)
то же, что и в (2), но (seq < lo - maximum win)

К счастью, сообщения "BAD state" не относятся к реальному повседневному трафику и проверка pf номера последовательности позволяет не столкнуться с большинством аномалий. Если вы видите эти сообещения появляющиеся нерегулярно и не замечаете большое число подвисших соединений, вы можете просто их игногрировать. В интернет работает множество реализаций TCP/IP и некоторые из них могут иногда генерировать ошибочные пакеты.

Однако этот класс проблем может быть легко диагностирован по появлению сообщений "BAD state", появляющихся только в подобных случаях.

Создание записей состояний TCP по начальному SYN пакету.

В идеале, записи состояний должны создваться при появлении первого пакета SYN.

Вы можете принудительно включить использование этого правила, пользуясь принципом:

“Использовать опции "flags S/SA" во всех правилах "pass proto tcp keep state"”

Только начальные SYN пакеты (и только они) имеют установленный флаг SYN и сборшенный ACK. Когда применение опции "keep state" привязывается только к начальным SYN пакетам, только эти пакеты будут создавать записи в таблице состояний. Таким образом любая существующая запись в таблице состояний будет произведена от начального SYN пакета.

Причиной создания записей только по начальным пакетам служит расширение протокола TCP под названием "масштабирование окна" (“window scaling”), определённое в RFC1323. Поле заголовка TCP, используещееся для оповещения о размере принятых окон, слишком мало для сегодняшних высокоскоростных линий связи. Современные реализации TCP/IP предпочитают использование больших значений размера окна, чем может уместиться в существующем поле. Масштабирование размера окна означает, что все размеры окон, о которых известно от хоста-получателя, должны быть умножены на определённое значение, заданное получателем, а не взяты сами по себе. Для того, чтобы данная схема заработала, оба хоста должны поддерживать расширение и обозначить друг для друга свою возможность реализации его на этапе установления соединения (“handshake”) используя опции TCP. Эти опции представлены только в начальных пакетах SYN и SYN+ACK. И только если каждый из этих пакетов содержит опцию, взаимосогласование будет успешным и размер окна всех последующих пакетов будет умножаться на коэффициент.

Если бы pf “не знал” об используемом масштабировании окна, бралось бы предоставляемое значение без коэфиициента, и вычисление размеров окна для приемлемых значений номеров последовательности производилось бы неверно. В типовом случае хосты в начале соединения предоставляют малые значения размеров окна и увеличивают их в процессе соединения. Не подозревающий о существовании факторов изменяющих размер окна, pf с некоторого момента начнет блокирование пакетов, потому что будет считать, что один их хостов пытается обойти предоставленный “собеседником” максимальный размер окна. Эффекты от этого могут быть более или менее заметны. Иногда, хосты отреагируют на потерю пакетов переходом в т.н. “loss recovery mode” (“режим повторной передачи”) и будут анонсировать меньший размер окна. После того, как pf повторно передаст отброшенные в первый раз пакеты, размеры окон будут далее возрастать, до точки в которой pf снова начнёт их блокировать. Внешним проявлением может быть временное зависание соединений и низкая производительность. Возможно также полное зависание или сброс соединений по таймауту.

Но pf знает от возможности масштабирования окон и поддерживает такую возможность. Как бы то ни было, предпосылкой для создания записей в таблицу состояний по первым SYN пакетам будет то, что pf может ассоциировать первые два пакета соединения с записью в таблице. А так как полное согласование коэффициентов размера окон имеет место только в этих первых двух пакетах, то нет надёжного метода определить эти коэффициенты после согласования соединения.

В прошлом, масштабирование размеров окна использовалось не так широко, но ситуация быстро меняется. Только недавно в Linux включена эта опция по умолчанию. Если вы испытываете трудности с зависающими соединениями, особенно с некоторыми комбинациями хостов и видите сообщения "BAD state" относящиеся к этим соединениям, проверьте, что вы действительно создаёте записи для таблицы состояний по первым пакетам соединения.

Вы можете определить, использует ли pf опцию масштабирования для соедиения из вывода pfctl:

$ pfctl -vss

kue0 tcp 10.1.2.3:10604 -> 10.2.3.4:80 ESTABLISHED:ESTABLISHED

wscale 0 wscale 1

Если присутствует запись "wscale x" выведенная во второй строчке (даже если x равен нулю), pf зачит знает о том, что соединение использует масштабирование.

Другой простой метод для выявления проблем связанных с масштабированием это временное выключение поддержки масштабирования и потвторное воспроизведение ситуации. В OpenBSD использование масштабирования может управлятся опцией sysctl:

$ sysctl net. inet. tcp. rfc1323

net. inet. tcp. rfc1323=1

$ sysctl - w sysctl net. inet. tcp. rfc1323=0

net. inet. tcp. rfc1323: 1 -> 0

Подобные проблемы появляются когда вы создаёте записи в таблице состояний по пакетам, отличным от начальных SYN и используете опцию "moulate state" либо трансляцию. В обоих случаях трансляция производится в начале соединения. Если первый пакет не транслирован, транчляция последующих обычно обескураживает принимающую сторону и приводит к тому, что посланные ответы блокируются pf с сообщением "BAD state".

Методика тестов

Тестирование производилось на экспериментальном ПК под управлением лицензионной Windows XP с установленным SP1 (тестирования проводились в идеализированных условиях - "операционная система + Firewall" для исключения влияния других программ на чистоту эксперимента). В качестве индикатора успешного доступа к сервисам использовалась утилита APS . В качестве средств внешнего воздействия применялись:

сканер XSpider 6.5 и 7.0
Retina Network Security Scanner 4.9
несколько сканеров моей разработки.

Кроме того, применялся сниффер CommView 4.1 (в качестве средства наблюдения за сетевым трафиком и в качестве утилиты для генерации и отправки пакетов с различными нарушениями в структуре). Применялись т.н. флудеры (flooder) распространенных типов, утилиты для имитации троянских программ.

На испытательном ПК в качестве средств доступа к сети и Интернет применялся IE 6, Outlook Express 6, TheBat 1.60, MSN Messanger 6.1. Кроме них в тесте участвовали имитаторы троянских программ и реальные троянские / Backdoor программы из моей коллекции (в частности Backdoor.Antilam, Backdoor.AutoSpy, Backdoor.Death, Backdoor.SubSeven, Backdoor.Netbus, Backdoor.BO2K), сетевые / почтовые вирусы (I-Worm.Badtrans, I-Worm.NetSky, I-Worm.Sircam, I-Worm.Mydoom, I-Worm.MSBlast), загрузчики троянских программ TrojanDownloader (в частности TrojanDownloader.IstBar) и шпионские SpyWare компоненты. Главной задачей тестов была попытка взглянуть на Firewall глазами пользователя, отметить его сильные и слабые с моей точки зрения стороны.

Kerio Technologies WinRoute Pro v4.2.5

Инсталляция и деинсталляция:
Проходит без проблем.
Установка с настройками "по умолчанию", без правил - действует только NAT. Работа в сети - без проблем, результаты сканирования - APS не показывает состояние тревоги, сканер считает, что все порты закрыты. Сам Winroute не выдает сигналов тревоги и никак визуально не идентифицирует факт сканирования.

Outpost Firewall Pro 2.1 Build 303.4009 (314)

Инсталляция и деинсталляция:
Установка под XP проходит без проблем, при запуске включается режим обучения.

ZoneLabs ZoneAlarm Pro with Web Filtering 4.5.594.000 - Personal Firewall

Инсталляция и деинсталляция:
В ходе установки подвесил XP в ходе попытки запуститься после инсталляции. После перезагрузки все заработало нормально.

AtGuard 3.22>

Инсталляция и деинсталляция:
Инталляция и деинсталляция особых проблем не вызывает

Достоинства:

Небольшой по размеру Firewall, имеет интересное решение с точки зрения интерфейса - он выполнен в виде панели, размещаемой вверху экрана

Недостатки и особенности:

В режиме обучения уязвим - с момента вывода запроса на создание правила до его создания пропускает пакеты в обоих направлениях
Интерфейс немного поглючивает при перерисовке окон

Общая оценка:
Простой Firewall, однако вполне функциональный

Kerio Personal Firewall 4

Инсталляция и деинсталляция:
Установка проходит без проблем, удаление "чистое" - проблем после деинсталляции не замечено.

Norton Internet Security 2004 (NIS)

Инсталляция и деинсталляция: Установка не вызывает проблем, но из всех проанализированных инсталлятор самый тяжеловесный.

Internet Connection Firewall, ICF - встроенный брандмауэр Windows XP

Инсталляция и деинсталляция: Установка не требуется, является штатным средством XP. Включение производится в настройках сетевого адаптера. По умолчанию ICF работает в режиме максимальной безопасности и (это результат моего наблюдения) принцип его работы таков - запросы приложений выпускаются наружу, а снаружи принимаются только пакеты, пришедшие в ответ на мои запросы (соответствие запрос-ответ явно ведется в виде динамической таблицы). Таким образом, при сканировании портов на компьютере с включенным ICF нет ни одного открытого порта (это логично - пакеты сканера портов не будут пропущены, т.к. их никто не запрашивал). Аналогично дело обстоит с различного рода "нюками", основанными на отправке нестандартных пакетов

Internet Connection Firewall, ICF - встроенный брандмауэр Windows XP SP2

Инсталляция и деинсталляция: Установка не требуется, является штатным средством XP (входит в пакет обновлений SP2 для XP). Включение производится в настройках сетевого адаптера. Следует заметить, что при установке SP2 или при установке XP с интегрированным SP2 кроме Firewall в системе появляется центр обеспечения безопасности, который может показывать настройки ICF

Sygate Personal Firewall Pro 5.5 build 2525

Инсталляция и деинсталляция:

ISS BlackIce 3.6.cci

Инсталляция и деинсталляция: Установка программы и ее деинсталляция происходит без проблем, но в ходе инсталляции возникает ошибка в библиотеке ikernel. Эта-же ошибка возникла и при деинсталляции. Возникнование данной ошибки не влияет на процесс установки и удаления программы. Инсталлятор не потребовал перезагрузку системы, что для Firewall необычно

Visnetic Firewall 2.2

Инсталляция и деинсталляция: Установка программы и ее деинсталляция происходит без проблем. После инсталляции требуется перезагрузка.

Look n stop personal firewall 2.05

Инсталляция и деинсталляция: Установка программы и ее деинсталляция происходит без проблем. После инсталляции требуется перезагрузка. Для работы устанавливает свой драйвер.

Kaspersky AntiHacker 1.5

Tiny Personal Firewall Pro 6.0

Инсталляция и деинсталляция:
Установка программы и ее деинсталляция происходит без проблем. После инсталляции требуется перезагрузка.

McAfee Personal Firewall Plus 6.0 Build 6014

Инсталляция и деинсталляция:
Установка программы и ее деинсталляция происходит без проблем. После инсталляции требуется перезагрузка.

R-Firewall 1.0 Build 43

Инсталляция и деинсталляция:
Установка программы и ее деинсталляция происходит без проблем. Размер дистрибутива небольшой (3.8 МБ), можно настроить состав продукта. Работа достаточно стабильная, на эталонном ПК явных сбоев и зависаний не замечено

Общие выводы и заключение

Итак, подведем итоги тестов. По сути, тесты подтвердили мои теоретические представления о состоянии проблемы:

Firewall нужно настраивать . Все тестируемые Firewall неплохо работали, но только после настройки (обучения, создания настроек вручную - не важно). Эксплуатация ненастроенного Firewall может нанести больше вреда, чем пользы (он пропустит опасные пакеты и наоборот, будет мешать полезным программам);
После настройки Firewall и IDS нужно тестировать - это тоже достаточно очевидный вывод, но тем не менее он важен. Первый шаг к созданию тестера я сделал - это утилита APS . Осталось еще два - имитатор троянской програмы (т.е. утилита, которая будет выполнять безопасные для пользователя попытки "сломать" Firewall изнутри (естественно, атаки будут описаны базой данных и будут проводиться по команде пользователя под его управлением), что позволит наблюдать за реакцией Firewall и IDS) и утилита для экспресс-сканирования портов и проведения базовых атак (по сути APS с точностью до наоборот - база портов у них может быть общая). Разработкой этих утилит я уже занимаюсь - их наличие в арсенале пользователя позволит произвести некий "инструментальный контроль".
Персональный Firewall уязвим перед вредоносными программами, работающими из контекста полезных. Вывод - как минимум долой разные "левые" панели и прочие BHO из браузера и электронной почты!! Перед установкой любого плагина, панели, утилиты расширения и т.п. нужно десять раз подумать о их необходимости, т.к. они не являются отдельными процессами операционной системы и работают из контекста родительской программы . Троянская программа легко детектируется персональным Firewall - он "видит", что некоторый процесс (скажем, bo2k.exe) пытается начать прослушивание порта xxxxx или обмен с неким хостом - выдается запрос о допусимости, пользователь начинает разбираться, что же это за "bo2k.exe" и Backdoor оказывается пойман. А вот если бы троянская программа работала из контекста браузера, то на обращение браузера в Интернет почти наверняка никто не обратит внимание. Такие троянские программы существуют, ближайший пример - TrojanDownloader.IstBar - он устанавливается именно как панель IE (в процессах его естественно нет, в списке автозапуска - тоже);
Многие персональные Firewall видны как процессы операционной системы и могут быть остановлены вирусом. Вывод - за работой Firewall нужно следить и его внезапное завершение может служить сигналом о проникновении на ПК вируса;
Некоторые Firewall (например Kerio) допускают дистанционное управление - функцию дистанционного управления необходимо или отключить, или запаролить.

Firewall Testing is the only way to accurately confirm whether the firewall is actually working as expected. Complicated firewall rules, poor management interfaces and other factors often make it difficult to determine the status of a firewall. By using an it is possible to accurately determine the firewall status.

This type of firewall test attempts to make connections to external facing services from the same perspective as an attacker . An unprotected open service (listening port) can be a major security weakness in poor firewall or router configurations.

Enter an IP address in the form below to perform a quick online firewall test . The port scan will test 10 of the most common TCP services (ports), with results showing a port as open , closed or filtered .

This firewall test is a high level overview that can reveal the status of a system firewall based on the port responses. See the Nmap Tutorial for more detail on interpreting the results.

Ensure complete coverage when testing a firewall by scanning all 65535 ports. Run software yourself or simply perform a comprehensive firewall test using our hosted Online Nmap Port Scanner .

Why You Need an External Firewall Test

To understand how vulnerable your systems are to external attackers, you need to understand what they look like on the network from an external or Internet facing perspective. A port scan conducted from outside a network perimeter will map and identify vulnerable systems.

Technical operations staff need to know what their network perimeter looks like from the outside. The perimeter may be a single IP gateway, a hosted Internet server or a whole Class B network; it does not matter - you need to understand what services Internet based threats can see and what they are able to access.

If you are a systems administrator or a security analyst for an organisation having access to an external port scanner will provide a number of benefits. The most important being that you should know the services listening on your perimeter . Testing should be performed at least monthly and ideally more often, to monitor for changes to the perimeter.

Home Router Firewall

For many users a home router is the firewall device that they will have to manage. In this case the most common configuration is for the SOHO device to be performing NAT (network address translation). In a NAT configuration the internal network has a number of devices on private IP address ranges (192.168.1.x) and they communicate with the Internet through the SOHO router. The router has a single public IP address assigned by the Internet provider or ISP. The translation of internal to public IP address is the NAT process.

Home routers should be port scanned to check for two important considerations:

1. The device itself may have listening services for management such as HTTP (tcp port 80) or Telnet (tcp port 23). These are normally only accessible from the Internal network, but if they are listening on the Public Internet side then anyone can access them and if the password is default or weak this could easily be accessed. If someone has access to your router, they can attack any devices on the Internal network.

2. Port Forwarding is another important consideration, where the external interface forwards traffic to an Internal address so that is accessible from the Internet. If you are hosting services on your Internal network and you want these to be accessible, you may setup a port forwarding rule on the SOHO router. Port scanning the external IP address can help troubleshoot port forwards and ensure that there are no services being forwarded that should not be.

Firewall Administration

Further more identification of the actual operating system is also possible, either from the service identification or through more low level analysis of the packets coming back from the host.

System and network administrators will also utilize to map the external network of a host or organisation. Networks change over time and documentation is not always kept current, so a quick port scan of the services listening on a network will help a system administrator to understand the layout of the network.

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

Многие из этих пользователей берут с собой ноутбуки в общественные места, например, в кафе, и подключаются к Интернету с использованием беспроводной Wi-Fi сети. Разумно при этом ожидать, что при запросе фаервола и выборе сети как общественная, компьютер должен быть защищен от вторжений со стороны других участников открытой сети.

Бизнес-пользователи, которые используют ноутбук в качестве единственного рабочего компьютера, могут оказаться в такой же ситуации, при этом их машины чаще всего настроены на контроль через удаленный рабочий стол (Microsoft Remote Desktop).

Цель этого теста определить, как наиболее популярные сторонние фаерволы (брандмауэры) – отдельные и в составе пакетов Internet Security – на самом деле обеспечивают основной контроль входящего доступа для пользователей ноутбуков, которые переключаются между домашней/рабочей и общественной сетью.

Пожалуйста, обратите внимание, что объем теста, очевидно, очень ограничен, и поэтому хороший результат в нем, не означает, что продукт обеспечивает полную безопасность сети.

Тестирование проводилось в январе 2014 года по заказу журнала CHIP Online (Германия). Используемые версии фаерволов были доступны по состоянию на 13 января 2014 года.

Процедура тестирования фаерволов

Тестовый ПК подключен к Интернету через беспроводную локальную сеть (WLAN), используя соединение сети, которая определяется как Частная в Центре управления сетями и общим доступом Windows (WNSC).

Тестовая версия каждого продукта, доступного по состоянию на 13 января 2014 года, устанавливается с настройками по умолчанию, и тестовый компьютер перезагружается. Если сам продукт предлагает пользователю определить текущий тип сети, как Частная/Доверенная – будет выбран данный вариант. Если продукт имеет функцию обновления, то оно выполняется. Проверяется, чтобы продукт был зарегистрирован в Центре поддержки Windows в качестве системного брандмауэра, и сам продукт показывал, что он работает должным образом. С помощью второго ПК проверяется подключение в существующей частной сети следующим образом:

Ping hostname -4
Ping hostname -6
Ping IPv4 address
Ping IPv6 address
File share hostname
File share IPv4 address
Remote Desktop (RDP) hostname
Remote Desktop (RDP) IPv4 address
Remote Desktop (RDP) IPv6 address

Проверяется, чтобы все эти формы удаленного доступа работали для обеспечения полной функциональности тестового ПК в частной сети и его максимального контроля. После этого выключается компьютер и роутер, к которому он был подключен, и снова запускается ПК. Затем он подключается к другой WLAN-сети, которая определяется как Общедоступная (Общественная) в WNSC, используя диалоговое окно Брандмауэра Windows.

Если фаервол показывает свой запрос на определение типа сети, устанавливается значение «Общественная» или «Недоверенная». Больше не делается никаких изменений в настройке продукта.

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

Раздел обновляется ежедневно. Всегда свежие версии самых лучших бесплатных программ для повседневного использования в разделе Необходимые программы . Там практически все, что требуется для повседневной работы. Начните постепенно отказываться от пиратских версий в пользу более удобных и функциональных бесплатных аналогов. Если Вы все еще не пользуетесь нашим чатом , весьма советуем с ним познакомиться. Там Вы найдете много новых друзей. Кроме того, это наиболее быстрый и действенный способ связаться с администраторами проекта. Продолжает работать раздел Обновления антивирусов - всегда актуальные бесплатные обновления для Dr Web и NOD. Не успели что-то прочитать? Полное содержание бегущей строки можно найти по этой ссылке .

Бесплатный фаервол Comodo. Тестирование, выводы

Comodo Firewall в работе

После установки и настройки Comodo спрятался в трее и начал доставать меня своими расспросами. В первый день я поигрался со всеми режимами фаервола и проактивной защиты и в конце концов заставил его замолчать. Каких-то тормозов после его появления в своей системе обнаружено не было. И вообще, работать с фаерволом от Comodo было достаточно легко и удобно. Интерфейс основного окна весьма прост и информативен:

Но вот к навигации по настройкам фаервола и проактивной защиты пришлось привыкать - не всегда удаётся быстро найти нужный пункт. Думаю, со временем это пройдёт.

Спустя несколько дней после установки Comodo Firewall я решил его немного потестировать.

Тест №1. Онлайн-тестирование

При нажатии на кнопку "Test" программа пытается установить связь с сервером сайта .

Поскольку эту утилиту Comodo Firewall ещё не знает, то при первой её попытке вырваться в интернет последовала незамедлительная реакция со стороны проактивной защиты и фаервола:

В обоих случаях я нажал заблокировать и получил подтверждение об успешном прохождении теста:

Затем я переименовал файл FireWallTest.exe в opera.exe и подменил им стандартный файл Оперы. Таким образом, я попытался обмануть Comodo Firewall, который уже хорошо знает этот браузер и постоянно и автоматически выпускает его в интернет. На запуск «фальшивой» Оперы из Тотала Comodo отреагировал следующим образом:

Получив моё разрешение на одноразовый запуск, фаервол предупредил меня о попытке выхода Оперы в интернет:

Получается, что любое приложение, для которого уже существуют правила, в случае подмены исполняемого файла без моего ведома выйти в интернет не сможет. Вроде всё хорошо, но вот какая штука: цвет верхней части окна с предупреждением зависит от серьёзности ситуации. Если Comodo оценивает событие как критичное, то цвет будет красным, если событие менее опасное – жёлтым. В моём случае Comodo посчитал смоделированную ситуацию не особо опасной и зажёг «жёлтый». К тому же вместо формулировки «исполняемый файл opera.exe не опознан» я бы предпочёл увидеть что «произошло изменение параметров файла opera.exe ”. Так предупреждают в подобных ситуациях комбайны от Касперского и Eset, например. Причём, пользователь видит окно тревоги с использованием красного цвета, что сразу заставляет обратить внимание на ситуацию. А предупреждение от Comodo может быть просто проигнорировано пользователем из-за недостаточного акцента на происходящее событие.

Подмена файла Оперы было лишь частью моего коварного плана. Следующей жертвой стал Internet Explorer 6 , который интегрирован в операционную систему, а, значит, iexplore.exe можно считать полноправным системным файлом. Каково же было моё удивление, когда под полное молчание Comodo я увидел окно о провале теста:

Видимо, создано лишнее правило, решил я и полез в политики фаервола и проактивной защиты. Покопавшись там минут 15, я принял единственно правильное решение - переустановить Comodo. Сказано - сделано. Оставив режимы работы по умолчанию, я повторил опыт с подменой iexplore.exe . На запуск из Тотала проактивная защита сработала, как и в случае с Оперой:

Здесь придётся сделать небольшое лирическое отступление. Дело в том, что при подмене исполняемого файла IE система в течение 4-8 секунд восстанавливает оригинальный iexplore.exe . В связи с этим результаты моего теста зависели от того, успевает подменённый файл постучаться в интернет или нет.

В случае, когда я успеваю совершить все манипуляции до восстановления explore.exe, происходит следующее. Получив моё разрешение на одноразовый запуск explore.exe , Тотал запускает утилиту FireWallTest, жму «Test”, проактивная защита Defens+ выдает предупреждение:

Если разрешаем (в качестве эксперимента) - отрабатывает фаервол:

Успеваем нажать «Блокировать» - тест пройден, утилита в интернет не проскочила. А вот если iexplore.exe восстановлен до того, как нажали кнопку блокировки - от Вашего выбора уже ничего не зависит - утилита автоматически получает доступ интернет в момент восстановления оригинального файла.

То же самое относится и к работе проактивной защиты: если не успел скомандовать блокировать до восстановления explore.exe - утилита автоматом получает доступ в интернет.

Вдоволь наигравшись с фальшивым IE, я вспомнил о самом первом провале теста, когда Comodo промолчал и выпустил «левый» файл в интернет. Переустановив Comodo, я перевёл Defense+ и фаервол в режим обучения и запустил IE. После этого вернул режимы, выставленные по умолчанию, и повторил тест. Comodo его снова молча провалил...

Тест №3. Дуэль

Находясь под впечатлением от результатов предыдущего теста, я искал дополнительные возможности протестировать Comodo и, наконец, нашёл утилиту AWFT.

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

Утилита является условно-бесплатной, ограничение - 10 запусков. В верхней части окна программы расположены кнопки, запускающие соответствующие тесты, внизу указан сайт, куда будет прорываться AWFT, и результат дуэли между фаерволом и утилитой. Кнопка Reset Points служит для сброса набранных очков.

На всякий случай я решил поменять адрес сайта на свой.

Тестирование происходило при включенном Comodo Firewall и Defense+, запущенной Оперой и отключенным монитором Авиры.

В первом тесте использован приём с загрузкой скрытой копии браузера и пропатчиванием памяти перед его запуском.

При нажатии кнопки теста выскочило окно с ошибкой:

После закрытия этого окна Сomodo отреагировал на тест окном запроса, при нажатии кнопки «Блокировать» AWFT, немного призадумавшись, отдала первое очко фаерволу.

По утверждению разработчиков утилиты тест №2 - это старый и давно известный трюк. Comodo снова реагирует окном запроса и снова получает очко.

В тесте №3 также используется старый трюк. Comodo просто молча его блокирует, видимо, трюк действительно известный.

Тест №4 аналогичен первому тесту с запуском скрытой копии браузера и пропатчиванием памяти перед его запуском. Фаервол не выдал никаких предостережений, но через небольшую паузу заработал очередное очко.

Во время пятого и шестого теста необходимо переключиться в браузер и немного посерфинговать (я просто обновлял загруженную в браузере страницу).

В тесте №5 утилита выполняет эвристический поиск установленного на компьютере (или в сети) разрешённого программного обеспечения, имеющего доступ к интернет через порт 80, затем запускает копию разрешённой программы и перед самым запуском патчит память, занимаемую этой программой (т.е., AWFT запускает и саму себя в памяти разрешённой программы). Comodo молча справился с тестом и получил за него целых 3 очка.

Тест №6 аналогичен предыдущему пятому тесту. Используется тот же приём с эвристическим поиском установленного софта, имеющего право выходить наружу через порт 80. Только способ взлома сейчас изменён - используется пользовательский запрос. Попутно с этим AWFT пытается прилепить к браузеру левый скрытный тулбар. При открытой Опере у меня выскочило такое окно:

В момент подтверждения мною этого пользовательского запроса Comodo выдал свой запрос, утилита была снова заблокирована, а фаервол получил 3 очка себе в зачёт.

Итог дуэли - 10:0 в пользу Comodo. Повторив тесты с открытым Internet Explorer, я получил те же результаты.

Заключение

Несмотря на некоторый неприятный осадок в душе, оставшийся после тестирования фаервола, я всё же рекомендую Comodo Internet Security для домашнего использования, но только в качестве фаервола. И не слушайте тех умников, которые советуют отключать проактивную защиту, ни в коем случае! Только с использованием Defense+ этот фаервол действительно обеспечивает безопасность Вашего компьютера. А вот что действительно не следует использовать, так это антивирус от Comodo. Мало того, что он прилично пропускает, у Вас возникнут проблемы с его обновлением - уж очень громоздкие базы у него. К тому же он прилично влияет на быстродействие системы. У меня просто замечательно работали в паре Comodo Firewall и Avira Antivir Personal.

Тормозов и глюков в системе во время работы фаервола мною обнаружено не было. Свои размышления о результатах моего тестирования я пока оставлю при себе, хочется послушать Ваши коментарии.

Во время написания заключительной части этой статьи я наткнулся на результаты недавнего тестирования фаерволов лабораторией Matousec. Comodo Internet Security оказался единственным фаерволом со 100-процентным результатом (см. форум по фаерволам). Что же, я свой выбор сделал... А Вы?

плюсы (явные) :
бесплатное распространение,
наличие собственной базы данных программ;
наличие проактивной защиты (Defense+);
простота установки и начальной настройки;
очень информативное и удобное окно со сводкой;

плюсы (сомнительные) :
наличие нескольких режимов работы;

минусы (явные) :
раздражающий режим инсталляции;
подмена исполняемого файла не определяется проактивной защитой как критическое событие;

минусы (сомнительные) :
откровенно неудачный антивирус.