20242423 2026-2027-1《网络与系统攻防技术》实验2实验报告

20242423 2025-2026-1《网络与系统攻防技术》实验二实验报告

姓名：luojinglin 学号：20242423 班级：2424班

1.基础知识

1.1 Netcat、Socat 与任务计划的基本原理

理解这几个工具时，可以把它们拆成三层：TCP 负责传输字节，Netcat 或 Socat 负责把字节接到标准输入输出，Shell 负责把收到的文本解释成命令。监听端只是在等待连接，连接端负责主动建立 TCP 会话；当两端都使用 127.0.0.1 时，数据不会经过外部网络，适合先观察机制。

Netcat 的使用方式比较直接，适合验证“端口是否能连通”；Socat 把地址写成 TCP、FILE、STDIO、EXEC 等组合，适合把文件、终端和进程串接起来。二者都不会自动产生权限，最终能执行什么命令，取决于被连接的程序和启动它的用户身份。

Netcat 可以把 TCP/UDP 连接抽象成输入和输出流；在实验中，一端监听 127.0.0.1:42423，另一端连接后把输入交给 /bin/sh，从而观察到受控的命令交互。Socat 的功能更通用，可以把 TCP、文件、标准输入输出和进程连接起来；本实验使用 TCP 与 /bin/sh 的组合，并将任务计划限定在用户会话和回环地址内。

cron 以固定时间字段触发命令；本实验使用每分钟一次的用户级任务写入实验日志。MITRE ATT&CK 将恶意使用 cron 的行为归入 T1053.003。[4] systemd-run --user 可以创建当前用户的临时 service 和 timer，适合观察任务启动、触发和状态查询。[2] 任务计划本身不是后门，是否安全取决于命令来源、权限、持久性、监听范围和可审计性。

1.2 后门与检测基础

从防守角度看，一个可疑控制入口通常可以沿着“怎么进入、由谁启动、连接到哪里、以什么身份运行”四个问题追查。入口和启动机制解释了持久性，网络连接解释了控制关系，用户和权限解释了影响范围。只看到一个工具名称或一个端口，不能直接下结论，必须把进程、文件、任务和日志放在一起核对。

本实验把任务计划当作一个需要审计的普通系统功能来观察。cron 和 systemd timer 本身可以用于备份、日志和维护，风险来自任务内容、运行权限、触发频率、网络范围以及是否能够被用户发现和删除。实验结束时清理任务，正好可以验证持久化入口是否真正消失。

后门是绕过正常认证或访问流程、提供额外控制入口的机制。正向连接与反向连接的差别在于谁主动发起连接，两者都需要结合网络方向和进程身份分析。Shell 通常提供命令解释能力，Meterpreter 则提供可扩展的交互式功能，两者不能仅凭“出现提示符”混为一谈。[3]

安全软件可能结合静态特征、行为规则、进程关系和网络活动判断风险。编码或文件外观变化不等于获得安全性，也不能证明绕过检测；单次未告警不能作为“免杀成功”的结论。本次没有进行免杀测试。文件 SHA-256 只用于确认两份文件字节一致，不能独立证明文件安全。

1.3 实验问题回答

（1）后门进入系统的可能方式

例如用户从不可信来源下载并运行伪装成工具或破解程序的可执行文件，程序在用户目录中落地并尝试创建启动项。防护重点是软件来源、哈希校验、最小权限和执行前审计。

（2）后门在 Windows 和 Linux 中的启动方式

Windows 常见位置包括登录启动项、计划任务、服务和 WMI 事件订阅；Linux 常见位置包括 cron、systemd service/timer、shell 启动文件、用户级服务、SSH authorized_keys 和守护进程配置。排查时应结合启动项、进程树、网络监听和文件时间线。

（3）Meterpreter 印象较深的功能

从防守视角看，Meterpreter 的模块化会话、进程/文件/网络枚举、扩展加载和后续控制能力最值得关注。它说明攻击工具往往把发现、持久化和数据访问组合成一个交互式会话，因此审计应关注异常进程、异常连接、临时文件和权限变化。本文不生成或运行真实 Meterpreter 载荷。

（4）如何发现系统是否安装后门

先核对主机名、用户、组和最近变更；再检查 cron、systemd timers/services、启动文件、SSH keys、监听端口、进程树和网络连接；随后对可疑文件做类型、权限、时间戳和哈希核验，结合系统日志确认来源。最后使用离线可信介质或安全软件复核，必要时重装系统和轮换凭据。本文的 audit_20242423.sh 对其中一部分进行了自动化检查。

2.实验内容

本实验围绕 Linux 主机上的回环连接、任务计划、文件传输和安全审计展开。通过 Netcat 与 Socat 在本机 127.0.0.1 地址上建立受控的实验连接，理解监听端、连接端与命令解释器之间的关系；通过 cron 和 systemd 用户定时任务观察任务计划的启动机制；通过编译一个无破坏性的测试程序并校验哈希，掌握文件传输后的完整性验证方法。

整个实验可以看成一条由浅入深的观察链：先用回环连接确认 Shell 的数据流，再用 cron 和 systemd timer 观察“谁在什么时候启动程序”，然后用一个无破坏性测试程序完成文件传输和哈希核对，最后从网络、任务、设备和 ELF 属性几个角度做审计。每一步都留下了可以复核的终端输出，而不是只记录一个最终结论。

报告中的“完成”指本人实际完成并有截图或终端记录支持的内容；对于原实验要求中涉及真实后门、隐蔽控制、设备采集、提权和 Shellcode 注入的部分，只记录原理、风险和安全替代验证，不把未执行的内容写成成功结果。

实验中还检查了音频、摄像头与输入设备信息、网络监听、用户定时任务和 sudo 权限，并查看 pwn1 的 GNU_STACK 属性及探针字节。各项实际完成情况在下文说明。

本次实验的主机名为 luojinglin，编写的文件名中包含学号 20242423。实验结束后检查任务计划与监听端口。

2.1 实验环境与完成情况

实验在 VMware 中的 Kali Linux 虚拟机上进行，主机名为 luojinglin，当前用户为 kali，UID 为 1000。Netcat、Socat 交互和文件传输分别使用 127.0.0.1 的 42423、42424、42425 端口。

发送目录为 /home/kali/sender_20242423，接收目录为 /home/kali/receiver_20242423，使用 gcc 编译 x86-64 ELF 测试程序。

已完成 Netcat 回环 Shell 与 cron 日志任务，以及 Socat 回环 Shell 与用户级 systemd 定时任务。文件部分完成了普通测试程序的编译、传输、哈希校验和运行。

原要求第3项的 MSF 后门没有生成；第4项只做了设备与权限审计，没有采集音视频、记录击键或提权；第5项只检查了 pwn1 的栈权限并查看探针字节，没有执行注入或建立反弹连接。

3.实验过程

3.1 Netcat 回环 Shell 与 cron 任务

首先确认 nc、socat 和 crontab 可用，并确认 cron 服务处于 active 状态。nc -h 显示所用版本为传统 Netcat v1.10-50.1。监听端使用 127.0.0.1:42423，连接端执行 /bin/sh。连接建立后在监听端依次执行 hostname、whoami、id 和 pwd，得到主机名 luojinglin、用户 kali、UID 1000 以及工作目录 /home/kali。

这里要区分两个容易混淆的角色：监听端占用本地端口并等待连接，连接端向这个端口发起 TCP 请求。连接成功后，hostname、whoami、id 和 pwd 分别验证主机名、当前用户、数字身份与工作目录，四条信息结合起来比单独看到一个提示符更可靠。

图1 Netcat 在本机回环地址建立受控 Shell，并核对身份信息

随后编写 /home/kali/cron_task_20242423.sh，使其把当前时间、主机名和用户写入 /home/kali/cron_20242423.log。通过 crontab -e 添加每分钟执行一次的条目：

* * * * * /bin/sh /home/kali/cron_task_20242423.sh

这行任务的五个星号依次对应分钟、小时、日期、月份和星期，全部使用星号表示每个字段都匹配，因此会在每分钟执行一次。cron 的运行环境比交互式终端简单，脚本中使用绝对路径可以减少 PATH 不同造成的失败。日志连续出现多个分钟点，说明“任务已写入”与“任务确实被触发”两个环节都得到了验证。

图2 用户 crontab 中的学号任务条目

图3 cron 日志按分钟生成，记录主机名和用户

从日志结果可以看到任务在多个分钟点连续执行，说明 cron 守护进程能够按计划启动脚本。实验结束后，用 crontab -l 确认条目已注释；另外检查用户 timer 和监听端口，结果见图9。

3.2 Socat 回环 Shell 与 systemd 用户定时任务

Socat 实验使用 127.0.0.1:42424。监听端通过 STDIO 接收交互输入，连接端通过 EXEC 启动 /bin/sh。随后在监听端执行 hostname、whoami、id 和 date。截图中的 service 状态显示 socat_20242423.service 为 active (running)，并由 socat_20242423.timer 触发。

这一步的观察重点不是把命令写得多复杂，而是看清 service、timer、socat 进程和 /bin/sh 之间的关系：timer 负责到点触发，service 负责承载一次运行，socat 负责连接 TCP 与标准输入输出，Shell 负责解释收到的命令。状态查询把这条关系显示在同一份记录中。

图4 Socat 回环 Shell 与 systemd 用户 service 状态

为观察任务计划启动过程，使用 systemd-run --user 创建 on-active=1min 的临时任务，并用 list-timers 查看下一次触发时间：

systemd-run --user --unit=socat_20242423 --on-active=1min /usr/bin/socat TCP:127.0.0.1:42424 EXEC:/bin/sh,stderr

systemd-run --user 表示使用当前用户的会话管理器，不需要把任务安装成系统级服务；--unit 给临时单元命名，--on-active=1min 表示启动后等待一分钟触发。list-timers 只能说明 timer 已经被调度，service 状态和实际终端输出才说明程序是否真正运行，所以验证时要同时看计划状态和进程结果。

图5 systemd-run --user 创建临时 timer，并列出待触发任务

timer 触发后，service 中出现 Socat 进程和 /bin/sh。完成测试后停止 service，并检查用户 timer 列表和监听端口。

3.3 安全测试程序编译与 Socat 文件传输

为了模拟“可执行文件被传送到另一目录后运行”的完整性验证流程，编写了带有学号标识的无破坏性程序 test_payload_20242423.c。程序只输出标签、主机名和 UID，不创建网络连接、不修改系统配置。编译后使用 file 和 sha256sum 检查文件类型及摘要。

文件传输实验分为四个可以独立核对的环节：发送端选择正确文件，接收端把字节写入目标路径，file 判断文件类型，SHA-256 判断传输前后内容是否一致，最后再运行接收端文件观察输出。这样的顺序能把“传到了”“没有损坏”和“程序行为符合预期”分别验证，避免只凭文件名或文件大小作判断。

图6 测试程序编译、ELF 类型检查、SHA-256 校验及本地运行结果

源文件位于 /home/kali/sender_20242423，接收目录为 /home/kali/receiver_20242423。使用 Socat 的 FILE 与 TCP 地址进行一次性传输，接收端保存后补充执行权限，再次计算摘要。源文件和接收文件的 SHA-256 均为：

541e9e805939f2266648d3a47d8d903c6524674c4675508849c10c616b386b62

图7 Socat 传输文件后，发送端与接收端哈希一致并成功运行

传输前后摘要一致，接收目录中的程序也能正常输出标签、主机名和 UID，说明文件内容与发送端相同。这个测试程序只打印信息。

同时也要看到哈希核对的边界：它能证明发送端和接收端是同一份字节，但不能证明文件本身安全。判断一个可执行文件能否信任，还需要知道来源、检查权限和时间戳、观察运行行为，并在必要时使用可信的安全工具进行复核。

3.4 本地安全审计与后门排查

执行 audit_20242423.sh，生成 /home/kali/audit_20242423_20261018_050201.log。以下内容依据本人复制的终端输出整理，此步骤尚无独立截图。日志显示主机名为 luojinglin，当前用户为 kali；存在 /dev/snd/* 音频设备节点；输入设备列表只记录键盘、鼠标等名称；监听套接字为空；用户 timer 数量为 0；非交互 sudo 检查要求输入密码。

审计结果最好按“身份、设备、输入、网络、任务、权限”六类阅读。身份信息确定检查对象，设备和输入信息说明可访问的硬件节点，网络信息查看是否存在监听，任务信息检查计划启动，权限信息说明当前用户是否能无密码改变系统。这样读日志比只找一个“有”或“没有”的结论更稳妥。

日志先列出了音频节点，随后又打印 no camera/audio device nodes，说明脚本的兜底提示不够精确。结合输出，只能确认音频节点存在且未看到 /dev/video*，不能据此认定音频设备不存在，也不能判断实际采集是否可用。

sudo 检查提示 unable to resolve host luojinglin，同时要求输入密码。主机名解析配置仍待核对，本次没有修改配置或进行提权。

本次审计只覆盖当前用户可见信息。没有监听端口或用户 timer，不代表系统一定没有后门；仍需结合系统级服务、进程、文件和日志。sudo 要求密码也只说明该检查没有取得非交互授权，不能据此判断所有提权路径。

3.5 Pwn1 栈权限检查与非执行 Shellcode 探针

对实验一准备的 /home/kali/Desktop/pwn1_20242423 使用 readelf -W -l 检查 GNU_STACK 属性，截图中显示 RWE，表示该 ELF 标记请求可读、可写、可执行的栈。该静态属性提示潜在风险，实际运行时权限还应结合进程映射确认；它本身不能证明漏洞已经利用成功。

RWE 是 ELF 程序头中的静态标记，能帮助判断程序的安全加固情况，但它不是一次漏洞利用的结果。是否存在可利用的溢出、输入是否能影响控制流、运行时地址如何变化，都需要单独验证。把“属性检查”和“代码执行”分开，是这一步安全边界的关键。

为避免执行真实 Shellcode，只编译一个 probe 程序，把三个字节 90 90 c3 作为普通数据打印为十六进制，并明确输出“probe bytes were inspected only; nothing was executed.” 这一步仅验证字节读取和记录流程，不建立反弹连接，也不向 pwn1 注入。

这里的 probe 只证明程序能够读取并记录一段字节，不能证明这些字节被当作指令执行，更不能证明 pwn1 已经被控制。以后阅读类似实验结果时，应仔细区分“生成字节”“传递字节”“把字节放入内存”和“跳转执行”这几个不同阶段。

图8 pwn1 的 GNU_STACK 属性与非执行 Shellcode 探针输出

3.6 实验清理与检查

完成实验后，将 cron 条目注释，停止 Socat 临时 service，并查询用户 timer 和监听端口。截图中 crontab 条目前已有注释符号，用户 timer 数量为 0，ss -lntup 没有列出监听端口。此检查仅反映当时的状态。

清理检查是实验的一部分，不是可有可无的收尾。cron 条目、systemd 临时单元和监听端口分别代表计划入口、运行实例和网络入口；三类状态都恢复后，才能说明本次临时实验没有继续留在系统中。

图9 实验结束后的清理检查：无用户 timer、无监听端口

4.问题及解决方案

• 问题1：粘贴命令时出现 ^[[200~，zsh 报 bad pattern。
• 问题1解决方案：删除混入的控制字符后重新手动输入命令；后续截图中命令成功执行。
• 问题2：Netcat 首次连接提示 Connection refused。
• 问题2解决方案：先在监听端启动监听，再在另一终端发起连接。连接成功后，在监听端执行 hostname、whoami、id 和 pwd 核验身份。
• 问题3：systemd-run 报 Failed to parse OnActiveSec。
• 问题3解决方案：截图中把后续交互命令混入了未完整输入的命令，导致时间参数解析失败。将任务创建与 Shell 交互分开输入，随后通过 list-timers 与 service 状态确认触发结果。
• 问题4：停止临时 timer 时提示 Unit not found，service 曾显示 failed。
• 问题4解决方案：临时单元可能已经退出或被回收。停止 service 后执行 reset-failed，并用 is-active、list-timers 和 ss 进行清理核验。
• 问题5：sudo 审计提示 unable to resolve host luojinglin。
• 问题5解决方案：记录为尚未修复的主机名解析配置问题。可进一步核对 /etc/hostname 与 /etc/hosts；本次没有执行配置修改，不能写成已经解决。
• 问题6：审计日志列出音频节点后又提示 no camera/audio device nodes。
• 问题6解决方案：把节点列表与兜底提示分别解释：已看到 /dev/snd/*，未看到 /dev/video*。脚本提示仍待细化，本报告不据此认定音频设备缺失。

5.学习感悟、思考等

本次完成了 Netcat 和 Socat 的本机回环 Shell、两类任务计划、普通测试程序传输、设备与网络审计，以及 Pwn1 栈权限检查。刚开始我在连接端输入验证命令，没有得到预期回显；后来在监听端输入 hostname、whoami 和 id，才确认了两个终端各自的作用。首次连接失败和多次粘贴报错也说明，排错时需要先核对监听状态与命令实际内容。

以前我容易把“能连上”当成实验成功，但这次的记录让我意识到，网络连接只是第一层现象。还要继续确认连接由哪个进程创建、进程以哪个用户运行、任务是否会再次启动，以及实验结束后入口是否已经清理。以后遇到异常连接，我会先按照这条线索逐项核对，而不是直接猜测原因。

这份实验也让我理解了安全实验中“边界”和“证据”的意义。对于设备节点、GNU_STACK 和 Shellcode 字节，只做读取、属性检查和非执行探针，就可以学习检测思路；至于真实采集、提权和注入，需要更严格的授权、隔离和复现条件。把做过的、观察到的和推测的内容分开写，报告才有可信度。

文件传输之后，两份文件的 SHA-256 完全一致，接收目录中的程序也输出了相同标签和身份信息。这比只看到“传送命令执行完毕”更能支持完整性判断。定时任务部分，我先观察到 timer 触发 service，最后又检查了任务和端口，才把实验过程闭合。

对于后门检测，单独查看进程或单独查看端口都不够。应把 cron/systemd、启动文件、网络监听、文件哈希、设备访问和日志关联起来，再结合最小权限和离线复核。对于 Shellcode 与 Meterpreter 一类内容，先进行静态属性检查和非执行探针，能够在不触发真实控制能力的情况下理解风险点。

参考资料

[2] systemd 项目《systemd-run 官方手册》（查阅日期：2026年10月18日）。

[3] Rapid7《Meterpreter Overview》（查阅日期：2026年10月18日）。

[4] MITRE ATT&CK《Scheduled Task/Job: Cron T1053.003》（查阅日期：2026年10月18日）。