Показаны сообщения с ярлыком iptables. Показать все сообщения
Показаны сообщения с ярлыком iptables. Показать все сообщения
вторник, 19 октября 2010 г.
среда, 8 сентября 2010 г.
Может ли iptables приводить к потере пакетов на сервере?
Еще как может, особенно, если высокая нагрузка на сеть и включено много conntrack модулей у iptables.
Update: предположение не подтвердилось, потери все же на канале.
Update: предположение не подтвердилось, потери все же на канале.
среда, 14 апреля 2010 г.
Мониторинг отброшенных / принятых соединений в iptables без dmesg
Стандартным способом узнать, какие именно соединения / пакеты принял iptables является цель -j LOG, которая выбрасывает их в кольцевой буфер ядра, dmesg. Но это крайне неудобно по двум причинам - замусоривается dmesg, где могут быть крайне важные и полезные сообщения от ядра, а также неудобно читать и следить за логом (да, есть klogd).
Тут нам на выручку приходит ULOG, позволяющий по netlink отправить сообщения о пропущенных / заблокированных пакетах в userspace, где их встретит демон.
Вот выдержка из мана по iptables:
Самое важное во всем этом то, что ULOG является не детерминирующим правилом, то есть после -j ULOG пакет будет пропущен дальше и если Вы хотите таки его отбросить, нужно следующим правилом добавить -j DROP.
Мое правило, работу которого я хочу контролировать логом имеет вид:
Чтобы сначала пакеты зафиксировать в ULOG нужно перед ним добавить еще одно правило:
Ставим:
После установки ulogd создает два лога:
Запускаем:
Пробуем коннект наружу:
Получаем один пакет, зафиксированный ULOG и один отброшенный:
Вот и все, запись о нашей попытке запсиана в лог:
Ну вот и все :) Разве что у меня остался вопрос, как добавить сюда uid/gid приложения пытавшегося осуществить отправку. Но он, к сожалению, не решается в рамках ULOG, так как только у цели LOG есть ключик --log-uid, который как раз логгирует uid отправителя.
Тут нам на выручку приходит 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 отправителя.
среда, 17 марта 2010 г.
Простой скрипт для бана 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
воскресенье, 7 марта 2010 г.
Предоставление доступа OpenVZ контейнерам к NAT
Загружаем модуль на ноде:
Открываем конфиг VE:
Ищем существующую строку либо добавляем сами строку (если строка уже была, то необходимо добавить последних три модуля в список, причем iptable_filter является обязательным, но указывается только в конфиге VE, но не глобальном):
Перезапускаем VPS:
modprobe iptable_nat
Открываем конфиг VE:
vi /etc/vz/conf/$VEID.conf
Ищем существующую строку либо добавляем сами строку (если строка уже была, то необходимо добавить последних три модуля в список, причем iptable_filter является обязательным, но указывается только в конфиге VE, но не глобальном):
IPTABLES="ip_tables iptable_filter iptable_nat"
Перезапускаем VPS:
vzctl restart $VEID
пятница, 5 марта 2010 г.
понедельник, 25 января 2010 г.
суббота, 16 января 2010 г.
Переброс всего трафика на другой сервер средствами iptables
Активируем форвардинг в ядре:
И теперь вот таким правилом отправляем весь трафик с исходного сервера (aa.aa.aa.aa) на удаленный сервер (bb.bb.bb.bb):
После этого трафик должен начать уходить наружу, о чем свидетельствуют счетчики в цепочке FORWARD iptables:
Более подробно можно посмотреть так:
Кстати, при этом даже не особо мощные сервера чувствуют себя просто чудесно:
И теперь на принимающей стороне можем видеть резво бегущий трафик:
Полное обнуление правил раутинга можно провести вот так:
Но я не особенно понимаю, достаются ли после этого пакеты на указанный порт сервисам, что работают на исходном сервере. Поэтому рекомендую их либо потушить либо снять с атакуемого порта.
При этом, на сервере-получателе будут отображаться адреса клиентов, а не адрес исходного сервера.
Также опционально можно включить маскарадинг, который как раз будет отображать айпи сервера источника:
Для отладки всех приведенных извращений рекомендую юзать:
основано на: http://www.simplehelp.net/2009/04/15/how-to-redirect-traffic-to-another-machine-in-linux/
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
Для тех, кто не ходит по ссылкам вот пример:
Первое правило добавляет IP нового клиента в таблицу recent. Второе правило проверяет наличие IP в таблице recent, и в случае, если от указанного клиента было более 3 попыток соединения за последние 60 секунд отклонит его последующие попытки.
Для тех, кто не ходит по ссылкам вот пример:
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
среда, 6 января 2010 г.
вторник, 5 января 2010 г.
четверг, 31 декабря 2009 г.
Активация iptables на Debian при запуске
Данный способ НЕ рекомендован к использованию, рекомендую для запуска и конфигурации фаерволла использовать пакет: iptables-persistent.
В отличие от RedHat-like дистрибутивов, iptables в Debian не считается сервисом и вызывается скриптами поднятия сети и для его активации необходимо поставить ему флаг +x:
Если же этого файла там нету, то его необходимо создать, вот его содержимое:
В отличие от RedHat-like дистрибутивов, iptables в Debian не считается сервисом и вызывается скриптами поднятия сети и для его активации необходимо поставить ему флаг +x:
chmod +x /etc/network/if-up.d/iptables
Если же этого файла там нету, то его необходимо создать, вот его содержимое:
#!/bin/sh
/sbin/iptables-restore < /var/lib/iptables/rules
Конфиг iptables в Debian
Находится вот здесь:
Необычно правда, что не в /etc, долго найти его не могу :(
/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&
Подписаться на:
Сообщения
(
Atom
)