June 2009 Archives

27了,不能再假装年轻了。

Heal The World (Lyrics)

| No Comments | No TrackBacks

In memorial of Michael Jackson (1958.08.29 - 2009.06.25)

"Heal The World"

There's A Place In
Your Heart
And I Know That It Is Love
And This Place Could
Be Much
Brighter Than Tomorrow
And If You Really Try
You'll Find There's No Need
To Cry
In This Place You'll Feel
There's No Hurt Or Sorrow

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 机制对其访问源地址、源端口进行随机化处理。

有时,企业内部会希望有一些内部域名来方便员工访问一些内部的资源。习惯上,这些 NS 记录并不会对公网上的 DNS 服务器发布,因此,如果 DNS 缓存服务器没有设置上级 forwarder,就可能会无法解析这类域名。想要解决这个问题,最简单的办法就是配置一组 forward 域,例如,在 BIND 9.x 中,使用类似下面的设置:

zone "internal.example.com" {
    type forward;
    forward only;
    forwarders {
        172.16.2.53;
    };
};

在上面的配置中,当有用户请求 internal.example.com 下的域名,例如 www.internal.example.com 时,缓存服务器便会把请求直接转发给对应的 DNS 服务器, 172.16.2.53 (这个服务器应是 internal.example.com 的权威解析)了。

在 Apache 文档中提到,不能在单个 IP 上同时有多个按名字识别的虚拟主机("named virtual host")。不完全是这样。

HTTPS协议的过程是:服务器首先与客户机之间进行服务器身份验证并协商安全会话,然后,客户端向服务器发送 HTTP 请求。这样一来,在客户端开始发送请求之前,服务器就已经把证书发给了客户端(客户端根据本地的根证书去验证证书链,等等)。而最重要的是,为了表明身份,这个证书的周知名称("Common Name")填写的应该是域名,否则浏览器会给出警告。

既然在这个过程中,客户端就所访问的域名所处的地位是"被告知"的地位,因此,客户端再发出的 Host: 请求头也就显得不那么有意义了。另一方面,如果客户请求的域名与周知名称不符,浏览器也会给出警告。至少,在表面上看是这样。

不过,对于自行签署的证书,以及一些发证机构而言,其实还可以签署一种普适HTTPS证书,这种证书的周知名称一栏是 *.domain.tld 这样的形式,即其主机名部分可以是任意字符串,而只有域名部分是确定的。

当然,这种证书的安全性有一定的负面影响:由于一个证书可以验证整个域下面的所有服务器,一旦其被破解,则所有加密通讯也就同时失密了(当然,可以每台服务器使用自己的单独的证书),不过这个问题并不是太严重,通常还算是尚可接受的范围。另一个潜在的影响是,某些手机上运行的浏览器不能正确处理这种证书,不过这个问题仅限于希望给手机提供服务的网站。

因此,简而言之,符合这样几个条件的前提下,是可以在同一个IP上部署多个HTTPS虚拟主机的:a) 这些虚拟主机是同属于同一域名的子域名 b) 拥有普适证书 c) 正确地配置Apache。


Apache配置要点

  • 在HTTPS(TCP 443)端口上配置NameVirtualHost,例如 NameVirtualHost *:443
  • 为每个虚拟主机配置同样的 SSL 设置(事实上只有第一个会生效)
  • 为每个虚拟主机配置对应的ServerName

驱动程序是什么

| No Comments | No TrackBacks

Disclaimer: 这是一篇科普文章,不会涉及太多的技术细节。

简单地说,驱动程序是操作系统与硬件(有时也包括其他的软件或在硬件上运行的firmware)之间的一种接口程序。对于操作系统来说,驱动程序是非常重要的

不过,在现代系统中,多数情况下,驱动程序并不只是简单机械地翻译操作系统的请求,更多的时候,驱动程序还有另外的很重要的作用,即绕过硬件本身的问题,常见的例如,临时加载一份较新版本的固件、针对某些版本的硬件禁用某些会导致问题的特性、分配内存的时候确保按边界对齐或只在前4GB分配以绕过DMA引擎寻址能力差的问题、通过增加延迟来解决硬件制造时对时序过于敏感的问题,等等。通过驱动程序绕过这些问题,能够让用户看不到(或者,至少在硬件负载不大的情况下看不到)问题的存在,并消除一小部分问题(例如原先随硬件发布的固件版本存在一些问题,而又没有提供更新固件的接口,新版本的驱动可能会在系统引导的过程中上传一份新版的固件到设备的临时存储)。

一般来说,驱动程序可以在逻辑上分为以下三个部分:

如题。

不过这一次因为-CURRENT code slush的缘故,应该不会在 8.0-CURRENT 里面引入了(Ed在svn里面建立了另一个branch来做)。我想从各方面考虑,9.0-RELEASE里面正式砍掉gcc那一套东西应该不会是很困难的事情。传统上 FreeBSD 的代码用到了很多gcc的扩展,因此可能还需要一段时间。

包含CLang的FreeBSD -CURRENT可以在 projects/clangbsd/ checkout。包含 CLang 的 LLVM 预计将能够在今年9月正式发布。

Monthly Archives

Pages

OpenID accepted here Learn more about OpenID
Powered by Movable Type 5.2.3