一次应急响应记录

背景:

周五晚上,我健身完回到宿舍收到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.解决问题的过程中,需要灵活应变,多想几种方法,尽量了解事件的全貌,然后做出判断,着手解决。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值