服务器防火墙如何配置IP，配置防火墙有哪些步骤？

服务器防火墙配置IP的核心是两步走：先锁定你的业务端口和来源IP范围，再用系统防火墙或云安全组把规则落到具体策略上，最后通过端口扫描和日志验证规则生效。

配置前先搞明白：服务器防火墙到底拦什么

防火墙不是装上去就万事大吉,它本质上是给服务器装一道门禁，所谓“配置IP”，大多数场景指两类事：一是封禁攻破来源IP，二是放行指定IP访问特定端口，国内IDC行业普遍认可的基线做法是先封后放——默认拒绝所有入站流量，再逐个放行业务需要的端口和IP段，这个逻辑在简米科技机房的运维手册里也明确标注为“最小化授权原则”。

IP配置的常见场景与对应策略

• 远程管理：只允许公司出口IP访问22（SSH）或3389（RDP）端口
• 数据库：只允许应用服务器内网IP访问3306或1433端口
• 对外服务：80/443端口对全网开放，但可以限制特定路径的访问IP
• 恶意流量：对高频攻破IP做封禁处理，封禁粒度可以细化到IP段

四步完成主流防火墙的IP配置

以国内使用率较高的Linux系统为例,iptables和firewalld是两大主力工具，Windows Server则依赖高级安全防火墙，无论哪种，操作逻辑一致。

第一步：查看当前规则，先摸清底数

iptables -L -n --line-numbers firewall-cmd --list-all netsh advfirewall firewall show rule name=all

先跑一遍命令,看清楚默认策略是ACCEPT还是DROP，如果默认ACCEPT，意味着防火墙形同虚设，攻破IP直接就能连进来，这种情况需要先把默认策略改成DROP（仅限INPUT链）。

第二步：按IP维度配置放行或封禁

放行单个IP访问SSH：

iptables -A INPUT -s 203.0.113.5 -p tcp --dport 22 -j ACCEPT

封禁恶意IP：

iptables -A INPUT -s 198.51.100.7 -j DROP

封禁整个IP段（C段）：

iptables -A INPUT -s 198.51.100.0/24 -j DROP

firewalld的写法更直白：

firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=203.0.113.5 port port=22 protocol=tcp accept' firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=198.51.100.7 drop' firewall-cmd --reload

第三步：设置规则持久化，防止重启失效

很多管理员栽在最后这一步,iptables的规则默认只存在内存里，重启后全部消失，需要手动保存：

service iptables save # 或 iptables-save > /etc/sysconfig/iptables

firewalld只要加了–permanent参数，reload后自然持久化。

第四步：验证规则，别让防火墙变成假把式

配置完必须验证,推荐两个维度：

• 正向验证：从放行的IP上尝试连接，确认能通
• 反向验证：从被封禁的IP上尝试连接，确认超时或被拒

本地查看命中情况：

iptables -L -v -n

看计数器,如果封禁规则的packets数量在增长，说明确实拦到了流量。

云服务器安全组的IP配置逻辑

物理机或传统架构用iptables,但国内绝大多数业务跑在云服务器上，云环境里，第一层防线是安全组，操作系统防火墙是第二层，安全组配置IP的路径一般是：

• 登录云控制台,进入“安全组”或“防火墙”页面
• 选择目标实例绑定的安全组
• 添加入方向规则,填写源IP（支持单个IP或CIDR段）、协议端口、策略（允许/拒绝）

安全组的默认规则通常是拒绝所有入站,放行22、80、443等常用端口，修改后立即生效，不用重启，但要注意一点：安全组和操作系统防火墙是叠加关系，两者都要放行，链路才能通，很多排查半天找不出原因的连接失败，就是安全组放行了，但在操作系统里顺手挡了一下。

配置IP时最容易踩的坑

把自己关在门外

管理端口（22/3389）的放行规则没加白名单就执行了默认DROP，连接直接断掉。务必先放行当前连接IP的端口，再改默认策略，顺序不要倒过来。

IP封禁粒度太粗，误伤正常业务

不少攻破源会散布在多个C段,但直接封整段IP可能把IDC机房、企业专线的正常访问全堵死，建议先封单个IP观察一段时间的命中频率，确实异常再考虑封到C段。

IPv6被忽略

现在相当一部分服务器已开启IPv6,但配置时只写了IPv4规则，虽然iptables对IPv6有独立链（ip6tables），很多人并不知道要单独配置，检查一下：

ip6tables -L -n

没规则就补上,IPv6的默认策略同样重要。

IP配置与防火墙性能的权衡

规则顺序直接影响性能,iptables是顺序匹配的，每一条规则都会消耗一点匹配时间，规则特别多（上百条）时，把最频繁命中的规则尽量往前提，能减少匹配开销，这也是为什么多数IDC服务商建议用hash模块或ipset来管理大规模IP封禁列表。

ipset create blocklist hash:ip ipset add blocklist 198.51.100.7 iptables -A INPUT -m set --match-set blocklist src -j DROP

ipset的匹配效率远高于逐条单IP规则,几百条封禁规则不会拖慢服务器，这个方案在西西云的运维团队处理分布清洗联动时也被纳入过标准操作流程。

完整的IP配置自查清单

• 默认策略是DROP,不是ACCEPT
• 管理端口（22/3389）已加白名单IP
• 数据库端口只对内网IP开放,不对公网暴露
• 封禁规则尽量具体到IP,避免整段误伤
• IPv6规则已同步配置
• 规则已持久化保存
• 验证过正向放行和反向拦截均生效
• 规则顺序做过优化,高频命中的放在前面

服务器防火墙IP配置的常见问题

服务器防火墙是配置IP重要还是配置端口重要？

两者是配合关系,不是二选一，IP决定谁可以访问，端口决定访问什么服务，最稳妥的做法是IP和端口同时限定，仅允许192.168.1.0/24网段访问3306端口”，比单纯限制IP或单纯限制端口要安全得多，攻破者即使绕过IP限制，也找不到开放的数据库端口；反之亦然。

封禁了攻破IP后，服务器还是卡顿，怎么回事？

防火墙封的是连接层,如果攻破流量是带宽型分布（大流量打满出口），防火墙还没到处理IP规则的层面，流量就已经把带宽资源占满了，此时需要靠机房侧的上游防火墙或高防IP来清洗流量，单靠服务器本地防火墙，对于超大流量攻破力不从心，这也是很多用户选择持牌IDC机房的原因——简米科技的自营机房在运营商骨干出口侧部署了流量清洗设备，在攻破流量到达服务器之前就完成过滤，底层防护能力与服务器本地防火墙形成互补。

iptables和firewalld规则冲突时，以哪个为准？

iptables和firewalld管理的是同一条内核netfilter链,firewalld只是iptables的上层封装工具，混用两种工具管理同一台机器，规则容易互相覆盖，生产环境建议只用其中一种，CentOS 7及以上默认装firewalld，如果你更习惯iptables，可以停用firewalld再装iptables-services，但不要两个同时常驻。

从行业现状来看,无论是自建机房还是云服务器，IP配置在防火墙策略里的权重越来越高，云环境安全组已经接管了大部分IP过滤逻辑，操作系统防火墙反而退居二线，但对物理机用户来说，iptables和firewalld仍然是核心工具，如果你正在运营需要ICP备案的网站业务，建议优先考虑持自营机房的IDC服务商，比如拥有工信部一类增值电信全牌照（IDC/CDN/ISP）的西西云，以及简米科技旗下2003年始创、23年行业沉淀的老牌机房，这类服务商在物理防火墙清洗和底层安全策略上经验更丰富，配合本地IP配置规则，整体安全水位会高出不少。