20253902 吴晨宇 2025-2026-2 《网络攻防实践》课程总结

一、内容总结与简介

电子取证额外作业：
电子取证课外作业

本次实验围绕电子数据取证中的多源证据分析展开，综合使用 Volatility、磁盘镜像挂载、Windows 注册表分析、邮件数据恢复、文件元数据提取以及日志时间线重建等方法，对系统中的用户活动和关键事件进行还原。实验不仅关注单一取证工具的使用，还将内存、磁盘、注册表、邮件和日志等不同来源的证据进行关联分析，通过时间、文件路径、账户信息和程序运行痕迹相互印证，提高了结论的可靠性。实验的创新点在于采用“多源数据交叉验证 + 时间线关联”的分析思路，将原本分散的取证结果整合为连续的行为链，并结合时区换算、元数据校验和日志持续时间分析，对关键事件进行更细粒度的还原，使整个取证过程更加系统、完整。

第一次实践：
20253902 吴晨宇 2025-2026-2 《网络攻防实践》 第一周作业

这是第一次实验，我主要完成了后续网络攻防实验所需的基础环境准备，并梳理了相关网络基础知识。我重点学习了网关、子网划分、VMware 三种网络模式，以及 Kali、SEED Ubuntu、Metasploitable 等实验主机在实验环境中的作用。相比直接开始漏洞利用，这一部分需要把攻击机、靶机和蜜网网关之间的网络关系必须理清楚，否则后续扫描、抓包、攻击和防御都会受到影响。通过这次实践，我对虚拟网络环境中的隔离、转发和连通性有了更清晰的认识。最重要的就是小心小心再小心！！这次实验，我犯了一个很大的错误， 没有去替换AI生成的参考文献，后续我将所有的参考文献都替换为了自己看过的、可以真实跳转的网页链接。

第二次实践：
20253902 吴晨宇 2025-2026-2 《网络攻防实践》 第二周作业

第二次实践主要围绕信息搜集展开，这是渗透测试前期非常关键的一步。从单位股权架构、域名查询、子域名挖掘、空间测绘、DNS 反查、IP 信息收集等多个角度进行分析，并结合 Wireshark、Nmap、Nessus 等工具完成相关实践。通过这次实验，我认识到信息搜集并不是简单扫描端口来分析服务面，而是要尽可能从组织架构、资产暴露面、域名体系和服务指纹等多个维度描绘目标轮廓。只有前期信息掌握得足够完整，后续漏洞验证和攻击路径选择才会更有针对性。个人信息搜集方面我也做了一个小巧思，利用现在很火的大模型进行信息搜集， 比如豆包和deepseek，现在这些大模型都可以进行联网搜索获取信息。此外 利用谷歌语法，也可以查到一些在公网上暴露的文件，从中也能获取到一些隐私信息，比如说 保研同学的身份证后六位。

第三次实践：
20253902 吴晨宇 2025-2026-2 《网络攻防实践》 第三周作业

第三次实践主要进行了网络嗅探与协议分析，重点使用 tcpdump 和 Wireshark 对实际网络访问过程进行抓包。 为了加深理解，我在阿里云服务器上自行搭建 Telnet 服务。我通过访问指定网站，观察浏览器连接到的 Web 服务器数量和 IP 地址，并进一步分析 Telnet 通信过程，通过追踪 TCP 流还原明文交互内容。这次实践更强调从数据包层面理解网络行为，包括 DNS 解析、TCP 连接建立、HTTP 访问和多服务器响应等过程。通过这次实践，我对“网络中真正发生了什么”有了更具体的认识，也体会到抓包分析在蓝队审计和攻击溯源中的重要作用。（当然实际渗透工作中，burpsuit会是更加常用的抓包工具）

第四次实践：
20253902 吴晨宇 2025-2026-2 《网络攻防实践》 第四周作业

第四次实践中主要学习并验证了几类典型网络协议攻击，包括 ARP 缓存欺骗、ICMP 重定向、SYN Flood、TCP RST 攻击和 TCP 会话劫持等内容。我先从协议原理上理解这些攻击为什么能够发生，再结合实验环境观察攻击效果。很多网络攻击并不是依赖复杂的代码漏洞，而是利用协议设计中缺乏认证、状态校验不足或资源分配机制不完善等简单问题。这些实验都是计算机网络课程中的经典协议，也是相关经典的安全问题。我认为本次实践中完成最好的部分，是准确把握了洪流攻击的本质——即 通过大量无效或半开连接消耗目标系统的资源（如连接队列、内存或带宽），并据此在 Win10 环境下 专门设计验证实验，实际测试并观察了资源被占用后的攻击效果。

第五次实践：
20253902 吴晨宇 2025-2026-2 《网络攻防实践》 第五周作业

第五次实践中主要完成了防火墙配置和入侵检测相关实验，重点使用 iptables 和 Snort。实验通过 iptables 配置 ICMP 阻断、端口访问控制和白名单规则，并验证不同主机访问结果的变化。后续我又安装并使用 Snort，对网络流量包进行检测与分析。通过这次实践，我对 Linux 防火墙规则的匹配逻辑、规则顺序以及配置错误后的排查方法有了更直接的认识，也学习了防火墙、IDS和IPS 在安全防护中分别承担的访问控制与异常检测作用。

第六次实践：
20253902 吴晨宇 2025-2026-2 《网络攻防实践》 第六周作业

第六次实践中，我主要完成了 MS08-067 漏洞利用和攻击流量时间线分析两部分内容。在漏洞利用部分，我先检查 Windows 靶机的端口和系统版本，再使用 Metasploit 加载 ms08_067_netapi 模块进行攻击，并验证获得的会话是否具备读写能力。在流量分析部分，我通过 Wireshark 观察 HTTP、FTP、TCP 等通信过程，识别攻击者 IP、受害者 IP、目录穿越、MSADC/RDS 利用、后门文件投递、Netcat 远程 Shell 以及后渗透命令。这次实践更重要的是从流量角度还原攻击链，让我认识到漏洞利用后的每一步行为都会在网络中留下痕迹（这也体现了攻击者在“后渗透”中痕迹掩盖的重要性）。

第七次实践：
20253902 吴晨宇 2025-2026-2 《网络攻防实践》 第七周作业

第七次实践中，我主要围绕 Samba usermap_script 漏洞进行实验，内容包括本地漏洞利用和远程攻击两个部分。我使用 Metasploit 的 exploit/multi/samba/usermap_script 模块对 Metasploitable 靶机发起攻击，并在获得 Shell 后通过 whoami、ifconfig、读取 /etc/shadow、创建文件、新建用户、SSH 登录等方式验证权限。这个实验的重点不只是“成功拿到 Shell”，还包括通过一系列操作确认当前权限级别和文件操作能力。通过这次实践，我对远程命令执行漏洞的危害有了更直观的理解，也认识到旧版本服务、错误配置和敏感文件权限在系统安全中的风险。

第八次实践：
20253902 吴晨宇 2025-2026-2 《网络攻防实践》 第八周作业

第八次实践主要完成了恶意代码静态分析、逆向分析和蜜罐流量分析等内容。前半部分，我对 RaDa.exe 样本进行了文件类型识别、字符串提取、查壳、脱壳和 IDA 分析，后面又分析了 crackme1.exe 和 crackme2.exe 的参数校验、文件名校验以及隐藏字符串还原。最后一部分，我使用 Wireshark、tshark、strings、grep 等工具分析 Windows 2000 蜜罐加入 IRC 僵尸网络的过程，识别 C2 服务器、统计僵尸网络规模，并还原 SMB/445 攻击链。通过这次实践，我学习到恶意代码分析不能只看程序本身，还要结合网络流量、系统行为和攻击链证据进行交叉验证。

第九次实践：
20253902 吴晨宇 2025-2026-2 《网络攻防实践》 第九周作业

第九次实践中，我主要进入 PWN 方向，围绕栈溢出和程序控制流劫持展开实验。我先复习了小端序、大端序、GDB 调试、栈结构和栈溢出基础，再对 pwn1 程序进行分析。实验中，我通过 checksec 查看程序保护机制，结合 IDA 分析 main、foo、getShell 等函数关系，发现 gets() 导致的栈溢出点，并构造输入覆盖返回地址，使程序跳转到 getShell() 执行 /bin/sh。这次实验和我本科做 CTF PWN 的经历比较贴近，也让我重新熟悉了从漏洞点定位、偏移计算到 payload 构造的完整流程。我认为本次实践中完成最好的部分，是借助 PWNDBG 对目标程序进行了 动态调试，从函数调用关系、寄存器状态和栈内存布局出发，逐步定位并分析了栈溢出漏洞的触发原理，实现了 从静态代码理解到动态执行验证的完整闭环。

第十次实践：
20253902 吴晨宇 2025-2026-2 《网络攻防实践》 第十周作业

第十次实践中，我主要围绕 Web 安全展开，内容包括 SQL 注入、XSS、CSRF 以及相关防御方法。我先在 SEED Ubuntu 中搭建 Web 靶场环境，然后对登录页面和资料更新功能进行 SQL 注入测试，利用单引号、注释符等方式改变后端 SQL 语句逻辑，并进一步通过参数化查询进行防御修改。后续 XSS 部分，我通过在用户资料中插入脚本验证存储型 XSS，尝试弹窗、读取 Cookie、通过请求回传信息、自动加好友以及构造蠕虫式资料修改脚本。这次实践Web 漏洞的本质：用户输入一旦没有和代码逻辑、结构或页面输出正确隔离，就可能被攻击者利用。

第十一次实践：
20253902 吴晨宇 2025-2026-2 《网络攻防实践》 第十一周作业

第十一次实践中，我主要围绕浏览器漏洞利用和网页挂马取证分析展开。实验前半部分先搭建了 Kali 攻击机和 Windows 2000 靶机环境，然后利用 Metasploit 对 IE 相关漏洞进行验证，重点包括 MS06-014 和 MS06-055。通过让靶机访问攻击页面，可以观察到漏洞触发后建立 shell 会话的过程，从而比较直观地理解浏览器漏洞利用并不是单纯“打开网页”，而是由页面加载、脚本执行、漏洞触发和载荷回连等多个环节共同完成。实验后半部分主要分析挂马样本的静态结构，包括 kl.htm、1.js、b.js、pps.js 和 bd.cab 等文件。分析过程中，我通过查看脚本内容、还原混淆逻辑、处理 Base64 编码、分析 XXTEA 解密过程，以及替换 eval 等方式，逐步还原出网页挂马的真实执行逻辑。可以看到，攻击页面会先探测浏览器环境和 ActiveX 控件，再通过堆喷射布置 shellcode，最后尝试下载并执行恶意程序。在实验最后，我还尝试将两个漏洞入口合并到同一个 HTML 页面中，并使用 Wireshark 抓包观察浏览器请求过程。结果表明，两个漏洞单独触发时都可以建立回连，但合并到同一页面后，受 IE 执行状态和脚本触发顺序影响，无法稳定实现两个会话同时上线。通过这次实验，我对网页挂马攻击链有了更完整的理解：从漏洞页面构造，到脚本混淆与解密，再到 shellcode 执行和恶意程序下载，每一步都可以在代码或流量中找到对应痕迹。相比只看漏洞结论，逐步还原攻击过程更能帮助我理解浏览器漏洞利用背后的真实逻辑。

二、最喜欢且做得最好的实践

20253902 吴晨宇 2025-2026-2 《网络攻防实践》 第二周作业

在第二周的作业里，我搜集学习了非常详细的信息搜集方案，此外在个人隐私泄露方面，我也运用了谷歌语法和AI画像两种前沿技术，也顺利地查询到了一些个人信息。

20253902 吴晨宇 2025-2026-2 《网络攻防实践》 第九周作业
我本科期间学过一年多的 PWN，不过也只能算是勉强入门。这次重新做 PWN 题，有一种“朝花夕拾”的感觉。从头搭建环境、分析程序，到使用 GDB 一步步调试，中间也经历了程序始终打不通时的焦虑和迷茫，和当初学习 CTF 时的状态很像——毕竟CTF“坐牢”才是常态。

这次作业我完成得比较细，也尝试了多种思路来解决问题，分析过程中尽可能使用了不同工具进行验证。例如，编辑 ELF 文件时先尝试使用 010 Editor，遇到加壳程序时使用 UPX 脱壳，再通过 IDA 进行静态分析。虽然整个过程并不顺利，但也正是在一次次尝试、排错和调试中，我重新找回了当初研究 PWN 时的感觉。

三、本门课学到的知识总结

以下内容大部分都是通过之前的博客总结而成，为了更加清晰地演示，里面放了一些以前的图片。纯人工，零添加

3.1 安全加固和检测技术

3.1.1 相关工具

1. Nmap相关功能

Nmap 在实验中主要承担信息搜集和攻击面识别的作用。第二周博客中，我们先通过 ipconfig 确认 Win2kServer 的 IP 地址，再使用 Nmap 对目标进行主机探活、TCP 端口扫描、UDP 扫描、服务版本识别和操作系统探测。这个流程比较符合实际安全检测的思路：先确认目标是否在线，再确认端口和服务，最后根据服务版本判断后续风险。

第一步，我们先要测试目标主机是否在线，主机探活常用命令如下：

nmap -sn 192.168.200.131 192.168.200.130

图 3-1-1 终端中使用 Nmap 对两个目标地址进行主机探活。

-sn 参数主要用于判断目标是否在线，不进行完整端口扫描。在实验环境中，先通过这种方式确认 192.168.200.131 和 192.168.200.130 均处于存活状态，可以避免后续对不存在或未启动的主机进行无效扫描。

确认目标在线后，可以继续进行 TCP 端口扫描：

sudo nmap -sS -p- 192.168.200.131

如果需要进一步判断目标运行的具体服务版本，可以使用服务识别参数：

nmap -sV -O -Pn 192.168.200.131

图 3-1-3 Nmap 对目标主机进行服务版本识别并显示部分端口对应的服务信息。

从识别结果中可以看到，目标主机存在多种服务信息。识别开放端口的价值在于，它可以把“端口开放”进一步转化为“可能存在的漏洞范围”。例如第六周 MS08-067 和第七周 Samba 相关实验，本质上都需要先确认目标服务和版本，再判断漏洞是否适用。

下面是我整理的，Nmap 常用功能：

检测目的	常用命令	观察重点	后续分析方向
主机探活	nmap -sn <IP/网段>	目标是否在线	明确扫描范围
TCP 端口扫描	nmap -sS -p- <IP>	开放端口和服务名称	判断暴露面大小
UDP 端口扫描	nmap -sU <IP>	UDP 服务是否开放	补充容易遗漏的服务
服务识别	nmap -sV <IP>	服务名称和版本	对照已知漏洞
系统探测	nmap -O <IP>	操作系统类型	辅助判断漏洞适用性

据我了解，在实际的渗透测试工作中，Nmap 可以分析目标业务面。扫描发现端口开放后，还需要继续判断服务是否必要、版本是否过旧（这种查看是否有1-day、N-day漏洞）、访问范围是否应该收缩。

2. Wireshark相关使用

Wireshark是非常著名的流量分析工具，主要用于流量抓取和协议分析，我们以分析telnet流量为例，可以直接在显示过滤器中输入：

telnet

图 3-1-4 Wireshark 使用 telnet 过滤器筛选 Telnet 协议数据包。

筛选出 Telnet 流量后，可以选中其中一个数据包，右键选择追踪 TCP 流，观察完整会话内容。后续基本上所有实验都可以参考这个流程，来对tcp流进行分析，获取通信的大致情况。

图 3-1-5 Wireshark 追踪 TCP 流后显示 Telnet 会话中的交互内容。

Wireshark 在浏览器漏洞实验中也很关键。为了验证靶机浏览器是否访问了两个漏洞路径，可以使用 HTTP 请求 URI 过滤条件：

http.request.uri contains "ms06055" or http.request.uri contains "ms06014"

图 3-1-6 Wireshark 使用 HTTP 过滤条件筛选与两个漏洞路径相关的请求记录。

Metasploit 中是否出现回显是一类证据，Wireshark 中是否存在对应 HTTP 请求是另一类证据。两者结合起来，才能更稳妥地判断浏览器有没有访问漏洞页面，以及后续未回连是否可能与浏览器执行状态有关。

Wireshark 常用过滤器可以整理如下：

# 按 IP 过滤
ip.addr == 192.168.200.131

# 按协议过滤
telnet
http
dns
arp

# 查看 HTTP 请求
http.request

# 按端口过滤
tcp.port == 80

# 筛选 SYN 请求
tcp.flags.syn == 1 && tcp.flags.ack == 0

# 查看指定 TCP 流
tcp.stream eq 0

# 过滤指定 URI
http.request.uri contains "ms06055"

Wireshark 的价值在于“从流量中还原出现了什么”。尤其是在漏洞利用、网页挂马和攻击链还原中，抓包结果可以作为取证和分析的关键环节，

3. Burp Suite

破解burpsuit是学习web安全的第一课hhhh，kali也是自带社区版的burpsuit。Burp Suite 的典型使用方法：拦截请求、观察参数、修改输入、重放请求并比较响应差异。

以第十周 SQL 注入实验为例，登录页面会接收用户名和密码参数。正常测试时，先输入普通用户名和密码，观察页面返回“账户不存在”；随后在用户名中加入单引号，页面返回 SQL 语法错误。这种“输入变化—响应变化”的分析过程，其实这正是 Burp Suite Repeater 模块适合完成的工作。

Burp Suite 的基本使用流程可以写成：

1. 浏览器配置代理到 127.0.0.1:8080
2. 打开 Burp Suite 的 Proxy 模块
3. 访问目标 Web 页面并提交表单
4. 拦截请求，观察请求方法、URL、Cookie 和参数
5. 将请求发送到 Repeater
6. 修改单个参数后重放请求
7. 对比响应状态码、页面内容和响应长度

我感觉，我最常用的模块如下：

模块	主要作用
Proxy	拦截浏览器请求
Repeater	手动重放请求
Intruder	批量构造请求
Decoder	编码与解码
Comparer	对比响应差异

Burp Suite可以让请求变得可见、可控、可复现。Web 漏洞分析时，一次只改一个参数，再观察响应变化，这样比盲目堆 payload 更可靠。

4.Sqlmap

Sqlmap是 SQL 注入检测工具（也是脚本小子最爱的工具）。它适合在已经通过手工测试或 Burp Suite 定位到可疑参数后使用，而不是一开始就对整个站点盲扫（这种非常容易影响业务，效率也特别差）。第十周 SQL 注入实验中，登录功能和资料更新功能都出现了用户输入直接拼接 SQL 的问题，这类场景正适合用 Sqlmap 进行辅助验证和修复后复测。

例如，对可疑 URL 参数进行检测时，可以使用：

sqlmap -u "http://192.168.200.5/unsafe_home.php?username=admin&password=123456" --batch

如果使用 Burp Suite 保存了完整请求，也可以用 -r 导入请求文件：

sqlmap -r request.txt --batch

需要指定参数时，可以使用：

sqlmap -r request.txt -p username --batch

Sqlmap 使用流程可以整理为：

阶段	操作	观察内容	分析重点
手工定位	输入单引号、注释符等内容	页面是否报错或响应变化	参数是否进入后端查询
请求整理	用 Burp Suite 保存完整请求	Cookie、请求方法、参数上下文	保证检测环境一致
自动验证	sqlmap -r request.txt	注入类型、数据库指纹	辅助手工判断
数据确认	--current-db、--tables	数据库和表信息	判断影响范围
修复复测	修复后重新运行检测	是否仍能识别注入	验证加固是否生效

Sqlmap可以帮助快速验证注入点，避免手动盲目测试。

3.1.2 加固方案

安全加固应该从检测结果出发。比较典型的加固方向包括：减少服务暴露面、配置防火墙访问控制、部署入侵检测、修复 Web 代码、限制数据库权限、加强账户与日志审计。

1. 收缩服务暴露面

对于真实环境来说，每一个开放端口都应该能解释清楚：为什么需要开放、谁需要访问、是否有访问控制、服务版本是否安全。

可以使用下面的命令查看本机监听端口：

ss -tunlp

对于不需要的服务，应停止并禁止开机自启：

sudo systemctl stop 服务名
sudo systemctl disable 服务名

如果某些服务必须保留，例如 Web、SSH 或数据库，也不应该默认对所有来源开放，而是应该结合防火墙规则限制访问范围。

扫描阶段发现的是“暴露面”，加固阶段要做的是“收缩暴露面”。端口不是越多越方便，而是越多越需要说明开放业务的合理性。

2. 防火墙与云平台安全组访问控制

为了加深理解，在第三周实验中，我在阿里云服务器上自行搭建 Telnet 服务。防火墙的作用是控制网络流量能否进入或离开主机。在实验中，iptables 主要用于主机本地访问控制，可以根据协议类型、源 IP、目标端口等条件决定数据包是放行还是丢弃。例如，可以通过规则丢弃 ICMP Echo Request 报文，降低主机被简单 Ping 探测到的概率：

iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

也可以对 Web 服务配置白名单，只允许指定主机访问 80 端口：

iptables -A INPUT -p tcp -s 192.168.200.5 --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP

这里需要注意规则顺序。iptables 会按照从上到下的顺序匹配规则，如果先写拒绝所有 80 端口访问，再写允许某个 IP 访问，那么后面的允许规则就不会生效。因此在配置白名单时，一般要先写允许规则，再写拒绝规则。

除了主机本地防火墙，云服务器还存在云平台安全组这一层访问控制。第三周实验中搭建 Telnet 服务时，即使服务器内部 Telnet 服务已经启动，如果阿里云安全组没有放行 23 端口，外部主机仍然无法连接。这说明云服务器的访问路径通常要同时经过两层检查：第一层是云平台安全组，决定公网流量能否到达云服务器；第二层是主机防火墙，决定流量进入系统后是否被允许访问具体服务。

图 3-1-11 阿里云安全组中配置 TCP 23 端口放行规则。

从加固角度看，安全组更像云平台提供的边界防火墙，iptables 则是服务器内部的本地防火墙。两者不是替代关系，而是叠加关系。只有安全组放行、本机防火墙允许、服务本身正常监听时，外部访问才可能成功。

因此，在云服务器加固时，不能只检查本机端口是否监听，也不能只看云平台安全组是否放行，而要把两者结合起来分析。对于 Telnet、数据库、远程管理等敏感端口，实验完成后应及时关闭服务或删除临时放行规则，避免公网长期暴露高风险入口。

3. 部署 Snort 进行入侵检测

防火墙主要解决“能不能通过”的问题，而 Snort 这类 IDS 更关注“流量里有没有可疑特征”。此外，老师上课提到了IDS和IPS的区别，IDS是“事后监控报警”，而IPS是“实时拦截阻断”。
参考命令如下：

snort -A alert_fast \
-c /etc/snort/snort.lua \
-R <(echo 'alert tcp any any -> any any (msg:"Nmap Scan Detected"; flags:S; sid:1000001; rev:1;)') \
-r ./listen.pcap \
-l /var/log/snort

告警日志中可以看到大量 Nmap Scan Detected 信息：

图 3-1-11 Snort 告警日志中显示多条与 TCP SYN 匹配相关的检测信息。

这里要注意，规则中的 msg:"Nmap Scan Detected" 是人为设置的告警名称，并不意味着所有触发记录一定来自 Nmap。更严谨的判断方式是继续分析 SYN 报文数量、目标端口分布、源目的地址、响应情况和会话统计等信息。

BTW，现在的安全厂商，实际做渗透测试业务已经不怎么赚钱了（可能银行一场长期测试才几万几十万），但是通过长期售卖和运行IDS、安全网关这种安全软件和设备，才是比较重要的营收来源。

4. 控制数据库权限

真实系统中，即使 Web 层出现漏洞，数据库账号也不应该拥有过高权限，否则漏洞影响范围会放大。

可以为 Web 应用创建低权限数据库账号：

CREATE USER 'webuser'@'localhost' IDENTIFIED BY 'StrongPassword';

GRANT SELECT, INSERT, UPDATE ON Users.* TO 'webuser'@'localhost';

FLUSH PRIVILEGES;

如果业务只需要查询和更新用户资料，就不应该授予 DROP、ALTER、FILE 等高危权限。这样即使某个参数仍然存在注入风险，也能尽量限制攻击者进一步破坏数据库结构或读取系统文件。

5. 加强账户和默认配置管理

真实系统上线前必须清理无用账号、修改默认密码，并确认每个账号都有明确用途。

常见检查命令如下：

# 查看系统用户
cat /etc/passwd

# 查看具有登录 Shell 的用户
grep -E "/bin/bash|/bin/sh" /etc/passwd

# 修改用户密码
passwd 用户名

# 锁定不需要登录的用户
sudo usermod -L 用户名

SSH 加固时可以重点检查以下配置：

sudo vim /etc/ssh/sshd_config

PermitRootLogin no
PasswordAuthentication no
AllowUsers your_user

修改后记得重启 SSH 服务：

在进行护网的时候，弱口令和默认密码往往是关键的一环，特别是医院或者政府单位，有的人需要频发的开机登陆，pin就会非常简单。或者核心人员疏于管理，口令都用的默认或者非常简单有规律，这样会是攻击人员打进内容或者进行横向的关键一环。

6. 日志审计与复测验证

安全加固完成后，还需要通过日志和复测确认效果。日志可以帮助发现异常访问，复测可以确认漏洞是否真正被修复。结合第五周 Snort、第十周 Web 修复和第十一周 Wireshark 抓包，我认为审计至少应该包含三类证据：工具扫描结果、流量记录、应用层响应。

常见日志位置包括：

# Nginx 访问日志
/var/log/nginx/access.log

# Apache 访问日志
/var/log/apache2/access.log

# SSH 登录认证日志
/var/log/auth.log

# 系统日志
/var/log/syslog

可以用下面的命令做初步排查：

# 查看 SSH 登录失败记录
grep "Failed password" /var/log/auth.log

# 检查 Web 访问中的可疑 SQL 注入关键词
grep -Ei "union|select|sleep|benchmark|or 1=1" /var/log/apache2/access.log

# 统计访问次数较高的 IP
awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -nr | head

日志中出现 union select、sleep()、or 1=1 等内容，说明有人提交过可疑请求，但并不等于攻击一定成功。是否成功利用，还需要结合响应状态码、返回长度、数据库变化、后续连接和主机行为继续判断。

3.2 Web安全技术及代码审计

3.2.1 sql注入

之前自己写的关于sql注入的博客

SQL 注入简介

SQL 注入是一类常见的 Web 安全漏洞。它产生的根本原因是：程序在构造 SQL 语句时，没有正确区分“SQL 语句本身”和“用户提交的数据”。如果后端代码直接把用户输入拼接进 SQL 查询中，攻击者就可能通过特殊输入改变原本的查询逻辑，从而干扰应用程序对数据库的正常访问。

从本质上看，SQL 注入是一种未经授权访问或操作数据库数据的漏洞。攻击者原本只能通过正常页面访问有限信息，但如果注入成功，就可能读取其他用户的数据、绕过登录验证、修改数据库内容，甚至在某些特殊情况下进一步影响后端服务器。

SQL 注入的原理很符合安全学习的一句真理：

任何来自用户侧的输入都不应该被默认信任。

这里的“用户输入”并不只包括登录框、搜索框、留言框，也包括 URL 参数、Cookie、HTTP Header、隐藏表单字段、排序字段等。只要这些数据会进入后端 SQL 查询，就有可能成为 SQL 注入的入口。

以实践的内容举个例子，正常的登录查询可能是：

SELECT * FROM users WHERE username='admin' AND password='123456';

如果后端直接拼接用户输入，而攻击者提交了带有 SQL 语义的内容，那么数据库执行的就可能不再是开发者原本设计的查询逻辑。

SQL 注入的危害

SQL 注入的危害通常比较严重（在src漏洞里面基本是中危起步），因为它直接作用于数据库，而数据库往往保存着系统中最核心的数据资源。一次成功的 SQL 注入攻击，可能导致敏感信息泄露、身份认证绕过、数据被篡改或删除，甚至在数据库账号权限过高时进一步影响服务器和后端系统。

SQL 注入的检测方式

SQL 注入检测的核心思路是：通过构造不同输入，观察应用程序响应是否出现异常差异。如果用户输入真的进入了 SQL 查询逻辑，那么不同输入可能会导致页面内容、错误信息、响应时间、返回长度等发生变化。

常见检测方式如下：

检测方式	测试思路	观察重点
单引号测试	提交 '，观察是否破坏 SQL 字符串结构	是否出现 SQL 语法错误或异常响应
SQL 语法测试	提交特定 SQL 片段，比较正常输入和构造输入的差异	页面内容、状态码、返回长度是否变化
布尔条件测试	提交 OR 1=1 和 OR 1=2 这类真假条件	条件真假是否导致页面差异
时间延迟测试	构造能触发数据库延迟执行的输入	响应时间是否稳定变长
带外检测	构造可能触发 DNS、HTTP 等外部交互的输入	是否产生带外网络请求

SQL 注入的常见类型

SQL 注入可以按照回显方式、利用方式和执行效果分为多种类型。不同类型的区别主要在于：页面是否直接返回数据、是否显示数据库错误、是否能通过响应时间判断、是否允许执行多条 SQL 语句等。sql注入测试，最重要的是耐心和经验！

类型	特点	常见判断依据
联合查询注入	利用 UNION SELECT 将构造查询结果拼接到原查询结果中	页面存在数据回显，字段数量和类型需要匹配
报错注入	通过数据库错误信息泄露表名、字段名或部分数据	页面直接显示数据库报错信息
布尔盲注	页面不直接返回数据，但会根据条件真假产生差异	页面内容、状态码、返回长度不同
时间盲注	页面内容几乎不变，通过响应时间判断条件是否成立	特定输入导致响应时间稳定变长
堆叠查询注入	在一次输入中追加并执行多条 SQL 语句	可能造成数据修改、删除或权限变化
二次注入	恶意输入先被保存，后续被再次拼接进 SQL 时触发	第一次提交正常，后续功能触发异常
宽字节注入	利用字符编码处理不一致绕过转义	与数据库连接字符集、编码配置有关
Cookie/Header 注入	注入点不在可见输入框，而在 Cookie 或请求头中	常见于日志记录、访问统计、用户追踪等功能

这些类型中，联合查询注入和报错注入比较直观，因为页面可能直接返回结果或错误信息；布尔盲注和时间盲注更隐蔽，需要通过页面差异或响应时间逐步推断；堆叠查询注入危害更高，因为它可能不只是读取数据，还可能执行修改、删除等操作。

代码审计与防御思路

从代码审计角度看，SQL 注入最常见的位置是 SELECT 查询中的 WHERE 子句，例如登录验证、搜索功能、用户详情查询等。但 SQL 注入并不只会出现在这里。只要用户输入进入 SQL 语句结构，就可能产生注入风险。

审计时需要重点关注以下位置：

SQL 位置	常见场景
SELECT 的 WHERE 子句	登录、搜索、详情查询
UPDATE 的更新值或 WHERE 子句	修改昵称、邮箱、密码、地址等资料
INSERT 的插入值	注册、留言、评论、表单提交
DELETE 的 WHERE 子句	删除订单、删除评论、删除用户记录
ORDER BY 子句	按用户选择的字段排序
表名、列名、LIMIT 参数	动态表名、动态字段、分页查询

危险代码通常有一个共同点：直接把用户输入拼接进 SQL 语句。

$sql = "SELECT * FROM users WHERE username = '$username'";

$sql = "UPDATE users SET nickname = '$nickname' WHERE id = $id";

$sql = "SELECT * FROM products ORDER BY $sort";

更安全的方式是使用预处理语句和参数化查询：

$stmt = $conn->prepare("SELECT * FROM users WHERE username = ?");
$stmt->bind_param("s", $username);
$stmt->execute();

参数化查询的意义在于，SQL 语句结构先被固定，用户输入再作为参数传入数据库。这样用户输入即使包含单引号、空格、SQL 关键字等内容，也只会被当作普通数据处理，而不会改变 SQL 语句本身的逻辑。

3.2.3 xss

xss基本原理

1、反射型（非持久型）
反射型XSS，又称非持久型XSS，攻击相对于受害者而言是一次性的，具体表现在受害者点击了含有的恶意JavaScript脚本的url，恶意代码并没有保存在目标网站，而Web应用程序只是不加处理的把该恶意脚本“反射”回受害者的浏览器而使受害者的浏览器执行相应的脚本。
2、存储型（持久型）
存储型XSS是指应用程序通过Web请求获取不可信赖的数据，在未检验数据是否存在XSS代码的情况下，便将其存入数据库。当下一次从数据库中获取该数据时程序也未对其进行过滤，页面再次执行XSS代码持续攻击用户。存储型XSS漏洞大多出现在留言板、评论区，用户提交了包含XSS代码的留言到数据库，当目标用户查询留言时，那些留言的内容会从服务器解析之后加载出来。
3、DOM型（非持久型）
DOM，全称Document Object Model，是一个平台和语言都中立的接口，可以使程序和脚本能够动态访问和更新文档的内容、结构以及样式，DOM-XSS简单理解就是不与后台服务器产生数据交互，是一种通过DOM操作前端代码输出的时候产生的问题。

xss危害

1.窃取用户Cookie
2.后台增删改文章
3.XSS钓鱼攻击
4.利用XSS漏洞进行传播和修改网页代码
5.XSS蠕虫攻击
6.网站重定向
7.获取键盘记录
8.获取用户信息等

xss常见攻击方式

一些可能绕过防御的攻击方式

xss 常见防护手段

1、对输入和URL参数进行过滤(白名单和黑名单)
检查用户输入的数据中是否包含一些特殊字符，如<、>、’、“等，发现存在特殊字符，将这些特殊字符过滤或者编码。
2、HTML实体编码
字符串js编码转换成实体html编码的方法（防范XSS攻击）
3、对输出内容进行编码
在变量输出到HTML页面时，可以使用编码或转义的方式来防御XSS攻击。
4、检查用户输入，必须以http或者https开头。注意，不可以仅仅是包含http和https

3.3 逆向分析技术

逆向分析这一部分，重点是先识别文件类型，再从字符串、文件结构、节区信息和函数调用等角度逐步分析；如果发现加壳痕迹，就先尝试脱壳；最后再结合 IDA Pro、x64dbg 等工具，从静态和动态两个角度验证程序逻辑。

整体流程可以概括为：

文件类型识别
    ↓
字符串与基础信息提取
    ↓
010 Editor 查看文件头和节区结构
    ↓
查壳与脱壳判断
    ↓
IDA Pro 静态反编译
    ↓
x64dbg 动态调试验证
    ↓
综合判断程序逻辑和可疑行为

每个阶段需要使用的工具及其作用也可以参考下表：

分析阶段	常用工具	主要作用
文件识别	file、readelf、checksec	判断文件格式、架构、平台和基础保护
字符串提取	strings	快速发现提示语、路径、URL、命令参数等线索
结构查看	010 Editor	查看文件头、节区、偏移、十六进制数据和 PE / ELF 结构
查壳脱壳	UPX、VM Unpacker	判断程序是否经过压缩、加密或保护
静态分析	IDA Pro	查看函数、字符串、交叉引用、伪代码和控制流
动态调试	x64dbg	通过断点、寄存器、栈和内存窗口验证程序执行路径

3.3.1 PE / ELF 文件基础识别

逆向分析的第一步是确认文件格式、运行平台和程序架构。对于 Windows 程序，通常关注 PE 文件；对于 Linux 程序，则主要关注 ELF 文件。

常用命令如下：

file <filename>

如果是 ELF 文件，还可以继续查看文件头和安全保护：

readelf -h <filename>
checksec <filename>

这里的checksec是一个非常非常常用的ctf工具（可以说是做二进制安全相关题目的第一步），可以精准的查看程序的安全防护，我们可以根据这里的信息选择后续的攻击（比如是否可以爆破canary等等）

这一阶段主要先解决几个基础问题：

观察内容	判断内容
文件格式	判断是 PE、ELF 还是脚本文件
程序位数	判断后续使用 32 位还是 64 位分析工具
运行平台	判断应该放在 Windows 还是 Linux 环境中分析
入口点	初步判断程序从哪里开始执行
节区数量	观察程序结构是否正常
安全保护	判断后续调试和漏洞分析难度

3.3.2 字符串提取与初步定位

strings 是静态分析中很常用的入口工具。它可以从二进制文件中提取可见字符串，帮助快速发现程序中可能存在的提示信息、路径、URL、注册表项、命令参数、错误信息等内容。

常用命令如下：

strings <filename>

如果输出内容很多，可以配合 grep 进行筛选：

strings <filename> | grep -i "http"
strings <filename> | grep -i "cmd"
strings <filename> | grep -i "password"

分析字符串时，我一般会重点看下面几类内容：

字符串类型	可能说明的问题
URL / IP / 域名	程序可能存在联网行为
文件路径	程序可能读写本地文件
注册表项	程序可能修改系统配置或实现自启动
错误提示	可以辅助判断程序分支逻辑
命令参数	可以推测程序隐藏功能或运行方式
加密、解密相关词	可能存在编码、混淆或隐藏数据

不过，strings 的结果只能作为线索，不能直接当作结论。尤其是恶意代码经常会加壳、压缩或混淆，导致原始样本中只能看到少量碎片化字符串。遇到这种情况，后面就需要继续查看文件结构和查壳情况。

有时候strings也可以作为ROP Gadget的一块拼图，比如在程序里搜集"/bin/sh"字符串等等，或者搜集一些eip、jmp等指令。

3.3.3 010 Editor 文件结构分析

010 Editor 更适合放在 IDA 分析之前使用。它不是用来反编译代码的，而是用来观察二进制文件本身的结构。相比普通十六进制编辑器，010 Editor 可以结合模板把文件头、节区表、字段偏移和原始字节对应起来，适合用来检查 PE / ELF 文件结构是否正常。

使用 010 Editor 时，我一般按下面的顺序分析：

1. 打开待分析的 PE / ELF 文件
2. 查看文件开头是否符合对应格式特征
3. 加载对应的 Binary Template
4. 展开文件头和节区表
5. 观察入口点、节区名称、节区权限和数据大小
6. 对比文件偏移和虚拟地址
7. 结合 IDA 中的地址继续定位代码或数据

对于 PE 文件来说，节区信息尤其值得关注。正常程序通常会有 .text、.data、.rdata、.rsrc 等节区；如果出现节区名称异常、节区权限过于宽松、节区熵值明显偏高，或者代码节和数据节边界很奇怪，就需要考虑程序是否经过加壳、压缩或混淆。

010 Editor 在脱壳前后对比时也比较有用。可以分别打开原始样本和脱壳后的文件，对比它们的节区数量、入口点位置、导入表和字符串分布。如果脱壳后文件结构更清晰，导入函数和节区信息更接近正常程序，就说明后续放入 IDA 中分析会更可靠。

在进入 IDA 看函数逻辑之前，可以先用010 Editor 检查文件头、节区和偏移关系，可以减少后面分析时的误判。

3.3.4 查壳与脱壳

加壳可以理解为给程序套了一层保护外壳。真实代码可能被压缩、加密或重新组织，程序运行时会先执行壳代码，再把真实程序还原到内存中。

分析加壳程序时，常见思路是：

先查看文件结构
    ↓
再结合查壳工具判断
    ↓
判断能否直接脱壳
    ↓
脱壳后重新做 strings、010 Editor 和 IDA 分析
    ↓
对比脱壳前后的字符串、节区、函数和结构变化

如果怀疑程序使用 UPX，可以先使用：

upx -l <filename>

如果确认是标准 UPX 壳，可以尝试：

upx -d <filename>

但实际分析中经常会遇到标准工具无法直接解包的情况。此时不能简单认为“没有加壳”，而应该考虑壳被修改、被保护，或者需要使用其他脱壳工具继续处理。

脱壳后还需要重新分析一次文件，例如：

strings <unpacked_filename>

同时也可以再次放入 010 Editor 中观察结构变化：

原始文件：查看入口点、节区名称、节区大小、导入表是否异常
脱壳文件：查看入口点是否变化，导入表和节区结构是否更清晰

重点比较脱壳前后是否出现更多有意义的信息：

对比内容	观察重点
字符串数量	是否出现更多可读字符串
导入函数	是否能看到更多系统 API
节区结构	是否比原始文件更接近正常程序
入口点位置	是否从壳代码转向真实代码
IDA 识别效果	是否能识别出更多函数和代码结构

脱壳的重点是看脱壳后的文件是否更适合继续分析。只有字符串、函数、导入表或代码结构变得更清晰，脱壳结果才有继续分析的价值。

3.3.5 IDA Pro 静态反编译

PWN题目中最最最好用的工具。IDA Pro 适合用来做静态逆向分析。它可以把机器码转换为汇编代码，并尽量恢复函数、字符串、交叉引用和程序控制流。

使用 IDA 分析 PE 文件时，一般按下面的顺序进行：

1. 打开 IDA Pro
2. 选择待分析的 PE 文件
3. 按文件类型选择 PE Executable
4. 等待 IDA 自动分析完成
5. 先看 Strings 窗口
6. 根据关键字符串查看交叉引用
7. 再进入函数和伪代码分析

在 IDA 中，我通常先看这几个窗口：

IDA 功能	使用方法	主要作用
Strings	查看程序中的字符串	快速定位提示语、路径、命令、URL
Functions	查看函数列表	观察程序结构和函数数量
Imports	查看导入函数	判断程序可能调用哪些系统功能
Xrefs	查看交叉引用	找到某个字符串或函数在哪里被使用
Graph View	查看控制流图	理解条件判断和分支跳转
Pseudocode	查看伪代码	把汇编逻辑转换成更容易理解的形式

在实际分析时，比较实用的方法是从字符串反推逻辑。例如先在 Strings 窗口中找到可疑字符串，再查看它的交叉引用，定位到使用该字符串的代码位置。这样比从入口点一行一行看汇编要高效很多。

（需要注意的是，ida反编译出来的变量名都是没有含义的，可以通过选中然后按'n'来重命名，这样使得程序更加可读）

常见分析思路如下：

发现可疑字符串
    ↓
查看该字符串的交叉引用
    ↓
定位调用位置
    ↓
观察前后的条件判断
    ↓
分析程序为什么进入不同分支

如果程序中存在输入校验、口令比较或隐藏功能，通常可以重点关注：

strcmp
strncmp
memcmp
GetCommandLine
CreateFile
RegSetValue
WinExec
ShellExecute
CreateProcess
InternetOpen
InternetConnect

这些函数可以帮助判断程序是否涉及参数判断、文件操作、注册表修改、命令执行或网络连接。

3.3.6 x64dbg 动态调试

IDA 更适合静态观察程序结构，x64dbg 更适合在程序运行过程中验证判断。静态分析看到的是“程序可能怎么走”，动态调试看到的是“这一次程序实际怎么走”。

使用 x64dbg 时，可以按下面的流程进行：

1. 将程序拖入 x64dbg
2. 运行到程序入口点
3. 根据 IDA 中的可疑位置设置断点
4. 输入不同参数运行程序
5. 观察寄存器、栈和内存变化
6. 单步执行关键跳转
7. 判断程序进入哪个分支

动态调试中比较常用的观察对象有：

观察对象	主要用途
EAX / RAX	常用于观察函数返回值
ESP / RSP	查看栈顶位置
EBP / RBP	辅助理解当前栈帧
EIP / RIP	当前即将执行的指令地址
Stack 窗口	查看函数参数、返回地址和局部数据
Dump 窗口	查看内存中的字符串或解密后内容
Breakpoints	在关键函数或地址处暂停程序

比较常见的断点位置包括：

字符串比较函数
文件读写函数
注册表操作函数
网络连接函数
进程创建函数
条件跳转附近

例如分析参数校验逻辑时，可以在字符串比较函数附近下断点；分析隐藏字符串时，可以在可疑循环或异或运算附近单步执行，观察内存中是否出现还原后的内容。

3.3.7 函数调用和寄存器监控

逆向分析时，不能只看某一条指令，而要结合函数调用、参数传递和寄存器变化一起理解。

在 32 位程序中，函数参数通常会通过栈传递；在 64 位程序中，前几个参数通常会通过寄存器传递。调试时需要结合具体调用约定观察参数来源。

常见分析方法如下：

1. 找到关键函数调用位置
2. 查看调用前压入了哪些参数
3. 观察寄存器中保存的地址或返回值
4. 单步进入或跨过函数调用
5. 比较调用前后的寄存器和内存变化

对于条件判断，需要重点看比较指令和跳转指令，例如：

cmp
test
je
jne
jz
jnz
call
ret

一般分析顺序是：

先看 cmp / test 比较了什么
再看 je / jne 跳向哪里
最后结合跳转后的代码判断成功分支和失败分支

这种方法在分析口令校验、文件名校验、参数校验和恶意行为开关时都很常用。

3.4 程序设计

3.4.1python程序设计

用 requests 发送和构造 HTTP 请求,可以自动化做信息搜集(比如 批量验证谷歌语法搜出来的链接)和 Web 漏洞测试(比如给登录表单提交不同的用户名密码,对比返回内容判断是否存在 SQL 注入);

用 scapy 手动拼数据包,可以做协议层面的攻击验证,比如伪造 ARP 响应包做缓存欺骗,或者构造带 SYN 标志位的 TCP 包做 SYN Flood;

写漏洞利用脚本时则常借助 pwntools这个库,比如栈溢出场景下用 p32()/p64() 按小端序打包地址,构造填充字节覆盖返回地址,再通过 send()/recv() 和目标程序交互拿到 shell,同样的思路也能用来自动化验证存储型 XSS 之类的 Web 漏洞是否被成功触发。

3.4.2栈溢出原理

栈溢出的根本原因在于函数调用时，局部变量、保存的寄存器值以及函数返回地址都会存放在栈上。如果程序使用了 gets()、strcpy() 这类不检查输入长度的危险函数，当输入数据超过缓冲区本身的大小时，多余的数据就会继续覆盖栈上后续内容，严重时会覆盖函数返回地址。

图 3-4-2 栈溢出原理示意图（自己画的）。

在实际利用中，我们需要先分析栈帧结构，明确 ebp、esp、局部变量区、saved EBP 和返回地址之间的位置关系。随后，通过计算缓冲区起始位置到返回地址之间的偏移量，构造特定长度的 payload。当前面的填充数据正好覆盖到返回地址位置时，再将返回地址改写为目标函数地址，例如 getShell()。这样函数执行结束并触发 ret 指令时，CPU 就不会返回到原来的调用位置，而是跳转到攻击者写入的地址继续执行。

这一过程还会受到程序保护机制的影响。通过 checksec 可以查看 NX、Canary、PIE、RELRO 等保护是否开启：Canary 会检测栈返回地址前的数据是否被破坏，NX 会限制栈上代码执行，PIE 会让程序地址随机化，RELRO 则会影响 GOT 表修改方式。因此，在正式利用前，需要先结合 checksec 判断程序防护情况，再决定采用 ret2text、shellcode、ROP 等利用方式。同时，也可以通过 IDA 反编译定位 gets()、strcpy() 等危险函数调用，从伪代码中还原程序输入逻辑和漏洞触发路径。

3.4.3程序设计上的经验

其实像python编写简单的poc脚本，有模板手搓起来不是复杂，但是现在这个vibecoding的时代，程序设计很多情况下可以交给AI来实现但是vibecoding遇到的最大的问题就是，网络安全的相关变成需求很容易触发安全风控，很多网络安全相关的。AI进行代码审计的能力也非常厉害，现在已经有非常多AI代审工具，发现了很多cve和cnvd。

3.5 计算机病毒技术

计算机病毒、蠕虫和木马都属于恶意代码，但三者的传播方式和功能重点不同。病毒通常需要依附在正常文件、可执行程序或文档宏中，依靠用户运行宿主文件完成感染；蠕虫重点在于较强的自我复制和主动传播能力，常通过网络扫描、漏洞利用、弱口令等方式扩散；木马则强调伪装和控制，通常伪装成正常软件，运行后在后台执行远程控制、信息窃取、下载恶意程序等操作。

病毒有非常多种，从传统的“熊猫烧香”等文件感染型病毒，到现在常见的勒索病毒（外国经常会有这种病毒，有的大公司为了避免负面影响，往往会交付赎金）、宏病毒、脚本病毒和无文件病毒，其攻击方式也在不断变化。随着网络发展，蠕虫其实渐渐用的不多了，木马逐渐从简单的隐藏程序演变为远程控制木马、下载木马和银行木马。

（特意回来加了一条）部分 Claude Code 版本会在检测到代理后，判断系统时区是否为 Asia/Shanghai 或 Asia/Urumqi，并检查代理地址是否与部分中国域名或人工智能机构有关，这一行为在网上引发了激烈地讨论，这很明显是一个后门（但是是否会被官方利用，成为木马，还有待观察）

3.6 网络溯源及防范技术

网络溯源主要是通过日志、流量和安全设备的告警信息，尽可能还原一次攻击是从哪里来的、什么时候发生的，以及攻击者做了什么。实际分析时，经常会查看 Web 日志、系统登录日志、防火墙日志和网络流量等内容，再根据 IP、时间、端口和请求特征把攻击过程串联起来。

不同攻击通常会留下不同的痕迹，例如暴力破解会出现大量连续登录失败，目录扫描会访问大量不存在的路径，SQL 注入可能会在请求中出现异常的 SQL 语句，而 DDoS 往往表现为短时间内流量或者连接数突然增加。

不过，网络溯源并不是简单地“找到一个攻击 IP”就结束了。IP 可能经过代理、跳板机甚至被伪造，所以更重要的是结合多种证据判断攻击路径和受影响范围。在护网里面，高级蓝队为什么“贵”，就是因为人家有能力溯源，要是在护网里面被抓到真实ip，那红队是要被狠狠扣分的。

3.7 加密解密技术

加密技术主要用于保护数据不被随意读取或篡改。常见的加密方式可以分为对称加密和非对称加密。对称加密使用同一把密钥进行加密和解密，例如 AES，速度比较快，适合加密大量数据；非对称加密则使用公钥和私钥，例如 RSA 和 ECC，更适合身份认证、密钥交换和数字签名。哈希算法则和普通加密不同，它主要用于生成数据摘要和进行完整性校验，例如 SHA-256。数字签名通常也会结合哈希算法和非对称密码技术，用于证明数据是谁发送的，以及内容是否被修改。HTTPS、软件签名、数字证书等技术，本质上都离不开这些密码学基础。

实际网络通信中，通常不会只使用一种加密算法，而是把多种技术结合起来。例如先使用非对称密码技术安全地协商密钥，再使用对称加密传输大量数据。

3.8 信息系统运行维护

信息系统运行维护主要就是保证服务器和各种服务能够长期、稳定、安全地运行。实际运维过程中，经常需要处理服务启动失败、端口无法访问、磁盘空间不足、进程异常、配置错误等问题。Linux 下常用 ps、top 查看进程，使用 free 查看内存，使用 df 和 du 检查磁盘空间，使用 ss 查看端口和网络连接，使用 systemctl 管理服务，再结合 journalctl 和各种日志文件定位具体问题。

我认为运维中比较重要的一点是形成固定的排查思路。例如一个服务无法访问，可以先检查服务有没有启动，再检查端口有没有监听，然后继续查看配置、日志、网络和系统资源。除了故障排查以外，备份、补丁更新、账号权限管理和安全加固也属于日常运维的重要内容。

3.9 法律

网络攻防并不是“技术上能做就可以做”，很多操作首先需要考虑授权和法律边界。网络安全相关法律法规主要涉及网络安全、数据安全和个人信息保护等方面，常见的包括《网络安全法》《数据安全法》和《个人信息保护法》等。

在实际学习和进行网络攻防实验时，最重要的是明确授权范围。未经允许扫描、攻击或者获取他人系统中的数据，都可能带来法律风险。即使是在漏洞研究中，也需要注意漏洞披露方式和数据处理范围。

我认为在dky学习网络安全不仅要掌握攻击和防御技术，更要知道哪些事情可以做、在什么范围内可以做。尤其是在涉及真实网站、真实用户数据和个人信息时，应该始终把授权和合规放在前面。

3.10 电子取证

电子取证主要是从计算机、手机、磁盘、内存和网络设备等数字设备中提取、分析和保存与事件有关的证据。常见的电子取证内容包括磁盘取证、内存取证、文件系统分析、手机取证和车联网取证等。例如，可以通过文件系统恢复被删除的文件，查看文件的创建、修改和访问时间；通过内存镜像分析正在运行的进程、网络连接和恶意代码；通过日志和网络流量还原攻击者的操作过程。

电子取证中比较重要的是证据链和完整性校验。通常会使用 MD5、SHA-256 等哈希算法计算证据文件的摘要，只要文件内容发生变化，哈希值通常也会改变，从而判断证据是否被修改。整个取证过程还需要记录证据来源、获取时间、使用工具和分析步骤，使后续分析结果能够被验证和复现。

常见的取证工具包括火眼取证、美亚取证、（这两个学生可以申请专业版，非常专业的取证工具）、 FTK Imager、Autopsy（镜像挂载工具）、Volatility、Wireshark 和 010 Editor 等。实际分析时，一般按照“获取证据、验证完整性、提取信息、分析关联、还原事件”的思路进行。电子取证的重点并不只是找到某一个文件或记录，而是通过多个证据之间的关联，尽可能还原完整的事件过程。

在CTF电子取证题目中，许多挑战都会模拟较为真实的安全场景。我们通过“鼠标到处点点”，从看似零散的信息中寻找蛛丝马迹。取证题目本质是题量很大，需要耐心和不断搜索相关知识来进行取证分析。

四、课堂收获与不足

我想先谈谈这门课最大的不足！首先，在课程初期撰写实验报告时，我没有认真校对正文和参考文献，直接保留了 AI 生成的参考文献，导致其中存在不准确、无法核验的问题。AI 生成的内容只能作为辅助，不能代替人工核查，尤其是参考文献、实验数据更要多加留意。这件事也督促我这学期参与投稿的几篇论文，我都从谷歌学术一一校对了bibtex。其次，在具体实验过程中，我有时过于执着于某一种解决思路，不够灵活。遇到问题时，我常常希望完全依靠自己的方法将其解决，即使进展缓慢，也不愿及时调整思路或尝试其他方案。因此，部分实验耗费了较多时间，而最终采用的方法也未必是最简洁、最高效的。

虽然我以前也学习过网络攻防相关课程，但这是我第一次通过一门课程，较为系统地接触协议安全、Web 安全、二进制安全、恶意代码分析和电子取证等多个方向，并从信息搜集、漏洞分析与利用、流量检测到攻击溯源与安全加固，较完整地理解网络攻防的基本流程。通过一系列实践，我不仅进一步掌握了相关安全原理，也更加熟悉了常用工具的使用方法，对不同安全方向之间的联系有了更清晰的认识，也让我重新找回写博客的感觉。

大一写csdn的成果hhh

在完成每一次实验时，我也尽量保留自己的思考过程，而不是简单照着实验指导书复现步骤，再对博客内容进行润色。我经常会思考是否存在更合适、更新颖或更高效的实现方式，并尝试使用不同工具进行交叉验证。虽然这些尝试有时增加了实验时间，甚至让我走了一些弯路，但是“折腾”也是学习网络安全的乐趣所在。

这门课程最大的收获，还是让我重新找回了当初参加 CTF 时面对问题苦思冥想的感觉。很多问题并不能直接从指导书中找到完整答案，很多bug同学没遇到只有自己才有，必须得自己去查资料、问AI，自己去研究问题的原理。比最终是否顺利完成某一个实验，我认为这种愿意持续思考、反复验证并享受解决问题过程的状态，才是我在这门课程中最珍贵的收获。