我们在Linux机器上运行面向公众的递归DNS服务器。我们已经被用于DNS放大攻击。是否有建议的iptables
规则可以帮助减轻这些攻击?
显而易见的解决方案是将出站DNS数据包限制为一定的流量水平。但是我希望找到一些更聪明的东西,以使攻击仅能阻止流向受害IP地址的流量。
我一直在寻找建议,但它们似乎都是“不要运行面向公众的递归名称服务器”。不幸的是,我们陷入了这样的局面:如果我们不这样做,那么不容易改变的事情就会崩溃,这是由于十多年前在这些攻击成为问题之前做出的决定。
我们在Linux机器上运行面向公众的递归DNS服务器。我们已经被用于DNS放大攻击。是否有建议的iptables
规则可以帮助减轻这些攻击?
显而易见的解决方案是将出站DNS数据包限制为一定的流量水平。但是我希望找到一些更聪明的东西,以使攻击仅能阻止流向受害IP地址的流量。
我一直在寻找建议,但它们似乎都是“不要运行面向公众的递归名称服务器”。不幸的是,我们陷入了这样的局面:如果我们不这样做,那么不容易改变的事情就会崩溃,这是由于十多年前在这些攻击成为问题之前做出的决定。
Answers:
完全不是“我的问题”场景的表情,这实际上不是您的错,并且应该/可以通过采取适当的措施100%解决此问题,而不管它是“困难”还是“艰难”,而这将终止您的打开递归服务器。
逐步淘汰:告诉客户该服务器自X日期起将消失。在那之后,他们需要安装一个补丁程序(假设您有一个补丁程序)以阻止它使用您的DNS服务器。这一直都在做。系统管理员,网络管理员,技术支持人员,程序员?我们明白了;这种报废的事情一直在发生,因为它的标准操作步骤是让供应商/服务提供商/合作伙伴告诉我们在X日期后停止使用某些东西。我们并不总是喜欢它,但是它在IT中已成为现实。
您说您在当前设备上没有此问题,所以我假设您已通过固件更新或补丁解决了此问题。我知道您说过您不能触摸设备,但是可以触摸吗?我的意思是,如果他们让这些箱子基本上打电话回家给你,他们真的不能说对谁在做什么肛门他们的设备; 您可能对他们所了解的所有内容都有一个反向代理设置,所以为什么不让他们安装可解决此问题的补丁程序,或告诉他们使用自己的DNS服务器。您的设备肯定支持DHCP;我想不出一个网络设备(不管多大年纪/体弱/奇),其不。
如果您不能做到这一点,那么下一步是控制谁可以访问递归服务器:您说很难知道谁在使用它以及如何使用它,但是现在是时候确定一下并开始丢弃流量了。不合法的。
这些是“准军事/政府”组织,对吗?好吧,它们很可能是他们所拥有的合法netblock的一部分。这些设备不是动态IP背后的家用路由器。找出。与他们联系,说明问题以及如何通过不强制执行固件或产品更换的方式为他们节省很多钱,前提是只有他们能够确认设备将用于访问DNS服务器的netblock / IP地址。
这一直都在做:我有几个客户以这种方式将Extranet访问或HL7侦听器限制为医疗保健合作伙伴;它并不难为了让他们填写表格并提供IP和/或Netblock,我应该从中获得流量:如果他们想访问Extranet,则必须给我一个IP或子网。而且这很少是一个移动的目标,因此,这并不意味着每天都会被成百上千的IP更改请求所淹没:大型校园医院网络拥有自己的带有数百个子网和成千上万个主机IP的网络模块,通常会给我我应该期望的几个IP地址或子网;同样,这些笔记本电脑用户不是一直在校园里徘徊,那么为什么我会期望看到来自不断变化的IP地址的UDP源数据包?显然,我在这里只是一个假设,但我敢打赌,对于少于100台设备,它并不像您想象的那样多。是的,它将是一个冗长的ACL,是的,
如果由于某种原因,沟通渠道不畅通(或者某人太害怕或不愿意与这些旧设备所有者联系并正确执行此操作),则需要建立正常使用/活动的基准,以便制定其他一些有助于(但不能阻止)您参与DNS放大攻击的策略。
长时间运行tcpdump
应该可以对传入的UDP 53进行过滤,并可以在DNS服务器应用程序上进行详细日志记录。我还想开始收集源IP地址/网络块/ geoIP信息(您在美国的所有客户端吗?阻止其他所有内容),因为正如您所说,您没有添加任何新设备,而只是提供了旧版设备现有设备的服务。
这也将帮助您了解所请求的记录类型,哪个域,由谁以及何时进行:为使DNS放大功能按预期工作,攻击者需要能够向服务器请求大记录类型(1)。功能域(2)。
“大记录类型”:您的设备是否甚至需要TXT或SOA记录才能被递归DNS服务器解析?您可以指定哪些记录类型在您的DNS服务器上有效;我相信使用BIND和Windows DNS可能实现,但是您必须进行一些挖掘。如果您的DNS服务器响应SERVFAIL
任何TXT或SOA记录,并且该响应至少比预期的有效负载小一个数量级(或两个)。显然,您仍然是“问题的一部分”,因为被欺骗的受害者仍然会SERVFAIL
从服务器上获取那些响应,但是至少您没有对它们进行锤击,也许您的DNS服务器已从收集到的列表中“除名”僵尸程序会随着时间的推移而用于“不合作”。
「运作中的网域」:您可能只能将有效的网域加入白名单。我在强化的数据中心设置中执行此操作,其中服务器仅需要Windows Update,Symantec等即可运行。但是,您现在只是在减轻造成的损害:由于服务器仍然会对伪造的源IP作出响应,因此受害者仍然会受到服务器的轰炸NXDOMAIN
或SERVFAIL
响应。同样,Bot脚本也可能会根据结果自动更新其打开的服务器列表,因此这可能会导致服务器被删除。
我也将使用某种形式的速率限制,如其他人所建议的那样,在应用程序级别(即消息大小,每个客户端的请求限制)或防火墙级别(请参阅其他答案),但是同样,您将必须进行一些分析,以确保您不会杀死合法流量。
经过调整和/或培训(再次需要在此处提供基线)的入侵检测系统也应能够随时间推移按源或数量检测异常流量,但可能会定期进行保姆/调整/监视以防止误报和/或查看它是否实际上在阻止攻击。
归根结底,您必须怀疑所有这些努力是否值得,或者您是否应该坚持认为正确的事情已经完成,并且从根本上消除了问题。
这取决于您要执行的速率限制类型。
速率限制iptables
实际上更旨在限制传入的数据包,因为达到限制的数据包将与过滤器匹配并应用指定的目标(例如ACCEPT
)。您可能会有一个后续目标DROP
,即过滤器无法匹配的数据包。尽管iptables
有QUEUE
目标,但它只是将数据包传递到用户空间,您需要在该空间提供自己的排队应用程序。您还可以对传出数据包进行速率限制,但是很少有人真正想开始丢弃传出流量。
iptables
速率限制下降:
iptables -A INPUT -p udp --port 53 -m hashlimit --hashlimit 1/minute --hashlimit-burst 5 -j ACCEPT
iptables -A INPUT -p udp --port 53 -j DROP
使用hashlimit
而不是limit
将为您提供每个目标IP的速率限制。即,五个达到8.8.8.8的数据包将达到限制,这将阻止将数据包发送到8.8.4.4,而hashlimit
如果8.8.8.8达到最大值,您仍然可以达到8.8.4.4,这听起来更像您想要的。
如果您不希望超过限制的数据包被丢弃,那么您真正想要的就是tc
。tc
将调节流量以获得稳定的流量,而不是大量的突发流量。在输入端,数据包较慢地传送到应用程序,但所有数据包都会按顺序到达。在传出数据包上,数据包将尽快离开您的应用程序,但会以一致的流形式放在网络上。
我用的不是tc
很多,但是这里有一个限速ICMP的示例,您可能很容易适应DNS。
您可以采取以下措施来减轻对欺骗性查询的响应,但这需要一些工作:
首先,请查看安全通道的日志,并找到一个被欺骗的IP地址。
然后使用该源IP(10.11.12.13)运行tcpdump,如下所示:
tcpdump -n src 10.11.12.13 and udp dst port 53 -v -X -S
您将获得如下内容:
18:37:25.969485 IP(tos 0x0,ttl 52,id 46403,偏移量0,标志[无],原型:UDP(17),长度:45)10.11.12.13.51169> 01.02.03.04.domain:4215+ ANY ?。(17) 0x0000:4500 002d b543 0000 3411 b9d9 0A0B 0C0D E ..-。C..4 ....... 0x0010:0102 0304 c7e1 0035 0019 0e89 1077 0100 ....... 5 ..... w .. 0x0020:0001 0000 0000 0000 0000 ff00 0100 ..............
现在有趣的部分!在http://tools.ietf.org/html/rfc1035上打开rfc1035,然后转到第4.1.1节。
现在是时候转换tcpdump的结果并弄清楚我们可以用来创建数据包级过滤器的模式了。
标头的ID从0x1C开始,因此我们在0x1E有一些标志,在0x20有QDCOUNT,在0x22有ANCOUNT,在0x24有NSCOUNT,在0x26有ARCOUNT。
剩下的实际问题为0x28,在这种情况下,NAME的值为null(ROOT),QTYPE = ANY的值为0xFF,而QCLASS = IN的值为0x01。
长话短说,我发现添加以下iptables规则可以阻止超过95%的欺骗性查询,这些查询要求在ROOT中进行任何记录:
iptables -A INPUT -p udp --dport domain -m u32 --u32 "0x28=0x0000ff00" -j DROP
您的里程可能会有所不同...希望这会有所帮助。
tc
在Linux中使用和排队规则以用于出站端口53 UDP:
IFACE=eth0
tc qdisc add dev ${IFACE} root handle 1: htb default 0
tc class add dev ${IFACE} parent 1: classid 1:1 htb rate 10mbit burst 20m
tc qdisc add dev ${IFACE} parent 1:1 handle 10: sfq perturb 1
tc filter add dev ${IFACE} protocol ip parent 1:0 prio 1 handle 1 fw flowid 1:1
将为disc
防火墙标记为“ 1”的任何数据包设置一个限制为10mbit的数据包。防火墙标记仅在防火墙内部,不会修改数据包。排队规则只是对数据包的处理。这是iptables
用来制作防火墙标记的方法:
iptables -A PREROUTING -o eth0 -p udp --sport 53 -t mangle -j MARK --set-mark 1
iptables -A PREROUTING -o eth0 -p udp --dport 53 -t mangle -j MARK --set-mark 1
根据您的喜好进行修改,以排除受信任的子网和/或目的地。该-o eth0
限制整形只出站数据包。希望这可以帮助。
这些设备是否仍处于支持合同之下?如果是这样,请与您的客户联系。让他们知道互联网在过去十年中有所发展,为了继续为这些设备提供名称解析,您需要了解SRC IP,以期望进行查询。将日期定为将来的大约6个月,此时您将不再能够为未知的客户提供服务,请坚持下去。这在行业中很常见。如果这些设备不再受支持合同的约束,这听起来像是一项业务决策。您的公司打算在不再产生收入的古老产品上花费多长时间?
这些听起来像是专用设备,它们是否如此专业,以至于您可以合理地预测期望合法查询的域?绑定支持视图,创建仅对那些域进行递归的公共视图。
将此作为学习的机会,如果您还没有这样做,请停止发布您没有能力修复错误的产品。这就是错误。肯定会早晚使该设备停止运行的设备。
这是我针对DDOS攻击使用过几次的解决方案,虽然它并不完美,但可以帮助我。该解决方案包含一个脚本,该脚本由cron每N分钟(例如1,2,3等分钟)调用一次,并阻止IP创建的连接数量大于脚本中给定连接的IP:
#!/bin/sh
PORT_TO_CHECK="53"
CONNECTION_LIMIT="20"
IPTABLES="/sbin/iptables"
netstat -an > /tmp/netstat.tmp
Buf_var1=`cat /tmp/netstat.tmp | grep -v "LISTEN"| grep ":$PORT_TO_CHECK\ " | grep -v "0.0.0.0" | awk '{print $5}' | grep -v ":$PORT_TO_CHECK$" | sed -e 's/^::ffff://g' -e 's/:.*$//g' | sort | uniq`
i=0
banned_flag=0
for conn in `for i in $Buf_var1; do echo -n "$i "; cat /tmp/netstat.tmp | grep -c $i;done | grep -v "=\ 0"`;do
[ $i = 0 ] && connip=$conn && i=1
[ $i = 2 ] && {
connum=$conn
[ $connum -ge $CONNECTION_LIMIT ] && {
[ "$var_test" = "" ] && {
$IPTABLES -I INPUT -s $connip -j DROP
banned_flag=1
}
}
}
[ $banned_flag = 1 ] && i=0
[ $i = 1 ] && i=2
done
rm -f /tmp/netstat.tmp