随着IPv4地址告罄，IPv6几乎无限的IP地址资源满足了全球互联网的需求。但是任何事物都是具有两面性的，有利也有弊。在满足互联网IP地址需求的同时，一系列安全问题也随之而至。IPv6与IPv4相比，在设计之初，就对安全问题做出了更多的考虑。借助 IPSec(Internet 协议安全性)，IPv6的安全性能确实得以改善。但是，近来发生的网络攻击事件显示，IPSec并不能处理IPv6网络中的所有漏洞问题。而对比 IPv4，新的网络环境要更为复杂，所产生的网络漏洞也更难预料。

而且，尽管IPv6的内部加密机制是为用户与服务器之间的交流提供身份认证与保密功能的，但是它令攻击者得以利用加密机制绕过防火墙和IPS检 查，直接向服务器发起攻击，原因正在于这些安全设备无法检测加密内容。除此之外，IPv6重定向协议中存在的安全隐患也非常值得人们关注。

企业从IPv4到IPv6安全问题须知

随着支持IPv6终端的数量增长，IPv6流量在许多企业计划过渡之前就已经出现在企业IPv4网络上了。员工可以随意的在这些新的未监控的网络里共享文件，下载视频，而这些漏洞会被黑客入侵。

在已有的IPv4网络，IPv6的潜在威胁会给企业带来一连串危险和带宽问题。像BYOD自带设备办公的趋势加重了这些问题，许多终端和设备现在都支持IPv6，由于用于工作的外来设备愈来愈多，企业IPv4网络的风险也越来越大。

在IPv4企业网络中出现的IPv6流量即"阴影网络"是个开放的地方，当使用IPv4网络的用户发现应用程序运行在IPv6阴影网络，这时就绕过了网络安全措施，将造成大量带宽被消耗。

在过渡的过程中，企业将面临更多的对信息安全问题以及对信息安全体系的重新理解和调整。

首先，为了实现IPv4与IPv6的无缝兼容，很多IPv6设备都内置了各种无状态的自动配置功能，而这样的网络设备对网络管理员而言却成了不 可控的设备。管理员将难以察觉哪些网络设备是失控的，而攻击者却可以利用这种情况下手。其次，在企业迎接IPv6的同时，IT管理的难度也会随之增加。同 时，目前业内对于IPv6协议的内置功能如何帮助用户提高隐私保护方面的问题的探讨寥寥无几，而是更多的把目光聚焦于如何更快捷地部署IPv6，这让很多 不安全的协议、标准、技术被不计后果的广泛采用，企业在这样的过渡环境中很容易受到攻击。

相对于人们在IPv4上积累的安全经验来说，业界在IPv6安全方面的经验还有所不足。在逐渐引入IPv6的日子里，所有的网络设备都不得不支 持两个版本的网络协议，因此增加的网络安全风险很可能导致巨大的损失。在看清IPv6之前，人们的警惕与热情显然需要并存。不需要使用IPV6或者没有完 成过渡的企业应该关闭所有系统上的IPV6，或者，企业应该"像IPV4一样对攻击进行监控和抵御"。

细说IPv6安全八大问题

IPv6对于大多数互联网利益相关者来说是一个新的领域，IPv6的推出会带来一些独特的安全难题，下面将讨论行业在继续应用IPv6的时候需要考虑的8个安全问题。

1.从IPv4翻译至IPv6处理过程的安全漏洞

IPv4和IPv6不是完全兼容，这是众所周知的问题。此时就需要从IPv4翻译至IPv6，于是协议翻译被看作是扩大部署和应用的一个途径。 在把IPv4通讯翻译为IPv6通讯时，将不可避免地导致这些通讯，在网络上通过的时候调解处理过程。此时将会出现利用潜在的安全漏洞的机会。

此外，这种做法引进必须包含处理状态的中间设备将破坏端对端的原则，使网络更加复杂。总的来说，安全人员应该关注所有的翻译和转变机制(包括建立隧道)的安全方面，只在进行全面评估之后才明确使用这种机制。

2.大型网段有利有弊

当前建议的IPv6子网的前缀是/64(264)，能够在一个网段容纳大约18 quintillion(百万的三次方)个主机地址。虽然这能够实现局域网的无限增长，但是它的规模也带来了难题。

例如，扫描一个IPv6/64网段的安全漏洞会需要几年的时间，而扫描一个/24 IPv4子网28这需要几秒钟。由于全面扫描是不可能的，一个较好的方法是仅利用第一个/118的地址(与IPV4的一个/22网段的主机数量相同)以便 缩小需要扫描的IP地址范围，或者明确地分配所有的地址，完全拒绝其它的地址。这将使认真的IP地址管理和监视比现在更加重要。人们预计还将看到攻击者使 用被动域名系统分析和其它侦查技术取代传统的扫描。

3.邻居发现协议和邻居请求能够暴露网络问题

IPv6的邻居发现协议使用五个不同类型ICMPv6(互联网控制消息协议第6版)信息用于若干目的。虽然邻居发现协议提供了许多有用的功能(，但是它还给攻击者带来了机会。IPv6中的攻击很可能取代ARP(地址解析协议)欺骗攻击等IPv4中的攻击。

4.阻塞大型扩展标头(header) 、防火墙和安全网关可能成为分布式拒绝服务攻击的目标

IPv6采用名为扩展标头的一套额外的标头，这些扩展标头将指定目的地选择、逐个跳点的选择、身份识别和其它许多选择。这些扩展标头在IPv6主标头后面并且连接在一起创建一个IPv6数据包(固定标头+扩展标头+负载)，IPv6主标头固定为40字节。

有大量扩展标头的IPv6通讯可能淹没防火墙和安全网关或者甚至降低路由器转发性能，从而成为分布式拒绝服务攻击和其它攻击潜在的目标。关闭路 由器上的IPv6源路由对于防御分布式拒绝服务攻击的威胁也许是必要的。明确规定支持哪些扩展标头并且检查网络设备是否正确安装是非常重要的。总的来 说，IPv6增加了更多的需要过滤的组件或者需要广泛传播的组件。

5. 6to4和6RD代理服务器也许会鼓励攻击和滥用

6to4以及互联网服务提供商迅速部署6RD会允许IPv6数据包跳出IPv4的壕沟，不用配置专用的隧道。但是，使用IPv6代理服务器也许会给代理服务器运营商带来许多麻烦，如发现攻击、欺骗和反射攻击。代理服务器运营商本身可能被利用为攻击和滥用的"源"。

6.支持IPv6服务可能会暴露现有的IPv4应用或者系统

一个限制是现有的安全补丁也许仅适用于IPv4技术支持。因此，在iPv4之前，在进行DNS查询已经更快部署IPv6的时候，大多数内核将喜 欢IPv6接口。确实，IPv6与IPv4之间的相互作用方式可能导致每一个DNS查询的通讯量增加一倍。这将导致大量的不必要的DNS通讯量以便优化用 户的体验。

操作系统和内容厂商频繁地组织非法访问以缓解和优化这种行为，这种行为将增加系统负荷和状态。此外，随着可以访问新的IPv6栈，新的安全漏洞 肯定会出现。在长期过渡的共存期间的双堆栈以及路由器、最终系统和DNS等网络服务之间的相互依赖肯定会成为攻击者的肥沃的土地。

7.许多用户被隐蔽在固定的一套地址后面

把用户隐蔽在大型网络地址转换协议转换((NAT-PT)设备后面会破坏一些有用的功能，如地理位置或者查找恶意网络行为根源的工具，使基于号码和名称空间声誉的安全控制出现更多的问题。

8.当建立通向其它网络的隧道时的IP安全问题

IP安全可能对发送者进行身份识别，提供完整性保护，加密数据包以提供传输数据的保密性。IP安全对于IPv4来说是一个可选择的功能，但是，它是IPv6强制规定的功能。

在隧道模式中(它实际上可以创建一个网络至网络、主机至网络和主机至主机之间通讯的虚拟专用网)，整个数据包封装在一个新的IP数据包中并且给予一个新的IT标头。

但是，虚拟专用网与一个超出原来创作者的控制的网络的连接可能导致安全问题或者被用来窃取数据。由于IP安全的安全保护和管理以及相关的密钥是由其它协议管理的并且增加了复杂性，IP安全不能像最初用于IPv4那样更广泛地支持IPv6。

6月7日消息，纳斯达克OMX集团周三提出一项计划，准备一次性用4000万美元赔偿Facebook IPO蒙受损失的投资者。在Facebook IPO时，由于系统技术故障，开盘时间晚了30分钟，一些订单未确认，使银行和交易商受损。

按计划，纳斯达克会提供现金赔偿，并提供交易折扣，从而挽回声誉损失。对于Facebook股票的下跌，纳斯达克声称与自己无关。

纳斯克达的补偿计划会呈交SEC，之前曾有金融公司称由于技术问题带来的损失达1亿美元，由现在的数据来看，4000万美元远远不及。消息人士称，这可能会引起竞争交易所的反对。

纳斯达克表示，会用1370万美元现金赔偿遭受损失的成员公司，包括纳斯达克在Facebook IPO首日交易获得的1070万美元利润，以及最高300万美元的交易赔偿金。

其它的赔偿会在6个月内、分期以交易折扣形式支付，如此一来，超过了监管机构设定的最高300万美元的赔偿金上限，这可能会引起竞争对手的反对。

赔偿将由美国金融产业监管局监督执行，它会对纳斯达克的决定进行评估，但它也表示最终还是由纳斯达克确定。

纳斯达克还表示，赔偿要求符合一定的标准，且不包括成员公司已经确定并决定交易的损失。纳斯克达认定三类交易可以获赔，包括以42或者42美元以下出售股票、但未执行的订单；42美元买入、已执行订单，但没有迅速确认的也在考虑获赔之内。

在Facebook IPO时，由于开盘晚了30分钟，导致大量经纪人的订单处于未确定交易中。公司无法知道自己的订单结果，直到股票开盘2小时后才了解详情。

全球的浏览器市场风起云涌，国外调查机构发布了5月份全球浏览器的分析图。在图上可以看到Firefox桌面浏览器已经降至20%，Chrome呈 缓慢逐渐上涨的趋势，不断蚕食Firefox的份额，不过IE仍然占据半壁江山。在全球综合浏览器排名情况中，IE浏览器仍然占据49.78%的份额，并 相当的稳定。而Chrome增长虽然缓慢，但是未出现下滑的情况，不断蚕食Firefox的市场份额，基本上已经和Firefox市场份额持平。而 Firefox5月份继续下滑。

在桌面浏览器上，IE还是占据半壁江山，而苹果的Safari在桌面市场上仅占4.62%，基本上是Chrome。Firefox，IE三者的天下。

在变化图上，可以看到IE和Safari基本上保持稳定，并未出现大的变化，主要是Firefox的份额逐渐被Chrome蚕食。

而凭借着iPhone的热销，Safari在全球移动浏览器方面的市场份额相当的大，而IE则表现的差强人意，仅占了0.74%同时Opera也有不俗表现。

我喜欢大卫·芬奇(David Fincher)拍的电影《龙纹身女孩》，他成功的把小说《龙纹身女孩》搬上了荧幕，超出了我的预期。我本以为这又是一部肤浅的、愤世嫉俗的用来敛钱的好莱坞电影，事实情况却是，这是一部情节紧张，能引起共鸣的电影，只是里面的淫杀犯罪让人毛骨悚然。我最喜欢的一个情节是龙纹身女孩用SQL来查找40年前的凶杀案的过程。

我们从电影里可以看到她使用笔记本电脑，轻而易举的进入瑞典警察局数据库，当她敲入像‘unsolved(未破案)’和‘decapitation(斩首)’等关键词时，屏幕上翻滚着绿色的检索出的信息，虽然我们看不清她使用的完整的查询语句：

处于一种天生的好奇，我忍不住截取了这些镜头画面，用Photoshop拼接了一下，下面是我得到的结果：

你马上能发现，这不是Oracle SQL——很显然 AS 关键字在Oracle里不能用在表假名上。事实上，如果我们回去看看她那个令人兴奋的查询结果输出时，你会看到 mysql 的提示符，而且还有 use [dbname] 连接数据库的语法，下面是一个更详细的画面：

我们实际上可以把她用的left join关键词表的SQL语句整理出来。

最终我们获得了一个全屏的输出结果信息：

下面就是我们Oracle“WTF研究会”部门重新构造出的她使用的SQL：

SELECT DISTINCT v.fname, v.lname, i.year, i.location, i.report_fileFROM   Incident AS i       LEFT JOIN V(ictim?)...  -- presumably v.incident_id = i.id       LEFT JOIN Keyword AS k ON k.incident_id = i.idWHERE  i.year BETWEEN 1947 AND 1966AND    i.type = 'HOMICIDE'AND    v.sex = 'F'AND    i.status = 'UNSOLVED'AND    ...       OR v.fname IN ('Mari', 'Magda')       OR SUBSTR ...AND    (k.keyword IN ('rape', 'decapitation', 'dismemberment', 'fire', 'altar', 'priest', 'prostitute')       ...       AND SUBSTR(v.fname, 1, 1) = 'R' AND SUBSTR(v.lname, 1, 1) = 'L');+--------+---------+------+-----------+----------------------------------+| fname  | name    | year | location  | report_file                      |+--------+---------+------+-----------+----------------------------------+| Anna   | Wedin   | 1956 | Mark      | FULL POLICE REPORT NOT DIGITIZED || Linda  | Janson  | 1955 | Mariestad | FULL POLICE REPORT NOT DIGITIZED || Simone | Grau    | 1958 | Goteborg  | FULL POLICE REPORT NOT DIGITIZED || Lea    | Persson | 1962 | Uddevalla | FULL POLICE REPORT NOT DIGITIZED || Kajsa  | Severin | 1962 | Dals-Ed   | FULL POLICE REPORT NOT DIGITIZED |+--------+---------+------+-----------+----------------------------------+

你也许会很惊讶，很奇怪，这样一个顶级的黑客为什么要outer-join的方式连接Victims(被害人)表和Keywords(关键词)表呢，还使用这样的文字过滤方式，岂不知MySQL里是有 like 语法的，更奇怪的是输出结果里根本没有姓和名分别以’R L’打头的受害人。

[本文英文原文链接：The Girl With The ANSI Tattoo ]