Инструменты для настройки iptables

Нафига они нужны-то? Проглядел в статье их синтаксис - так проще сразу iptables использовать...

Какой изврат люди только не придумают, лишь бы man iptables не читать...

Ничего проще shorewall нет. рекомендую.

Для iproute2 веб морды никто не встречал?

>Какой изврат люди только не придумают, лишь бы man iptables не читать...

Это да ;). Но всё ж лучше изучить Iptables Tutorial, имхо. А ман юзать как справочник по конкретным вопросам.

кг/ам

Автор не описал и десятой части конфигурялок, и пропустил две самых
лучших/фичастых - shorewall и pcxfirewall. Двойка. Назад в первый класс.

Очень неплохо - IMHO, по образу и подобию CheckPoint FW: http://www.fwbuilder.org

Ага, а какую фигню они генерят эти все конфигурялки, ажно страшно смотреть становится.

Бред какой то. Зачем осваивать пограмму которая генерит правила к другой программе? С конфигурялкой к sendmaail я еще понимаю, но iptables имеет такой простой синтаксис, что проще один раз понять принцип работы и базовые элементы составления правил, чем запариваться на использование сторонних программ.

ЗЫ: После пары часов шаманства плюнул.... man iptables. ЗЫ2: Конфигурялки умеют использовать POM ?

судя по обилию конфигурялок для айпитаблес у них на редкость убогий синтаксис...
посмотрел - так и есть: и рядом с pf\ipfw не лежали.

Можно еще использовать ferm http://ferm.foo-projects.org/ Тоже надстройка, но немного по-проще. Из плюсов - все те-же опции что и в iptables (поддерживаются ipchains) но не нужно писать всякие скрипты типа for port in 3128 1080 8000; do iptables ....; done

Это для тех, кто "неасилил" прочесть документацию, в т.ч. про мультипорт расширения

>судя по обилию конфигурялок для айпитаблес

конфигурялка для конфигурялки вообще, имхо нонсенс. Лишняя сущность. Синтаксис айпитейблс, имхо, достаточно понятен (для человека имеющего общее представление о tcp/ip) и гибок в настройке правил.

Единственный "недостаток" - начинающему юзеру надо поднапрячься (познакомиться в общих чертах со стеком тсп/ип и почитать туториал. Если его (этот "недостаток") "исправлять" - нужна гуевая конфигурялка айпитейблс с чекбоксами и прочим, а не городить огород с новыми синтаксисами - проще тогда в самом айпитейблс разобраться :)

вот как раз у меня эта проблема, повсюду фаирвол-коробочки с нормальным веб интерфейсом, все почеловечески можно настроить и тут понадобилось в rhel настроить ... все что там нашел это redhat-config-securitylevel, но это смешно, а убивать тучу времени на 50 мануала для плевой задачи сильно коробит.

>понадобилось в rhel настроить ... все что там нашел это redhat-config-securitylevel

Фигня этот секьюрити-левел. Правила генерит конченные.

>а убивать тучу времени

если тебе требуется несколько простеньких правил - тучу времени ты не убьёшь. Пару часов чтения упомянутого туториала (на опен.нет есть) и всё: набиваешь правила в консоль, потом

/sbin/iptables-save > /etc/sysconfig/iptables

и всё. Зато ты будешь точно знать, по каким правилам у тебя фильтруется трафик, а не надеятся на разработчика конфигурялки. Лично мне нравится ощущение контроля над правилами фильтрации, и посвятить пару часов этому вопросу - не проблема... имхо.

Если ты имеешь понятие о фильтрации вообще - никакой проблемы в использовании iptables нет. Синтаксис простейший. А размер хауту объясняется не сложным синтаксисом, а тем что там поясняется, что такое фильтрация, как она работает и для чего она нужна. Это надо знать в любом случае, все равно что ты используешь - консоль или веб-интерфейс.
iptables - 4ever

мне уже подсказали http://gazette.linux.ru.net/rus/articles/iptables-tutorial.html

но черт подери, ради того чтоб оставить 22 порт только для себя, читать весь этот толмуд - жестоко. а читать прийдется все до корки ибо если я облажаюсь то до сервера ехать не один десяток км.

>ради того чтоб оставить 22 порт только для себя, читать весь этот толмуд - жестоко

весь не надо. если айпитейблс уже присуствует в системе со всеми модулями начинай сразу отсюда http://gazette.linux.ru.net/rus/articles/iptables-tutorial.html#HOWARULEISBUILT

Я бы тебе порекомендовал GIPTables - очень классный набор шел-скриптов для генерации правил iptables: http://www.giptables.org/, все настраивается в одном конфигурационном файле.

P.S. ebuild присутсвует :) emerge giptables

Нах? Лучше разобраться самому. Для удалённого сервера правила надо генерировать ТОЛЬКО руками и головой. больше вариантов нет.

P.S. какой ещё ебилд?? У него RHEL.

А чего все так возмутились? Я например чувствую себя увереннее если пишу правила сразу для iptables, но в тоже время хочу разобраться в firehol.
Почему? Потому что для простых (и не только) файерволов firehol'овское описание выглядит намного короче, интуитивно понятнее и значительно легче читается. Отчасти это благодаря тому факту, что в firehol определены многие распространённые протоколы/типы пакетов (samba, dhcp, distcc, jabber...). Мне кажется значительно понятнее выглядит строка "client dhcp accept" чем соответствующее более длинное правило для iptables. Всё это добро сделано через обыкновенные шелл скрипты, так что никто не плодит лишних сущностей. Кроме того это всё легко расширяется, добавлением своих скриптов-правил.

Вот только у меня есть одна маленькая проблемка с firehol'ом...
В /etc/firehol/firehol.conf для eth1 прописаны следующие правила:
interface eth1 internet
    server ftp      reject
    server ssh      accept
    server samba    reject
    server squid    reject
    server smtp     reject
    client all      accept

Т.е. насколько я понимаю все исходящие соединения разрешены, но при
попытке зайти в irc мой irssi говорит Connection refused. :( Также
не коннектится аська и джаббер. Web при этом работает нормально. %)
Знатоки firehol'а, подскажите что я не так сделал? Документацию по
firehol'у пока пролистал довольно бегло, так что чур меня сильно
не бить. ;)

2 Dimez

Нафига изобретать колесо, если уже есть что-то готовое:

- зачем каждый раз снова и снова писать в 99% случаях одни и те же правила?

- кто-то уже все это дело автоматизировал, зачем изобретать колесо и пытаться это дело автоматизировать снова?

- многие, даже "продвинутые" пользователи не имеют понятия о разного рода сэнити-чекс, коннекш-трэкинг, син-флуд, спуфинг, лимит настройках в iptables;

Все это уже "автоматизированно" в GIPTables, а GIPTables в свою очередь есть шел-скрипт с набором конфиг. и модульных файлов, то есть написать доп. модуль для какого-либо протокола не составляет труда.

"P.S." относился ко всем ;) ebuild есть ;)

Там ссылки на сайты-сканнеры.Пошёл, проверился - почти всё ок.Только ответы на icmp идут.Там рекомендуют закрыть.А надо ли? Машина домашняя.Хочу услышать профессионалов

> Только ответы на icmp идут.Там рекомендуют закрыть.

О, я тоже хочу услышать мнение профессионалов - зачем рекомендуют закрывать icmp? Это же крайняя глупость IMHO. Разве что для того чтобы полностью "спрятать" хост... но нафиг это делать?

А зачем кому-то тебя пинговать?
Или ещё проще...
.. если не нужно - значит ОТКЛЮЧИТЬ!

А тебя это напрягает? А если сервис проверяет наличие хоста по эху? Зачем тебе его пинговать? ;)

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

А зачем тебя удп пакетами долбать? А зачем тебя ТСП пакетами долбать? iptables -A INPUT -s 0/0 -j DROP тебя спасет.

>ибо если я облажаюсь то до сервера ехать не один десяток км. да ну.... я всегда в такой ситуации делаю запуск по крону скрипта убирающего все правила... на период пинательств iptables минут на 5..;) облажался... сходил... покурил... подумал про место облажания.... ПАМАГАТ АДНАКА...;)

Ну, им кажется, что это необходимая мера защиты... ;-)

Иногда действительно полезно закрывать некоторые типы icmp, но уж никак не всё полностью... в этом больше вреда, чем пользы... почему? думаю сам понимаешь..

Не надо... если сильно беспокоит, можешь перекрыть лишь отдельные типы запросов...

Мой совет, всегда составляй и пиши правила ручками, по крайней мере, точно будешь знать, что у тебя фаерволится, я что нет..

> Иногда действительно полезно закрывать некоторые типы icmp, но уж никак не всё полностью... в этом больше вреда, чем пользы... почему? думаю сам понимаешь..

Прекрасно понимаю. :) Однако интересует откуда пошли такие советы про _полное_ запрещение ICMP? Уже не первый раз встречаю...

> Мой совет, всегда составляй и пиши правила ручками, по крайней мере, точно будешь знать, что у тебя фаерволится, я что нет..

Я так и делаю. :) Просто захотелось посмотреть на firehol. Между прочим беглый просмотр вывода iptables -L после запуска firehol'а ничего не прояснил в моей проблеме. Вроде стоят правила пропускающие irc, а irssi не подключается... засада. Ладно, как-нибудь в свободное время посмотрю более внимательно.

>Нафига они нужны-то? Проглядел в статье их синтаксис - так проще сразу iptables использовать...

интерфейс iptables можно сравнить с ассемблером - он позволяет сделать все, но сложные веши делать вручную очень неудобно. Например если у тебя сеть из нескольких машин, то все просто и можно написать вручную, но когда в сети этих машин > 100 (и при этом постоянно меняется конфигурация сети) и количество человек правящих скрипт больше одного то вручную писать команды iptables просто нереально.

К тому же в линуксе есть проблема с тем, что стоимость поиска правила в цепочке линейна (то есть O(N)) поэтому при количестве правил > 200 и хорошем трафике ядро начинает ощутимо тормозить. Поэтому приходится строить из правил дерево (что вручную оптимально сделать очень гемморойно).

Каждый решает такую задачу по-разному. Мы например в свое время (года 3-4 назад) придумали простенький язык описания топологии сети и компилятор к нему, который компилирует в набор правил iptables (старые версии делали ipchains) оптимальным образом. Если кому интересно продолжить развитие сего проекта, то его сайт http://flexfw.sf.net

есть правило -j log, как есть -j accept, -j reject, -j drop, специально для отладки позволяет записать пакеты в журнал

> есть правило -j log, как есть -j accept, -j reject, -j drop, специально для отладки позволяет записать пакеты в журнал

Знаем, знаем. :) Просто решил сразу здесь спросить, возможно кто-нибудь уже сталкивался с такой проблемой.

> А зачем тебя удп пакетами долбать? А зачем тебя ТСП пакетами

> долбать? iptables -A INPUT -s 0/0 -j DROP тебя спасет.

Эх.... малолетки. Вот такими правилами (тока под винду) один мой пользователь себя и закрыл...

Потом звонит и говорит, что у меня почтовик не работает...

ЗЫ: iptables -A INPUT -s 0/0 -j REJECT, естественно впереди у тебя разрешающие правила. Тогда я хотябы хост твой буду видеть.

По умолчанию у тебя не загружены модули ip_nat_irc, ip_conntrack_irc, загрузи и будет тебе счастье, так же и с ftp.

> я всегда в такой ситуации делаю запуск по крону скрипта убирающего все правила... на период пинательств iptables минут на 5..;)

Русская рулетка? :)

"кто успеет..."

> По умолчанию у тебя не загружены модули ip_nat_irc, ip_conntrack_irc, загрузи и будет тебе счастье, так же и с ftp.

Хм... И чем же в моём случае помогут эти модули? Ничем. Попробовал загрузить их на всякий случай - результата никакого.

Частично уже решил проблему - у меня была ошибка в синтаксисе конфига (лишняя пустая строка в неподходящем месте). Теперь если на интерфейсе стоит "client all accept", то irc, jabber и т.п. работают без проблем. Но теперь хочется большего - пропускать _только_ irc и jabber, используя правила вида "client irc accept", "client jabber accept". Снова не трафик не проходит... :(

>Частично уже решил проблему - у меня была ошибка в синтаксисе конфига (лишняя пустая строка в неподходящем месте). Теперь если на интерфейсе стоит "client all accept", то irc, jabber и т.п. работают без проблем. Но теперь хочется большего - пропускать _только_ irc и jabber, используя правила вида "client irc accept", "client jabber accept". Снова не трафик не проходит... :(

Тебе нужно следующее правило в FORWARD:

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

P.S. С FireHOL не знаком, команду, аналогичную выше приведенной, не скажу.

> Тебе нужно следующее правило в FORWARD:

> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

А зачем мне правило в цепочке FORWARD? У меня файервол работает на локальной машине. Поэтому нужны правила только для INPUT и OUTPUT.

> в линуксе есть проблема с тем, что стоимость поиска правила в цепочке линейна (то есть O(N)) поэтому при количестве правил > 200 и хорошем трафике ядро начинает ощутимо тормозить.

Непонятно, что ты хотел этим сказать. Что, в других ОС оно работает быстрее?

Raz poshla takaya p'yanka:

/sbin/iptables -N bad_tcp_packets /sbin/iptables -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset /sbin/iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New not syn:" /sbin/iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP /sbin/iptables -A INPUT -p tcp -j bad_tcp_packets /sbin/iptables -A OUTPUT -p tcp -j bad_tcp_packets

>> в линуксе есть проблема с тем, что стоимость поиска правила в цепочке линейна (то есть O(N)) поэтому при количестве правил > 200 и хорошем трафике ядро начинает ощутимо тормозить.

>Непонятно, что ты хотел этим сказать. Что, в других ОС оно работает быстрее?

Для линукса есть патч http://www.hipac.org (прада похоже на него забили) в котором была сдеалана внутрення реализация цепочек деревом. Правда насколько я помню там были какие-то довольно сильные ограничения на правила (вроде там conntrack нельзя было пользовать)

Повторю некоторые сообщения, но... 1. Какой смысл придумывать правила конфигурирования файрволла, транслируемые в другие правила? Да, есть смысл в диалоговой (не обязательно GUI) конфигурялке. Но не набор же правил ей подсовывать, это можно и с iptables сделать! 2. Никакой конфигуратор, работающий через iptables, не обеспечит бОльшей гибкости, чем используемый инструмент. Для бОльшей гибкости надо работать с ядром (iproute2).

> Повторю некоторые сообщения, но... 1. Какой смысл придумывать правила конфигурирования файрволла, транслируемые в другие правила?

Такой же смысл как и делать компилятор языка C. iptables можно сравнить с ассемблером - на нем можно сделать все что угодно, но это не очень удобно.

iproute2 это средство управления сетевым стеком и не имеет отношения к firewall'у