Lion蠕虫是通过攻击系统BIND服务器 8.2,8.2-P1,8.2.1,8.2-Px以及所有8.2.3的测试版的缺陷来传播的．最好的保护方法是升级BIND。你可以从下面的站点获得它的升级版本：
http://www.isc.org/prodUCt/BIND
FTP://ftp.redhat.com/pub/redhat/updates
http://security.debian.org/dists/stable/updates/main
http://www.suse.com/us/support/download/updates/index.Html
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，如果你要浏览www.fubar.gov的WEB页面，向fubar.gov的域名服务器发出了一个URL请求。而fubar.gov为了负载的平衡，把它的某台服务器放在了AT&T的主干网上。如果使用TCP/53端口来查询域名服务器，fubar就会识别出你的地址并把你定向到离你最近的服务器对你的WEB请求进行响应。
综上所述，在进入过滤规则以前对上面提到的内容进行最后的检查：
1）标出所有在你的安全保护范围之外的从域名服务器。
2）确定所有查询都小于484个字节。
[1] [2] [3] 下一页
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文档：
http://www.linux.org/docs/ldp/howto/IPCHAINS-HOWTO.html
与上面一样，我们需要知道所有主、从域名服务器的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
上一页 [1] [2] [3] 下一页
第三，我们还要建立一条规则，允许在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的对话状态。更多的信息见：
http://netfilter.samba.org/
我们设置的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查询的规则
（出处：http://www.sheup.com）
上一页 [1] [2] [3]
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的对话状态。更多的信息见：
http://netfilter.samba.org/
我们设置的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查询的规则
（出处：http://www.sheup.com/）
上一页 [1] [2] [3] [4]