业务侧快速关闭服务器上不必要的端口，是降低被攻击面最直接、成本最低的动作；先摸清端口现状，再用防火墙或系统层规则收敛暴露面，验证生效后把流程固化进日常运维。
很多业务同学听到”端口安全”觉得是安全团队的事，但实际上一台服务器开着哪些端口，往往取决于业务的部署方式，你多开一个没用的端口，就等于给攻击者多留了一扇没上锁的门。
业务侧可关闭不需要的端口有哪些选择
先说结论：关闭端口的手段不止一种，选哪条路取决于你的操作权限和线上环境，常见的动手方式有下面三类。
用iptables或firewalld直接拦截
这是最通用的办法,适合大多数Linux服务器，你不需要改业务配置，只要在系统防火墙层把外部访问挡掉就行。
比如用iptables封掉一个MySQL默认的3306端口：
iptables -A INPUT -p tcp --dport 3306 -j DROP用firewalld的发行版（CentOS 7+、Rocky Linux）则可以写：
firewall-cmd --permanent --remove-port=3306/tcp
firewall-cmd --reload如果你是Windows Server，用自带的”高级安全Windows Defender防火墙”新建入站规则，把对应端口设为阻止即可，操作路径是：控制面板 → Windows Defender防火墙 → 高级设置 → 入站规则 → 新建规则 → 端口。
停掉对应的服务和进程
有些端口是随开机自启的服务拉起来的,这类情况光用防火墙拦还不够，因为服务本身还在跑，占资源且可能被本地提权利用，你要找到端口对应的进程，然后停用掉。
用下面的命令查端口和进程的对应关系：
netstat -tlnp看到PID之后,再用ps -ef | grep PID确认是哪个程序，如果是你自己部署的测试服务或临时工具，直接systemctl stop对应服务名，再systemctl disable防止开机自启。
改监听地址，让端口只对内网开放
有些端口业务上确实要用,但没必要对公网暴露，那你可以把监听地址从
0.0.0收紧到内网网卡IP，比如改成168.1.10:8080，这样公网访问直接被系统网络栈拒绝，等于在更底层关了门。
改监听地址通常需要修改应用的配置文件,比如Nginx改listen字段，Tomcat改server.xml里的Connector地址，改完重启进程生效，这个方式的好处是，端口看着还在，但外部扫描器已经探测不到了。
端口扫描工具怎么看哪些端口开着
你不能靠感觉判断”应该没开什么危险端口”，要用工具实际扫一遍，常见的安全基线检查工具和手动扫描方法都可以派上用场。
从本机视角自查
直接在服务器上执行：
ss -tlnpsocket statistics会列出所有正在监听的TCP端口，带的地址表示对所有网卡开放，这种暴露面最大，重点看有没有0.0.0或的监听项，然后逐个确认对应进程是不是必须的。
netstat -tlnp也可以，但较新的系统上ss信息更全、速度更快。
从外部视角自查
本机看的是”监听”状态，和外部看到的”端口开放”状态不完全一致，想模拟攻击者的视角，用nmap扫一下：
nmap -sT -p 1-65535 <你的服务器公网IP>-sT是全连接扫描，安全设备可能会记日志，但结果最准确，如果你只想看常见的危险端口，用nmap --top-ports 1000就够了。
扫出来的状态为open的端口，就是你当前真正对外暴露的入口，对照业务上线的端口清单，凡是清单里没有的，都属于”可关闭”的候选对象，业内专家指出，相当一部分入侵事件的第一步，就是先扫一遍目标IP的开放端口，再针对敏感服务发起攻击。
定期用端口扫描工具复查
一次扫描只能说明当下没问题,建议把扫描动作放到每月一次的巡检清单里，或者直接用定时任务跑一遍nmap并保存结果，与上一个月的输出做对比，新增的端口如果没有对应的需求记录，就要立刻关掉。
端口关不掉的几种情况，试试这些替代方案
总有一些端口是”业务离不开、大家不敢动”的，这种时候强关不现实，但仍有办法把风险降下来。
加上来源IP白名单
比如你的管理后台端口,可以只允许公司的出口IP访问，用firewalld做源地址限制：
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10" port port="8080" protocol="tcp" accept'
firewall-cmd --reload这样外部任何IP扫到这个端口都是超时或拒绝连接,只有指定的IP能访问，效果上等于把端口”隐藏”了起来。
用云安全组再做一层收敛
很多公有云的控制台里都有”安全组”或”防火墙”配置，这层规则优先级高于系统防火墙，即使服务器内部忘了关端口，安全组没有放行，公网也访问不到。
建议的做法是：在安全组里只放行80、443等必要的入站端口，其余一律拦截，这样即使某台服务器的系统防火墙配置出错，安全组还能兜底。
实在无法关闭的端口，至少加上入侵防御
如果某个老旧的业务系统必须开放一个高风险的端口,同时也无法改架构，那你至少要保证这个端口前面有防护设备，或者在服务器上部署主机入侵检测系统，一旦有人对这个端口发起批量探测或暴力破解，能第一时间告警和封禁IP。
关闭之后，怎么确认攻击面真的变小了
关完端口不是终点,还要验证两个事：一是业务没受影响，二是外部真的扫不到了。
业务自测
去找业务负责人或测试同学,把核心链路走一遍，顺着用户在页面上的操作路径，登录、查询、保存、上传等动作挨个试一遍，确认没有报错后，才算完成验证。
外部复扫
再执行一次nmap扫描,对比关端口前后的结果，原来开放的端口如果现在变成了
closed或filtered，说明规则已生效，这里有个小细节：nmap扫出的filtered多数是防火墙拦了，closed则可能是服务停了但防火墙没拦，两者都算达到目的。
留存变更记录
把关闭的端口、对应的业务模块、操作时间、验证结果记录在运维变更单里，后续再有人问起这个端口去哪了，直接翻记录就能答上来，行业共识认为，端口管理混乱的核心原因不是没人关，而是关了之后没人记，过了几个月又有人把端口放开，风险也就回来了。
常见问题：业务侧关闭端口时容易踩的坑
端口关了服务起不来，怎么办
先别急着把防火墙规则删掉,执行ss -tlnp看服务进程还在不在，再用journalctl -u 服务名看启动日志，多数情况是服务绑定在了一个已被防火墙拦截的地址上，确认是”防火墙先拦截、服务后启动”的顺序问题，一般把服务重启一遍就能解决，如果是端口冲突，换一个内部未占用的端口再放行。
数据库端口需要关闭公网访问吗
这里想提醒的是,数据库端口别直接暴露在公网上，你可以在安全组或防火墙层面只允许应用服务器所在的内网网段访问数据库端口，用iptables示例：
iptables -A INPUT -p tcp --dport 3306 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -j DROP先把内网放行,再把其他来源全部丢掉，顺序不要反了，否则内网也连不上。
和云平台安全组里的规则冲突了怎么办
安全组和服务器内部防火墙同时生效时,两边的规则都要检查，先看安全组的入站方向是否放行了该端口，再看服务器内部防火墙是否拦截，两层规则交集之外的部分都进不来，排查时按这个顺序看：云平台控制台的安全组规则、服务器内防火墙规则、服务本身的监听地址，逐层确认。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/652984.html
