Цитата(svgr @ 9.1.2015, 19:25)

Единственное с чем стОит играться - это отдельные ли IP мониторить или подсети, ибо в случаи с ботнетом - количество IP всё равно ограничено, а в случаи спуфинга можно почти любой IP выдумать, какой вздумается.
Ну, раз при спуфинге можно подставить любой ип, то явно не стоит делать отслеживание на уровне ипшников. В таком случае точно памяти не напасешься.
Цитата(svgr @ 9.1.2015, 19:25)

UPD: можно даже не сортированный. Hashtable подойдёт. В цикле оббегать в поисках "превышения скорости" и всё.
Идея правильная, правда есть одно НО. Что будет, когда долбанут спуфом не с десятка /24 подсетей, а со всего 0.0.0.0/0?
А вот что будет:

Ну, почти 800 мегабайт на процесс. Хотя можно, конечно, надеяться, что такого не будет.
Цитата(svgr @ 9.1.2015, 19:25)

Вторая проблема на все 100% в HLDS'е. Просто если так рассуждать, то valve ни в чём не виноват. Это "лошары", проектировавшие udp просчитались. Не конструктивный подход.
UDP спроектирован нормально. Об амплификации должны думать те, кто проектируют протоколы на базе UDP. Если вам имя виновного надо, то оно есть у меня - это Джон Кармак. Куча современных шутеров унаследовали сетевой протокол (вместе с проблемой амплификации) от Quake.
Проблема глубже, чем кажется
Цитата(svgr @ 9.1.2015, 19:25)

Нет, не кажется. Лучше пусть они сидят там в бане во время атаки, чем постоянно (не знаю у кого как, а я все "нашумевшие подсетки" в drop на роутере загнал. И уберу либо когда появится заплатка, либо когда в следующий раз вспомню про существование роутера. Эти сегменты сети для меня безынтересны. Но тут пусть каждый сам выбирает. Кому "голый стим", а кому и "последний dproto с настроенным по максимуму автобаном".
А вот игроки из безынтерсных вам подсетей хотят играть. И если такая мега-защита будет вшита в модуль, который на каждом втором сервере стоит, играть они не смогут.
Цитата(svgr @ 9.1.2015, 19:25)

Согласен, идея далеко не best. Но лучше придумать хоть какое-то решение (а оно в любом случаи будет костылевидным), чем сложить ручки, взять свечку и молча лежать, пока земелькой в яме закидывают.
Решение проблемы №1: iptables -t raw -A PREROUTING -p udp -j NOTRACK + iptables -t raw -A OUTPUT -p udp -j NOTRACK
Решение проблемы №2: Спасение утопающих - дело рук самих утопающих. Но если утопающих таки жалко, можно попробовать hashlimit-ом или recent лишние пакетики по /24 подсетям срезать
Цитата(svgr @ 9.1.2015, 19:25)

А зачем нам вообще куда-то таскать пакеты? hlds получил их, проанализировал, если счёл нужным, определённые проигнорировал.
Вариант отброса пакета иптаблесом:
Обработка прерывания от сетевухи => фильтрация в netfilter => пакет дропается
Вариант отброса пакета хлдсом:
Обработка прерывания от сетевухи => фильтрация в netfilter => добавляем пакет в очередь пакетов в сокете => пытаемся разбудить процесс хлдса => процесс вызывает recvfrom() => копируем содержимое пакета и инфу о нем в userspace память => hlds отбрасывает пакет
Дроп пакетов в ядре всегда будет эффективнее.
Цитата(svgr @ 9.1.2015, 19:25)

Костыли в роутерах и на iptables все, кому было надо, уже подставили. Вопрос не в этом. Вопрос в том, что сейчас тулзу оттестировали, поняли, что она работает.
Амплификацию с игровых серверов юзают уже года 3 точно. Но всем было насрать до января 2015 года, пока не начали долбить целые подсети.
Цитата(svgr @ 9.1.2015, 19:25)

А вот потом атака может всплыть вновь. И она уже может быть повёрнута против любого из нас, т.к. принцип действия разжеван, а способ действия идеален для атак на "себе подобных".
Я думаю что 80% трафика срежется блокированием udp source портов 27015:27020. Для клиентов геймхостингов делать вообще ничего не надо будет (ТП всё сделает сама), а тем кто арендует дедик, достаточно сделать один звонок в саппорт дц. Хоумхостинги, извините, но вы в жопе :)
Отредактировал: berq, - 9.1.2015, 19:23