4.9 KiB
作者：沐安大数据运维
链接：https://www.zhihu.com/question/23063802/answer/1967299165974423120
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
都很明确：开，必须开，除非你想体验半夜被报警电话吵醒的刺激感。
前任运维说“咱们有云防火墙，系统层iptables没必要开，影响性能”。
有个业务部门偷偷开了个Redis端口在外网，没设密码。一个月后，我们成了别人的挖矿肉鸡，CPU常年100%，清理后门花了两天时间。
养成个好习惯：新服务器上线，第一件事就是配iptables。
iptables不是累赘，是你的“安全底线”
很多人觉得，现在都是云时代了，有云厂商的安全组，iptables多余。这话对了一半。
云安全组确实好用，像大楼的物业保安。但iptables是你家的防盗门。保安可能会看走眼，但防盗门永远忠实地守在你家门口。
如果云平台控制台故障，安全组规则突然失效。
如果服务器上的iptables还开着，那几千台机器就能否避免全暴露在公网上。
想想都头皮发麻。
性能影响？别自己吓自己
“开防火墙影响性能”——这是最大的误解。
看到过过一个测试：开启基础防护规则（开22、80、443端口，默认拒绝其他入站），对网络性能的影响可以忽略不计。除非你每条规则都带着几十个复杂的字符串匹配，那确实会慢。但正常使用，根本感觉不出来。
比起性能那点微不足道的损失，安全带来的收益太大了。
怎么配置才既安全又省心？
我现在的标准配置模板，用了很多年，分享给大家：
# 清空现有规则
iptables -F
# 设置默认策略：进来的包都拒绝，出去的都允许
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# 本机访问本机全部允许
iptables -A INPUT -i lo -j ACCEPT
# 允许已建立的连接和相关的连接通过（最关键的一条！）
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# 开SSH端口（根据实际情况改）
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# 开Web端口（如果需要）
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# 最后，允许ping（调试用）
iptables -A INPUT -p icmp -j ACCEPT
这套规则的核心思想是：先堵死所有入口，再按需开小门。
不同场景下的灵活用法
根据服务器角色，配置要有侧重：
Web服务器：主要开80、443，数据库端口3306只对内部IP开放
iptables -A INPUT -p tcp -s 192.168.1.0/24 --dport 3306 -j ACCEPT
数据库服务器：尽量不暴露在外网，业务端口只对应用服务器IP开放
跳板机：SSH端口可以改成非标准端口，减少被扫描的概率
iptables -A INPUT -p tcp --dport 58222 -j ACCEPT
运维老鸟的小技巧
- 规则顺序很重要：iptables按顺序匹配，常用的规则放前面
- 保存规则是必须的：配置完一定要
service iptables save，否则重启就没了 - 先放行再操作：远程操作时，先在crontab里设置5分钟后清空规则的备份计划，防止把自己锁在外面
- 日志记录：对可疑的访问尝试记录日志，方便排查
iptables -A INPUT -p tcp --dport 22 -m limit --limit 5/min -j LOG --log-prefix "SSH attempt: "
新时代的替代品？各有各的好
现在确实有更现代的方案：
习惯iptables，因为它：
- 通用：哪个Linux发行版都有
- 透明：每条规则我都知道在干什么
- 灵活：想怎么配就怎么配，没有黑盒子
讲话
运维这行干久了，你会明白一个道理：安全往往败在侥幸心理上。
“就一会儿，应该没事”
“咱们系统小，没人会盯上”
“有云防火墙呢，够了”
不要等代价产生了再后悔。
开启iptables，就像是给你的服务器买了份保险。
平时感觉不到它的存在，真出事了，它能救你的命。
在运维的世界里，谨慎从来都不是坏事。