服务器端口是攻击者最直接的入口。每一次对外开放服务，都意味着把一个端口暴露给不可信网络。端口安全配置的目标不是把端口藏起来，而是确保只有必要的端口对外开放，并且每个开放端口都有严格的来源限制、协议约束与审计记录。多数入侵事件并不是因为攻击者发现了某个未知端口，而是因为很多端口在默认配置下监听全网地址、允许弱口令或根本没有访问控制。
端口安全配置的基础原则
端口安全的起点是收敛攻击面。任何服务器在上线前都应该执行一次端口清单梳理，关闭所有与业务无关的服务。可以通过ss -lntup查看当前正在监听的TCP和UDP端口，确认每个进程的真实监听地址。监听地址为0.0.0.0表示对所有网卡开放，这是最危险的状态。
ss -lntup
一个常见误区是认为修改默认端口就等于安全加固。修改SSH端口确实可以减少自动化扫描的噪声，但它无法阻止针对特定目标的探测。如果某个端口仍然对所有来源开放，攻击者只需一次全端口扫描即可发现新端口。正确的做法是优先限制来源IP，再考虑是否修改默认端口。对于SSH和远程桌面这类管理端口，应只允许堡垒机或办公网络IP访问，而不是全网开放。
第二项原则是默认拒绝。无论是主机防火墙、云安全组还是容器网络策略，都应采用白名单模式，即只放行明确需要的端口与来源，其他流量一律丢弃。云服务器的安全组与系统防火墙并不冲突，二者叠加可以构成两层防线。安全组负责在云平台边界过滤流量，主机防火墙则提供更细粒度的控制，例如限制某个进程只监听内网接口。
常见服务端口的加固示例
SSH服务通常监听22端口，也是暴力破解的高发目标。建议先限制登录来源，再禁用root远程登录和密码认证，改用密钥登录。修改/etc/ssh/sshd_config时不要直接关闭正在使用的会话，可以先保留一个测试连接，验证配置无误后再重启服务。
Port 22022 PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes AllowUsers opsuser
如果业务上无法禁用密码认证，则应设置强密码策略并配合失败登录限制。工具fail2ban可以监控SSH日志，在多次失败后临时封禁来源IP。需要注意，修改端口后必须同步更新防火墙规则和安全组，否则新的管理端口无法连接。
远程桌面RDP默认使用3389端口，历史上存在大量漏洞攻击。Windows服务器应避免将3389端口直接暴露到公网，优先使用VPN或专线连接。如果必须开放，可以通过Windows防火墙限制远端IP。
netsh advfirewall firewall add rule name="RDP Restricted" dir=in action=allow protocol=TCP localport=3389 remoteip=203.0.113.10
HTTP和HTTPS是Web服务器最常见的开放端口。80端口通常用于跳转到443，或者在负载均衡器上做健康检查。对外提供Web服务时，应确保仅开放80和443，不要同时暴露应用服务器端口如8080。Nginx或Apache的监听地址可以绑定到内网IP，由负载均衡器统一对外转发。
server {
listen 10.0.0.5:80;
server_name app.ipipp.com;
return 301 https://$host$request_uri;
}
server {
listen 10.0.0.5:443 ssl;
server_name app.ipipp.com;
ssl_certificate /etc/nginx/ssl/app.pem;
ssl_certificate_key /etc/nginx/ssl/app.key;
}数据库端口是配置错误的重灾区。MySQL、Redis和MongoDB默认都可能监听全网地址，其中Redis在没有密码的情况下被公网访问几乎等同于服务器失陷。MySQL应设置bind-address为内网地址或127.0.0.1，只允许应用服务器连接。
[mysqld] bind-address = 127.0.0.1 skip-networking
Redis应在配置中启用保护模式并设置访问密码，同时绑定到内网地址。
bind 10.0.0.5 protected-mode yes requirepass "replace-with-strong-password"
MongoDB也应通过bindIp限制监听地址，并开启认证。许多数据泄露事件正是因为这些内存数据库被设置为默认无认证且监听0.0.0.0。数据库层通常不需要直接对公网开放，如果业务必须跨机房访问，应通过专线、VPN或SSH隧道，而不是简单放行3306或6379端口。
防火墙与安全组策略落地
有了服务自身的监听限制，还需要在主机防火墙层面实施统一规则。以下iptables规则将默认策略设为丢弃，仅允许已建立的连接，以及来自指定IP的SSH访问，并对公网开放Web端口。
iptables -P INPUT DROP iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p tcp --dport 22022 -s 203.0.113.10/32 -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT
使用UFW的服务器可以用更简洁的方式实现同样效果。
ufw default deny incoming ufw allow from 203.0.113.10/32 to any port 22022 proto tcp ufw allow 80/tcp ufw allow 443/tcp ufw enable
云安全组规则应和主机防火墙保持一致，避免出现主机已禁止但安全组仍然放行的情况。安全组的出站流量一般保持默认放行，重点是入站规则。对于不直接提供服务的服务器，入站规则最好只保留管理端口，并且来源设为堡垒机的内网IP或办公网段。
在实施规则时要特别小心重启后的持久化。iptables规则默认不保存，重启后可能丢失，应使用iptables-save或发行版提供的持久化工具。对于云服务器，优先在控制台配置安全组，因为安全组不依赖系统状态，重装系统后依然生效。
验证与持续审计
配置完成后需要从外部视角验证实际暴露面。可以在一台外部主机上使用nmap扫描服务器，核对开放端口是否与预期一致。注意扫描前应获得授权，且不要对生产环境发起高强度探测。
nmap -sT -Pn --top-ports 1000 203.0.113.20
内部则使用ss -lntup或netstat -lntp反复核查监听地址。重点检查是否有服务监听0.0.0.0，以及进程是否与预期一致。端口变化往往意味着服务被误配置或系统被安装了后门。
端口安全管理不是一次性任务。每当新业务上线、软件升级或调整架构时，都应重新评估开放端口。可以定期导出安全组和防火墙规则，与资产清单进行比对。对于暴露在公网的服务器，建议结合入侵检测系统与日志采集，记录每一次连接尝试，必要时设置自动化告警。只有让端口始终处于可控、可审计的状态，才能有效降低服务器被入侵的风险。