企业官网建设流程全解析

US.KG 域名网站服务器如何审计监听端口并限制入站流量：端口清点与防火墙规则

【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KG

域名注册与数字面板（DigitalPlat）只负责注册控制层，它不会替服务器开通防火墙端口——服务器自身的监听端口与防火墙策略，才决定哪些入站流量真正可达。US.KG 教程给出了一条完整操作路径：先用sudo ss -lntup清点当前所有监听器，按"默认拒绝"原则收紧入站流量，只保留 TCP 80/443 与按设计限制的管理端口，最后用重跑端口检查、nc与curl验证收紧没有切断正常访问。本文适用对象：一台已授权管理的 Debian 或 Ubuntu 服务器，已安装 Nginx 作为 Web 服务器，操作账号为非 root 且带sudo。

开始前的准备条件

• 服务器为通用 Debian 或 Ubuntu 系统，已安装 Nginx（Prepare a Linux Web Server 一节的示例环境）；
• 拥有非 root 的管理账号，可通过sudo执行管理命令；
• 在修改防火墙之前，先弄清管理访问（SSH）走哪条恢复路径，并确认该路径不会被规则切断。文档明确提醒：修改认证或访问限制时，不要在未验证可用恢复路径的情况下禁用旧方式；
• 确认改动前已有备份。Server Hardening and Maintenance 的 Hardening Lab 要求在动手前"确认备份存在"。

第一步：捕获监听器清单

sudo ss -lntup

这条命令列出全部 TCP 监听器及其所属进程（sudo用于读取进程归属信息），它的输出就是本次变更的基线，改动后要能直接对比。macOS 上的等价命令是lsof -nP -iTCP -sTCP:LISTEN（本机检查用）。

对清单中的每一个监听器，记录以下字段：

• 进程属主（Process owner）
• 绑定地址（Bind address）
• 端口与协议
• 业务用途（Business purpose）
• 是否需要公开（Whether it must be public）
• 更新责任（Update responsibility）

同时做三项检查（均来自 Hardening Lab 的步骤）：

1. 确认每个监听端口的属主进程和所属包；
2. 检查应用是否以 root 运行；
3. 复核网站目录权限。Prepare a Linux Web Server 用下面的命令找出网站目录中异常宽泛（组/其他可写）的文件，文档同时提醒：先审查结果再改权限，部分协作流程会刻意保留组写权限。

find /var/www/example.dpdns.org -xdev -type f -perm -0002 -print

（example.dpdns.org是文档中的示例域名，换成你的实际网站目录。）

数据库、缓存和内部应用端口应绑定在私有或本地接口上，除非远程访问是明确设计且受保护的。确认过依赖后，属主或用途不明、没有更新责任人的服务应禁用或移除——不要留"不知道谁在听"的端口。

第二步：按默认拒绝原则收紧入站流量

Server Hardening and Maintenance 给出的 Firewall Design 原则是：默认拒绝所有未经请求的入站流量，然后只放行必需的服务。对一个简单 Web 服务器，公网入站最多只需要：

TCP 80 HTTP and certificate validation workflow TCP 443 HTTPS

管理访问（如 SSH）的开放范围应"根据实际的恢复路径和网络设计"来限制，而不是照抄一个固定端口清单。IPv4 与 IPv6 的防火墙策略要分别确认，不能只测一边。

执行规则时：

• 使用服务器上已经选定的防火墙系统。Prepare a Linux Web Server 的 Firewall Check 一节明确写道："Use the firewall system already chosen for the server"——文档不指定 ufw、nftables 等具体工具的命令，以系统现用工具为准；
• 原则是"permit only required inbound services"：至少，网站流量需要 TCP 80 和 443；管理访问要限制得尽量紧；
• 不要把无关的管理端口暴露到公网（同节要求）；
• 每次收紧后立即验证（见下节），确认没有切断恢复路径和正常访问。

第三步：验证端口清单与入站规则

收紧后重跑端口清点，并与基线对比，确认剩余监听器都符合记录表：

sudo ss -lntup

Secure, Monitor, and Back Up 的 Step 6（Apply Server Baseline）要求"确认只有必需的公开端口开放"后，重跑sudo ss -lntup与sudo nginx -t。完整验证清单：

sudo nginx -t systemctl status nginx --no-pager journalctl -u nginx --since '30 minutes ago' --no-pager

再从外部机器测试端口可达性：

nc -vz example.dpdns.org 80 nc -vz example.dpdns.org 443

文档提醒：nc只证明 TCP 连接建立，不能证明 HTTP、TLS 或应用层正常，所以还要做应用层验证：

curl -I http://example.dpdns.org

如果要在 DNS 生效前就验证，可以用 Host 头直连服务器地址（192.0.2.10为文档示例地址）：

curl -I -H 'Host: example.dpdns.org' http://192.0.2.10

如果 DNS 解析正常但连接超时，按 Troubleshooting Decision Trees 中 "DNS Resolves but Website Times Out" 决策树逐层判断，记录观察结果后再动配置：

1. 服务器在网络层是否可达？不可达先查路由与服务器可用性；
2. 端口 80/443 是否在监听？没有则启动或配置 Web 服务器；
3. 网络与主机防火墙是否放行该连接？没有则应用审核过的防火墙规则（Apply the reviewed firewall rule）；
4. 前三步都正常，再检查虚拟主机、TLS 和应用日志。

What DigitalPlat Does 的故障分层表把这一现象归到"Correct DNS but connection timeout → Server and firewall"，即 DNS 已经正确时，问题在服务器与防火墙层，不在 DNS 层。

月度复核与限制

Server Hardening and Maintenance 把"Review listening ports and service owners"列入 Monthly Maintenance Checklist，端口审计是持续性动作，每月至少复核：

1. 待处理的安全更新；
2. 监听端口与服务负责人；
3. 备份与恢复测试；
4. 磁盘空间与日志轮转；
5. 账号与 SSH 访问；
6. 证书续期；
7. DNS 与 nameserver 变更；
8. 移除废弃的文件、记录集与集成；
9. 测试公开用户路径；
10. 记录完成情况和未解决的风险。

收尾时记住几条硬边界：

• 不能切断唯一恢复路径：调整 SSH 网络访问或禁用旧认证前，必须先验证恢复路径可用；
• IPv4 与 IPv6 防火墙策略分别确认，只做完一边不算完成；
• 数据库、缓存和内部应用端口保持在私有或本地接口上，除非远程访问被明确设计并受保护；
• 管理接口在可能的情况下不要放在公开路径；
• 规则改动前先确认备份存在，按 Hardening Lab 的节奏"一次做一个安全改进，然后验证服务"，不要一次改多项再排查；
• 文档给出的是端口清点命令、入站策略原则与验证手段；具体防火墙命令取决于服务器已选择的防火墙系统，文档未指定 ufw、nftables 等工具的具体写法。

【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KG