南京邮电大学网络信息安全实验资源：源码、报告与避坑指南

简介南京邮电大学网络信息安全课程实验报告与源码说明资料包面向该校网络信息安全方向本科生与课程学习者也适合需要复习实验考点、独立完成课程设计的同学重点解决实验流程不清晰、报告撰写不规范、源码调试无从下手等问题。压缩包整体约152.84MB以实验报告和源码说明文件为主覆盖网络攻击与防御、密码算法、协议分析等课程核心实验为复习迎考和动手复现提供了系统参照。目前已有204人学习使用适合对照实验要求逐项查漏补缺。通过阅读源码注释与实验报告可掌握抓包分析、加密算法实现、防火墙配置等典型任务的解决路径学习从需求分析、代码调试到结果验证的完整流程并参考规范的报告结构与排版方式。资料按实验模块组织便于按需查找相比零散笔记这套压缩包能更完整地还原课程实验从设计、编码到总结的全过程提升实验应试与实操能力。1. 南京邮电大学网络信息安全课程实验资源报告、源码与说明文档的价值点南京邮电大学的网络信息安全课程实验资源核心不在于代码量有多大而在于“实验报告、源码、源码说明”是不是一个闭环。课程资料里最常见的问题是报告贴了半页代码却没有参数说明换台机器根本跑不起来。这份资源把几个典型实验的报告模板、可执行源码和“怎么跑、输出什么、报告填什么”的说明文档打包在一起覆盖密码学算法、网络嗅探、主机安全配置和入侵检测几个方向。适合正在补实验、准备课程设计或者系统复习网安基础的人也适合刚接手这门课程、想少踩坑的本科生。下面按我的拆包习惯把这份资源的使用路线讲清楚。2. 资源结构拆解实验报告、源码与说明文档怎么配套使用2.1 实验构成与实际文件组织这份资源按照网络信息安全课程常见大纲组织不同学期实验载体略有差异但核心验证点是稳定的。典型的实验构成如下表实验模块常见实验载体报告需要写出的核心验证点对称加密Python/C/Java 调用密码库实现 AES/DES明文、密文、密钥、IV、填充方式公钥密码与数字签名RSA 密钥对生成、私钥签名、公钥验签密钥长度、签名长度、Hash 算法哈希摘要md5sum、sha256sum 等命令行工具摘要长度、碰撞与适用场景对比网络嗅探tcpdump / Wireshark 抓包TCP 三次握手、HTTP 请求字段防火墙与端口扫描iptables nmap端口状态变化、规则命中次数入侵检测Snort 规则配置与告警规则触发条件、告警日志内容拿到压缩包后我一般会先解压建目录树一次看清整个包的结构而不是直接双击打开某个源码文件。Linux 下的操作方式是这样unzip 南京邮电大学-课程实验-网络信息安全-实验报告和源码说明.zip -d lab cd lab tree -L 2-d lab指定解压到 lab 目录避免压缩包里多层嵌套的目录直接把文件散落到桌面tree -L 2只显示两层目录结构目的是快速区分“报告模板”“源码”“说明文档”三个区域不会被 build 目录或中间产物刷屏。如果压缩包解压后文件名出现乱码那多半是编码问题处理方法在第五章避坑清单里详说。Windows 下用资源管理器解压也完全可行只是建议解压后马上整理出文件清单再对照报告模板找源码入口。2.2 源码与实验报告的对应关系这份资源的源码说明通常不会把整份项目文档贴出来而是针对每个实验给出主程序入口、依赖环境和“报告里应该抄哪几个输出”。我的读包习惯是先在报告模板里找到实验目标再回到源码目录里定位对应文件。比如报告模板里第一个实验是“对称加密算法对比”那源码目录下一般会有aes_demo.py、des_demo.py这样的文件。pip install pycryptodome python aes_demo.py这里pip install pycryptodome装的是当前主流的密码学库pycrypto 已经停止维护老实验包里如果写的是from Crypto.Cipher import AES新的 pycryptodome 也能兼容。运行python aes_demo.py后如果输出里出现“AES-128-CBC”和十六进制密文说明环境已经跑通。报告里的“实验过程”部分把自己实际跑出来的密文粘贴进去再补一句参数说明即可不用把 AES 算法推导过程抄一遍。报告的重点是“你调用了什么参数、输出了什么、和理论是否一致”如果这一步只有代码没有输出数据老师一问就穿帮。所以源码说明文档的意义就是把“在哪改参数、在哪看输出”给你标出来避免你和代码互相看不懂。3. 密码学实验复现从对称加密到 RSA 签名的完整闭环3.1 AES-128-CBC 加解密参数对齐是第一步对称加密实验通常要求对比 DES 和 AES。AES 的参数项比 DES 多一个 IV这也是最容易翻车的地方。下面是一个可以照跑的 AES-128-CBC 样例# aes_cbc_demo.py from Crypto.Cipher import AES from Crypto.Util.Padding import pad, unpad import binascii # AES-128 要求密钥恰好 16 字节即 128 位 key b1234567890abcdef iv b0000000000000000 cipher AES.new(key, AES.MODE_CBC, iv) plaintext bNetwork Security Lab Report ciphertext cipher.encrypt(pad(plaintext, AES.block_size)) print(密文hex:, binascii.hexlify(ciphertext).decode()) # 解密必须使用同一 key 和 iv dec_cipher AES.new(key, AES.MODE_CBC, iv) decrypted unpad(dec_cipher.decrypt(ciphertext), AES.block_size) print(解密结果 :, decrypted.decode())参数说明key是 16 字节对应 AES-128如果把 key 改成 32 字节自动变成 AES-256输出密文长度也会相应变化。iv在 CBC 模式下必须与加密端一致否则解密后前 16 字节是乱码。pad(plaintext, AES.block_size)用的是默认的 PKCS7 填充AES 块大小固定为 16 字节所以明文长度不是 16 的倍数时会被自动补齐。ECB 模式不需要 IV但相同明文会得到相同密文报告里如果让你对比 CBC 和 ECB 的差异这一点是核心结论。报告里需要验证密文一致性时可以用 openssl 命令行平行算一遍echo -n Network Security Lab Report | openssl enc -aes-128-cbc -K 31323334353637383930616263646566 -iv 30303030303030303030303030303030 -nosalt | xxd-K和-iv后面跟的是十六进制形式。31323334353637383930616263646566对应的 ASCII 字符串正好是1234567890abcdef因为31是字符1的 ASCII 码32是2。-nosalt必须加openssl 默认基于口令加密时会生成随机盐导致相同 key 也产生不同结果。如果这里对不上多半是echo -n后面多了空格或者明文末尾被加了换行符。填报告时把“PKCS7 填充、CBC 模式、16 字节 IV”三个参数明确写出来比抄十行代码更有说服力。3.2 RSA 密钥生成与数字签名公钥私钥别搞反RSA 实验的重点是密钥对生成和签名验签流程。课程实验里经常出现的问题是把公钥和私钥的角色理解反了签名一定用私钥验签一定用公钥。下面的样例可以直接对照源码说明运行# rsa_sign_demo.py from Crypto.PublicKey import RSA from Crypto.Signature import pkcs1_15 from Crypto.Hash import SHA256 # 生成 1024 位 RSA 密钥对 key RSA.generate(1024) private_key key.export_key() public_key key.publickey().export_key() print(私钥长度:, len(private_key), bytes) print(公钥长度:, len(public_key), bytes) msg bhello njupt h SHA256.new(msg) sig pkcs1_15.new(key).sign(h) print(签名长度:, len(sig), bytes) # 验签必须用公钥 try: pkcs1_15.new(key.publickey()).verify(h, sig) print(签名验证: OK) except (ValueError, TypeError): print(签名验证: FAILED)RSA.generate(1024)后面的 1024 指密钥位数课程实验通常用 1024 或 2048。2048 安全性更高但生成和签名耗时明显变长。签名长度等于密钥位数除以 81024 位对应 128 字节如果报告里出现 256 字节的签名长度说明用了 2048 位密钥。这里SHA256.new(msg)是先对消息做摘要再签名签名结果是摘要的加密值而不是对整条消息加密。验签异常包括两类一是 key 角色调换拿私钥对象去 verify二是消息被改动哈希值对不上。报告中一般要求把私钥、公钥导出成 PEM 文件存档验证时再用文件导入避免把私钥直接硬编码在验证代码里。PEM 格式是另一个隐蔽的坑。新版本 pycryptodome 导出公钥默认是 PKCS#8 格式老版本导出的是 PKCS#1两种格式开头一行内容不同openssl rsa -pubin -in public.pem -RSAPublicKey_out这条命令可以把 PKCS#8 公钥转换成 PKCS#1 格式。报告中如果粘贴公钥内容时出现两行不一致的 base64多半就是格式混用了。把密钥长度、签名长度、Hash 算法这三项写进报告的“实验数据”表格RSA 实验就算完整了。3.3 哈希与 HMAC 对比报告表格里写什么哈希实验一般不会要求你从头实现 SHA-256而是用命令直接对比摘要算法表现。源码说明里通常会提供一个对比表格模板我按实际跑出来的数据填echo -n njupt network security | md5sum echo -n njupt network security | sha256sumecho -n不输出末尾换行确保摘要内容精确是njupt network security。MD5 输出固定 32 位十六进制字符SHA-256 输出 64 位。报告用表格式对比更清晰算法摘要长度当前安全性评价典型应用场景MD5128 bit已存在碰撞不用于签名文件完整性快速校验SHA-256256 bit目前安全数字签名、口令哈希SM3256 bit国产商用密码标准合规场景强制要求如果实验涉及 HMAC还需要区分“哈希”和“带密钥的哈希”。HMAC 的输入多一个 key输出长度和底层的 SHA-256 一样但密钥参与了两轮压缩运算所以相同消息在不同密钥下输出完全不同。报告里如果只贴摘要值而不写是否使用密钥老师会追问。这个实验本身不难但要在报告中写清楚“我对比了哪些算法、输入是什么、输出长度是多少”不要只丢一串哈希值。4. 网络攻防实验落地抓包分析、端口扫描与防火墙规则配置4.1 tcpdump 抓包与 TCP 三次握手验证网络嗅探实验的核心是验证 TCP 三次握手。用 tcpdump 在 Linux 下抓包再用 Wireshark 打开做协议分析是课程资料里最常见的组合sudo tcpdump -i eth0 -n tcp port 80 -c 20 -w http_handshake.pcap参数含义-i eth0指定抓包网卡先执行ip addr确认当前机器实际网卡名避免eth0不存在导致抓包失败-n不做 DNS 反解直接显示 IP避免抓到一堆解析日志干扰分析tcp port 80是抓包过滤表达式只保留 80 端口的 TCP 包-c 20表示抓满 20 个包自动结束适合课程实验场景-w把报文保存为 pcap 文件。抓包完成后用 Wireshark 打开筛选出tcp.flags.syn1能看到客户端发送 SYN服务器回 SYN-ACK客户端再回 ACK 的过程。报告里需要记录的字段是源端口、目的端口、Sequence Number 和 ACK Number。抓包之前记得先在另一台终端发起 HTTP 请求否则网卡上没有流量-c 20会一直等下去。常见做法是curl http://example.com -o /dev/nullcurl访问后tcpdump 会立刻捕捉到 TCP 连接。这里有一个重要的实验设计问题如果访问 HTTPS80 端口过滤条件根本看不到应用层内容后面避坑章节会展开讲。报告里应该写清楚“访问的是明文 HTTP”才能解释抓到的包里有GET / HTTP/1.1请求行。4.2 nmap 端口扫描与 iptables 防火墙联动主机安全实验一般分三步先扫描开放端口再配置防火墙规则最后重新扫描验证状态变化。下面是典型操作# 扫描目标主机的 22、80、443 端口 sudo nmap -sS 192.168.137.10 -p 22,80,443 # 配置防火墙同网段允许访问 SSH其余来源直接丢弃 sudo iptables -A INPUT -p tcp --dport 22 -s 192.168.137.0/24 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 22 -j DROP-sS是 TCP SYN 半开扫描只发送 SYN 包、根据是否收到 SYN-ACK 判断端口状态。半开扫描需要 root 权限所以前面加了sudo如果没有 root 权限nmap 会退化为-sT全连接扫描速度更慢且会在目标机器上留下完整连接记录。iptables 两条规则顺序敏感ACCEPT规则在DROP规则之前同网段的包先被放行如果两条顺序颠倒先匹配到DROP规则的包直接被丢弃同网段也无法连接实验现象完全反了。课程报告里需要解释为什么配置前 22 端口是open配置后变成filteredfiltered状态说明防火墙丢包后没有任何回应nmap 无法区分端口是否开放。扫描时注意不要扫描和自己不同网段的机器课程实验一般在 VMware 或 VirtualBox 的 NAT 网段内完成。如果目标机器和扫描机不在同一网段中间隔着路由设备防火墙规则再强也可能误报。报告里把扫描机的 IP、目标机 IP、防火墙规则三条信息列出来实验结论自然成立。4.3 入侵检测规则与告警日志验证Snort 实验在课程中作为扩展部分重点是验证规则是否真正触发。下面是一条基础规则和启动命令echo alert tcp any any - 192.168.137.10 80 (msg:HTTP access detected; sid:1000001; rev:1;) /etc/snort/rules/local.rules sudo snort -A console -q -c /etc/snort/snort.conf -i eth0规则头的结构是“动作 协议 源地址/源端口 方向 目的地址/目的端口”。alert tcp any any - 192.168.137.10 80表示任何来源的 TCP 流量访问本机 80 端口时触发告警msg是控制台显示的提示文字sid是规则唯一标识自定义规则建议从 1000000 之后开始避免和系统内置规则冲突。启动参数中-A console把告警直接打印到终端-q减少启动信息输出-c指定配置文件-i指定监听网卡。验证规则是否生效最简单的方式是在另一台机器上curl http://192.168.137.10然后回到 Snort 终端看有没有出现[**] [1:1000001:1] HTTP access detected告警。如果没有任何输出先检查/etc/snort/snort.conf里的HOME_NET配置默认的any虽然能匹配所有地址但有些模板会把HOME_NET写成固定网段导致规则目的地址不匹配。报告里写告警日志时把规则编号1:1000001:1和触发流量描述都贴上完整性更好。5. 避坑清单从解压到交报告最容易翻车的五个细节5.1 解压、编码与代码环境类坑一zip 解压后文件名乱码现象解压出来的文件变成黑活之类无法识别的乱码文件名双击后记事本打开内容也是乱码。原因压缩包生成时使用了中文文件名且编码标志位不兼容Windows 资源管理器按 GBK 解压macOS 或 Linux 默认按 UTF-8 解压两边对不上。解决Windows 下用 7-Zip 右键解压到指定目录Linux 下用unzip -O gbk 资源包.zip -d lab指定 GBK 编码解压。macOS 下推荐使用 The Unarchiver它对这种混合编码处理得比较好。坑二导入 Crypto 报 ImportError现象按要求执行python aes_demo.py直接报ModuleNotFoundError: No module named Crypto。原因当前环境只装了 Python 但没有密码学库或者之前同时装过 pycrypto 和 pycodestome两个包共享Crypto前缀相互冲突导致 import 失败。解决先彻底卸载再重装。pip uninstall pycrypto pycryptodome -y pip install pycryptodome5.2 密码学与网络验证类坑三AES 密文和 openssl 输出对不上现象Python 输出密文是7a8f...openssl 输出是9d0c...长度和内容都不一样。原因openssl 的enc命令在默认情况下基于口令生成密钥会附带一个 8 字节随机盐直接用-K传十六进制密钥时如果不加-nosalt输出的结果仍然包含盐头导致密文不一致。解决openssl 命令行显式加-nosalt并确认-K、-iv的十六进制值从 ASCII 字符串转出来与 Python 里一致。很多时候只是echo末尾多了空格。坑四nmap 扫描结果全是filtered现象配置 iptables 之前扫描目标端口显示open配置规则后所有端口变成filtered包括没有配置规则的 8080 端口。原因虚拟机网卡模式下扫描机的流量到达目标机之前经过了一层 NAT某些情况下虚拟网络把未匹配的包丢弃也可能是目标机的系统防火墙默认策略是DROPnmap 收不到任何回应无法区分closed和filtered。解决先用sudo nmap -sT做全连接扫描建立基线能看到端口在防火墙规则变更前是open、配置后变成filtered。如果还是全部 filtered把目标机防火墙规则改成 REJECT 并带tcp-reset这样 nmap 能明确识别closed。报告中写明“扫描机和目标机均在 NAT 网段内”这个前提比端口状态本身更重要。坑五抓包文件里看不到 HTTP 明文现象用tcp port 80抓包打开 pcap 文件后发现所有包都是 TLS 协议没有GET / HTTP/1.1明文请求。原因访问的是 HTTPS 域名浏览器默认走 443 端口TLS 加密后的内容在应用层不可见。解决改用curl http://neverssl.com -o /dev/null访问一个明确支持明文 HTTP 的站点或者先抓 443 端口看 TLS 握手过程再切换到 80 端口抓明文 HTTP。报告中如果强调“验证 TCP 三次握手”两种方式都行如果强调“分析 HTTP 请求字段”必须用明文 HTTP 流量。6. 验收习惯提交报告前用一条命令把实验闭环实验报告写完之后最怕的是代码能跑但报告里的数据是复制别人的或者代码在自己电脑上能跑、换台机器就崩。我的习惯是提交前做一遍完整验收核心是“重新从源码跑一遍看输出是否和报告一致”。具体流程可以打包成一个简单的检查脚本# 逐个运行源码目录下的 python 文件统计输出是否包含关键字段 for f in $(ls lab/source/*.py); do echo $f python $f 21 | head -5 done这段脚本遍历源码目录下所有 Python 文件逐个运行并打印前五行输出。作用不是替代人工检查而是逼着自己确认每个实验都有实际出口。如果某个脚本运行报错输出的前五行就是堆栈开头马上能定位缺包还是缺文件。README 文档里列出的每个实验模块我都要求至少跑出“报告里出现的那个关键数值”比如 AES 的密文、RSA 的签名长度、Snort 的告警记录。只要数值对得上报告里的实验过程才算真正闭环。从那段被 AES 和 openssl 的盐头折腾到深夜的经历之后我拿到任何实验包都会先跑一遍这种“空输出检查”再动手写报告。宁可花十分钟确认脚本能跑也不要等交报告前一天发现采集的数据缺失。希望帮到你。本文还有配套的精品资源点击获取