网络安全实战：服务器加固、流量分析与渗透测试避坑指南

发布时间：2026/10/26 2:12:29

简介：本资源为2021年全国职业院校技能大赛网络安全竞赛官方试题文档，面向高职高专及中职院校网络安全专业师生、备赛指导教师与初/中级渗透测试学习者，聚焦实战型安全加固能力训练。试题覆盖五大核心模块：A-1至A-6任务分别对应登录安全加固（Win/Linux双平台）、数据库加固（MySQL权限与账户安全）、流量完整性保护（IIS HTTPS重定向）、Windows事件审计策略配置、SSH/VSFTPD/IIS服务加固及防火墙策略（端口禁用、ICMP控制、IP白名单），内容深度贴合国赛评分标准与真实攻防场景。资源为单个119KB的DOCX文件，结构清晰、步骤详实，含命令行参数、配置路径、截图提示及典型错误规避说明，可直接用于模拟演练、教学拆解或考点复盘。目前已有959人学习下载，是掌握系统级安全加固全流程、理解多平台协同防护逻辑的高价值备赛资料。

1. 这份2021年国赛题不是“考完就扔”的模拟卷，而是我带三届学生打穿加固—取证—渗透全链路的实战沙盒

去年带某高校网安集训队复盘时，一个学生指着A-5任务里vsftpd的idle_session_timeout=600参数问我：“老师，为什么设600秒而不是300？超时太短会不会误杀合法上传？”——我没直接答，而是翻出他上个月在真实企业服务器上配错data_connection_timeout导致ERP系统文件上传卡死的日志。那一刻我意识到：这份题从来不是考你“会不会点菜单”，而是考你在没有GUI、没有报错提示、只有命令行和日志的黑匣子里，能不能靠参数逻辑推演出服务的真实行为边界。它把Windows策略组、Linux内核参数、MySQL权限模型、IIS模块加载机制、Wireshark协议栈解析、Volatility内存对象关系……全拧成一根绳，逼你用同一套安全思维去解不同系统的结。新手照着步骤能跑通A-1到A-6，但真正拉开差距的，是B模块里从hashdump提取的NTLMv2哈希，到用john --wordlist=rockyou.txt --format=NT hash.txt爆破时，你是否记得加--fork=4避免Kali虚拟机内存溢出——这种血泪经验，文档里不会写，但决赛现场会卡死你十分钟。这篇就带你一节一节拆开这份题，不讲“应该怎么做”，只说“我当时怎么想、为什么这么调、翻车后怎么救”。

2. 服务器与数据库加固：别被“设置密码长度16位”骗了，真正的坑在策略生效的底层链路上

2.1 Windows密码策略的四个生效层级：从组策略刷新到域控同步的断点排查

很多人以为在“本地安全策略”里改了最小密码长度=16就万事大吉，结果测试时user1还能用8位密码登录。问题出在策略生效的四个断点上：

第一层：组策略对象（GPO）链接位置
本地安全策略只影响本机，若服务器加入域，必须检查域控制器上的GPO是否链接到该OU。用gpresult /h report.html生成报告，重点看“应用的组策略对象”列表里是否有冲突策略（比如某条旧策略强制设为8位）。
第二层：策略刷新延迟
gpupdate /force强制刷新后，需等待secedit /refreshpolicy machine_policy完成。常见翻车点：执行gpupdate后立刻测登录，此时LSASS进程尚未重载新策略。验证方法：net user user1查看“密码最后设置时间”，若未更新说明策略未生效。
第三层：密码历史缓存
即使新策略要求16位，若user1上次密码是8位且未过期，系统允许沿用。必须用net user user1 *强制重置密码，此时才会触发新长度校验。
第四层：SAM数据库加密算法
Windows Server 2012+默认启用LMSHARE，但若兼容旧系统开启LANMAN，密码会被截断为14字符。检查注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LMCompatibilityLevel，值必须≥5（仅NTLMv2）。

提示：所有加固操作前先执行sfc /scannow修复系统文件，避免因DLL损坏导致策略加载失败。

2.2 Linux密码策略的`/etc/login.defs`陷阱：PASS_MIN_LEN只是冰山一角

修改PASS_MIN_LEN 16看似简单，但实际生效需满足三个条件：

条件一：PAM模块必须启用pam_pwquality.so
检查/etc/pam.d/common-password是否存在password requisite pam_pwquality.so retry=3。若只有pam_unix.so，改login.defs无效。修复命令：
```
# Ubuntu系 sudo apt install libpam-pwquality echo "password requisite pam_pwquality.so retry=3 minlen=16" | sudo tee -a /etc/pam.d/common-password
```
条件二：用户密码必须通过chpasswd或passwd重置
直接改/etc/shadow的密码字段（如$6$...）不触发PAM校验。必须用echo "user1:P@ssw0rd1!" | chpasswd，否则旧密码仍可用。
条件三：SSH登录绕过PAM的风险
若/etc/ssh/sshd_config中UsePAM no，则SSH登录不校验密码强度。必须设为yes并重启sshd。

2.3 MySQL加固的致命误区：MD5加密不是加固，是自废武功

题目要求UPDATE user SET password=MD5(password) WHERE user='user1'，这是典型教学陷阱。真实场景中：

MySQL 5.7+已废弃PASSWORD()函数，MD5()返回32位字符串，但MySQL内部存储的是41位哈希（*HASH格式）。直接UPDATE会导致密码无法验证。

正确做法是用ALTER USER：

ALTER USER 'user1'@'localhost' IDENTIFIED WITH mysql_native_password BY 'P@ssw0rd1!';

更关键的是权限粒度：题目要求GRANT SELECT,INSERT,DELETE,UPDATE ON testdb.*，但若testdb不存在，授权会静默失败。必须先CREATE DATABASE testdb;再授权，否则user1连接后执行USE testdb报错Unknown database。

2.4 用户时间限制的Windows玄学：net user /time的时区坑

net user user1 /time:M-F,9:00-18:00表面无错，但实测发现周五18:00后仍可登录。原因在于：

Windows时间策略以本地时区为准，若服务器时区设为UTC+0，而管理员按北京时间（UTC+8）配置，实际生效时段是UTC时间1:00-10:00（即北京时间9:00-18:00），但系统显示的“当前时间”是UTC，导致认知偏差。
验证方法：systeminfo | findstr "时区"确认时区，再用tzutil /g获取时区ID，比对control panel > date and time > time zone是否一致。

2.5 常见问题与避坑清单：加固操作中高频翻车点

现象	原因	解决方案
Linux修改`/etc/issue`后SSH登录无欢迎语	`/etc/ssh/sshd_config`中`Banner`路径指向错误，或文件权限非644	`sudo chmod 644 /etc/ssh/banner && sudo systemctl restart sshd`，用`sshd -T \| grep banner`验证配置加载
IIS HTTPS重定向后网站白屏	URL重写规则未排除`.well-known/acme-challenge/`路径，导致Let's Encrypt证书验证失败	在IIS重写规则中添加条件：`{REQUEST_URI} NOT MATCHES ^/.well-known/`
MySQL删除test库后`SHOW DATABASES`仍显示test	`DROP DATABASE test;`执行成功，但`FLUSH PRIVILEGES;`未执行，权限缓存未更新	执行`FLUSH PRIVILEGES;`后重启mysqld服务
VSFTPD设置`idle_session_timeout=300`后FTP客户端频繁断连	客户端KeepAlive未开启，300秒无命令即断开，但数据传输中无命令发送	在客户端配置`ftp -e "set ftp:keepalive on"`，或服务端增加`tcp_keepalive_interval=60`
Windows防火墙禁用445端口后SMB共享不可用	防火墙规则应用顺序错误，新规则被默认“允许局域网”规则覆盖	在高级安全防火墙中，将445端口规则移到规则列表顶部，并勾选“启用此规则”

3. 流量保护与事件监控：HTTPS重定向不是配个URL就行，而是要懂TLS握手与HTTP状态码的博弈

3.1 IIS HTTP→HTTPS重定向的三种实现方式对比：URL重写 vs HTTP响应头 vs 应用层跳转

题目指定用IIS URL重写，但实际部署中必须理解三种方式的适用场景：

URL重写（推荐）：在IIS管理器中启用“URL重写”模块，添加入站规则：
- 匹配URL：(.*)
- 条件：{HTTPS} OFF
- 操作：重定向到https://{HTTP_HOST}/{R:1}，状态码301
  优势：不修改应用代码，支持通配符；风险：若网站有多个域名（如www.test.com和test.com），需在条件中增加{HTTP_HOST} ^(www\.)?test\.com$，否则重定向到错误域名。

HTTP响应头（备用）：在web.config中添加：

<system.webServer> <httpProtocol> <customHeaders> <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" /> </customHeaders> </httpProtocol> </system.webServer>

作用：HSTS头强制浏览器后续请求走HTTPS，但首次访问仍是HTTP，存在中间人攻击窗口。

应用层跳转（慎用）：在ASP.NET中写if (!Request.IsSecureConnection) Response.Redirect("https://" + Request.Url.Host + Request.Url.PathAndQuery);
致命缺陷：若用户访问http://test.com/admin/login.aspx，跳转后变成https://test.com/admin/login.aspx，但原始POST数据丢失，导致登录失败。

3.2 审核策略的“成功/失败”双开关逻辑：为什么只开“成功”会漏掉暴力破解

Windows审核策略中，“登录事件”需同时勾选“成功”和“失败”。原因在于：

成功登录日志（Event ID 4624）：记录正常登录，用于审计合规性。
失败登录日志（Event ID 4625）：记录密码错误、账户锁定等，是检测暴力破解的唯一依据。
若只开“成功”，当黑客用hydra -l admin -P wordlist.txt rdp://192.168.1.100爆破时，日志中只有大量4625事件，但若未开启“失败”审核，则这些事件根本不会写入安全日志。

验证方法：

# 查看当前审核策略 auditpol /get /category:"Logon/Logoff" # 启用登录失败审核 auditpol /set /category:"Logon/Logoff" /failure:enable

3.3 IIS日志字段的W3C格式陷阱：为什么“用户名”字段常为空

题目要求日志记录“用户名”，但实测发现该字段多为“-”。因为：

W3C日志的cs-username字段仅记录Windows身份验证（NTLM/Kerberos）的用户名，若网站用Forms认证或Basic认证，该字段为空。
正确做法：在IIS日志字段中勾选cs-auth-user（认证用户名），该字段对所有认证方式有效。
若仍为空，检查应用池身份是否为ApplicationPoolIdentity，需赋予其读取日志目录权限：
```
icacls "C:\inetpub\logs\LogFiles" /grant "IIS AppPool\DefaultAppPool":(OI)(CI)RX
```

3.4 并发连接数限制的性能悖论：设1000真能防DDoS吗？

最大并发连接数=1000看似合理，但实际可能加剧服务崩溃：

Windows Server 2019默认连接数上限为5000，设1000反而降低吞吐。

真正防DDoS需结合连接速率限制：在IIS URL重写中添加规则，对单IP每分钟请求数>100的IP返回429状态码。
规则XML：

<rule name="RateLimit" stopProcessing="true"> <match url=".*" /> <conditions> <add input="{REMOTE_ADDR}" pattern="^(\d{1,3}\.){3}\d{1,3}$" /> </conditions> <serverVariables> <set name="RATELIMIT" value="1" /> </serverVariables> </rule>

3.5 常见问题与避坑清单：HTTPS与日志配置的隐性故障

现象	原因	解决方案
HTTPS重定向后Chrome提示“您的连接不是私密连接”	证书绑定到`test.com`，但用户访问`www.test.com`，SNI不匹配	在IIS绑定中为`www.test.com`单独添加证书，或使用通配符证书`*.test.com`
IIS日志中“客户端IP地址”显示为127.0.0.1	网站前端有Nginx反向代理，未配置`X-Forwarded-For`头传递	在Nginx配置中添加`proxy_set_header X-Forwarded-For $remote_addr;`，IIS日志字段勾选`X-Forwarded-For`
审核策略开启后磁盘空间暴涨	安全日志默认大小512MB，满后覆盖旧日志，但若日志满且未配置自动备份，关键事件被覆盖	用`wevtutil sl Security /ms:512000000`将日志大小设为500MB，并启用“日志满时自动备份”
IIS最大并发连接数设1000后网站响应变慢	应用池队列长度（Queue Length）默认1000，连接数限制与队列长度冲突	在应用池高级设置中，将“队列长度”设为5000，避免请求排队超时
HTTPS重定向规则导致API接口405错误	重写规则未排除`/api/`路径，POST请求被301重定向为GET	在URL重写条件中添加`{REQUEST_URI} NOT MATCHES ^/api/`

4. 服务加固与防火墙：SSH端口改2222只是开始，真正的战场在连接建立前的三次握手

4.1 SSH加固的深度配置：Port与PermitRootLogin之外的五个必改项

仅改端口和禁root远远不够，生产环境必须调整以下参数：

LoginGraceTime 30：登录超时从默认120秒缩短至30秒，减少暴力破解尝试窗口。
MaxAuthTries 3：单次连接最多3次密码尝试，超过即断开。
ClientAliveInterval 300：服务器每300秒发心跳包，配合ClientAliveCountMax 0（0表示不重试），5分钟无响应即断连。
UseDNS no：禁用DNS反向解析，避免因DNS故障导致登录延迟。
AllowUsers user1：显式指定允许登录用户，比DenyUsers root更安全（白名单优于黑名单）。

配置后验证：

# 检查配置语法 sudo sshd -t # 重载配置（不中断现有连接） sudo systemctl reload sshd # 查看当前SSH连接状态 sudo ss -tnp \| grep :2222

4.2 VSFTPD的匿名上传禁用原理：anonymous_enable=NO不是终点，而是起点

anonymous_enable=NO仅禁用匿名登录，但若local_enable=YES且write_enable=YES，本地用户仍可上传。必须组合配置：

anon_upload_enable=NO：禁用匿名用户上传（即使已登录）。
anon_mkdir_write_enable=NO：禁用匿名用户建目录。
chroot_local_user=YES：将本地用户限制在主目录，防止越权访问。
allow_writeable_chroot=YES：解决chroot后目录不可写的经典问题（需VSFTPD 3.0.0+）。

注意：chroot_local_user=YES后，用户主目录权限必须为755且属主为root，否则VSFTPD拒绝启动。

4.3 Linux防火墙的iptables链式思维：为什么`-j DROP`必须放在`-j ACCEPT`之后

题目要求iptables -A INPUT -s 172.16.1.1 -p tcp --dport 22 -j ACCEPT，但若这条规则在-j DROP之后，则永远不生效。iptables规则按自上而下顺序匹配，一旦匹配即执行动作并停止遍历。

正确顺序：

# 1. 先放行可信IP sudo iptables -I INPUT 1 -s 172.16.1.1 -p tcp --dport 22 -j ACCEPT # 2. 再拒绝其他IP的22端口 sudo iptables -I INPUT 2 -p tcp --dport 22 -j DROP # 3. 保存规则（Ubuntu需安装iptables-persistent） sudo netfilter-persistent save

4.4 禁Ping的三种方法实效对比：临时/永久/防火墙方案的适用场景

方法	临时性	影响范围	推荐场景
`echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_all`	重启失效	全局	快速测试网络连通性
`sysctl -w net.ipv4.icmp_echo_ignore_all=1`	重启失效	全局	脚本化临时加固
`iptables -A INPUT -p icmp --icmp-type 8 -j DROP`	持久（需保存）	仅INPUT链	生产环境首选，可精确控制源IP

提示：禁Ping后，ping命令失效，但telnet ip 22仍可检测端口开放，不影响业务。

4.5 常见问题与避坑清单：服务加固中的隐蔽失效点

现象	原因	解决方案
SSH改端口2222后无法连接	防火墙未开放2222端口，或SELinux阻止新端口	`sudo firewall-cmd --permanent --add-port=2222/tcp && sudo firewall-cmd --reload`；SELinux下执行`sudo semanage port -a -t ssh_port_t -p tcp 2222`
VSFTPD设置`idle_session_timeout=300`后FileZilla报“连接超时”	FileZilla默认KeepAlive间隔为30秒，小于300秒但未发送空包	在FileZilla设置中，将“FTP Keep-alive命令间隔”设为200秒，或服务端增加`tcp_keepalive_time=600`
iptables禁止23端口后Telnet仍可连接	规则添加到OUTPUT链而非INPUT链，或规则顺序错误	`sudo iptables -L INPUT -n \| grep 23`确认规则在INPUT链，且位置正确
IIS日志中“方法”字段显示为OPTIONS而非GET/POST	浏览器预检请求（CORS）触发OPTIONS方法，非真实业务请求	在IIS日志字段中取消勾选`cs-method`，改用`cs-uri-stem`分析真实路径
MySQL改用户为SuperRoot后phpMyAdmin无法登录	phpMyAdmin默认连接用户为`root`，未更新配置文件`config.inc.php`	修改`$cfg['Servers'][$i]['user'] = 'SuperRoot';`并重启Apache

5. 内存取证与流量分析：从`hashdump`到`Flag{ip:端口}`，每一步都是逆向思维的具象化

5.1 Volatility内存取证的版本适配：为什么`hashdump`在Win10上常失败

volatility -f memory.dmp --profile=Win7SP1x64 hashdump在Win10内存镜像中大概率报错，因：

Win10 RS5+引入KASLR（内核地址随机化），hashdump依赖的_SEP_TOKEN_PRIVILEGES结构偏移动态变化。

正确姿势是先用imageinfo确定profile：

volatility -f memory.dmp imageinfo # 输出中选择最匹配的profile，如Win10x64_17134 volatility -f memory.dmp --profile=Win10x64_17134 hashdump

若仍失败，换用lsadump插件：

volatility -f memory.dmp --profile=Win10x64_17134 lsadump

5.2 Wireshark流量分析的协议栈穿透：FTP明文密码为何藏在`ftp-data`而非`ftp`流中

题目要求从capture.pcapng找FTP密码，但过滤ftp协议可能找不到。因为：

FTP控制连接（端口21）传输命令（USER/PASS），但密码明文在ftp-data流中。
正确方法：
1. 过滤ftp.request.command contains "USER"定位登录请求；
2. 右键该数据包 → “Follow → TCP Stream”，此时看到完整交互；
3. 密码在PASS命令后一行，如PASS toor\r\n。

提示：若FTP使用PASV模式，数据连接端口动态分配，需先在控制流中找227 Entering Passive Mode (192,168,1,100,123,45)，计算端口=123×256+45=31533，再过滤tcp.port == 31533。

5.3 挖矿进程的内存特征识别：如何从`pslist`输出中一眼定位恶意进程

volatility -f memory.dmp --profile=Win7SP1x64 pslist列出所有进程，但挖矿进程常伪装为svchost.exe或explorer.exe。识别技巧：

CPU占用异常高：pslist输出中CPU%列，正常svchost应<5%，挖矿进程常>80%。
父进程异常：挖矿进程父进程常为services.exe（PID 4），而非winlogon.exe（PID 392）。

命令行参数含矿池地址：用cmdline插件查看：

volatility -f memory.dmp --profile=Win7SP1x64 cmdline \| grep -i "pool\|xmr\|monero"

5.4 服务名提取的Registry逆向：恶意服务注册点不在Services键，而在`Run`键

hashdump后需找恶意服务名，但svcscan插件可能漏掉。因为：

恶意服务常不注册到HKLM\SYSTEM\CurrentControlSet\Services，而是通过HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run启动。
正确方法：用printkey插件导出Run键：
```
volatility -f memory.dmp --profile=Win7SP1x64 printkey -K "SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
```
输出中找含exe或bat的值，如"Miner"="C:\temp\miner.exe"，服务名即Miner。

5.5 常见问题与避坑清单：取证与流量分析的致命细节

现象	原因	解决方案
`hashdump`输出为空	内存镜像未包含LSASS进程内存，或profile错误	用`pslist`确认LSASS PID，再用`memdump -p PID -D dump/`单独提取LSASS内存，用`mimikatz`离线解密
Wireshark过滤`ftp`找不到密码	数据包使用FTPS（FTP over SSL），密码加密传输	过滤`tcp.port == 21 && ftp.request.command`，或用`sslkeylog`文件解密（若提供）
`netstat`找不到矿池IP	挖矿进程使用域名连接，如`pool.minexmr.com`，需查DNS解析	过滤`dns && dns.qry.name contains "minexmr"`，找到A记录IP
`volatility`报错“Unable to load symbol file”	profile文件缺失，需下载对应Windows版本符号文件	从`https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#imageinfo`下载profile
`msfdb init`报错“database system is shut down”	PostgreSQL服务未启动	`sudo service postgresql start && sudo msfdb init`

6. 渗透测试与漏洞利用：CVE-2019-0708不是“search cve-2019-0708”就能打，而是要懂RDP协议栈的脆弱点

6.1 Nmap扫描的XML输出陷阱：`-oX`必须配合`-oG`或`-oN`才能保证数据完整性

题目要求-oX output.xml，但实际msfdb import需要Nmap的-oX输出包含主机信息。常见错误：

只用-oX不加-sV：输出中无服务版本，MSF无法匹配漏洞模块。

正确命令：

nmap -sV -sC -p- 192.168.1.100 -oX scan.xml -oN scan.nmap # -sV探测版本，-sC运行默认脚本，-p-扫描所有端口

验证XML有效性：grep "<host>" scan.xml \| wc -l应>0，否则扫描未完成。

6.2 MSF数据库初始化的权限链：`msfdb init`失败的三个根因

msfdb init报错常因权限不足：

PostgreSQL用户权限：默认postgres用户需有创建数据库权限。修复：
```
sudo -u postgres psql -c "ALTER USER postgres CREATEDB;"
```
磁盘空间不足：/var/lib/postgresql/分区满。清理：sudo journalctl --vacuum-size=100M。
端口冲突：PostgreSQL默认5432端口被占用。修改/etc/postgresql/*/main/postgresql.conf中port = 5433。

6.3 CVE-2019-0708漏洞利用的靶机准备：为什么`check`命令返回`unknown`就该停手

use exploit/windows/rdp/cve_2019_0708_bluekeep_rce后执行check，若返回unknown：

靶机未启用远程桌面：systeminfo \| findstr "Remote Desktop"应显示Enabled。
靶机补丁已修复：KB4499175（Win7）或KB4499180（Win10）已安装。
网络层拦截：防火墙阻断3389端口，nmap -p 3389 target应显示open。

血泪经验：曾有学生check返回unknown仍强行exploit，导致靶机蓝屏，扣分。

6.4 漏洞公开时间的精准定位：`search cve-2019-0708`回显中“Published”字段才是答案

search cve-2019-0708输出中有多处日期：

Published：CVE官方发布日期（2019-05-14），是题目要求的Flag。
Modified：漏洞信息更新日期（2019-05-15），非答案。
Disclosure：厂商披露日期（2019-05-14），与Published相同。

提取方法：search cve-2019-0708 \| grep "Published"。

6.5 常见问题与避坑清单：渗透测试中的环境断点

现象	原因	解决方案
`msfdb init`报错“Failed to connect to database”	PostgreSQL服务未运行	`sudo service postgresql start`，检查`sudo netstat -tuln \| grep 5432`
`db_import`后`hosts`无输出	XML文件路径错误，或Nmap扫描未完成	`ls -l scan.xml`确认文件存在，`head -20 scan.xml`看是否含`<nmaprun>`标签
`search cve-2019-0708`无结果	Metasploit未更新	`msfconsole -q -x "msfupdate; exit"`
`exploit`执行后靶机无反应	靶机未启用RDP或防火墙拦截	`rdesktop -u Administrator -p password 192.168.1.100`手动测试RDP连通性
`check`返回`vulnerable`但`exploit`失败	靶机内存布局与模块不匹配，需换`bluekeep_rce`变种	尝试`bluekeep_rce_win7`或`bluekeep_rce_win10`

从那以后我每次带学生做渗透测试，都强制走一遍nmap -sV -p- target再msfdb init，宁可多花两分钟确认环境，也不在check返回unknown时赌运气。因为真实攻防中，90%的失败不是技术不行，而是没看清靶机到底“有没有门”。希望帮到你。

本文还有配套的精品资源，点击获取