Security

记一笔关于iPad的DFU mode

由于送修 iPad 最终没有修好，因此店家给提供了一台二手的 iPad。作为不折腾就会死星人我觉得显然应该重刷一遍固件（卖家已经重新清空了数据），因此做了一次 DFU mode 固件更新。

Heartbleed之危机公关处理

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

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

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

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

大家可以放心了！

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

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

OpenBSD fork 了 OpenSSL

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

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

一种针对 ntp 服务的 UDP 杠杆式攻击

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

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

一种针对DNS缓存服务器的杠杆式攻击

今天发现一台国内的机器流量异常，检查发现这台机器上运行的 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)

启用 SPDY

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

增加了一个 DNSsec 的数据采集

📜 历史文件已不具备现实意义

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

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

记一下PGP密钥的转移过程

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

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

检测中间人攻击

今天在邮件列表里看到 John Nagle （就是发明 TCP Nagle 算法的 那个 John Nagle）提到希望 OpenSSL 提供一些帮助自动检测中间人攻击的 方法。简单地说，因为中间人攻击会改变双方看到的加密流（密钥变了），因此，如果上层协议包含了加密流的某些特征，攻击者想要实施中间人攻击的成本就会大大增加。他同时举了一个例子，一种早期的加密电话会在话机上显示从密文开始的部分计算的两位数字，而通话双方则通过通话来确认数字相同，这样，中间人攻击的实施者就必须解析语音并替换掉相关的字词来避免被发现。

简单的例子是，比如准备发出 HTML/XML 之前，首先发出它们在加密之后的密文的 hash。攻击者如果简单地截获并重新加密文档，则攻击会被立即发现；如果缓冲并重新计算结果，必然会引入延迟；如果事先准备好文件并做好计算，则需要在看到文件之前就准备好这些资料（不过实际应用中，攻击者很可能会选择这么做）。这些都会增加实施中间人攻击的困难。

FreeBSD.org 这次的入侵事件

我回国之前， FreeBSD 安全团队内部正在准备一项重要的安全公告，不过这次不是由于 FreeBSD 的代码本身，而是由于 FreeBSD 项目集群中的一部分受到了入侵。这份公告后来于 11 月 17 日正式 发表。

• ← 上一页
• 下一页 →