Назад | Перейти на главную страницу

Нужна помощь в проверке файла tcpdump для блокировки атаки

Мне нужна помощь, мой игровой сервер уже 2 дня подвергается атакам DoS. Атаки на полосу пропускания - не проблема, так как я использую OVH, и они отфильтровываются, но атакуются порты моего игрового сервера, что приводит к истечению времени ожидания серверов и отключению всех игроков.

Так что сначала это было легко, он атаковал пакетами одинаковой длины, 1062.

444 0.017859    159.208.182.160 192.95.55.2 UDP 1062    Source port: 53407  Destination     port: 27016
445 0.017902    14.87.205.89    192.95.55.2 UDP 1062    Source port: 22286  Destination    port: 27016
446 0.017907    68.191.26.190   192.95.55.2 UDP 1062    Source port: 48964  Destination port: 27016
447 0.017992    201.50.53.136   192.95.55.2 UDP 1062    Source port: 13001  Destination port: 27016
448 0.017993    58.15.28.176    192.95.55.2 UDP 1062    Source port: senip  Destination port: 27016

Итак, я просто сделал:

iptables -A INPUT -p udp --dport 27016 -m length --length 1062 -j DROP

Что сработало, мои серверы внезапно снова ожили. Это было примерно 1000-4000 КБ / с трафика.

Следующее, что вы знаете, он начинает отправлять трафик со скоростью 12 МБ / с, с которым я должен справиться, так как я использую гигабит, и что я сделал, потому что только атакованный сервер вышел из строя (есть 4 сервера, работающие на 4 разных IP-адресах. на том же сервере и другие были в порядке).

Я снова запустил tcpdump и еще кое-что. Все атаки длиной 1062, которые я блокировал ранее? Так что я как бы застрял здесь и не знаю, что делать.

Может кто-нибудь взглянуть на мой файл tcpdump и сказать, что я делаю не так и как я могу заблокировать эту атаку (или не могу)? Я бы действительно оценил это!

Мне трудно читать это с помощью wirehark, я пытался блокировать пакеты с длиной, шестнадцатеричным кодом и т.д., но все безуспешно.

http://www.mediafire.com/download/8xe7cvx33dlgwxx/ddos2.tar.gz

Спасибо!

Еще одна вещь, во время атаки мой dmesg выводит следующее:

[35126.217197] nf_conntrack: table full, dropping packet
[35144.702662] nf_conntrack: table full, dropping packet
[35147.513124] nf_conntrack: table full, dropping packet

Я уже пробовал такие вещи, как sysctl -w net.netfilter.nf_conntrack_max = 524280, но это, похоже, не имело никакого значения.

Спасибо.

Если вы не собираетесь применять NAT или фильтрацию на основе проверки с отслеживанием состояния, вам лучше не использовать отслеживание соединений. Вы можете отключить отслеживание подключений для каждого пакета, используя NOTRACK цель в raw стол. Это должно избежать table full сообщения, которые вы видите.

Подходящие правила могут выглядеть так:

-A PREROUTING -p udp --dport 27016 -j NOTRACK
-A OUTPUT -p udp --sport 27016 -j NOTRACK