基於iptables防火牆堵漏

七彩程式碼發表於2023-11-04

之前在網上流傳個段子:發現自己電腦被入侵,最有效的辦法是即拔掉網線~
雖然只是個段子,卻說明一旦機器發現漏洞被入侵,阻斷入侵刻不容緩,無論對個人電腦和業務伺服器都是如此。
商業伺服器雖然有各種防護措施,但是也不能保證百分百安全,一旦被入侵處理起來可不能直接拔網線。具體處理措施有很多,比如打各種系統補丁、封埠、修復程式碼漏洞、清除後門程式等等~

最近處理系統漏洞過程中遇到了個比較有意思的事情:
伺服器上有個非核心業務埠8080懷疑被入侵了,發現之後立刻安排安全部門和研發同步排查,在所有事情搞清楚之前研發先透過iptables規則drop掉了所有到8080埠的請求,然後安全同事用nmap掃描8080埠的狀態是filtered......
印象中埠要麼是open要麼是closed,那filtered是個什麼狀態呢?nmap居然知道我過濾了請求?一查還真是。
原來nmap掃描埠有6種狀態:

  1. Open 開放狀態:
    nmap 發起兩個 SYN 的請求,伺服器上監聽在此埠的程式會進行應答,會返回 SYN/ACK, nmap 收到服務端返還回來的應答後會傳送兩個 RST ,並不會和服務端建立通訊連線,完成埠的探測。

  2. Closed 關閉狀態:
    nmap 發起兩個 SYN 的請求,伺服器上由於沒有程式監聽該埠,核心會返回 RST, nmap 收到服務端返還回來的 RST 報文,將探測結果定義為 closed 。

  3. Filtered 過濾狀態:
    這種情況是服務端將收到的 nmap SYN 報文直接丟棄,不進行應答, 由於 nmap 直接傳送了兩個 SYN 報文,都沒有收到應答,所以認定服務端開啟了防火牆,將 SYN 報文丟棄。

  4. Unfiltered 未過濾狀態:
    nmap 預設進行的是 SYN 掃描,當用 -sA 選項( TCP ACK 掃描),連續傳送兩個同樣的 ACK 報文,由於 snmp 確認收到了一個服務端根本沒有傳送的報文,所以服務端會傳送一個 RST 報文, snmp 收到服務端傳送來的 RST 報文後,確認服務端沒有對報文進行丟棄處理,注意本探測不能發現埠是開放還是關閉狀態,只能確認探測的報文服務端已收到,並回復給了 snmp RST報文。

  5. Open|filtered 開放或過濾狀態:
    這種狀態主要是 nmap 無法區別埠處於 open 狀態還是 filtered 狀態。這種狀態長出現於 UDP 埠

  6. Closed|filtered 關閉或者過濾狀態

原來如此,Filtered其實就是nmap認為是對端drop掉了SYN包;

現在的IP tables規則是這樣的:

iptables -A INPUT -s 172.16.7.80 -p tcp --dport 80 -j DROP

檢視的執行結果是這樣的:

抓包看server側沒有相應,端側就會重傳:

漏洞雖然堵住了,請求也確實進不來了,但總感覺差了點什麼,有沒有辦法讓nmap掃描結果是Closed 呢?上面關於Closed解釋是:當nmap掃描系統沒有監聽埠時,kernel會響應RST,只要讓iptables返回RST就行了,看iptables文件中,Reject部分如下:

REJECT
作為對匹配的包的響應,返回一個錯誤的包:其他情況下和DROP相同。 此目標只適用於INPUT、FORWARD和OUTPUT鏈,和呼叫這些鏈的用 戶自定義鏈。這幾個選項控制返回的錯誤包的特性:
--reject-with type
Type可以是icmp-net-unreachable、icmp-host-unreachable、icmp-port-nreachable、icmp-prot o-unreachable、 icmp-net-prohibited 或者 icmp-host-prohibited,該型別會返回相應的ICMP錯誤資訊(預設是port-unreachable)。選項
echo-reply也是允許的;它只能用於指定ICMP
ping包的規則中,生成ping的回應。最後,選項tcp-reset可以用於在INPUT鏈中,或
自INPUT鏈呼叫的規則,只匹配TCP協議:將回應一個TCP RST包。

於是將iptables規則改成如下:

iptables -A INPUT -s 172.16.7.80 -p tcp --dport 80 -j REJECT --reject-with tcp-reset

再次掃描,結果變成了我們想要的樣子:

相關文章