每当我通过 SSH 连接到某个地方时,我都会在日志中看到类似这样的内容:
sshd[16734]: reverse mapping checking getaddrinfo for
1.2.3.4.crummyisp.net [1.2.3.4] failed - POSSIBLE BREAK-IN ATTEMPT!
而且它是正确:如果我这样做host 1.2.3.4
它会返回1.2.3.4.crummyisp.net
,但如果我这样做host 1.2.3.4.crummyisp.net
它就不会被找到。
我有两个问题:
存在什么安全威胁?有人怎么能以某种威胁性的方式伪造单向 DNS?
我有办法修复这个问题吗?我会给我的 ISP 发送一个错误报告,但谁知道它会被送到哪里去呢。
答案1
存在什么安全威胁?
有人怎么能以某种威胁性的方式伪造单向 DNS?
任何控制 DNS 反向区域的一方都可以将他们的 PTR 记录设置为他们想要的任何值。可以想象,有人可以将其 PTR 记录设置为legithost.example.com
,然后尝试强行进入您的环境。
如果您的用户手指笨拙,经常输入错误密码,并且缺乏反暴力破解措施,那么一大堆输入密码失败的日志条目legithost.example.com
可能会被忽略为“哦,那只是鲍勃 - 他打字太笨了!”,这让攻击者有机会不断猜测密码,直到他们进入系统。
(该消息的理论安全优势在于攻击者不能在您的 DNS 区域中创建/更改A
记录legithost.example.com
,这样他就无法消除警告 - 不存在某种类型的 DNS 中毒攻击...)
我有办法修复此问题吗?
选项1:修复您的 DNS,使正向 ( A
) 和反向 ( PTR
) 记录匹配。
选项 2:添加UseDNS no
到系统sshd_config
文件中以关闭警告。
答案2
如果HostbasedAuthentication
设置完成后,您可以指定可以登录的主机名/etc/hosts.equiv
、~/.shosts
和~/.rhosts
。(客户端主机上也有一个公钥检查(它可能是known_host
服务器的))。
如果密钥泄露(在这种情况下您已经遇到问题)并HostbasedUsesNameFromPacketOnly
设置为yes
(可能UseDNS no
也需要),则可以利用这一点,并且攻击者使用相关密钥提供授权主机的主机名。
另一种攻击可能是某个已知服务器伪装成另一个已知服务器以获取更高的权限。
为了避免这些攻击,会比较反向和正向 DNS(如果它们不匹配,则会出现日志条目)。
另一个可能受到攻击的东西:的authorized_keys
host=
参数和Match
块Host
,如果使用主机名(而不是 IP 地址)并且修改了 DNS 条目,则可以为错误的主机激活该参数和块。(UseDNS yes
为此需要使用非 IP)