老服务器开启防火墙：Firewalld 配置与安全整改实践

前言：接手长期裸奔、无人维护的老旧 Linux 服务器，启用防火墙最常见事故就是 SSH 端口排查失误直接锁死远程连接。本文完整覆盖端口探测、监听地址辨析、业务链路排查、firewalld 配置、上线校验、规则收紧全流程，可以直接作为生产环境操作手册。、

一、查看服务器当前监听情况
#

1.1 使用 ss 查看监听端口
#

Linux 中可以使用 ss 查看当前网络连接及端口监听情况。

首先执行：

ss -tulnp

常见参数含义如下：

参数	含义
`-t`	显示 TCP
`-u`	显示 UDP
`-l`	只显示监听状态
`-n`	直接显示 IP 和端口号，不进行名称解析
`-p`	显示占用端口的进程
`-4`	只显示 IPv4
`-6`	只显示 IPv6

因此：

ss -tulnp

可以理解为：

查看服务器当前所有 TCP、UDP 监听端口，并显示对应进程信息。

例如：

tcp   LISTEN  0  256  *:5005              *:*   users:(("aptweb",pid=16098,fd=13))
tcp   LISTEN  0  128  *:6425              *:*   users:(("sshd",pid=1077,fd=3))
tcp   LISTEN  0  511  127.0.0.1:20180     *:*   users:(("VMToolsAgentAPI",pid=1616,fd=9))
udp   UNCONN  0  0    0.0.0.0:68          0.0.0.0:*

需要注意：

TCP 监听端口一般显示为：

LISTEN

UDP 没有 TCP 那样的连接建立过程，因此通常显示：

UNCONN

所以不建议使用：

ss -tulnp | grep LISTEN

来查看服务器的全部监听端口，因为这样会把 UDP 端口过滤掉。

如果只需要检查 TCP，则可以使用：

ss -lntp

1.2 查看 IPv4 监听情况
#

如果服务器业务网络主要使用 IPv4，可以单独查看 IPv4 监听端口。

查看 IPv4 TCP：

ss -lntp4

查看 IPv4 UDP：

ss -lunp4

例如：

LISTEN 0 256  *:5005          *:*  users:(("aptweb",pid=16098,fd=13))
LISTEN 0 511  *:6385          *:*  users:(("redis-server",pid=1601,fd=7))
LISTEN 0 511  127.0.0.1:20180 *:*  users:(("VMToolsAgentAPI",pid=1616,fd=9))
LISTEN 0 128  *:6425          *:*  users:(("sshd",pid=1077,fd=3))

这里主要关注 Local Address:Port 一列。

例如：

*:5005

表示该服务监听所有 IPv4 本地地址。

如果服务器存在：

192.168.10.20
10.10.10.20

那么该服务可能通过这些服务器 IP 的 5005/TCP 接受连接。

因此：

*:端口
0.0.0.0:端口
服务器实际IPv4地址:端口

都属于开启防火墙前需要重点排查的对象。

而：

127.0.0.1:20180

表示服务只监听 IPv4 本机回环地址。

正常情况下，其他服务器无法直接通过：

服务器IP:20180

访问该服务，因此通常不需要为这类端口配置防火墙入站放行规则。

1.3 查看 IPv6 监听情况
#

如果服务器启用了 IPv6，或者希望完整检查服务器监听情况，可以执行：

ss -lntp6

查看 IPv6 TCP 监听。

UDP：

ss -lunp6

可能看到：

LISTEN 0 128 :::6425  :::* users:(("sshd",pid=1077,fd=4))
LISTEN 0 511 :::6385  :::* users:(("redis-server",pid=1601,fd=6))

其中：

:::6425

通常可以理解为：

[::]:6425

即监听所有 IPv6 本地地址。

类似 IPv4 中的：

0.0.0.0:6425

需要注意，即使服务器实际业务只使用 IPv4，Linux 系统仍可能启用了 IPv6 协议栈，因此 ss 输出中依然可能出现：

:::端口

这并不一定说明服务器正在实际使用 IPv6 对外提供业务。

完整排查时建议分别执行：

ss -lntp4

和：

ss -lntp6

分别确认 IPv4 和 IPv6 的监听情况。

1.4 确认服务器实际使用的 IP 地址
#

除了查看监听端口，还需要确认服务器实际配置了哪些 IP 地址。

执行：

ip addr

例如：

2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP>
    inet 192.168.10.20/24 brd 192.168.10.255 scope global ens192

其中：

inet 192.168.10.20/24

代表 IPv4 地址。

如果看到：

inet6 2001:db8::20/64

则代表服务器配置了 IPv6 地址。

需要注意：

inet6 ::1/128

属于 IPv6 本机回环地址，类似 IPv4 中的：

127.0.0.1

不能因为存在 ::1 就认为服务器正在实际使用 IPv6 对外提供服务。

二、理解监听地址
#

你的几种情况：

*:5005

127.0.0.1:20181

::ffff:127.0.0.1:9200

:::19029

分别代表不同范围。

2.1 `*:5005` 代表什么？
#

例如：

tcp LISTEN 0 256 *:5005

这里的 *：

表示：

在 ss -lntp4 输出中，*:5005 表示该服务监听所有 IPv4 本地地址。

假设服务器有：

eth0:
192.168.1.100

eth1:
10.10.10.100

那么：

*:5005

等价于：

168.1.100:5005

10.10.100:5005

0.0.1:5005

也就是说：

外部机器理论上可以访问。

例如：

http://192.168.1.100:5005

关注等级：

⭐⭐⭐⭐⭐

这种必须重点关注。

因为：

*:端口

意味着：

这个服务暴露到了网络。

你的：

*:5005
*:3000
*:5000
*:8008
*:19998
*:6385
*:6386
*:6387
*:19029
*:29028

全部属于这一类。

2.2 `127.0.0.1:20181` 是什么？
#

例如：

127.0.0.1:20181

表示：

只监听本机回环地址。

也就是：

服务器自己访问：

curl 127.0.0.1:20181

可以。

但是：

其他机器：

192.168.1.20:20181

访问：

失败。

因为：

这个服务根本没有绑定网卡。

关注等级：

⭐

一般不用开放。

你的：

0.0.1:20180
0.0.1:20181
0.0.1:20182
0.0.1:45159
0.0.1:25

都不用配置防火墙。

2.3 `::ffff:127.0.0.1:9200` 是什么？
#

这个比较容易迷惑。

你的：

::ffff:127.0.0.1:9200

实际上是：

IPv4映射IPv6地址。

拆开：

::
IPv6

ffff:
IPv4映射

127.0.0.1
本机

等价于：

127.0.0.1:9200

也就是：

本机服务。

例如：

Elasticsearch：

9200
9300

通常：

9200：

HTTP API

9300：

节点通信

你的：

::ffff:127.0.0.1:9200

::ffff:127.0.0.1:9300

不用开放。

2.4 `:::19029` 是什么？
#

这个是IPv6。

例如：

:::19029

这里：

::

代表：

IPv6所有地址。

:::19029 本质上通常表示 [::]:19029。是否同时接受 IPv4 连接，与应用程序创建 socket 时的配置以及系统 net.ipv6.bindv6only 设置有关，因此不能仅凭 ::: 就判断该端口与 IPv4 完全无关。

类似 IPv4：

*:19029

也就是说：

所有IPv6网卡监听。

你的：

:::6385
:::6386
:::6387
:::19029
:::6425

需要注意。

IPv4 + IPv6同时监听

例如：

*:6385

:::6385

说明：

Redis同时监听：

IPv4:

0.0.0.0:6385

IPv6:

[::]:6385

实际上就是：

所有网络接口。

三、哪些端口需要关注
#

看这个规则：

监听地址	是否外部可访问	防火墙关注
127.0.0.1	否	不用
::ffff:127.0.0.1	否	不用
*	是	重点
0.0.0.0	是	重点
::	是	重点
:::	是	重点

四、正式操作
#

对于长期未启用防火墙的服务器，一旦启用 firewalld，未被现有允许规则匹配的入站连接可能被阻断。因此，开启防火墙前必须首先确认并放行 SSH 等远程管理端口，避免因规则遗漏导致服务器失联。

整体操作原则如下：

先确认远程管理端口 → 梳理监听端口 → 确认业务访问关系 → 配置放行规则 → 开启防火墙 → 验证远程及业务 → 持续观察

4.1 确认远程管理端口
#

开启防火墙前，首先确认服务器当前使用的远程管理方式及实际监听端口。

对于 Linux 服务器，通常使用 SSH 进行远程管理，默认端口为 22/TCP，但部分服务器可能出于安全或历史原因修改过 SSH 端口。

可以执行以下命令确认 SSH 实际监听端口：

ss -lntp | grep sshd

例如：

LISTEN 0 128 0.0.0.0:6425 0.0.0.0:* users:(("sshd",pid=1077,fd=3))

说明当前 SSH 实际使用：

TCP 6425

此时后续防火墙规则应放行 6425/TCP，而不是默认的 22/TCP。

注意：

开启防火墙前必须优先确保远程管理端口已经存在允许规则，否则可能导致当前 SSH 会话断开后无法重新连接服务器。

生产服务器操作时建议同时保留当前 SSH 会话，并另外打开一个 SSH 窗口进行验证，在确认新连接正常之前不要主动退出原有会话。

4.2 查看服务器当前监听端口
#

确认远程管理端口后，需要梳理服务器当前所有监听端口。

执行：

ss -tulnp

如果服务器只使用 IPv4，可以重点查看 IPv4 TCP 监听端口：

ss -lntp4

例如：

LISTEN 0 256  *:5005          *:*    users:(("aptweb",pid=16098,fd=13))
LISTEN 0 511  *:6385          *:*    users:(("redis-server",pid=1601,fd=7))
LISTEN 0 511  127.0.0.1:20180 *:*    users:(("VMToolsAgentAPI",pid=1616,fd=9))
LISTEN 0 128  *:6425          *:*    users:(("sshd",pid=1077,fd=3))

需要重点关注监听在以下地址上的服务：

*:端口
0.0.0.0:端口
服务器实际IP:端口

这些服务可能接受来自其他主机的 IPv4 网络连接，需要进一步判断是否需要配置防火墙放行。

对于：

127.0.0.1:端口

表示服务仅监听本机回环地址，正常情况下其他服务器无法直接通过服务器业务 IP 访问，因此通常不需要专门配置入站放行规则。

4.3 梳理端口用途
#

不要将 ss 查询到的所有监听端口直接全部放行。

需要逐一确认端口对应的程序及用途，可以通过以下命令辅助判断：

ss -lntp

或者：

ps -ef | grep <进程名称>

建议形成端口清单：

端口	协议	进程	用途	是否需要其他主机访问	访问来源	是否放行
6425	TCP	sshd	SSH远程管理	是	运维管理网	是
5005	TCP	web	业务服务	待确认	待确认	待确认
6385	TCP	redis-server	Redis	视架构而定	应用服务器	限源放行
29028	TCP	mongod	MongoDB	视架构而定	应用服务器	限源放行
20180	TCP	VMToolsAgentAPI	本机服务	否	localhost	否

判断原则：

远程管理端口：必须放行，但建议限制来源为运维管理网段；
对外业务端口：根据实际业务需求放行；
数据库、中间件端口：原则上不对所有来源开放，如存在跨服务器调用，应仅允许指定应用服务器或业务网段访问；
仅监听 **127.0.0.1** 的端口：通常无需配置入站放行；
用途不明的端口：不得直接放行，应先确认程序、负责人及业务用途。

4.4 检查当前业务连接关系
#

ss -ntp

重点查看：

ESTAB

例如：

ESTAB 0 0 192.168.10.30:6385 192.168.10.20:52316

表示：

192.168.10.20
        ↓
192.168.10.30:6385

正在存在连接。

然后说明：

对于老服务器，这是非常重要的一步。某个端口即使不知道具体业务用途，如果当前存在来自其他服务器的长期连接，也不应贸然阻断，应先确认调用方和业务关系。

4.5 检查当前防火墙配置
#

以使用 firewalld 的 Linux 服务器为例：

systemctl status firewalld

检查当前 zone：

firewall-cmd --get-active-zones

查看默认 zone：

firewall-cmd --get-default-zone

查看当前配置：

firewall-cmd --list-all

建议同时确认服务器网卡：

ip addr

以及网卡对应的 firewalld zone，避免将规则添加到了错误的 zone。

4.6 优先配置远程管理端口
#

假设服务器 SSH 实际端口为：

6425/TCP

在启用防火墙前，应首先配置 SSH 放行规则。

例如当前使用 public zone：

firewall-cmd --permanent --zone=public --add-port=6425/tcp

检查永久配置：

firewall-cmd --permanent --zone=public --list-ports

确认存在：

6425/tcp

如果条件允许，更推荐限制 SSH 来源。

例如只允许运维网段：

192.168.10.0/24

可以配置：

firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.10.0/24" port protocol="tcp" port="6425" accept'

这样只有指定运维网段可以连接 SSH。

4.7 配置业务端口
#

根据前期梳理结果配置业务规则。

例如业务系统需要对外提供：

5005/TCP

可以添加：

firewall-cmd --permanent --zone=public --add-port=5005/tcp

在不确定具体访问范围的情况下，

第一阶段可以先：

允许 SSH 当前使用范围

确认稳定之后，再：

全范围允许
    ↓
运维网段允许
    ↓
固定堡垒机IP允许

因为很多老环境里：

NAT 后来源地址和想象的不一样；
堡垒机出口 IP 不明确；
运维跨网段；
VPN 地址池变化。

第一次就限错 source，比单纯漏业务端口更麻烦。

所以你的思路可以变成：

先保证可用，再逐步收敛。

如果某个端口只允许指定业务服务器访问，例如：

Redis：6385/TCP
应用服务器：192.168.10.20

建议使用来源限制：

firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.10.20/32" port protocol="tcp" port="6385" accept'

不要为了方便直接将 Redis、MongoDB、Elasticsearch 等数据库或中间件端口向整个网络开放。

4.8 开启防火墙
#

确认以下内容已经完成：

SSH实际端口已经确认；
SSH放行规则已经配置；
对外业务端口已经确认；
跨服务器调用关系已经确认；
数据库及中间件访问来源已经确认；
防火墙规则已经核对。

然后再启动防火墙：

systemctl start firewalld

设置开机自动启动：

systemctl enable firewalld

或者：

systemctl enable --now firewalld

检查：

systemctl status firewalld

4.9 开启后立即验证 SSH
#

不要关闭当前 SSH 窗口。

另外打开一个终端，重新连接服务器：

ssh -p 6425 用户名@服务器IP

确认新的 SSH 会话可以正常建立后，才说明远程管理规则基本正常。

如果新 SSH 无法建立，应使用原有 SSH 会话立即检查：

firewall-cmd --list-all

确认端口、zone、来源 IP 等配置是否正确。

4.10 验证业务端口
#

从实际客户端或业务服务器进行测试。

例如：

nc -vz 服务器IP 5005

也可以使用：

telnet 服务器IP 5005

对于 HTTP/HTTPS 服务：

curl -I http://服务器IP:5005

同时检查业务系统：

Web页面是否正常；
客户端是否可以正常连接；
数据库连接是否正常；
Redis/MongoDB等中间件调用是否正常；
服务器之间接口调用是否正常；
定时任务、文件传输、监控、备份等功能是否正常。

4.11 检查最终防火墙规则
#

执行：

firewall-cmd --list-all

重点确认：

services:
ports:
sources:
rich rules:

最终应遵循：

默认阻断非必要入站访问，只允许明确的业务端口，并尽可能限制访问来源。

不能因为某个端口处于 LISTEN 状态，就直接将该端口向整个网络开放。

4.12 整改完成后持续观察
#

对于长期未开启防火墙的历史服务器，不建议开启后立即认定整改完成。

应在开启防火墙后持续观察一段时间，重点关注：

是否出现业务访问异常；
是否存在遗漏的服务器间调用；
是否存在监控、备份、日志采集等系统无法连接；
是否存在第三方系统接口调用失败；
是否存在数据库或中间件连接异常。

确认业务稳定后，再对临时放行规则进行复核和收敛。

五、操作流程总结
#

确认服务器及业务信息
        ↓
确认 SSH/RDP 实际远程管理端口
        ↓
查看当前监听端口
        ↓
梳理每个端口对应的程序及用途
        ↓
检查当前 ESTABLISHED 网络连接
        ↓
确定“谁需要访问哪个端口”
        ↓
优先配置远程管理端口放行
        ↓
配置必要业务端口放行
        ↓
数据库/中间件尽量限制来源 IP
        ↓
开启防火墙
        ↓
保留原会话并新建 SSH/RDP 连接验证
        ↓
逐项验证业务
        ↓
持续观察并收敛规则

核心原则：

先梳理、后放行、再开启；先管理、后业务；能限制来源的端口尽量限制来源；用途不明确的端口不得直接开放。

一、查看服务器当前监听情况#

1.1 使用 ss 查看监听端口#

1.2 查看 IPv4 监听情况#

1.3 查看 IPv6 监听情况#

1.4 确认服务器实际使用的 IP 地址#

二、理解监听地址#

2.1 *:5005 代表什么？#

2.2 127.0.0.1:20181 是什么？#

2.3 ::ffff:127.0.0.1:9200 是什么？#

2.4 :::19029 是什么？#

三、哪些端口需要关注#

四、正式操作#

4.1 确认远程管理端口#

4.2 查看服务器当前监听端口#

4.3 梳理端口用途#

4.4 检查当前业务连接关系#

4.5 检查当前防火墙配置#

4.6 优先配置远程管理端口#

4.7 配置业务端口#

4.8 开启防火墙#

4.9 开启后立即验证 SSH#

4.10 验证业务端口#

4.11 检查最终防火墙规则#

4.12 整改完成后持续观察#

五、操作流程总结#