周末服务器告警，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的恶意攻击第一次遇到，感谢各类博客文档的完备，及时定位处理。