CSS и iptables

Вы тут, ребята, такую ахинею несёте, что я даже вспомнил свой пасс чтобы выступить в роли кэпа
1) rcon у сурса работает поверх тцп, правила у The_Razer как раз к этому и относятся
2) В рамках протокола UDP действительно нет понятия сессии, но
3) conntrack/netfilter отслеживает состояние удп сессий, и Пума дал ссылку на то, как именно он это делает
4) --connlimit-upto относится именно к сессиям, отслеживаемым коннтраком, поэтому смысл для удп он имеет

Если вдруг кто не знает, смотреть активные сессии контрака можно так 'cat /proc/net/ip_conntrack' или так 'conntrack -L'

berq, зацепило значит) ведь тема интересная на самом деле, относительно всего того, что тут не устают переспрашивать.
Согласен. НО определяет он его тупо по какому то флагу, который появляется при первом обмене пакетами и после "установки" соединения (estabilished) он пропадает. Далее не порядковых номерков, не флажков причастных к идентификации сессии нет. Т.е. если бы хотел задосить - я бы установил соединение и в этом одном соединение набросал бы столько, что он бы их заколебался обрабатывать. Понятное дело что там рейты и всё такое... но обрабатывать то он их всё равно хоть сколько нибудь будет.
С распределённой атакой это не поможет ни при каких обстоятельствах. Ну ты и сам знаешь, чего тут рассказывать. Нет смысла закрывать от udp флуда контролируя кол-во сессий. А вот кол-во пакетов в секунду на сессию наверное уже имеет смысл.
Да и не маловажный фактор - канал забивается в любом случае.

???!!
Сессия (по крайней мере удп) в коннтраке определяется по 4-м параметрам: адрес1(ip + port), адрес2(ip + port)
Сочетание адрес1 + адрес2 уникально для каждой сессии. Никаких флагов там нет.
Если приходит пакет, который не относится ни к одной из активных сессий, создается новая сессия в состоянии NEW.
Если через какоето время проходит ответный пакет, сессия переходит в состояние ESTABLISHED.
Если какое-то время в рамках сессии не было передано ни одного пакета, она удаляется.


Ну обрабатывать пакеты (т.е. принять их от сетевухи) всё равно придется в любом случае.

Касаемо заколебался обрабатывать - не заколебается. При твоем подходе (одна сессия - много пакетов), список флудящих ип быстренько забанится связкой hashlimit + ipset.
При этом подходе машинка с нормальной сетевухой (которая создает кучу очередей приёма), прожует хоть 2 Мппс такого флуда и даже не подавится.
Так что скорее это ты заколебаешься пакетики отправлять :))))

Теперь рассматриваем другой вариант - каждый пакетик открывает новую сессию. Например, это флуд с одного ип и постоянно разных сурс портов.
Обработка каждого такого пакета приходит к нехилым затратам в виде аллокации памяти под структуру сессии и ее инициализацию.
Флуд такого типа с ботнета (причем при небольших нагрузках на канал, например 100 ппс с бота), при отсутствии ограничения на кол-во сессий с ип(!), приводит к переполнению таблицы сессий - это означает, что нормальные клиенты не смогут достучаться до сервисов (т к сессии не создадутся). А это уже дениал оф сервис. Причем без зафлуживания всей входящей полосы :)

berq, ну я просто опустил адрес1 и адрес2 - на этот счёт и так всё понятно. я как раз говорил о забрасывание пакетами в рамках одной сессии. ну или 5, как в данном случае.
ну мы в общем об одном и том же говорим. с халфлимитом всё ясно. только в конкретно обсуждаемых правилах нет его. И ipset тоже нет. Соответственно данный набор правил не интересен. Как я и сказал ранее - кол-во пакетов в промежуток времени на сессию, уже другое дело + ну и в реджект/дроп (кстати а что тут предпочтительнее для тебя?). Просто сессии - мало.
Короче я с тобой согласен, можешь не строчить всё это!) уже всё что нужно рассказали. кому надо, тот сделает как нужно.

если я например выставлю принимать только 10 новых соединений в секунду на протокол юдп, то больше он не будет принимать!

coolman, спасибо кэп!
;)