为什么要更改默认的ssh端口?[关闭]


Answers:


65

它并不像某些人所声称的那样有用,但是它至少会减少对日志文件的影响,因为许多暴力登录尝试仅使用默认端口,而不是扫描以查看SSH是否在其他地方监听。不过,有些攻击会在其他地方扫描SSH,因此这不是灵丹妙药。

如果您的服务器将成为某种类型的共享主机,而不仅仅是满足项目需求,那么使用非默认端口可能会很麻烦,因为您将不得不一遍又一遍地向用户解释它。当他们忘记了他们的客户端程序无法连接到端口22时!

在非标准端口上使用SSH的另一个可能的问题是,如果遇到一个客户端,该客户端具有受限的外发过滤器集,该客户端无法连接到自定义端口,因为它们的过滤器仅允许使用例如22、53、80端口443为新的外发连接的目的地。这是罕见的,但肯定不是闻所未闻的。与此类似,某些ISP可能会在除通常预期的端口(端口443或HTTPS,22的SSH等)之外的其他端口上看到加密的流量,以试图隐藏P2P连接和限制(或阻止)连接不方便。

为了方便起见,我个人将SSH保留在标准端口上。只要采取通常的预防措施(严格的密码/密钥策略,限制root用户登录等等),就不必担心,并且可以使用诸如此类的工具来缓解暴力攻击造成的日志文件增长问题。作为fial2ban可以暂时阻止在给定时间间隔内提供过多不良身份验证凭据集的主机。

无论您选择哪个端口,如果您确实远离22,请确保端口低于1024。在大多数类似Unix-a的默认配置中,只有root(或root组中的用户)可以监听1024以下的端口,但任何用户都可以在更高的端口上监听。在较高的端口上运行SSH会增加流氓(或被黑客入侵)用户设法使SSH守护程序崩溃并用其自己的代理或代理替换它的机会。


我是该服务器的唯一用户。感谢您澄清1024+问题。如果选择的话,我会使用48xxx端口。无论如何,我仍然不知道它是否有用= /
动态

16
+1表示> 1024位。
MattC 2011年

26

这是一种通过隐蔽实现的简单(但出奇的有效)安全形式。

如果您的SSH服务器不在端口22上,那么那些扫描整个Internet并在默认帐户中查找弱密码的人就不太可能找到它。如果要扫描整个网络,则无法检查所有可能的64k端口来查找SSH服务器。

但是,如果有人主动将您作为目标,则它没有任何好处,因为简单的一次性nmap扫描将显示其实际运行的端口。


3
“检查所有64k可能的端口” ...在1023以上的任何端口中运行SSH只是错误的。与使系统在默认端口中运行相比,它使系统容易受到攻击。
朱利诺

3
@Juliano-请解释。仅仅因为您必须具有 root权限才能在特权端口上侦听,所以(AFAIK)不会使在非特权端口上运行不安全
Alnitak 2010年

4
顺便说一句,它不是通过模糊来保证安全性,否则,您还必须以相同的方式调用密码身份验证。当不公开实现时,就会通过模糊性确保安全性。在此,明确说明了实现方式(“我更改了服务端口”),并且机密(“哪个端口?”)仍然是机密的。

5
@John-实际上我明白了@Juliano的观点。它不会使SSH守护程序本身从本质上降低安全性,但是在一般情况下,在非特权端口上运行不会使root 启动守护程序的正常假设无效。因此,如果您可以某种方式停止该守护程序(例如通过DoSing停止运行),则可以在不需要root漏洞的情况下在其位置启动自己的假守护程序。然后,该假守护程序可能会捕获足够的详细信息以允许进一步利用。
Alnitak

2
@John,没错-它仍然需要攻击者具有足够的权限才能自己启动新的守护程序。关键是他们不再需要root用户访问权限才能启动它。
Alnitak

21

为了真正避免暴力攻击,请务必遵循以下步骤:

  • 安装denyhosts或fail2ban
  • 限制SSH端口每秒的连接数
  • 更改SSH端口
  • 拒绝root登录
  • 通过密钥而不是密码启用身份验证

11
似乎是一个很好的清单,除了我不太同意的端口更改部分之外,这太晦涩了。现代的端口扫描程序会在几秒钟内找到它吗?(而且许多网络不会允许随机端口流量通过,通常限制为
22、80

1
端口更改限制蛮力攻击会检查在默认端口上运行的ssh,如果攻击更严重,则只有在这种情况下,攻击者才能对网络/主机中的漏洞端口进行扫描。
2009年

1
实际上,我认为,在一个好的防火墙后面,如果您使服务保持最新状态,并且更改了它们的默认设置,则可以免受恶意人员的攻击。可能不是来自0day攻击或未知攻击
Ali Mezgani 09年

2
使用denyhosts / fail2ban可以减少切换端口或需要密钥的需求。如果您不允许使用密码,则没有必要使用denyhosts / fail2ban或更改端口。
杰里米·L

1
使用denyhosts / fail2ban不一定能减轻对其他安全措施的需求。安全性的重点是为试图规避安全性的用户创建尽可能多的障碍。当然,您可能不需要将端口从22更改为2222,但是说另一个管理员来了并重新启用了密码...您仍然会遇到其他一些减速情况。上面列出的每个步骤使管理员所获得的百分比接近100%安全的可能性。
Patrick R

12

是的,它很有用,因为它有助于避免所有蛮力攻击并有助于保持日志清晰:)

至于由您决定的端口号,我看到公司经常使用1291。我使用更高的内容,尽管只是为了帮助避免使用某些脚本。

不允许root ssh登录并更改端口号,也许不能使用诸如fail2ban之类的东西,那么您应该很聪明。添加iptables以取得良好效果,并使您的内容保持最新,并且您应该不会有任何问题。


2
+1表示“清除日志”
Lekensteyn

3
但是,请查看David Spillett的回答,以了解为什么端口1291(大于1024)可能很危险。
Konerak 2011年

如果您建议在许多其他更好的答案之后两年使用一个非特权端口,则可能比“我见过公司这样做”准备更好的理由。我已经看到公司做了很多事情。我很少想效仿他们的榜样。
underscore_d

11

使用非标准的ssh端口将需要更多说明和文档,并回答“我无法登录”电子邮件。

我认为在非标准端口上运行sshd 的以下好处比它所产生的问题更重要:

  • 99.9999%的暴力攻击是由漫游器执行的,它们仅查找端口22,并且从不浪费时间尝试发现非标准端口。蛮力攻击和诸如denyhostsfail2ban之类的对策会消耗资源,您只需在非标准端口上运行ssh服务器即可节省资源。
  • 您将摆脱所有有关僵尸程序试图侵入系统的无用报告。如果在失败的登录报告中显示任何IP,则很可能是人。

而且,如果您想真正讨厌,可以始终在标准端口22上运行伪造的sshd(使用DenyUsers *),而常规sshd则在端口54321上运行。这将确保您所有的漫游器和入侵者都将永远受益。尝试登录到拒绝所有登录的服务,因为没有人会想到尝试找到真正的 sshd服务。

我的2美分。


1
但是,这可能会导致更多的支持电话。
布拉德·吉尔伯特

3
的确如此,但是增强的安全性是有代价的。:)
生来骑行2009年

11

出于任何“安全”原因这样做都是虚假的。这是默默无闻的安全性的最佳示例,而不是安全性。

如果您想使日志更轻便,更整洁,那么可以,它很有用,因为您不会得到太多的端口敲门/脚本式暴力破解尝试。


1
是的 当我在端口22上使用ssh时,每天我的日志中都会显示超过20000次失败的密码尝试。这意味着我每天都会收到一封安全警告电子邮件。我禁用了密码身份验证-您必须具有正确的私钥才能登录-因此我不担心有人进入,但是我宁愿仅在实际情况发生时收到安全警告电子邮件。
jdege 2010年

10

我会在标准端口上运行ssh并使用诸如fail2bandenyhosts之类的东西来限制字典攻击的数量。

另一个选项是禁用使用密码altogheter的登录,而仅允许使用ssh-keys登录。


8

因为外面有很多坏人会扫描所有服务器IP的开放端口,以试图加以利用。我曾经整天在我的SSH端口上遭受重击攻击,直到将其移至另一个端口以及不再与我的任何网站链接的IP上。


7

尝试暴力破解密码猜测攻击的脚本机器人通常集中在端口22上很有用,因此更改端口通常会将其丢弃。您需要在减轻风险的价值与配置ssh客户端以连接到非标准端口的痛苦之间取得平衡(公认的是,如果您没有很多用户在连接,这不是很大的痛苦)。

或者,您可以通过关闭密码验证并改为要求RSA密钥验证来缓解暴力风险。

我通常不更改SSHD上的端口,因此我不建议使用其他端口号,而是检查常用端口列表以找到另一个端口号(即一个未被其他人使用的端口号,因此可能会被扫描) 。


6

我总是将SSHd更改为使用端口2222,每个需要进入我的服务器的人都知道这一点,这不是秘密。这样做绝对不会增加安全性(除非将来的黑客是绝对的傻瓜)。

我从中获得的唯一好处是,身份验证日志没有针对“ root”,“ alice”,“ bob”,“ sally”,“ admin”等的百万次登录尝试失败。


5

事实证明,通过晦涩难懂的安全性是无用的,通常出于上述所有原因(重新配置中的客户端问题,防火墙和代理问题等),我都使用标准端口配置ssh访问。

除此之外,我始终禁用root登录和密码身份验证,并且在最后一步中,我使用fail2ban摆脱了syslog中令人讨厌的消息。在Debian / Ubuntu中,它就像输入一样简单aptitude install fail2ban。默认配置工作得很好,但是我通常将某些参数调整为限制性更强,具有更长的禁止时间(至少一天),并且只有两次失败的身份验证尝试作为禁止的触发。


4

我想说的是,更改SSH端口时保护自己免受最大威胁的事情是自动扫描,它将尝试使用标准的用户名/密码来获得访问权限,如果您的密码策略严格,则不必担心他们。


更不用说端口扫描程序也会尝试其他端口。
Jim Deville

4

如果禁用密码登录到服务器(强烈建议使用),则更改SSH端口完全没有用。通过禁用密码登录(并要求基于密钥的身份验证),您消除了尝试强行输入密码的可能性,因此,您不必担心端口号。

如果您继续允许基于密码的身份验证,那么您将有可能尝试成功进行暴力破解,或者-根据我的经验,更常见的是-您的密码被盗用,因为您在运行系统时输入密码键盘记录器。


如果您/完全没有用/出于安全考虑完全没有用/,我同意。但是,更改端口有助于降低身份验证日志中的噪音。
克里斯·S

“并且需要基于密钥的身份验证”?这是什么
动态的

1
@ yes123,SSH可以使用公用-专用密钥对而不是密码来认证用户。它们的密钥对也可以用密码保护,从而提供两个因素的身份验证(您所知道的=密码;您所拥有的=密钥文件)。如果实施此操作,则可以禁用密码登录(这样,知道您的本地密码的人将无法使用密钥文件和密钥文件的密码)。与密钥相比,密码相对不安全,与密钥对相比,暴力破解容易几百万倍(尽管通常仍然很困难)。请参阅man ssh-keygen以获取大量信息。
克里斯S

@ yes123,各种与ssh相关的手册页(sshd,sshd_config,ssh,ssh_config)非常有用。 该文档看起来像是使用ssh进行公钥身份验证的很好的教程。
larsk's

2

尽管看起来像是典型的“默默无闻的安全性”,但我估计它是有道理的,因为扫描所有可能的端口(〜64k)比仅使用其中一个端口耗时更多。

但是我可以补充一点,“端口敲门”要好得多。


1

没有答案,但是评论太久了,所以我来做这个CW。

我已经思考了一段时间,得出的结论是,朱利安诺(Juliano)在对阿尼塔克(Alnitak)的回答的评论中所说的话有很多道理。尽管如此,我发现通过在端口22上运行SSH使得对它发起任何形式的攻击实在太容易了。

为了解决此问题,我确实在端口22上运行内部SSH服务器,并使用防火墙将高端口转发到目标计算机上的22。正如朱利安诺指出的那样,这通过隐蔽性提供了一些安全性,同时又保留了低端端口的安全性。

我通常不会通过模糊处理来保证安全,并且经常指出,简单的端口扫描将揭示目标端口,从而使模糊处理毫无用处。为了解决这个问题,无论是在办公室还是在家里,我的防火墙(Smoothwall Express)都使用一个名为Guardian Active Response的脚本,该脚本由Snort警报触发。通过观察,我可以告诉您,当您从同一源中击中3个以上不同的端口时,您的数据包将被丢弃直到预设的重置时间。这使得运行端口扫描变得相当困难并且非常耗时,这使得晦涩难懂实际上是物有所值的。实际上,这使我在过去被拒之门外,以至于我为源(家庭或办公室)IP地址设置了一个排除项。


约翰,好主意港口!我认为我们俩都学到了一些东西:)
Alnitak

1

您遇到的问题是,将防火墙设置为仅允许某些IP连接,而老板在他出门在外时厌倦了打开特定IP。如果您要在防火墙上锁定某些IP,那可能会很麻烦。

我在这里想到两件事。更改端口可防止自动攻击。就是这样,但这是那里平均攻击流量的很大一部分...自动化脚本扫描网络。如果更改默认端口,这些攻击应该立即消失。因此在这方面确实有意义。但这对定向攻击没有任何作用,因为如果您有一个特别讨厌的小朋友,攻击者可以从Nessus或NMAP进行扫描以确定您正在使用的端口。

其次,如果您使用的是类似UNIX的服务器,则可以安装Denyhosts之类的实用程序来阻止攻击。如果安装denyhosts,它将监视错误的登录尝试,并且在尝试失败(无论确定次数)之后,它将在指定的时间内禁止IP。Denyhosts还可以与其他denyhost主机进行对话并传递禁令列表,因此,如果攻击者被锁定在Montana的Fred的Linux系统之外,您的系统也将获得该IP的禁止。只要您的用户记住他们的密码,它就非常有用。

这完全取决于您的使用方案。您拥有多少个程序,这些程序对于更改SSH / SCP的连接端口是“痛苦的事情”(并且,如果它们不允许这样做或使您感到痛苦,那么您确实需要亲自考虑更改供应商)。如果只是潜在的恐惧,我会说这不是问题。这是您的老板,要求做的事情不是完全古怪的,因为许多系统管理员确实打开了SSH端口(有些人讨厌那些讨厌任何因模糊而闻到安全隐患的人……但确实确实减少了)自动扫描产生的背景杂讯。)

失败了-更改端口会阻止自动脚本和大多数不良流量。不会阻止定向攻击者。也可以考虑安装自动禁止实用程序。如果正确执行,层的安全不会对您造成伤害,更改端口所带来的好处比在大多数情况下所带来的伤害还要大。


1

我已经在端口> 1024上运行SSH超过5年了。从那以后,我再也没有看到任何端口可以在我的日志文件中尝试(除了我自己)。我管理的服务器使用端口> 1024运行。

许多在端口> 1024上运行的SSH服务器都有自己的网站,该网站非常受欢迎。

如果SSH服务器在我自己的公司中运行,则也许我已经在此处发布了该服务器的IP地址,以便你们可以尝试入侵该服务器。不幸的是,SSH服务器不是我自己的。;-)

但是,您还必须设置其他东西才能使其安全。仅SSH> 1024还是不够的。端口号不能在/ etc / services中,必须使用端口转发(例如,端口1124-> 22),必须禁用对Root的直接访问。

因此,如果您想争论一点,最好在几年内在端口> 1024上运行SSH。

p / s:1124不是我的SSH端口号。哈哈。


0

我猜你是否还没有发现端口可以方便地使用它,否则,不。


0

很好地将SSH移到其他端口确实有一定意义,它有助于提高安全性,但并没有很大帮助。当然,要这样做,您必须控制防火墙,但这对您来说不是问题。我认为取消港口移动带来的好处是开放可接受的范围-实际上,我想说的是,这样做比取消带来的好处更多,而且比您今天暴露的更多。我确信您可以说服他移动端口并通过整理可能的入口点列表而不是全部打开它们来显着减小进入范围。


0

更改ssh端口是没有意义的练习,只会给您带来有限的安全性。最好只禁用密码身份验证,这样就消除了暴力尝试密码的风险,并且完全依赖基于ssh密钥的身份验证。如果您的环境需要密码验证,请采用某些两种因素的机制,例如SecurID或Wikid。

两者都给您带来了真正的安全性提高,而更改ssh端口仅给您带来了安全性的错觉。


0

这是实用的POV:我使用更改了SSH端口的服务器运行了公开可见的私有ssh服务器超过四年,并且没有进行密码扫描的任何尝试。为了进行此质量检查,我只启用了其中一个的22个功能,为期一天。结果,大约每10分钟扫描一次,密码尝试频率大约为每秒5次。此外,“扫描小子”还会寻找具有某些OpenSSH漏洞的服务器。

可以肯定的是这是默默无闻的安全措施,如果遇到敌人,这是没有用的。


-3

无论“默默无闻的安全”人群的抱怨声如何,它的效果都很好。

傻兔子,一切安全就是默默无闻的安全。仅仅因为您认为晦涩的加密协议Z [需要DNA样本,共享密钥的组合以及不可能由人类密码实际键入的组合]实际上是安全的,所以并非如此。事实是,任何安全措施都取决于用户的概率和假设。如果我知道如何利用这个假设,那对您来说太糟糕了,但是确实存在。

无论如何,

我们已经这样做了多年,同时还包括:a)限制连接尝试的速度(但是,我不知道我们如何设置它,在ssh配置中有所设置),以及b)禁止任何主机使用字典攻击进行脚本攻击的脚本X在Y分钟内猜错了。我们禁止主机建立连接一段时间,这使得更容易适应不断变化的网络拓扑。

如果您的密码足够复杂,并且只能在15分钟内进行3次尝试,则不必担心。同样,监视分布式攻击也不难-我们通常通过子网和ip进行整理,以排除这种情况。

最后,您只需要一个秘密的松鼠方法,即可通过修改f / w规则来允许连接到您的端口。它可以是任何东西... smtp,web,魔术dns查询。诸如SecurID或Wikid之类的东西只会将更多信息移交给第三方。而且不要让我开始通过第三方获取安全证书。


2
-1,您似乎不太了解什么是默默无闻...做一些不明显的事情并不等同于对其进行锁定。虽然没有安全性是绝对的,但肯定存在差异,将三因素身份验证混为一谈并不能帮助任何人。
克里斯·S

1
抱歉,克里斯,这是崇尚宗教的宗教。也许不能选择一把锁,因此认为拥有一把可以确保您的安全,但是可以选择所有的锁。跳出框框思考:在许多情况下,做出“不明显”的事情可能比使用锁更好。您的安全模型/观点就像将笔记本电脑放在带警报器的锁车中–一个带石头的调节器,笔记本电脑不见了。但是,也许这不是调节器,而是具有零日漏洞利用和杀戮时间的人……哦,看!克里斯有一个“安全”的目标很明显!模糊性是安全性的重要组成部分。
随机joe

抱歉,您的比较和逻辑不成立。我确实知道如何挑选锁,这样可以更快地将它们切断,打碎窗户,四处走走。每个安全措施都需要一定的时间和精力来解决它。模糊处理需要花费少量时间和精力,大约需要几分钟到几小时。真正的安全性,例如尝试限制速率的密码,使获得密码花费大量时间。巨大的时间差异是“假”安全性和“真实”安全性之间的区别;默默无闻属于前者。
克里斯S
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.