FastNetMon

Показаны сообщения с ярлыком iptables. Показать все сообщения
Показаны сообщения с ярлыком iptables. Показать все сообщения

среда, 8 сентября 2010 г.

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

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

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

среда, 14 апреля 2010 г.

Мониторинг отброшенных / принятых соединений в 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 отправителя.

воскресенье, 7 марта 2010 г.

Предоставление доступа 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

суббота, 16 января 2010 г.

Переброс всего трафика на другой сервер средствами 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/

понедельник, 11 января 2010 г.

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

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

iptables -nvL


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

iptables -Z

суббота, 9 января 2010 г.

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

пятница, 8 января 2010 г.

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

четверг, 7 января 2010 г.

Защита от перебора паролей 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

четверг, 31 декабря 2009 г.

Активация 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, долго найти его не могу :(

суббота, 26 декабря 2009 г.

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&