平时正常跑业务的时候，基本没人愿意碰服务器防火墙。但很多时候部署软件、搭建集群，端口死活不通，排查半天才发现是防火墙拦截了，不少人索性直接关掉它。防火墙一关，眼前的故障确实消失了，但后续会埋下不少安全隐患。
Linux系统关闭防火墙，得先确认本机使用的防火墙程序。CentOS7及以上版本默认使用firewalld，查看状态指令是systemctl status firewalld；临时关闭执行systemctl stop firewalld，如果想要开机不再自动启动，追加systemctl disable firewalld。Ubuntu、Debian系列常用ufw工具，ufw status查看运行状态，ufw disable执行关闭操作。还有老旧系统在用iptables，执行service iptables stop，或者直接用iptables -F清空全部规则；清空之前建议先用iptables-save导出保存规则，不然后续想恢复只能凭记忆手动配置。
Windows服务器关闭防火墙操作会直观很多。打开控制面板找到Windows Defender防火墙，在左侧菜单选择启用或关闭选项，把专用网络、公用网络两项全部设置为关闭，保存确认即可。命令行也能一键操作，输入netsh advfirewall set allprofiles state off就能完成。但Windows Server的防火墙很难一次性永久关闭，域环境的服务器尤其明显，安全组策略刷新之后，防火墙会被自动重新开启。
防火墙关闭完成，第一件事就要验证端口连通状态，不能直接默认端口已经通了。可以从另外一台机器使用telnet或者nc工具测试。Linux机器执行nc -zv 目标IP 端口；Windows使用telnet 目标IP 端口，确认连通之后再继续后续工作。如果测试依旧不通，问题根源就不在防火墙，需要排查安全组、路由策略或是目标服务本身有没有正常监听端口。
安全层面的风险必须讲清楚。防火墙一旦关闭，服务器就相当于直接裸奔暴露在网络里。公网服务器只要开放22端口，短短几分钟就会有扫描器进行探测。之前有相关统计，公网暴露的Linux服务器开启SSH端口，平均几分钟就会收到暴力破解尝试。防火墙关闭之后，这类攻击请求会直接抵达登录服务，密码强度不足就很容易被入侵。Windows服务器的情况更严重，开放3389端口，RDP爆破流量短时间内就能填满系统日志。
如果迫不得已需要关闭防火墙，至少做好几项防护兜底。把SSH、RDP的默认端口修改为非标准端口，不要继续使用22和3389。密码设置长一点，十几位，混合大小写、数字和符号。条件允许优先启用密钥登录，放弃密码登录方式。如果访问人群固定，可以在云平台控制台的安全组限制来源IP，仅放行公司出口IP或者VPN网段。安全组属于云平台层面流量过滤，和操作系统防火墙相互独立，关闭系统防火墙不会影响安全组继续拦截外部流量，相当于把防护转移到云平台侧，实用性很强。
临时关闭和永久关闭防火墙完全是两回事。调试阶段用systemctl stop临时停止，调试结束立刻systemctl start恢复，这种操作没有问题。风险点在于执行disable禁用之后遗忘，几个月之后接手的运维人员完全不清楚这台服务器防火墙处于关闭状态。临时调试的话，关闭前做好记录，或者配置定时任务，几小时之后自动重新启用防火墙。这种遗忘的情况真实存在，有人调试完成忘记开启，时隔半年才发现问题。
还有个很常见的误区，部分人认为关闭防火墙之后黑客找不到入口，服务器就安全了。事实刚好相反，防火墙关闭之后所有端口对外开放，攻击面会大幅扩大。防火墙的核心作用是放行指定必要端口，拒绝其余所有端口的访问。关掉防火墙等同于拆掉大门，任何人都可以访问服务器。真正稳妥的方案不是关闭防火墙，而是梳理需要开放的端口，精准添加放行规则。firewalld使用firewall-cmd --add-port=8080/tcp --permanent，ufw执行ufw allow 8080，只开放业务必需端口，其余端口保持拦截。
如果服务器安装宝塔、cPanel这类主机面板，面板会接管防火墙管理，不要同时在系统层面操作防火墙，两套防火墙容易产生规则冲突。宝塔防火墙直接在面板页面配置，系统自带firewalld或者ufw保持关闭，交由面板托管。两套防火墙同时运行，规则会互相覆盖，最终生效的策略无法预判。
最后提醒一句，如果一定要关闭防火墙，操作前备份当前防火墙规则。iptables执行iptables-save > /root/iptables.bak导出备份；firewalld的规则文件存放在/etc/firewalld/目录，可以打包保存。万一关闭防火墙之后出现异常，有备份文件方便恢复。防火墙并不是运维的阻碍，拦截流量大多是因为规则配置不对。花十分钟学习添加端口放行规则，远比关掉防火墙之后长期担惊受怕更合适。