Security

今天早上4点多就爬起来准备发安全公告（友商约的是早上5点发），一刷，OpenSSL官方已经正式发表了（时间大约是4点30），于是立即开始相关手续，commit修正，发公告，通知CERT，这些不表。

今天看到 John Baldwin commit 的这个 r266391 增加了相关支持。

RDSEED 和 RDRAND 的区别是 RDRAND 采用的是 128-bit AES 密钥的 CTR-DRBG，而 RDSEED 则是直接从真随机数发生器中获得输出（两者并不是直接使用真随机发生器的输出，这些输出是做过 AES-CBC-MAC 处理的，防止外界通过观测输出了解内部运行的细节），较慢，后者具备 multiplicative prediction resistance 特性。

这次 Heartbleed 安全漏洞之后，阿里巴巴集团的多个产品均迅速修复了漏洞（好事），但事后的公关处理做的却有待改进。

我在微博上看到有人转发 阿里安全 在4月9日13:01发表的一篇微博，内容如下：

关于OpenSSL某些版本存在基于基础协议的通用漏洞，阿里各网站已经在第一时间进行了修复处理，目前已经处理完毕，包括淘宝、天猫、支付宝等各大网站都确认可以放心使用。

紧接着， 支付宝 转发了 这条微博：

大家可以放心了！

我并不是阿里巴巴/支付宝的客户，不过看到有人转发这条消息，我半开玩笑地 回了一句：

冲这句「大家可以放心了」就没法放心了……

OpenBSD [捐款链接] 又一次出手为民除害了！ Undeadly报道： OpenBSD has started a massive strip-down and cleanup of OpenSSL。

这次 Heartbleed 的事情搞的我十分不爽，这事固然不能全怪 OpenSSL 的开发者，但是整个过程非常的让人不舒服，具体的就不多说了。等过个几十年再回头看看这次这件事情再说吧。

今天(2014/01/14)发了4个安全公告和2个勘误公告，其中 FreeBSD-SA-14:02.ntpd 是针对 NTP 的这种攻击的因应措施。

攻击的原理是通过发送一个小包（GET_MONLIST），得到大体积的回应。而由于 NTP 使用了 UDP 协议，因此攻击者可以伪造源 IP，从而，通过较小的流量代价，即可利用其他服务器作为杠杆来攻击受害者。

📜 连 Google+ 都没了。

Google 在一篇关于 Google Maps 更新的 blog 中提到， Google Latitude 即将关闭 并转入 Google+。（另外话说，这事有必要这么偷偷摸摸的吗？）

我目前还在使用的 Google 服务有：

今天发现一台国内的机器流量异常，检查发现这台机器上运行的 DNS 缓存服务被人用作了攻击的放大杠杆，这里简单记一下。

发现流量异常，首先当然是检查服务器上的 TCP 会话，发现了一些不太正常的东西，关闭之后流量减少，但仍然没有回到正常水平。

于是听包。这一听发现一大片：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

07:39:53.271744 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.271772 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.271784 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.271792 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.274225 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.274252 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.274262 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.274270 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.291822 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291850 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291860 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291869 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291877 IP 92.XX.XX.148.56278 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)

之前 Frank 同学提到了这个问题，所以今天花了些时间来配置。 nginx 对 SPDY 的支持是一项比较新的特性，只有在 1.3.x 版本以上才支持。FreeBSD 的 nginx-devel 默认并不启用 SPDY，需要在 make config 的阶段启用。

📜 我认为不再需要收集更多数据了。

这个 blog 的首页底部增加了两个图，用来测试访客是否启用了 DNSsec 验证。这项服务是由 Matthäus Wander 和 Torben Weis 提供的，点击这个连接可以检查自己的 DNS 缓存服务器是否会进行 DNSsec 验证。如果没有，可以参考我的这张 作弊条 来自行配置。

今天上午，我和现任 FreeBSD 安全长官 Simon 完成了一次 PGP 密钥的转移，这里记一下过程。

由于这个密钥用于签署安全公告和声明等等，因此非常重要。发送方对于密钥做了三重加密：第一重是 GnuPG 本身的密钥密码；第二重是 AES；第三重是我本人的 PGP 公钥。加密后的结果放到了一台可信的中转服务器上，然后以安全方式取走；用我的 PGP 密钥解密之后，通过两个不同的渠道分别发送 AES 密钥；最后一步的密码采用加密方式发给我，我在解密成功之后，修改密码，并销毁全部中间文件。