Время от времени таблицу <BRUTEFORCERS> нужно очищать. Кто-то из тех, кто плохо себя вел (подбирая пароли к нашему серверу) сидит на динамическом IP, а кто-то одумался и больше так не будет.

Очищаем таблицу раз в час, по крону :

59 * * * * root/sbin/pfctl -t BRUTEFORCERS -T expire 86400

эта команда уберет записи, старшие чем 1 сутки (86400 секунд)

Обратите внимание, правила pass (in|out) для одного интерфейса указываются всего 1 раз. Например,

pass in on $inf_if from $Vasya to any pass out on $ext_if from $Vasya to any

а не

pass in on $inf_if from $Vasya to any pass out on $inf_if from $Vasya to any pass in on $ext_if from $Vasya to any pass out on $ext_if from $Vasya to any

Неоднократно слышал утверждение о том, что "мы не можем управлять тем трафиком, который пришел к нам. Что пришло, то пришло". Это утверждение НЕ справедливо с точки зрения очередей ALTQ. В нашем примере, я привязываю очереди именно к IN трафику, например :

pass in on $int_if proto tcp from $buh to any port nntp \ queue ( qbuh, qack ) modulate state

хотя очередь у нас одна и поднята она на

altq on $ext_if cbq bandwidth 970Kb queue .....

внешнем интерфейсе! Так можно делать, когда поднят NAT. В этом случае PF сам определит, что такие-то пакеты , выходят через интерфейс $ext_if соответствуют

pass in .... queue ( qbuh, qack )....

и их нужно шейпить.

in пишется когда инициатором соединения являемся НЕ мы (т.е. НЕ шлюз);
out пишется когда соединение происходит по нашей инициативе (или по инициативе сети, которую мы представляем);

Ну и напоследок несколько рецептов :

1) При обновлении правил, чтобы каждый раз не набирать :
сначала для проверки правил

pfctl -nf <путь к конфигу>

а потом для их применения

pfctl -f <путь к конфигу>

Воспользуйтесь вот этим :

Скрипт sh (скачать можно тут), который обновляет правила фаервола, если в них нет ошибок

#!/bin/sh pfctl -nf /usr/local/etc/pf-casual-rules.cfg if test $? = 0; then pfctl -f /usr/local/etc/pf-casual-rules.cfg echo "rules reloaded" else echo "there are some mistakes" fi

только путь к Вашему конфигу не забудьте поменять.

2) Бывает так что сервер давно сдан, но просят порт там пробросить или еще что-то открыть/закрыть.
Это нужно на тот, случай, если Вы доспустили ошибку (но не синтаксическую, а смысловую), заблокировался доступ по ssh и кататься в другой город Вам не с руки.
Если мне нужно менять правила на сильно удаленной машине поступаю следующим образом :
2.1) завожу временный файл с правилами, над которыми буду работать, допустим /usr/local/etc/pf-temp-rules.cfg
2.2) пишу к нему скрипт аналогичный скрипту из пункта 1)
2.3) ставлю в cron перезагрузку через 10 минут
делаю с помощью

#shutdown -r HH:MM

2.4) выполняю скрипт обновления временных правил и если что-то пойдет не так как хотелось бы, то через 10 минут комп перезагрузится и сработают старые правила. Если же с правилами все ОК — убиваю shutdown вручную.

3) Всегда записывайте правило state там где оно должно быть.
Т.е. если хотите, чтобы, например UDP пакеты создавали состояние так и пишите :

pass .... proto udp... >>> keep state <<<

если наоборот, состояния не нужны пишите no state

pass .... proto udp... >>> no state <<<

Это связано с тем, что в старых версиях PF

keep state

НЕ дописывается автоматически ко всем правилам фльтрации. Долго думал почему же не работает банальнейшее правило (конфиг состоял из одной строчки)

pass all

Пакеты уходили, но не возращались....
Потом только догадался глянуть версию FreeBSD, она оказалась 6.3 . После записи

pass all keep state

естественно все заработало. Не попадитесь также.

4) Если есть сомнения в работе очередей — можно посмотреть на их работу в реальном времени командой

pfctl -vvsq

единичный "снимок" очередей получается с помощью :

pfctl -vsq

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

pfctl -vsr

или

pfctl -vvsr

5) Виртуальные интерфейсы и PF.
Может случиться так, что в момент загрузки правил PF некоторые (например, tun*, ng*) интерфейсы не имеют адреса, это вызовет ошибку и правила не будут загружены. Их следует обновлять в момент когда интерфейс будет иметь адрес либо записывать в конфиге не

ext_if="tun0"

а непосредственно IP адрес, если он заранее известен

ext_if="88.77.66.55"

Для ppp у меня работает скрипт :
ppp привередлив к пробелам в этих конфигах, поэтому пишите именно так.
ppp.linkup

MYADDR: ! sh -c "/sbin/pfctl -f /etc/pf.basic.007"

ppp.linkdown

MYADDR: ! sh -c "/sbin/pfctl -F all"

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

6) Отладка правил.
Лично я отлаживаю правила следующим образом :

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

block all pass in on $int_if from ..... pass in on $int_if from ..... # заглушка pass out on $ext_if from any to any

после того, как разобрался с $int_if можно перейти и к $ext_if.

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

pass in on $int_if proto udp from $admin to any port domain \ queue qdns keep state

пишем

pass in on $int_if from $admin to any keep state

а дальше добавляем порт, протокол и т.д.

Рецепт от Peter N.M. Hansteen из "THE BOOK OF PF" :
"Перед тем как окунуться с головой в Ваш набор правил, Вы можете легко определить а PF ли является источником проблем? Запрещение PF, с помощью команды pfctl -d , чтобы увидеть исчезнет ли проблема может оградить Вас от больших неприятностей." (стр.131, [2])


Литература :