Security

安全：该做什么和不该做什么

很多事情都有Do’s and Don’ts，这里试着整理一下与安全有关的。

本文版权所有 © 2010 Xin LI delphij@FreeBSD.org 保留所有权利；非商业转载请注明出处 https://blog.delphij.net/， 谢绝商业转载。

安全不能建立在"别人不知道"的基础上

“别人不知道"是一种非常常见的安全 假象，举例来说，一种自己设计的山寨加密算法、一个系统中一般人不知道的位置等等，都属于这一类。

将安全建立在"别人不知道"的基础上是非常危险的。首先它会给设计者和用户带来"安全"的幻像，这会直接导致与系统交互的人放松警惕；其次，这样的设计往往留有"后门”，甚至是设计者不知道的后门（因为往往他们并不对这类设计进行充分的、专业的审计），容易被攻击者利用；最后，这种做法存在第三方泄密问题，即，使用这种系统的人，需要提防设计系统的人被其他人买通并泄漏一些秘密的情况。

延缓攻击的手段不能用来阻挡攻击

有许多延缓攻击的手段，例如改变服务的端口（比较常见的如将 ssh 改为 tcp/22 以外的端口），或禁止服务程序显示自己的版本等等，或仅仅简单地启用防火墙，这些手段起到的作用只是延缓攻击，而不应作为一种安全屏障。对于多层次式的安全设计来说，采取这些措施有助于提高检测到入侵的机会，但是它们本身并不会提高安全性。

与前一种情况类似，这种做法也只是让管理员放松警惕。例如以 ssh 为例，有人认为将端口改为一个非知名端口可以避免相关的攻击，但事实是，攻击者依然可以利用 ssh 实现或协议设计中存在的一些漏洞来攻破系统。拥有特定资源的攻击者甚至不需要直接对目标系统实施攻击。在较复杂的攻击手段中，包括简单的 port knocking 一类的保护手法，都可以使用类似分组重放这样的方法来逐步攻破。

采用层次式的安全设计

所谓层次式的安全设计，说的是在一套安全系统中包含不同层次的、存在层次式监控关系的安全结构。例如，将本地包含执行文件的那些文件系统通过一定的方式导出给监控网段的机器，就可以让那些机器在攻击者不知情，或至少不太容易注意到的情况下对入侵进行检测；通过将一些重要日志发到以不同的访问控制机制，甚至不同网络协议的记录设备上，则可以有效地检测入侵者的入侵行为，并为日后的分析留下更多的有用信息。

层次式安全在现实中也有应用。例如产品的质检，除了制造商自己进行的质量控制之外，有时分销商或政府也会进行一些抽样的检查。我们注意到，这些设计中的一个重要的特点是在不同的系统中使用不同的访问控制逻辑。例如，日志服务器必须从特定的客户端，甚至只能从某些隔离的内网登录。此时，延缓攻击的手段可以作为它的一项辅助设施，即其目的并不是阻止攻击，而是吸引攻击者在攻击目标上花费更多的时间，从而帮助入侵检测机制更容易地检测这些攻击。

不要轻信任何东西，包括X.509证书

安全系统的设计者必须对安全有全面的理解和认知。有一句很著名的话叫做 In God we trust, all others must submit an X.509 Certificate，需要注意的是，这里说的是 must submit，并没有说 submit 了就可以 trust 了。

和前面所说的层次式安全设计类似，我们的一个基本假定应该是，一个安全系统中的任何参与者，无论是用户还是计算机或程序，都是可能存在弱点的。安全系统，或用户，都不应轻信任何东西，例如，在特权隔离 (Privilege Separation) 这样一种设计中，特权进程除了完成那个非特权的子进程的请求之外，还有一个任务是维护一个"理性状态机"（Sanity DFA），这个状态机的作用是检测非特权进程的异常状况，如果发生这样的情况，则特权进程有拒绝提供服务，并杀掉非特权进程的责任。作为用户，对于系统给出的响应，除了验证对方的证书之外，也应有常识性的了解和适当的判断。

为什么重复free()比内存泄漏危害更大

C程序设计中，内存操作相关的错误可以说是最常见，同时也是非常隐蔽的一类错误。这类错误往往导致程序莫名其妙地崩溃、耗尽系统资源，或是形成严重的安全弱点。

DNS安全：投毒攻击与缓存服务器的配置

DNS是目前互联网上使用最为普遍，同时也是漏洞很多的一个协议。DNS投毒攻击（Poisoning）是一种比较常见的攻击手法，具体而言，通常一台 DNS 缓存服务器能够影响大量的客户机，通过投毒攻击，能够使得大量用户访问某个具体域名时得到不正确的结果（例如，钓鱼网站，等等）。

实现安全的三种途径

回国的时候和 康神 及端木吃饭的时候聊起过这个话题，这里整理出来。

实现安全有三种主要的手法：基于隐蔽的安全（或者，基于假象的安全）、基于默认配置的安全和基于设计的安全。

基于假象的安全很容易理解，也很容易实现。举一个简单的例子，在一片西瓜地前面戳一块牌子，说这块西瓜地里有一个西瓜里面注射了剧毒。

可以想象，由于信息的不对称（不知道是哪个西瓜有毒，或者根本就没有西瓜有毒），试图偷西瓜的人就会有所忌惮—-如果偷走的西瓜含有剧毒，那么这个西瓜是没办法吃的。然而，这样做有至少三个很致命的弱点：首先，为了实现最大化的利益，很可能瓜地的主人并不真的注射剧毒（或者反过来说，把偷瓜的人毒死并不是他的目的，他的目的是尽可能地保护瓜不被偷）；其次，即使瓜地的主人真的只给一个西瓜注射了剧毒，那么如果有人偷了那个西瓜并且死掉，那么知道这件事的人就可以冲过来直接把所有的西瓜偷走；最后，一个以牙还牙的小偷，很可能会在牌子上留下这么一段话：现在有两个了……

简单地说，基于假象或隐蔽的安全，建立在"别人不知道其机制"的基础上。这样的做法有时能够在一定程度上延缓攻击，但并不能使攻击的成功率降低。将弱点隐蔽这种方法成本比较低，例如，把门钥匙放在门框上、将知名服务端口如ssh（tcp/22）转到不知名端口如tcp/12580上、port knocking技术，以及国内银行常用的Active X插件等等。然而，假象终归是假象，这些方法都不能真正改善系统的安全性。这类做法，充其量只能作为没有其他更好的办法时候的一种临时 workaround，而不能带来长久的安全。

第二种做法，也就是基于默认配置的安全，是一类非常常见的策略。这种做法通常与其他安全机制合并使用。简单地说，采用这种策略的系统，在其出厂的时候是没有暴露在外的弱点的，例如它可能只开启了非常少量，甚至完全不开启任何服务，随后，管理员可以根据需要进行配置来开放一些需要的服务。

关于邮件的安全

今天在 车东 的 blog 上看到一篇说 关于邮件安全的文章，这里也说说我对这个问题的看法。

基于邮件的 XSS 问题其实是困扰 Webmail 供应商的一个很严重的问题。其实，未必是 XSS，有时可能是更简单的内存泄露问题。比较简单的是我 1999 年左右在某国内邮件服务提供商提供的邮件服务发现的一个问题，即，一方面我可以发脚本，获得 cookie；另一方面，我可以用 HTML 去构造一个特殊的 GET 请求（通过 IMG tag）来把这些cookie拿到。

接下来的故事就很简单了，攻击者通过在本地种这些 cookie，便可以访问收到并打开邮件的用户的邮件。严格地说，这甚至算不上一个跨站脚本攻击。解决方法也很简单，在服务器端的session中保存用户的登录 IP 地址。

然而，新一代的攻击变得越来越复杂了。一种典型的攻击是，发送垃圾邮件的人通过各种方法令你访问某个特定的 URL，并借此确认你的邮件地址有效。

Upgraded to MovableType 4.1

Finally found some time to do this, upgraded to 4.1, perhaps this will be faster?

This version is a security update. Is 4.1 production-ready? Who knows…

Mailman对退信的反DoS机制

虽然不做邮件很久了，不过自己有在维护一些社区的邮件列表系统，所以对这方面也比较关注。

以前一直没有仔细研究过Mailman关于退信的处理，最近遇到了一些问题，也看了一些 RFC，这里面提到了一个问题，即，与所有其他的电子邮件类似，退信也是可以伪造的。而对于邮件列表而言，出于建设和谐社会的考虑，往往希望对于经常退信的订户自动采取暂停订阅甚至退订的动作，以减少双方不必要的邮件投递流量。

• ← 上一页