云服务器防火墙软件怎么选：WAF、安全组与主机防火墙的边界

核心要点（TL;DR）

安全组管南北向端口放行，主机防火墙管实例内精细控制，WAF管应用层攻击。
三层不是替代关系，漏掉任意一层都会留下可利用的攻击面。
默认拒绝入站、只放行必要端口，是云服务器防火墙上手第一步。
0.0.0.0/0 开放管理端口是最常见的高危配置，必须优先收敛。

很多人买了云服务器，第一件事就是配安全组，配完就以为高枕无忧。结果日志里照样出现大量异常请求，数据库端口被扫、SSH 被爆破、Web 应用被打穿。问题不在工具本身，而在于把云服务器防火墙当成了一个东西——实际上 WAF、安全组、主机防火墙分处三个不同层次，边界不清就会既误封又漏防。本文按实战顺序拆解三层职责，并给出可直接执行的配置命令与检查清单。

三层到底各管什么：一张表看清边界

先把概念对齐，后面配置才不会互相打架。

层次	工作位置	能管什么	管不了什么
安全组	云平台虚拟网络层	IP、端口、协议、方向	应用层内容、进程身份、同组内横向流量
主机防火墙	操作系统内核（nftables）	进程、用户、连接状态、限速、日志	分布式CC、大规模DDoS清洗
WAF	HTTP/HTTPS 反向代理层	SQL注入、XSS、爬虫、CC、恶意UA	非HTTP端口、内网东西向流量

一句话：安全组是大门，主机防火墙是房门，WAF 是门口保安。三者是叠加关系，不是替代关系。

第一步：先收敛安全组，把暴露面砍到最小

安全组是零成本、见效最快的一层，先做对再谈其他。核心原则只有一条：默认拒绝入站，按需放行。

管理端口（22/3389）的 source 改成固定办公 IP，不要留 0.0.0.0/0。
数据库（3306/5432）、缓存（6379/11211）一律只放行内网网段，禁止公网。
Web 业务只放行 80/443，其余高位端口全部关闭。
出站规则默认放行，但对可疑外联（如矿池端口）可单独封禁。

改完后在另一台机器上验证实际可达端口：

nmap -Pn -p- 你的公网IP

只应看到你主动放行的端口，多一个都是风险。

第二步：主机防火墙补齐实例内的细粒度控制

安全组被误改、或同安全组内主机被攻陷横向渗透时，主机防火墙是最后一道闸门。新系统统一用 nftables，别再手写 iptables 规则。

nftables 最小可用配置

nft add table inet filter
nft add chain inet filter input '{ type filter hook input priority 0 ; policy drop ; }'
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input iif lo accept
nft add rule inet filter input tcp dport { 22, 80, 443 } accept
nft add rule inet filter input icmp type echo-request limit rate 10/second accept

注意 policy drop 是默认拒绝，规则顺序即匹配顺序，established 必须放最前，否则已建立连接会被误断。

用上层工具更省心

Ubuntu 用 ufw：

ufw default deny incoming
ufw allow from 203.0.113.10 to any port 22 proto tcp
ufw allow 443/tcp
ufw enable

CentOS/RHEL 用 firewalld：

firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=203.0.113.10 port port=22 protocol=tcp accept'
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

两者底层都是 nftables，不用重复维护规则。

第三步：判断你是否真的需要 WAF

WAF 不是必选项。只有对外提供 HTTP/HTTPS 服务、且有登录、支付、上传、搜索等动态接口时，才值得上。判断标准：

有用户输入进入数据库 → 需要防注入
有登录接口 → 需要防爆破与CC
有文件上传 → 需要防WebShell
纯静态站或纯API内网调用 → 可暂缓

上 WAF 时注意：源站 IP 必须对公网隐藏，只允许 WAF 回源 IP 访问 443，否则攻击者可绕过 WAF 直连源站，等于白买。这一层可在安全组里直接限制回源网段，配合主机防火墙做二次校验。若使用 AegisX 的云防护能力，回源 IP 白名单与源站隐藏是内置项，可减少手工维护成本。

排查与上线检查清单

每次变更后按此清单过一遍，能挡住八成低级错误：

ss -tulnp 确认无非必要 0.0.0.0 监听
安全组无 0.0.0.0/0 的管理端口规则
主机防火墙默认策略为 drop/deny
SSH 已改端口或限制来源 IP，禁用密码登录
WAF 已开启且源站仅接受回源 IP
规则变更后从外网实测端口与业务可用性

常见坑：只改安全组忘了主机防火墙，导致规则冲突；或只配主机防火墙，安全组仍全开，等于门锁了但门框是空的。

行动建议

今天就做三件事：把安全组里所有 0.0.0.0/0 的管理端口规则清掉；在每台实例上启用 nftables 或 ufw 并设默认拒绝；用 nmap 从外部扫一遍确认暴露面。三层各司其职，云服务器防火墙才真正形成纵深，而不是堆了一堆工具却处处漏风。

常见问题（FAQ）

云服务器已经有安全组了，还需要装主机防火墙吗？

需要。安全组工作在云平台虚拟网络层，只能按IP和端口过滤，无法识别实例内部进程、用户和协议细节，也无法防止同安全组内主机横向渗透。主机防火墙（nftables/firewalld/ufw）能在操作系统层做进程级、用户级和连接状态控制，是安全组失效或被误改后的最后一道闸门。两者叠加才构成纵深防御。

WAF和安全组到底谁先上？预算有限怎么排优先级？

先上安全组，再上主机防火墙，最后按业务暴露面决定是否上WAF。安全组零成本、见效最快，能立刻收敛端口暴露；主机防火墙补足实例内细粒度控制；WAF针对HTTP/HTTPS层的SQL注入、XSS、CC攻击等，只有对外提供Web服务时才必要。预算有限时优先把前两层配正确，比盲目买WAF更有效。

安全组全部放行0.0.0.0/0会有什么后果？

等于把服务器直接暴露在公网扫描器面前。SSH 22、RDP 3389、Redis 6379、MySQL 3306等端口会被自动化工具在数小时内探测到并尝试爆破或未授权访问，历史上大量挖矿与勒索事件都源于此。正确做法是管理端口只放行固定办公IP，业务端口按需开放，数据库与缓存端口一律不对公网放行。

主机防火墙用iptables还是nftables？

新系统优先nftables。iptables在新版内核中已是nftables的兼容前端，nftables语法更统一、性能更好、支持集合与映射，一条规则可匹配大量IP。CentOS/RHEL 8+、Debian 10+、Ubuntu 20.04+默认已内置nft。若使用firewalld或ufw，其底层也已切换到nftables，直接用上层工具即可，无需手写规则。

怎么快速检查服务器有哪些端口暴露在公网？

在服务器上执行 ss -tulnp 查看监听端口，再结合云控制台安全组规则逐条比对。外部验证可用 nmap -Pn -p- 你的公网IP 从另一台机器扫描，确认实际可达端口。重点核对是否有 0.0.0.0 或 :: 监听的非必要服务，以及安全组中 source 为 0.0.0.0/0 的规则，发现即收敛。

资讯中心