我并不完全相信这样做可以提高安全性，因为
存在端口扫描器
如果应用程序易受攻击，无论端口号如何，它都将保持不变。
我错过了什么还是回答了自己的问题？
#1 楼
它没有针对目标攻击提供任何严肃的防御。如您所说，如果将服务器作为目标服务器，则它们将对您进行端口扫描，并找出您的门在哪里。但是，将SSH移离默认端口22会阻止一些非针对性和业余脚本的儿童类型攻击。这些是相对不老练的用户，他们使用脚本一次扫描端口较大的IP地址，以专门查看端口22是否打开，并在发现端口22时对它们发起某种攻击（强力攻击，字典攻击，等等）。如果您的计算机位于要扫描的IP块中，并且未在端口22上运行SSH，则它不会响应，因此不会在计算机列表中显示此脚本小家伙来攻击。因此，提供了一些低级安全性，但仅针对这种机会性攻击。
例如，如果您有时间，请在服务器上进行日志潜水（假设SSH在端口22上） ），然后抽出所有唯一的失败SSH尝试。然后将SSH移出该端口，等待一段时间，然后再次进行日志潜水。毫无疑问，您将发现更少的攻击。<br />
我曾经在公共Web服务器上运行Fail2Ban，当我将SSH从端口22移开时，这确实非常明显。这将机会攻击降低了几个数量级。 br />
评论
同意在尝试将SSH移至非标准端口时，我看到了非常相似的下降。幸运的是，禁用了密码身份验证，这确实不是问题。
–EEAA
2011年9月28日在20:10
到目前为止最好的答案。这一切都取决于谁在攻击。我曾经帮助管理一个系统，该系统遭到了扫描小家伙的零日攻击。大概在MS-RDP中，因为防火墙没有暴露IIS。我们的主机不允许我们更改RDP端口（托管主机），因此当他们为IDS / IPS过滤建立新模式时，我们基本上不得不坐在那里。尽管对于像SSH这样的较成熟的服务器，其安全性问题似乎不如某些MS产品好，但可能没有太大帮助。
–马特·莫尔纳（Matt Molnar）
2011年9月28日在20:18
绝对同意。安全是所有关于层的问题，拥有的层越多，安全性就越高。这可能是一个薄弱的层，但仍然是一层。只要不仅仅依赖它，它就只能增加安全性。
– Paul Kroon
2011年9月29日，1：11
将SSH移出端口22的另一点是，大量的SSH尝试加服务，因为Fail2Ban有时可能会占用宝贵的CPU时间。在顶级硬件上，它可以忽略不计，但是某些较旧的服务器可能会遇到CPU峰值的情况。它的CPU时间，内存和带宽可用于其他用途。
– artifex
2011-09-29 17:54
我在Server 2003上对RDP进行了相同的操作-它大大减少了事件查看器中失败的身份验证条目的数量。
– Moshe
13年1月17日在7:25
#2 楼
保持日志清洁非常有帮助。如果您看到在端口33201上运行sshd的尝试失败，则可以放心地认为此人是您的目标，并且您可以选择采取适当的措施。例如，与当局联系，调查此人可能是谁（通过交叉引用您注册用户的IP或其他名称）等。
如果您使用默认端口，则它将无法知道有人在攻击您还是只是白痴在随机扫描。
评论
出色的区别
– ZJR
2011年9月29日下午2:00
+1这是更改我从未听说过的端口号的最佳论据，到目前为止，这是唯一诱使我这样做的方法
–squillman
2011-09-29 23:29
+1这很重要。有针对性的威胁比随机探测要危险得多（如果您有任何不错的安全性，脚本小子就会转移到更容易的目标上）。目标攻击者可能对特定漏洞甚至密码模式了解更多。能够在端口22的垃圾邮件群之外识别出这些攻击是很好的。
–史蒂文·斯奈德（Steven T. Snyder）
2011-09-30 17:12
这是错误的。我已经看到至少一台服务器通过对非标准SSH端口的扫描而受到损害。没有内在的原因使攻击者也无法扫描其他端口。
– Sven Slootweg
15年7月2日在9:54
@SvenSlootweg，是的，尤其是在计算机变得越来越快，越来越便宜的情况下，扫描花费了65535倍的时间再也不能了。
–起搏器
16年2月8日在4:25
#3 楼
不，不是。并不是的。术语是“默默无闻的安全”，这不是可靠的做法。在这两点上您都是正确的。Obscurity的安全性充其量只能阻止发现默认端口的偶然尝试，因为他们知道在某个时候他们会发现有人打开了前门。但是，如果您面临任何严重威胁，则更改保管箱端口最多只会减慢最初的攻击速度，但是由于您已经指出的情况，这样做的幅度很小。
做自己帮忙，并正确配置您的端口，但要采取适当的预防措施，使用适当的防火墙，授权，ACL等将其锁定。
评论
以我自己的拙见，将（强）密码和加密投影到安全性的想法有点捉襟见肘。
–squillman
2011-09-28 19:26
仅使用8个字符以及全部字母和数字字符（甚至不允许使用特殊字符），可能的组合数为62 ^ 8（218,340,105,584,896）。即使使用端口扫描检测器，65535也不是在同一宇宙中。注意，我不推荐弱密码。
–squillman
2011-09-28 19:52
同样，“这不是说非标准端口就是整个安全设备”。一点点帮助。这是一个10秒钟的调整，如果没有其他问题，它将阻止您的服务器出现在寻找SSH的人面前。
–ceejayoz
2011-09-28 23:12
嗯在我的书中，跟踪非标准端口是不值得的。我会不同意任何人的看法……除了改变端口之外，增加其他对策当然是其中的一部分，我宁愿把事情留给那些难题。
–squillman
2011-09-28 23:42
从我所看到的来看，非标准端口已经变得相当标准。 ssh为2222，HTTP为1080、8080、81、82、8088。否则，它将变得晦涩难懂，您想知道端口7201上有什么服务，以及为什么您无法连接到7102上的ssh。
–BillThor
2011-09-29 0:17
#4 楼
这只是一个微不足道的水平，但在黑客入侵的道路上并不是一个明显的速度颠簸。这是一个难以长期支持的配置，因为必须告知与该特定服务有关的所有信息。从前，避免网络蠕虫是一个好主意，因为这些蠕虫只扫描一个端口。但是，蠕虫迅速繁殖的时代已经过去。
评论
+1解决更困难的配置和支持问题。让您浪费时间来保护门（而不是去搜索房屋的位置）。
– Macke
2011-09-29 6:55
#5 楼
正如其他人指出的那样，更改端口号不能为您提供太多安全性。我想补充一点，更改端口号实际上可能对您的安全性有害。
想象一下以下简化方案。破解程序扫描100台主机。这些主机中有九十九个在这些标准端口上提供了服务：
Port Service
22 SSH
80 HTTP
443 HTTPS
但是有一个主机在人群中脱颖而出，因为它们是系统所有者尝试的。来混淆他们的服务。
Port Service
2222 SSH
10080 HTTP
10443 HTTPS
现在，这对于破解者来说可能很有趣，因为该扫描显示了两件事：
主机的所有者正在尝试隐藏其系统上的端口号。所有者可能认为系统上有有价值的东西。这可能不是行之有效的系统。
他们选择了错误的方法来保护其系统。管理员由于认为端口混淆而犯了一个错误，这表明他们可能是经验不足的管理员。也许他们使用端口混淆来代替适当的防火墙或适当的IDS。他们可能还会犯其他安全错误，并且可能容易遭受其他安全攻击。现在让我们进一步探讨吧？
如果您是一名黑客，您会选择查看在标准端口上运行标准服务的99台主机之一，还是这台主机？使用端口混淆？
评论
除非经验告诉我，否则我将查看99位主持人。如果您问我，那些正在四处移动端口的人可能更容易打补丁和保护自己。
–ceejayoz
2011-09-28 23:14
我会看一下脱颖而出的1台主机，这时有些PFY认为“如果更改端口号，我就无敌了！”。但已将root密码设置为“ password”。
–安德鲁（Andrew）
2011年9月29日，下午1:53
@Ceejayoz，完全同意。我在2222上运行SSH，没有安全性，但是减少了脚本小子。我认为他们也更可能忽略我，不愿更改端口，也可能采取了其他措施。显然，这不是所有的默认配置...
–克里斯S
2011-09-29 2:44
我了解并非所有人都同意我的观点。但是根据我的经验，有很多系统所有者会使用端口混淆功能，但是他们会犯一些错误，例如在暴露了一些关键的安全漏洞后不更新OpenSSH，或者会使用共享大学系统中未加密的SSH密钥，等等。这些系统是多汁的目标。
– Stefan Lasiewski
2011年9月30日在16:53
通过扩展：转移到非标准端口，您更有可能不鼓励脚本小子，但也更有可能引起有经验的黑客的兴趣。哪个提出了问题：您更害怕针对哪个目标？
– tardate
2011年10月1日，下午4:36
#6 楼
我将至少部分地与大趋势背道而驰。就其本身而言，更改为其他端口可能会在搜索时使您花费几秒钟的时间，因此实际上并不会给您带来任何好处条款。但是，如果将非标准端口与反端口扫描措施结合使用，则可以真正提高安全性。
在我的系统中存在以下情况：非公共服务在非标准端口上运行。在指定的时间内，尝试从单个源地址到两个以上端口的任何连接尝试（无论成功与否）都会导致来自该源的所有流量都被丢弃。
要击败该系统，需要运气（在被阻止之前击中正确的端口）或分布式扫描（这会触发其他措施），或者时间很长，也会引起注意并采取措施。
评论
结合Andreas Bonini关于有针对性的攻击的观点，这是使用备用端口的有力论据。
– JivanAmara
2014年11月6日19:42
#7 楼
我认为移动应用程序运行的端口根本不会增加安全性-仅仅是因为同一应用程序仅在不同的端口上运行（具有相同的优点和缺点）。如果您的应用程序存在漏洞，则将其侦听的端口移动到另一个端口将无法解决该漏洞。更糟的是，它会积极鼓励您不要解决该弱点，因为现在它不会一直被自动扫描不断加重。它隐藏了真正的问题，它是应该实际解决的问题。一些示例：
“它清理日志”-然后您有一个您如何处理日志的问题。
“减少连接开销”-开销很小（与大多数扫描一样），或者您需要在上游完成某种过滤/拒绝服务缓解操作
“减少应用程序的暴露”-如果您的应用程序无法经受自动扫描和利用，那么您的应用程序存在严重的安全缺陷需要解决（即，对其进行修补！）。
真正的问题是管理上的：人们期望SSH为22，MSSQL为1433，依此类推。解决这些问题又是一层复杂性和所需的文档。坐在一个网络上，不得不使用nmap只是想弄清楚事情已经转移到哪里，这很烦人。安全性充其量只是短暂的，缺点也不是很小的。不要这样解决实际问题。
#8 楼
您是正确的，它不会带来太多的安全性（因为TCP服务器端口范围只有16位熵），但是您可能由于其他两个原因而这样做：已经说过：尝试多次登录的入侵者可能会使您的日志文件混乱（即使使用fail2ban可以阻止来自单个IP的字典攻击）；
SSH需要使用公钥加密来交换秘密密钥以创建安全隧道（这是一个在正常情况下不需要经常进行的昂贵的操作）；重复的SSH连接可能会浪费CPU能力。
备注：我并不是说您应该更改服务器端口。我只是在描述更改端口号的合理原因（IMO）。
如果这样做，我认为您需要向其他所有管理员或用户明确指出，这不应被视为安全功能，并且所使用的端口号甚至都不是秘密，并且将其描述为带来真正安全性的安全功能并不被视为可接受的行为。
评论
日志文件可以使用适当的过滤器轻松整理。如果您在谈论由于日志减少而导致的服务器性能，那么我们不再在谈论安全性。性能完全是一个完全不同的主题。
–起搏器
16-2-8在5:43
当由于磁盘使用过多而导致计算机无法使用时，不是这样。
–好奇
16年2月8日在9:07
是的，这是一个性能问题。性能当然也很重要，但是这个特定线程仅专门讨论安全性。 （出于该线程的目的，请想象您是Google大小的，而Google实际上确实希望这些数据用于分析和/或销售目的。）
–起搏器
16-2-8在15:47
#9 楼
我可以看到一种假设情况，即在备用端口上运行sshd可能会带来安全方面的好处。在这种情况下，您正在运行的sshd软件中发现了一个被利用的远程漏洞。在这种情况下，在备用端口上运行sshd可能会给您带来额外的时间，而您不必成为随机的随身目标。我自己在其他端口上运行sshd私人计算机，但这主要是为了方便/var/log/auth.log中的混乱。在多用户系统上，我真的不认为上面介绍的假设的小安全好处是没有在标准部件上发现sshd引起额外麻烦的充分原因。
评论
该方案只有在所有管理员绝对没有在此“额外时间”上共进午餐等方面留有余地的情况下才有效。
–起搏器
16-2-8在5:49
#10 楼
它稍微增加了安全性。攻击者发现开放端口后，现在必须找出端口上正在运行的内容。无法访问您的配置文件（尚未:-)），他不知道端口12345是否正在运行http，sshd或其他一千种常用服务之一，因此它们需要做一些额外的工作来弄清楚正在运行的内容，然后才能认真对待。攻击它。正如其他发布者所指出的那样，尝试登录端口22可能是无知的脚本小子，僵尸木马，甚至是输入IP地址错误的真正用户。几乎可以肯定，尝试登录端口12345要么是真实用户，要么是严重的攻击者。
另一种策略是拥有一些“蜂蜜陷阱”端口。由于没有真正的用户会知道，那么这些端口号的任何连接尝试必须被视为恶意，你可以阻止/自动报告违规IP地址。
有一种情况使用不同的端口号的特殊情况绝对可以使您的系统更安全。如果您的网络运行的是诸如Web服务器之类的公共服务，而且还运行内部仅供内部使用的Web服务器，则可以通过在其他端口号上运行并从该端口阻止任何外部访问来绝对阻止任何外部访问。
评论
必须权衡〜0.1％的安全性增长与相关的安全性下降之间的权衡，这可能会导致安全性总净损失，具体取决于用例和上下文。
–起搏器
16-2-8在5:54
评论
我做的一件事是使用某些默认端口（例如SSH端口22）作为蜜罐。尝试连接到这些端口的任何人都会被完全阻止x倍的时间。它被证明对端口扫描有效。当然，这只是安全性工具箱中的一种工具。有关通过模糊性实现安全性的一般问题在这里提出：security.stackexchange.com/questions/2430/…
好吧，这可能是“给孩子写脚本的障碍”
@BelminFernandez，“安全工具箱中的一个工具”吗？不，这是为了减少服务器负载（性能），并且与安全无关，仅是虚假的。从安全角度考虑，如果服务器已经很强大，则完全没有必要；如果服务器容易受到攻击，也就无法使其变得更加安全。
@Pacerier，同意将工作重点放在实施更可靠的安全实践上。但是，没有理由不能同时使用两者。