本页网址二维码：
本页网址二维码：
一个人的蓝队......真是无奈。
题图来自Pixabay公共图片库
一句话：尽一切可能限制攻击队获得操作系统管理员权限。
攻防演练是人和人的对抗，攻心为上。
攻防演练的时间是有限的，只要攻击队发现被拖住了，就会去寻找下一个更加容易得分的目标。
说起来容易，做起来难。因为实际情况太多太复杂了。所以本篇先说一下这次攻防演练的对抗防御过程。
| 一、源起 |
这次攻防演练，本打算躺平放弃了（见我之前发的：缺乏资源如何应对网络安全攻防演练？），但到了发现被入侵那一刻，斗心就上来了。心想：
“老子哪有那么容易让你们得手”
于是和攻击队打了一个上午的拉锯战，最后成功守住了靶标系统，迫使攻击队转移攻击其他单位的靶标系统。
验证了自己宝刀未老（可以猜猜号主年龄，当然猜中也没奖）。
剧透：其它单位靶标系统不堪一击，成为攻击队的送分题。
实际上，攻击队在前一晚已经上传了 WebShell，但由于各种原因和实施了的关键措施：用非特权账户运行中间件，我才有机会在第二天早上拉锯和反制。所以这就是本文标题的源头，妥妥的救命稻草。
| 二、过程 |
言归正传。攻击队在前一晚就已经发掘到了一个弱口令的测试账户。至于这个弱口令账户哪里来的......事后查了是这个应用系统在初始安装时就自动创建的，没人用的，这真是个巨坑啊。
随后，攻击队找到了这个应用系统的一处任意文件上传漏洞，上传了 JSP 的 WebShell，开始进行试探，什么 whoami ifconfig 之类的命令运行一通，获取主机和网络信息。
但是，这个应用系统是以普通用户运行的 Tomcat 中间件，系统 CentOS 7的补丁持续更新，并且开启了 SELinux，所以在攻击队前一晚的尝试中，并未能找到有效的提权办法获得 root 权限，反而在日志机留下大量的操作失败记录。
由于已经提前报备了每天23点后操作系统定时关端口然后做备份，到点了，定时任务启动，端口关闭，WebShell 不可用，攻击队只能被迫去睡觉（不是）。
所以这种定时关端口的措施也确实有作用，减少暴露攻击面确实是颠扑不破的真理。
（也因为我这没有也不可能有24小时值守啊）
然后第二天，早于攻击队上班也起了作用。当然我还先慢悠悠地磨豆，煮咖啡，冲调，然后一边喝一边常态化启动 Thunderbird 收服务器的 Logwatch 邮件......好家伙，有料！
（好像有人问豆子哪里的，答案是某鹿，某东有售。顺带吐槽某品牌奶越来越稀，只是不耐受人群没得选）
邮件显示，用于运行 Tomcat 的锁定用户正在尝试用 root 身份执行特权命令！
（收服务器 Logwatch 邮件这个操作相当 Old School ，我这实时监控手段是不足的，需要补，不过穷啊）
这不就是有 WebShell 了吗！斗心登时就上来了，老虎头上叮虱子是吧，干！
首先检查有无被新创建文件，方法很简单：
find -newermt '2023-07-11 00:00:00' ! -newermt '2023-07-12 23:59:59'
发现上传了两个用时间戳做文件名的JSP文件，其中一个还复制到了WEB根目录下面并改名为 error.jsp 想躲起来，但文件的创建时间已经深深地出卖了你。
（这两个文件是 WebShell 的先导落地，作用是伪装为PNG文件响应远程传入和结果传出，实现下一步无文件木马的注入运行）
立马改掉文件名不给运行，例如：
mv error.jsp error.jsp_disabled_by_wavecn
但不删除。因为要预备写防守报告拿分时作为证据。
接下来，快速登录多开N个 Putty 窗口，同时：查看系统日志、查看服务器上的 tomcat 日志、检查内存有无异常进程。虽然都是很简单的操作，作为科普还是写一下。
系统日志用 tail 持续观察新输出，之前的日志通过日志机看就好：
tail -f /var/log/messages
Tomcat 日志是关键。需要往前追溯，用 less：
less /opt/tomcat/logs/debug_
同步检查内存进程：
ps aux | grep tomcat
所以上一篇文章里面说的多屏幕排布窗口还是很有用的，虽然内容基本就是调侃：没有资源的情况下如何熬过攻防演练？
只是，Tomcat 日志进不了日志机独立保存。这其实是个管理漏洞，以后还要考虑把 Tomcat 日志如何转移保存到日志机，或者另一台服务器。
居然 ps 操作显示已经有异常的 java 进程在运行了：
[root@server ~]# ps aux | grep tomcat
tomcat 86487 0.0 0.0 113280 1220 ? S 11:34 0:00 sh -c cd "/home/tomcat/.java";./java -p iLTi6kGVLnn+rXRGFq86gz/qaXafjwGot2dAwZAonky4u1wqTtA4O17BR8UsdmV6 2>&1
tomcat 86489 0.2 0.0 715572 11236 ? Sl 11:34 0:03 ./java -p iLTi6kGVLnn+rXRGFq86gz/qaXafjwGot2dAwZAonky4u1wqTtA4O17BR8UsdmV6
不放截图是为了精简内容。话说我手头这破应用系统何德何能需要劳烦到出动无文件木马......确实已经是主流手段了。
不管那么多直接杀掉就好。
kill -9 进程号
右边在杀进程，左边查 Tomcat 日志，重点是按上传的 WebShell 文件的时间开始往前看，找出攻击者用的是哪个系统用户，通过什么系统功能实现上传 WebShell 的。
（看日志确实靠经验，也靠对这个信息系统的熟悉程度）
按目录关键字，在日志里面找到了相关的系统用户ID和攻击队的IP地址。马上用信息系统的管理员禁用被攻击队利用的系统用户账号。
（我还在数据库的用户表里面查询确认了图片中的账号名“01”，然后才用应用系统管理员禁用了这个账号）
Tomcat 日志里面记录了攻击队上传的经过BASE64编码的无文件木马代码，有空会翻出来再看看具体是啥。
然后急 Call 系统的开发商，开发商居然说，啊，那个漏洞还未修补吗，然后反手发来一个补丁。
（囧）
一看补丁适用的应用系统版本，凉了，不是我这个版本，是较新的版本。
（大囧）
好吧，尽管试试。一番备份和替换，重启 Tomcat......系统能登陆但功能界面都出不来。
（预料中的囧）
只能回退了。
回退完，重启服务，攻击队也几乎同时就换了另一个真实用户账号（又是弱密码！）登录了，重新上传了 WebShell，且又启动了无文件木马的 java 进程。
（这是明知对面有人还继续吗，但你对面那个可是 root 用户哦，你提不了权就没有赢面的哦）
继续 kill -9 杀进程，同时把 WebShell 上传的目标目录设置为 root 所有，且目录属性为000，谁都别想写。
chown chmod 这些命令太常用，实在是懒得在这里做格式了。
想想还不够，Tomcat 日志既然写得这么清楚，URI和参数都有：
于是去WAF设置自定义规则，按URI和参数进行拦截：
应用规则：
再然后，继续排查禁用可能被攻击队控制的其它弱密码账户，果然还是有人用弱密码一直不改的（这系统开新账号统一初始弱密码，厂家从不改这个奇葩设计，也是巨坑），重启 Tomcat 服务确保账户不能用。
平静下来了。攻击队应该也知道了，另一边的人还是有两把刷子的。
然后就开始听到其它单位在喊救命了。
于是，各种截图，写防守报告，上传演练管理平台，经裁判组评审，拿到60分的加分。
其实防守报告多写一些内容或者能拿多点分，但后来想，一个人的防守，算了，不搞那么累，还不如看看自己的桌面墙纸：
| 三、结论 |
整个过程，关键就是在于攻击队的 WebShell 不是以 root 用户身份运行，无法控制主机。然后就是其它措施的共同作用，比如勤奋地打好补丁使得操作系统没有可利用的提权漏洞。如此多管齐下，实现拖住了攻击队的步伐，最终就能相对从容地把攻击队送去别家。
进一步地，可以对这个专用系统账号进一步设限制，禁止执行特权命令之类，总之从严就还有很多功课需要补。
另一个大前提，是作为管理员对这系统的熟悉和了解程度。我是不会说我之前对这系统做了多少铺垫，包括自己换 Tomcat 漏洞版本，大改jsp代码适配 Tomcat 的变化，自己改 jsp 里面的漏洞，用数据库触发器调整系统功能逻辑和绕过BUG等等。
所以我是早就问开发商拿了数据字典的，一个人的蓝队，DBA也是我。
就差反编译修改代码后再编译来实现功能修补了。
只是弱密码排查、测试账户封禁始终都还是有遗漏，这点自己都觉得比较失败。
下一篇再具体讲讲这救命稻草相关的实现。
