我对 *nix 操作系统非常陌生,我遇到了一些麻烦,我认为这是由于 iptables 防火墙配置错误造成的。
我的服务器在端口 22 上运行 SSH,在 TCP 端口 25565 上运行服务器软件。SSH 和服务器软件对从网络内部建立的连接(即使用服务器的本地地址 10.0.0.xx 建立的连接)做出适当的响应。但是,如果我尝试从网络外部或使用路由器的外部 IP 地址访问它们,它们不会响应。
路由器配置为将这些端口转发到服务器;我非常怀疑那里有错误。
研究 iptables 之后,我尝试了一些指南,但没有看到任何结果。
iptables -L 的输出如下:
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:25565
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:27015
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
来自网络内部的 nmap 扫描报告端口 22 和 25565 已打开,端口 80 和 2705(我目前未运行的另一个服务器软件)已关闭。使用路由器的外部 IP 运行 nmap 不会返回有用的结果;我相信路由器正在检测扫描尝试并拒绝响应。
服务器正在纯文本模式下运行 Debian。
有谁知道问题是什么,或者有建议的故障排除步骤吗?
回应评论:
netstat -tpln 给出以下内容(除其他外);我认为这很好,尽管我不明白 tcp 和 tcp6 之间的区别。
tcp6 0 0 :::25565 :::* LISTEN 3092/java
Hosts.deny 没有条目。
然而,/var/auth.log 有一些......有趣的内容。人们在 SSH 暴露的那一刻就开始尝试暴力破解我的 root 密码,这正常吗?
但是,是的,仔细阅读日志似乎表明我是唯一无法通过 SSH 连接到我的服务器的人。
答案1
iptables 是“让我们导出原始内核表并让管理员理解它”设计的最糟糕(最好?)示例之一。
简单的防火墙将处理您所描述的常见情况,并让您保持理智。它只是 iptables 的一个包装器,但它以任务结构而不是内核结构来表达。
答案2
但是,是的,仔细阅读日志似乎表明我是唯一无法通过 SSH 连接到我的服务器的人。
这敲响了警钟……您是否正在尝试从内部的网络?这不太可能奏效。您必须从路由器的互联网端测试您的访问,例如从 VPS 或 3G 手机。只是一个想法...
答案3
尝试清除你的 iptables 并将默认策略设置为ACCEPT
,如果你可以连接你的问题是你的 iptables 规则,否则你的路由器有问题。
关于 auth.log 文件中的条目,有几个已知僵尸网络的阻止列表,它们很可能试图破坏您的配置(或者只是您进行测试),安装openssh-blacklist-extra
以提供额外的保护(它应该与sshd,但快速检查可能会有所帮助)。另外,应该fail2ban
也是个好主意。
答案4
虽然您可以iptables
手动配置,但使用工具根据您的要求构建防火墙要可靠得多。我发现岸墙成为一个有据可查且易于使用的工具。它以封装形式提供。如果您需要 IPv6,还有 Shorewal6 软件包。有许多配置的示例配置,可以作为一个很好的起点。
该ucf
包还可用于构建规则集。
两者都会设置一些标准规则,您在部署自己的防火墙时可能会错过这些规则。