После детального анализа я собрал эти детали.
Я нахожусь под UDP Flood, который больше зависит от приложения. Я запускаю Game-Server, и злоумышленник наводняет меня запросом «getstatus», который заставляет GameServer отвечать, давая ответы на запрос, которые вызывают вывод на IP-адрес атакующего до 30 МБ / с и задержку сервера.
Вот детали пакета,
Пакет начинается с 4 байтов 0xff, а затем getstatus.
Теоретически пакет выглядит как "\ xff \ xff \ xff \ xffgetstatus"
Теперь, когда я пробовал множество вариантов iptables, таких как ограничение состояния и скорости, но они не работали. Ограничение скорости работает хорошо, но только когда сервер не запущен. Как только сервер запускается, кажется, что ни одно правило iptables не блокирует его.
У кого-нибудь еще есть больше решений? кто-то попросил меня связаться с провайдером и сделать это в сети / маршрутизаторе, но это выглядит очень странно, и я считаю, что они могут этого не делать, поскольку это также повлияет на других клиентов.
Отвечая на все эти ответы, я бы сказал:
Во-первых, это VPS, поэтому они не могут сделать это за меня. Во-вторых, меня не волнует, поступает ли что-то, но поскольку его приложение сгенерировано, должно быть решение уровня ОС для блокировки исходящих пакетов. По крайней мере, исходящие нужно остановить.
Во-вторых, это не Ddos, так как всего 400 кбит / с на входе генерируют 30 МБ / с на выходе из моего GameServer. Этого никогда не бывает в D-dos. В этом случае следует использовать решение на уровне провайдера / оборудования, но это другое. И да, запрет его IP-адреса останавливает поток исходящих пакетов, но у него гораздо больше IP-адресов, поскольку он подделывает свой оригинал, поэтому мне просто нужно что-то, чтобы заблокировать его автоматически.
Даже пробовал много брандмауэров, но, как вы знаете, они всего лишь интерфейсы для iptables, поэтому, если что-то не работает с iptables, что будут делать брандмауэры?
Это были правила, которые я пробовал,
iptables -A INPUT -p udp -m state --state NEW -m recent --set --name DDOS --rsource
iptables -A INPUT -p udp -m state --state NEW -m recent --update --seconds 1 --hitcount 5 --name DDOS --rsource -j DROP
Он работает для атак на неиспользуемые порты, но когда сервер прослушивает и отвечает на входящие запросы злоумышленника, он никогда не работает.
Хорошо, Том.Х, твои правила работали, когда я как-то так их изменил:
iptables -A INPUT -p udp -m length --length 1:1024 -m recent --set --name XXXX --rsource
iptables -A INPUT -p udp -m string --string "xxxxxxxxxx" --algo bm --to 65535 -m recent --update --seconds 1 --hitcount 15 --name XXXX --rsource -j DROP
Они работали около 3 дней очень хорошо, когда строка «xxxxxxxxx» была ограничена по скорости, блокировалась, если кто-то затопил, а также не влиял на клиентов. Но только сегодня я попытался обновить цепочку, чтобы попытаться удалить ранее заблокированный IP-адрес, поэтому мне пришлось очистить цепочку и восстановить это правило (iptables -X и iptables -F), некоторые клиенты уже были подключены к серверам, включая меня. Таким образом, восстановление правил сейчас также полностью заблокирует некоторые строки клиентов, в то время как некоторые из них не затронуты. Значит ли это, что мне нужно перезапустить сервер или почему еще это могло произойти, потому что в последний раз, когда правила работали, никто не был подключен?
Вы почти у цели, но вполне возможно, что вы занимались грузом чужой работы, возможно, из-за ограничения скорости ssh, не понимая этого. Учтите, что я не критикую вас: опираться на работы других людей - отличная идея в сообществе свободного программного обеспечения; но вы должны понимать, почему они сделали то, что сделали, чтобы правильно использовать это.
Я установил испытательный стенд, используя nc (netcat) для перенаправления UDP-трафика с машины с именем bill на машину с именем risby со следующими строками:
risby% nc -l -u 12345
bill% seq 1 10000000 | nc -u risby 12345
Это привело к очень быстро растущему списку чисел из netcat risby, очень похожему на флудинг команд, который у вас был.
Но когда я создал два новых правила для iptables risby, которые фильтровали только UDP-трафик на порт 12345 без оглядки на состояние, все работало нормально:
iptables -I INPUT 1 -p udp --dport 12345 -m recent --set --name ddos
iptables -I INPUT 2 -p udp --dport 12345 -m recent --rcheck --seconds 1 --hitcount 5 --name ddos -j DROP
Когда я повторно запустил netcats, первые несколько пакетов от bill прошли через risby, и числа быстро выросли до примерно 1800, но затем он полностью остановился, и дальнейший трафик от bill не поступал.
Обратите внимание, что очень важно, чтобы эти правила были рано в вашей цепочке INPUT iptables, поэтому я вставил их в строки 1 и 2 соответственно.
редактировать:
Увеличьте скорость и потребуйте, чтобы она поддерживалась дольше; возможно --seconds 10 --hitcount 50? В конце концов вы достигнете порога, при котором затронуты несколько законных клиентов, но DDoS все еще будет существенно ограничен. Обратите внимание, что в этом типе дросселирования уровня 3 всегда возможен дружественный огонь; мой собственный ssh-сервер ограничивает количество новых подключений двумя на окно 60 секунд, что делает повторные scps довольно медленными. Но это цена, которую я готов заплатить, и чтобы добиться большего, требуется регулирование уровня 4, что означает, что приложение должно поддерживать регулирование. iptables здесь не поможет.
Отмечу что --hitcount не может принимать значение выше, чем ip_pkt_list_tot параметр модуля ядра xt_recent, и если значение превышено, во время создания правила выдается ошибка:
[root@risby scratch]# iptables -A INPUT -p udp -m recent --rcheck --seconds 1 --hitcount 50 --name ddos -j DROP
iptables: Invalid argument. Run `dmesg' for more information.
Но это значение может быть установлено до 255 во время вставки модуля. Следуя предложениям в этой записи блога, можно перезагрузить модуль, явно задав параметр:
[root@risby scratch]# rmmod xt_recent
[root@risby scratch]# modprobe xt_recent ip_pkt_list_tot=100
[root@risby scratch]# iptables -A INPUT -p udp -m recent --rcheck --seconds 1 --hitcount 50 --name ddos -j DROP
[root@risby scratch]#
Обратите внимание, как --hitcount 50 больше не вызывает ошибок. Возможно, вам потребуется промыть INPUT цепь (iptables -F INPUT) и любые другие цепочки, использующие recent модуль, прежде чем вы сможете удалить и снова вставить xt_recent модуль.
используйте tcpdump, чтобы получить пакетный дамп трафика.
tcpdump -s0 -w somefile.tcp proto udp and port NN and host www.xxx.yyy.zzz
проверьте пакеты в wirehark на предмет соответствия байтовой строке;
создать правило iptables со строкой для поиска строки протокола приложения, чтобы разрешить определенное количество этих пакетов в секунду, а затем отбросить остальные эти пакеты
iptables -I INPUT -p udp --dport NN -m string --algo bm \
--hex-string "|ff ff ff ff 67 65 74 73 74 61 74 75 73|" \
-m limit --limit 1/second -j ACCEPT
iptables -I INPUT -p udp --dport NN -m string --algo bm \
--hex-string "|ff ff ff ff 67 65 74 73 74 61 74 75 73|" -j DROP
ему повезло, что это udp, потому что он менее ресурсоемкий для сопоставления в модуле netfilter ...
предостережения в том, что вы собираетесь блокировать все запросы getstatus, если вы не можете найти какой-либо другой фильтр только для этого источника, и вам придется немного поработать в Википедии, чтобы выработать правильное шестнадцатеричное представление вашей строки соответствия
Свяжитесь с вашим провайером и попросите заблокировать трафик на маршрутизаторе.
Это не повлияет на других клиентов, так как они будут принимать во внимание место назначения пакетов (= ваш сервер).
Любые iptables или другие локальные подходы не будут решением, так как пакеты нужно обрабатывать в любом случае, чтобы они повлияли на ваш сервер.
Вы не думали о бане его IP (если он не подделывает его)? То, что вы испытываете, известно как отказ в обслуживании. Предлагаю вам попробовать OSSEC. Это может помочь заблокировать IP-адрес, который использует злоумышленник.