作者：hansome
日期：2001-4-30 10:16:38
來源：Linux技術支持站點 (www.linuxaid.com.cn)

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查詢的規則： 
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更多的信息見： 
http://www.ists.dartmouth.edu/IRIA/knowledge_base/swatch.htm 
最后，為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軟件，控制經過網絡的數據可以使你躲開威脅。對于大型的系統，無法快速升級系統，本文所討論的措施會很有幫助。