为什么要更改默认的ssh端口?


Answers:


27

最可能的原因是使人们更加难以随机尝试暴力破解他们可以找到的任何SSH登录名。我的面向互联网的计算机使用默认的SSH端口,而我的日志曾经填充有以下内容(摘自实际的日志文件):

sshd[16359]: Invalid user test from 92.241.180.96
sshd[16428]: Invalid user oracle from 92.241.180.96
sshd[16496]: Invalid user backup from 92.241.180.96
sshd[16556]: Invalid user ftpuser from 92.241.180.96
sshd[16612]: Invalid user nagios from 92.241.180.96
sshd[16649]: Invalid user student from 92.241.180.96
sshd[16689]: Invalid user tomcat from 92.241.180.96
sshd[16713]: Invalid user test1 from 92.241.180.96
sshd[16742]: Invalid user test from 92.241.180.96
sshd[16746]: Invalid user cyrus from 92.241.180.96
sshd[16774]: Invalid user temp from 92.241.180.96
sshd[16790]: Invalid user postgres from 92.241.180.96
sshd[16806]: Invalid user samba from 92.241.180.96

这些天来,我使用DenyHosts来阻止无法通过太多次身份验证的IP,但是切换端口可能同样容易。几乎所有这种暴力攻击都不会费心扫描以查看您的sshd是否正在侦听另一个端口,它们只是假设您没有在运行而继续前进。


15

不,这是默默无闻安全措施

如果您的sshd设置不足以仅尝试使用端口22来面对愚蠢的脚本小子,那么您还是有问题。

一个更合理的反应是:

  • 确保您的用户使用的密码很好,很难猜到/强行使用
  • 禁用密码身份验证(至少对于重要帐户),仅使用公共密钥身份验证
  • 注意SSH安全问题和升级

sshd写入系统日志的噪音可能还会使某些人感到烦恼,例如:

Jan 02 21:24:24 example.org sshd[28396]: Invalid user guest from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28396]: input_userauth_request: invalid user guest [preauth]
Jan 02 21:24:24 example.org sshd[28396]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth]
Jan 02 21:24:24 example.org sshd[28398]: Invalid user ubnt from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28398]: input_userauth_request: invalid user ubnt [preauth]
Jan 02 21:24:24 example.org sshd[28398]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth

然后可能很想掩盖sshd端口或使用自动阻止解决方案(例如DenyHosts,Fail2ban或BlockHosts)以再次提高信噪比

但是确实存在更好的选择。例如,您可以配置syslog守护程序,以便仅将sshd日志噪声写入(例如-),/var/log/sshd-attempts.log并且将信号(即其余的sshd日志消息)写入/var/log/messages等等。

自动拦截工具的部署应仔细考虑,因为安全增加了更多的复杂性相关系统的手段也越来越危险剥削。确实,多年来,每个DenyHostsFail2banBlockHosts都有多个DoS漏洞报告。


4
我真的不同意“默默无闻的安全性”,我认为,在这种情况下,这个答案是一个普遍的谬误。@Michael的推理通常显示出将其放在其他地方的更好理由。这主要是为了摆脱所有脚本攻击。不一定意味着您担心它们,或认为它对确定的攻击者有效。我知道我从不担心他们会真正加入。但是所有的木屑都令人讨厌。
xenoterracide

1
@xenoterracide:如果您仅关注日志文件的可读性,那么还有其他更好的选择来排除噪音,而不是将端口更改为一种默默无闻的策略,这就是问题所在。关于IP阻止,这不是问题的一部分:请注意,给与安全相关的系统增加更多的复杂性也意味着增加了被利用的风险。考虑例如seclists.org/fulldisclosure/2007/Jun/121 ossec.net/main/attacking-log-analysis-tools。是的,DenyHosts受此影响。
maxschlepzig

1
不仅要考虑可读性。适当地记录在案的端口更改并不是模糊的安全性。
xenoterracide

4

更改SSH端口主要是为了安全起见。它给您一种做某事的模糊感。您已将SSH端口隐藏在门垫下。

如果您在Internet上运行SSH服务器,则会在日志中看到很多失败的登录尝试,这些尝试都是来自寻找奇怪的弱密码的漫游器, 服务器版本中弱密钥和已知漏洞的。失败的尝试仅仅是:失败尝试。至于评估您的脆弱程度,它们完全无关紧要。您需要担心的是成功的入侵尝试,并且您不会在日志中看到这些尝试。

更改默认端口将减少此类僵尸程序的命中次数,但只会挫败被任何体面的安全性阻止的最不复杂的攻击者(定期应用安全更新,合理强度高的密码或禁用的密码身份验证)。唯一的好处是减少了日志量。如果这是一个问题,请考虑使用DenyhostsFail2ban之类的东西来限制连接速率,这也可以改善带宽。

更改默认端口的主要缺点是:它使您不太可能从防火墙后面登录。防火墙更有可能使服务通过其默认端口通过,而不是通过某些随机的其他端口。如果您未运行HTTPS服务器,请考虑同时使SSH在端口443上侦听(或将传入的TCP请求从端口443重定向到端口22),因为某些防火墙允许无法在端口443上解码的流量,因为它看起来像像HTTPS。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.