run*_*ako 72 ssh port blocking
我是一名程序员，我为一些客户工作过，他们的网络阻止了端口 22 上的传出连接。考虑到程序员经常需要使用端口 22 进行 ssh，这似乎是一个适得其反的过程。充其量，它迫使程序员向公司收取 3G 互联网费用。在最坏的情况下，这意味着他们无法有效地完成工作。
鉴于这造成的困难，有经验的系统管理员能否解释一下看似双输的行动的预期好处？
Jam*_*s F 80
我没有看到有人详细说明了 SSH 端口转发的具体风险。
如果您在防火墙内并且可以通过 SSH 出站访问公共互联网上的一台机器，您可以通过 SSH 连接到该公共系统，并在此过程中创建一个隧道，以便公共互联网上的人们可以完全通过 SSH 连接到您网络内的系统绕过防火墙。
如果 fred 是您的桌面，而 barney 是您公司的重要服务器，并且 wilma 是公开的，则运行（在 fred 上）：
ssh -R*:9000:barney:22 威尔玛
登录后，攻击者可以通过 ssh 连接到 wilma 上的 9000 端口，并与 barney 的 SSH 守护进程对话。
您的防火墙永远不会将其视为传入连接，因为数据是通过最初在传出方向上建立的连接传递的。
这很烦人，但完全合法的网络安全策略。
Rob*_*oir 38
如果他们阻止了混杂的端口，让一些东西通过并随机阻止一些其他东西（我喜欢 Paul Tomblin 的关于阻止 SSH 并允许 Telnet 的人的悲伤故事）那么他们要么有一个非常奇怪的边缘案例继续保护他们的网络边界，或者他们的安全策略，至少从外部来看，显然是经过深思熟虑的。您无法理解这样的情况，因此只需向他们收取痛苦并继续您的一天的现行费率即可。
如果他们阻止所有端口，除非有一个特定的商业案例允许流量通过该端口，此时他们会仔细管理，那么他们正在这样做，因为他们能胜任他们的工作。
当您尝试编写一个安全的应用程序时，您是否让其他进程可以轻松地随意读取和写入信息，或者您是否有一些精心记录的 API，您希望人们调用它们并仔细清理它们？
风险管理 - 如果您认为进出 Internet 的网络流量存在风险，那么您希望在路由数量和方法数量方面最大限度地减少流量到达 Internet 的方式。然后，您可以监视和过滤这些选定的“祝福”网关和端口，以尝试确保通过它们的流量符合您的预期。
这是一个“默认拒绝”防火墙策略，通常被认为是一个好主意，但我会提出一些警告。它的意思是，除非有特定的理由解除封锁，否则一切都会被封锁，而且这个理由的好处大于风险。
编辑：我应该澄清一下，我不只是在谈论允许一个协议而另一个被阻止的风险，我在谈论允许信息在不受控制的情况下流入或流出网络的业务的潜在风险道路。
现在是警告，可能还有一个释放事物的计划：
当您被某些事情拒之门外时可能会很烦人，这就是您发现自己与某些客户的处境。很多时候，防火墙的负责人认为他们的工作是说“不”，而不是“这是风险，现在有什么好处，让我们看看我们能做什么”。
如果您与为您的客户管理网络安全的人交谈，他们可能愿意为您设置一些东西。如果您可以在其末端确定一些您需要访问的特定系统，和/或保证您只会从特定 IP 地址进行连接，那么他们可能会更乐意为这些特定条件为 SSH 连接创建防火墙例外，而不是他们将只是打开与整个互联网的连接。或者他们可能有一个 VPN 设施，您可以用来通过防火墙建立隧道。
Pau*_*lin 18
纽约州罗彻斯特的某家大公司曾经拍过很多电影，我在那里工作时阻止了传出的 ssh，但允许telnet！当我问起时，他们说 ssh 是一个安全漏洞。
换句话说，公司有时会做出愚蠢的决定，然后就安全问题编造胡言乱语的借口，而不是承认自己的错误。
如果公司不允许外部登录，我可以理解阻止入站 SSH 通信。但是，这是我第一次听说出站 SSH 阻止。
需要注意的是，这种防火墙可能只会限制临时 SSH 用户。如果有人真的想在外部使用 SSH（通常是在企业网络之外他们可以访问的服务器/机器），他们可以轻松地在 22 以外的端口（例如端口 80）上运行 SSH 服务器。该块将很容易被绕过。
还有一些公共域工具可让您通过 HTTP（端口 80 或 HTTPS 端口 443）退出企业，并提供代理以让您连接到外部的端口 22。
编辑：好的，等一下，我知道为什么这可能是一项政策。
有时，人们使用 SSH 隧道来绕过基本的出站防火墙，用于 IM 和 Bittorrent 等协议（例如）。这 // 可能 // 触发了这样的策略。但是，我仍然觉得这些隧道工具中的大多数都可以在 22 以外的端口上工作。
阻止此类出站隧道的唯一方法是动态检测 SSH 通信并（动态）阻止这些 TCP 连接。
这可能是监管/合规问题。您的雇主希望能够读取/存档所有通信。这通常是银行等行业的要求。