Записки старого админа

Решил немного отвлечься от всех дел и написать что-то полезное для новичков связавшихся с ipfw.

Из своей практики знаю как новички обходят стороной ipfw и другие firewalls. Но не стоит их боятся, ведь они предназначены для помощи админам, а не на вред им же :).. Хотя, не исключается момент, когда не подумав о последствиях — админ запускает правила только что написанного firewallа и попадает в просак. Особенно это касается, когда речь идет об удаленном сервере. После чего админу приходится собираться в путь дорожку к этому самому серваку :(. Было и у меня такое пару раз, когда я забыл в ipfw открыть 22 порт, перед дропанием всего лишнего. Или например, когда неграмотно прописал правила перед divert (NAT) и так же потеряв к нему доступ. Но это было в начале моей практики данного пункта изучения. Поэтому я и решил написать эту статью, что бы прочитавшие — меньше наступали на грабли.

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

Первая заметка.
При создании правил, старайтесь использовать шаг хотя бы в 10 правил, для того что бы в случае чего — добавить еще в средину новые правила:

   ipfw add <b>10</b> ....
   ipfw add <b>20</b> ....
   ipfw add <b>30</b> ....

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

   ipfw table 1 add 192.168.1.11 
   ipfw table 1 add 192.168.1.12
   ipfw table 1 add 10.16.0.0/24

Так же можно, маркировать добавляемые подсети. (Это может быть полезным для задавания ограничений с помощью, pipe или queue), например:

   ipfw pipe 1 config bw 1Mbit/s 
   ipfw pipe 2 config bw 2Mbit/s 
 
   ipfw table 1 add 10.18.2.15   1
   ipfw table 1 add 10.18.2.16   1
   ipfw table 1 add 10.18.2.17   2
   ipfw table 1 add 10.18.4.0/24 2
 
   ipfw add pipe tablearg ip from any to "table(1)"
   ipfw add allow ip from "table(1)" to any

Третья заметка.
Постарайтесь что бы последним (65535), ну или предпоследним (65534) правилом вашего ipfw, была такая строчка:

   ipfw add 65534 deny log ip from any to any

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

  ipfw -q flush

при закрытом фаерволе, вы потеряете к нему доступ (поэтому, если у вас нет под руками ip kvm подключенного к вашему серверу — то лучше так не делать, а скомпилить его открытым и добавить правило руководствуясь этим пунктом.

Четвертая заметка.
Перед закрытием правил, обязательно открыть 22 порт, для того что бы не потерять доступ по ssh (если вы настраиваете фаервол через него):

  ipfw add 100 allow ip from any to me 22
  ipfw add 100 allow ip from me 22 to any

Пятая заметка.
Как видно в предыдущем примере, старайтесь использовать одноименные правила под одним номером — это позволит проще убирать и добавлять их. То есть, например у вас в кроне стоит какой нибудь скрипт, убирающий и добавляющий правило с номером 500. Или же вы сами будете при каких либо настройках добавлять или удалять некоторые правила. Для того что бы было меньше телодвижений — это ускорят работу:

Сделать.

  ipfw delete 500

Всегда быстрее, чем

  ipfw delete 500
  ipfw delete 501
  ipfw delete 502

И так далее.

Также, если у вас есть несколько каналов или поставлена сложная задача при создании правил с большим количеством хостов или подсетей, а также где есть повторение одних и тех же правил (например, до nat и после) — используйте правило skipto

Очень полезна эта функция, в случае использования 2 каналов со статическими шлюзами:

   if1="rl0"
   if2="rl1"
   if3="rl2"
   gw1="шлюз 1"
   gw2="шлюз 2"
 
   ipfw add 10 skipto 30 tag 1 in recv $if1 keep-state #(маркируем пакеты вошедшие через карточку 1)
   ipfw add 20 skipto 30 tag 2 in recv $if2 keep-state #(маркируем пакеты вошедшие через карточку 2)
   ipfw add 30 allow { recv $if1 or recv $if2 } #(разрешаем все пакеты входящие снаружи на обоих карточках)
   ipfw add 40 allow in recv $if3 #(разрешаем ответы на внутренней карточке)
   ipfw add 50 fwd $gw1 tagged 1 #(Отправляем пакеты по маркированные тегом 1 на первый шлюз)
   ipfw add 60 fwd $gw2 tagged 2 #(Отправляем остальные пакеты, которые с тегом 2 на второй шлюз)

Это типичный пример для динамического правила в фаерволе.

Ну и наконец-то я подошел к самому главному. Структура и порядок рекомендуемых правил при создании фаервола.

1. Инструкции deny и reject (если нужно), чтобы убить ненужный трафик. Всем известный пример:

  ipfw add 1 deny all from table(1) to any

Он добавлен при настройке sshit;
2. Дальше идут правила count для полезного трафика на внешнем интерфейсе. (Также — если нужна полная статистика, то пишем правила count до 1го пункта);
3. Далее идут правила forward и skipto, prob, keep-state если нужно;
4. Следом идут правила allow(pass) на ваши сервисы, доступные из вне вашей сети;
5. После, идут правила divert (NAT);
6. Снова идут правила подсчета count, но уже для внутренней сети (это если важна статистика);
7. Теперь все правила allow,pipe,queue на внутренние подсети, или хосты;
8. Следом, allow для разрешенных соединений с роутера, а также уже соединенных (established)
9. Ну и на последок, о чём я уже говорил — запрещаяем всё остальное, складывая в логи то что режется log deny any to any. В логи пишем обязательно — это поможет при настройке.

Просмотреть то что лежит в логах можно командой:

   tail /var/log/security

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