基於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

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

相關文章