 |
|
|
|
Shorewall: iptables с человеческим лицом
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):
Давайте разберемся, как все это работает, на простейшем примере: подключении к Интернету одной локальной сети. Соответствующие заготовки можно найти в 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 Комментарии удалены ради экономии места, полный вариант можно найти в указанном выше каталоге 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 Отличие состоит в том, что весь входящий из Интернета трафик игнорируется посредством 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 и «-». Интерес представляют лишь опции – остановимся на них подробнее:
Стоит отметить, что приведенная схема является возможной, но не самой оптимальной. Например, для net есть смысл указать norfc1918 (немаршрутизируемых адресов там не должно быть по определению), а logmartians установить также и для loc (чтобы вовремя заметить в ней подозрительную активность и подавить ее). В конечном итоге, все определяется уровнем безопасности и контроля, который вы хотите достичь. Из других опций следует упомянуть optional (простите за тавтологию), подавляющую ошибку компиляции в случае, если интерфейс недоступен при запуске Shorewall (полезно для PPP-соединений) и routeback, заставляющую весь трафик, пришедший через интерфейс X, возвращаться к отправителю через него же (без этого практически не обойтись в ситуации, когда провайдеров несколько). Наконец, чтобы все это заработало, нужно настроить маскрадинг. Для этого в файл /etc/shorewall/masq достаточно добавить одну строку: #INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC MARK Это может выглядеть странновато, но на самом деле все просто. В колонке 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 Разберемся в происходящем построчно. Во-первых, как вы помните, наша политика запрещает все соединения, кроме созданных между клиентом в локальной сети и сервером в Интернете: ни связка «клиент-брандмауэр», ни связка «брандмауэр-Интернет» сюда не попадают. При этом на шлюзе с 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 В результате любая попытка «выйти в аську» будет протоколироваться и отклоняться с сообщением вроде «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 Зона и адрес, на который должны быть переправлены запросы, указывается в поле 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 Из всех крупных дистрибутивов Linux, по умолчанию Shorewall включен только в Mandriva (где он является межсетевым экраном по умолчанию) и репозитории Debian. Пакеты существуют для Red Hat/Fedora и других RPM-дистрибутивов, а также Arch Linux. Если все это не про вас, установить Shorewall можно вручную. Вам потребуется два архива: shorewall-common-4.2.x, содержащий файлы, общие для всех разновидностей Shorewall, и компилятор: shorewall-perl-4.2.x или shorewall-shell-4.2.x. Настоятельно рекомендую также загрузить и документацию: она содержится в архиве shorewall-docs-html-4.2.x. А вот shorewall-lite пока можете оставить: это облегченный вариант, позволяющий загружать уже готовые правила, заранее сгенерированные на отдельном компьютере, но не компилировать их. С зависимостями проблем возникнуть не должно: потребуется достаточно новое ядро и Iptables/iproute2, а также интерпретатор Perl с рядом распространенных модулей или Bash. Все подробности можно найти в документации. |
ВАЛЕНТИН СИНИЦЫНКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
