HOWTO: Iptables для новичков

[dr.Faust]

Для эффективной защиты от брута необходимо дополнительно ограничить количество попыток ввода пароля.

да... кол-во попыток ввода пароля для SSH задается в параметре MaxAuthTries, файл /etc/ssh/sshd_config

Оно по дефолту ограничено 3.

Вобщем наверно можно промежуточное резюме?
Тогда вот.
TODO:
1 Ограничить флуд в лог во всех правилах логирования.
2 Убрать логирование INVALID пакетов TCP.
3 Добавить защиту от подмены IP в цепочку TCP_BAD_PACKETS
4 Убрать в цепочке UDP_BAD_PACKETS правило --dport 135:139 -j DROP (лишнее)

Спорные моменты:
1 Добавление правил от различного рода атак.
    Их наверное надо собрать в кучу - я ведь небольшой специалист (Спасибо что помогаете и подсказываете мне) по безопасности, о некоторых атаках я просто не знаю... А потом сделать опциональнымы в отдельном блоке, для неикушённых пользователей написать - типа - не знаете - не трожьте.

2 Вынесение всех правил для BAD пакетов в одну цепочку.
       Изначально я так и сделал, а потом распаралелил, и вот для чего - чтобы пакеты не проходили лишнии правила - всё равно потом пакеты раскидываются по типам, так зачем гнать ICMP и UDP пакеты через правила для TCP и наоборот.

Непонятные мне моменты:
1 Какое можно придумать правило от брутфорса? Что-то с модулем recent? Оно же тормозить будет весь траф и машина будет вся на netfilter пахать....
2 И всё таки FORWARD... Да, я понимаю что это не наш трафик - он идёт через нашу машину. НО! Он же идёт к компам в нашей сети. Это же братский тафик - зачем его фильтровать? Внешним он быть не может из-за NAT - значит он полностью инициирован братьями нашими меньшими... Ну я так думаю. Чего-то неправильно?

[AnrDaemon]

Для эффективной защиты от брута необходимо дополнительно ограничить количество попыток ввода пароля.

да... кол-во попыток ввода пароля для SSH задается в параметре MaxAuthTries, файл /etc/ssh/sshd_config

Оно по дефолту ограничено 3.

Проверь, ты будешь удивлён...

Вобщем наверно можно промежуточное резюме?
Тогда вот.
TODO:
1 Ограничить флуд в лог во всех правилах логирования.
2 Убрать логирование INVALID пакетов TCP.
3 Добавить защиту от подмены IP в цепочку TCP_BAD_PACKETS
4 Убрать в цепочке UDP_BAD_PACKETS правило --dport 135:139 -j DROP (лишнее)

Спорные моменты:
1 Добавление правил от различного рода атак.
    Их наверное надо собрать в кучу - я ведь небольшой специалист (Спасибо что помогаете и подсказываете мне) по безопасности, о некоторых атаках я просто не знаю... А потом сделать опциональнымы в отдельном блоке, для неикушённых пользователей написать - типа - не знаете - не трожьте.

2 Вынесение всех правил для BAD пакетов в одну цепочку.
       Изначально я так и сделал, а потом распаралелил, и вот для чего - чтобы пакеты не проходили лишнии правила - всё равно потом пакеты раскидываются по типам, так зачем гнать ICMP и UDP пакеты через правила для TCP и наоборот.

Лучше раскидывать по частоте.
И лучше с этим в какой-нибудь другой топик уже съехать.

Непонятные мне моменты:
1 Какое можно придумать правило от брутфорса? Что-то с модулем recent? Оно же тормозить будет весь траф и машина будет вся на netfilter пахать....

Я же сказал, что искать... Там и готовый рецепт, и ссылки на более подробные инструкции.

2 И всё таки FORWARD... Да, я понимаю что это не наш трафик - он идёт через нашу машину. НО! Он же идёт к компам в нашей сети. Это же братский тафик - зачем его фильтровать? Внешним он быть не может из-за NAT - значит он полностью инициирован братьями нашими меньшими... Ну я так думаю. Чего-то неправильно?

Это сильно зависит от структуры твоей сети. У меня на попечении две... ладно, три, считая домашнюю, сети. Везде стоят Linuxовые серваки, но насколько разные сети... В одной инет приходит прямо в сервер, и выходит на WiFi роутер и локалку. В другой наоборот, инет приходит на роутер, оттуда в локалку, но экранирован от неё настройкой подсетей. Дома вообще зоопарк - два инета, ADSL и PPPoE, все в одной сети, все (оба роутера и сервер) работают NAT'ом. Зоопарк в клиентах (ноуты, коммуникаторы, десктоп). На каждый случай свои рецепты даже разделения трафика. Про защиту надо говорить особо, это целая тема.

[alexxnight]

Вобщем наверно можно промежуточное резюме?
Тогда вот.
TODO:
...
4 Убрать в цепочке UDP_BAD_PACKETS правило --dport 135:139 -j DROP (лишнее)

я думаю, что можно оставить, без указания IP адресов:
iptables -A UDP_BAD_PACKETS -p udp --dport 135:139 -j DROP

Спорные моменты:
1 Добавление правил от различного рода атак.
    Их наверное надо собрать в кучу - я ведь небольшой специалист (Спасибо что помогаете и подсказываете мне) по безопасности, о некоторых атаках я просто не знаю... А потом сделать опциональнымы в отдельном блоке, для неикушённых пользователей написать - типа - не знаете - не трожьте.

Да, согласен, потом после составления основного скелета можно будет вставить цепочки защит от атак.

2 Вынесение всех правил для BAD пакетов в одну цепочку.
       Изначально я так и сделал, а потом распаралелил, и вот для чего - чтобы пакеты не проходили лишнии правила - всё равно потом пакеты раскидываются по типам, так зачем гнать ICMP и UDP пакеты через правила для TCP и наоборот.

Здесь 2 соображения:
1. Распараллелить пакеты по цепочкам и не гонять их по заведомо неподходящим правилам - это хорошо и это правильно.
2. Но, во избежание путаницы и удобочитаемости лучше, чтобы логически объединенные правила были в одном месте.

Я думаю, что можно и так и так... Вычислительных мощностей сейчас достаточно. Да и к тому же мы ограничиваем не весь трафик, а только попытки установить соединения, а это менее значительная часть трафика...

Непонятные мне моменты:
1 Какое можно придумать правило от брутфорса? Что-то с модулем recent? Оно же тормозить будет весь траф и машина будет вся на netfilter пахать....

Правило от брутфорса можно написать и с помощью модуля recent и hashlimit. Но, как я уже сказал, их лучше потом нацеплять на готовый скелет... В общем, потом напишу

2 И всё таки FORWARD... Да, я понимаю что это не наш трафик - он идёт через нашу машину. НО! Он же идёт к компам в нашей сети. Это же братский тафик - зачем его фильтровать? Внешним он быть не может из-за NAT - значит он полностью инициирован братьями нашими меньшими... Ну я так думаю. Чего-то неправильно?

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

И если резюмировать, то какая картина получается?

[dr.Faust]

Ну где-то примерно такая как под сполером.

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

# Generated by iptables-save v1.4.4 on Fri Mar 18 01:25:36 2011
*mangle
:PREROUTING ACCEPT [5:260]
:INPUT ACCEPT [7893:2790792]
:FORWARD ACCEPT [1218:356521]
:OUTPUT ACCEPT [4:848]
:POSTROUTING ACCEPT [9484:4915774]
COMMIT
# Completed on Fri Mar 18 01:25:36 2011
# Generated by iptables-save v1.4.4 on Fri Mar 18 01:25:36 2011
*filter
:INPUT DROP [4:208]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4:848]
:BAD_PACKETS - [0:0]
:ICMP_PACKETS - [0:0]
:SAFETY_TRACE - [0:0]
:TCP_PACKETS - [0:0]
:UDP_PACKETS - [0:0]
-A INPUT -j SAFETY_TRACE
-A INPUT -j BAD_PACKETS
-A INPUT -p tcp -j TCP_PACKETS
-A INPUT -p udp -j UDP_PACKETS
-A INPUT -p icmp -j ICMP_PACKETS
-A BAD_PACKETS -m conntrack --ctstate INVALID -j DROP
-A BAD_PACKETS -s 127.0.0.0/8 ! -i lo -j DROP
-A BAD_PACKETS -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -m limit --limit 3/min -j LOG --log-prefix "iptabler:new not syn:"
-A BAD_PACKETS -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j DROP
-A BAD_PACKETS -p udp -m udp --dport 113 -m limit --limit 3/min -j LOG --log-prefix "iptabler:new not syn:"
-A BAD_PACKETS -p udp -m udp --dport 113 -j REJECT --reject-with icmp-port-unreachable
-A BAD_PACKETS -f -j DROP
-A ICMP_PACKETS -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ICMP_PACKETS -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A ICMP_PACKETS -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A SAFETY_TRACE -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A SAFETY_TRACE -i lo -j ACCEPT
-A SAFETY_TRACE -s 192.168.8.0/24 -i wlan0 -j ACCEPT
-A TCP_PACKETS -p tcp -m tcp --dport 22 -j ACCEPT
-A UDP_PACKETS -p udp -m udp --sport 53 --dport 1024:65535 -j ACCEPT
-A UDP_PACKETS -p udp -m udp --dport 123 -j ACCEPT
-A UDP_PACKETS -p udp -m udp --sport 67:68 --dport 67:68 -j ACCEPT
COMMIT
# Completed on Fri Mar 18 01:25:36 2011
# Generated by iptables-save v1.4.4 on Fri Mar 18 01:25:36 2011
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -s 192.168.8.0/24 -o eth0 -j MASQUERADE
COMMIT
# Completed on Fri Mar 18 01:25:36 2011


Пользователь решил продолжить мысль 18 Марта 2011, 01:40:56:

Лучше раскидывать по частоте.

Э... это как?

И лучше с этим в какой-нибудь другой топик уже съеха

Написал модерам.

Значит FORWARD остаёстся сейчас открытым, если в конфиге указано, что мы НАТ - как в примере, иначе - DROP.
Правила блокирования собрал в одном месте - в принципе цепочек осталось гораздо меньше и теперь они читаемей (соглашусь - это логично - тут простота чтения важнее, чем производительность).

[AnrDaemon]

Наоборот вообще-то. Если NAT включен, то -P FORWARD DROP + правильные фильтры, если NAT выключен, то без разницы - до форварда ничего не дойдёт.

"По частосте" - первыми расположить правила, в которые попадёт (и уйдёт из цепочки по ACCEPT/DROP/REJECT/etc.) наибольшее количество пакетов, чтобы правила, расположенные после них, не замедляли работу системы.

[dr.Faust]

Наоборот вообще-то. Если NAT включен, то -P FORWARD DROP + правильные фильтры, если NAT выключен, то без разницы - до форварда ничего не дойдёт.

Логично, но тут вопрос как раз в правильных фильтрах. Мне лично в голову тут ничего не приходит...
Я ведь и писал раньше, что если нет форвардинга - смысл в DROP, а если он есть, то входящих пакетов там просто небудет. А что фильтровать в исходящем трафике я не представляю. (входящий и исходящий я имею ввиду по отношению к локальной сети)

"По частосте" - первыми расположить правила, в которые попадёт (и уйдёт из цепочки по ACCEPT/DROP/REJECT/etc.) наибольшее количество пакетов, чтобы правила, расположенные после них, не замедляли работу системы.

Понятно. Но ведь вроде так и есть. Нет?
Сначала пакет попадает в цепочку SAFETY_TRACE где пропускается подавляющая часть трафика.
Потом выбрасываем плохие пакеты и наконец разрешаем валидным пакетам установить соединение на разрешёных портах. Если это сделать раньше, не получится ли так, что соединение будет установлено плохим пакетом, например фрагментированным?

[AnrDaemon]

А что такого плохого во фрагментированном пакете? O.o

По правилам - вообще не читал, голова не тем занята.

[dr.Faust]

А что такого плохого во фрагментированном пакете? O.o

Ну как же - что бы пройти правило NEW без SYN...

По правилам - вообще не читал, голова не тем занята.

Понимаю...
Там меня вот такой вопрос волнует - в правиле от подмены адреса:

Код: [Выделить]

-p tcp --tcp-flags SYN,ACK SYN,ACK -m conntrack --ctstate NEW,INVALID -j REJECT --reject-with tcp-resetзачем  SYN и ACK? Почему не просто:

Код: [Выделить]

-p tcp --tcp-flags ACK SYN -m conntrack --ctstate NEW,INVALID -j REJECT --reject-with tcp-reset?

[AnrDaemon]

NEW и INVALID это два состояния...
Моя имха, должно быть достаточно

-p tcp -m conntrack --ctstate INVALID -j REJECT --reject-with tcp-reset

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

[dr.Faust]

Вот ещё проблемка выплыла - не загружаются правила после перезагрузки в 10.04 (в 10.10 всё нормально).
Сделано там так - правила сохраняются в исполняемый /etc/iptabler/iptabler.rules и на него делается ссылка /etc/network/if-pre-up.d/netfilter-rules

[AnrDaemon]

Link точно без точек в имени?
В файле строка загрузки присутствует? ("#! /sbin/iptables-restore")
И, у меня в if-up.d лежит, работает.

[dr.Faust]

Дык он же скриптом создается - должно быть всё одинаково.
Проверю конечно завтра всё ещё раз, но уже завтра. Сегодня точнее.

[alexxnight]

А что такого плохого во фрагментированном пакете? O.o

Ну как же - что бы пройти правило NEW без SYN...

Верно, есть такая разновидность атак

Там меня вот такой вопрос волнует - в правиле от подмены адреса:

Код: [Выделить]

-p tcp --tcp-flags SYN,ACK SYN,ACK -m conntrack --ctstate NEW,INVALID -j REJECT --reject-with tcp-resetзачем  SYN и ACK? Почему не просто:

Код: [Выделить]

-p tcp --tcp-flags ACK SYN -m conntrack --ctstate NEW,INVALID -j REJECT --reject-with tcp-reset?

--tcp-flags работает так: вначале через запятую указывается список флагов, которые нужно проверить, а затем, после пробела, указываются флаги, которые должны быть подняты (указываются также через запятую). Поэтому SYN,ACK SYN,ACK говорит о том, что нужно проверять флаги SYN,ACK и должны быть установлены SYN,ACK.

А если указать --tcp-flags ACK SYN - это значит что нужно проверять флаг ACK и установлен должен быть флаг SYN. Вобщем не логично...
Пользователь решил продолжить мысль 19 Марта 2011, 09:23:45:

NEW и INVALID это два состояния...
Моя имха, должно быть достаточно

-p tcp -m conntrack --ctstate INVALID -j REJECT --reject-with tcp-reset

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

Если речь идет о правиле защиты от spoofing, то
-p tcp --tcp-flags SYN,ACK SYN,ACK -m conntrack --ctstate NEW,INVALID -j REJECT --reject-with tcp-reset

Если интересно, спросите, объясню почему именно так

[AnrDaemon]

Думаю, я понял из вашего предыдущего объяснения.
ctstate=NEW для отказа в установлении новых кривых соединений, INVALID - для отказа в подмене адреса во время сессии.
У меня только вопрос, ESTABLISHED|RELATED сработает до или после INVALID?

[bubuntu-ru]

А так если
for a in /proc/sys/net/ipv4/conf/*/rp_filter;
do
echo 1 > $a
done