你是否曾有过这样的经历:启动软盘上的写入保护开关,以防止启动病毒和恶意覆写;关闭调制解调器,以防止黑客在晚上打来电话;卸载ansi.sys 驱动,以防止恶意文本文件重新排布键盘,让下一次敲击直接格式化你的硬盘;检查autoexec.bat和config.sys文件,以确认没有恶意条目通过插入它们进行自启动。
时过境迁,上述情况如今很难见到了。黑客们取得了进步,技术替代了过时的方式。有的时候,我们这些防御者做得如此之好,让黑客放弃了攻击,转向更有油水的目标。有的时候,某种防御功能会被淘汰,因为我们认为它不能提供足够的保护,或者存在意想不到的弱点。新的技术浪潮不论是大是小,都会带来新的威胁。黑客们迅速替换手中的技术,把去年流行的攻击方式扔进垃圾箱,而安全社区正在疲于奔命。
也许没有什么东西,能够像计算机技术一样变化如此迅速。随着科技前进步步前进,保护它的责任也越变越重。如果你在计算机安全的世界里混迹已久,可能已经见识过很多安全技术的诞生和消亡。有的时候,你就快能够解决一种新的威胁了,而威胁本身却很快过时了。攻击和技术的步伐持续前进,即使是所谓最尖端的防御技术,比如生物认证和高级防火墙,都终将失败并退出局面。下面是那些注定要进入历史教科书的安全防御技术,我们五到十年后再翻开这篇文章,一定会超出你的想像。
No.1:生物认证
在登录安全领域里,生物认证技术是十分诱人的良药。毕竟,你的脸、指纹、DNA或者其它生物标志似乎是完美的登录凭据。但这只是门外汉的见解。对专家而言,生物认证并没有看上去那么安全:如果它失窃,你本人的生物标志却无法改变。
录入你的指纹吧。大多数人只有10个。任何时候你使用指纹作为生物识别凭据进行登录,那些指纹,或者更确切地说,其数字标识,必须被存储在某处以进行比对。不幸的是,这些数字标识损坏或者被盗是太常见的现象。如果坏人偷走了它们,你怎么能分辨出真实指纹凭据和对方手中数字标识的区别?
在这种情况下,唯一的解决办法是告诉世界上的每一个系统,不要继续使用你的指纹,但这几乎不可能做到。这对任何其它生物特征标记而言都是成立的。如果坏人得到了你生物信息的数字版本,要否认自己的DNA、脸、视网膜是很难的。
还有另一种情况,如果你用于登录的那些生物特征,比如说指纹本身被破坏了呢?
加入生物识别的多因素认证是一种击败黑客的方法,比如在生物识别之外加上密码、PIN。但一些使用物理要素的双因素认证也可以很容易地做到这一点,比如智能卡、USB钥匙盘。如果丢失,管理人员可以很快地颁发给你新的物理认证方式,你也可以设置新的PIN或者密码。
尽管生物识别登录正迅速成为时髦的安全功能,它们永远都不会变得无处不在。一旦人们意识到生物识别登录并不是它们看上去的那样,这种方式将失去人气,或者消失。其运用时总是要结合另一个认证要素,或者只是用在那些不需要高安全性的场景下。
No.2:SSL
自1995年发明以来,安全套接层协议(Secure Socket Layer,SSL)存在了很长一段时间。在这二十年里,它为我们提供了充分的服务。但如果你还没有听说过的话,我们需要介绍一下Poodle攻击,它让 SSL协议无可挽回地走远了。SSL的替代者传输层安全协议(Transport Layer Security,TLS)则表现稍好。在本文介绍的所有即将被扔进垃圾桶的安全技术中,SSL是最接近于被取代的。人们不应该再使用它了。
问题在哪?成百上千的网站依赖或启用了SSL。如果你禁用所有的SSL,这也是流行浏览器最新版本里的一般默认做法,各种网站都会变得无法连接。也许它们可以连接,但这只是因为浏览器或应用接受对SSL进行降级。此外,因特网上仍旧存在数百万计古老的安全Shell(Secure Shell,SSH)服务器。
OpenSSH最近似乎一直在遭到入侵。尽管大约一半的攻击事件和SSL毫无关系,但另一半都是由于SSL的漏洞引起的。数百万计的SSH/OpenSSH网站仍在使用SSL,尽管他们根本不应该这样做。
更糟糕的是,科技专家们使用的术语也在导致问题。几乎每个计算机安全行业内的人都会将TLS数字证书称为“SSL证书”,但这纯属指鹿为马:这些网站并不使用SSL。这就像是说一瓶可乐是可口可乐一样,尽管这瓶可乐可能是另外一个品牌。如果我们需要加快世界抛弃SSL的速度,就需要开始用本名称呼TLS 证书。
不要再使用SSL了,并且将Web服务器证书称为TLS证书。我们越早摆脱“SSL”这个词,它就能越快地被扫进历史的垃圾堆。
No.3:公钥加密
如果量子计算的实现和配套的密码学出现,我们如今使用的大多数公钥加密技术:RSA、迪斐·海尔曼(Diffie-Hellman,DH)等等将很快变成可读状态,这可能会让一些人大吃一惊。很多人长期以来都认为可使用级别的量子计算再过几年就要到来了,但这种估计属于盲目乐观。如果研究人员真的拿出了量子计算技术,大多数已知的公钥加密方式,包括那些流行算法,都会非常容易破解。世界各地的间谍机构经年累月地秘密保存着被锁死的机密文件,等着技术大突破。而且,如果你相信一些流言的话,他们已经解决了这个问题,正在阅读我们的所有秘密。
一些密码学专家,比如布鲁斯·施耐尔(Bruce Schneier),一直以来对量子密码学的前景存有疑问。但批评家无法拒绝这种可能性:一旦它被开发出来,所有使用RSA、DF,甚至椭圆曲线(EllipTIc Curve Cryptography,ECC)加密的密文瞬间变成了可读状态。
这并不是说不存在量子级的加密算法。的确有一些,比如基于格(LatTIce)方法的加密、超奇异同源密码交换(Supersingular Isogeny Key Exchange)。但如果你使用的公钥不属于这类,一旦量子计算开始普及,你的坏运气就要来了。
No.4:IPsec
如果启用,IPsec会保护两点或多点间数据传输的完整性和隐私性,也即加密。这项技术发明于1993年,在1995年成为开放标准。数以百计的厂商支持IPsec,数百万计的计算机使用它。
不像本文中提到的其它例子,IPsec真的有用,而且效果很好,但它却有着另一方面的问题。
首先,虽然它被广泛使用并部署,但从没达到大而不倒的规模。其次,IPsec十分复杂,并不是所有厂商都支持它。更糟的是,如果通讯双方中的一方支持 IPsec,另一方如网关或负载平衡器不支持它,通讯经常会被破解。在许多公司中,IPSec通常作为可选项存在,强制使用它的电脑很少。
IPsec的复杂性也造成了性能问题。除非你在IPsec隧道两侧都部署专门硬件,不然它就会显著减缓所有用到它的网络连接。因此,大型的事务服务器,比如数据库和大多数Web服务器根本无法支持它。而这两类服务器恰恰是存储最重要数据的地方。如果你不能用IPsec保护大部分数据,它又能带来什么好处呢?
另外,尽管它是一个“公共”的开放标准,IPsec的实现却通常无法在各个厂商之间共用,这是另一个减缓乃至阻止IPsec被广泛部署的原因。
但对IPsec而言,真正的丧钟是HTTPS得到了广泛使用。如果你启用了HTTPS,就不再需要IPsec。这是个两者必择其一的选择,世界作出了它的决定。HTTPS赢了。只要你有一份有效的TLS电子证书,一个兼容的客户端,就能使用HTTPS:没有交互问题、复杂度低。存在一些性能影响,但对大多数用户而言微不足道。全球正迅速变成一个默认使用HTTPS的世界。在这个过程中,IPsec将会死亡。
No.5:防火墙
无处不在的HTTPS基本上宣告了传统防火墙的末日。早在三年前就有人写过相关文章,但三年过去,防火墙依旧无处不在。但真实情况呢?它们大多数未经配置,几乎全部都没有配备“最低容许度,默认屏蔽”规则,然而正是这种规则才让防火墙具备了价值。相信不少人都知道大多数防火墙规则过于宽松,甚至“允许所有XXX”这样规则的防火墙也不稀罕。这样配置的防火墙基本上还不如不存在。它啥都没干,只是在拖网速后腿。
不管你怎么定义防火墙,它必须包括一个部分:只允许特定的、预配置的接口,只有这样它才能算是有用。随着这个世界向着HTTPS化迈进,最终,所有防火墙都会只剩下几条规则:HTTP、HTTPS和DNS。其它协议,比如ads DNS、DHCP等等,也会开始使用HTTPS-only。事实上,很难想象一个不是以全民HTTPS化告终的世界。当这一切来临,防火墙何去何从?
防火墙提供的主要防御功能是保护脆弱的服务免遭远程攻击。具有远程脆弱性的服务通常极易破坏,远程利用缓冲区溢出是最常见的攻击方式。看看莫里斯蠕虫(Robert Morris Internet worm)、红色警戒(Code Red)、冲击波(Blaster)和蓝宝石(SQL Slammer)吧。你能回忆起最近一次世界级缓冲区溢出蠕虫攻击出现在哪年吗?应该不会超过本世纪头几年。而这些蠕虫都还远不及上世纪八九十年代那些的威力。基本上,如果你不使用未打补丁、存在漏洞的监听服务,就不需要传统防火墙。你现在就不需要。对,你没听错。你不需要防火墙。
一些防火墙厂商经常鼓吹他们的“高级”防火墙拥有传统产品远不能及的功能。但这种所谓的“高级防火墙”只要它们进行“数据包深度检查”或签名扫描,只会导致两种结果:其一,网速大幅度下降,返回结果充斥着假阳性;其二,只扫描一小部分攻击。大多数“高级”防火墙只会扫描数十到数百种攻击。如今,每天都会出现超过39万种新型恶意软件,这还不包括那些隐藏在合法活动中无法识别的。
即使防火墙真的达到了他们宣称的防护级别,它们也不是真的有效。因为如今企业面临的两种最主要的恶意攻击类型是:未打补丁的软件和社会工程。
这么说吧,是否配备防火墙都一样被黑。也许它们在过去表现太好了,导致黑客转向了别的攻击类型。但不管是什么原因,防火墙如今已经几乎没有用了,从过去十年前这个趋势就开始了。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)