Конфигурация, описанная в прошлом разделе, уже является работоспособной, но не слишком полезной. Обогатим ее, внеся исключения из стандартных политик в /etc/shorewall/rules. Вот каким видят этот файл авторы Shorewall (комментарии по-прежнему опущены):
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK
# PORT PORT(S) DEST LIMIT GROUP
DNS/ACCEPT $FW net
SSH/ACCEPT loc $FW
Ping/ACCEPT loc $FW
Ping/DROP net $FW
ACCEPT $FW loc icmp
ACCEPT $FW net icmp
Разберемся в происходящем построчно. Во-первых, как вы помните, наша политика запрещает все соединения, кроме созданных между клиентом в локальной сети и сервером в Интернете: ни связка "клиент-брандмауэр", ни связка "брандмауэр-Интернет" сюда не попадают. При этом на шлюзе с Shorewall, весьма вероятно, будут запущены кэширующий DNS-сервер (dnsmasq или BIND) и SSH-сервер для удаленного администрирования. Без правил в первых двух строках они будут бесполезными: брандмауэр не сможет связаться с DNS-сервером, отвечающим за интересующую вас зону, а sshd не увидит входящее соединение. Альтернативный вариант (разрешить шлюзу выход в Интернет, а локальной сети - произвольный доступ к шлюзу) тоже возможен и в ряде случаев даже оправдан, но менее безопасен.
В колонке ACTION (кроме двух последних записей) мы видим пример использования макросов DNS, SSH и Ping. Макрос - это просто набор заранее определенных правил, принимающий окончательное действие (например, пропустить или отклонить пакет) в качестве дополнительного параметра.
Макросы определяются в файлах macro.имя_макроса в каталоге
/usr/share/shorewall. Вот так, например, выглядит макрос macro.DNS:
#ACTION SOURCE DEST PROTO DEST SOURCE RATE USER/
# PORT(S) PORT(S) LIMIT GROUP
PARAM - - udp 53
PARAM - - tcp 53
Как нетрудно видеть, это просто правила, отбирающие TCP/UDP-трафик на порт 53. При развертывании макроса ключевое слово PARAM заменяется фактическим значением параметра: для нашего случая это будет ACCEPT.
Аналогичным образом, мы принимаем ICMP Echo-запросы, исходящие от локальных компьютеров на адрес маршрутизатора, но явным образом игнорируем "пинги", приходящие из сети. Этого можно было бы и не делать (политика по умолчанию выполняет ровно то же самое), но данное правило не создает никаких записей в журнальных файлах и соответственно препятствует их быстрому захламлению. Как мы уже обсудили выше, о полезности подобного подхода можно поспорить (в конце концов, внезапная волна ping-запросов может свидетельствовать о готовящейся атаке), но здесь следует отметить для себя один факт: правила в /etc/shorewall/rules выполняются до действий, связанных с политиками. Последние две строки разрешают любой ICMP-трафик между брандмауэром и компьютерами локальной сети, а также между брандмауэром и Интернетом.
Думается, после всего вышесказанного составить обещанное правило для блокировки ICQ не составит труда:
#ACTION SOURCE DEST
ICQ/LOG:info loc:!192.168.0.10 net
ICQ/REJECT loc:!192.168.0.10 net
В результате любая попытка "выйти в аську" будет протоколироваться и отклоняться с сообщением вроде "Connection refused". Отметим, что это ограничение не касается клиента с адресом 192.168.0.10 (за что ему были дарованы такие привилегии - придумайте сами: автор вообще не сторонник запретительно-технических мер борьбы с неэффективностью работы офисных служащих).
Записи в файле /etc/shorewall/rules (как, впрочем, и во многих других в Shorewall, за исключением /etc/shorewall/tcrules) проверяются до первого совпадения - составляя собственные правила, имейте это в виду.
Сказанное не относится к действиям LOG и QUEUE - они не прерывают обработку пакета.
Итак, поздравляем: настройка Shorewall завершена. Чтобы изменения вступили в силу, необходимо набрать команду:
# shorewall start
но грамотные люди рекомендуют сначала удостовериться, что ваши настройки корректны. Это можно сделать командой:
# shorewall check
Она выполнит процесс компиляции, но не станет запускать сгенерированный скрипт; вы же сможете отловить все ошибки и предупреждения.
Посмотреть, какие именно правила iptables были созданы Shorewall от вашего имени, можно командой:
