使用晦涩的端口号会提高安全性吗？

如果您已经在使用高熵密码或公钥身份验证，答案是“不是真的”。大多数情况下，您只是在消除日志中的噪音。

我担心偏离这些建议会带来意想不到的后果。

这取决于选择的端口。在 Linux 中，默认情况下，低于 1024 的所有端口都需要 root 访问权限才能监听它们。如果您使用 1024 以上的端口，则任何用户帐户都可以在没有进程监听的情况下监听它。

为什么这很重要？假设您选择将 ssh 设置为绑定到 port 20,000。如果有人可以停止服务器上的 SSH 进程（假设他们以某种方式找到了使进程崩溃的方法），并且可以本地访问该服务器，那么他们可以20,000在服务重新启动之前在端口上运行自己的 SSH 服务器。任何登录的人都将登录到坏人 SSH 服务器。

这不像以前那么重要了，因为现在只有值得信赖的 IT 员工才能获得服务器的登录访问权限。但是，如果攻击者在您的服务器上站稳脚跟，它确实有可能导致特权升级和其他令人讨厌的事情。

除了低于 1024 之外，数字 22 没有什么特别之处。之所以选择它，主要是因为 SSH 是 telnet 在 port 的替代品23，并且21已经被 FTP 采用。只要您在下面选择一个端口1024，该端口就无关紧要。

这是好习惯吗？我们应该使用众所周知的端口吗？

我不会说我推荐它。我也不建议反对它。正如我所说，它避免了日志文件中的大量噪音，但好处很大程度上仅限于此。

对于任何对 SSH 的背景故事感兴趣的人，您可以在以下网址找到它：https ://www.ssh.com/ssh/port

是的，它确实。真正的问题是：多少？

为什么会这样？您已经拥有基本的安全性，因此日常机器人攻击不必担心。但是明天可能是 0-day，攻击者知道很快就会有补丁发布，所以他们争先恐后地使用它，不会为复杂的事情烦恼——他们只会攻击尽可能多的机器标准端口。任何一种理论上的 SSH 蠕虫也会使用这种策略。你会受到保护。

这会给您带来多少额外的安全保障？它可以防止这种情况以及 2-3 种其他特定情况。对于任何不是完全白痴的人的任何有针对性的攻击，它最多只会增加几分钟。它对您已经受到充分保护的场景没有任何作用。

将这些数字插入您最喜欢的风险分析方法中，您应该会想出一些相对较小的东西。不利的一面是，您需要付出额外的努力来设置非标准端口号，记录它，在故障排除期间可能会丢失它并浪费一些时间等。

我的猜测是，您只需进行分析即可收支平衡。或者，换句话说：是的，它确实提高了安全性，但不值得麻烦，因为改进非常小。

不，它不会提高安全性。它可以减少日志混乱，因为自动攻击只会尝试默认端口，例如 ssh。但在端口扫描和shodan.io中，该端口仍会显示为 SSH 。

这些自动攻击通常针对容易实现的目标，使用标准用户名（如 root、smith 等）和弱密码。如果他们成功了，那么你首先就会遇到问题。

如果您将 ssh 配置为仅允许密钥身份验证、禁止 root 登录并使用合理密码、使用 fail2ban 或类似机制来阻止违规者，它们就不是真正的威胁。

我使用 fail2ban 配置为在 3 次尝试失败后暂时阻止五分钟，在 3*5 次尝试失败后暂时阻止一周。这减少了日志混乱并阻止了暴力攻击的任何实际进展。

对于有针对性的攻击者来说，监听哪个端口没有区别。只有在我看来，风险可以忽略不计的自动化攻击才重要。

更改默认端口可以使您免于端口扫描和脚本小子，但您可能无法抵御目标攻击，攻击者可以识别与端口无关的正在运行的服务。

如果您只想摆脱脚本小子，这可能会有所帮助，但您可能无法保护自己免受其他高级攻击。

我的建议是使用默认端口（可能会减少您的管理开销）并部署多方面的安全防御来缓解攻击。

例如，在使用默认端口的情况下，仅允许某些受信任的来源使用 SSH 部署基于证书的身份验证。