选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……
DNS是目前互联网上使用最为普遍，同时也是漏洞很多的一个协议。DNS投毒攻击（Poisoning）是一种比较常见的攻击手法，具体而言，通常一台 DNS 缓存服务器能够影响大量的客户机，通过投毒攻击，能够使得大量用户访问某个具体域名时得到不正确的结果（例如，钓鱼网站，等等）。
为了减少DNS投毒攻击的威胁，有两项非常重要的安全实践，其一是将权威DNS服务器（这些服务器负责解析某些特定的域名）与缓存 DNS 服务器（这些服务器负责代替其他机器解析域名，并将结果在其本地缓存，以减少权威 DNS 服务器负载和不必要的网络间流量）分开部署，并启用 DNSsec；其二，是限制 DNS 缓存服务器的可访问来源 IP，并在边界路由器上过滤来自不受信路由器，但来源 IP 字段是本网络的数据包。
由于 DNSsec 目前还没有被广泛部署，限制能够访问 DNS 缓存服务器的来源 IP 是缓存服务器配置的一项非常重要的部分。我们知道，UDP协议中，来源IP字段是可以伪造的（这也是为什么TCP协议要比UDP安全的原因，因为它使用三次握手机制来提高伪造来源 IP 的难度），而 DNS 协议的普通查询建立在 UDP 之上（这是出于显而易见的性能考虑；在实际实现中，许多 DNS 服务器支持以 TCP 方式进行查询），而其事务 ID 只有 16 个 bit，很容易伪造，因此，攻击者通过向 DNS 缓存服务器发出查询受害域名的请求包，并同时发送大量伪造的 DNS 回应，并在这些伪造回应中人为地设置较大的 TTL，就很有机会"污染"缓存 DNS 服务器的本地缓存，并在其中长期滞留，从而达到影响更多客户机的目的。
针对 DNS 投毒攻击，目前并没有真正的遏制方法，所有采取的措施，包括 DNS 缓存服务器的查询端口随机化等等，都只是将攻击者成功的机会减少一些量级。真正解决这类攻击的方法只有 DNSsec 和 IPsec。
对于企业网络管理员来说，通过在企业内部架设 DNS 缓存服务器并进行合理的配置，能够有效地减少 DNS 投毒攻击的风险。这类网络往往采用的是不被路由的 RFC 1918 内网 IP 地址，并通过 DHCP 来对客户机进行配置，因此可以通过后者来将客户机 DNS 指定为内部的 DNS 缓存服务器。具体来说，企业内部 DNS 应配置为只监听内网，同时在访问外网时，尽可能利用 NAT 机制对其访问源地址、源端口进行随机化处理。
Read more...在 Apache 文档中提到，不能在单个 IP 上同时有多个按名字识别的虚拟主机(“named virtual host”)。不完全是这样。
HTTPS协议的过程是：服务器首先与客户机之间进行服务器身份验证并协商安全会话，然后，客户端向服务器发送 HTTP 请求。这样一来，在客户端开始发送请求之前，服务器就已经把证书发给了客户端（客户端根据本地的根证书去验证证书链，等等）。而最重要的是，为了表明身份，这个证书的周知名称（“Common Name”）填写的应该是域名，否则浏览器会给出警告。
既然在这个过程中，客户端就所访问的域名所处的地位是"被告知"的地位，因此，客户端再发出的 Host: 请求头也就显得不那么有意义了。另一方面，如果客户请求的域名与周知名称不符，浏览器也会给出警告。至少，在表面上看是这样。
不过，对于自行签署的证书，以及一些发证机构而言，其实还可以签署一种普适HTTPS证书，这种证书的周知名称一栏是 *.domain.tld 这样的形式，即其主机名部分可以是任意字符串，而只有域名部分是确定的。
当然，这种证书的安全性有一定的负面影响：由于一个证书可以验证整个域下面的所有服务器，一旦其被破解，则所有加密通讯也就同时失密了（当然，可以每台服务器使用自己的单独的证书），不过这个问题并不是太严重，通常还算是尚可接受的范围。另一个潜在的影响是，某些手机上运行的浏览器不能正确处理这种证书，不过这个问题仅限于希望给手机提供服务的网站。
因此，简而言之，符合这样几个条件的前提下，是可以在同一个IP上部署多个HTTPS虚拟主机的：a) 这些虚拟主机是同属于同一域名的子域名 b) 拥有普适证书 c) 正确地配置Apache。
Apache配置要点
Disclaimer: 这是一篇科普文章，不会涉及太多的技术细节。
简单地说，驱动程序是操作系统与硬件（有时也包括其他的软件或在硬件上运行的firmware）之间的一种接口程序。对于操作系统来说，驱动程序是非常重要的
不过，在现代系统中，多数情况下，驱动程序并不只是简单机械地翻译操作系统的请求，更多的时候，驱动程序还有另外的很重要的作用，即绕过硬件本身的问题，常见的例如，临时加载一份较新版本的固件、针对某些版本的硬件禁用某些会导致问题的特性、分配内存的时候确保按边界对齐或只在前4GB分配以绕过DMA引擎寻址能力差的问题、通过增加延迟来解决硬件制造时对时序过于敏感的问题，等等。通过驱动程序绕过这些问题，能够让用户看不到（或者，至少在硬件负载不大的情况下看不到）问题的存在，并消除一小部分问题（例如原先随硬件发布的固件版本存在一些问题，而又没有提供更新固件的接口，新版本的驱动可能会在系统引导的过程中上传一份新版的固件到设备的临时存储）。
一般来说，驱动程序可以在逻辑上分为以下三个部分：
Read more...如题。
不过这一次因为-CURRENT code slush的缘故，应该不会在 8.0-CURRENT 里面引入了（Ed在svn里面建立了另一个branch来做）。我想从各方面考虑，9.0-RELEASE里面正式砍掉gcc那一套东西应该不会是很困难的事情。传统上 FreeBSD 的代码用到了很多gcc的扩展，因此可能还需要一段时间。
包含CLang的FreeBSD -CURRENT可以在 projects/clangbsd/ checkout。包含 CLang 的 LLVM 预计将能够在今年9月正式发布。
Read more...我今天话放这儿。
Read more...回国的时候和 康神 及端木吃饭的时候聊起过这个话题，这里整理出来。
实现安全有三种主要的手法：基于隐蔽的安全（或者，基于假象的安全）、基于默认配置的安全和基于设计的安全。
基于假象的安全很容易理解，也很容易实现。举一个简单的例子，在一片西瓜地前面戳一块牌子，说这块西瓜地里有一个西瓜里面注射了剧毒。
可以想象，由于信息的不对称（不知道是哪个西瓜有毒，或者根本就没有西瓜有毒），试图偷西瓜的人就会有所忌惮—-如果偷走的西瓜含有剧毒，那么这个西瓜是没办法吃的。然而，这样做有至少三个很致命的弱点：首先，为了实现最大化的利益，很可能瓜地的主人并不真的注射剧毒（或者反过来说，把偷瓜的人毒死并不是他的目的，他的目的是尽可能地保护瓜不被偷）；其次，即使瓜地的主人真的只给一个西瓜注射了剧毒，那么如果有人偷了那个西瓜并且死掉，那么知道这件事的人就可以冲过来直接把所有的西瓜偷走；最后，一个以牙还牙的小偷，很可能会在牌子上留下这么一段话：现在有两个了……
简单地说，基于假象或隐蔽的安全，建立在"别人不知道其机制"的基础上。这样的做法有时能够在一定程度上延缓攻击，但并不能使攻击的成功率降低。将弱点隐蔽这种方法成本比较低，例如，把门钥匙放在门框上、将知名服务端口如ssh（tcp/22）转到不知名端口如tcp/12580上、port knocking技术，以及国内银行常用的Active X插件等等。然而，假象终归是假象，这些方法都不能真正改善系统的安全性。这类做法，充其量只能作为没有其他更好的办法时候的一种临时 workaround，而不能带来长久的安全。
第二种做法，也就是基于默认配置的安全，是一类非常常见的策略。这种做法通常与其他安全机制合并使用。简单地说，采用这种策略的系统，在其出厂的时候是没有暴露在外的弱点的，例如它可能只开启了非常少量，甚至完全不开启任何服务，随后，管理员可以根据需要进行配置来开放一些需要的服务。
Read more...LLVM 是 Illinois 大学发起的一个开源项目，它到底是什么呢？从字面上看，它是一个虚机系统，然而这又和之前为大家所熟知的 JVM 以及 .net Runtime 这样的虚机不同，它提供了一套中立的中间代码和编译基础设施，并围绕这些设施提供了一套全新的编译策略（使得优化能够在编译、连接、运行环境执行过程中，以及安装之后以有效的方式进行）和其他一些非常有意思的功能。
为什么这个项目很重要呢？对于普通的开发人员来说，LLVM计划提供了越来越多的可以使用、编译器以外的其他工具。例如代码静态检查工具 LLVM/Clang Static Analyzer，是一个 Clang 的子项目，能够使用同样的 Makefile 生成 HTML 格式的分析报告；而对关注编译技术的开发人员来说，LLVM提供了很多优点：
Read more...“For 27 years, Sun has stood for courage, innovation, a willingness to blaze trails, to envision and engineer the future.”
Good luck, Sun!
Read more...可怕，很可怕。
其实也没啥，年度对帐单其实就是把月度对帐单里面的帐目做了一下summary，然后分门别类地把刷卡的明细排列出来，告诉你每个月花了多少钱，有多少调整金额和charge（我从来不相信国内某银行宣传材料上写的那种月底不把钱还清是好的理财策略的说法，无论如何不还清导致最终的还款现值pv都会比还清的高，所以这项几乎一定是 < 0的）。
不过我比较好奇的是这么大量的数据是如何存储和查询的。难不成是事先查询好保存成一个待下载的数据吗？想想看，这么大用户量跟数据量（当然，热数据很少，而且访问模式其实和邮件比较类似），还是需要动些脑筋才能做好的，也许这也是当天交易只减信用额度而不反映到实时帐单上的原因。
Read more...和蛇头GG讨论了一个关于卖票的问题，简单地说是票很有限，需求量很大，如何能够尽可能高效地让票以尽可能公平的方式卖出去。
我设计了一个分布式的结构来解决这个问题，当然这个原型可以进一步改进，此处按下不表。记录一下我对这个结构公平性的描述的一个比喻：
“因为其他人也hash了，或者换句话说，这个系统其实不介意一开始有人就注定拿不到票。 就跟一大群人排队抽签是一样的道理，其实这个就相当于说一帮人排队抽签决定去拿一个信封， 然后拿到空信封的可以重新排队抽签，要么拿到票。”
这个系统其实要求参与进来的客户机一起参与计算（但是这些计算并不会明显加大服务器系统的负载），有一些能想到的缺陷，也许需要克服，也许根本不是问题？先把想法记下来再说。
Read more...