文章总结： 本文介绍Linux服务器安全加固技术，重点讲解FirewallD与ufw两款防火墙管理工具的实战配置方法。FirewallD采用区域概念和运行时与永久双层配置，支持动态修改规则；ufw追求简洁易用，默认拒绝所有入站流量。文章详细列举常用命令、端口开放操作及对比分析，并探讨内核层面安全加固策略，为构建完整防护体系提供可操作建议。
综合评分： 82
文章分类： 安全建设,解决方案,安全工具,运维安全

Linux 服务器安全加固技术（5）

原创

寰宇秘阁
寰宇秘阁

寰宇密阁

2026年9月28日 14:00
安徽

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

在上篇文章中，我们深入探讨了 Linux 防火墙的底层基石——nftables 的工作原理，包括表、链、规则的组织方式以及数据包的匹配流程。掌握底层原理固然重要，但在日常运维场景中，直接编写 nftables 规则的情况其实并不多见。绝大多数系统管理员更倾向于使用高层防火墙管理工具来简化配置工作。

在 Linux 发行版的两大阵营中，防火墙管理工具的选择呈现出明显的分化：RHEL（Red Hat Enterprise Linux）及其衍生版本采用功能强大的 FirewallD，而 Ubuntu/Debian 阵营则推崇简洁易用的 ufw（Uncomplicated Firewall）。两者在设计理念和使用方式上各有特色，但最终目标一致——帮助管理员高效管理网络流量的进出。

本文将详细介绍这两款工具的实战配置方法，并在最后探讨内核层面的安全加固策略，帮助你构建一套从应用层到内核层的完整防护体系。

一、FirewallD：RHEL 的动态防火墙管理

1.1 FirewallD 概述

FirewallD 是由 Red Hat 开发的防火墙后台服务程序（daemon），目前不仅在 RHEL 及其衍生版（如 CentOS、Rocky Linux、AlmaLinux）上默认启用，在 SUSE 系列发行版中也被广泛采用。

FirewallD 相较于传统防火墙管理方式，最大的优势在于动态修改规则。传统方式下，每次修改防火墙规则都需要重启防火墙服务，这不仅会导致短暂的安全空窗期，还会中断现有的网络连接。而 FirewallD 允许在运行时直接修改规则并即时生效，无需重启服务，从根本上避免了这些问题。

FirewallD 通过 systemd 启动并在后台运行。管理员使用命令行工具 firewall-cmd 或图形界面工具 firewall-config 与守护进程交互，二者均通过 D-BUS 消息总线与 FirewallD 通信。在默认配置下，FirewallD 会封锁除 22 端口（SSH）以外的所有入站端口。这意味着，如果你需要在 RHEL 系统上提供任何网络服务，必须显式地开放对应的端口。

1.2 区域（Zone）概念

区域是 FirewallD 的核心概念。每一个网络接口都会被分配到一个区域中，不同的区域定义了不同的信任级别和流量过滤策略。你可以把区域理解为预定义的规则集合，对应不同的网络使用场景。

以下是 FirewallD 提供的主要区域及其特点：

| 区域 | 行为描述 | 典型使用场景 |
| — | — | — |
| block | 阻止所有入站流量，向发送方返回 ICMP 错误消息 | 需要明确拒绝连接的场景 |
| drop | 丢弃所有入站流量，不向发送方返回任何通知 | 对外完全隐身的场景 |
| public | 仅允许 SSH（端口 22）和 DHCPv6 连接，阻止其余所有端口 | 面向公网的服务器（默认区域） |
| external | 阻止大部分端口，启用 IPv4 地址伪装（masquerading） | 路由器的外网接口 |
| home / internal | 比 public 宽松，额外允许 Samba（仅客户端）、CUPS 打印服务和 Zeroconf/Avahi/mDNS | 被认为相对安全的局域网桌面 |
| trusted | 允许所有网络流量通过 | 完全可信的内部网络 |

默认情况下，RHEL 将所有网络接口分配到 public 区域。如果需要将某个接口分配到其他区域，可以在接口配置文件中进行设置：

# 文件 /etc/sysconfig/network-scripts/ifcfg-<接口名>
...
ZONE=trusted

如果你想深入了解某个区域的具体规则，可以查看 /usr/lib/firewalld/zones 目录下对应的 XML 定义文件。

1.3 运行时配置 vs 永久配置

FirewallD 在配置管理上区分了两个层面：

– 运行时配置（Runtime）：修改立即生效，但在系统重启或 FirewallD 服务重启后失效。默认情况下，firewall-cmd 执行的所有操作都属于运行时配置。
– 永久配置（Permanent）：修改不会立即生效，但会持久保存。需要配合 --permanent 选项使用，并通过 --reload 命令激活。

这种双层设计非常实用。在测试新的防火墙规则时，先使用运行时配置进行验证：如果规则有问题导致自己被锁在外面，只需等待系统重启或远程重启 FirewallD 服务即可恢复。确认规则无误后，再加上 --permanent 选项使其永久生效。

典型的配置流程如下：

# 先在运行时测试规则
firewall-cmd --zone=public --add-service=http

# 确认没有问题后，写入永久配置
firewall-cmd --permanent--zone=public --add-service=http

# 重新加载使永久配置生效
firewall-cmd --reload

自定义的永久规则会存储在 /etc/firewalld 目录中。

1.4 firewall-cmd 常用命令详解

firewall-cmd 是管理 FirewallD 最主要的工具。下面按照使用频率分类介绍常用命令。

查询类命令：

# 检查防火墙运行状态
firewall-cmd --state
running

# 查看当前活跃的区域及其绑定的接口
firewall-cmd --get-active-zones
internal
  interfaces: enp0s8
external
  interfaces: enp0s3

# 列出所有可用区域
firewall-cmd --get-zones
block dmz drop external home internal public trusted work

# 查看默认区域
firewall-cmd --get-default-zone
public

# 查看指定接口所属的区域
firewall-cmd --get-zone-of-interface=enp4s0
public

区域和接口管理：

# 修改默认区域
firewall-cmd --set-default-zone=internal

# 将接口从一个区域移动到另一个区域（永久生效）
firewall-cmd --permanent--zone=public --remove-interface=enp4s0
firewall-cmd --permanent--zone=trusted --add-interface=enp4s0

需要注意的是，如果接口的区域已经在 ifcfg-<name> 配置文件中通过 ZONE 参数固定，则无法通过 firewall-cmd 动态修改。

服务和端口管理：

这是日常运维中最高频的操作场景。当你在服务器上部署了新的网络服务后，需要在防火墙中开放对应的端口。

# 列出 FirewallD 预定义的所有已知服务
firewall-cmd --get-services

# 查看某个区域当前允许的服务
firewall-cmd --zone=public --list-services
http dhcpv6-client smtp ssh https imaps

实战操作示例——开放 HTTP/HTTPS 服务：

假设你刚在 RHEL 服务器上部署了一个 Web 服务，需要开放 80 和 443 端口：

# 添加 HTTP 和 HTTPS 服务到 public 区域（永久生效）
firewall-cmd --permanent--zone=public --add-service=http
firewall-cmd --permanent--zone=public --add-service=https

# 重新加载防火墙规则
firewall-cmd --reload

# 验证配置是否生效
firewall-cmd --zone=public --list-services

如果你需要开放的端口没有对应的预定义服务，也可以直接指定端口号：

# 开放 TCP 8080 端口
firewall-cmd --permanent--zone=public --add-port=8080/tcp

# 开放 UDP 53 端口
firewall-cmd --permanent--zone=public --add-port=53/udp

firewall-cmd --reload

此外，如果你需要在 FirewallD 之外集成自定义的 iptables 规则，可以在 /etc/firewalld/direct.xml 文件中配置，具体语法可参考 man firewalld.direct。

二、ufw：Ubuntu 的简化防火墙

2.1 Ubuntu 的”无防火墙”哲学

与 RHEL 默认严格封锁所有端口的做法截然不同，Ubuntu 的默认行为恰恰相反——不启用任何防火墙，所有端口完全开放。这个看似”奇特”的设计决策背后有其逻辑：Ubuntu 认为默认安装不包含任何网络服务，既然没有监听端口的程序在运行，也就没有需要保护的对象。而一旦管理员主动安装并配置了网络服务，就应当自行负责安全防护。

尽管这种理念存在争议，Ubuntu 仍然提供了自己的防火墙管理工具——ufw（Uncomplicated Firewall，直译为”不复杂的防火墙”）。从名称就能看出，ufw 的设计哲学是追求极致的简洁，让防火墙配置不再成为管理员的负担。

ufw 在 Ubuntu 系统中默认安装但并未激活。与 FirewallD 功能丰富但使用复杂的风格不同，ufw 用一套极简的命令语法就能覆盖大部分常见的防火墙配置需求。

2.2 ufw 基本操作

启用与停用：

# 启用防火墙（立即生效，且开机自启）
ufw enable

# 停用防火墙
ufw disable

需要特别注意，ufw enable 执行后防火墙会立即生效。如果你正在通过 SSH 远程管理服务器，务必先放行 SSH 端口再启用防火墙，否则可能把自己锁在门外。

默认策略设置：

# 设置默认策略为拒绝所有入站流量（推荐，也是 ufw 的默认值）
ufw default deny

# 设置默认策略为允许所有入站流量
ufw default allow

ufw 的默认策略是 deny，这意味着一旦启用防火墙，除非你明确放行，否则外部无法访问服务器上运行的任何网络服务。

端口和服务规则管理：

# 按端口号放行
ufw allow 80
ufw allow 443

# 按服务名放行
ufw allow ssh
ufw deny telnet

# 指定协议
ufw allow 53/udp
ufw allow 8080/tcp

实战操作示例——开放 SSH 并查看状态：

以下是一个典型的初始化流程：

# 先放行 SSH 服务
ufw allow ssh

# 启用防火墙
ufw enable

# 查看当前状态和规则列表
ufw status
Status: Active
To                         Action      From
--                         ------      ----
22                         ALLOW       Anywhere
22                         ALLOW       Anywhere (v6)

从输出可以看到，ufw 默认同时处理 IPv4 和 IPv6 的规则。

自定义规则——指定接口和 IP 范围：

对于更精细的控制需求，ufw 也支持丰富的规则语法：

# 仅允许特定 IP 地址访问 SSH
ufw allow from 192.168.1.100 to any port 22

# 允许特定子网访问
ufw allow from 10.0.0.0/24

# 指定网络接口
ufw allow in on eth0 to any port 80

自定义规则会存储在 /lib/ufw/user.rules 和 user6.rules（IPv6）文件中。此外，ufw 还会参考 /etc/ufw/ 目录下的规则文件。

IPv6 流量控制：

ufw 默认同时管理 IPv4 和 IPv6 流量。如果你的环境不需要 IPv6 支持，希望完全屏蔽 IPv6 流量，可以修改配置文件：

# 编辑 /etc/sysconfig/ufw
IPV6=no

2.3 ufw 应用配置文件

ufw 有一个实用的特性——应用配置文件（Application Profile）。当你通过包管理器安装某些网络服务时，对应的 ufw 配置文件会自动安装到 /etc/ufw/applications.d 目录下。这些配置文件预定义了服务所需的端口信息，让你无需手动查找端口号。

# 列出所有可用的应用配置文件
ufw app list
Available applications:
  Apache
  Apache Full
  Apache Secure
  CUPS
  Dovecot IMAP
  Dovecot POP3
  Dovecot Secure IMAP
  Dovecot Secure POP3
  OpenSSH
  Postfix
...

查看某个配置文件的详细信息：

ufw app info "Apache Full"
Profile: Apache Full
Title: Web Server (HTTP,HTTPS)
Ports: 80,443/tcp

使用应用配置文件放行服务：

# 放行 Apache 的 HTTP 和 HTTPS 端口
ufw allow "Apache Full"

# 放行 OpenSSH
ufw allow "OpenSSH"

需要注意，应用配置文件在安装后默认并不会自动激活，你仍然需要手动执行 ufw allow 来启用它们。

三、FirewallD vs ufw 对比

了解了两款工具后，我们来做一个横向对比，帮助你根据实际情况选择合适的工具：

| 特性 | FirewallD | ufw |
| — | — | — |
| 默认发行版 | RHEL/CentOS/Rocky/SUSE | Ubuntu/Debian |
| 默认状态 | 已启用，仅开放 SSH | 已安装但未启用 |
| 核心概念 | 区域（Zone） | 简单的 allow/deny 规则 |
| 规则管理 | 运行时 + 永久双层配置 | 规则直接持久化 |
| 配置复杂度 | 较高，功能丰富 | 较低，上手快 |
| 动态更新 | 支持，无需重启 | 重新加载规则 |
| 图形界面 | firewall-config | gufw（需额外安装） |
| 底层实现 | nftables/iptables | iptables |

简单来说，如果你使用 RHEL 系列发行版，FirewallD 是不二之选，它功能全面且与系统深度集成；如果你使用 Ubuntu 系列，ufw 的简洁风格能让你快速完成配置工作。

四、云环境中的防火墙策略

在讨论防火墙配置时，有一个特殊但极其常见的场景不得不提——云环境。

在云平台上运行的 Linux 虚拟机通常不会启用内部防火墙。初听之下这似乎不可思议，但实际上有其合理性：大多数云环境在虚拟机之上提供了独立的防火墙功能层。例如，AWS EC2 使用安全组（Security Groups）来控制实例的入站和出站流量，Azure 有网络安全组（NSG），Google Cloud 有 VPC 防火墙规则。

这种架构意味着流量在到达虚拟机之前就已经被云平台的防火墙过滤了。在这种情况下，再在虚拟机内部启用防火墙可能会增加配置复杂性和调试难度。

不过，是否在云虚拟机中启用内部防火墙，取决于你的安全需求和合规要求：

– 仅依赖云平台防火墙：配置简单，管理集中，适合大多数场景。
– 双层防火墙策略：云平台防火墙 + 虚拟机内部防火墙，提供纵深防御，适合安全要求较高的生产环境。

建议根据实际的安全策略和合规需求来做决定，而不是一刀切地选择某种方案。

五、内核安全加固（Kernel Hardening）

防火墙控制的是网络层面的安全，但系统安全是一个多层次的课题。内核作为操作系统的核心，其安全配置同样至关重要。默认情况下，Linux 内核的配置更侧重于功能性和性能表现，安全方面的设置并非总是最优的。通过内核加固（Kernel Hardening），我们可以限制一些潜在的攻击面，让系统更加坚固。

修改内核行为主要有两种常用途径：

1、运行时修改：通过 sysctl 命令动态调整内核参数，配合 /etc/sysctl.conf 实现持久化。
2、启动时设置：通过 GRUB 引导选项向内核传递参数。

5.1 通过 sysctl 修改内核参数

sysctl 命令允许在系统运行期间动态读取和修改内核参数。查看当前参数值和修改参数的方式如下：

# 读取当前参数值
sysctl kernel.kptr_restrict
kernel.kptr_restrict =1

# 修改参数值（注意等号前后不能有空格）
sysctl-wkernel.kptr_restrict=2

要查看所有可用的内核参数，可以执行 sysctl -a，目前 Linux 内核大约有 1000 个可调参数。

为了在系统启动时自动应用安全配置，应将参数写入 /etc/sysctl.conf 文件。以下是一组推荐的安全加固参数：

# /etc/sysctl.conf 安全加固配置

# 限制 dmesg 访问：仅 root 用户可执行 dmesg 查看内核日志
# 防止普通用户获取内核敏感信息
kernel.dmesg_restrict=1

# 限制 eBPF 使用：仅 root 用户可使用扩展伯克利包过滤器
# eBPF 功能强大但也可能被利用进行攻击
kernel.unprivileged_bpf_disabled=1
net.core.bpf_jit_harden=2

# 禁止运行时内核重启：阻止通过 kexec 在运行时加载新内核
# 防止攻击者替换内核
kernel.kexec_load_disabled=1

# 限制 SysRq 键功能：仅允许 SAK（安全注意键）功能
kernel.sysrq=4

# 限制进程调试：仅 root 用户可通过 ptrace 调试其他进程
# 防止普通用户窥探其他进程的内存数据
kernel.yama.ptrace_scope=2

# 启用 SYN Cookie：防御 SYN 洪泛（SYN Flood）攻击
# SYN Flood 是最常见的 DDoS 攻击类型之一
net.ipv4.tcp_syncookies=1

# 禁止 ping 响应：使服务器对 ICMP echo 请求不做回应
net.ipv4.icmp_echo_ignore_all=1

写入配置文件后，可以立即激活：

# 从配置文件加载并应用所有参数
sysctl-p

对以上参数做一些补充说明：

– kernel.dmesg_restrict=1：内核日志中可能包含内存地址、驱动信息等敏感数据，限制 dmesg 访问能减少信息泄露风险。
– kernel.unprivileged_bpf_disabled=1：eBPF 是内核中的一个沙箱化执行引擎，功能强大但如果被非特权用户利用，可能成为攻击向量。
– kernel.kexec_load_disabled=1：kexec 允许在不经过 BIOS/UEFI 的情况下直接引导新内核，攻击者可能利用这一机制加载恶意内核。
– kernel.yama.ptrace_scope=2：ptrace 系统调用允许一个进程观察和控制另一个进程的执行，限制此功能可以防止进程间的信息窃取。
– net.ipv4.tcp_syncookies=1：TCP SYN Flood 攻击通过发送大量半连接请求来耗尽服务器资源，启用 SYN Cookie 可以在不消耗连接队列的情况下验证连接的合法性。

需要注意的是，上述部分参数严格来说并不要求完整的 root 权限，而是需要特定的 Linux Capabilities。基于 Capabilities 机制，即使非 root 进程也可能在受限范围内行使某些特权操作。

5.2 通过 GRUB 设置内核启动选项

有些内核安全选项无法在运行时修改，必须在内核启动时通过引导参数传入。在 RHEL、Ubuntu 以及大多数 Linux 发行版中，内核都通过 GRUB（Grand Unified Bootloader）引导启动。

修改方法是编辑 /etc/default/grub 文件，在 GRUB_CMDLINE_LINUX 行的末尾添加所需的选项：

# 编辑 /etc/default/grub
GRUB_CMDLINE_LINUX="... debugfs=off randomize_kstack_offset=on"

这里推荐的两个安全选项：

– debugfs=off：禁用 debugfs 虚拟文件系统。debugfs 提供了内核调试数据的访问接口，在生产环境中关闭它可以减少信息泄露风险。
– randomize_kstack_offset=on：随机化系统调用的内核栈偏移量，使得内核栈的内存布局更难被预测，从而增加利用内核漏洞进行攻击的难度。

修改 /etc/default/grub 后，必须更新 GRUB 配置并重启系统才能生效：

# RHEL 及其衍生版
grub2-mkconfig -o /boot/grub2/grub.cfg
reboot

# Debian/Ubuntu
update-grub
reboot

在修改启动选项之前，建议充分调研每个选项的作用和可能的副作用。盲目跟从网上的”安全加固指南”而不理解其含义，可能导致系统功能异常。

六、总结与最佳实践

本文从实战角度介绍了 Linux 系统中两大主流防火墙管理工具——FirewallD 和 ufw 的使用方法，并探讨了内核层面的安全加固策略。最后给出一些综合性的最佳实践建议。

防火墙工具选择：

• 使用 RHEL/CentOS/Rocky Linux 时，拥抱 FirewallD。利用区域机制管理不同信任级别的网络接口，善用运行时配置来安全地测试规则。
• 使用 Ubuntu/Debian 时，优先选择 ufw。它的语法简洁直观，应用配置文件机制也非常方便。
• 无论选择哪个工具，都要遵循”最小权限原则”：只开放必要的端口，默认拒绝一切不明确允许的流量。

防火墙配置要点：

• 远程管理服务器时，永远先放行 SSH 端口再启用防火墙。
• 使用 FirewallD 时，善用运行时配置进行测试，确认无误后再写入永久配置。
• 定期审查防火墙规则，移除不再需要的端口和服务。

纵深防御策略：

• 防火墙解决的是网络层面的安全问题，内核加固则从操作系统核心层面减少攻击面。
• 将防火墙配置与内核安全参数调优结合起来，构建多层次的安全防线。
• 通过 sysctl 限制非特权用户的危险操作（dmesg 访问、ptrace 调试、eBPF 使用等）。
• 通过 GRUB 启动参数禁用不必要的内核调试功能，启用内核栈随机化。

云环境特别注意：

• 了解云平台提供的防火墙机制（如 AWS Security Groups），避免与虚拟机内部防火墙产生规则冲突。
• 根据安全合规需求决定是否采用双层防火墙策略。

安全从来不是一劳永逸的事情。防火墙和内核加固只是整个安全体系中的两个环节，还需要配合 SELinux/AppArmor 强制访问控制、定期的安全更新、完善的日志审计等措施，才能真正构建起一道坚实的安全防线。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：寰宇密阁 寰宇秘阁
寰宇秘阁《Linux 服务器安全加固技术（5）》