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個字節。
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
第三，我們還要建立一條規則，允許在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查詢的規則
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查詢的規則
