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

# Блокируем все входящие IP/TCP/UDP-соединения на внешнем интерфейсе

block in log on fxp1 proto ip from any to any

block in log on fxp1 proto tcp from any to any

block in log on fxp1 proto udp from any to any

Обратим внимание, что все пакеты (запрещенные нами входящие соединения) не будут отбрасываться сразу, а будут передаваться дальше на проверку (отсутствует ключевое слово quick). Если соответствующего разрешения не будет найдено, пакет будет блокирован в соответствии с этими правилами. А «incident will be reported»[9], как говорится. Сразу за этими строчками мы начнем добавлять правила в зависимости от уже продуманной к этому моменту (хорошо бы даже четко описанной «на бумаге») политики нашей «огненной стены». Для экономии времени на обработке файла с правилами условимся прекращать дальнейшее расcмотрение правил[10] при подпадании пакета под заданные условия. Заметим, что каждый сервис потребует как минимум два правила: для входящих и для исходящих пакетов на каждый используемый сервисом порт. Также, памятуя о специфике каждого сервиса, будем задавать управляющие флаги, не забывая обращаться к документации по протоколам и к IPFilter Based Firewalls HOWTO[11].

FTP

Предположим, у вас имеется FTP-сервер, к которому вы хотите открыть публичный доступ. Как известно, в работе по протоколу FTP используется два порта – для передачи команд и, собственно, для передачи данных. В нотации стека протоколов TCP/IP для протокола FTP используется протокол транспортного уровня TCP. Соответственно для этого сервиса правила будут выглядеть следующим образом:

pass out quick on fxp1 log proto tcp/udp from 213.27.10.xx/32 to any keep state

pass in quick on fxp1 log proto tcp from any to 213.27.10.xx/32 port = 21 flags S keep state

Директива flag означает, что фильтр будет отслеживать флаги в каждом пакете и, если нужно, сравнивать с заданными флагами в правилах IPFilter. В данном случае мы будем отслеживать пакеты с установленным SYN – этот флаг присутствует в пакетах при инициализации TCP-соединения.

Здесь же мы впервые используем управляющий флаг keep state. Остановимся на нем поподробнее. Сами по себе пакетные фильтры не умеют различать начало, середину или конец любой TCP/UDP/ICMP, а ориентируются по установленному в пришедшем пакете FIN-флагу. Администратору же в данном случае остается только надеяться на то, что такие пакеты не будут FIN-сканированием. В IPFilter применена методика keeping state[12] для распознавания установленных сессий и отличия их от действий злоумышленников. Разработчики исходили из того, что раз любая TCP/IP-сессия проходит в три этапа: старт (установка соединения), соединение и разрыв соединения (все это может уместиться и в одном-единственном пакете) – при этом, в общем случае (исключая злонамеренные действия), должны иметь место именно все три стадии. Если старт сессии разрешен правилами фильтра, то понятно, что последующие пакеты этой сессии (subsequent-пакеты) и ее стоп-пакет тоже должны быть пропущены. Так же, как если запрещено начало сессии, то и последующие пакеты будут автоматически блокированы. Такой подход также позволяет избежать IP stack overflow – переполнения IP-стека. Более подробное описание можно найти в IPFilter Based Firewalls HOWTO, где помимо описания работы IPFilter даны общие рекомендации по построению межсетевого экрана.