公司内网开发服务器不可访问事故处理

Posted 2022-04-05 乌龟漫步

记一次公司内网开发服务器部分服务不可访问故障处理。事故发生于2022年4月3日下午4点，起因是上午10点左右有同事反馈远程登录地址打开报错，由于是放假并不想去管......下午抽空的时候去看了看发现是代理有问题，开始处理代理的问题，经测试，外网访问代理端口33306（mysql）网络连接是正常的但是没有数据传输，应对方法是重启代理，事故由此发生。经过半天的奋战，最终在凌晨1.45恢复。

事故发生

简单介绍一下公司的远程开发环境。在公司内网有一台物理服务器，由于疫情现在需要在家远程开发，现在实现远程开发的方式是通过SSH远程端口转发，将本地端口转发到腾讯云的一台代理服务器（云服务器），在代码中访问远程服务器。如下图。

在内网服务器启动了SSH端口转发的进程，重启方式也很简单，就是把SSH端口转发的进程kill掉然后再重启。问题就出现在这里，由于有很多的端口转发一个个kill效率太低，于是使用了​​ps​​命令将端口转发的进程ID找出来，然后kill掉它们。

ps auxf | grep ssh -L | grep -v grep | awk print $2 | xargs -I kill -s 9 

这里查找SSH转发命令的时候特地加了​​-L​​参数，防止​​sshd​​进程被​​kill​​掉。问题就出在这里，这条命令把内网服务器转发的22端口也就是ssh的端口转发进程kill了。此时我与内网服务器的ssh连接断开了，这意味着我不能在把其它代理在启动起来，下周同事上班的时候会发现redis、MySQL无法访问，影响了工作开展。

此时面临的问题有：

1. 与内网的连接断开，无法访问到内网。
2. 上海正处于疫情期间，无法出门，公司无人值守，也就是说没有办法赶到公司重启代理。
3. 如果在下周上班前不恢复，开发同事无法正常工作，会对公司造成损失。

事故处理

连不上内网，登不上内网服务器。问题很大，必须快速修复。明确目标：在内网服务器执行命令，恢复ssh端口的访问。

经过一番尝试，发现并不是所有的端口转发进程都被kill掉了。还有一个web端口转发可以外网访问。web服务后台是php语言编写的，于是开始找漏洞看能不能在网站目录写入一个PHP脚本。PHP是一种解释性语言，只有在网站document root写入一个文件，然后在浏览器访问它就能被执行。这就很好办了，只要能执行命令就有机会恢复。

借着这次机会，对我们网站进行了一次测试，翻了很久代码，没有发现可以入手的地方，这说明我们的网站安全性还是很不错的，这很好。在网上查询了PHP的漏洞也没有发现可以利用的地方（也可能是我才疏学浅不懂利用），此路不通，要想想其它的方法。

突然想到我们公司路由器是有公网IP的，问题有了转机。只要在公司路由器配置一个端口转发就可以访问到内网服务器。于是向公司网管询问路由器公网IP，是否可以在外网访问。网管的答复是路由器有外网IP，但是不能在外网访问，只能在内网访问。又一条路走不通。

想不到别的办法了，开始向其他同事求助。这次靠谱了，同事告知有一个项目留了一个测试后门，是使用HTTP的，可以执行任意代码，但是执行用户（tomcat）权限很低。

有了执行命令的接口，开始的想法是在PHP网站​​document root​​写入一个文件，但是tomcat的权限无法写入。于是想到着这个接口执行ssh端口转发命令。

# 生成ssh秘钥
$ ssh-keygen -N  -f /tmp/tomcat_idrsa
# 查看公钥内容，将公钥添加到代理服务器 ~/.ssh/authorized_keys
$ cat /tmp/tomcat_idrsa.pub
# 执行端口转发命令
$ /usr/bin/ssh  -NR 0.0.0.0:2222:127.0.0.1:22 -i ./tmp/tomcat_idrsa [e-mail] 2>&1 &

但是由于命令执行用户权限不够，端口转发命令执行失败，报错如下

Could not create directory /usr/share/tomcat7/.ssh.
Host key verification failed.

最后是使用nc来做端口转发，将内网服务器ssh端口转发到代理服务器上，然后使用ssh登录到内网服务器，将代理启动。

代理服务器执行命令：

# 建立一个命名管道
$ mkfifo ./sshd
# 监听2222端口，接收来自内网的连接
# 监听4444端口，作为ssh服务端端口，使用ssh命令连接此端口: ssh root@127.0.0.1 -p4444
$ nc -l 2222 < ./sshd | nc -l 4444 > ./sshd

内网服务器执行命令：

# 建立一个命名管道
$ mkfifo /tmp/fixup_tun;

# 将ssh端口转发出去
$ nc xxx.xxx.xxx.xxx 2222 < /tmp/fixup_tun | nc 127.0.0.1 22 > /tmp/fixup_tun &

总结

此次事故发生的时机也好也不好，好的是当前处于假期中不影响工作，离上班还有两天时间，在这段时间可以想办法去修复。不好的是如果没有后门接口就只能去公司进入内网操作，加上上海正处于疫情期间，去公司是不可能了，这样的话就只能搞一台云服务器做开发环境，但是这又访问不到内网的数据，会对工作造成影响。

此次事故发生的原因主要是操作不规范，没有弄成一致性的脚本去完成操作，人工操作很容易失误，造成损失。经过这次事故也体会到了公司远程开发环境的脆弱性以及上云的重要性，上云后重启、各种操作都很方便，不用担心公司断电无法重启内网服务器等等问题。

下面是几个总结：

1. 规范化操作，将一些常用的操作整理成脚本，避免操作失误。
2. 多留些备用方案。
3. 上云！上云！上云！

参考

• ​​NetCat使用介绍​​​
• ​​How to use ssh-keygen to generate a new SSH key​​
• ​​SSH port forwarding - Example, command, server config​​​