基于iptables防火墙堵漏

发布时间 2023-11-04 13:39:28作者: 七彩代码

之前在网上流传个段子:发现自己电脑被入侵,最有效的办法是即拔掉网线~
虽然只是个段子,却说明一旦机器发现漏洞被入侵,阻断入侵刻不容缓,无论对个人电脑和业务服务器都是如此。
商业服务器虽然有各种防护措施,但是也不能保证百分百安全,一旦被入侵处理起来可不能直接拔网线。具体处理措施有很多,比如打各种系统补丁、封端口、修复代码漏洞、清除后门程序等等~

最近处理系统漏洞过程中遇到了个比较有意思的事情:
服务器上有个非核心业务端口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

再次扫描,结果变成了我们想要的样子: