Пару слов о конфигурировании транспарентного прокси :


int_if="re0" # внутренний интерфейс, имеет адрес 192.168.0.133
ext_if="tun0" # внешний интерфейс, \
динамический белый адрес (подключение по pppoe)
dns_serv="153.53.53.53" # адрес нашего DNS сервера
proxy_if="lo0" # интерфейс, на котором слушает прокси
proxy_port="8080" # порт прокси
boss="192.168.0.168" # IP адрес компьютера босса
buh="192.168.0.100" # IP адрес компьютера бухгалтера
admin="192.168.0.25" # IP адрес компьютера администратора
WinPeak="192.168.0.60" # IP адрес компьютера менеджера
allowed_icmp_types="{ echoreq, unreach }" # разрешенные типы icmp сообщений.
# Остались неизменными с прошлой статьи. Всякие icmp-редиректы ффтопку.
#--
# Cписок немаршрутизируемых адресов, с которых к нам
# будут долбиться на внешний интерфейс, а мы их будем заботливо писать в лог.
non_route_nets_inet="{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, \
10.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, 0.0.0.0/8, 240.0.0.0/4 }" 

Запись интерфейсов в виде

int_if="re0"

и

ext_if="tun0"

имеет значительное преимущество перед записью непосредственно IP адресов, как минимум в двух случаях :
{a} выдается динамический адрес
{b} есть необходимость получить маску, установленную на интерфейсе.

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

$ext_if

в правила подставиться IP адрес, динамически выданный интерфейсу tun0.

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

$int_if:network

Хотелось бы отметить, что физическому внешнему интерфейсу re1 в целях безопасности вообще не назначено IP адреса.

Следующая секция  
2) таблицы


table <BRUTEFORCERS> persist

Таблицы в PF реализуют динамические списки значений. У нас всего одна таблица, в этот список попадают IP адреса тех, кто превысил лимит подключений в единицу времени к сервису ssh.

3) Опции



# тем, кто лезет туда куда не нужно вежливо сообщаем что нельзя set block-policy return set skip on lo0 # не проверяем на lo0 # изменяем время для состояния установленного tcp соединения, # которое по-умолчанию черезчур большое (24часа) set timeout { frag 10, tcp.established 3600 } # перед тем, как отправить фрагментированный пакет дальше # сначала дожидаемся всех его частей scrub in all

Если Вас досят — есть смысл поставить вместо "return"


set block-policy drop

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

4) Трафик-шейпинг или очереди



# реальная полоса 1Мбит, а здесь нужно ставить на несколько % меньше # ЭТО *ОЧЕНЬ* ВАЖНО! Иначе шейпинг не будет работать!! altq on $ext_if cbq bandwidth 970Kb queue \ { qboss, qbuh, qadmin, qWinPeak, qssh, qdns, qntp, qack } queue qboss bandwidth 38% priority 2 cbq ( borrow ) queue qbuh bandwidth 18% priority 2 cbq ( borrow ) queue qadmin bandwidth 15% priority 2 cbq ( borrow ) queue qWinPeak bandwidth 12% priority 3 cbq ( default borrow ) queue qssh bandwidth 8% priority 4 cbq ( borrow ) queue qdns bandwidth 2% priority 5 cbq ( borrow ) queue qntp bandwidth 2% priority 7 cbq ( borrow ) queue qack bandwidth 5% priority 6 cbq ( borrow )

Сколько % нужно минусовать от реальной полосы — зависит от канала. На асимметричных каналах (например, ADSL) рекомендуются значения до 10% меньше, чем реальная полоса. Лично у меня в локальной сети работало и с 2% .
Боссу даем 38% ширины канала, бухгалтеру 18% и себе 15%. Приоритеты траффика у нас троих одинаковые (priority 2), когда есть свободная полоса, разрешаем занимать ее (borrow).
   Чем больше priority тем меньше время, которое пакеты будут пребывать в очереди.
При использовании очередей cbq максимальный priority, который можно поставить равен 7. Если не указывать priority, то по умолчанию она принимается равной 1.
   Трафик к удаленному рабочему столу компьютера WinPeak имеет бОльший приоритет (priority 3). Кроме того, здесь я поставил метку default, согласно синтаксису очередей cbq (одна такая должна быть в любом случае).
ssh траффик имеет еще больший приоритет (priority 4) и гарантированную ширину канала 8%.
dns запросы идут нечасто, так что получают (priority 5) и ширину в 2%.
   Запросы синхронизации времени (NTP) пускаем по очереди с максимально возможным в очередях cbq приоритетом, ширина канала 2%.
   И последнее что хотелось бы отметить, это легковесные ACKnowledgement пакеты (еще назыаются квитанциями о получении), которые отправляются получателем для подтверждении принятых пакетов. Очень важно чтобы эти пакеты не застревали в очереди, потому что у отправителя может сработать тайм-аут и он повторно отправит пакеты, на которые не получил подтверждений о получении; priority 6 и ширина канала 5% (т.к. по этой категории пойдут пакеты от ВСЕХ пользователей и сервисов нашей сети).

5) NAT



# NAT всех разрешенных портов, кроме www nat on $ext_if from $int_if:network to \ any port { ntp, nntp, domain } -> $ext_if # www завернем на прокси rdr on $int_if proto tcp from $int_if:network to any port www \ -> $proxy_if port $proxy_port # пробросим порт RDP внутрь нашей сети, на комп WinPeak (комп менеджера) rdr on $ext_if proto tcp from any to $ext_if port rdp -> $WinPeak port rdp

# Единственное на чем хотелось бы заострить Ваше внимание
# - это логичность следования секций.
# Правила NAT и rdr срабатывают до правил фильтрации,
# поэтому они и распологаются выше по конфигу.
# И именно поэтому трафик, который пойдет от клиента по 80
# порту мы пропускаем по правилу
# pass in on $int_if  proto tcp from { $boss, $buh, $admin } to \
# $proxy_if port >>>> $proxy_port <<<< порт 8080!
# потому что когда будет обрабатываться это правило
# rdr уже сработает и подменит 80й порт 8080м
# (а также подменит IP адрес получателя)

6) Правила фильтрации



# хорошее начало любых правил :-P # Правда! (см. [7]) block all # блокируем всяких нехороших людей # стандартный антиспуфинг средствами pf antispoof log quick for { lo0, $int_if, $ext_if } # те, кто ломится на внешний интерфейс с левыми адресами block drop in log quick on $ext_if from $non_route_nets_inet to any # умников, которые лезут на внутренний интерфейс с любых сетей # отличных от 192.168.0.0/24 block drop in log quick on $int_if from !$int_if:network to any # пишем тех, кто ломится к нам на 25 порт. Облегчает работу по # определению зараженных компов в локальной сети block drop in log quick on { $int_if, $ext_if } proto tcp \ from any to any port smtp # агаааааа, а эти подбирали пароли к ssh block drop log quick from <BRUTEFORCERS> # всех пишем в лог # у меня набегает # 10 Мб логов за 5 дней (!), на сервере которому пытаются пролезть на порт smtp # и видимо подDoSивают. Главное не забыть настроить # ротацию логов man newsyslog.conf # ssh для локальных юзеров pass in on $int_if proto tcp from $int_if:network to $int_if port ssh \ queue ( qssh, qack ) synproxy state ( max-src-conn-rate 1/60, \ overload <BRUTEFORCERS> flush global ) # и для пользователей с инета pass in on $ext_if proto tcp from any to $ext_if port ssh \ queue ( qssh, qack ) synproxy state ( max-src-conn-rate 1/60, \ overload <BRUTEFORCERS> flush global ) # synproxy защищает наш сервис ssh от DoS атак, благодаря тому, что # сначала САМ устанавливает соединение # (не допуская полуоткрытых состояний), # а потом передает установленное соединение сервису. # Имеет немного бОльшие накладные расходы по сравнению с keep # max-src-conn-rate numer/time interval # позволяет применить определенные действия # к превысившим ограничение по количеству подключений # за единицу времени. Здесь я указал максимум 1 подключение # за 60 секунд. Все превысившие это ограничение заносятся в таблицу # BRUTEFORCERS и с ними разрываются (flush) установленные # соединения по всем (global) портам. Обратитие внимание, что # 1/60 -- очень агрессивная настройка. Не попадитесь под нее сами. # В Вашем случае 5/300 возможно будет более актуальным. # разрешаем входящий трафик www, который пойдет через прокси. # Нет смысла в разделении этого трафика по очередям cbq, т.к. : # 1. Можем зашейпить его с помощью squid delay pools # 2. PF не сможет определить принадлежность трафика к # к конкретному пользователю, после того как траф будет # пропущен через squid (ведь шейпинг у нас работает на $ext_if). pass in on $int_if proto tcp from { $boss, $buh, $admin } to \ any port $proxy_port # пропустим запросы синхронизации времени поступающие на # $int_if . Помещаем такие пакеты в самую быструю очередь. # Т.к. подтверждение о получении в UDP не высылается # то и не указываем вторым параметром имя очереди qack. # -- pass in on $int_if proto udp from { $boss, $buh, $admin } to \ any port ntp queue qntp keep state # Заметьте, что вторым параметром при указании очереди # указывается имя очереди, по которой пойдут ACK пакеты # queue ( ИмяОчередиОсновныхПакетов, ИмяОчередиACK_Пакетов ) #-- # Для создания # состояний UDP пакетов имеет смысл указывать только # keep state. Остальные (modulate и synproxy) полезны # для tcp. # Новостные конференции USENET (nntp) # вот тут юзеры могут и покачать, шейпим однозначно! # от Босса pass in on $int_if proto tcp from $boss to any port nntp \ queue ( qboss, qack ) modulate state # от Бухгалтера pass in on $int_if proto tcp from $buh to any port nntp \ queue ( qbuh, qack ) modulate state # от -=Админа=- pass in on $int_if proto tcp from $admin to any port nntp \ queue ( qadmin, qack ) modulate state # modulate -- это почти тот же keep с тем отличием, что # при установлении соединения будут сгенерированы # высококачественные Initial Sequence Number, которые # труднее угадать, соответственно труднее перехватить сессию. # DNS запросы идут по спец очереди qdns с высоким приоритетом # UDP не шлет ACK, qack не используем # от Босса pass in on $int_if proto udp from $boss to any port domain \ queue qdns keep state # от Бухгалтера pass in on $int_if proto udp from $buh to any port domain \ queue qdns keep state # от -=Админа=- pass in on $int_if proto udp from $admin to any port domain \ queue qdns keep state # входящие соединения с компом WinPeak по порту rdp # защищаем с помощью synproxy pass in on $ext_if proto tcp from any to $WinPeak port rdp \ queue ( qWinPeak, qack ) synproxy state # теоретически здесь synproxy уже не нужен pass out on $int_if proto tcp from any to $WinPeak port rdp \ queue ( qWinPeak, qack ) modulate state # выходящий через $ext_if ntp траффик # здесь пропишем очередь вручную для # пакетов, исходящих не из локальной сети, а # непосредственно от сервера pass out on $ext_if proto udp from $ext_if to any port ntp \ keep state queue qntp # выходящий через $ext_if nntp траффик (tcp) pass out on $ext_if proto tcp from $ext_if to any port nntp \ modulate state # выходящий через $ext_if www траффик (tcp) pass out on $ext_if proto tcp from $ext_if to any port www \ modulate state # выходящий через $ext_if dns траффик (udp) # здесь пропишем очередь вручную для # пакетов, исходящих не из локальной сети, а # непосредственно от сервера pass out on $ext_if proto udp from $ext_if to \ $dns_serv port domain keep state queue qdns # Возможность доступа к SAMS из внешней сети. # Логируем, # защищаем с помощью synproxy . pass in log on $ext_if proto tcp from any to $ext_if \ port www synproxy state # icmp pass log inet proto icmp all icmp-type $allowed_icmp_types

Время от времени таблицу <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 совместно с NAT, а именно : у нас нет возможности привязать очереди к исходящим через $ext_if интерфейс пакетам, т.е. :


pass out on $ext_if from $boss to any queue qboss

НЕ будет направлять пакеты от босса в его очередь, потому что сначала сработает NAT и пакеты будут уходить с адресом отправителя $ext_if, а не $boss . Конечно же, остается возможность приоритезации трафика по портам или конкретным диапазонам IP адресов назначения, но это не всегда то, чего бы мы хотели.
Специально для этого случая (ALTQ+NAT), есть возможность привязки к очередям на этапе, когда адрес отправителя еще можно различить, т.е. на внутреннем интерфейсе. Что и сделано в моем наборе правил :


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 .....

В этом случае 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])


Литература :