直觉上这似乎是明智的。但是，我们俩基本上都是自学成才的，因此我对改善我们自己的安全程序而不是遵循公认的惯例的想法感到不安。我知道，一般而言，密码方案和协议是由专家团队精心设计的，并且每个细节都旨在防止某种形式的攻击，无论看起来多么微不足道。我担心偏离这些建议会带来意想不到的后果。
但是我的同事似乎有证据支持他。他能够证明我们每天尝试通过22号端口并继续前进都遭受数十次攻击。我知道一般情况下我们应该避免默默无闻地避免安全性，但是远离这个共同的目标确实确实可以阻止大多数攻击。
这是否是好习惯？我们应该使用众所周知的端口吗？
ADDENDUM
我们不仅仅依赖晦涩的端口。我们还有许多其他安全措施，包括强制性硬件密钥。我将更清楚地陈述我的问题。
是否出于任何原因特别选择了端口22作为SSH？使用其他端口是否有危险？
#1 楼
使用晦涩的端口号是否可以提高安全性？
如果您已经在使用高熵密码或公钥身份验证，答案是“不是真的”。通常，您只是摆脱了日志中的噪音。
我担心偏离这些建议会带来意想不到的后果。
这取决于所选择的端口。在Linux中，默认情况下，所有1024以下的端口都需要root访问权限才能侦听它们。如果您使用的端口高于1024，那么如果还没有进程在监听，则任何用户帐户都可以在该端口上进行监听。
为什么这很重要？假设您选择将ssh设置为绑定到端口
20,000。如果有人可以停止服务器上的SSH进程（假设他们以某种方式找到了使该进程崩溃的方式）并可以对该服务器进行本地访问，则可以在服务重新启动之前在端口20,000上运行自己的SSH服务器。然后，任何登录的人都将登录到坏人SSH服务器。这已不再像以前那么重要了，因为这些天来，只有受信任的IT员工才能获得登录访问权限到服务器。但是，如果攻击者在您的服务器上立足，它确实有特权升级和其他麻烦的可能。
除了低于1024，数字22并没有什么特别的。因为SSH替代了端口
23上的telnet，并且FTP已经使用21。只要在1024下方选择一个端口，该端口就无关紧要。这是否是好习惯？我们应该使用众所周知的端口吗？
我不会说我推荐它。我也不会建议这样做。就像我说的那样，它避免了日志文件中的大量干扰，但是好处仅限于此。
对于任何对SSH背景故事感兴趣的人，您都可以在以下网址找到它：https://www.ssh.com/ssh/port
评论
评论不作进一步讨论；此对话已移至聊天。
–Rory Alsop♦
18年7月20日在10:32
不。任何尝试登录该恶意服务器的人都会受到警告，提示主机密钥已更改（允许客户端退后一步，编辑其known_hosts文件以删除此类条目，再次连接，接受未知密钥并登陆攻击者拥有的另一台服务器，甚至连他们家里的文件都丢失了）。还要注意，重定向可以通过iptables完成，因此sshd实际上正在侦听22（从外部无法访问），并且实际端口20,000被其遮蔽了。
–Ángel
18年7月21日在21:56
@Ángel尽管这是正确的，但它仍将为具有任意读取漏洞或允许访问主机密钥的旁通道攻击的人提供功能（这不是很小的风险）。此外，它使社交工程攻击变得更容易，并且可以利用客户端。您使用iptables重定向端口是正确的，如果您要安全使用高端口，这将是一个好主意。
–森林
18年7月24日在4:59
#2 楼
是的，它确实。真正的问题是：要多少钱？为什么呢？您已经具有基本的安全性，因此日常的bot攻击不必担心。但是明天可能会是0天，攻击者知道直到补丁发布不会很快，因此他们争先恐后地使用它，而不会打扰复杂的事情-他们只会在尽可能多的计算机上使用标准端口。任何一种理论上的SSH蠕虫都将使用此策略。您将受到保护。
这可以为您带来多少额外的安全保障？它可以防止这种情况发生，也可以避免其他2-3种特定情况。对于完全不是白痴的人，任何针对性的攻击最多只会增加几分钟。它对您已经受到充分保护的情况没有任何帮助。
将这些数字放入您喜欢的风险分析方法中，您应该想出一些相对较小的方法。不利的一面是，您需要付出更多的努力来设置非标准端口号，对其进行记录，在故障排除过程中可能会丢失它并浪费一些时间等。即使进行分析。或者，换句话说：是的，它确实提高了安全性，但是由于改进很小，因此不值得麻烦。
评论
“明天可能是0天，[攻击者]只会在标准端口上攻击尽可能多的计算机。”在其他答案中没有提到的好点！
–吕克
18年7月17日在15:54
@ jpmc26您不了解安全性，并认为它是二进制属性。不是。我也很好奇为什么我需要用两个防火墙阻止一个封闭的端口，以及为什么这样做可以提高我的安全性。
–汤姆
18年7月19日在4:10
@ jpmc26在此问题中，防火墙中的0天如何重要？我清楚地讲了将sshd设置为0天，并且清楚地描述了这种情况。我们俩都同意，使用非标准端口最多只会在安全性方面有小幅提高，但是在某些情况下它确实会有所作为。
–汤姆
18年7月19日在10:28
我知道防火墙是如何工作的。我以为发问者不是一个完整的白痴，并且已打开SSH，因为他需要它可以访问。第2部分展示了一个典型的安全误解-您的防御需要抵抗每个攻击者。那是错的。如果我需要解释原因，请打开一个新问题，该问题超出了注释的字符数限制。
–汤姆
18年7月19日在12:48
如果您阻止了99％的攻击者，则意味着您每10年遭到一次黑客攻击，而不是每年10次。如果您认为这没有什么不同，我们没有什么可以讨论的。
–汤姆
18年7月19日在20:56
#3 楼
不，它不会提高安全性。这可能会减少日志混乱，因为自动攻击只会尝试默认端口，例如ssh。但是该端口仍将在端口扫描和shodan.io中显示为SSH。弱密码。如果它们成功，那么您首先会遇到问题。如果您将ssh配置为仅允许密钥身份验证，禁止root登录并使用明智的密码，请使用fail2ban或类似的机制来阻止违规者，他们不是真正的威胁。
我使用fail2ban配置为在3次失败尝试后暂时阻止5分钟，并在3 * 5次失败尝试后暂时阻止一周。这样可以减少日志混乱，并阻止蛮力攻击的任何实际进展。我认为，对于自动攻击而言，风险可以忽略不计。
评论
难道不那么频繁地受到攻击是否可以改善安全性？因为我同意，随机的巨魔通常会通过基本的预防措施来阻止。但是，并非每次攻击都带有很小的破坏风险吗？即使冒着像正确猜出RSA密钥一样不可能的风险？
–威廉·罗森布鲁姆
18年7月17日在5:40
我认为，针对RSA的暴力破解没有真正的风险。而且我还没有观察到任何自动攻击都在尝试这种方法。他们尝试密码验证。在进行真正的针对性攻击（这会做大量工作来查找有效的用户名等）时，更改端口将无济于事。
–vidarlo
18年7月17日在5:41
@WilliamRosenbloom，大多数自动攻击的破坏风险为零。考虑一下在过去的一年里一直在尝试通过暴力方式对我的服务器进行root访问的那个人：即使他拥有密码，私钥和世界上最好的黑客的帮助，他进入服务器的风险也为零。配置为拒绝来自root的所有登录请求。
–马克
18年7月17日在23:26
@WilliamRosenbloom除非它不会永久减少攻击。有些僵尸网络可能永远不会发现，但是有一些聪明的僵尸网络会由于端口扫描或流量检查而发现。一旦发生这种情况，您就回到了起点。而且，它对任何严重的针对性攻击几乎没有任何作用，任何熟练的攻击者都会迅速找出端口所在。
–奥斯汀·海梅加恩（Austin Hemmelgarn）
18年7月18日在1:54
同意如果您的ssh身份验证是可靠的，那么对您来说最危险的攻击是某种高级持久威胁（APT）。 APT网络犯罪分子不会被其他端口上的ssh侦听器的安全性所迷惑。如果您在压力下被迫进行事件响应，那么您会很高兴拥有标准的东西。
– O. Jones
18年7月20日在18:21
#4 楼
更改默认端口可以使您免于端口扫描和脚本骗子的攻击，但您可能无法承受针对性攻击，因为攻击者可以识别与端口无关的运行服务。如果您只想获取远离脚本小子，这可能会有所帮助，但您可能无法确保自己免受其他高级攻击的侵害。
我的建议是使用默认端口（可能会减少您的管理开销）并部署多方面的安全防护以减轻攻击。
例如，在使用默认端口的情况下，仅允许对某些受信任的源使用SSH部署基于证书的身份验证。
评论
我们不依靠晦涩难懂。我们还有许多其他安全措施，包括硬件身份验证密钥。晦涩的端口只是常规安全性之上的额外一层。知道这一点，您是否仍建议使用默认端口22？除管理费用外，还有其他原因吗？
–威廉·罗森布鲁姆
18年7月17日在2:08
@WilliamRosenbloom综上所述，您显然已经防御了基本攻击。任何能够通过您的硬件身份验证密钥的人，也都可以找到该替代端口……因此，我认为Sayan的帖子仍然站着：“使用默认端口并部署[多层安全性]”。
–吕克
18年7月17日在15:52
如果您使用的是硬件密钥，则使用非标准端口仅是安全区。任何有机会破坏硬件密钥的攻击者都不会立即识别您的真实ssh端口。实际上，低得多的攻击者可以轻松地做到这一点。
–goteguru
18年7月17日在18:14
#5 楼
我会说是的，请使用非常规端口号，因为这将过滤掉许多自动程序。但不要依赖它，因为我注意到很多机器人都会在网络/主机上扫描任何打开的端口，然后尝试使用它们。港口。禁用root登录，如果可以的话，将IP列入白名单，请勿使用密码进行登录（使用keys），还应为所有登录启用通知。并设置防火墙，这很重要。评论
让我们继续聊天中的讨论。
–森林
18年7月21日在2:48
#6 楼
像这样遮盖大量端口只会阻止简单的漫游器，而僵尸程序会寻找众所周知的端口。脚本小子和坚定的黑客可以简单地通过端口扫描其余端口范围来找到服务，因此您只需要停止一些日志噪音即可。该服务的标准端口。该服务的开发人员可以选择在任何其他端口上运行它，并且可能与该端口交互的任何程序都可以选择指定要与哪个端口通信。我同意这里的其他帖子也指出，像SSH之类的敏感端口应保留在1024以下的特权端口空间中。这涉及在iptables处关闭端口，直到“敲响”了一系列端口，然后将打开所需的端口。
例如，您可能会向8000 4545 28882 7878发送一个数据包。输入iptables将解锁您想要的端口。实际上，这确实阻止了大多数脚本小子和黑客，因为没有广告宣传任何端口。但这并不能阻止重放攻击，但是此时您有更大的问题要担心。
https://en.wikipedia.org/wiki/Port_knocking。
真的，您应该使用TCPWrappers，并且只允许已知的ip和网络范围访问SSH之类的端口。您是否需要让来自中国的IP访问SSH？还是开发人员仅需要从办公室局域网访问？如果他们可以远程工作，请将其VPN接入局域网
评论
端口敲门是一个安全的想法，但是它具有绝对糟糕的可用性。
–汤姆
18年7月17日在12:22
@Tom，除非您编写脚本来为您处理...远程管理员的可用性并不是真正的大问题。
– schroeder♦
18年7月17日在12:25
@schroeder，您假定您总是在能使用灵巧脚本的同一台计算机上执行管理工作。在这种情况下，您不需要端口敲门，基于密钥的身份验证也将使暴力攻击变得毫无意义。
–汤姆
18年7月17日在13:17
@tom是的，我假设是这样。如果您的管理员从未知或不受控制的计算机登录，那么您还有另一个问题。您对基于密钥的评论也令人困惑：基于密钥的身份验证对于可用性很糟糕。我认为您可能需要扩大您在原始评论中的意思以及您所依据的假设。
– schroeder♦
18年7月17日在13:19
@schroeder-对的，基于密钥的身份验证在可用性上并没有改善很多，但是至少这是一个标准过程，这是正确的。我的经验表明，您的假设在99％的时间内都是正确的，而在您真正需要登录的那一次却是错误的，但是您却没有笔记本。我经常将自己拒之门外，以至于您总是需要至少一种不需要特定软件或设置的方式。
–汤姆
18年7月17日在13:25
#7 楼
就像其他人提到的那样，迁移到非标准端口不是安全的解决方案，因为您只过滤了幼稚的攻击。<br />同时，如果结合其他预防措施，迁移可能会更有价值。例如，您将蜜罐放置在标准端口上（该环境与系统的其余部分物理隔离，但对于攻击者而言似乎是合法的部分）。然后，如果您看到某人闯入了蜜罐，则很可能是黑客，因此您可以自动将其禁止。
当然，您不应使用已知漏洞的过时软件版本，无论他们绑定到监听的端口号。
评论
不要在生产服务器上运行蜜罐
– AndrolGenhald
18年7月17日在16:11
@AndrolGenhald我还是喜欢这个主意。攻击者将在任何其他端口之前尝试22，因此，如果您在其中看到的像TCP SYN一样多，则可以禁止IP地址访问任何端口（因此主机对攻击者而言将是死机）。或者，您可以将端口22上的流量代理到其他位置的蜜罐服务器。我同意在产品上使用高交互性蜜罐绝对不是一个好主意。
–吕克
18年7月17日在16:31
@AndrolGenhald，不要将裸露的生产服务器暴露给外界。然后，在与生产服务器相同的IP上具有可访问的蜜罐可能只是路由配置。
–尤里·斯卡图拉（Yury Schkatula）
18年7月17日在16:32
@Luc是的，在端口22上监听和登录可能很有用，也可以将其路由到其他位置，但是答案并不能解释任何问题。 YurySchkatula也许您应该在答案中添加它？
– AndrolGenhald
18年7月17日在16:42
@Luc听起来很不错的方法，它是禁止系统管理员在购买新计算机时忘记尝试第一次连接时更改端口的好方法。
– jpmc26
18年7月19日在12:14
#8 楼
不，不是这样，或者如果我想更精确地讲，这是对威胁的错误保护。后退一步：我们要保护的威胁是什么？我们试图保护的威胁是公共互联网上可以绕过常规身份验证机制的任何人。这就是这些“脚本小子”正在尝试做的事情：即使未经授权，也要使用SSH访问服务器。特别是，您的上级希望阻止这些攻击者甚至无法开始建立SSH连接。
什么是阻止建立网络连接的标准技术？防火墙。解决此问题的标准方法是将端口22完全阻止外部流量通过。更大的问题是SSH完全可以用于公共Internet，而防火墙完全解决了这一问题，而晦涩的端口仅将其稍微隐藏了一下，实际上并没有阻止连接。如果需要外部访问，则允许此授权访问的标准答案是进入网络的VPN。这将阻止脚本小子和知识型攻击者，他们可能会弄清楚如何找到您实际使用的端口。
如果您损失了1％的攻击者，您仍然会丢失。您需要针对100％攻击者的保护措施。相反，如果您成功地阻止了100％的攻击者（到目前为止），那么您必须拥有更强大的保护措施。这些其他保护措施使晦涩的端口变得无关紧要，如果是这样（希望如此），则使用其他端口所做的所有操作都会使像您这样对实际的安全实践不太熟悉的人们感到困惑，并且很可能会浪费时间进行尝试在他们尝试连接时获得合法访问权（未配置新系统，必须询问某人正确的端口，管理员忘记告诉该人有关非标准端口的信息，而该人必须再次打扰他们以诊断问题，等等。） />
这就是为什么我们对“默默无闻的安全性”和Kerckhoffs原则抱有偏见。我们应该避免使用无法真正保护我们的行为来分散自己的注意力。我们应该节省时间和精力来进行切实有效的保护，并避免这些混淆方法给我们带来的错误的“安全”感。
#9 楼
最后，我想补充一点，安全是一个涉及双方资源的游戏。时间就是这样的资源。这种措施浪费了攻击者的时间，所以还不错。当攻击者资源仍连接到您的自定义端口时，您还可以了解它们。也许特别有针对性地针对您。
但是，如果这给您的管理任务增加了可观的开销，您可能希望将时间花在其他地方。如果不是，那就去做，但是不要依赖它。
#10 楼
对于高度脆弱的应用程序使用非标准端口是非常好的做法。 SSH有许多漏洞，而22是暴力破解的常见默认端口。这可能取决于它。在DMZ服务器上针对端口22进行暴力攻击非常普遍，尤其是在企业环境中。例如，在金融领域，许多公司使用不同的默认端口进行SSH / SFTP通信，以在组织之间进行有效的数据传输。 >
这种情况下的想法更多地是要过滤掉一些噪声（端口22 Brute Forcing），以便更容易监视备用端口上的其他流量。任何有能力的人都可以在面向Internet的服务器上找到任何开放端口。
这被认为是减轻风险或降低风险的一种形式。说好的做法，我指的是面向互联网的设备上的好的做法。防火墙后面的任何东西通常都是安全的。
评论
我不会说openssh有很多漏洞。许多已报告的问题可能允许经过身份验证的用户获得特权，但这不同于远程攻击者获得访问权限...
–vidarlo
18年7月17日在4:35
将前门钥匙隐藏在垫子下面不是很好的做法。是的，这比将钥匙留在锁中要好，但并没有更好。更好的主意是减轻漏洞，而不是隐藏漏洞。
– schroeder♦
18年7月17日在12:27
评论
没有模糊的安全感。只有默默无闻。这项原则是数十年前确立的。在我看来，减少日志文件中的垃圾是一项安全功能，因为这意味着您可以将更多精力放在实际问题上。
通过默默无闻来实现安全性并不是天生就坏，仅依靠它就可以了。模糊性可以提供的微不足道的好处无法替代真正的安全性，但可以附加使用。晦涩的缺点是通常给授权用户增加不便（必须记住与规范的偏差），安全性通常是在限制未授权用户而不妨碍授权用户过多之间建立平衡。
这完全取决于您正在考虑的攻击媒介。如果您想逃避人们随便扫描22端口端口的网络，那么可以，但是，如果您想防御有人攻击您的主机，就可以了。
我在树莓派上运行ssh服务器，可以从Internet访问它。当我在端口22上运行ssh时，10 MB的ramdisk日志分区已在数小时内变满-都是由于登录尝试记录。将ssh移至高端口后，六个月来我没有一次未经授权的访问尝试。对我来说，这是一个好处。