简介这是一份面向网络安全课程设计场景的端口监控程序完整源码基于MFC对话框框架实现可对指定IP地址、指定端口与自定义线程数执行多线程端口扫描适合高校信息安全、网络工程等专业学生作为课程设计或实验参考。文件共17个核心代码集中在4个头文件与3个C源文件中涵盖端口扫描逻辑、线程调度和对话框界面另含工程文件、图标与资源脚本便于在Visual C 6.0中直接打开编译压缩包仅29KB。已有238人浏览学习。结合代码可理解端口扫描的基本原理与实现细节学习入侵者如何探测目标主机的开放端口进而据此加固本机系统为将来设计更安全的网络应用打下基础。1. 网络安全终端监控里的端口扫描代码课程设计到底要你交什么端口扫描看起来像黑客电影里的戏码但落到“网络安全终端监控”这门课程设计里它只是一段需要稳定运行的网络探测代码。你的目标是输入一个 IP 或者网段输出这台设备上正在监听的 TCP 端口清单再把这个清单交给你写的监控逻辑去做异常判断。我见到的课程设计几乎都会把这个模块放在整套代码最前面因为端口一变通常意味着服务装错了或者机器可能被动手脚。适合做这个方向的是已经有一门 Python 或 C 语言编程基础、手里有一台虚拟机或教学机房机器的同学如果你还没理解三次握手先看完第二章再写代码能少改一半 bug。2. 端口扫描原理与课程设计定位先搞清 TCP 半开扫描和三次握手再动手写2.1 终端监控为什么必须依赖端口扫描一台主机启动某个服务时服务端程序会调用 bind() 绑定一个 IP 和端口然后进入 LISTEN 状态监听连接。比如 Web 服务监听 80 或 443远程登录服务监听 22数据库可能监听 3306。这些端口就是操作系统里对外开放的“门牌号”。端口扫描做的事情就是主动去连接这些端口看哪些端口愿意响应“我可以接受连接”从而反推出这台机器正在运行哪些网络服务。放到终端监控的场景里这个信息不是课外附加题。一台被管控的终端如果突然多出几个对外监听的端口极有可能意味着被植入了后门程序或者被安装了违规的外部访问软件反过来一个本该在 443 端口提供服务的业务主机突然扫不到 443那就要立刻检查服务是否崩溃、配置是否被改动。可以说没有端口扫描模块终端监控只能看到进程列表和 CPU 占用看不到网络上到底暴露了什么。把这两件事绑在一起正是这门课程设计想让你掌握的核心能力。2.2 三种常见扫描方式TCP connect、SYN 半开、UDP课程设计答辩时老师大概率会先问“你用的是哪种扫描方式”。常见的端口扫描有三类区别主要在对 TCP 三次握手的处理上。扫描方式原理权限要求速度对目标产生的影响课程设计推荐度TCP connect 扫描完整建立三次握手连接成功说明端口开放普通用户即可中等会留下完整连接记录目标日志能看到最推荐SYN 半开扫描只发 SYN收到 SYN-ACK 就判定开放不发起 ACK 完成握手需要 root 权限构造原始报文快目标一般只会记录到异常半连接可讲原理不建议主写UDP 扫描发送 UDP 报文靠 ICMP 端口不可达判断关闭普通用户即可慢且不可靠可能触发目标系统大量 ICMP 响应只做扩展项TCP connect 扫描最贴近“课程设计”的定位代码逻辑直观、不依赖底层 raw socket、普通账号就能跑。它的原理就是主动完成一次三次握手客户端发 SYN服务端回 SYN-ACK客户端再回 ACK握手完成。如果端口没监听内核会直接回 RST握手在第一步就中断connect 调用立即失败。你只要会调用系统提供的 socket 接口就不需要关心底层报文封装的细节。SYN 半开扫描在原理上更“黑客”但在纯 Python 里实现非常别扭你要自己构造 IP 头和 TCP 头算校验和用 raw socket 发送而 Windows 和大部分 Linux 教学环境对普通用户的 raw socket 都有限制。与其把大量时间耗在底层协议栈上不如先把 TCP connect 扫描做扎实然后在文档里把 SYN 原理讲清楚这已经能满足课程设计的考核要求。UDP 扫描则更麻烦因为很多 UDP 服务不回应任何报文判断不能得出结论只适合作为加分项写进报告。2.3 课程设计评分的三个考察点正确性、异常处理、结构化输出我给学生看代码时经常说课程设计不是“效果越炫评分越高”而是看代码能不能被别人复用。评分通常落在三个点上。第一是正确性扫描结果和系统自带的 netstat 或第三方工具比对不能出现大量漏报和误报。第二是异常处理目标不可达、连接超时、线程池抛错这些分支都要处理干净不能随便崩掉。第三是输出结构化扫描结果不应该只是 print 到控制台而应该返回一个列表或 JSON 对象方便终端监控模块继续消费。曾经有个同学把扫描结果全部 print 到屏幕上监控子模块完全不知道去哪里读取答辩时又把代码写成了硬编码端口列表换个目标 IP 就得改源码。这个案例我印象很深课程设计的端口扫描代码本质上是给下一个程序调用的不是给老师肉眼看的。所以我建议你把代码拆成三层底层函数只负责“输入一个 IP 和端口返回布尔值”中层负责“扫描一段端口返回开放端口列表”上层负责“把结果记录成 JSON 或写入数据库”。三层分开后面改并发、加服务识别、加告警逻辑都会顺手很多。3. 用 Python 交付可运行的端口扫描代码从单线程到并发3.1 最小可运行版本基于 TCP connect 的单线程扫描先别急着上并发把最小可运行版本跑通更重要。这段代码可以直接保存成scanner.py只依赖 Python 标准库 socket不需要装任何第三方包。import socket def check_port(host: str, port: int, timeout: float 1.0) - bool: 检测目标主机上的单个 TCP 端口是否开放。 返回 True 表示端口开放False 表示关闭或不可达。 sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(timeout) try: # connect_ex 返回 0 表示连接成功非 0 表示失败 return sock.connect_ex((host, port)) 0 except OSError: # 超时、网络不可达等情况下直接视为不可用 return False finally: sock.close() if __name__ __main__: target 127.0.0.1 for port in range(1, 1025): if check_port(target, port): print(f{port} open)这里我特意用了connect_ex而不是connect()。connect()在超时会抛出TimeoutError连接被拒绝会抛ConnectionRefusedError每个错误都要单独写 try 分支代码会显得很啰嗦。connect_ex会把结果直接映射为错误码整数0 表示连接成功其余值代表不同的失败原因更适合写扫描器这种“结果只有开或关”的场景。注意函数的三个参数host是目标 IPport是要测的端口timeout控制单次连接的超时秒数。finally里sock.close()必须保留否则大量 socket 句柄堆积会导致程序运行一段时间后报“无法分配文件描述符”的错误。这段代码的问题也很明显单线程逐个连接扫描 1 到 1024 端口在内网可以接受但如果目标在跨网段、防火墙策略严格的地方每个端口都要等满 timeout 秒整个扫描会拖得很久。先跑通这个版本等于给后面的并发版本留了一张正确性对照表。3.2 加并发用线程池把扫描时间从几分钟压到几秒终端监控需要周期性扫描单线程版本扫一次要等好几分钟显然不现实。常见做法是引入concurrent.futures.ThreadPoolExecutor用一批线程同时发起连接。socket 的 connect 属于 I/O 等待型操作等待期间线程会主动让出 CPU所以即使 Python 有 GIL这段代码依然能获得接近线性的并发提升。from concurrent.futures import ThreadPoolExecutor, as_completed def scan_one(host: str, port: int, timeout: float): 单个端口扫描的线程任务返回 (端口, 是否开放)。 sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(timeout) try: if sock.connect_ex((host, port)) 0: return port, True return port, False except OSError: return port, False finally: sock.close() def scan_ports(host: str, ports, timeout: float 1.0, max_workers: int 256): 并发扫描端口列表返回升序排列的开放端口列表。 open_ports [] with ThreadPoolExecutor(max_workersmax_workers) as executor: future_map { executor.submit(scan_one, host, port, timeout): port for port in ports } for future in as_completed(future_map): port, is_open future.result() if is_open: open_ports.append(port) return sorted(open_ports)max_workers256不是越大越好。本机实验室环境 256 足够再高会让系统同时堆积大量半开连接反而加大丢包概率产生大量假超时。timeout的设置在第四章里会专门讲这里只要记住局域网目标用 0.3 到 1.0 秒跨网段建议 1.5 秒以上。这段代码还有一个容易被忽略的好处每个线程创建的 socket 都是独立的线程之间没有任何共享可变状态天然线程安全。如果你尝试把同一个 socket 分给多个线程去并发 connect那才是真正的“玄学”现场。另外as_completed会按完成顺序返回结果而不是按提交顺序所以最后必须对open_ports做一次sorted()保证输出稳定方便后续比对。3.3 把结果整理成监控能用的 JSON 记录课程设计的终端监控模块需要知道三件事扫描的是哪台主机、什么时候扫的、哪些端口是开放的。只返回一个裸列表不满足要求。我在项目里一般会把上层输出设计成 JSON 对象这样无论是写文件、写数据库还是传给前端展示都不用改接口。import json import time def scan_host_to_record(host: str, start_port: int 1, end_port: int 1024, timeout: float 1.0, max_workers: int 256): 扫描指定主机的端口区间返回一条结构化记录。 ports range(start_port, end_port 1) open_ports scan_ports(host, ports, timeout, max_workers) return { host: host, timestamp: time.strftime(%Y-%m-%d %H:%M:%S), open_ports: open_ports, count: len(open_ports), } if __name__ __main__: record scan_host_to_record(127.0.0.1) print(json.dumps(record, ensure_asciiFalse, indent2))输出示例会像这样{host: 127.0.0.1, timestamp: 2025-01-15 14:22:30, open_ports: [80, 443], count: 2}。这个结构有什么用终端监控模块拿到记录后把同主机的相邻两次记录做差集就能得到“新增端口”和“消失端口”两个列表。新增端口意味着可能部署了新服务或出现可疑程序消失端口意味着业务异常下线这些才是真正需要告警的事件。时间戳字段也很关键没有时间戳历史记录就无法排序课程设计里最常用的“增量变化”功能也就做不出来了。4. 扫描参数怎么调超时、线程数、端口范围和服务识别4.1 超时时间内网用 0.3 秒跨网段用 1.5 秒误报怎么控制端口扫描翻车最多的地方不在代码逻辑而在参数设置。timeout设短了目标明明开放却来不及回包扫描结果就是一片“假关闭”设长了每次扫描耗时长课程演示时机器容易卡在三五分钟没有任何输出。我给你一个相对稳妥的经验同一个交换机或同一台物理机上的虚拟机RTT 通常不超过 2 毫秒timeout 给 0.3 秒就够跨机房、跨网段、经过防火墙的常规链路timeout 给 1.5 到 2 秒公网目标建议至少 3 秒但课程设计里我不建议拿公网主机乱试。扫描总耗时大概可以按这个公式估算端口数量除以并发线程数再乘以超时时间。所以如果端口范围实在太大优先考虑减少端口数而不是盲目调低 timeout。还有个细节值得单独说connect_ex在超时后会抛出OSError的子类异常而不是返回一个可读错误码。所以我在 3.1 节里用 try 包裹了整个调用的处理是必要的。你要判断“超时”和“连接被拒绝”其实可以进一步区分但课程设计里把两者都归为“端口未开放”即可因为监控系统的动作都是重新扫描或者告警不会深究失败模式。4.2 端口服务识别不要只返回端口号用 getservbyport 和 banner只返回端口号老师会问你“8080 到底是什么服务”。常见做法是调用socket.getservbyport()把端口翻译成服务名比如 22 映射到 ssh80 映射到 http443 映射到 https。这个函数读的是系统服务表在 Windows 和 Linux 上结果略有差异但通常够用。def guess_service(port: int) - str: 尽力猜测端口对应的常见服务名识别不了则返回 unknown。 try: return socket.getservbyport(port) except OSError: return unknown如果你想在课程设计里拿一个加分项可以再做 banner 抓取。很多服务在连接建立后会主动打印一条版本信息最典型的是 FTP、SSH、HTTP。抓到了版本就可以结合端口共同判断服务是否异常。def grab_banner(host: str, port: int, timeout: float 2.0) - str: 尝试读取目标端口返回的第一行 banner 信息。 try: s socket.create_connection((host, port), timeouttimeout) s.sendall(b\r\n) banner s.recv(256) s.close() return banner.decode(utf-8, ignore).strip() except OSError: return 注意事项是不是所有服务都会主动发 banner有的服务收到非法数据直接关连接有的服务根本不理会\r\n所以这个函数的返回值只能作为辅助证据不能用它作为端口是否开放的唯一判断依据。建议把grab_banner单独放到一个函数里只对已确认开放的端口调用避免对大量关闭端口做无意义探测。4.3 三种场景的参数模板本机、教学机房、模拟靶场课程设计一般会在三种环境里运行自己的本机、教学机房局域网、两台虚拟机组成的模拟靶场。三种环境的参数完全不一样我一般会在代码开头放一个参数配置区统一维护。场景端口范围timeout线程数说明本机回环地址1-655350.1-0.3 秒256扫描速度很快适合功能自测教学机房同一网段1-10240.3-0.5 秒128并发不要太高避免影响同机房其他机器虚拟机模拟靶场1-100001.0-2.0 秒200目标防火墙策略不一致预留重试空间表格里的 1-1024 和 1-10000 区间都只是一个建议按课程要求改。如果你把教学机房所在的网段整个扫一遍建议按单台主机逐个扫并且每台主机之间留一点间隔不要让同一秒内大量 SYN 包并发涌向整个机房。一个很常见的做法是加一个delay_between_hosts参数单位秒默认 0.2 秒只在多主机扫描时生效。这个细节讲出去至少能避免现场被其他正在上课的同学投诉网卡卡。5. 端口扫描代码的常见翻车与排查超时全灭、结果对不上、卡死5.1 现象所有端口都显示关闭或超时这个现象我见过太多次。学生信心满满跑程序结果 1 到 1024 端口全部超时第一反应是“代码写错了”。其实代码大概率没问题问题是目标主机不搭理你。原因是目标机器的防火墙在默认策略下丢弃了陌生来源的连接请求或者代码里写了host localhost而目标服务只监听了 IPv6 的::1你的 IPv4 socket 永远连不上再或者两台机器虽然在同一网段但互相之间被交换机的端口隔离策略挡住了。解决步骤按顺序来先用ping -c 3 目标IP确认网络可达再用nc -zv -w 2 目标IP 具体端口单独测一个已知开放端口比如目标机器上确定跑着的 22 或 80确认业务端口正常最后检查代码里连接的 IP 和实际目标机 IP 是否一致尤其别把 WiFi 网卡的 IP 误当成了虚拟机 IP。如果 ping 不通但同网段内其他机器能通就先去目标机器上看防火墙状态在受控的教学环境里临时关闭防火墙可以辅助排查但这是排查手段不是最终方案实验做完要记得还原。5.2 现象扫描结果和系统自带 netstat 对不上扫描结果明明显示 8080 端口开放用netstat -an看却找不到这个端口于是怀疑代码误报。这种对不上往往不是同一个概念。原因有三个。第一netstat默认显示 IPv4 和 IPv6 混合你可能看到的是 TCPv6 的监听而扫描器只探测了 IPv4。第二Linux 上用ss -tlnp看到的 LISTEN 状态才表示端口处于可用状态netstat里还可能有一批TIME_WAIT状态的连接记录这些不代表端口开放如果你把TIME_WAIT端口也当成开放端口就会多出一堆假数据。第三Windows 防火墙可能允许外部连接访问某个端口但该端口并没有被服务监听netstat同样不会显示而扫描器从外部连接却成功了这是因为防火墙的放行策略和服务的监听状态是两回事。解决的办法是统一对比口径在目标机上执行netstat -tlnpLinux或netstat -an | findstr LISTENINGWindows只看 LISTEN 状态的端口并且用同一个 IP 地址族和扫描器比对。如果在 Linux 上有 1000 个端口需要快速核对用ss -tlnp | awk {print $4}提取端口列表再和扫描结果做差集这样就不会被连接状态干扰了。5.3 现象程序跑到一半卡死像黑匣子一样没有输出并发版本最容易出的问题就是运行后终端一片空白等十几分钟也不结束让人完全不知道它到底是还在跑还是已经死了。这其实就是一个黑匣子问题根本原因有三个一是把 65535 个端口一次性全部丢进线程池每个 future 都要排队后面排队的任务还没执行前面的结果也在堆积二是 timeout 设了 5 秒而目标机根本没有这个端口每个连接都要等满超时三是代码里把异常吞掉了没打任何日志程序实际上还在跑但你完全感知不到。解决的办法有三条端口量大的时候分批提交比如每 1000 个端口一个批次批次之间做一次 sleep(0.2)timeout 遵循“能短则短”的原则避免一个异常目标拖垮全部任务在每扫描完一个批次后打印日志输出当前已用时间、已扫描端口数、已发现开放端口数这样任何时候都能判断程序是正常推进还是真的卡死了。把这三条写进去课程演示的时候就不会出现全班同学盯着一个没有输出的终端等一分钟的尴尬场面。5.4 现象现场演示时被问到“这样扫描目标会发现吗”课程设计答辩经常被追问一个战术问题你的扫描会不会被目标发现。这不算 bug但答不好会让前面所有工作扣印象分。原因在于很多学生只写了代码没想清楚端口扫描行为的本质。TCP connect 扫描会在目标机器上留下完整的连接记录Web 服务器更会把每个连接写进访问日志所以目标端完全可以发现扫描行为。SYN 半开扫描留下的痕迹少很多但也不是零痕迹而且需要 root 权限。课程设计题目是“网络安全终端监控”核心价值是保护自己的终端不是去探测别人的机器。解决方案是两层第一层在代码里明确加一个授权校验比如用常量AUTHORIZED_HOSTS限定可扫描的 IP 列表遇到列表外的目标直接拒绝执行并打印提示第二层答辩时把话说明白本代码用于受控实验环境的终端监控不会拿去做未授权扫描。这两个回答已经能把问题接住了还能顺势引出你对合规边界的理解。6. 把端口扫描变成终端监控的核心模块验证、落库与增量对比6.1 用 SQLite 落库并做两次扫描的增量对比端口扫描代码在课程设计里最自然的上游应用是把结果存库然后通过增量对比产生告警。我用 SQLite 做存储不需要额外安装服务代码也只依赖标准库 sqlite3。import sqlite3 import json def save_scan(conn: sqlite3.Connection, record: dict): 把一条扫描记录写入 SQLite 数据库。 conn.execute( CREATE TABLE IF NOT EXISTS scan_log ( id INTEGER PRIMARY KEY AUTOINCREMENT, host TEXT, ts TEXT, open_ports TEXT ) ) conn.execute( INSERT INTO scan_log (host, ts, open_ports) VALUES (?, ?, ?), (record[host], record[timestamp], json.dumps(record[open_ports])), ) conn.commit() def compare_last_two(conn: sqlite3.Connection, host: str): 取同一主机最近两次扫描结果返回端口变化。 rows conn.execute( SELECT open_ports FROM scan_log WHERE host? ORDER BY id DESC LIMIT 2, (host,), ).fetchall() if len(rows) 2: return 首次扫描没有可比对记录 old set(json.loads(rows[1][0])) new set(json.loads(rows[0][0])) return { 新增端口: sorted(new - old), 消失端口: sorted(old - new), }这段代码把 JSON 直接存成文本字段对于课程设计规模的数据量完全够用。compare_last_two返回的“新增端口”和“消失端口”就是终端监控模块的原始告警素材你可以在此基础上加一个简单策略发现高危端口比如 23、3389、4444新出现时立刻输出告警发现监控名目的业务端口消失时也立刻输出告警。做到这一步端口扫描代码就已经不是一个孤立工具而是真正嵌进了监控系统。6.2 在提交课程设计前做的三个自查验证课程设计提交前我会建议每个人都做一遍“背靠背验证”用自己代码跑一遍再拿系统命令或第三方工具跑一遍两边结果对上才敢说代码正确。第一个验证是回环地址自测在没有任何服务的 Windows 或 Linux 机器上扫描127.0.0.1结果应该为空然后随便启动一个本地服务比如 Python 自带的python -m http.server 8000再扫描一次端口 8000 必须在开放列表里。第二个验证是找一台虚拟机或同机房机器用你的代码和nmap -sT各扫描一次目标主机的同一个端口段对比开放列表不需要完全相同但你的开放端口集合必须是对方开放端口集合的子集多出来的就可能有问题。第三个验证是连续扫描同一目标五次结果应该完全一致如果五次结果忽多忽少就要回头看 timeout 设置是否过短、线程并发是否过高、目标防火墙是否在做动态丢包。我印象最深的一次翻车是我自己做这个题目时把端口范围拉满到 65535timeout 设成 3 秒线程数 512结果整个机房扫描持续了十几分钟期间其他同学上课用的网络明显卡顿。后来我养成了一个习惯也是对这门课最简单的建议代码里永远保留一个AUTHORIZED_RANGES常量只在明确授权的 IP 范围内执行扫描单机演示默认从回环地址和本机局域网 IP 开始不要一上来就扫整个网段。这个习惯让我后来做监控类项目时少踩了很多坑。希望这篇整理出的思路能帮到你祝你的课程设计一次过。本文还有配套的精品资源点击获取