记一次apache安全攻击

周末服务器告警，cpu100%

• apache
• wordpress
• php

原因

• web后台管理权限泄露（比如密码泄露，wordpress安全配置等），上传了恶意脚本
• apache未对上传文件夹进行权限限制，其中的php脚本可以直接浏览器访问，运行恶意代码

处理方案

• 配置apache配置文件，对上传文件夹禁止脚本功能，重载配置

        <Directory "/www/uploads">
                php_admin_flag engine off
        </Directory>

service apache2 reload

• 修改wordpress后台密码
• 删除恶意脚本

检查步骤

1.登录服务器，运行 top 得到高cpu的进程pid,例如 23860

从top信息中没有该进程的执行路径，
command就 ./mh，用户是 www-data
需要其他方式确认该进程的信息

2.获取该pid进程使用到的所有资源清单

• strace -p 29442
• lsof -p 29442
• ps -aux |grep -v grep|grep 23860
• netstat -anp|grep 23860

3 .上面的信息保留后，可以尝试 kill -9 pid 检查进程是否会复活

基本上这样的进程都会自动复活的，需要找到其复活方式，
linux系统可以检查 cron 是否有未知的定时任务

#------------------查看所有用户的crontab任务-------
cat /etc/passwd | cut -f 1 -d : |xargs -I {} crontab -l -u {}

tail -f /var/log/apache2/accesses.log  
# 查看访问日志，定位是否有未知请求

4 . 下面是对病毒定位的有用的信息，其他的可作为入侵证据

# lsof  -p 23860
COMMAND   PID     USER   FD   TYPE    DEVICE SIZE/OFF    NODE NAME
mh      23860 www-data  cwd    DIR     253,1     4096       2 /
mh      23860 www-data  txt    REG     253,1   161084 1016640 /www/uploads/2020/01/mh (deleted)
mh      23860 www-data  mem    REG     253,1 33554432  438088 /tmp/.dev
mh      23860 www-data    0u   CHR       1,3      0t0       6 /dev/null

找到一条文件路径 /www/uploads/2020/01/mh ，该文件是 deleted 状态，进入目录查找cpu告警期间创建的文件
对比文件创建时间与控制台cpu飙升时间相差45分钟

# ls -al /www/uploads/2020/01/*.php

猜测是wordpress后台密码泄露，上传了php恶意脚本
web上传目录有脚本权限，php脚本可直接运行
apache的访问日志中有定时请求

185.c.c.c - -  "GET /uploads/2020/01/er_pan.php HTTP/1.1" 404 527
52.c.c.c - -  "GET /wp-login.php HTTP/1.1" 200 288

按照安全配置后，cpu恢复正常

总结

因为是测试服，没有认真考虑安全漏洞，又是在周末，之前遇到的cpu高占用基本上是业务导致，
因此在收到短信告警时，并没有及时处理，等到第二次告警时，已经过去一个下午了
好在这次攻击不是流量攻击，否则公司的云服务器流量配置就会被耗空。
linux的恶意攻击第一次遇到，感谢各类博客文档的完备，及时定位处理。