普遍的看法是,企业需要防火墙来保护他们的网络安全。事实上,正如企业网络从业人员可以证明的那样,“必须购买防火墙”的心态已经渗透到该领域。
也许你也是一个信徒。但是,如果你有任何技术人员为你工作,你是否意识到他们可能在你的防火墙后面有通往他们家用机器的隧道?哦,所以你不允许80以外的端口?没关系——基于HTTPS的VPN,或者用户在端口80上运行ssh来转发端口或运行网络扩展,都越来越受欢迎。
你的网络和服务拓扑结构多久更改一次?你的防火墙多久更新一次?你的家庭用户是否运行防火墙?他们从家庭网络访问VPN后拥有什么权限?他们是否运行开放的802.11网络,或者是否有有好奇心的朋友的青少年儿子或女儿?
如果你对你的答案感到沾沾自喜,那么你认识的其他公司呢?
我提出这些问题是为了阐明集中式安全中的漏洞,我认为集中式安全是一个过时的概念,可能从来没有太大的意义。 “边缘”安全可能是一个被过度使用的流行语,但我认为它更有意义。我们应该保护连接到互联网的设备,并确保它们只适当地信任本地和远程网络上的其他设备。如今,放置一个802.11网桥或让恶意隧道穿透任何公司边界太容易了,因此如果你的主机和服务不安全,那么所有边界安全所做的只是提供虚假的信心。
为了给你提供一些关于我的断言的背景信息,让我告诉你我的经验。在80年代末和90年代初,我管理着一所大学的公共访问和部门路由器网络以及Unix机器。在过去的十年里,我创立、领导了费城第一家ISP(netaxs.com),现在只是外围参与。我的“日常”工作是在Akamai,我们在那里运行超过13,000台主要是Unix机器,提供Web和应用程序交付——HTTP、HTTPS、DNS和流媒体。现在我更多地从事网络方面的工作,但我仍然为netaxs执行积极的系统管理员职责。
通常,区域ISP或国家网络提供商需要运行TACACS+(路由器身份验证/日志记录)、Radius(通用身份验证/日志记录)、NNTP(Usenet新闻)、SMTP、DNS和HTTP等服务,以实现后端功能或让用户满意。特别是古老的ISP(如netaxs、panix、std.com和io.com)甚至运行shell服务器,允许任何每月支付20美元的人访问。
这可能会让你感到惊讶,但很少有区域提供商运行防火墙!有些在路由器上放置过滤器以帮助处理DoS类型的请求,但不是为了阻止主机安全的服务。尽管如此,大多数老牌区域ISP都有良好的安全记录——即使是那些提供shell帐户服务的ISP也是如此。许多ISP不愿设置防火墙,而是将这项可能有利可图的业务外包,因为担心责任问题——主要是网络或服务拓扑会发生变化,而防火墙不会更新。
一些客户已经实施了防火墙,但最终拨号访问和运行RIP的主机将他们的内部网络桥接到一个或多个网络或互联网。最近的故事往往涉及用户在公司网络内外运行隧道,或者绕过不安全的家庭或远程办公室网络,通过VPN访问主网络。
在过去,使用SLIP或PPP通过拨号线路来“扩展”最终用户运行到互联网或公司网络核心的“存根网络”。在过去几年中,主流方法是使用基于PPTP或IPSec的VPN。但最近,主流安全行业已开始销售基于HTTPS的VPN系统,通常在TCP端口80上运行,估计表明这些基于HTTPS的VPN将迅速获得市场份额。
此外,许多精通Unix的“高级用户”使用ssh隧道将其个人机器连接到公司或ISP网络,要么转发特定端口,要么实际上在ssh内部运行PPP,使用ssh作为传输和加密的机制。用户经常运行这些ssh会话,使其看起来像是端口80的出站连接,因此通常不会被拒绝访问Web应用程序的防火墙或路由器过滤器阻止。同样,基于HTTPS的VPN技术可以在用户可以使用HTTPS访问远程互联网应用程序的任何环境中建立出站连接。还有VPN应用程序,例如vpnd,我已经在Linux下运行它来在任意端口上运行VPN,从防火墙内部启动。
基本上,ssh或基于HTTPS的公司网络扩展都可以允许从外部发起的连接到达公司网络的内部核心,而无需通过防火墙进行代理、数据包过滤、内容过滤或监控!一种可能的配置是配置主机来NAT从外部发起的连接。另一种配置是配置主机通过ssh隧道通过PPP路由来自本地LAN的IP范围的单个IP地址,公司主机也被配置为为远程IP地址代理arp。显然,在交换基础设施上启用MAC地址过滤可以阻止第二种配置,但这很少完成,并且仍然不能阻止主机通过NAT从外部提供访问。
在过去,网络管理员只是拒绝用户的模拟电话线,以保护核心公司网络免受计划外的访问。使用可能在任何端口上的VPN,保护变得更加困难。可以在几分钟后重置会话,但这可能会破坏其他应用程序。或者,可以搜索网络流统计信息,查找与奇怪的外部主机的长时间通信。但是,当今大多数边界安全供应商都没有这些功能,并且在大型网络中,很难跟踪所有持久连接。
一种严厉的措施是要求所有流量都通过代理,包括DNS,因为你当然可以通过端口53上的UDP或TCP构建隧道。但是,这种代理会阻止所有对启用HTTPS的互联网网站的访问。如果你采取这一步骤,请为对用户行为进行重大修改所带来的麻烦做好准备。
如果你不想将你的内部网络与互联网断开连接,我强烈建议你先保护终端设备,然后再关注集中式(非基于主机的)安全。请注意,我并不是说防火墙毫无用处。只是完全依赖它们太容易且太普遍了。这条路通向漏洞!防火墙可用于记录活动,以及拦截蠕虫、病毒和不良内容(尽管基于服务器的阻止通常更有效)。但首先要保护主机,然后在你需要时添加这些附加功能。以下是一些更具体的建议
这些建议已经是10年前的旧闻了——但人们常常忽略或降低它们的优先级,因为他们将外部和/或内部防火墙视为安全网。但是没有完美的安全网——即使保护主机也不会使你坚不可摧。由于任何坚定的攻击者(例如,员工的青少年)都可能找到一个用户通过批准和支持的VPN通道“进来”,因此确保经过身份验证的用户在你的网络内部时不会获得王国的钥匙也很重要。
你可能会惊讶于有多少公司实施黑客行为,以启用对SAP和Siebel等单体后端应用程序的Web访问。我见过多个这样的“轻量级”客户端实现,它们使用通用用户名和密码向后端进行身份验证,允许访问应用程序或数据库级别的所有数据!
还要意识到,任何用于共享用户数据的NFS或SMB实现实际上都会向任何可以获得本地root/管理员权限的人开放所有数据。即使邮件服务需要单独的身份验证,许多用户也将邮件存储在文件服务器上,无论是作为Unix邮箱还是作为笔记本电脑硬盘的备份。
我已经谈到了人们可以通过端口80构建的隧道VPN,但是许多公司正在转向Web服务架构,该架构将端口80作为越来越多应用程序的网关。虽然保护Web服务是另一篇文章的主题,但我会提醒开发人员,仅仅能够执行对象/函数/代码就需要最高级别的安全性——在参数检查、对象/函数和参数定义的访问限制以及当然是对对象/函数的细粒度访问限制方面。
我坚信,保护网络上的主机和服务是确保公司数据安全的唯一合理方法。获得网络访问权限不应开放对网络中机器的访问权限,并且以一个用户的身份获得访问权限不应在没有额外身份验证的情况下开放其他用户的数据。
我现在可以听到反对意见——这种边缘安全很难!
是的,保护所有主机,然后确保用户数据集彼此隔离,对于许多公司来说,这是一个棘手的挑战,超出了最先进的水平。但是,转向边缘安全既是必要的,也是值得的。让我们面对现实:大多数大型网络可能已经被渗透或很容易被中等坚定的攻击者渗透。计划用AFS替换NFS;确保用户不会将笔记本电脑备份到用户隔离性较弱的文件服务器;当然,要像保护每个内部主机一样,将其直接连接到互联网。祝你好运,愿原力与你同在。
###
AVI FREEDMAN 目前是Akamai Technologies的首席网络科学家;FastNet的首席网络架构师和董事会成员;并参与初创公司Money For Clue Consulting和Watch My Net。 Avi在Akamai工作了3年。在此之前,他在AboveNet领导工程部门。 1992年,Avi创立了Netaxs,费城地区的原始ISP。 2002年,Netaxs被FastNet收购。 Avi的兴趣在于路由、性能分析和安全。
最初发表于Queue杂志第1卷,第1期—
在数字图书馆中评论本文
Niklas Blum, Serge Lachapelle, Harald Alvestrand - WebRTC - 开放Web平台的实时通信
在这个疫情时期,世界比以往任何时候都更转向基于互联网的RTC(实时通信)。在过去十年中,RTC产品的数量大幅增长,这在很大程度上是由于更便宜的高速网络访问和更强大的设备,但也归功于一个名为WebRTC的开放、免版税平台。 WebRTC正在从实现有用的体验发展到在疫情期间对于数十亿人继续工作和教育以及保持重要的人际接触至关重要。 WebRTC未来的机遇和影响确实令人着迷。
Benjamin Treynor Sloss, Shylaja Nukala, Vivek Rau - 重要的指标
衡量你的站点可靠性指标,设定正确的目标,并努力准确地衡量这些指标。然后,你会发现你的服务运行得更好,中断更少,用户采用率也更高。
Silvia Esparrachiari, Tanya Reilly, Ashleigh Rentz - 跟踪和控制微服务依赖关系
如果你曾经把钥匙锁在房子或车里,你就会熟悉依赖循环。没有钥匙你就打不开锁,但没有打开锁你就拿不到钥匙。有些循环是显而易见的,但更复杂的依赖循环可能很难在它们导致中断之前找到。跟踪和控制依赖关系的策略对于维护可靠的系统是必要的。
Diptanu Gon Choudhury, Timothy Perrett - 为互联网规模的服务设计集群调度器
希望构建调度系统的工程师应考虑他们使用的底层基础设施的所有故障模式,并考虑调度系统的运营商如何在租户系统所有者进行故障排除期间配置补救策略,同时帮助保持租户系统的尽可能稳定。