前几天从 Sourceforge 上的一篇文章了解到 Complemento 这个工具包，其中的 LetDown 用来做网站网络的压力测试，预防 DoS (拒绝服务)攻击还是不错的，起码可以熟悉一些常见的场景。另外，这个工具可以比较方便的嵌入到 Python 脚本中，用来做更大规模的压力测试(注意随意测试是有风险的)。
Complemento 的 HowTo 文档比较完备，可以用作参考。这个工具包现在也已经内置到 BackTrack 这个用作安全渗透的 Linux 发行版中了。
最近一两年，DDoS 攻击在国内现在更加"流行"而且商业目的明显，经常用做打击竞争对手的武器。当然现在也不只是打Web服务器，也可能会打打 DNS 什么的...
其实我非常好奇各个公司的技术人如何应对 DDoS 的，除了拼硬件，拼带宽，或许饭桌和钱是最好的防御手段。
--EOF--
BTW，Nessus 仍然是扫描系统漏洞的最佳工具，居家旅行...必备...
关于支付宝的证书使用中出现的 800A138F 错误是个老问题了。这里尝试对这个问题做说说个人看法。
历史原因说来话长，我尽量说得简要一些。首先需要涉及证书（Certificate ）在操作系统中通过 ActiveX 形式的登记（Enrollment ）这事儿。在 Windows XP 之前，延续使用的是 XEnroll.dll 这个库接口。但是因为这东西比较古老，且出于"更安全"、更方便开发的角度上考虑，从 Windows Vista 与 Windows Server 2008 开始引入 CertEnroll.dll （参考)。这个差异也导致了支付宝证书在不同版本的操作系统间的导出再导入可能会出现问题。
一般来说，错误信息类似如下：
错误原因：'cenroll' 为空或不是对象，错误代码：800A138F。
Microsoft XEnroll，在产生密钥对时失败！错误原因：'null'为空或不是对象，错误编码：800A138F
(这个错误信息表明是使用 XEnroll.dll 过程中出现了问题。)
不知出于什么考虑，微软上 Vista 的时候居然没考虑到 XEnroll.dll 这东西没了，向后兼容性如何处理呢? 而有些第三方开发厂商也不是未卜先知。所以，Vista 大量涌入市场的时候就暴露出来了问题(当然第三方开发商也要狠狠的打自己自己一个嘴巴)。微软的拿手解决方案就是发行一个补丁 ，在 Vista 和 Windows Server 2008 上也能使用老的 "Certificate Services Web enrollment pages" （其实就是给 操作系统里安装一个 XEnroll.dll 库)。参见知识库 922706 。
这个 800A138F 错误大多数时候出现在 Vista 系统上。也是有很多其他客观因素的，其中比较主要的一个是 User Account Control(UAC)这个特性带来的麻烦。UAC 默认级别替用户"多考虑许多"，安全级别控制的很好，好到这个安全成了麻烦。这个如果通过系统管理员用户一项一项的去设置的话，是可以对付安装上的，但是不可避免的是，很多用户不是操作系统专家，甚至不知道什么是"系统管理员"，所以如果把 UAC 关闭的话，可能会直接省了不少麻烦，但是这样的话，又有很多用户会觉得安全性受到了威胁，也难免抓狂，这个选择很是两难。
除了 Vista ，在 XP 上也会遇到这个错误。一般来说，某些第三方的小工具会禁止 Microsoft Certificate Enrollment CAB (这也是非常头疼的一个问题)，这种情况下可以考虑修改注册表或者是在这类工具的插件管理的地方把这个 CAB 放开。或者考虑修改注册表的方式 (参考)。
我的个人建议是：不要使用 Windows Vista ！(请默念10遍：Windows Vista 是个烂系统) 这是个微软内部都承认失败的操作系统。使用老的 Windows XP 吧，毕竟，微软已经承诺对 XP 延续支持到 2011 年了。至于 Windows 7 ，尽管叫好声不断，但我们现在只能期待。
另外，对于 IE 用户，建议使用 IE7 或者 IE8 (IE6 出来已经有 10 年，老掉牙矣，且从安全性的角度上考虑也的确不佳)。
以上是对支付宝证书错误 800A138F 的一点非专业解释，兄弟我并非 Windows 操作系统专家，期待对 Windows 操作系统更为熟悉的朋友进行补充以及纠正。现在情况已经如此，一刀切解决问题似乎不太现实，没有理由推卸任何责任(尽管个别读者可能这么认为)，只能尽量、尽快改进--现在已经在和合作方一起进行对此错误的处理！
用户的痛苦我也是感同身受！这并非客套话。
--EOF--
注意：这篇文章有实效性，且包括作者本人主观看法。
更新：从用户的反馈来看，Windows 7 比 Vista 易用性和性能好了很多，推荐使用。
跨站脚本攻击(XSS, Cross Site Scripting) 可能是目前所有网站都比较头疼的问题，Google 也不例外。这次 Google 又做了一次雷锋，把内部用来审计 XSS 的工具开源了：ratproxy。
Ratproxy 工作流程：
在我的 Ubuntu 下测试了一下，需要说一下的是，本地系统需要安装 libssl-dev 与 openssl 。
$ sudo apt-get install libssl-dev openssl
$ cd ratproxy ; make
然后就可以提交类似:
$ ./ratproxy -v . -w foo.log -d foo.com -lfscm
然后，人肉点击相关的页面进行测试了。这个工具的设计思路还是很值得借鉴的，推荐对安全感兴趣的同学读一下源代码。
ratproxy 的作者是 MIchal Zalewski，一个波兰的白帽子黑客。他的个人主页上能找到更多有趣的工具。
--EOF--
另参见另一份试用报告
在公司洗手间看到一个关于“密码提示问题”的笑话。不过仔细一琢磨发现不是这回事儿。电子商务网站几乎都设置密码提示问题的。一个有趣的现象是有些 UE(或交互设计师？反正是干这个活儿的人) 工程师自己都没搞清楚这个 "密码提示问题“ 要给用户什么。
对于 UE 我是门外汉，不过我理解的这个过程就是建立公钥和私钥：公开的密钥即“密码提示问题”，是其他用户也可以看到的)，只有自己知道的叫私钥，也就是答案。很明显，既然说到私钥，那么私钥的保护就是关键。设计者有必要引导用户保护好自己的私钥。
我们先看个例子(类似的网站很多，就别说具体哪家了，都那鸟样)：
告诉我，用户需要填入"正确"的还是"错误"的答案?
就这个密码提示问题来说，如果没有直接明白的告诉用户正确的使用方式(你的用意!），那么很多用户还是输入“真实”的答案。除了第一个和第四个问题之外，其他几个问题我想在SNS 网络如此盛行、搜索引擎如此强大的今天，要得到答案是不存在什么障碍的。用户并不傻，但用户也不是都会耍小聪明，如果你去做个统计，我相信会有大量的用户输入的答案是可以猜到的。
或许有人会说，"没事啊，即使别人猜到了这个答案，密码最后也会发到原用户自己的信箱里的啊"。拜托，安全本来就是一环套一环的，这个如果被搞定了，你能确保用户的信箱不会被搞定么?
到各个站点查看帮助说明，发现原易趣的说明还是比较到位的(是否在用户设定问题的时候提示，我就不知道了)：
选择一个容易回答但其他人难以猜到答案的问题。
密码提示问题与任何其他机密信息一样重要，所以不要向其他人透露。
为安全起见，可以为问题提供并不正确或答非所问的回答。
前几天白鸦有篇文章《跟着用户走到沟里》，其实很多时候网站是设计者把用户带到沟里。
--EOF--
