一次应急响应记录

背景：

周五晚上，我健身完回到宿舍收到qq消息，原来是安全厂商在扫描资产时，发现一批openssh漏洞如下图：

其实我是一名小白，我的第一反应就是升级openssh版本。但是这里问题又来了，我们内网主机是无法连接公网的，yum命令无法使用。问了其他运维人员，我还不能随便升级openssh，必须找其他部门配合，但是领导下了死命令，今天之内必须修复，我也是组内的人临时求助到我，之前的情况并不了解。

于是我接下来的思路是源码安装openssh，然后在自己的公网主机中做一个实验，如果通过则在内网主机中使用该方法。找了一圈，发现其实都有一些问题。

这个时候，我不知道为啥运行了查看防火墙的命令：

iptables -L -n

我惊讶的发现，该防火墙的规则居然为空，类似下图，我一下子明白了，原来是防火墙没开启，内网中我们的防火墙都是有特定的配置规则，只允许堡垒机和某些业务机访问，其他机器均不能访问，这都是通过iptables来配置的。

于是我参照该业务的其他主机的防火墙规则进行了手动配置。这里有出现问题了，我本来想把其他主机的/etc/sysconfig/iptables直接复制到漏洞主机上，然后重启iptables应用即可，结果发现service iptables restart 和 systemctl restart iptables都无法使用。

为了进度，我只能手动配置，第一行是需要放行的堡垒机，主机拒绝22端口的主机必须放在最后一行，不然你都无法通过堡垒机登录了，只能之后去机房插键盘。。。

iptables -I INPUT -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

?然后我使用nmap简单扫描了一下，发现22端口的流量已经被防火墙过滤了（此IP是我替换过的）：

┌──(root?local)-[~]
└─# nmap -p 22 192.168.7.1
Starting Nmap 7.94 ( https://nmap.org ) at 2023-12-15 22:38 CST
Nmap scan report for 133.38.137.89
Host is up (0.047s latency).

PORT   STATE    SERVICE
22/tcp filtered ssh

我赶紧在群里面给出了我的简单复测结果，接下来就等安全厂商的扫描结果，毕竟领导最后还是看厂商（我是甲方），过了大概半个多小时，安全厂商终于给出了复测结果，果然没问题，此次响应到此结束。

总结

经过这次事件，我学习到了：

1. 在企业中防火墙非常重要，iptables一定要学会，新机器也可以用firewalld，但是经典就是经典，就像ak47，是战士亲密的战友。

2.扫描器扫出来的漏洞的修补中，要尽量了解到主机的环境，了解其他相似主机的环境，找到其差异的地方，大部分情况下扫描器都是扫出了版本问题，如果类似openssh这种，我们有堡垒机就可以通过防火墙来过滤，如果是某些应用，可能只有升级。

3.解决问题的过程中，需要灵活应变，多想几种方法，尽量了解事件的全貌，然后做出判断，着手解决。