16.1Базовая настройка

Центральной концепцией при настройке Shorewall является зона - логическая единица, объединяющая в себе однородные (с точки зрения доступа) узлы сети. Классическими примерами зон являются локальная сеть, Интернет и демилитаризованная зона DMZ. Как правило, зоны отображаются на сетевые интерфейсы по принципу 1:1, хотя подобный подход никоим образом не навязывается.

Обмен трафиком между зонами контролируется так называемыми политиками. Естественно, его можно разрешить (ACCEPT), запретить (DROP) или отклонить (REJECT). В последнем случае отправитель получит соответствующее уведомление (RST для TCP или ICMP Unreachable для других протоколов). Тонкая настройка производится с помощью правил, представляющих собой исключения из ранее заданной политики (например, для пары зон "DMZ-локальная сеть" имеет смысл установить политику DROP, но разрешить соединение с конкретными системами по определенным протоколам прикладного уровня).

Таким образом, настройка Shorewall в простейшем случае сводится к следующим шагам (здесь и далее предполагается, что общим корнем для конфигурационных файлов программы является /etc/shorewall; это значение может быть переопределено параметром CONFIG_PATH в главном конфигурационном файле /etc/shorewall/shorewall.conf):

1. Определить зоны в /etc/shorewall/zones.

2. Задать политики обмена трафиком между каждой парой зон в /etc/shorewall/policy.

3. Указать "списочный состав" зон в /etc/shorewall/interfaces и (в

более сложных случаях /etc/shorewall/hosts). В принципе, предназначение /etc/shorewall/interfaces более широкое, чем может показаться из предыдущего предложения, но в целях настоящей статьи мы не будем касаться подобных "тонкостей".

4. Настроить правила пакетной фильтрации в /etc/shorewall/rules.

5. Опционально: если в локальной сети используются немаршрутизируемые ("серые") адреса, активировать маскрадинг/SNAT в /etc/shorewall/masq (обратите внимание: все, что касается DNAT, содержится не здесь, а в /etc/shorewall/rules).

Давайте разберемся, как все это работает, на простейшем примере: подключении к Интернету одной локальной сети. Соответствующие заготовки можно найти в shorewall-common-4.2.x.tar.bz2/Samples/two-interfaces (см. врезку "Установка Shorewall"), но прежде чем вы возьметесь за них, позвольте продублировать предостережение из фирменной документации: не администрируйте Shorewall удаленно через SSH (или хотя бы не производите через SSH его первоначальную настройку). Это возможно и неплохо работает, но в один прекрасный момент вы непременно заблокируете себе сетевой доступ, и вам все равно придется идти на склад за клавиатурой и монитором. Если вы экспериментируете на реальной машине, озаботьтесь этим с самого начала.

Для начала разберемся с зонами. В данном случае их понадобится три штуки: одна для Интернета (назовем ее net), одна для локальной сети (loc) и одна (fw) для самого брандмауэра; наличие последней зоны является обязательным во всех конфигурациях. Имена зон можно выбирать произвольно (за вычетом зарезервированных ключевых слов, вроде all и none), но в настройках по умолчанию они не могут быть длиннее пяти символов. Имя зоны брандмауэра (в нашем примере - fw) сохраняется в переменной $FW, с которой мы еще не раз встретимся по ходу изложения. Зоны net и loc имеют тип ipv4 (последние версии Shorewall поддерживают также протокол IPv6, но мы не будем говорить о нем в контексте данной статьи), для fw зарезервирован специальный тип - firewall.

В итоге файл /etc/shorewall/zones примет следующий вид:

#ZONE TYPE OPTIONS IN OUT

# OPTIONS OPTIONS

fw firewall

net ipv4

loc ipv4

Комментарии удалены ради экономии места, полный вариант можно найти в указанном выше каталоге Samples.

Перейдем к политикам. В данном случае они сводятся к одной-единственной фразе: клиенты из локальной сети могут беспрепятственно обмениваться данными с Интернетом (всякие "аськи" можно "прикрыть" потом, в /etc/shorewall/rules), весь остальной трафик запрещен, если не оговорено иное. Иными словами, для пары loc-net установлена политика ACCEPT, для всего остального - REJECT. Соответствующий файл /etc/shorewall/policy может выглядеть так:

#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST

loc net ACCEPT

all all REJECT info

Обратите внимание на последнюю строку: она интересна нам по двум причинам. Во-первых, в ней задается политика по умолчанию, которая действует, если для некоторой пары зон не найдена никакая другая, во-вторых, весь трафик, удовлетворяющий политике по умолчанию, протоколируется в syslog с уровнем info. Указанный вид политики по умолчанию является своего рода хорошим тоном: считается, что для всех штатных ситуаций предусмотрены специальные политики и срабатывание умолчательной является сигналом о подозрительной активности.

Если заглянуть все в тот же каталог Samples, можно заметить, что предлагаемый авторами Shorewall набор политик выглядит чуть сложнее, а именно:

#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST

loc net ACCEPT

net all DROP info

all all REJECT info

Отличие состоит в том, что весь входящий из Интернета трафик игнорируется посредством DROP: разумный подход к безопасности подсказывает, что не следует уведомлять потенциального взломщика о том, что вы существуете и как-то обрабатываете его пакеты. Протоколирование можно и выключить: вряд ли вы будете ежедневно продираться через тысячи строк журнальных файлов в поисках потенциально опасных действий, а какой-нибудь Snort справится с этой задачей лучше и быстрее (кстати, если вы действительно собираетесь использовать его в связке с Shorewall, внимательно прочтите все, что касается политики QUEUE на man-странице shorewall-policy).

Если же не просто заглянуть в каталог Samples, а еще и прочитать файл two-interfaces/policy со всем тщанием, вы заметите, что политик в нем на самом деле не три, а десять. Как отмечают сами авторы, это сделано для большей детализации сообщений в журнальных файлах: функциональность, что у десяти, что у трех, одинаковая; кроме того, "разворачивать" политики Shorewll может автоматически. Поэтому мы тоже побережем журнальное пространство и перейдем к интерфейсам.

Соответствующий файл /etc/shorewall/interfaces выглядит так:

#ZONE INTERFACE BROADCAST OPTIONS

net th0 detect dhcp,tcpflags,routefilter,nosmurfs,logmartians

loc eth1 detect tcpflags,nosmurfs

Как нетрудно догадаться, локальная сеть в этом примере подключена к интерфейсу eth1, а выход в Интернет обеспечивается через eth0 (автор предпочитает прямо противоположную схему нумерации, но о вкусах не спорят). В колонке BROADCAST задается широковещательный адрес: в большинстве случаев система способна узнать его самостоятельно, а Shorewall-perl и вовсе понимает здесь только два значения: detect и "-". Интерес представляют лишь опции - остановимся на них подробнее:

• dhcp - сообщает, что на интерфейсе выполняется DHCP-клиент или сервер;

• tcpflags - предписывает проверять приходящие TCP-пакеты на предмет наличия нелегальных комбинаций флагов;

• routefilter,nosmurfs,logmartians - разные по своему действию, но близкие по духу параметры, заставляющие Shorewall обращать внимание на пакеты, которых "точно не должно быть на этом интерфейсе". Так, пакеты с широковещательным адресом отправителя отклоняются (nosmurfs), "марсиане" (пакеты с некорректным исходным адресом) протоколируются (logmartians). Сюда же можно отнести неиспользованную в данном примере опцию norfc1918, запрещающую принимать пакеты с немаршрутизируемых адресов вроде 192.168.0.0/16 (точный список берется из /etc/shorewall/rfc1918). Параметр routefilter предписывает включить в ядре фильтрацию по маршруту, но пользоваться им следует с осторожностью: в схеме с несколькими исходящими каналами возможны трудно диагностируемые неполадки.

Стоит отметить, что приведенная схема является возможной, но не самой оптимальной. Например, для net есть смысл указать norfc1918 (немаршрутизируемых адресов там не должно быть по определению), а logmartians установить также и для loc (чтобы вовремя заметить в ней подозрительную активность и подавить ее). В конечном итоге, все определяется уровнем безопасности и контроля, который вы хотите достичь.

Из других опций следует упомянуть optional (простите за тавтологию), подавляющую ошибку компиляции в случае, если интерфейс недоступен при запуске Shorewall (полезно для PPP-соединений) и routeback, заставляющую весь трафик, пришедший через интерфейс X, возвращаться к отправителю через него же (без этого практически не обойтись в ситуации, когда провайдеров несколько).

Наконец, чтобы все это заработало, нужно настроить маскрадинг. Для этого в файл /etc/shorewall/masq достаточно добавить одну строку:

#INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC MARK

eth0 eth1

Это может выглядеть странновато, но на самом деле все просто. В колонке INTERFACE указывается исходящий интерфейс, в нашем случае это eth0 (он, напомню, подключен к Интернету). В поле SOURCE перечисляются адреса, для которых нужно применить SNAT-преобразование: здесь, как и во многих реальных случаях, это просто eth1, то есть вся локальная сеть скопом.

При желании, имя интерфейса можно заменить явным указанием "серых" адресов (скажем, 192.168.0.0/24). Запретить SNAT для избранных узлов сети можно при помощи следующего синтаксиса: eth1:!192.168.0.1,192.168.0.3, кстати, он действует и во многих других конфигурационных файлах Shorewall.

Колонка ADDRESS является необязательной и позволяет указать IP-адреса, которые будут использоваться при маскардинге в качестве исходящих (в подавляющем большинстве случаев этого не требуется). Оставшиеся колонки позволяют отобрать пакеты, подлежащие SNAT-преобразованию, более точно; как именно - мы обсудим в следующем разделе.

Напоследок отметим, что если в вашей системе имеется более двух интерфейсов, число правил в /etc/shorewall/masq соответственно увеличивается (в общем случае в нем должны быть перечислены все пары "локальный интерфейс-внешний интерфейс").