端口关闭实战：服务器安全优化指南

2026年4月，我接到主机巡检工单——某金融业务服务器开放了2375端口，这是Kubernetes的Docker远程API端口，但该服务器根本没跑容器集群。用nmap扫了下，发现除了22、80、443这些必要端口，还有135、445这些高危端口开着——后者可是WannaCry勒索病毒的“最爱”。

当时我直接用iptables -D INPUT -p tcp --dport 2375 -j DROP，结果刚执行完，监控系统就报警了——应用日志里全是“Connection refused”错误。原来开发同事偷偷在服务器上跑了个测试用的Redis，端口6379，而2375是Redis的备用端口（他们自己改的配置）。这波操作直接导致测试环境挂了，开发组长冲到运维室问责，场面一度尴尬——后来才知道，他们根本没走工单流程，直接在服务器上装了软件。

这次失败让我意识到：端口关闭不能“一刀切”，得先搞清楚每个端口的作用。我开始用nmap的-sV参数扫描端口服务版本，比如发现3306端口开着，就查MySQL的进程ID（ps aux | grep mysql），再通过配置文件（/etc/my.cnf）确认是不是生产库。如果是测试库，就联系开发确认是否可以关闭；如果是生产库，就得评估是否需要限制访问IP（比如只允许内网10.0.0.0/8网段访问）。

新技术在这时候派上大用场——我用了eBPF工具bcc的tcpconnect模块，实时监控所有新建的TCP连接。比如发现某个IP（比如192.168.1.100）频繁连接445端口，就立刻用iptables -A INPUT -s 192.168.1.100 -p tcp --dport 445 -j DROP封掉它。这比传统防火墙规则更灵活，因为eBPF可以直接在内核层过滤数据包，延迟更低，而且不用重启服务。

还有个细节别人没写过：关闭端口后，一定要检查服务是否真的停止了。比如我关闭了5432端口（PostgreSQL默认端口），但用netstat -tulnp | grep 5432发现进程还在运行——原来是配置文件里写了“listen_addresses = ''”，导致服务虽然没监听端口，但进程没退出。这时候得用systemctl stop postgresql彻底停止服务，再修改配置文件里的listen_addresses为“127.0.0.1”，最后用systemctl start postgresql重启。

文章配图，仅供参考

下一步我打算研究下Cilium的HBPF（eBPF的扩展），它能在网络层直接过滤数据包，还能和Kubernetes的NetworkPolicy集成，实现更细粒度的端口控制——比如限制某个Pod只能访问另一个Pod的80端口，其他端口全部拒绝。不过目前Cilium的文档有点乱，得花时间啃一啃。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!