понедельник, 12 сентября 2011 г.

Настраиваем фаервол: ipfw

Для начала, Ipfw должен быть в ядре или в виде модуля. Если ядро самосборное - крайне желательно собирать с IPFIREWALL_DEFAULT_TO_ACCEPT
Это связано с тем, что при ошибке в конфиге фаера или просто перезапуск без перевода процесса в фон чревато полной недоступностью сервера из сети. А так - прошёл ipfw -f -q flush (сброс правил), состояние стало "разрешить всё", и пока не дойдём до правила в конце "запрет всего лишнего", мы сможем как минимум переподключиться и поправить правила. Хотя это и не спасёт от ошибки вида "забыли проковырять дырку для ssh".
Минимальный набор служб, который обычно надо выпустить: 22 (ssh - tcp), 25 (smtp, отправка уведомлений с сервера, tcp), 53 (dns - как минимум мы сами должны уметь делать резолв, может быть как tcp так и udp)
Также надо сразу разрешить трафик на служебном интерфейсе lo0

Проверим, что ipfw включен:
ipfw -a list

Должно быть что-то вроде
65535 583535090 359726489527 allow ip from any to any
Правило номер 65535, следующие 2 числа это сколько трафика вошло и вышло (in и out), потом само правило - разрешить всё ото всех.

Простейшее правило:
ipfw add allow all from any to any via lo0
Разрешаем весь трафик на интерфейсе lo0

Разрешим для примера ssh
ipfw add allow tcp from any to me 22
ipfw add allow tcp from me 22 to any
Это правила без контроля соединения, поэтому надо 2 правила: первым мы разрешили коннекты к нам на 22 порт (ssh), но ответы от нас будут резаться. Вторым правилом мы разрешили отправлять с нашей стороны с 22 порта.

Есть динамические правила. Пишутся так:
ipfw add allow all from any to me 25 setup keep-state
Внимание! На нагруженном сервере спокойно можем схватить "Too many dynamic rules". Немного рассматривал у себя на примере limit, но вызывается это именно на keep-state, поэтому не рекомендую для web-сервера вешать на 80 порт, не понимая принципов работы IPFW. Также не рекомендую для ssh - если на сервере кончились динамические правила, фаервол не сможет нам разрешить ssh-подключение.

Пытался разобраться в смысле setup+keep-state, не разобрался. Кто-то пишет только setup, кто-то только keep-state...

- дальше по аналогии нужные правила -
Нюансы: например, чтобы почта ходила нормально, нужно 2 набора:
1) почта к нам
allow all from any to me 25 setup keep-state

2) почта от нас
allow all from me 25 to any setup keep-state

То же для днс, веба (если у нас там веб-сервер) - обновления тянутся по 80 порту...

Также не забываем про пинги
allow icmp from any to any

Теперь запретим всё лишнее, но будем писать лог, что запретили
ipfw add 65000 deny log all from any to any

логи идут в /var/log/security, но надо включить вывод

в ядре
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=100 # или сколько надо по умолчанию

либо в /etc/rc.conf
firewall_logging="YES"

либо
sysctl -w net.inet.ip.fw.verbose=1

Не забываем первое время проверять этот файл - там может оказаться забытая служба или разные аномалии.

Можно запретить выборочные порты, например 3306 (mysql), чтобы в лог не попадало об этом записей.

Вообще, возможностей значительно больше, включая нат, копирование всех пакетов куда-либо (tee), ограничение скорости (queue) итд. На хорошую книгу можно набрать.


Линки
Как вести лог блокировок в iptables и ipfw
http://dragonflybsd.blogspot.com/2011/03/ipfw.html

2 комментария:

  1. ipfw add allow all from any to me 22

    Allow all разрешает и tcp и udp. А ssh работает только по tcp.

    Setup keep-state пишут только для протокола tcp, он требует установки соединения. Протокол udp может работать сразу, поэтому пишут просто keep-state

    ОтветитьУдалить
  2. про ssh согласен. Поправил.

    А в чём сиысл setup? Создание того самого динамического правила? Тогда keep-state для tcp без setup к чему приведёт?

    ОтветитьУдалить