鉴于由此带来的困难,有经验的系统管理员能否请您解释一下似乎输得不好的行为所期望的收益?
#1 楼
我看不到有人详细说明了SSH端口转发的特定风险。到该公共系统,并在此过程中创建一个隧道,以便公共Internet上的人们可以SSH进入网络内部的系统,完全绕过防火墙。公司和wilma的服务器是公开的,正在运行(在fred上):ssh -R *:9000:barney:22 wilma
并登录会让攻击者ssh到wilma上的9000端口并与barney的SSH守护程序进行对话。
您的防火墙永远不会将其视为传入连接,因为数据正在通过最初在传出方向上建立的连接进行传递。 >
很烦人,但是是完全合法的网络安全策略。
评论
感谢您的深刻见解。这是针对开放出口港口的技术风险(相对于政治风险)的为数不多的应对措施之一。
– runako
09年6月15日在1:31
+1是出于充分的技术理由。 (但是,这只能由恶意的实习生完成,该实习生还可以使用远程主机上除TCP 22之外的其他端口。借助该端口,我们可以阻止所有策略)
–DerMike
2011年1月5日,12:52
使用自定义的定制协议和一些巧妙的代理编程,可以通过HTTPS完成此操作-尽管速度较慢。只要允许出站加密流量,就很容易受到这种“攻击”。
– Michael Sondergaard
2011年7月7日在18:52
这是JamesF的一个很好的响应,但不是一个值得考虑的安全性问题,因为它假定了极为罕见的情况,并且需要利用SSH服务器/客户端。恶意用户必须首先利用SSH服务器(在您的台式机上),然后找出一种方法来利用SSH客户端(在企业主机上)。由于您无法使用端口22来访问或与防火墙企业主机通信(该主机只有传出端口22)。如果您的安全标准如此之高,则在任何情况下您的企业主机都不应该在Internet上。
– exter
13年5月15日在15:56
如果HTTPS和SSH不可用,则可以通过DNS(例如,使用碘)建立隧道流量。但这很慢。
– Mark K Cowan
16-10-11在15:35
#2 楼
如果他们阻止了端口的杂乱无章,让某些内容通过并随机阻止了其他内容(我喜欢Paul Tomblin关于阻止SSH并允许Telnet的人们的可悲故事),那么他们要么对他们的方式有一个非常奇怪的边缘案例至少要保护他们的网络外围安全,或者至少从外面看,他们的安全策略显然没有经过深思熟虑。您无法理解这种情况,因此只向他们收取痛苦者的费用,并随您的生活继续下去。如果他们阻塞所有端口,除非有特定业务允许通过该端口的流量,此时要对其进行仔细的管理,然后才这样做,因为他们能胜任工作。
当您尝试编写一个安全的应用程序时,您是否愿意让其他进程轻松地向其读取和写入信息,或者您是否拥有一些经过精心记录的API,希望人们能够这样做?
风险管理-如果您认为进出网络的流量存在互联网风险,请尽量减少流量可以到达Internet的方式,无论是路线数量还是方法数量。然后,您可以监视和筛选这些选定的“祝福”网关和端口,以尝试确保通过它们的流量符合您的期望。
这是一个“默认拒绝”防火墙策略,通常被认为是一个好主意,我将提出一些警告。它的意思是除非有特定的原因需要取消阻止,否则所有内容都将被阻止,并且该原因的好处大于风险。
编辑:我应该澄清一下,我不仅在谈论一个协议被允许而另一个协议被阻止的风险,我说的是允许信息业务以不受控制的方式流入或流出网络的潜在风险。
现在需要注意的是,也许还有一个释放东西的计划:
当您被某些东西拒之门外时,这可能会很烦人,这是您与某些客户所处的位置。
防火墙负责人常常以为“不”而不是“这里有风险,现在有什么好处,让我们看看能做什么”。 >
如果您与负责为客户管理网络安全的人员交谈,他们可能会为您设置一些内容。如果您可以在它们的末端识别出一些特定的系统,则您需要访问它们,并且/或者保证仅从特定的IP地址进行连接,因此,对于这些特定条件的SSH连接而言,为它们创建防火墙例外可能比它们更快乐。就是开放与整个互联网的连接。或者他们可能具有可用于穿越防火墙的VPN工具。
评论
对于+1,如果他们阻止所有端口,除非有特定的业务案例允许通过该端口的流量,此时要对其进行精心管理,则他们会这样做,因为他们能胜任其工作。
–cop1152
09年6月15日在3:42
-1,因为安全人员无法监视ssh,但Telnet可以。我的观点是,尽管存在愚蠢的网络安全策略,但在不了解实际业务需求的情况下,将策略描述为“随机”和“ whackjob”也是很短暂的。
–血腥
09年6月15日在5:34
恩,您当然有权获得您的意见,埃里克(Eric)当然,如果您觉得这些词具有贬义性,我会很乐意更改这些词,但我相当有信心认为,这样的政策可能会被深思熟虑或非常不寻常。
–罗布·莫尔
09年6月15日在12:52
为“所有端口” +1
–伊恩·博伊德(Ian Boyd)
09年6月15日在14:29
#3 楼
我在纽约州罗切斯特市的一家大型公司曾经制作过很多电影,但我在那儿工作时却阻止了传出的ssh,但允许telnet!当我问到这个问题时,他们说ssh是一个安全漏洞。 >评论
TELNET是安全漏洞。应该禁止它(这只是为了将来人们做出更好的愚蠢决定)。
– nik
09年6月14日在17:42
让我在这里详细说明一下,什么是安全孔取决于要固定的表面。如果您是网站所有者,尝试连接到服务器,则TELNET是一个漏洞。如果您是一家金融公司的员工,试图通过外部连接到您的家庭服务器(受雇主监控的线路),则SSH是雇主的安全漏洞!
– nik
09年6月14日在17:46
考虑到双向欺骗telnet是多么容易,我想说telnet即使对于允许其传播的公司来说也是一个安全漏洞。但是,允许但不允许ssh的公司在任何情况下都不会做出明智的安全决策。
– Paul Tomblin
09年6月14日在17:51
Telnet是不断赠送的礼物。 20年前还可以,但现在我真的希望它会停止。
–罗布·莫尔
09年6月14日在18:06
这一切都取决于您的POV。他们可能有需要通过Telnet访问某些旧进程的人员,我们可以轻松对其进行审核。 OTOH,您不知道SSH发生了什么,人们可以建立到外部网络的隧道并做各种愚蠢的事情。这些天不应该使用Telnet,但是任何允许传出SSH的人都需要寻求新的职业。
–duffbeer703
09年6月15日,0:16
#4 楼
如果公司不允许外部登录,我可以理解阻止入站SSH通信。但是,这是我第一次听到出站SSH阻止。需要注意的重要一点是,这种防火墙可能只会限制临时SSH用户。如果某人真的想在企业网络外部进行SSH SSH(通常是到他们具有重要访问权限的服务器/机器),他们可以轻松地在22以外的端口(例如端口80)上运行SSH服务器。该块将很容易被绕过。
还有一些公共域工具,这些工具可使您通过HTTP(端口80或HTTPS端口443)退出企业,并提供代理以使您可以连接到外部的端口22 。
编辑:好的,请稍等,我知道为什么这可能是一项政策。
有时,人们使用SSH隧道绕过基本出站用于IM和Bittorrent等协议的防火墙。 // //可能触发了这样的策略。但是,我仍然觉得大多数这些隧道工具都可以在22以外的端口上运行。
可以阻止此类出站隧道的唯一方法是通过动态检测SSH通信,并且(动态地) )阻止这些TCP连接。
评论
端口443更好,因为已经假定它已加密,因此代理不会对奇怪的数据感到不安。您可以轻松地设置侦听端口443的ssh服务器,并且从那里可以到任何地方。
– Bandi
09年6月14日在18:08
在我工作过的地方,我的一位同事使用了一个程序,该程序通过ssh隧道将所有网络流量通过我们的Web代理传输到他家用计算机上的端口80,然后从那里传输到Internet。他可以使用他想要的任何协议,但看起来好像是从他家而不是公司来的。幸运的是,他知道网络管理员的无能为力,因此他不会冒被捕获的风险。
– Paul Tomblin
09年6月14日在18:44
当然,如果您确实经历了这些精心设计的舞蹈之一来绕过防火墙,那么您将无法真正诉诸无罪和无知。很难做到所有这些,然后说“对不起老板,这很奏效,所以我没有意识到自己做错了什么。”
–罗布·莫尔
09年6月14日在19:22
#5 楼
这可能是监管/合规性问题。您的雇主希望能够阅读/存档所有通信。这在银行等行业中经常是必需的。评论
这是否意味着它们也必须阻止HTTPS?
– runako
09年6月15日在1:29
不,它们启用SSL检查。此过程将解密HTTPS,然后通过按组策略在所有工作站中注入受信任的证书来对入/出数据包进行重新加密。这样,他们可以过滤/扫描与HTTP相同的内容。银行业是锁定网络的最严酷的环境之一。
–spoulson
09年6月15日在13:04
#6 楼
我认为阻止出站端口22的主要原因有两个。首先,正如人们所提到的,SSH端口转发可以用作代理或绕过其他端口和服务以避免IT策略。
其次,许多恶意软件/僵尸网络将使用端口22,因为它通常被视为“安全”端口,因此被允许。然后,他们可以从该端口启动进程,并且受感染的计算机也可能启动SSH蛮力攻击。
#7 楼
通常,除非有必要,否则通常是阻塞所有传出连接的情况,直到您尝试没人要求端口22可用于传出连接(仅80、433等)。如果是这种情况,那么解决方案可能很简单,只需联系IS / IT并告诉他们为什么需要添加例外,以便您的工作站可以建立到特定主机或一般主机的SSH连接。有时人们担心,人们可能会使用该工具将SSH用作设置代理(通过链接上的端口转发)来绕过其他控件的一种方式。在某些受管制的行业(例如银行)中,这可能是非常重要的因素,在这些行业中,出于法律原因(禁止内幕交易,检测/阻止公司或个人数据的传输等)或需要监视/记录所有通信的公司非常担心内部泄漏会意外或以其他方式泄露商业机密。在这些情况下,使用您的3G链接(或其他技术(例如尝试通过HTTP隧道SSH))来规避这些限制可能会违反您的合同,因此会被解雇(或更可能是法律罪行),因此请务必谨慎
另一个原因可能是,如果有一些意外的事情设法减少了传出的占用空间(减少了公司防火墙内的主机可以访问的内部服务以及整个世界的内部服务)本身安装在公司运行的机器上。如果在端口22上无法建立SSH连接,则许多尝试使用蛮力SSH登录名的更简单的黑客会阻止其传播路径之一。在这种情况下,您可以再次要求添加一个例外,以便您的计算机可以建立SSH连接,前提是这些连接对于控制防火墙的人员是合理的。
评论
是的,很有可能所有不需要使用的出站服务都已被阻止(默认情况下)。
– nik
09年6月14日在17:51
但是,阻止tcp / 22不会阻止安全的出站通信(只要用户在外部有侦听器,就可以在任何端口上进行通信,这在当今并不困难)。
– nik
09年6月14日在17:51
如果内部网络已用于SSH通信,则阻止它将不起作用,并且如果不需要SSH通信,通常网络内也将没有易受攻击的SSH侦听机。而且,典型的蠕虫传播不会尝试强行使用SSH(如果您担心在en.wikipedia.org/wiki/SSHBlock上看到的内容),则更有可能在Windows计算机上尝试tcp / 445。
– nik
09年6月14日在17:55
#8 楼
您的客户可能拥有他们想要保留的重要数据。对整个网络开放的出站SSH确实是一件坏事。绕过代理,泄漏敏感数据并且通常令人讨厌是很琐碎的事情。IMO,通过网络/互联网外围的任何事物都应该被理解和控制。如果一组开发人员需要通过ssh访问托管服务提供商处的服务器,那就很好-但也需要记录在案。通常,在我工作过的地方,我们建立了到网络外部的专用站点到站点VPN连接(实质上是扩展内部网络),并避免了Internet上的SSH等客户端协议。
评论
感谢你的回答。您如何处理到您控制范围之外的站点(例如EC2,Web主机等)的专用VPN?这些供应商通常是愿意为您完成此自定义设置,还是通常需要在业务方面做出一些大的最低承诺才能使他们这样做?
– runako
09年6月15日在1:33
另外,您是否担心会强迫人们使用网外3G卡来完成工作?以我的经验,锁定的网络不可避免地会导致大量3G卡和其他隐藏的规避措施,因为如果有人不得不知道IT审批人的使用,人们就无法在指定的时间内完成工作。打电话获得例外。 (一个令人震惊的案例包括一个不接受来自Internet的传入附件的邮件服务器。Yikes!)我很好奇您如何管理这种平衡。
– runako
09年6月15日在1:40
添加有关通过ssh进行端口转发的评论,我认为这是对该问题的正确答案。 ssh可能是通过代理服务器允许的良好协议。管理员可以监视发生的情况,可以阻止端口转发,人们可以将其用于远程Shell和远程复制服务。
–血腥
09年6月15日在5:39
我们足够大,以至于我们90%的服务都不需要运行出站管理。通常,当我们这样做时,我们会将专用VPN隧道作为RFP的要求,这往往会消除不愿意或不能提供它的供应商。因此,我相信使用3G和类似解决方法的人数很少。
–duffbeer703
09年6月15日在12:33
另外,您不能让安全人员指示访问权限。您可以让应用程序支持和网络人员制定出可接受的解决方案,并接受安全性审查。在流程的早期(而不是早上投入生产)制定解决方案。但是,这使您避免了DMV样式的延迟获取请求。
–duffbeer703
09年6月15日在12:35
#9 楼
因为SSH可以用作VPN。它是经过加密的,因此网络管理员几乎不知道将要离开他们网络的内容(客户数据库的转储等)。我只是在我的每月专栏“秘密隧道”中介绍了这些内容。某些3G互联网的成本要便宜得多,而不必担心加密协议会将数据从网络中引出。另外,如果您默认阻止传出端口22并进行流量检查,则可以轻松地在非标准端口上找到SSH,从而发现违反安全策略的人员。评论
感谢您的见解。听起来您不会将3G视为秘密隧道。您能否阐明一些原因,使人们在与Internet进行通信时完全脱离网络更有意义?似乎您更喜欢流氓设备,甚至比开放的22更便宜。
– runako
09年6月15日在1:36
“ ...您可以轻松地在非标准端口上找到SSH ...”真的吗?想在443以外的端口上寻找SSL / TLS协商吗?非常好奇。
– Dscoduc
09年6月23日在17:45
是的,您可以检测到ssh流量,谷歌:snort / ssh / detection / content / rules,对其他IDS的了解不多,但是如果Snort可以做到,那么他们就必须非常努力地做到这一点。
–库尔特
09年6月25日在6:10
#10 楼
我认识几个人,他们滥用SSH的功能通过SSH安装SOCKS代理,从而绕过了一些站点限制。甚至是一些简单的端口转发(
ssh -L ....
),如果端口确实被阻止由于站点限制,我将转到:本地管理员,然后
您的项目经理
将其保存到表中让他们详细说明阻止此操作的原因。当然,您需要有充分的理由说明为什么需要访问外部SSH端口来开发内部产品(内部存在:为公司蛇油公司工作时为什么需要访问boxA.example.com)
但是我还没有看到一家公司阻止传出的SSH :)
评论
我见过一家公司阻止传出SSH。他们还阻止了几乎所有其他内容,例如,病毒使用代理检查了所有HTTP传输。该公司是中央证券存管处。
– Esko Luontola
09年6月14日在18:09
我在这样的公司工作。幸运的是,SSH可以通过https进行隧道传输。当然,它们只允许https到端口443 ... sslh进行救援!
– Mikeage
09年6月14日在18:55
proxytunnel FTW :)
–马丁M.
09年6月14日在21:24
#11 楼
显而易见的答案都已陈述。它是一种加密协议,可用于通过创建隧道来规避策略(这是通过公司Web筛选器的好方法),以及未经授权的通信渠道(反向代理)构成的威胁。<没错,在任何现代网络中都应该销毁telnet。但是,我可以看到在禁止ssh的同时允许telnet出入网络。 Telnet的功能不如SSH强大,我始终可以通过嗅探器实时监视流。如果我的核心网络中没有任何telnet设备,并且某些用户想进行telnet,我在乎什么。我可以看到它,并确认它不是威胁。
当然,所有这些都取决于默认策略是阻止所有出口并且仅允许特定协议的想法。奖励积分,如果您在实现优势之前就代理它们。
#12 楼
这不是专门阻止端口22的情况,因为管理员对SSH有反对意见,更多的情况是仅打开他们知道需要打开的端口。如果尚未告知管理员需要打开SSH,则管理员将按照禁用服务器上未使用的服务的相同原理将其阻止。#13 楼
显然,除非网络管理员采取了认真,认真的措施来阻止SSH流量,否则很容易绕过TCP / 22出站阻止。更重要的是,资产管理员需要有足够的能力来运行资产清单,以赶上3G调制解调器和第二个NIC上的可疑IP地址。我们在该地区拥有ClearWire服务,因此我们甚至将WiMax作为围绕网络安全性的最终选择。我们不是主要关注信息泄漏的机构。但是,如果要这样做,就需要将严格的网络安全策略与严格的资产策略以及审计结合起来。据我所知,我认为不存在可以关闭具有某种外部网络连接清单的资产的网络插孔的现成安全软件包。
如果没有这样的软件包,资产库存过程是捕获3G或WiMax等最终运行网络连接的最佳方法之一。
最后,对TCP / 22的盲目阻止只会阻止意图破坏其工作网络的AUP的最终用户。
评论
您可以使用诸如SCCM之类的自定义报告来获取该信息。在我工作的地方,使用个人笔记本电脑或WAN卡绕过网络安全性会受到纪律处分。
–duffbeer703
09年6月15日在23:42
#14 楼
我已经看到22当他们发现人们将HTTP流量引导通过22时被阻止了。对于那些需要它的人来说,这是一个秀场阻止者,但组织仍然坚持下去。#15 楼
大多数大型组织将阻止所有内容,仅允许通过代理服务器进行HTTP / HTTPS访问。听到任何公司允许从台式机或服务器直接进行外部连接的消息,我会感到非常惊讶。具体需求。
#16 楼
没有什么能阻止您在端口80上运行远程sshd。ssh和sshd都有-p选项来设置端口。当然,如果您的管理员很聪明,他们应该注意ssh流量,而不是仅端口22的流量。因此,听起来您遇到了政策问题,而不是技术问题。
不过,正如其他人指出的那样,加密协议可能会导致不得不担心各种合规性问题的人们感到胃灼热。
评论
封锁港口只是成功的一半。要完成此周期,您必须确保要保护的服务不在非标准端口上运行。问题实际上应该是“为什么阻止22端口出站?”因为有100万个很好的理由说明为什么要在非标准端口上运行ssh服务。出站...没那么多。我在罗伯特·莫尔(Robert Moir)的回答上加上了+1,因为他在解释它方面做得很好。
@KPWINC,在标题中添加了说明。谢谢!
将端口22视为pandora的盒子。网络管理员无法看到流量中的流量,更糟糕的是,可以使用ssh绕过网络安全性,从而损害网络的完整性。
@biosFF:端口443。