记一次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的恶意攻击第一次遇到,感谢各类博客文档的完备,及时定位处理。

猜你喜欢

转载自www.cnblogs.com/duoxuan/p/12186698.html