前言：
在网络安全取证分析与渗透测试工作中，服务器镜像仿真、服务部署调试及安全漏洞挖掘是核心实操环节。本次针对 CentOS 7.9 服务器镜像展开全流程实操，从镜像仿真、nginx 服务配置、CRM 系统部署排障，到前端调试与账密突破，还原完整实操步骤，拆解核心技术要点与安全漏洞，为同类实操场景提供可落地的技术参考。
一、前期准备与镜像仿真
本次实操核心工具选用超级取证大师（镜像仿真）、Finalshell（远程连接）、记事本（配置编辑），全程基于 root 权限操作，为后续服务配置与系统分析搭建基础环境。
1.镜像仿真：通过超级取证大师成功仿真服务器镜像，镜像内操作系统为 CentOS 7.9，使用默认 root 账号（密码：123456）完成系统登录。
2.查看服务器 IP：执行基础指令获取服务器IP，为远程连接和后续服务配置提供基础。
# 查看服务器网卡及IP信息 ifconfig
3.远程连接：打开 Finalshell，新建连接并输入服务器 IP（192.168.145.128）、账号（root）、密码（123456），测试连接成功后，搭建后续全流程实操的远程操作环境。
二、nginx 服务配置与调试
初始状态下直接访问服务器 IP 返回 404 错误，经排查为 nginx 未配置 IP 访问规则，且存在域名强制跳转、HTTPS 未配置等问题，通过分步配置 IP 访问、生成自签名证书、修复静态资源权限，实现 nginx 服务正常访问。
1.初始问题排查：执行cat /etc/nginx/nginx.conf和ls /etc/nginx/conf.d/查看 nginx 核心配置，发现配置文件仅支持域名访问，无 IP 访问相关规则，导致直接访问 IP 触发 404。
尝试访问：
2.配置 IP 访问规则：新建ip-access.conf配置文件，指定服务器 IP 为访问地址，初始复用/data/www/official-website/home为网站根目录，完成基础 IP 访问配置。
#新建并编辑nginx IP访问配置文件：
cat > /etc/nginx/conf.d/ip-access.conf << ‘EOF’#初始配置内容：
server { listen 80; server_name 192.168.145.128; root /data/www/official-website/home;index index.html index.htm;}
重启尝试：
在浏览器打开发现强制跳转至https需要配置https 3.HTTPS 自签名证书配置：配置 IP 访问后发现存在 HTTPS 强制跳转问题，通过 OpenSSL 生成自签名 SSL 证书，存放于/etc/nginx/ssl目录，修改配置文件实现 HTTPS 访问。
# 创建证书专属存放目录# 生成2048位RSA私钥# 生成证书请求文件并创建自签名证书（有效期365天，一路回车默认配置）
mkdir -p /etc/nginx/ssl && openssl req -x509 -days 365 -nodes -newkey rsa:2048 -keyout /etc/nginx/ssl/ip.key -out /etc/nginx/ssl/ip.crt
配置nginx：
cat /etc/nginx/conf.d/ip-access.conf << 'EOF'server { listen 443 ssl; server_name 192.168.145.128; ssl_certificate /etc/nginx/ssl/ip.crt; ssl_certificate_key /etc/nginx/ssl/ip.key; location / { root /data/www/official-website/home; try_files $uri $uri/ /index.html; index index.html index.htm; }}EOF
#重启nginx生效配置
成功访问
4.静态资源与权限修复：配置 HTTPS 后发现静态资源（CSS/JS/ 图片）加载失败，经排查为根目录映射错误 + 目录权限不足，调整根目录并赋予 nginx 对应读写执行权限，最终实现网站正常访问。
# 调整nginx目录权限，赋予nginx用户读写执行权限chmod -R 755 /data/www/official-websitechown -R nginx:nginx /data/www/official-website
# 调整文件目录初始：
查找正确目录：
找出正确路径，根目录为/data/www/official-website，将根目录拿至全局
在此操作下首页路径会出错，需要调整首页路径
server {
listen 443 ssl;
server_name 192.168.145.128;
ssl_certificate /etc/nginx/ssl/ip.crt;
ssl_certificate_key /etc/nginx/ssl/ip.key;
# 修正后网站根目录
root /data/www/official-website;
location / {
try_files $uri $uri/ /index.html;
# 重新指定默认首页路径
index /home/index.html index.htm;
}
}
重启nginx之后就能正常访问
三、CRM 系统部署与问题排查
对于此服务器虽然已经将网站部署，但是我们的取证目标是其后台登录系统！
接下来的操作目标就是将其找出并成功运行！
在/data/crm/server目录发现 CRM 系统核心包crm-admin.jar，启动后进程立刻退出，按「定位根因→解决根因→配套完善→验证启动」 的实操逻辑，完成全流程排障，最终实现 CRM 后端（8080 端口）成功启动。
jar包情况：
配置文件定位与验证：
在jar包外有application配置文件，需要修改配置时可以对application进行修改并在启动指令中加上它，就不需要修改已经打包好的jar包
打开application查找关键词profiles
找到了druid，说明这个文件也得同步带上，它实际上就是数据库的配置文件
初始 Jar 包启动与根因定位：进入 CRM 目录执行启动指令，发现进程启动后立刻退出，通过查看启动日志精准定位核心问题。
# 进入CRM服务器端目录
cd /data/crm/server
# 前台启动Jar包，查看实时启动日志
java -jar crm-admin.jar
# 查看CRM核心启动日志，定位失败原因
tail -f /data/crm/server/logs/sys-error.log
核心问题分析：从日志中提取核心报错，确定阿里云 RDS 数据库域名解析失败为唯一根因，该问题衍生出后续一系列连锁错误：
① 域名解析失败：java.net.UnknownHostException: pc-wz91285gpe3tl28d8.rwlb.rds.aliyuncs.com，服务器无法将 RDS 域名解析为对应 IP，无法建立数据库连接；
② 数据库连接异常：org.springframework.jdbc.CannotGetJdbcConnectionException: Failed to obtain JDBC Connection，程序重试 3 次后仍无法连接，放弃数据库操作；
③ Bean 初始化失败：org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sysConfigServiceImpl'，服务层核心 Bean 初始化时执行数据库查询，因连接失败导致初始化出错；
④ 依赖注入失败：org.springframework.beans.factory.UnsatisfiedDependencyException，sysRoleController/sysUserServiceImpl等核心组件依赖未初始化的 Bean，注入流程中断；
⑤ Spring 容器启动失败：org.springframework.boot.SpringApplication: Application run failed，核心 Bean 缺失导致整个 Spring 容器无法完成初始化，最终 CRM 进程退出。
本地 MySQL 环境修复：因 RDS 数据库解析失败，选择不使用。但是代码逻辑必须要有数据库，决定将 CRM 数据库切换至本地 MySQL，首先修复本地 MySQL 权限不足、运行目录缺失等问题，确保本地数据库环境可用。
查看本地MySQL情况：
修复权限问题：
# 修复MySQL数据目录及文件权限
chmod -R 755 /var/lib/mysql
chown -R mysql:mysql /var/lib/mysql
# 新建MySQL运行目录并修复权限
mkdir -p /var/run/mysqld
chown -R mysql:mysql /var/run/mysqld
# 启动MySQL服务并查看运行状态
systemctl start mysqld
systemctl status mysqld
尝试登录MySQL
发现root的密码并不是默认的123456
在配置文件中查找关键词password
尝试找到共用密码
使用配置文件中找出的密码进行尝试
成功
CRM 数据库配置修改（核心根因解决）：本地 MySQL 环境修复后，直接定位并修改 CRM 核心数据库配置文件，将原 RDS 数据库连接信息替换为本地 MySQL，从配置层面彻底解决根因。
修改本地数据库连接配置：
编辑application-druid.yml，删除原 RDS 数据库远程连接配置，替换为本地 MySQL 的连接信息，适配本地数据库环境：
同时将配置文件中的账密修改成root+找出的密码
CRM 核心数据表补全：本地 MySQL 环境修复、CRM 数据库配置修改完成后，在本地 MySQL 中创建 CRM 专属数据库并补全核心缺失数据表，解决表结构不匹配问题，为 CRM 启动做好数据层配套。
日志报错数据库对不上：
补全数据库表：
在完成以上修正之后启动jar包：
日志提示redis指向aliyun出错，使用与数据库同样的方法，将配置文件路径指向本地redis并修改端口。
CRM 后端服务启动与验证：所有根因解决 + 配置、数据层配套完善后，后台启动 CRM Jar 包，验证 8080 端口监听状态，确认后端服务成功启动。
启动：
cd /data/crm/server
java -jar crm-admin.jar --spring.config.location=application.yml,application-druid.yml
四、前端配置与登录调试
CRM 后端（8080 端口）成功启动后，nginx重新部署前端访问存在路由刷新 404和验证码接口 404两个核心问题，通过修改 nginx 配置，添加前端路由兼容规则、配置接口反向代理、关闭验证码接口自动重定向，实现前后端正常交互。
在上述操作完成，后端修复成功后，显示前端进行同步
决定使用nginx来部署前端，舍弃原搭建好的网站前端，改为crm系统前端
前端路由与反向代理配置：CRM 前端代码存放于/data/crm/web，修改 nginx 的ip-access.conf配置，指定前端根目录，添加路由兼容规则，并将/api前缀接口反向代理至后端 8080 端口，解决跨域与路由刷新问题。
# 编辑nginx IP访问配置文件
vi /etc/nginx/conf.d/ip-access.conf
添加 CRM 前端专属配置：
nginx
# CRM前端服务配置
server {
listen 80;
server_name 192.168.145.128;
root /data/crm/web;
index index.html index.htm;
# 解决前端路由刷新404
location / {
try_files $uri $uri/ /index.html;
}
# /api接口反向代理至后端8080端口
location /api/ {
proxy_pass http://127.0.0.1:8080/api/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
启动前后端之后状态：
验证码接口异常修复：配置完成后，前端登录页调用/api/captchaImage获取验证码返回 404，经排查为 nginx 自动重定向将后端 401 未授权响应强制转为 404，单独为验证码接口关闭重定向，保留原始响应。
异常接口显示404：
后端访问却显示401
在确认路径无误后，前后端有不同的返回，猜测是nginx重定向原因
正确情况下的运行逻辑：
前端提交验证码接口访问请求至后端->后端返回401认证失败->nginx从后端收取401返回前端->前端启动重新鉴权请求，从本地取token等认证信息提交至后端->后端认证成功返回200正常访问
但是nginx重定向之后就发生错误：
前端提交验证码接口访问请求至后端->后端返回401认证失败->nginx从后端收取401发现暂时没法访问，重定向到类似/login的路径，实际上没有这个路径，就返回404至前端->前端收到404以为没有验证码接口，便不再启动重新鉴权请求->返回404
所以请求后端是401，请求前端因为有nginx重定向返回404
因此需要将nginx重定向关闭
# 编辑nginx配置文件，添加验证码接口专属规则
vi /etc/nginx/conf.d/ip-access.conf
在 CRM 前端server配置块中添加：
# 验证码接口专属配置，关闭自动重定向
location /api/captchaImage {
proxy_pass http://127.0.0.1:8080/api/captchaImage;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_redirect off;
}
# 检查nginx配置语法，重载配置生效
nginx -t
nginx -s reload
完成系统部署：
五、账密突破方案：CRM 系统安全漏洞挖掘与实战
通过分析 CRM 系统登录模块核心源码，发现基于org.springframework.security.authentication的认证机制存在双重关键漏洞，结合数据库表操作，实现无需正确账号密码、跳过二次校验的无权限登录，完成 CRM 系统渗透突破。
核心漏洞发现与源码分析：通过反编译 CRM Jar 包获取登录模块核心源码，定位到密码认证绕过和二次校验绕过两个可利用漏洞，核心源码与漏洞逻辑如下：
① 密码认证绕过漏洞：系统自定义认证提供者CustomAuthenticationProvider中，存在硬编码的特殊密码校验逻辑，当输入密码为固定值CUSTOM_LOGIN_SMS时，将直接跳过原始密码的加密校验流程，直接判定身份验证通过。
核心源码：
@Override
public Authentication authenticate(Authentication authentication) throws AuthenticationException {
String username = authentication.getName();
String password = authentication.getCredentials().toString();
if ("CUSTOM_LOGIN_SMS".equals(password)) {
SysUser user = userService.getUserByUsername(username);
if (user != null && user.getStatus() == 0) {
List authorities = getAuthorities(user.getRoles());
return new UsernamePasswordAuthenticationToken(user, password, authorities);
}
}
// 正常密码加密校验逻辑
SysUser user = userService.getUserByUsername(username);
if (user == null || !BCrypt.checkpw(password, user.getPassword())) {
throw new BadCredentialsException("账号或密码错误");
}
List authorities = getAuthorities(user.getRoles());
return new UsernamePasswordAuthenticationToken(user, password, authorities);
}
② 二次校验绕过漏洞：密码验证通过后，系统会触发登录二次短信校验流程，该校验逻辑由needSmsVerify方法控制，若用户账号关联NoSmsVerify专属角色标识，方法将直接返回false，跳过所有二次短信校验流程。
核心源码：
public boolean needSmsVerify(SysUser user) {
SysDept dept = getDeptUp(user.getDeptId());
Object[] roles = user.getRoles().stream().map(SysRole::getRoleKey).toArray();
if (ArrayUtil.containsAny(roles, new Object[]{"NoSmsVerify"})) {
return false;
}
if (Objects.isNull(dept) || Objects.isNull(dept.getLevel())) {
return true;
}
if (StrUtil.isBlank(dept.getWhiteListIp()) && dept.getLevel().intValue() == 4) {
return true;
}
if (dept.getLevel().intValue() <= 3) {
return true;
}
return false;
}
账密突破实操步骤：基于上述两个漏洞，通过 MySQL 操作在本地 CRM 数据库中新增超级管理员账号、添加NoSmsVerify免校验角色并建立账号角色关联，最终实现无权限登录，全程操作如下：
# 登录本地MySQL，进入CRM业务数据库
mysql -uroot -p(密码)
USE crm;
① 新增超级管理员账号：在sys_user表中插入superadmin账号，密码可随意填写（后续将通过特殊密码绕过校验），确保账号状态为启用、未删除：
INSERT INTO sys_user (username, password, dept_id, status, del_flag)
VALUES ('superadmin', '123456', 1, 0, 0);
② 新增NoSmsVerify免二次校验角色：在sys_role表中插入专属免校验角色，确保role_key为NoSmsVerify（与源码校验值完全一致）、角色状态为启用：
INSERT INTO sys_role (role_id, role_key, role_name, status)
VALUES (106, 'NoSmsVerify', '免二次短信校验角色', 0);
③ 建立账号与免校验角色的关联：在sys_user_role用户角色关联表中，将新增的superadmin账号与NoSmsVerify角色进行绑定，实现二次校验绕过：
INSERT INTO sys_user_role (user_id, role_id)
VALUES ((SELECT user_id FROM sys_user WHERE username='superadmin'), 106);
④ 退出 MySQL 数据库，完成所有配置操作：
exit;
最终突破登录：完成上述数据库操作后，返回 CRM 前端登录页面，输入账号：superadmin、密码：CUSTOM_LOGIN_SMS，点击登录即可实现无权限突破，登录逻辑如下：
密码校验阶段：输入的密码CUSTOM_LOGIN_SMS触发源码硬编码逻辑，直接跳过密码加密校验，系统判定身份验证通过；
二次校验阶段：因superadmin账号关联了NoSmsVerify角色，系统直接跳过二次短信校验流程，无额外验证步骤；
最终结果：成功绕过账号密码校验和二次短信校验，直接登录 CRM 系统并获取超级管理员对应操作权限。
至此完成整个服务器的部署与破解
六、实操总结与安全启示
本次针对 CentOS 服务器镜像完成了从镜像仿真、服务配置到 CRM 系统渗透的全流程实操，覆盖 Linux 系统运维、nginx 中间件配置、Java 应用排障、MySQL 数据库调试、网络安全漏洞挖掘等多个技术领域。
系统安全漏洞启示：本次 CRM 系统暴露的两个核心漏洞，均为基础代码逻辑设计缺陷，属于开发阶段易忽视、但安全风险极高的典型问题，一是硬编码特殊密码实现身份校验绕过，直接突破系统第一道身份验证防线；二是通过单一角色标识控制核心二次校验流程，未做多重校验与权限校验，易被攻击者利用实现二次验证绕过。企业在开发系统时，应做好三点基础安全防护：
① 彻底移除所有硬编码的密码、密钥、校验规则等敏感信息，统一采用加密存储 + 加密校验的方式实现身份验证，杜绝任何形式的校验绕过逻辑；
② 优化权限控制与业务校验机制，避免单一参数、单一角色控制核心业务流程，结合账号权限、登录 IP、设备信息、短信 / 验证码等多维度实现多重验证；
③ 严格控制数据库操作权限，对用户、角色、权限关联等核心业务表做精细化操作限制，禁止低权限账号执行新增、修改、删除、关联等高危操作，同时做好数据库操作日志审计。
实操价值：本次全流程实操所涉及的服务器镜像仿真、Linux 系统基础运维、nginx 中间件配置与调试、Java 应用启动排障、MySQL 数据库配置与建表、网络安全漏洞挖掘与利用等技能，是网络安全取证分析、渗透测试工程师及企业日常服务器运维人员的必备基础技能。本次所有操作步骤、命令配置、代码片段均经过实际场景验证。
写在最后
本次实操从基础的服务器镜像仿真到复杂的应用部署调试，再到最终的安全漏洞挖掘与利用，每一步操作都有明确的目标、可验证的结果，确保实操过程的严谨性与可复现性。在网络安全领域，实操是检验知识的唯一标准，唯有通过大量的真实场景实操，积累排障经验、熟悉漏洞原理、掌握利用方法，才能真正提升问题解决与漏洞挖掘的核心能力。
后续我们将持续分享更多实操干货与核心技术要点，敬请关注！