bsamita/SOC-Analyst-Writeups
GitHub: bsamita/SOC-Analyst-Writeups
一个蓝队 SOC 分析师的实战调查报告集合，记录了基于真实工作流的安全事件分析与威胁检测过程。
Stars: 0 | Forks: 0
# 🔍 使用 Wireshark 进行端口扫描分析
这是一份关于分析 TCP 端口扫描捕获文件（`portscan_challenge.pcap`）的实操记录，旨在找出攻击者、目标以及哪些端口保持开放。整个过程完全在 Wireshark 中通过读取 TCP flags 完成——无需 Nmap 输出，仅凭原始握手数据包即可得出结论。
## 📁 此仓库中的文件
- `portscan_challenge.pcap` — 所分析的捕获文件
- `screenshots/` — 下方引用的 Wireshark 视图
## 🎯 目标
给定一个数据包捕获文件，回答以下问题：
1. 谁在进行扫描？
2. 谁正在被扫描？
3. 有多少个端口成为目标？
4. 哪些端口最终是开放的？
## 第一步：使用 Conversations 视图了解全貌
进行任何 pcap 分析的第一步都是——**Statistics → Conversations → TCP 标签页**。这能让你鸟瞰捕获文件中的每一次会话，而无需逐个滚动数据包。
仅这一个视图就立刻回答了我的四个问题中的三个：
- **扫描 IP (Address A)：** `192.168.1.66` — 同一个源 IP 反复出现，每次都与不同的目标端口配对
- **目标 IP (Address B)：** `192.168.1.50` — 每次的目标 IP 都相同
- **目标端口：** 14 个独立端口 — `21, 22, 23, 25, 53, 80, 110, 139, 143, 443, 445, 3306, 3389, 8080`
这种模式就是最明显的线索：同一个 IP，使用顺序的源端口（40000, 40001, 40002...），在几毫秒内访问同一目标上的一长串知名服务端口。这不是正常的用户流量——这是一个端口扫描器（Nmap 或类似工具）正在执行它的任务。
## 第二步：找出哪些端口是真正开放的
知道*哪些*端口被探测与知道哪些端口是*开放*的是两码事。为此，你需要查看目标是如何响应的——这取决于 TCP flags。
### 快速复习：TCP 握手通常如何工作
| 步骤 | 发送方 | 设置的 Flags |
|---|---|---|
| 1 | 客户端 → 服务器 | 仅 `SYN` |
| 2 | 服务器 → 客户端 | `SYN` + `ACK` |
| 3 | 客户端 → 服务器 | 仅 `ACK` |
只有当该端口上确实有程序在监听时，握手才会进行到第 2 步。因此：
| 目标的响应 | 代表的含义 |
|---|---|
| **SYN + ACK** | 端口**开放** — 有服务进行了响应 |
| **RST + ACK** | 端口**关闭** — 主机在线，但没有程序监听 |
| **无响应** | 端口可能被**过滤**（防火墙静默丢弃了请求） |
### 应用过滤器
在 Wireshark 的过滤栏中输入：
```
tcp.flags.syn==1 and tcp.flags.ack==1
```
这表示：“只显示 SYN flag 和 ACK flag 都设置为 1 的数据包。”这种组合只会出现在上述握手的第 2 步中——即端口确认其处于开放状态。
匹配到了四行。但其中只有**三行**实际上属于本次扫描：
| 数据帧 | 源地址 | 端口 | 属于扫描吗？ |
|---|---|---|---|
| 4 | 93.184.216.34 | 443 | ❌ 否 — 这是无关的背景 HTTPS 会话 |
| 11 | 192.168.1.50 | 22 | ✅ 是 |
| 18 | 192.168.1.50 | 80 | ✅ 是 |
| 24 | 192.168.1.50 | 443 | ✅ 是 |
所以真实的结果是：目标上的 **端口 22 (SSH)、80 (HTTP) 和 443 (HTTPS) 处于开放状态**。
### 手动复核
过滤器虽然好用，但也有必要知道如何手动确认——以防过滤器拼写错误给你带来虚假的自信。点击任意单个数据包，并在详细信息窗格中展开 **Transmission Control Protocol** 部分：
在这里，第 11 帧显示 `Source Port: 22`，并且在下方 flags 字段中 SYN 和 ACK 位都被设置了——手动证实了过滤器告诉我们的结果。这是一个好习惯：让过滤器缩小范围，然后手动验证至少一两个结果，这样你就不会盲目相信工具了。
## ✅ 最终答案
| 问题 | 答案 |
|---|---|
| 扫描 IP | `192.168.1.66` |
| 目标 IP | `192.168.1.50` |
| 目标端口 | 14 (`21, 22, 23, 25, 53, 80, 110, 139, 143, 443, 445, 3306, 3389, 8080`) |
| 开放端口 | `22` (SSH), `80` (HTTP), `443` (HTTPS) |
## 🧠 关键要点
- 在几毫秒内，从一个 IP 向另一个 IP 的多个端口发送的大量 SYN 数据包是典型的端口扫描特征——即使没有看到扫描工具自身的输出也能识别。
- `tcp.flags.syn==1 and tcp.flags.ack==0` 用于筛选**扫描尝试**（发出的探测）。
- `tcp.flags.syn==1 and tcp.flags.ack==1` 用于筛选**开放端口确认**（响应）。
- 务必根据实际的源/目标 IP 对过滤结果进行合理性检查——从技术上讲，过滤器匹配到的数据包可能与您正在调查的安全事件毫无关系，就像本次捕获中无关的 HTTPS 会话一样。
- 在详细信息窗格中手动检查至少一个数据包的 flags 是一种好习惯，可以验证过滤器所显示内容的准确性。
*实验捕获文件在 Wireshark 中分析。这是我正在进行 SOC Analyst 培训和实际数据包分析练习的一部分。*
标签：SOC分析, Wireshark, 句柄查看, 并发处理, 插件系统, 端口扫描分析