Схема пути пакета в iptables

http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg

Может ли iptables приводить к потере пакетов на сервере?

Еще как может, особенно, если высокая нагрузка на сеть и включено много conntrack модулей у iptables.

Update: предположение не подтвердилось, потери все же на канале.

Мониторинг отброшенных / принятых соединений в iptables без dmesg

Стандартным способом узнать, какие именно соединения / пакеты принял iptables является цель -j LOG, которая выбрасывает их в кольцевой буфер ядра, dmesg. Но это крайне неудобно по двум причинам - замусоривается dmesg, где могут быть крайне важные и полезные сообщения от ядра, а также неудобно читать и следить за логом (да, есть klogd).

Тут нам на выручку приходит ULOG, позволяющий по netlink отправить сообщения о пропущенных / заблокированных пакетах в userspace, где их встретит демон.

Вот выдержка из мана по iptables:

This target provides userspace logging of matching packets. When this target is set for a rule, the Linux kernel willmulticast this packet through a netlink socket. One or more userspace processes may then subscribe to various multicast groups and receive the packets. Like LOG, this is a "non-terminating target", i.e. rule traversal continues at the next rule.

Самое важное во всем этом то, что ULOG является не детерминирующим правилом, то есть после -j ULOG пакет будет пропущен дальше и если Вы хотите таки его отбросить, нужно следующим правилом добавить -j DROP.

Мое правило, работу которого я хочу контролировать логом имеет вид:

-A OUTPUT -p tcp -m tcp --dport 25 -j DROP

Чтобы сначала пакеты зафиксировать в ULOG нужно перед ним добавить еще одно правило:

-A OUTPUT -p tcp -m tcp --dport 25 -j ULOG --ulog-prefix "SMTP25BLOCK" --ulog-cprange 0 --ulog-qthreshold 50
-A OUTPUT -p tcp -m tcp --dport 25 -j DROP

Ставим:

apt-get install -y ulogd

После установки ulogd создает два лога:

/var/log/ulog/ulogd.log - системный, хранит информацию о работе демона
/var/log/ulog/syslogemu.log - лог трафика, сюда как раз будут записываться прошедшие через ULOG пакеты

Запускаем:

/etc/init.d/ulogd start

Пробуем коннект наружу:

telnet mail.ru 25
Trying 217.69.128.45...
^C

Получаем один пакет, зафиксированный ULOG и один отброшенный:

iptables -nvL
Chain OUTPUT (policy ACCEPT 1546 packets, 2211K bytes)
1 60 ULOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 ULOG copy_range 0 nlgroup 1 prefix `SMTP25BLOCK' queue_threshold 50
1 60 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25

Вот и все, запись о нашей попытке запсиана в лог:

tail /var/log/ulog/syslogemu.log
Apr 14 21:48:19 v1 SMTP25BLOCK IN= OUT=eth0 MAC= SRC=xx.xx.xx.xx DST=yy.yy.yy.yy LEN=60 TOS=10 PREC=0x00 TTL=64 ID=29311 DF PROTO=TCP SPT=50089 DPT=25 SEQ=731105051 ACK=0 WINDOW=5840 SYN URGP=0

Ну вот и все :) Разве что у меня остался вопрос, как добавить сюда uid/gid приложения пытавшегося осуществить отправку. Но он, к сожалению, не решается в рамках ULOG, так как только у цели LOG есть ключик --log-uid, который как раз логгирует uid отправителя.

Простой скрипт для бана IP

vi /usr/bin/ban_ip.sh

#!/bin/sh

iptables -I INPUT -p tcp -s $1 --dport 80 -j DROP

chmod +x /usr/bin/ban_ip.sh

ban_ip.sh 11.22.33.44

Предоставление доступа OpenVZ контейнерам к NAT

Загружаем модуль на ноде:

modprobe iptable_nat

Открываем конфиг VE:

vi /etc/vz/conf/$VEID.conf

Ищем существующую строку либо добавляем сами строку (если строка уже была, то необходимо добавить последних три модуля в список, причем iptable_filter является обязательным, но указывается только в конфиге VE, но не глобальном):

IPTABLES="ip_tables iptable_filter iptable_nat"

Перезапускаем VPS:

vzctl restart $VEID

Защита от UDP флуда конкретного IP

iptables -A INPUT -p udp -d xx.xx.xx.xx -j DROP

iptables, забанить подсеть

iptables -I INPUT -s xx.xx.xx.xx/24 -j DROP

Переброс всего трафика на другой сервер средствами iptables

Активируем форвардинг в ядре:

echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p

И теперь вот таким правилом отправляем весь трафик с исходного сервера (aa.aa.aa.aa) на удаленный сервер (bb.bb.bb.bb):

iptables -t nat -I PREROUTING -p tcp -d aa.aa.aa.aa --dport 80 -j DNAT --to bb.bb.bb.bb

После этого трафик должен начать уходить наружу, о чем свидетельствуют счетчики в цепочке FORWARD iptables:

iptables -nvL | grep FORWARD
Chain FORWARD (policy ACCEPT 1430K packets, 69M bytes)

Более подробно можно посмотреть так:

iptables -t nat -nvL

Кстати, при этом даже не особо мощные сервера чувствуют себя просто чудесно:

0.3%hi, 1.3%si, 0.0%st

И теперь на принимающей стороне можем видеть резво бегущий трафик:

iptables -nvL | grep dpt:80
348K 17M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW

Полное обнуление правил раутинга можно провести вот так:

iptables -t nat -F

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

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

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

iptables -t nat -A POSTROUTING -j MASQUERADE

Для отладки всех приведенных извращений рекомендую юзать:

tcpdump -n port 80

основано на: http://www.simplehelp.net/2009/04/15/how-to-redirect-traffic-to-another-machine-in-linux/

Сбросить счетчики iptables

В iptables для каждой цепочки и каждого правила есть два счетчика - счетчик обработанных пакетов и счетчик пропущенного / заблокированного трафика. Их можно посмотреть командой:

iptables -nvL

Но иногда может потребоваться их обнулить, для этого используется команда:

iptables -Z

nf_conntrack: table full, dropping packet в dmesg

Чем чреваты такие записи? Потерей сетевых соединений, то есть те соединения, что не помещаются в таблицу для хранения статуса соединений будут просто-напросто сброшены, для клиента это, скорее всего, будет выглядеть как connection refused.

Имеем до:

# sysctl -a | grep conntrack_max
net.ipv4.netfilter.ip_conntrack_max = 65536
net.netfilter.nf_conntrack_max = 65536
net.nf_conntrack_max = 65536

Открываем конфиг ядра:

vi /etc/sysctl.conf

Вносим туда (все три выше указанных опции, как я понял, являются алиясами и изменяя один, изменяются все другие):

net.ipv4.netfilter.ip_conntrack_max=1548576

Применяем настройки:

sysctl -p

В итоге имеем увеличенное число отслеживаемых соединений:

sysctl -a | grep conntrack_max
net.ipv4.netfilter.ip_conntrack_max = 1548576
net.netfilter.nf_conntrack_max = 1548576
net.nf_conntrack_max = 1548576

iptables state INVALID

-m state -- state INVALID в man описывается так:

Where state is a comma separated list of the connection states to match. Possible states are INVALID
meaning that the packet could not be identified for some reason which includes running out of memory
and ICMP errors which don’t correspond to any known connection

Но в Интернетах пишут о них более понятно:

This packet is associated with no known connection. These packets should be dropped.

Так что приговор один:

iptables -I INPUT -m state --state INVALID -j DROP

Разрешаем соединения до SSH сервера

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

Защита от перебора паролей SSH посредством iptables

Модуль recent дает очень удобный способ защитить sshd от перебора ботами, вот отличная статья по его настройке: http://www.debian-administration.org/articles/187

Для тех, кто не ходит по ссылкам вот пример:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name ssh_secure --set
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name ssh_secure --update --seconds 60 --hitcount 4 -j DROP

Первое правило добавляет IP нового клиента в таблицу recent. Второе правило проверяет наличие IP в таблице recent, и в случае, если от указанного клиента было более 3 попыток соединения за последние 60 секунд отклонит его последующие попытки.

conntrack: максимальное число отслеживаемых и текущее использование

Максимальное:

# cat /proc/sys/net/netfilter/nf_conntrack_max
65536

В Центос:

cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
65536

Текущее использование:

# cat /proc/sys/net/netfilter/nf_conntrack_count
2363

В Центос:

cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
51749

ISPManager + Nginx + защита 8080 порта

iptables -A INPUT -p tcp -s ! реальный_ip_машины --dport 8080 -j DROP

Не делайте так!

vrt1:~# iptables -P INPUT DROP
vrt1:~#

не делайте так люди :)

Удобный просмотр счетчиков и правил iptables

iptables -nvL

Активация iptables на Debian при запуске

Данный способ НЕ рекомендован к использованию, рекомендую для запуска и конфигурации фаерволла использовать пакет: iptables-persistent.

В отличие от RedHat-like дистрибутивов, iptables в Debian не считается сервисом и вызывается скриптами поднятия сети и для его активации необходимо поставить ему флаг +x:

chmod +x /etc/network/if-up.d/iptables

Если же этого файла там нету, то его необходимо создать, вот его содержимое:

#!/bin/sh
/sbin/iptables-restore < /var/lib/iptables/rules

Конфиг iptables в Debian

Находится вот здесь:

/var/lib/iptables/rules

Необычно правда, что не в /etc, долго найти его не могу :(

OpenVZ + multiport

cat /etc/gentoo-release
Gentoo Base System release 1.12.13

При попытке использовать модуль multiport возникает проблема:

iptables -A drop-invalid -i venet0 -p tcp -m multiport --dports 100:150 -j DROP
FATAL: Could not load /lib/modules/2.6.18-128.2.1.el5.028stab064.8/modules.dep: No such file or directory
FATAL: Could not load /lib/modules/2.6.18-128.2.1.el5.028stab064.8/modules.dep: No such file or directory

Фиксица легко:

mkdir -p /lib/modules/2.6.18-128.2.1.el5.028stab064.8
depmod -a

И все:

iptables -A drop-invalid -i venet0 -p tcp -m multiport --dports 100:150 -j DROP

(с) http://forum.openvz.org/index.php?t=msg&goto=38107&