從連接埠下手 企業防範SQL蠕蟲的侵襲

SQL蠕蟲一直是讓商業網路管理員很頭疼的問題，許多時候如果通過Etherpeek針對連接埠1433、1434抓包會發現，很多使用者電腦上面並沒有安裝SQL伺服器，但是仍能監測有蠕蟲通過1433連接埠向外面大量發包。一般來說微軟的案頭資料庫MSDE也有可能感染該蠕蟲。

看看SQLsnake蠕蟲，也叫Spida及Digispid，首次露面以來，就一直在掃描成千上萬台與Internet相連的電腦系統的1433連接埠，企圖尋找運行微軟SQL且沒有在系統管理員帳號上設定適當密碼的系統。還存在另外一種病毒，即使並沒有安裝資料庫的PC也會感染。這個時候用戶端PC如果沒有辦法解決的話，就只能從網路層進行防護了。

一般來說UDP連接埠1434都是用來做偵聽的，可以在網路裝置上過濾掉UDP1434；而TCP連接埠1433是SQL伺服器正常通訊需要的連接埠，並不能全網過濾掉。

但是一般來說，跨網段的資料庫很少，這樣，我們可以開放有資料庫的網段的1433連接埠，然後再過濾全網的1433，這樣減少了故障處理點，也達到了目的。

看看下面的ACL，核心三層交換器S8016針對1433、1434所做的ACL，其他裝置類似。

註：全網封UDP 1434，開放10.145.7.0網段的TCP連接埠1433。

rule-map　intervlan　rule72　tcp　any　any　　eq　1433
rule-map　intervlan　rule73　tcp　any　any　eq　1434
rule-map　intervlan　rule69　tcp　any　10.145.7.0　0.0.0.255　eq　1433
eacl　acl-jxic　rule69　permit　priority　34083
eacl　acl-jxic　rule72　deny　priority　34088
eacl　acl-jxic　rule73　deny　priority　34090

之後用Etherpeek抓包一看，SQL蠕蟲沒有了，裝置也沒有警示，大功告成！