第二篇：攻击面收敛：高危端口管控与服务监听审计
关键词
端口审计、ss 命令、攻击面管理、UDP 协议、数据库安全、Docker 端口映射
摘要
承接上篇，当 SSH 安全得到保障后，我们需要深入服务器内部，审视那些因部署各类业务（如 CMS、代理面板、Docker 容器）而意外开启的端口。本文将深入讲解如何使用 Linux 原生工具进行端口“体检”，区分 TCP 与 UDP 协议的风险差异，并重点阐述 3306（MySQL）和 25（SMTP）等高危端口的管控策略，最终实现攻击面的最小化。
1. 端口审计：透视服务器的内部经络
1.1 什么是“攻击面”？
在网络安全中，每一个开放的端口（Open Port）都是一个潜在的攻击面。无论是博客系统、管理面板，还是数据库，只要它们监听在 0.0.0.0（全网），就理论上存在被利用漏洞进行入侵的风险。
1.2 神器登场：ss 命令详解
相较于古老的 netstat，ss（Socket Statistics）能更快速地显示系统套接字信息。
核心指令：
Bash
sudo ss -tulpn
-t: TCP 协议-u: UDP 协议-l: 监听状态 (Listening)-p: 显示进程信息 (Process)-n: 不解析域名 (Numeric)
1.3 读懂审计报告
执行命令后，我们可能会看到如下列表（IP与端口已脱敏）：
2. 协议区分：TCP 与 UDP 的防火墙策略差异
2.1 TCP：连接的基石
绝大多数服务（HTTP, SSH, 面板, VMess）都依赖 TCP。
策略：在防火墙中，对于 Web 服务（80/443）和面板管理端口（如 10086），必须放行 TCP。
2.2 UDP：速度的狂欢与风险
随着 QUIC 协议和 Hysteria2 等技术的发展，UDP 端口的重要性日益凸显。
Hysteria2 场景：该协议底层完全基于 UDP。如果在防火墙只开了 TCP，客户端将无法连接。
端口跳跃 (Port Hopping)：某些服务会使用一段端口范围（如 40000-50000）。
策略：对于此类服务，仅需放行 UDP。不要错误地放行同端口的 TCP，以减少不必要的暴露。
2.3 混合端口的陷阱
某些代理节点（如 VLESS+Reality）仅使用 TCP，而 Warp 客户端（WireGuard 协议）使用 UDP。
痛点：新手常为了省事，将 TCP/UDP 全部放行。
修正：严格区分。例如，SSH 端口（20022）在防火墙策略中应明确设为 TCP: 允许，UDP: 拒绝/忽略。
3. 高危端口管控：关上不该开的窗
3.1 数据库端口 (3306, 6379)
痛点：许多面板一键部署时，默认将 MySQL 绑定在 0.0.0.0。一旦防火墙误开，黑客利用弱口令瞬间脱库。
解决方案：
防火墙拦截：在腾讯云防火墙中，显式添加一条规则：
TCP 3306, 6379 -> 拒绝。配置绑定：修改 MySQL 配置文件，设置
bind-address = 127.0.0.1，使其仅对本机可见。
3.2 邮件端口 (25)
痛点：Linux 发行版常预装 exim4 或 postfix，默认监听 25 端口。这不仅消耗内存，还可能被利用发送垃圾邮件。
解决方案：
卸载服务：如果 VPS 不作为邮件服务器，直接卸载。
Bash
sudo apt purge exim4 postfix -y sudo apt autoremove -y防火墙拦截：
TCP 25 -> 拒绝。
3.3 面板入口 (8080-8099)
各类面板（如 H-UI, X-UI, 宝塔）通常占用特定端口。
优化：
不要使用默认端口（如 54321, 8888）。
修改为无规律端口。
在防火墙中仅放行修改后的 TCP 端口。
4. 第二阶段总结
通过 ss 命令的深度审计和防火墙的精细化配置（拒绝 3306/25，区分 TCP/UDP），我们将服务器内部的“经络”梳理清晰。
对比前：各类服务杂乱监听，TCP/UDP 混用，数据库裸奔，存在极大被入侵和数据泄露风险。
对比后：仅必要的业务端口对外开放，内部服务（如数据库、Warp 本地代理）被牢牢锁死在 localhost，攻击者无路可走。
请阅读本系列之三：主动防御体系：Fail2Ban 部署与入侵防御技术演进
本文首发于E路领航 (blog.oool.cc)，转载请注明出处