Стич Опубликовано 1 ноября, 2016 (изменено) · Жалоба На Linux NAT машине периодически получаю conntrack table full nf_conntrack_tcp и udp timeoutы уже настроены. ip_conntrack_max и hashsize выставлены Подскажите как наиболее производительней ограничить количество записей в conntrack на ip? Ну и цифры что бы юзеру комфортно было. В сети нашёл три варианта. Вариант 1. iptables -p tcp -m state --state NEW -m connlimit --connlimit-above 2000 -j REJECT iptables -p udp -m state --state NEW -m connlimit --connlimit-above 2000 -j REJECT Вариант 2. -A FORWARD -s 172.16.0.0/12 -p udp -m state --state NEW -m recent --set --name UDPFLOOD --rsource -A FORWARD -s 172.16.0.0/12 -p udp -m state --state NEW -m recent --update --seconds 10 --hitcount 200 --name UDPFLOOD --rsource -j DROP -A FORWARD -s 172.16.0.0/12 -p tcp -m state --state NEW --dport 1024:65535 -m recent --set --name TCPFLOOD --rsource -A FORWARD -s 172.16.0.0/12 -p tcp -m state --state NEW --dport 1024:65535 -m recent --update --seconds 10 --hitcount 200 --name TCPFLOOD --rsource -j DROP Вариант 3. CONNS=20 $IPT -N NEWCONNLIMITUDP $IPT -A NEWCONNLIMITUDP -m hashlimit --hashlimit ${CONNS}/sec --hashlimit-burst ${CONNS} --hashlimit-mode srcip --hashlimit-name connlimit_udp -j RETURN $IPT -A NEWCONNLIMITUDP -j DROP $IPT -N NEWCONNLIMITTCP $IPT -A NEWCONNLIMITTCP -m hashlimit --hashlimit ${CONNS}/sec --hashlimit-burst ${CONNS} --hashlimit-mode srcip --hashlimit-name connlimit_tcp -j RETURN $IPT -A NEWCONNLIMITTCP -j DROP $IPT -A FORWARD -i ppp+ -p udp -m state --state NEW -j NEWCONNLIMITUDP $IPT -A FORWARD -i ppp+ -p tcp --dport 1024:65535 -m state --state NEW -j NEWCONNLIMITTCP Изменено 1 ноября, 2016 пользователем Стич Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 1 ноября, 2016 · Жалоба может быть стоит увеличить максимальный размер conntrack? Если поставите 64bit ядро, то проблема размера conntrack Вас вообще не должна волновать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Стич Опубликовано 1 ноября, 2016 (изменено) · Жалоба может быть стоит увеличить максимальный размер conntrack? Если поставите 64bit ядро, то проблема размера conntrack Вас вообще не должна волновать. Уже увеличено и таймауты выставлены, ядро 64 бит, память 2Гига(увеличить нет возможности да и это путь в никуда) Но появляется ддосер и не хватает памяти. echo 8388608 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max echo 8388608 > /sys/module/nf_conntrack/parameters/hashsize ## echo "60" > /proc/sys/net/netfilter/nf_conntrack_generic_timeout ##600 echo "15" > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_syn_sent #120 echo "30" > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_syn_recv #60 echo "900" > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established #7200 echo "30" > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_fin_wait #120 echo "20" > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_close_wait #60 echo "30" > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_last_ack #30 echo "30" > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_time_wait #120 echo "10" > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_close #10 echo "30" > /proc/sys/net/netfilter/nf_conntrack_udp_timeout #30 echo "45" > /proc/sys/net/netfilter/nf_conntrack_udp_timeout_stream #180 echo "10" > /proc/sys/net/netfilter/nf_conntrack_icmp_timeout #30 Интересует как правильно и эфективно ограничивать колличество записей так что бы не упасть от внутренгей или внешней атаки на conntrack Изменено 1 ноября, 2016 пользователем Стич Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dignity Опубликовано 2 ноября, 2016 · Жалоба Противостояние DDoS+ Iptables NAT (conntrack) + тазик - это фантастика. Попробуйте без Conntrack. http://linux-ip.net/html/nat-stateless.html - понимаю, что это не совсем то, что Вы хотите, но в вашей схеме можно только резать источники по количеству инициализаций TCP сессий. http://unix.stackexchange.com/questions/139285/limit-max-connections-per-ip-address-and-new-connections-per-second-with-iptable - типа так или просто скрипт, который смотрит new в tcpdump и блочит злодеев. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Morbid Опубликовано 2 ноября, 2016 · Жалоба Ну мы конечно не лочим злодеев автоматический, но скриптом выясняем "вредителей" (анализ и подсчет текущих сессий в conntrack -L), и подсвечиваем их в мониторинге, а далее уже принимаем решение блочить или нет. В целом ни кто не мешает это сделать автоматический, при необходимости. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Стич Опубликовано 2 ноября, 2016 (изменено) · Жалоба На Противостояние DDoS+ Iptables NAT (conntrack) + тазик - это фантастика. Попробуйте без Conntrack. http://linux-ip.net/...-stateless.html - понимаю, что это не совсем то, что Вы хотите, но в вашей схеме можно только резать источники по количеству инициализаций TCP сессий. У кого нибудь есть в продакшене Stateless NAT? И смысл в нем тогда лучше просто public каждому раздать. мы конечно не лочим злодеев автоматический, но скриптом выясняем "вредителей" (анализ и подсчет текущих сессий в conntrack -L), и подсвечиваем их в мониторинге, а далее уже принимаем решение блочить или нет. В целом ни кто не мешает это сделать автоматический, при необходимости. Может лучше правило: iptables -p tcp -m connlimit --connlimit-above 10000 -j REJECT Как я понял лекарства другого нет Изменено 2 ноября, 2016 пользователем Стич Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dignity Опубликовано 3 ноября, 2016 · Жалоба И смысл в нем тогда лучше просто public каждому раздать. Мне кажется, что если используется аналог ISG, то вполне себе и stateless можно, то есть при выходе клиента в сеть ему выделяется некая трансляция. Я слышал ранее версию, что в ЧНН online не более 30% (хотя мне кажется, что с пришествием цифровых технологий, сейчас уже не так все). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 3 ноября, 2016 · Жалоба Я слышал ранее версию, что в ЧНН online не более 30% (хотя мне кажется, что с пришествием цифровых технологий, сейчас уже не так все) Сейчас в онлайне круглосуточно 60% и выше, а в час пик цифра постепенно стремится к 100%. У всех роутеры, смартТВ, боксы и т.п. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Стич Опубликовано 3 ноября, 2016 · Жалоба Я думаю в stateless будут проблемы с разными протоколами так как helper'ов нету. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yazero Опубликовано 3 ноября, 2016 (изменено) · Жалоба хорошую тему поднял. 1)вот мои попытки ограничить абонента на брасе(хочу убрать conntrack, но все никак) и NAT. в случае ddos не помогает. т.к. абонент генерит syn бесконечно. пробовал для TCP -j TARPIT разницы не заметил. т.е. на порту очень много drop пакетов во время ddos и сервер генерит много прерывайни cat /proc/interrupts. пробовал играться с ethtool -c rx-usecs iptables $IPT -A FORWARD -s xx.xx.xx/24 -p tcp -m state ---state NEW -m connlimit --connlimit-above 3000 --connlimit-mask 32 -j REJECT --reject-with tcp-reset $IPT -A FORWARD -s xx.xx.xx/24 -p udp -m state --state NEW -m connlimit --connlimit-above 3000 --connlimit-mask 32 -j REJECT 2) почему такой hashsize? Правило простое: hashsize = nf_conntrack_max / 8 ##ddos net.netfilter.nf_conntrack_tcp_timeout_close = 10 net.netfilter.nf_conntrack_tcp_timeout_close_wait = 10 net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 20 net.netfilter.nf_conntrack_tcp_timeout_last_ack = 20 net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20 net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 20 net.netfilter.nf_conntrack_tcp_timeout_time_wait = 10 недавно изменил параметр net.ipv4.tcp_syncookies=1 на 2 c данными правилами conntrack full давно не видел, сколько клиентов ? а у вас есть dump conntrack -L , какие состояния соединений преобладаю, какие таймеры ? 3) для ddos-ра с конкретного хоста в текущий момент прописал правило iptables -I FORWARD -s xx -p tcp -m conntrack --ctstate NEW -j DROP iptables -I FORWARD -s xx -p tcp -m conntrack --ctstate NEW -m limit --limit 60/s --limit-burst 20 -j ACCEPT iptables -I FORWARD -s xx -p tcp --tcp-flags RST RST -j DROP iptables -I FORWARD -s xx -p tcp --tcp-flags RST RST -m limit --limit 2/s --limit-burst 2 -j ACCEPT 4) тестирую fastnetmon он срабатывает и можно писать правила, вот часть dump TCP flows: 8 91.197.78.170:2167 < 216.251.17.21:23 44 bytes 1 packets 91.197.78.170:2167 < 177.109.25.32:23 40 bytes 1 packets 91.197.78.170:2167 < 134.90.238.153:23 40 bytes 1 packets 91.197.78.170:2167 < 185.107.224.202:23 40 bytes 1 packets 91.197.78.170:2167 < 186.94.128.76:2323 40 bytes 1 packets 91.197.78.170:46330 < 95.142.205.103:443 2113970 bytes 1418 packets 91.197.78.170:58182 < 220.121.86.143:23 52 bytes 1 packets 91.197.78.170:61824 < 52.0.252.246:4244 128 bytes 1 packets Outgoing TCP flows: 142 91.197.78.170:2167 > 116.30.107.0:23 44 bytes 1 packets 91.197.78.170:2167 > 68.68.32.1:23 44 bytes 1 packets 91.197.78.170:2167 > 170.10.71.2:23 44 bytes 1 packets 91.197.78.170:2167 > 207.149.127.2:23 44 bytes 1 packets 91.197.78.170:2167 > 178.129.134.4:23 44 bytes 1 packets 91.197.78.170:2167 > 17.88.189.5:23 44 bytes 1 packets 91.197.78.170:2167 > 41.247.220.6:23 44 bytes 1 packets 91.197.78.170:2167 > 133.0.4.12:23 44 bytes 1 packets 91.197.78.170:2167 > 27.247.224.13:23 44 bytes 1 packets 91.197.78.170:2167 > 36.115.58.15:23 44 bytes 1 packets 91.197.78.170:2167 > 24.138.225.17:23 44 bytes 1 packets 91.197.78.170:2167 > 163.208.169.18:23 44 bytes 1 packets 91.197.78.170:2167 > 178.50.176.19:23 44 bytes 1 packets 91.197.78.170:2167 > 155.113.163.20:23 44 bytes 1 packets 91.197.78.170:2167 > 216.251.17.21:23 84 bytes 2 packets 91.197.78.170:2167 > 173.93.237.21:23 44 bytes 1 packets 91.197.78.170:2167 > 50.158.89.23:23 44 bytes 1 packets 91.197.78.170:2167 > 118.62.89.31:23 44 bytes 1 packets 91.197.78.170:2167 > 116.217.152.32:23 44 bytes 1 packets 91.197.78.170:2167 > 202.22.159.32:23 44 bytes 1 packets 91.197.78.170:2167 > 206.37.243.33:23 44 bytes 1 packets 91.197.78.170:2167 > 63.26.108.35:23 44 bytes 1 packets 91.197.78.170:2167 > 114.102.130.36:23 44 bytes 1 packets 91.197.78.170:2167 > 88.62.141.38:23 44 bytes 1 packets 91.197.78.170:2167 > 124.98.102.39:23 44 bytes 1 packets 91.197.78.170:2167 > 140.121.125.46:23 44 bytes 1 packets 91.197.78.170:2167 > 207.5.46.49:23 44 bytes 1 packets 91.197.78.170:2167 > 136.125.181.49:23 44 bytes 1 packets 91.197.78.170:2167 > 12.170.121.53:23 44 bytes 1 packets 5) также в нете есть скрипт conntrack_top им тоже мониторю. P.S. на устройствах cg-nat данная проблема решена. Изменено 3 ноября, 2016 пользователем yazero Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Стич Опубликовано 3 ноября, 2016 · Жалоба Можно про cg-nat подробнее, Вы имеете ввиду сторонние железно коробочные решения. Или конкретную программную реализацию под Linux. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yazero Опубликовано 3 ноября, 2016 (изменено) · Жалоба Да, я имел ввиду железно-коробрчные решения. Opensource еще не видел.На линуксе есть rdp.ru и uplink-spe.com. Изменено 3 ноября, 2016 пользователем yazero Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rm_ Опубликовано 3 ноября, 2016 · Жалоба периодически получаю conntrack table full Ну и цифры что бы юзеру комфортно было. На какой стадии у вас внедрение ipv6? Юзер и не заметил бы всей этой возни с натами и сопутствующих ему проблем, если бы у него вконтактик, пейсбук, ютуб, яндекс, гугл и майлру шли напрямую по v6. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 3 ноября, 2016 · Жалоба Яндексы и вконтакты нагрузки на коннтрак не создают, а вот торренты да всякие торрент-ТВ создают, и через v6 не лечатся. Основная масса пиров то v4-only.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Стич Опубликовано 4 ноября, 2016 · Жалоба ipv6 Даже не рассматривается. Давайте ipv6 обсуждать в другой теме не надо эту тему здесь забивать. Вас услышали. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 5 ноября, 2016 · Жалоба периодически получаю conntrack table full Ну и цифры что бы юзеру комфортно было. На какой стадии у вас внедрение ipv6? Юзер и не заметил бы всей этой возни с натами и сопутствующих ему проблем, если бы у него вконтактик, пейсбук, ютуб, яндекс, гугл и майлру шли напрямую по v6. Зато ощутил бы периодические проблемы с в6 на серверах вк Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fet4 Опубликовано 27 января, 2022 · Жалоба В 01.11.2016 в 12:11, Стич сказал: Вариант 1. iptables -p tcp -m state --state NEW -m connlimit --connlimit-above 2000 -j REJECT iptables -p udp -m state --state NEW -m connlimit --connlimit-above 2000 -j REJECT Вариант 2. -A FORWARD -s 172.16.0.0/12 -p udp -m state --state NEW -m recent --set --name UDPFLOOD --rsource -A FORWARD -s 172.16.0.0/12 -p udp -m state --state NEW -m recent --update --seconds 10 --hitcount 200 --name UDPFLOOD --rsource -j DROP -A FORWARD -s 172.16.0.0/12 -p tcp -m state --state NEW --dport 1024:65535 -m recent --set --name TCPFLOOD --rsource -A FORWARD -s 172.16.0.0/12 -p tcp -m state --state NEW --dport 1024:65535 -m recent --update --seconds 10 --hitcount 200 --name TCPFLOOD --rsource -j DROP Вариант 3. CONNS=20 $IPT -N NEWCONNLIMITUDP $IPT -A NEWCONNLIMITUDP -m hashlimit --hashlimit ${CONNS}/sec --hashlimit-burst ${CONNS} --hashlimit-mode srcip --hashlimit-name connlimit_udp -j RETURN $IPT -A NEWCONNLIMITUDP -j DROP $IPT -N NEWCONNLIMITTCP $IPT -A NEWCONNLIMITTCP -m hashlimit --hashlimit ${CONNS}/sec --hashlimit-burst ${CONNS} --hashlimit-mode srcip --hashlimit-name connlimit_tcp -j RETURN $IPT -A NEWCONNLIMITTCP -j DROP $IPT -A FORWARD -i ppp+ -p udp -m state --state NEW -j NEWCONNLIMITUDP $IPT -A FORWARD -i ppp+ -p tcp --dport 1024:65535 -m state --state NEW -j NEWCONNLIMITTCP Изменено 1 ноября, 2016 пользователем Стич На сегодня какой вариант используете для ограничения количества сессий ? Может есть что-то посовременней? connlimit серъезно кушает процессор, два другие варианта считают пакеты. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Стич Опубликовано 27 января, 2022 · Жалоба В 27.01.2022 в 13:19, fet4 сказал: На сегодня какой вариант используете для ограничения количества сессий ? Может есть что-то посовременней? connlimit серъезно кушает процессор, два другие варианта считают пакеты. Не ограничиваем, просто расширили conntrack Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 27 января, 2022 · Жалоба В 27.01.2022 в 16:19, fet4 сказал: На сегодня какой вариант используете для ограничения количества сессий ? Отключить линуховый conntrack и воспользоваться https://github.com/andrsharaev/xt_NAT По дефолту кол-во сессий зашито в модуль по 4к на тцп/юдп/ицмп, при желании, можно сделать параметром/ами модуля. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...