Security

说明：这个程序会在启动专业版时以控件的形式提示并安装。

目前招商银行出于保护用户安全的原因，在其助手中增加了一个功能，即，如果用户来自远程桌面登录，则关闭系统的远程桌面服务，并重新启动系统。

我认为这个「功能」是有很严重的问题的。首先，它没有给用户任何明确的说明发生了此变动，并且直接重启了计算机。由于招商银行过去的良好信誉，我信任并安装了这个控件(有招商银行的签名)，然而，这个控件在没有经过我同意的情况下，擅自变动了计算机的服务设置，并重新引导系统。由于我只有一台桌面机跑跑Windows来使用招商银行专业版，这个功能无疑是让我完全无法使用招商银行的专业版系统了。

The Register报道，在过去两个月中，垃圾邮件呈现了爆炸性的增长，一些机构得到的数据是，垃圾邮件的数量增加了4.5倍。作者并推测，这种现象与近来流行的新型攻击方式——botnet有关。

当然，绝对不仅仅是botnet。近来，垃圾邮件的发送者也改进了他们的发送技术。通过摘取邮件列表内的信息加以随机混合拼装，并透过可变的图片背景色来掩盖真实的图片，垃圾邮件发送者已经能够有效地绕过反垃圾邮件的Bayesian分析等新兴(2002年左右开始大量投入应用)技术了。

前一阵在为cn.freebsd.org的邮件列表做维护时发现，由于网易的邮件系统无法正确地(更具体地说，是以符合标准的方式)进行退信，导致一些无效地址仍然在不停地接收邮件，导致邮件系统的管理员必须手动处理这些退信产生的报告。后来在挖掘了mailman的文档之后，发现它支持djb的VERP退信。

相比处理符合标准的退信来说，VERP所需的编码量更少，并且对于不符合标准的退信也能够做很好的处理。从开销上说，由于VERP不需要parse整封邮件，因此也不会导致性能上的折损，甚至由于不需要进行任何解信操作，这种做法在性能上应该会优于标准的做法。

写了两个小程序，分别实现了RSA和Caesar(rot13)算法。感觉自己写命令行程序UI的能力下降了：（

说说这周发生的事情。

这周初步解决了困扰很久的ssh密码扫描蠕虫的问题。习惯上我是上来就禁止口令登录的，所以这种扫描(据蜘蛛说，这是一种叫做scanssh的虫子，不过我手头没有蜜罐资源，所以也就没有捕捉样本)没什么用，不过这种虫子讨厌的地方在于它能够花费几个小时的时间去穷举你的口令，而且是不同的帐号，这会产生几百KB的日志。

传统上判断操作系统是通过扫描进行的，例如，发一个SYN+FIN的包，看对方如何回应，由于各式各样的原因，包括性能考虑，或编程上的疏忽，这些包会留有一些特征。这类典型的应用是nmap和NetCraft。

这类方法有它的作用，对于尝试攻击的人来说，这些特征能够给他们相当多的信息，这些信息甚至足以让攻击者找到一击毙命的攻击方法(例如，发现那是一台没有打过补丁、没有防火墙的Windows)。然而，它也有一些不可避免的局限：

• 并不是所有地区的法律都允许网络扫描行为。除此之外，这种行为通常也是不受欢迎的，至少它不是一种友好的行为。(事实上，发生在互联网上的扫描行为几乎都不是友善的)
• 对于NAT后的服务器，它只能判断出NAT网关所用的操作系统，而无法判断其后的系统所用的操作系统。
• 事后的「反击」或「报复」性扫描往往于事无补，在第一击的时候遏制攻击，对于安全相当重要。

之前一直有些头疼的ssh虫问题，很令人吃惊地找到了一个解决方法。在扫描感染IP的TCP特征之后，发现这些机器的共同特征——他们都用的是Linux。

很幸运地，我不使用Linux，FreeBSD附带的pf提供了一项非常有意思的强大能力(这项能力源于OpenBSD的pf)，即按操作系统来控制访问。其它用法还包括例如，禁止没有打补丁的Windows访问，让不同用的操作系统访问得到不同的内容等等。

考虑到Linux如此容易感染ssh蠕虫，我决定采用下述pf策略：

block in quick proto tcp from any os “Linux” to any port ssh

决定reboot之前彻底封禁来自这些机器的IP包。

58.181.2.72
60.31.211.5
60.248.202.210
61.154.12.95
67.15.164.194
67.15.197.26
202.8.85.116
202.111.128.231
210.13.41.1
210.29.163.57
210.117.6.185
210.221.221.57
211.95.160.46
211.99.194.3
211.147.224.41
211.150.123.229
218.1.65.233
218.23.49.228
218.31.157.27
218.55.227.175
218.188.0.56
218.249.15.254

The patch is available at: http://people.freebsd.org/~delphij/for_review/bsd_gzip/. Please note that this is considered experimental and it is preliminary for FreeBSD for now, while I think it is very mature code and has been available on NetBSD for years. Positive and negative feedbacks are all welcome.

最近一周FreeBSD发布了多个安全公告，其中有一个gzip的安全问题是Google的人发现的，由于gzip目前已经长期处于无人维护的状态，我认为是时候把这个程序杀掉了。(这次安全更新导致了某些文件无法解压缩)