Директива deny сводит к минимуму риск определенных атак типа «отказ в обслуживании» и усложняет взломщику задачу сканирования системы. В то же время директива reject позволяет скрыть факт наличия брандмауэра, так как она заставляет систему вернуть отправителю сообщение о том, что хост или порт недоступен (как если бы маршрутизатор не смог найти хост или на нем отсутствует приложение, контролирующее заданный порт).

В нашем случае предпочтительнее будет указать директиву deny, потому что она заставляет систему игнорировать пакет, чтобы отправитель думал, будто пакет потерялся или хост-адресат выключен. Я бы еще добавил, что такая реакция сильно замедляет автоматическое сканирование.

Например, команда, добавляющая правило, которое запрещает доступ к нашему серверу 172.29.1.1 для атакующего хоста 172.29.1.19, будет выглядеть следующим образом:

ipfw add deny ip from 172.29.1.19 to 172.29.1.1

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

Не забудьте проверить список настроек ipfw с помощью команды «ipfw list». Это необходимо для того, чтобы ваше запрещающее правило не лишилось смысла из-за стоящего перед ним уже есть разрешающего. В случае если у вас уже используются разрешающие правила для данного трафика, проследите за тем, чтобы запрет оказался выше по списку.

Можно, конечно, ограничиться только запретом tcp, но лучше, чтобы все выглядело, как будто сервер не просто недоступен, а выключен. Такого результата легче добиться, запретив любой IP-трафик. Вообще утилита ipfw обладает довольно большими возможностями, подробно ознакомиться с которыми можно в справочнике [2].

Итак, мы определились с тем, какие записи в журнале событий нам необходимо просматривать и как на них реагировать. Для разнообразия будем список заблокированных IP-адресов с указанием времени блокирования отправлять на почту системному администратору. Хотелось бы сразу предупредить, что этих писем будет довольно много и поэтому необходимо заранее создать в почтовом клиенте соответствующую папку и правило для перенаправления писем.

Листинг 2. Сценарий, блокирующий атаки на POP3

#!/usr/bin/perl -w

use Mail::Sendmail;

# максимально разрешенное число попыток

$max=10;

# файл журнала, с которым мы и работаем

$watchfile=         '/var/log/messages';

$ipfw=          '/sbin/ipfw';

# то же ipfw но после сохранения изменений

$ipfw_save=     '/sbin/ipfw_save';

# исходные значения ipfw

$ipfw_restore=  '/sbin/ipfw-restore';

# файл конфигураций ipfw

$cfgfile=           '/etc/sysconfig/ipfw'