如何防止lion蠕虫的感染

日期：2001-05-15

源：Linux技术支持站点 ()

Lion蠕虫是通过攻击系统BIND服务器 8.2,8.2-P1,8.2.1,8.2-Px以及所有8.2.3的测试版的缺陷来传播的．最好的保护方法是升级BIND。你可以从下面的站点获得它的升级版本：

ftp://ftp.redhat.com/pub/redhat/updates
http://security.debian.org/dists/stable/updates/main

ftp://ftp.caldera.com/pub/updates/OpenLinux/
ftp://ftp.slackware.com/pub/slackware
本文的目的是帮助无法升级系统的用户，保护自己的系统不被lion蠕虫侵害。解决方案由以下部分组成：
1.Cisco路由器访问控制列表(ACL)
2.Linux ipchans
3.Linux Netfilter

过滤TCP/53端口
TCP/53端口有几个合法的用途，包括：zone传输、大于484个字节的数据请求、平衡负载。
zone传输用来在主、从域名服务器之间传输完整的zone信息。数据文件存储在主域名服务器上，被传输到一个或者多个从域名服务器上。这个功能可以同时把请求直接传递到几个域名服务器进行域名解析，提高了系统的性能。
看看主域名服务器的/etc/named.conf文件，可以知道是否有从域名服务器需要通过TCP/53端口访问主域名服务器。你可能会看到如下的入口：
zone "fubar.gov" in {
type master;
file "master/fubar.gov";
allow-transfer {outside.net.1.10;};
这一段规定只有在outside.net.1.10的IP地址内的系统才能够允许使用TCP/53端口与主域名服务器通信。如果这个IP地址超出了我们的防护边界(例如是我们ISP的DNS服务器)，那么在定义我们自己的访问列表时，我们就应该注意这个地址。如果和我们的域名服务器在同一个子网中，就意味着数据的传输不会超出我们的保护范围，所以我们无须担心.
如果在/etc/named.conf文件中没有类似的入口，而你还有一个或者几个从域名服务器复制zone信息，那么你需要在/etc/named.conf文件中加入类似的入口以帮助对访问的控制。
一般地，DNS使用UDP/53端口进行通信，如果请求数据超过了484个字节(512减去DNS包头的长度)，域名服务起就切换到TCP/53端口。这是TCP/53端口的第二个合法用途。注意作为一个DNS管理者，你应该对此进行控制。为了避免这种情况的发生，首先要确认你的域名服务器对请求的应答数据不会超过484个字节。通过不对TXT请求或者超长的域名请求进行应答，可以避免这种情况。如果你的系统中的域名都是象"server.mydomain.foo或者相似的结构，人们将永远没有机会使用TCP/53端口和你的域名服务器建立连接。
一些系统管理员可能会认为TCP/53端口的第三种合法用途不太合法。一些具有平衡负载功能的系统为了标志你在Internet中的位置，会产生向TCP/53端口发出的请求。例如，如果你的IAP是AT&T，如果你要浏览的WEB页面，向fubar.gov的域名服务器发出了一个URL请求。而fubar.gov为了负载的平衡，把它的某台服务器放在了AT&T的主干网上。如果使用TCP/53端口来查询域名服务器，fubar就会识别出你的地址并把你定向到离你最近的服务器对你的WEB请求进行响应。
综上所述，在进入过滤规则以前对上面提到的内容进行最后的检查：
1）标出所有在你的安全保护范围之外的从域名服务器。
2）确定所有查询都小于484个字节。
3）如果要实施下面所述的保护措施，在对系统进行升级以前停止有其它组织提供的负载平衡功能。

CISCO路由器的访问控制列表
为了阻止lion的攻击，你必须使用扩展或者反向的访问列表，因为我们要在TCP/53端口进行过滤，所以不能使用标准的访问列表。因为反向过滤可能控制在TCP/53端口的传输，所以我们需要设置SYN位阻塞进入TCP/53的包。反向过滤还可以保护系统不受端口扫描的威胁，不过lion不使用端口扫描。然而，反向过滤需要占用更多的路由器内存和处理器时间。所以我们在本文中关注扩展访问列表。
让我们首先从过滤向内的包以阻止端口扫描与攻击开始。我们要做的第一件事就是确定一个规则：允许合法的从域名服务器使用TCP/53进行数据的传输。我们假设我们的ISP作为一个从域名服务器，其域名服务器的地址是“outside.net.1.1"，再假设我们的域名服务器的IP地址是"inside.net.2.2"。由此，在全局配置模式下我们将建立第一个ACL：
Access-list 101 permit tcp host outside.net.1.1 host inside.net.2.2 eq 53
接着，我们将允许对TCP/53端口的申请进行应答，因为我们内部的域名服务器可能向Internet上的域名服务器发出请求。
Access-list 101 permit tcp any host inside.net.2.2 eq 53 est
最后，我们需要阻塞所有试图从TCP/53向内的包。我们也可以写入日志
Access-list 101 deny tcp any any eq53 log
从而使这种包被阻塞，并被记入了日志。
如果Cisco路由器是你的唯一一条防线，除了上面的规则外，你还要加入下面的规则(顺序不能颠倒)
Access-list 101 permit tcp host outside.net.1.1 host inside.net.2.2 eq 53
Access-list 101 permit tcp any host inside.net.2.2 eqq53 est
Access-list 101 deny tcp any any eq 53 log
如果在路由器后面有防火墙来做大部分的包过滤，那么使用下面的规则是比较恰当的：
Access-list 101 permit tcp host outside.net.1.1 host inside.net.2.2 eq 53
Access-list 101 permit tcp any host insde.net.2.2 eq 53 est
Access-list 101 deny tcp any any eq 53 log
Access-list 101 permit ip any any
你选择那种规则依赖于你的配置。这两种规则都要在路由器的外部接口，对向里的包使用。通常它是第一个串口，以serial0(例如在2501)或serial0/0(3600或更高)。在此我们假设是serial0,其全局配置模式如下：
interface s0
ip access-group 101 in
现在我们来配置向外的包过滤规则。我们假设你已经按照上面的步骤进行了配置，并且向内的包过滤规则已经生效。我们现在假设我们内部的某台主机已经被侵入，接着这台主机将试图攻击Internet上的其它主机，我们应该阻塞这种传输，并把它记入日志。然而，这样会产生一个小小的问题，我们无法控制从Internet上返回的数据的大小。这意味着我们需要允许内部的任何域名服务器通过TCP/53端口向外查询。很显然我们将会采取措施来修补这些域名服务器的缺陷。对于其它的主机，使用下面的包过滤规则将有利于记录潜入的lion蠕虫的活动：
Access-list 102 permit tcp host inside.net.2.2 any ea 53
Access-list 102 deny tcp tcp deny eq 53 log
Access-list 102 permit ip any any
你应该把这些包过滤规则用在对内部的接口，假设是Ethernet0:
interface eht0
ip access-group 102 in

ipchains
ipchains是基于Linux内核2.2版本的一种静态包过滤防火墙，因为lion蠕虫集中攻击Linux系统，所以讨论一下ipchains的包过滤规则是非常恰当的。本文不是讲述IPChains的功能，如果想了解这方面的信息请参考ipchains-howto文档：

与上面一样，我们需要知道所有主、从域名服务器的IP地址。我们还是假设"out.net.1.1"是我们ISP的域名服务器IP地址，它作为从域名服务器；内部域名服务器IP地址是“inside.net.2.2"，它作为主域名服务器。
首先我们要建立一条规则，让从域名服务器能够和主域名服务器对话：
ipchains -A input -p tcp -s outside.net.1.1/32 -d inside.net.2.2/32 53 -j ACCEPT
接着，我们需要建立一条规则，允许我们内部的域名服务器建立TCP/53查询：
ipchains -A input -i eth0 -p tcp -s inside.net.2.2/32 -d 0/0 53 -j ACCEPT
第三，我们还要建立一条规则，允许在TCP/53对我们的域名服务器响应的包进入：
ipchains -A input -p tcp ! -y -s 0/0 -d inside.net.2.2/32 53 -j ACCEPT
最后，我们过滤掉所有其它所有的TCP/53连接(不管是向内还是向外)并把它们都记录到日志：
ipchains -A input -p tcp ! -y -s 0/0 -d 0/0 53 -l -j DENY
把这些加起来就是：
ipchains -A input -p tcp -s outside.net.1.1/32 -d inside.net.2.2/32 53 -j ACCEPT
ipchains -A input -i eth0 -p tcp -s inside.net.2.2/32 -d 0/0 53 -j ACCEPT
ipchains -A input -p tcp ! -y -s 0/0 -d inside.net.2.2/32 53 -j ACCEPT
ipchains -A input -p tcp ! -y -s 0/0 -d 0/0 53 -l -j DENY
要注意：ipchains采用的是首次适配的原则，所以如果在前面有一个允许TCP/53传输的规则：
ipchains -A input -i eth0 -p tcp -s 0/0 -d 0/0 -j ACCEPT
那么，上面写的所有规则都将失效，因为这条规则允许从TCP/53向外的传输。

Netfilter
netfilter是Linux2.4版内核中的一个防火墙。netfilter超过了ipchains，它最大的好处就是有能力维护UDP和TCP的对话状态。更多的信息见：

我们设置的netfilter过滤规则和ipchains类似，只在语法上稍有不同。还有，我们对日志和应答传输的处理也有一点不同。
我们再次从允许从域名服务器和主域名服务器对话开始：
iptables -A FORWARD -m state --state NEW -p tcp -s outside.net.1.1/32 -d inside.net.2.2/0 --dport 53 -j ACCEPT
接着，我们设置允许内部域名服务器向外进行TCP/53查询的规则：
iptables -A FORWARD -m state --state NEW -p tcp -s inside.net.2.2/0 -d 0/0 --dport 53 -j ACCEPT
最后，我们允许对上面的规则进行应答:
iptables -A FORWARD -m state --state ESTABLISH,RELATED -j ACCEPT
netfilter对日志的处理方式和ipchains不同。对于命令行开关，netfilter的日志命令行选项是"jump"或"-j"。它增加了规则的大小，同时也增加了弹性。例如，我能够建立下面两个规则把所有上面的包过滤规则没有匹配的传输记录到日志并抛弃：
iptables -A FORWARD -S 0/0 -d 0/0 --dport 53 -j LOG --log-level info --log-prefix "lion_scan"
iptables -A FORWARD -S 0/0 -d 0/0 --dport 53 -j DROP
现在，如果我们要检查我们的日志，只需要以root的身份登录，输入西面的命令：
#grep lion_scan /var/log/messages* >/root/lion_scan_matches.txt
甚至我们还可以安装一个日志分析工具例如swatch向我们发出警告。关于swatch更多的信息见：

最后，为netfilter设置的包过滤规则是：
iptables -A FORWARD -m state --state NEW -p tcp -s outside.net.1.1/32 -d inside.net.2.2/0 --dport 53 -j ACCEPT
iptables -A FORWARD -m state --state NEW -p tcp -s inside.net.2.2/0 -d 0/0 --dport 53 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISH,RELATED -j ACCEPT
iptables -A FORWARD -S 0/0 -d 0/0 --dport 53 -j LOG --log-level info --log-prefix "lion_scan"
iptables -A FORWARD -S 0/0 -d 0/0 --dport 53 -j DROP

结论
Lion蠕虫将以很快的速度席卷Internet。最好的保护方法是升级BIND软件，控制经过网络的数据可以使你躲开威胁。对于大型的系统，无法快速升级系统，本文所讨论的措施会很有帮助。