这次回北京之前的周末，FreeBSD安全团队发表了内部通知，发现 FreeBSD.org 有些机器被入侵，最近终于做了全面披露了。目前，基本的代码审计和攻击检查已经做完，部分机器还在重装的过程中。

对 FreeBSD 这样的开源项目来说，在基础设施遭到攻击之后，首先必须被怀疑的便是有可能有人在代码库中植入了新的后门。由于代码量十分巨大，逐行审计是非常不现实的。由于 FreeBSD 在 BSD 时代即采用了版本控制系统（最早 BSD 时代是 SCCS，FreeBSD早期是CVS，现在是 subversion），因此，每一行代码的来源，包括作者、具体的修改时间，以及为什么那样修改等等，都可以很容易地查找到。

FreeBSD 采用了许多种不同的方法来同步修订历史，这包括了旧式的 CVSup、通过邮件的 CTM，以及 svnsync。CVSup类似于rsync，但是是为 CVS 优化的。FreeBSD 的 CVS 代码库之前是通过 SVN export 出来，然后通过CVSup发给所有的下游镜像，其好处是比rsync节省带宽和时间（因为CVSup会记录修改的文件信息，两相比较便不必完全传送文件的 stat 数据了），缺点和 rsync 一样，如果源站点的数据出了问题，备份也会被修改，而且是不可逆的。CTM和svnsync都是类似会计记账的方式，也就是说一旦有了修改便不可反悔（CTM更通过邮件发出，从而可以被第三方备份服务永久性记录），从而便于审计。

所幸的是，目前为止的调查中，并没有迹象显示 CVS 代码库或 subversion 代码库中混入了任何未经授权的变动。为了保险起见，FreeBSD.org 的管理员将 cvs 改为从 subversion 完全导出（因为 svn 的审计比较容易）覆盖，以避免某些没有检测到的问题给用户带来影响。

我们能够从这个事情中学习什么教训呢？我想，最重要的是，备份应该采用和源数据不一样的更新、删除逻辑，因为这样才可以知道具体发生了什么变化。也就是说，数据源这边在备份那边的权限应该是不能改变历史记录数据的，比如只允许添加，等等。

关于这次入侵的具体情况，等有时间再写出来。