Recently in Security Category

之前和 A core 聊过这个问题。整理一下发出来。

这个话说的可能比较绝对，有人说，缺少信任的社会是可悲的----而我想说的是，现今，被过度滥用的信任则是可怕的。通过各式各样的社交网站，如 Facebook、LinkedIn、开心网、豆瓣，但是我个人认为豆瓣算是一个比较另类的社交网站，因为上面的人很少使用真名），很多人之间的联系被轻易地挖掘和利用。

类似"谁认识谁"这样的信息，在过去是不太容易获得的。而有了社交网站，一切都变得如此透明。一个人的人际关系如何？作为招聘的HR，只要到这样的网站上检索一番就能够一目了然；想要让一个人身败名裂？很简单，从身边的人下手----几年前，在blog还没那么普及的时候，我就收到了一封匿名的"检举信"，讲的是某低年级同学在某地所做的丑事，导致该君到处写信灭火，而事实？只是寻衅报复----互联网使得信息的传播变得比人类以往的任何时候都要更加迅速，当然，正如很多可以分成靠谱的和不靠谱的东西一样，海量的信息带来的则也包括了海量不靠谱的信息。

和很多人一样，我对于要求填写个人信息的注册表格有非常强烈的抵触情绪。我为什么要相信一个网站或公司能够确保这些信息不被未经授权的第三方得到？事实上，正如对软件所做的各种保护一样，主流安全公司所做的所谓验证，无非只是一种心理上的安慰----这家公司采用了比较严格的流程，使得你的隐私信息，例如姓名、地址、信用卡号，等等，不太容易被攻击者得到----比如说，这些信息只能一次性地写入到服务器，之后只能得到其中的后几位，而那台记录这些信息的服务器受到了更为严格的保护----但是，只要这些信息能够被任何这家公司的工作人员读取，那么，它就不可能是绝对安全的。

你相信大型邮件服务提供商，例如 Google、MSN、Yahoo、网易、新浪 能够保证邮件的安全吗？我想，海量的用户带来的巨大的关注成本以及这些公司招聘时候对入职人员的进行的考察所保证的职业操守，足以让我相信做为一个普通用户，完全可以信赖这些邮件系统；然而，如果你的通讯涉及到巨大的商业或其他利益，事实上，基本上没有有效的办法去阻止邮件在不知道的情况下发生丢失或被泄露给通讯双方所不知道的第三方。

从工作在客户端的间谍软件，到大楼的网管，再到互联网服务提供商（到互联网骨干，再到IDC等等），再到服务器所属的那家公司----如果考虑收信的一方，那么还要再多加一倍的可能入侵的环节，更重要的是----你的通讯多数时候是明文的。加密并不能解决全部问题，除非能够有有效的方法确认收件人的身份，并保证路上不出现故意的"遗失"，还要保证，在你能够把文本加密之前，所用来编辑和加密的系统是可信的。

互联网时代没有隐私。永远不要说"永远不"，但是我还是想说，如果不希望某些信息公之于众，那么最好的办法仍然是把它烂在肚子里，而不是放到互联网上某个让你觉得别人永远找不到的角落。类似地，也不要把能够很容易地获得的信息太当回事，这个世界上有很多不够小心的人，但这并不代表，这个世界上的人都不够小心。

哦，对了，写这篇文章是因为看到了 MD5 considered harmful today，终于有人凑出了一个CA证书。是的，加密也不一定有用了。

在Hotmail里面收到了很多假开心网的邀请信。点开一看，恶心的来了：填好了MSN地址，然后让你填密码。

这家公司真恶心。

前几天和网通的人聊起了这项最新科技，看起来这项技术已经民用相当长时间了，它可以与IPv4和IPv6并存（实际上是互相不干扰），并且解决了一些ATM不适应时代的问题。

Bruce Schneier大师说，DNS漏洞的细节还是被提前披露了，人们开始撰写利用这一漏洞的攻击程序，等等。这里摘录一些比较精彩的内容，推荐您阅读原文。

然而，因此而对 Kaminsky 展开口诛笔伐显然是不对的。在圈外人士看来，也许如果他在这个事情上缄口不语，我们便不会有这许多的麻烦。这显然是不对的， Kaminsky 偶然发现了这个问题，他没有理由相信自己是第一个，更没有理由相信自己是最后一个发现这些问题的。问题出在 DNS 协议本身，而不是 Kaminsky。

这一事件带给我们的真正的教训是：事实上，打补丁这样的工作并不是那么的轻而易举。安全工程师需要在一开始就介入设计----因为发现问题、修补、然后部署补丁这个过程不仅代价高昂、低效而且通常不够完整----这会比事后打补丁要容易的多。这次事件再次证明了这一点----数学家Daniel J. Bernstein设计的djbdns在几年前就已经实现了源端口随机化，虽然他并没有发现 Kaminsky 的攻击，但是他所采取的是对付一整类攻击的方法，因而，这一在2000年发布的程序，尽管没有打任何补丁，仍然做到了对 Kaminsky 攻击的免疫。

最近炒的比较火的一个漏洞是 DNS 协议本身发现的一个严重问题（CERT VU#800113）。国内媒体对此的报道多数都语焉不详，因此我想有必要说说这个漏洞到底是怎么回事。

之前一直比较公开的一个秘密是，Google Toolbar实际上是可以在 FreeBSD 上运行的（注意不是通过 Linux ABI 支持）。不过 Firefox 3 发布之后，以前通过 Linux Firefox 安装 toolbar 这条路被堵住了，因此只好寻求新的解决途径。

具体做法：

0. 下载 Google Toolbar：
fetch http://dl.google.com/firefox/google-toolbar-ff3-linux.xpi

1. 将其解压缩到一个空目录：
mkdir google-toolbar
cd google-toolbar
tar xf ../google-toolbar-ff3-linux.xpi

2. 修改 install.rdf，将其中关于em:targetPlatform的描述改为FreeBSD。

3. 删除 META-INF，我们之前的操作破坏了数字签名。

4. 重新打包成 .xpi 文件（用zip）

5. 修改 Firefox 配置（通过about:config，将extensions.hideInstallButton修改为false）

6. 在 Tools -> Addon 里面按Install，选择我们自己的.xpi文件。

7. 根据提示重启 Firefox。

如题，机器将从亦庄机房迁移到另一个机房，目前测试速度不错。

一段鲜为人知的历史。

据考证，世界上公认的第一封垃圾电邮，是1978年5月3日由 DEC 公司的销售代表 Gary Thuerk 发出的，两个行业随后相继诞生。

06年 工大 上 IPv6 的时候，我曾经说过，什么时候从 IPv6 上收到了垃圾邮件，才说明 IPv6 真的要普及了。到后来，我自己的机器也上了 IPv6，而这个 IPv6 的应用也仅仅是邮件而已。

今天我终于通过 IPv6 收到了一封直接发往 geekcn 的垃圾邮件，这个垃圾邮件网关是 2001:748:100:40::2:4，虽然说也许这个发垃圾邮件的人仍然是无意为之，但是至少，这是一个值得记住的、划时代的事件----一封垃圾邮件，从发垃圾邮件的人到我的服务器之间走的是 IPv6 而不是传统的 IPv4，这说明 IPv6 离真正普及再也不像几年前看着那样遥远了。

2008硬盘磨损年！

我相信很多人都遇到过硬盘卡壳、掉链子的情况。当然，这篇文档的主旨不是告诉你怎么样可以绕过那些老爷子写的课本上说的金科玉律──重要的数据都应该有备份──如果你的数据最终丢失了，那么我的问题是：你的备份呢？

但是，即使你有经常备份的习惯，有些数据还是会难免出现一些没有及时备份而导致丢失的情况。我的观点是，没有备份计划的数据都不是重要数据，不要等到数据丢失了再去后悔，但是我们显然应该采取各种各样的手段来阻止没有及时备份的那一小部分数据的丢失。

硬盘

大家一起默念：它很便宜！它会坏掉！

是的，实战经验会告诉你，它很便宜！它也会坏掉！不管这个硬盘是来自什么厂商，也不管它是SATA、SCSI、SAS或者是传统的ATA接口，它出现故障只是时间早晚的问题。

为了解决这个问题，人们提出了廉价磁盘冗余阵列（RAID）的概念。例如，使用两块相同容量的磁盘组成 RAID-1 (MIRROR) 阵列，可以在其中任意一块出现问题时，从另一块中取出数据。而如果有至少3块硬盘，便可以组成 RAID-5 （注：还有其他RAID级别可以用3块硬盘组成冗余结构），只损失 1/n 的容量（n为硬盘数量）来得到带冗余的存储，使得存储可靠性得以提高。

除了改善可靠性之外，RAID还可以用来改善读写性能。例如用多块硬盘组成 RAID-0 阵列，可以将读写性能提高 n 倍，等等。我们并不讨论这些RAID级别。

不幸会发生

和很多人已经想到的一样──不要高兴的太早......

带数据冗余的 RAID 的一个基本假设是，磁盘是不骗人的，它有两种状态：好、坏，并且，主机（或RAID控制器）能够可靠地识别这种状态。

很不幸，这句话只对了一半。一块磁盘要么是好的、要么是坏的（这里，"坏的"的定义是读写时会发生任何错误），但是主机未必能够识别这种状态。

更为严重的是，有些时候主机甚至连读出来的数据是否是正确的这件事都不知道！当你发现自己的程序在其它机器上都很正常，但是在某台机器上总是神秘的崩溃的时候，你就要看看是不是那台机器的内存或者其他存储器出现问题了。

2008硬盘磨损年，你需要这个工具，是的，即使你有备份，只要那备份不是实时的，你还是会需要这个工具。

recoverdisk(1)是FreeBSD 7.0新引入基本系统（/sbin!）的磁盘复制工具，这个工具对于修复硬盘、光盘、存在坏盘上的文件等各种情形都能非常有效地进行迅速修复：它首先尝试以1MB的块尺寸读取和写入数据，随后是64K和512字节（1扇区），遇到错误时会自动跳过，从而最大限度地从损坏的磁盘上恢复数据（如果是用 dd(1) 来恢复数据，通常在遇到坏区时会丢掉整个block，而recoverdisk则是先跳过，然后回过头来用较小的块尺寸重新读取直到失败，而此时主要的数据都已经恢复了）。

目前我知道国内有至少两家主要的互联网公司用了这样的域名，不知道他们用的是什么域名服务器，至少 BIND 9 是不支持这样做的。

RFC 952 - 美国国防部互联网主机表规范中的相关条文如下：

1. A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.). Note that periods are only allowed when they serve to delimit components of "domain style names". (See RFC-921, "Domain Name System Implementation Schedule", for background). No blank or space characters are permitted as part of a name. No distinction is made between upper and lower case. The first character must be an alpha character. The last character must not be a minus sign or period. A host which serves as a GATEWAY should have "-GATEWAY" or "-GW" as part of its name. Hosts which do not serve as Internet gateways should not use "-GATEWAY" and "-GW" as part of their names. A host which is a TAC should have "-TAC" as the last part of its host name, if it is a DoD host. Single character names or nicknames are not allowed.

而成为正式 Internet 规范 STD 13 的 RFC 1034 则如此建议（Section 3.5 Preferred name syntax）：

The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET).

<domain> ::= <subdomain> | " "

<subdomain> ::= <label> | <subdomain> "." <label>

<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

<let-dig-hyp> ::= <let-dig> | "-"

<let-dig> ::= <letter> | <digit>

<letter> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case

<digit> ::= any one of the ten digits 0 through 9

因此，在域名的主机名称中出现 _ 是不规范的，这个字符不应出现在 A RR 中。BIND 9 会明确拒绝这种配置，并且其 resolver 也会拒绝接受这类域名。在使用中，应尽量避免这种情况。