OpenNET: статья - Shorewall: iptables с человеческим лицом (firewall iptables linux)

Ключевые слова: firewall, iptables, linux, (найти похожие документы)
From: Валентин Синицын Date: Mon, 23 Apr 2009 17:02:14 +0000 (UTC) Subject: Shorewall: iptables с человеческим лицом Материал предоставлен редакцией журнала Системный администратор. Опубликовано в журнале "Системный администратор" N 2 2009 Едва ли можно утверждать, что Linux испытывает недостаток в средствах настройки межсетевых экранов. Чем же выделяется из них Shorewall? Попробуем разобраться! Организация шлюза для выхода в Интернет - та задача, с которой неминуемо сталкивается практически любой администратор. Естественно, для сетей разных размеров она будет решаться по-разному, но в сегменте SOHO для этих целей, вероятнее всего, будет выделен обычный компьютер под управлением специализированного (IpCop, Smoothwall, ClarkConnect и т. п.) или универсального (Debian, Red Hat, ...) дистрибутива Linux (случай с BSD оставим для другой статьи). При использовании IpCop со товарищи все более-менее ясно: у администратора есть веб-интерфейс, через который задаются необходимые параметры и активируются требуемые сервисы, после чего система оказывается способной решать типовые задачи без сколько-нибудь серьезной настройки. Это очень удобно и эффективно, до тех пор, пока те самые задачи не выходят за рамки типовых. Как только это случается, зачастую оказывается проще настроить с нуля универсальный дистрибутив, чем перекроить "под себя" специализированный. Универсальность, в свою очередь, обычно подразумевает несколько возможных путей решения одной и той же задачи, даже если речь идет о вещах столь обыденных, как настройка межсетевого экрана и маршрутизации. Практически все современные дистрибутивы Linux предлагают для этих целей собственные инструменты (как консольные, так и графические), но, в принципе, ничего не мешает использовать iptables/iproute2 и напрямую. Кроме того, существует как минимум один универсальный конфигуратор, подходящий практически к любому дистрибутиву, а в Mandriva даже выполняющий роль того самого "собственного инструмента" - Shorewall (http://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 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 соответственно увеличивается (в общем случае в нем должны быть перечислены все пары "локальный интерфейс-внешний интерфейс"). Фильтрация трафика Конфигурация, описанная в прошлом разделе, уже является работоспособной, но не слишком полезной. Обогатим ее, внеся исключения из стандартных политик в /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 Из всех крупных дистрибутивов 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. Все подробности можно найти в документации.

2.3, reader (ok), 17:23, 26/04/2009 [^] [^^] [^^^] [ответить]	+/–
всего лишь генератор правил для iptables. по моему проще разобраться с iptables, чем править три десятка файлов. ну это конечно же кому что нравится. по мне так iptables-save гораздо понятней.

2.10, Craft (?), 01:29, 10/12/2011 [^] [^^] [^^^] [ответить]	+/–
Кашерно писать все на асемблере..Тока база иногда может изменится, а правила едины)