ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

Tomcat日志分析实战:从401到WebShell的攻防推演

Tomcat日志分析实战:从401到WebShell的攻防推演 1. 玄机靶场里那行被忽略的404Tomcat日志不是流水账是攻击者的行车记录仪你刚在玄机靶场点开“日志分析-Tomcat日志分析”关卡页面弹出一串密密麻麻的access.log片段第一反应可能是——这不就是一堆时间戳、IP、状态码和URLCtrlF搜个/admin或者/phpmyadmin没找到就点“提交”系统却冷冷返回“答案错误”。我第一次也这么干过结果在靶场里卡了整整三小时。后来才发现自己把Tomcat日志当成了交通摄像头拍下的模糊车牌照片只盯着“有没有车经过”却完全没看清楚“哪辆车、几点、从哪条道、以什么速度、往哪个方向、撞了几次护栏”。Tomcat日志真正的价值从来不在“有没有发生”而在于“怎么发生的”。它不像Windows事件日志那样自带分类标签也不像MSSQL日志那样有明确的执行语句回溯它的力量藏在格式的克制里——每一条记录都严格遵循%h %l %u %t %r %s %b %{Referer}i %{User-Agent}i这个模板像一份被压缩过的犯罪现场草图。你看到的192.168.1.100 - - [10/Jan/2024:14:23:15 0800] GET /login.jsp HTTP/1.1 200 1234 https://example.com/ Mozilla/5.0...其实是一组解码密钥192.168.1.100是作案车辆的VIN码[10/Jan/2024:14:23:15 0800]是GPS定位的时间戳GET /login.jsp HTTP/1.1是方向盘转向角度与油门深度的组合指令200是引擎是否成功点火的反馈而1234字节的响应体大小则暗示着这次“闯入”是否拿到了有效载荷。玄机靶场设计这个关卡根本不是考你能不能用grep找出异常IP而是看你能不能把日志还原成一场动态攻防推演。比如当你发现同一IP在3秒内连续发起7次POST /api/user/login请求且每次Referer字段都为空、User-Agent固定为curl/7.68.0这背后大概率不是脚本小子在试密码而是自动化工具在探测接口是否存在SQL注入点——因为真实浏览器发起的登录请求必然携带Referer来自登录页且User-Agent会随页面加载过程产生微小变化。这种细节只有把日志当“行车记录仪”反复回放才能捕捉到。所以别再把access.log当成待检索的文本库了。它是一份结构化的行为证据链每个字段都是一个可验证的动作节点。接下来我会带你一层层拆解Tomcat日志的物理结构、逻辑语义、实战分析路径以及玄机靶场里那些藏在状态码、URL编码、响应体大小背后的“反常即正常”信号。这不是教你怎么读日志而是教你如何让日志开口说话。2. 日志文件的物理切片access.log、catalina.out、localhost_access_log.txt谁在说真话在玄机靶场的Tomcat日志分析关卡里你拿到的原始数据包里通常包含三个核心日志文件access.log、catalina.out和localhost_access_log.txt。很多初学者一上来就埋头猛啃access.log结果漏掉了最关键的线索。这就像破案时只看监控录像却忽略了嫌疑人丢在现场的烟头和指纹。这三个文件不是冗余备份而是从不同维度记录同一场攻防事件的“三视角证词”必须交叉印证才能还原真相。2.1 access.log网络层的精准刻度尺access.log是Tomcat默认启用的访问日志由AccessLogValve组件生成其内容严格遵循NCSA Common Log Format或扩展格式。它的核心价值在于精确性和不可篡改性——只要请求抵达Tomcat的Connector端口无论后端Servlet是否处理成功、甚至是否真的存在这条记录都会被写入。这意味着它能捕获到所有“触达服务器”的流量包括大量扫描器发出的试探性请求。我们来看一个典型条目10.0.2.15 - - [10/Jan/2024:08:45:22 0000] GET /manager/html HTTP/1.1 401 1024 - python-requests/2.28.110.0.2.15源IP注意这里不是客户端真实IP而是经过NAT或代理后的地址。在靶场环境中这通常是虚拟机网卡IP。[10/Jan/2024:08:45:22 0000]请求到达时间时区为UTC0000这是关键玄机靶场所有日志时间统一为UTC如果你用本地时区解析时间线会彻底错乱。GET /manager/html HTTP/1.1请求行包含方法、URI和协议版本。URI/manager/html是Tomcat管理后台的经典路径出现即高危。401HTTP状态码表示“未授权”。这说明请求被Tomcat基础认证拦截但证明该路径确实存在且可访问——攻击者正通过401响应确认管理后台存活。1024响应体字节数。401响应通常返回一个标准HTML登录页大小约1024字节是合理值。如果这里显示0则说明请求被防火墙或WAF提前拦截未抵达Tomcat。提示在玄机靶场中access.log里的401、403、404状态码往往比200更值得深挖。因为200只代表“页面打开”而401/403证明目标路径存在且受保护404则可能暴露了攻击者尝试的非法路径如/WEB-INF/web.xml。2.2 catalina.out应用层的故障显微镜catalina.out是Tomcat启动脚本catalina.sh的标准输出重定向文件它记录的是JVM进程的stdout/stderr流。这里没有结构化字段全是纯文本堆栈和日志消息但它承载着access.log永远无法提供的信息Java层面的异常细节、类加载失败、数据库连接超时、甚至内存溢出OOM的完整堆栈。假设你在catalina.out里看到Jan 10, 2024 8:45:23 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet [jsp] threw exception org.apache.jasper.JasperException: Unable to compile class for JSP ... Caused by: java.io.FileNotFoundException: /usr/local/tomcat/work/Catalina/localhost/_/org/apache/jsp/login_jsp.java (No such file or directory)这段日志说明用户访问/login.jsp时JSP引擎试图编译该页面但找不到对应的.java源文件。这通常意味着/login.jsp是一个不存在的路径或者Web应用部署不完整。结合access.log中同一时间点的404记录就能确认这是一个无效路径探测——攻击者在枚举常见JSP页面。注意catalina.out中的时间戳格式为Jan 10, 2024 8:45:23 AM与access.log的[10/Jan/2024:08:45:22 0000]格式不同且时区也不同前者为系统本地时区后者为UTC。在玄机靶场中catalina.out的时间通常比access.log快8小时因靶场系统设为CST。做时间关联分析时必须先统一时区否则会错过关键时间窗口。2.3 localhost_access_log.txt虚拟主机的专属记事本这个文件名容易让人误解为“本地访问日志”实则是Tomcat为每个Host配置生成的独立访问日志。在默认配置中它与access.log内容高度重合但在多虚拟主机Virtual Host场景下它会按Host隔离记录。玄机靶场虽多为单Host但此文件仍具特殊价值它记录了Host头的真实值。例如当攻击者发送如下请求GET / HTTP/1.1 Host: evil.com User-Agent: curl/7.68.0access.log中%h字段仍显示源IP但localhost_access_log.txt的%vvirtual host字段会记录evil.com。这揭示了Host头攻击如Password Reset Poisoning的痕迹——攻击者试图通过伪造Host头诱导应用生成指向恶意域名的重置链接。在玄机靶场的进阶关卡中你可能会发现access.log里大量200请求但localhost_access_log.txt中对应条目的%v字段却是attacker.com。这就是典型的Host头污染证据仅靠access.log无法识别。2.4 三日志交叉验证实战一次真实的漏洞探测还原让我们用一个玄机靶场常见案例演示如何联动分析access.log线索10.0.2.15 - - [10/Jan/2024:08:45:20 0000] GET /webdav/ HTTP/1.1 401 1024 - sqlmap/1.7.2catalina.out线索Jan 10, 2024 4:45:21 PM org.apache.catalina.realm.JDBCRealm authenticateINFO: Failed authenticate() call for user adminlocalhost_access_log.txt线索10.0.2.15 - - [10/Jan/2024:08:45:20 0000] GET /webdav/ HTTP/1.1 401 1024 http://target.com/ sqlmap/1.7.2注意%v字段此处为target.com证明Host头合法推演过程时间上三条日志均发生在08:45:20-21 UTCcatalina.out的4:45:21 PM对应UTC08:45:21时间吻合。access.log和localhost_access_log.txt均显示/webdav/路径返回401证明WebDAV功能已启用且受认证保护。catalina.out中JDBCRealm authenticate失败日志说明认证后端是数据库且用户名admin被尝试。User-Agent为sqlmap/1.7.2结合/webdav/路径可判定这是sqlmap对WebDAV接口的自动化探测WebDAV常存在XML外部实体注入XXE漏洞。结论攻击者正利用sqlmap探测WebDAV服务的XXE漏洞且已确认目标存在该服务。此时若在catalina.out后续日志中发现org.apache.xerces.parsers.SAXParser相关异常则XXE已被触发。这三份日志如同三棱镜将同一束光折射出不同色彩。忽略任何一份都可能让关键线索从指缝中溜走。3. 状态码背后的攻防语言401不是拒绝是邀请函404不是消失是藏宝图在玄机靶场的Tomcat日志分析中新手常犯的最大错误是把HTTP状态码当作简单的“成功/失败”二元标签。他们看到200就认为“一切正常”看到404就划掉不看却不知这些数字是攻击者与防御系统之间无声对话的密码本。每一个状态码都对应着一次具体的交互意图和系统响应逻辑。读懂它等于拿到了攻防双方的实时对话记录。3.1 401 Unauthorized不是大门紧闭而是门锁已确认401状态码的官方定义是“请求要求用户的身份认证”但它在实战中的真实含义远不止于此。在Tomcat日志里401出现意味着目标路径真实存在否则会返回404该路径受Tomcat内置认证机制如Basic Auth、Digest Auth保护认证流程已启动但凭证未提供或错误。这三点构成了一个极具价值的攻击链路确认信号。我们来看玄机靶场中一个经典场景10.0.2.15 - - [10/Jan/2024:09:12:33 0000] GET /manager/html HTTP/1.1 401 1024 - Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 10.0.2.15 - - [10/Jan/2024:09:12:34 0000] GET /host-manager/html HTTP/1.1 401 1024 - Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 10.0.2.15 - - [10/Jan/2024:09:12:35 0000] GET /docs/ HTTP/1.1 200 12345 - Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36表面看前三行都是401最后一行是200。但深层解读是/manager/html和/host-manager/html返回401证明Tomcat管理后台和主机管理后台均已部署并启用且处于默认保护状态。这是高危资产暴露的铁证。/docs/返回200说明文档目录可公开访问攻击者可从中下载tomcat-docs.pdf等文件获取版本号、配置细节等情报。更关键的是401响应头中必然包含WWW-Authenticate字段如WWW-Authenticate: Basic realmTomcat Manager Application。这个realm值正是暴力破解时的用户名字典来源——攻击者会尝试admin:admin、tomcat:tomcat等默认凭据组合。因此在玄机靶场中一旦发现401下一步必然是检查catalina.out中是否有JDBCRealm或UserDatabaseRealm的认证失败日志从而确认后端认证方式。实操心得在玄机靶场搜索401时不要只看状态码更要关注URI路径。/manager/、/host-manager/、/scripts/、/WEB-INF/等路径的401优先级远高于/favicon.ico的401。后者可能是浏览器自动请求前者则是主动探测。3.2 403 Forbidden权限的边界也是越权的起点403与401常被混淆但二者有本质区别401是“你没带钥匙”403是“你有钥匙但没权限进这扇门”。在Tomcat中403通常由SecurityConstraint或Valve如RemoteAddrValve触发意味着请求已通过身份认证但在授权阶段被拒绝。一个典型例子10.0.2.15 - - [10/Jan/2024:09:25:11 0000] GET /admin/dashboard.jsp HTTP/1.1 403 1024 https://target.com/login.jsp Mozilla/5.0这里的关键线索是Referer: https://target.com/login.jsp。它表明用户是从登录页跳转而来大概率已通过认证。但访问/admin/dashboard.jsp却被403拒绝。这暗示两种可能角色权限不足用户登录后获得的是user角色而/admin/*路径要求admin角色IP白名单限制RemoteAddrValve配置了只允许127.0.0.1访问/admin/*而攻击者IP10.0.2.15被拒绝。在玄机靶场中403常与越权漏洞Insecure Direct Object Reference, IDOR关联。例如攻击者修改URL参数GET /api/user/profile?id1001→200GET /api/user/profile?id1002→403GET /api/user/profile?id1002roleadmin→200这说明后端仅校验了id参数未校验当前用户是否有权访问该id。403在此处不是终点而是越权尝试成功的分水岭。3.3 404 Not Found消失的路径藏着最危险的入口404常被当作“无意义”的噪音过滤掉但在高级日志分析中它是攻击者侦察活动的直接证据。404本身不危险但高频、有规律、针对敏感路径的404集合就是一张动态更新的攻击地图。我们分析一组玄机靶场常见的404序列10.0.2.15 - - [10/Jan/2024:09:30:01 0000] GET /phpmyadmin/ HTTP/1.1 404 1024 - sqlmap/1.7.2 10.0.2.15 - - [10/Jan/2024:09:30:02 0000] GET /pma/ HTTP/1.1 404 1024 - sqlmap/1.7.2 10.0.2.15 - - [10/Jan/2024:09:30:03 0000] GET /admin/phpmyadmin/ HTTP/1.1 404 1024 - sqlmap/1.7.2 10.0.2.15 - - [10/Jan/2024:09:30:04 0000] GET /mysql/ HTTP/1.1 404 1024 - sqlmap/1.7.2这四条记录IP、User-Agent、时间间隔1秒高度一致构成一个典型的“路径爆破”行为。攻击者在枚举MySQL管理后台的常见别名。虽然全部404但User-Agent为sqlmap/1.7.2证明这是自动化工具行为而非人工浏览。更危险的是404中的URL编码。例如10.0.2.15 - - [10/Jan/2024:09:35:10 0000] GET /login.jsp?username%27%20OR%20%271%27%271 HTTP/1.1 404 1024 - Mozilla/5.0%27是单引号的URL编码%20是空格整个参数username OR 11是经典的SQL注入payload。它返回404说明注入点不在username参数或后端已过滤。但这条日志的价值在于它证明攻击者正在测试/login.jsp的注入可能性且已掌握基础语法。避坑提醒在玄机靶场中不要用grep -v 404直接过滤掉所有404。正确做法是先用awk $9 ~ /^404$/ {print} access.log | sort | uniq -c | sort -nr统计高频404路径再结合User-Agent和时间分布判断是否为扫描行为。真正的威胁往往藏在“失败”之中。3.4 500 Internal Server Error服务器的求救信号500是Tomcat日志中最需警惕的状态码因为它意味着应用代码执行出错而错误详情可能被泄露。在开发环境Tomcat默认会将完整的Java堆栈打印到响应体中这相当于把服务器的“病历本”直接交给攻击者。一个危险的500日志10.0.2.15 - - [10/Jan/2024:09:40:22 0000] GET /search.jsp?keyword1%27%20AND%2012%20UNION%20SELECT%201,2,3,4,5-- HTTP/1.1 500 5678 - Mozilla/5.0500本身不说明问题但5678字节的响应体大小异常巨大普通错误页通常2KB。这强烈暗示堆栈信息被完整返回。此时应立即检查catalina.out寻找类似org.apache.jasper.JasperException: An exception occurred processing JSP page /search.jsp at line 45 ... Caused by: java.sql.SQLException: Column password not found in table usersColumn password not found暴露了数据库表结构users表和字段名password为后续的SQL注入提供了精准靶标。在玄机靶场中500日志的响应体大小是首要筛查指标——大于3000字节的500几乎必然包含堆栈。4. URL与参数的暗语解码从%2F到../WEB-INF/攻击者如何用编码绕过你的防线在玄机靶场的Tomcat日志里URL字段%r即GET /path?paramvalue HTTP/1.1是攻击者最活跃的“画布”。他们在这里书写各种编码、混淆、路径遍历的暗语而这些字符在日志中以原始形式呈现未经解码。如果你只用肉眼扫视就会错过所有精心设计的攻击意图。理解URL编码、路径遍历、参数污染的底层逻辑是读懂这份“暗语”的第一把钥匙。4.1 URL编码不只是%20更是攻击的变形衣URL编码Percent-encoding的规则是将非ASCII字符和保留字符如/,?,#,,等转换为%加两位十六进制数。但攻击者利用它远不止于传递空格。%2F斜杠/的编码。在Tomcat中%2F会被解码为/但某些WAF或中间件会将其视为普通字符串而放过。例如GET /images/%2F../WEB-INF/web.xml HTTP/1.1这等价于/images//../WEB-INF/web.xml利用双斜杠//绕过简单的路径过滤规则最终指向WEB-INF/web.xml。%00空字节Null Byte。在旧版Tomcat7.0.100中%00可用于截断字符串绕过文件扩展名检查。例如GET /upload.php?fileshell.jpg%00.php HTTP/1.1后端可能只检查shell.jpg的扩展名而忽略%00之后的.php导致上传恶意PHP文件。%25%自身的编码。这是编码嵌套的开始。%252F%2F/。攻击者用多层编码混淆检测GET /%252F%252E%252E%252F%2557%2545%2542%252D%2549%254E%2546%252Fweb.xml HTTP/1.1解码一层得%2F%2E%2E%2F%57%45%42%2D%49%4E%46%2Fweb.xml再解码得/../WEB-INF/web.xml。这种“编码套娃”是绕过基于正则的WAF的常用手法。在玄机靶场中搜索%2F、%2E.、%00、%25是发现路径遍历和Null Byte攻击的最快途径。命令grep -E %2F|%2E|%00|%25 access.log | head -204.2 路径遍历Path Traversal../不是错误是精准的手术刀路径遍历的核心思想是利用../向上回退目录层级突破Web根目录限制访问WEB-INF/、META-INF/等敏感目录。Tomcat默认禁止此类访问但攻击者会用各种变体绕过。标准遍历GET /images/../../../../etc/passwd HTTP/1.1→400 Bad RequestTomcat 8默认拦截变体绕过双写..GET /images/....//....//etc/passwd HTTP/1.1利用..被过滤后剩余././再与//组合形成有效路径。URL编码.GET /images/%2e%2e/%2e%2e/%2e%2e/etc/passwd HTTP/1.1%2e是.绕过对明文..的过滤。绝对路径GET /%57%45%42%2d%49%4e%46%2fweb.xml HTTP/1.1%57%45%42%2d%49%4e%46%2fWEB-INF/直接访问。在玄机靶场日志中WEB-INF、META-INF、classes/、lib/等路径的404或400是路径遍历探测的明确信号。尤其当Referer为空、User-Agent为curl或sqlmap时可信度更高。4.3 参数污染Parameter Pollution一个名字多重含义HTTP参数名重复时不同服务器处理方式不同PHP取第一个Java取最后一个Node.js取数组。攻击者利用此差异构造“参数污染”攻击。Tomcat基于Java Servlet规范默认取最后一个同名参数。例如GET /login.jsp?usernameadminusername%27%20OR%20%271%27%271 HTTP/1.1后端request.getParameter(username)返回 OR 11而非admin。更隐蔽的是利用和;分隔符GET /login.jsp?usernameadmin;password123usernameattacker HTTP/1.1Tomcat将;视为查询字符串结束符usernameattacker成为新参数覆盖前者。在玄机靶场中搜索[a-zA-Z].*[a-zA-Z].*模式可发现参数污染尝试。例如GET /api/user?uid1001uid1002tokenabc HTTP/1.1若业务逻辑依赖uid而uid1002被最终采用则可能造成IDOR。4.4 Referer与User-Agent伪装的面具也是溯源的指纹Referer和User-Agent字段常被攻击者伪造但它们的伪造痕迹恰恰是识别自动化工具的黄金特征。Referer为空-表示请求无Referer。浏览器点击链接或地址栏直接输入时Referer为空。但真实用户很少连续多次无Referer访问敏感路径如/manager/html。若发现10.0.2.15在1分钟内发起10次GET /manager/html且Referer全为-基本可判定为扫描器。User-Agent异常sqlmap/1.7.2、dirbuster/1.0、gobuster/3.5明确标识工具名和版本。Mozilla/5.0 (X11; Linux x86_64)Linux桌面环境但真实用户更常用Windows NT 10.0或Mac OS X。python-requests/2.28.1Python脚本特征真实浏览器绝不会用此UA。在玄机靶场中User-Agent是区分人工与自动化攻击的最可靠指标。命令awk {print $12} access.log | sort | uniq -c | sort -nr | head -10查看Top 10 UA若sqlmap、curl、python-requests占据前列即可确认扫描行为。5. 实战推演从玄机靶场一道题看懂一次完整的WebShell植入全过程现在让我们把前面所有知识点整合进一个玄机靶场的真实题目推演。这道题名为“Tomcat日志分析-WebShell植入痕迹”提供一份access.log和catalina.out的片段。目标是找出攻击者植入WebShell的路径、时间、方式及WebShell文件名。这不是理论而是你明天就要面对的实战。5.1 原始日志数据节选access.log:10.0.2.15 - - [10/Jan/2024:10:01:15 0000] GET / HTTP/1.1 200 1234 - Mozilla/5.0 10.0.2.15 - - [10/Jan/2024:10:01:16 0000] GET /manager/html HTTP/1.1 401 1024 - sqlmap/1.7.2 10.0.2.15 - - [10/Jan/2024:10:01:17 0000] GET /host-manager/html HTTP/1.1 401 1024 - sqlmap/1.7.2 10.0.2.15 - - [10/Jan/2024:10:05:22 0000] GET /manager/html HTTP/1.1 200 5678 http://target.com/manager/html Mozilla/5.0 10.0.2.15 - - [10/Jan/2024:10:05:23 0000] GET /manager/status HTTP/1.1 200 2345 http://target.com/manager/html Mozilla/5.0 10.0.2.15 - - [10/Jan/2024:10:05:24 0000] GET /manager/deploy?configfile:/tmp/shell.war HTTP/1.1 200 1024 http://target.com/manager/html Mozilla/5.0 10.0.2.15 - - [10/Jan/2024:10:05:25 0000] GET /shell/ HTTP/1.1 200 4567 - Mozilla/5.0 10.0.2.15 - - [10/Jan/2024:10:05:26 0000] GET /shell/cmd.jsp?cmdwhoami HTTP/1.1 200 123 - Mozilla/5.0catalina.out:Jan 10, 2024 6:05:24 AM org.apache.catalina.core.ApplicationContext log INFO: Manager: deploy WAR file [/tmp/shell.war] Jan 10, 2024 6:05:24 AM org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive [/usr/local/tomcat/webapps/shell.war] Jan 10, 2024 6:05:24 AM org.apache.catalina.startup.HostConfig deployWAR INFO: Deployment of web application archive [/usr/local/tomcat/webapps/shell.war] has finished in [123] ms5.2 分步推演攻击链还原Step 1侦察阶段10:01:15-10:01:17攻击
返回列表