ВАЛЕНТИН СИНИЦЫН, разработчик ПО, автор курсов по Linux и веб-технологиям. Кандидат физико-математических наук, доцент УрФУ

Shorewall:
iptables с человеческим лицом

Едва ли можно утверждать, что Linux испытывает недостаток в средствах настройки межсетевых экранов. Чем же выделяется из них Shorewall? Попробуем разобраться

Организация шлюза для выхода в интернет – та задача, с которой неминуемо сталкивается практически любой администратор. Естественно, для сетей разных размеров она будет решаться по-разному, но в сегменте SOHO для этих целей, вероятнее всего, будет выделен обычный компьютер под управлением специализированного (IpCop, Smoothwall, ClarkConnect и т.п.) или универсального (Debian, Red Hat, …) дистрибутива Linux (случай с BSD оставим для другой статьи).

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

Это очень удобно и эффективно, до тех пор, пока те самые задачи не выходят за рамки типовых. Как только это случается, зачастую оказывается проще настроить с нуля универсальный дистрибутив, чем перекроить «под себя» специализированный.

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

Практически все современные дистрибутивы Linux предлагают для этих целей собственные инструменты (как консольные, так и графические), но, в принципе, ничего не мешает использовать iptables/iproute2 и напрямую. Кроме того, существует как минимум один универсальный конфигуратор, подходящий практически к любому дистрибутиву, а в Mandriva даже выполняющий роль того самого «собственного инструмента» – Shorewall (www.shorewall.net) Томаса Истепа (Thomas M. Eastep). Вот о нем-то мы и поговорим подробнее.

Основная задача Shorewall – преобразование высокоуровневой логики работы межсетевого экрана, описанной в многочисленных конфигурационных файлах /etc/shorewall, в низкоуровневые правила iptables.

В терминах Shorewall, такой процесс называется «компиляцией» и выполняется с помощью «компилятора» – скрипта на языке оболочки или на Perl.

Изначально Shorewall был написан на чистом Shell; Perl-компилятор (Shorewall-perl) появился в версии 3.4.2 как сопутствующий продукт, но в настоящий момент он уже является более гибким, чем исходный вариант, ныне известный как Shorewall-shell. Shorewall-perl работает гораздо быстрее «собрата», аккуратнее проверяет конфигурационные файлы на этапе компиляции (и генерирует более подробные сообщения об ошибках), поэтому, если у вас нет каких-то специальных требований или антипатии к Perl, есть смысл остановиться именно на нем.

Основным преимуществом Shorewall является уже упомянутая выше высокоуровневость: вы сообщаете, что нужно сделать, предоставив программе самой решать, как это реализовать.

Надо отметить, что генерируемые Shorewall правила отнюдь не избыточны и грамотно структурированы, то есть одной из «оберточных проблем» – нечитабельного вывода – можно не опасаться.

Более того, все создаваемые в ходе работы компилятора вспомогательные скрипты имеют аккуратные отступы, так что (при желании) в них всегда можно разобраться.

Из недостатков Shorewall нужно отметить некоторую потерю гибкости (по сравнению с использованием «чистых» iptables/iproute2 ) и, что более важно, статичность создаваемой конфигурации. Для внесения каких-либо изменений (скажем, добавлении правила фильтрации) нужно отредактировать соответствующие файлы (правда, это необязательно делать напрямую – Shorewall умеет выполнять подстановки переменных) и выполнить повторную компиляцию. В некоторых случаях это может быть неприемлемо.

В заключение этого вводного обзора хочу обратить внимание на еще одно преимущество Shorewall – превосходную документацию, как справочную, так и обучающую. В дистрибутиве можно найти заготовки конфигурационных файлов для типовых ситуаций: отдельная машина, шлюз, шлюз с DMZ.

Исходя из этого обстоятельства, я не буду пытаться обогнать указанные ресурсы в плане подробности изложения, а постараюсь проиллюстрировать подходы к настройке Shorewall в ряде распространенных ситуаций.

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

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

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

Тонкая настройка производится с помощью правил, представляющих собой исключения из ранее заданной политики (например, для пары зон «DMZ-локальная сеть» имеет смысл установить политику DROP, но разрешить соединение с конкретными системами по определенным протоколам прикладного уровня).

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

• Определить зоны в /etc/shorewall/zones.
• Задать политики обмена трафиком между каждой парой зон в /etc/shorewall/policy.
• Указать «списочный состав» зон в /etc/shorewall/interfaces и (в более сложных случаях /etc/shorewall/hosts). В принципе, предназначение /etc/shorewall/interfaces более широкое, чем может показаться из предыдущего предложения, но в целях настоящей статьи мы не будем касаться подобных «тонкостей».
• Настроить правила пакетной фильтрации в /etc/shorewall/rules.
• Опционально: если в локальной сети используются немаршрутизируемые («серые») адреса, активировать маскрадинг/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	eth0		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 соответственно увеличивается (в общем случае в нем должны быть перечислены все пары «локальный интерфейс-внешний интерфейс»).

Фильтрация трафика

Конфигурация, описанная в прошлом разделе, уже является работоспособной, но не слишком полезной. Обогатим ее, внеся исключения из стандартных политик в /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 от вашего имени, можно командой:

# shorewall show

Разумеется, «iptables -L» тоже никто не отменял.

Дополнительные возможности

Давайте посмотрим, что еще можно сделать с нашей конфигурацией Shorewall.

Первое, что приходит сразу на ум, – прозрачный прокси-сервер: прием, о порочности которого было сказано уже достаточно много, но тем не менее широко распространенный. Неудивительно, что соответствующие настройки можно найти прямо в примерах на man-странице shorewall-rules(5):

#ACTION  SOURCE DEST      PROTO DEST    SOURCE  ORIGINAL
#                               PORT    PORT(S) DEST
REDIRECT loc    3128      tcp   www      -      !192.168.0.2

Действие REDIRECT передает пакет локальному (для шлюза) процессу, прослушивающему порт, указанный в колонке DEST (у нас это 3128 – стандартная настройка Squid и большинства других HTTP-прокси). Правило удовлетворяет TCP-соединениям, имеющим в качестве порта назначения 80 (в примере использован псевдоним www, заданный в /etc/services), кроме адресованных 192.168.0.2 (вероятно, внутреннему веб-серверу).

Рассмотренное выше перенаправление является частным случаем DNAT-преобразования (в том смысле, что REDIRECT можно рассматривать как DNAT на локальный IP-адрес), которое можно применять с самыми разными целями. Например, классический проброс портов (port forwarding) интернет-соединений на все тот же внутренний веб-сервер может быть организован следующим образом:

#ACTION SOURCE DEST            PROTO  DEST  SOURCE  ORIGINAL RATE
#                                     PORT  PORT(S) DEST     LIMIT
DNAT    net    loc:192.168.0.2 tcp    http  -       -        3/sec:10

Зона и адрес, на который должны быть переправлены запросы, указывается в поле DEST. Если у шлюза несколько IP-адресов, а проброс портов нужно производить только для одного, укажите его в колонке ORIGINAL DEST. Наконец, RATE LIMIT задает максимально допустимую нагрузку: в среднем 3 запроса в секунду, но не более 10 пиково.

Действие DNAT удобно тем, что создает сразу два правила iptables: одно непосредственно для преобразования адресов, а другое – для приема трафика, удовлетворяющего заданным критериям. В большинстве ситуаций это именно то, что требуется. Если же вы по каким-либо причинам хотите добавить только DNAT и ничего больше, используйте действие DNAT-.

DNAT-преобразование можно применить для создания «виртуальных сервисов»: сетевых служб, которые, с точки зрения клиентов локальной сети, выполняются на шлюзе, а на самом деле находятся где-то в другом месте.

Возьмем, к примеру, электронную почту: если сеть сравнительно невелика, то вполне вероятно, что в ней не будет собственного SMTP-сервера: всю корреспонденцию будут просто отправлять через сервер провайдера. Если эти самые провайдеры (а вместе с ними и SMTP-серверы) меняются достаточно часто (да, такое тоже бывает: в первые две недели месяца связь обеспечивает компания A, по исчерпанию лимита – компания Б), перенастройка почтовых клиентов на компьютерах пользователей превращается в головную боль.

Следующее правило избавит вас от нее:

#ACTION SOURCE   DEST        PROTO DEST    SOURCE  ORIGINAL
#                                  PORT    PORT(S) DEST
DNAT-	loc	 net:1.2.3.4 tcp   25      -       192.168.0.1

Мы осуществляем прозрачную передачу всех TCP-соединений на 192.168.0.1:25 серверу с адресом 1.2.3.4 (использовать здесь доменные имена можно, хотя и настоятельно не рекомендуется). Теперь можно сообщить вашим пользователям, что для исходящей почты нужно указать сервер 192.168.0.1 (особые эстеты могут завести для него доменное имя – при наличии в сети DNS-сервера это займет пару секунд) – и дело в шляпе.

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

Здесь может пригодиться еще одна особенность Shorewall – умение получать параметры извне и работать с переменными. Центральная роль здесь отводится файлу /etc/shorewall/params: это сценарий на языке оболочки, который копируется в результирующий скрипт, генерируемый Shorewall в процессе компиляции. Он, например, может иметь такой вид:

ROUTER_IP=192.168.0.1
SMTP=$(get_current_smtp)

Здесь подразумевается, что в вашей системе реализована команда get_current_smtp, возвращающая IP-адрес SMTP-сервера текущего провайдера. Тогда правило для «виртуального сервера» можно переписать так:

#ACTION SOURCE   DEST        PROTO DEST    SOURCE  ORIGINAL
#                                  PORT    PORT(S) DEST
DNAT-	loc	 net:$SMTP   tcp   25      -       $ROUTER_IP

Имена переменных рекомендуется начинать с большой буквы – так вы гарантированно избежите конфликта имен с внутренними переменными Shorewall. Теперь при смене провайдера достаточно просто выполнить команду shorewall restart.

Вместо заключения

Shorewall позволяет создавать конфигурации практически любой сложности: с несколькими провайдерами (в том числе разделяющими один сетевой интерфейс), мостами, шейпингом и учетом трафика, VPN... На худой конец, его можно сравнительно легко модифицировать под свои нужды, а лицензия (GPLv2) позволяет даже распространять измененные копии. Искусство в том, чтобы понять, не забиваете ли вы микроскопом гвозди (и не идете ли с саблей на танки), но выбор инструмента, оптимальным образом подходящего под конкретную задачу, – это тема совсем для другой статьи. Или даже учебника.

Ключевые слова: Shorewall, iptables.

Комментарии могут оставлять только зарегистрированные пользователи