防火墙UDP Flood Dos / DDoS

最近我一直忍受着似乎是一个UDP查询洪水攻击。我正在寻找一种方法来阻止使用软件防火墙（如iptables）的攻击，这应该是可能的，如下所述。攻击的目标是在7777端口上运行的GTA圣安地列斯多人（SA-MP）服务器。通过向服务器提供查询（用于确定服务器的在线等级），攻击者能够导致服务器的真正用户拒绝服务。

我在OVH专用服务器上托pipe此服务器，其中包含“Anti-DDoS游戏”保护。他们没有检测到这个特殊的攻击。鉴于这是针对SA-MP服务器软件缺陷的低带宽攻击，我相信应该可以使用iptables等软件防火墙来阻止攻击。

我的服务器在Ubuntu 14.04 x64上运行。

攻击对networking或主机上其他服务的可用性没有影响，只影响SA-MP服务器的可用性。 SA-MP服务器的CPU使用率不受攻击影响。

请注意，以下pcap文件中的目标地址已更改为50.0.0.0。假定SA-MP服务器在50.0.0.0:7777上运行。这些文件只显示目的地为50.0.0.0:7777的stream量。

以下pcap文件是在攻击期间创build的： https ： //www.dropbox.com/s/5729k6vonqop7vh/attack.pcap

相应的匿名iptables日志：

Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.236.34.109 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=108 ID=37535 PROTO=UDP SPT=10365 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.228.244.109 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=108 ID=56141 PROTO=UDP SPT=26757 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.9.122.145 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=109 ID=28986 PROTO=UDP SPT=34861 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.12.137.119 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=112 ID=48843 PROTO=UDP SPT=26837 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.41.70.162 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=107 ID=45760 PROTO=UDP SPT=51292 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.12.97.62 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=107 ID=33629 PROTO=UDP SPT=16468 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.245.87.139 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=108 ID=61928 PROTO=UDP SPT=41088 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.203.14.22 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=108 ID=27207 PROTO=UDP SPT=57344 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.225.52.188 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=111 ID=13336 PROTO=UDP SPT=43057 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.82.59.154 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=106 ID=56663 PROTO=UDP SPT=59536 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.40.3.89 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=106 ID=51704 PROTO=UDP SPT=57477 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.104.10.111 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=109 ID=46872 PROTO=UDP SPT=51380 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.4.49.184 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=108 ID=30226 PROTO=UDP SPT=16636 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.38.178.54 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=108 ID=4646 PROTO=UDP SPT=35017 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.139.77.54 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=108 ID=23920 PROTO=UDP SPT=57421 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.104.123.34 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=109 ID=52328 PROTO=UDP SPT=34833 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.179.166.24 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=112 ID=12342 PROTO=UDP SPT=10357 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.75.214.181 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=109 ID=51967 PROTO=UDP SPT=8220 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.99.5.153 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=107 ID=32396 PROTO=UDP SPT=51236 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.95.125.95 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=106 ID=23852 PROTO=UDP SPT=16509 DPT=7777 LEN=19 Sep 6 19:20:35 sonic kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff SRC=177.138.137.71 DST=50.0.0.0 LEN=39 TOS=0x00 PREC=0x00 TTL=107 ID=64385 PROTO=UDP SPT=43176 DPT=7777 LEN=19

以下pcap文件显示正常stream量： https : //www.dropbox.com/s/dc05y54sru0c57u/normal.pcap

意见

恶意的UDP数据包长度为19，包含string“SAMP3”
普通数据包的长度可以是19，但是不包含“SAMP3”
恶意报文全部来自177.0.0.0/8

我有空路由177.0.0.0/8没有成功。这种解决scheme在任何情况下都是不可行的，因为它可能会拒绝对真实用户的访问。

以下尝试限制接受数据包的数量不成功 。规则要么不工作要么导致拒绝服务。

 #!/bin/bash iptables -F iptables -A INPUT -p udp -d 50.0.0.0 --destination-port 7777 -m string --string 'SAMP3' --algo bm -m limit --limit 100/s -j ACCEPT iptables -A INPUT -p udp -d 50.0.0.0 --destination-port 7777 -m string --string 'SAMP3' --algo bm -j DROP exit 0

也不成功：

 #!/bin/bash iptables -F iptables -A INPUT -p udp -d 50.0.0.0 -s 177.0.0.0/8 --destination-port 7777 -j DROP exit 0

50.0.0.0将被服务器的IPv4 WAN地址replace。

如果您能提供任何有关stream量如何可能下降的见解，那将不胜感激。 stream量分析的经验非常有限。如果推荐，我会愿意使用iptables以外的软件。

由于服务器的源代码不可用，因此不可能实现应用层解决scheme。

提前致谢。

你正在处理SA-MP查询洪水，这是SA-MP社区中的一个已知问题，目前还没有任何方法可以阻止这种情况发生，我相信你已经熟悉了这个更新。然而，最近发生的基于同一洪水方法的攻击，却是以欺骗性的源地址为基础的，而开发者尚未解决。有一个用户做了这个修复，但他们不会释放源代码。

了解DDoS攻击的第一件事是，如果它到达你的服务器，任何事情都为时已晚。请确保你阅读这篇文章，因为它会给你一个更好的主意，你反对。

作为一个实际的build议，我会build议检查CloudFlare和Incapsula提供的服务。根据您的stream量，您可能有资格获得免费级别，如果没有，这是一个很好的起点。

更新：对不起，我错过了这不是一个网站，而是一个使用UDP的应用程序。首先根据最新的报道，networking游戏网站现在是DDoS攻击的主要目标。目的是赎金，所以如果你的应用程序产生任何收入，那么你可能需要与像Akamai，Verisign，F5等大公司交谈。他们有专门为保护游戏网站而devise的软件包，但它们并不便宜。