2009年3月8日星期日
译：IIS安全检查清单（中英对照）
The following checklist is a summary of the security points which should be checked prior to bringing an IIS server online. In cases where these points are not followed, the admin may want to securely document the known security issues for referral should a security compromise occur.
下面是安全要点的简要清单，在检查这些安全要点之前需要确保IIS服务器在线。在违反下面安全要点的情况下，管理员可能需要了解安全文档中对已知的安全问题应该发生的安全危害的介绍。
q No IIS on a domain controller
1.域控制器上没有IIS。
q Install only services needed (ftp, www, smtp, nntp). Mailing out does NOT require smtp; use CDOSYS.DLL (a COM based method native to Windows) or a 3rd party executable like blat.exe for web applications that require outgoing mail.
2.仅安装需要的服务( FTP,WWW,SMTP,NNTP)发送邮件不需要SMTP服务；可以使用CDOSYS.DLL（一个Windows提供的COM组件）或者使用第三方的Web应用程序例如：blat.exe来发送邮件。
q Virtual directories are NEVER used across servers.
3.从不使用跨服务器的虚拟目录。
q The underlying Windows OS has been secured.
4.底层的Windows操作系统是可以靠的。
q Only system administrators are local administrators.
5.仅系统管理员是本地管理员。
q Websites should NEVER be on the system drive.
1.网站绝不应该在系统驱动器上。
q Setup SSL if transmitted information is sensitive. Require SSL (Remove ability to access via port 80) if SSL is enabled.
2.如果传播的信息是敏感的需要安装SSL，如果SSL已经启用则请求SSL（通过访问端口 80 的删除能力）。
q All FTP sites, and as needed WWW sites should enable IP filtering for stanford-only sites. Ipsec filters can be used to accomplish this.
3.所有的FTP站点和需要的万维网站点需要启用对“stanford-only”的站点进行IP筛选。IPSec筛选器可用于实现这一目标。
q Virtual directories should be used as little as possible. They aren’t needed unless you need to span drives. And if you need to span drives reconsider based on the security implications.
4.虚拟目录应尽少使用， 除非您需要跨驱动器否则不需要使用虚拟目录。 如果需要跨驱动器，需要基于安全隐患重新考虑。
q Remove NTFS write perms everywhere possible.
5.移除NTFS驱动器下所有可移除的写入权限。
q Don’t make it easy to find your scripts and code. Hackers target code seeking vulnerabilities they can use to take control of the server. Good ideas include:
6.不要让其他人很容易地找到脚本和代码。黑客通过这些代码寻找漏洞，他们可以使用这些漏洞来控制服务器。下面是一些好的防范方法：
o Don’t use an obvious name for your scripts directory. ‘Scripts’, ‘cgi-bin’, ‘exchange’, and ‘bin’ are so common that automated tools look for them.
不要为您的Scripts目录使用明显的名称。 'Scripts' ， 'cgi-bin' ， 'exchange' 和'bin'这些关键字很容易被扫描器等自动化工具找到。
o Consider renaming the extension on all of your scripts to something uncommon. For example, rename myscript.asp to myscript.dum. This will require adding an ISAPI extension mapping for .dum to the appropriate code handler (asp.dll in this case). This makes your scripts harder to find. Incidentally, specifically renaming all .asp scripts to .html works fine without modifying the ISAPI extension mapping.
考 虑重命名您的脚本的扩展名为不寻常的字符。 例如，将 myscript.asp 重命名为 myscript.dum。 这将需要在ISAPI 扩展名映射（MIME）增加一个映射.dum到特定的代码处理器（在这种情况下是改变到“asp.dll”代码处理器）。 这样会使您的脚本难以找到。 顺便说一下一种特殊情况，重命名所有的.asp为.html 不需要修改 ISAPI 扩展名映射。
o Consider compiling scripts into dll files. This not only protects the code from analysis, but it also results in a major performance gain. Compiled code runs about 20 times faster.
考虑编译所有的到DLL文件中。这不仅保护了源代码，也大大提高了性能。编译过的代码运行比原来的脚本将近快20倍。
o Web applications (i.e. scripts and executables) only need a limited amount of permissions to run properly. Giving more permissions than is necessary allows a malicious hacker to download and analyze your code for vulnerabilities. The minimum permissions needed are: NTFS: Read, IIS: Execute. IIS: Read is NOT required, and will allow a hacker to download your code.
Web 应用程序 （即脚本和可执行文件） 只需要有限的权限就能正常运行。 提供更多的权限将会被黑客利用来下载文件和分析您的代码的漏洞，以及允许黑客下载你的代码。 所需的最低权限是：NTFS： 读取，IIS：执行，IIS：不需要读取。
q Be careful when using the Add/Remove control panel on an IIS Server. If you open the Windows components, Windows will inadvertently reset all ISAPI filter and extensions to the default, and may reset other things. This is a poor design by Microsoft that you need to be careful with.
7.小心使用 IIS 服务器上的添加/删除控制面板。 如果您打开 Windows 组件，Windows 会无意中重置所有 ISAPI 筛选器和扩展为默认值并可以重置其它事情。这是Microsoft的其中一个你需要小心的有问题的设计。
q Delete all default virtual directories (icon w/ world on top of folder) and application roots (icon w/ green ball in box)
1.删除所有默认虚拟目录 （带有世界顶部的文件夹的图标） 和应用程序根 （带有绿球在框中的图标）
o Delete iisadmin
删除iisadmin
o Delete iissamples
删除iissamples
o Delete msadc.
删除msadc
o Delete iishelp
删除iishelp
o Delete scripts
删除scripts
o Delete printers
删除printers
q Delete ALL default content.
2.删除所有默认内容
o Delete %systemdirectory%\inetsrv\iisadmin
删除%systemdirectory%\inetsrv\iisadmin
o Delete %systemdirectory%\inetsrv\iisadmpwd
删除%systemdirectory%\inetsrv\iisadmpwd
o Delete inetpub\wwwroot (or \ftproot or \smtproot)
删除inetpub\wwwroot (or \ftproot or \smtproot)
o Delete inetpub\scripts
删除inetpub\scripts
o Delete inetpub\iissamples
删除inetpub\iissamples
o Delete inetpub\adminscripts
删除inetpub\adminscripts
o Delete %systemroot%\help\iishelp\iis
删除%systemroot%\help\iishelp\iis
o Delete %systemroot%\web\printers
删除%systemroot%\web\printers
o Delete %systemdrive%\program files\common files\system\msadc. Only websites that integrate with Microsoft Access databases need msadc.
删除%systemdrive%\program files\common files\system\msadc.只有使用Microsoft Access 数据库的网站需要 msadc。
q Configure Default Website with extremely secure settings (e.g. require ssl, Integrated Windows auth only, accessible from only one IP, NTFS perms to none on an empty home directory, etc.), then stop the site. This results in a broken default website that 80% of hackers will blindly attack, instead of your real website.
3.配置默认网站为极为安全设置（例如，需要SSL，仅集成Windows验证，只可从一个IP访问，NTFS权限主目录不能为空等） ，然后停止该网站。这样的结果是破坏默认网站，80%黑客会盲目地攻击，而不是您的真实网站。
q Configure all website(s) with host header matching the DNS name of the site. Go to ISM, Web Site tab, Advanced button, Select “All Unassigned” (or the specific IP) and Edit Button, and designate the host header in the appropriate field. Do this for both http and https. Do NOT configure default website with host header. This will prevent 90% of all automated hacking tools from working by sending them to your crippled default website.
4. 配置所有与主机头的DNS名称相匹配的网站。 打开ISM，网站选项卡，点击高级按钮，选择对话框 “ 全部未分配 ” （或特定的 IP) 然后点击编辑按钮，并指定了主机头在适当的栏位。对HTTP和HTTPS进行同样的操作。不配置默认网站的主机头。这将把90 ％的自动化黑客工具的工作转到瘫痪掉的默认网站上。
q Home directory IIS perms: Enable Read and Log. TURN OFF Write, Index, Browsing, Script Source Access (only WebDAV uses this), and Frontpage Web permissions. Set execute permissions to None. Enable execute permissions for the directory that holds your scripts.
5.主目录的IIS权限：启用“读取”和“记录访问”。禁用"写入"，"索引资源"，"目录浏览"，“脚本资源访问”（仅WebDAV使用此权限）以及Frontpage Web权限。执行权限选择“无”。对目录包含脚本文件的目录启用执行权限。
q Disable all unnecessary ISAPI filters. Do this under ISM, ISAPI filters tab.
6.禁用所有不必要的ISAPI筛选器，执行此操作打开ISM，ISAPI筛选器选项卡。
o Delete the Frontpage ISAPI filter (or extensions on older IIS servers), if you have a choice. If Frontpage ISAPI (extensions) is required, make them read only. On older IIS servers, you disable Frontpage extensions with the following command: “c:\program files\common files\microsoft shared\web server extensions\40\bin\fpsrvadm –o uninstall –p all”.
删 除 Frontpage ISAPI 筛选器 （或较早的 IIS 服务器上的扩展）在不需要这些情况下。 如果需要 Frontpage ISAPI （扩展），设置它为只读。 较早的 IIS 服务器上禁用 Frontpage 扩展使用以下命令：“ c \common\microsoft shared\web server extensions\40\bin\fpsrvadm –o uninstall –p all”。
o Digest Authentication. This authentication method requires support for reversibly encrypted passwords—which is a bad idea. Reversible encrypted passwords aren’t supported in the Stanford Windows Infrastructure. Delete this filter.
摘要式身份验证。 此身份验证方法需要支持可逆加密的密码，这是一个坏主意。 可逆加密的密码在斯坦福 Windows 结构中不被支持。 删除此筛选器。
o HTTP Compression. This filter allows compression of the http stream. This is a nice feature, but might be at the expense of security.
HTTP 压缩。 此筛选器允许 HTTP 流的压缩。 这是一个很好的功能，但可能会导致安全性降低。
o SSL. It’s unlikely you wouldn’t want SSL support, but if you don’t need it, then delete it.
SSL。 ’不大可能您不需要 SSL 的支持，但如果你真不需要它请删除它。
q Delete the dll files associated with ISAPI filters that you disabled. Frontpage: fpexdll.dll, Digest: md5filt.dll, Compression: compfilt.dll, SSL: sspifilt.dll.
7.删除与 ISAPI 筛选器禁用相关联的 DLL 文件。 Frontpage： fpexdll.dll，摘要： md5filt.dll，压缩： compfilt.dll，SSL： Sspifilt.dll。
q Unmap the following extensions (if possible):
.asa, .asp, .bat, .cdx, .cer, .htr, .htw, .ida, .idc, .idq, .printer, .shtm, .shtml, .stm
Within ISM, go to the Home Directory tab, and choose Configuration button.
8.（如果可能） 取消映射下列扩展名：.asa、.asp、.bat、.cdx、.cer、.htr、.htw、.ida、.idc、.idq、.printer、.shtm、.shtml、.stm 在 ISM，主目录选项卡，并选择配置按钮。
q Disable “Enable Parent Paths” setting. Go to ISM, Home Directory tab, Configuration button, App Options tab, uncheck checkbox. This prevents malicious web traversal without knowing the underlying directory structure. Web developers can not use paths like ..\..\default.htm and must use fully qualified paths.
9.禁用“启用父路径”设置。 在 ISM，主目录选项卡，点击 配置按钮，打开应用程序选项选项卡，取消选中复选框。 这样可以防止不知道目录的基础结构情况下恶意的 Web目录遍历。 Web 开发人员不能使用像路径..\..\Default.htm，必须使用完全合格的路径。
补丁级别q Apply Service Packs and hotfixes. UpdateExpert makes this very easy or Microsoft’s HfCheck tool can be used.
1.应用 Service Pack 和修补程序。可以使用 UpdateExpert，Microsoft ’s HfCheck 工具。
q Install high encryption pack (comes with Windows 2000 SP2) so 128 bit encryption is available.
2.安装高加密包 （附带 Windows 2000 SP 2) ,可以使用128 位加密。
q Basic authentication disabled at site level, virtual directory level, directory level –Everywhere!
1.在网站层级、 虚拟目录层级、 目录层级 等所有地方禁用基本身份验证。
q Digest authentication disabled everywhere.
2.在任何地方禁用摘要式身份验证。
q IUSR & IWAM accounts should not be domain users nor should they be guests. If no anonymous access is required, delete these accounts.
3.IUSR & IWAM 帐户不应是域用户，也不应是Guests用户。 如果不需要匿名访问则删除这些帐户。
q If web data is ultra-sensitive consider placing server outside a domain.
4.如果web 数据是 ultra-sensitive（超灵敏）数据，考虑将服务器放置在域之外。
q Enable IIS auditing, change to W3 extended logging, and check that the info that is being logged is appropriate. (e.g. Is username needed?) Consider enabling the following items: Date and time, IP address of the client, IP address of the server, Server port, Username, HTTP method used to access your site, URI Stern, URI Query, Status of the request.
1.启用 IIS 审计，变更为W3号扩展日志记录，并检查信息被正确记录。 （例如：需要用户名吗？） 考虑启用下列项目： 日期和时间，客户端的IP地址，服务器的IP地址，服务器端口，用户名， 用于访问网站的HTTP方法，URI 尾，URI 查询，请求的状态。
q Set permission to IIS logs to system and local administrators only.
2.设置只允许系统和本地管理员能访问IIS日志。
q Remove write perms to hklm\software for non-admin accounts. Administrators & System: FULL, Everyone: Read/Execute
3.删除"hklm\software"的非管理员帐户的写入权限 。 管理员和系统帐户：完全控制，所有人： 读取或执行。
q Restrict NTFS perms to ALL executables on system. NTFS perms: Administrators & System: FULL, Users: Read/Execute. Give IUSR account execute permissions sparingly.
4.限制 系统上所有可执行程序的NTFS权限。 NTFS 权限：管理员和系统帐户：完全控制、 用户： 读取或执行。 给 IUSR 帐户谨慎执行权限。
q Restrict perms to any script interpreters such as perl. NTFS perms: Administrators & System: FULL, Everyone: Read/Execute. Give IUSR account execute permissions sparingly.
q Ensure Everyone has only read on:
6.确保所有人只有只读权限：
Web root
%systemroot%
%systemroot%\system32
%systemroot%\system32\inetsrv
%systemroot%\system32\inetsrv\asp
%systemroot%\program files\common files\
iis网站防护：http://www.iisutm.com
原文：http://windows.stanford.edu/docs/IISsecchecklist.htm
2009年3月7日星期六
Web应用防火墙正日趋流行，过去这些工具被很少数的大型项目垄断，但是，随着大量的低成本产品的面市以及可供选择的开源试用产品的出现，它们最终能被大多数人所使用。
在这篇文章中，先向大家介绍Web应用防火墙能干什么，然后快速的概览一下Web应用防火墙最有用的一些特征。通过这篇文章的阅读，大家能清楚地了解web应用防火墙这个主题，掌握相关知识。
什么是web应用防火墙？
有趣的是，还没有人能真正知道web应用防火墙究竟是什么，或者确切的说，还没有一个大家认可的精确定义。从广义上来说，Web应用防火墙就是一些增强 Web应用安全性的工具。然而，如果我们要深究它精确的定义，就可能会得到更多的疑问。因为一些Web应用防火墙是硬件设备，一些则是应用软件；一些是基 于网络的，另一些则是嵌入WEB服务器的。
国外市场上具有WEB应用防火墙功能的产品名称就有不同的几十种，更不用说是产品的形式和描述 了。它难以界定的原因是这个名称包含的东西太多了。较低的网络层（Web应用防火墙被安置在第七层）被许多设备所覆盖，每一种设备都有它们独特的功能，比 如路由器，交换机，防火墙，入侵检测系统，入侵防御系统等等。然而，在HTTP的世界里，所有这些功能都被融入在一个设备里：Web应用防火墙。
总体来说，Web应用防火墙的具有以下四个方面的功能：
1. 审计设备：用来截获所有HTTP数据或者仅仅满足某些规则的会话
2. 访问控制设备：用来控制对Web应用的访问，既包括主动安全模式也包括被动安全模式
3. 架构/网络设计工具：当运行在反向代理模式，他们被用来分配职能，集中控制，虚拟基础结构等。
4. WEB应用加固工具：这些功能增强被保护Web应用的安全性，它不仅能够屏蔽WEB应用固有弱点，而且能够保护WEB应用编程错误导致的安全隐患。
但是，需要指出的是，并非每种被称为Web应用防火墙的设备都同时具有以上四种功能。
由 于WEB应用防火墙的多面性，拥有不同知识背景的人往往会关注它不同方面的特点。比如具有网络入侵检测背景的人更倾向于把它看作是运行在HTTP层上的 IDS设备；具有防火墙自身背景的人更趋向与把它看作一种防火墙的功能模块。还有一种理解来自于“深度检测防火墙”这个术语。他们认为深度检测防火墙是一 种和Web应用防火墙功能相当的设备。然而，尽管两种设备有些相似之处，但是差异还是很大的。深度检测防火墙通常工作在的网络的第三层以及更高的层次，而 Web应用防火墙则在第七层处理HTTP服务并且很好地支持它。
直接更改WEB代码解决安全问题是否更好？这是毋庸置疑的，但也没那么容易（实现）。
因为，通过更改WEB应用代码是否一定就能增强系统安全性能，这本身就存在争论。而且现实也更加复杂：
* 不可能确保100%的安全。人的能力有限，会不可避免地犯错误。
* 绝大多数情况下，很少有人力求100%的安全。如今的现实生活中那些引领应用发展的人更多注重功能而不是安全。这种观念正在改变，只是有点缓慢。
* 一个复杂的系统通常包含第三方产品（组件，函数库），它们的安全性能是不为人知的。如果这个产品的源代码是保密的，那么你必须依赖商品的厂商提供补丁。即使有些情况下源代码是公开的，你也不可能有精力去修正它们。
* 我们不得不使用存在安全隐患的业务系统，尽管这些旧系统根本无法改进。
因此，为了获得最好的效果，我们需要双管齐下：一方面，必须提高管理者和开发者的安全意识；另一方面，尽可能提高应用系统的安全性。
Web应用防火墙的特点
Web应用防火墙的一些常见特点如下。
异常检测协议
如果阅读过各种RFC，就会发现一个被反复强调的主题。大多数RFC建议应用自己使用协议时要保守，而对于接受其他发送者的协议时可以自由些。Web服务 器就是这样做的，但这样的行为也给所有的攻击者打开了大门。几乎所有的WAF对HTTP的请求执行某种异常检测，拒绝不符合Http标准的请求。并且，它 也可以只允许HTTP协议的部分选项通过，从而减少攻击的影响范围。甚至，一些WAF还可以严格限定HTTP协议中那些过于松散或未被完全制定的选项。
增强的输入验证
就频繁发生的Web安全问题而言，有些是源于对Web设计模型的误解，有些则来自于程序师认为浏览器是可信的。很多WEB程序员用JavaScript在 浏览器上实现输入验证。而浏览器只是一个用户控制的简单工具，因此攻击者可以非常容易地绕过输入验证，直接将恶意代码输入到WEB应用服务器。
有一个解决上述问题的正确方法，就是在服务端进行输入验证。如果这个方法不能实现，还可以通过在客户和应用服务器之间增加代理，让代理去执行Web页面上嵌入的JavaScript，实现输入验证。
消极的安全模型VS积极的安全模型
曾经设置过防火墙规则的人，可能会碰到这样的建议：允许已知安全的流量，拒绝其他一切访问。这就是一种很好的积极安全模型。恰恰相反，消极安全模型则是默认允许一切访问，只拒绝一些已知危险的流量模式。
每种安全模型方式都存在各自的问题：
消极安全模型：什么是危险的？
积极安全模型：什么是安全的？
消极安全模式通常使用的更多。识别出一种危险的模式并且配置自己的系统禁止它。这个操作简单而有趣，却不十分安全。它依赖于人们对于危险的认识，如果问题存在，却没有被意识到（这种情况很常见），就会为攻击者留下可趁之机。
积极安全模式（又称为白名单模式）看上去是一种制定策略的更好方式,非常适于配置防火墙策略。在Web应用安全领域中，积极安全模式通常被概括成对应用中的每一个脚本的枚举。对枚举的每一个脚本，需要建立一个相应列表，表中内容如下所示：
* 允许的请求方式（比如，GET/POST或者只POST）
* 允许的Content-Type
* 允许的Content-Length
* 允许的参数
* 指定参数和可选参数
* 参数类型（比如，文本或整数）
* 附加参数限制
上述列表仅仅是个例子，实际的积极安全模式通常包括更多的要素。它试图从外部完成程序员本应从内部完成的工作：为提交到Web应用的信息验证每一个比特。 如果肯花时间的话，使用积极安全模式就是一个比较好的选择。这个模式的难点之一，在于应用模式会随着应用的发展而改变。每当应用中添加新脚本或更改旧脚 本，就需要更新模式。但是，它适用于保护那些稳定的、无人维护的旧应用。
自动开发策略可以解决以上问题：
* 一些WAF能够监视流量，并根据这些流量数据自动配置策略，有些产品可以实时进行这样的工作。
* 通过白名单，可以标识特定的IP地址是可信的，然后，依据观察的流量，配置WAF，更新安全策略。
* 如果通过一个全面的衰减测试，（仿真正确的行为，）来创建一个应用，并且在WAF处于监控状态时执行测试，那么WAF可以自动生成策略。
可见，没有哪个模式是完全令人满意的。消极安全模式适用于处理已知问题，而积极安全模式则适用于稳定的Web应用。理想的做法是，在现实生活中，将二者结合使用，取长补短。
及时补丁
积极安全模式理论上更好一些因为浏览器和WEB应用程序之间的通信协议通过HTML规范进行了很好的定义。现在的Web开发语言都可以处理带有多个参数的 HTTP请求。因为这些参数在Web应用防火墙中都是可见的，因此WEB应用防火墙可以分析这些参数判断是否存在允许该请求。，
当一个应用中的漏洞被发现时大多数情况下我们会尽可能在代码中修补它。受诸多因素的影响（如应用的规模，是否有开发人员，法律问题等等 ），开发补丁的过程可能需要几分钟，或者一直到无限长的是时间。这些时间正是攻击者发起攻击的好机会。
如 果开发人员能够在非常短的时间内在代码中修补好漏洞，那你就不用担心了。但如果修补这个漏洞需要花费几天，甚至几周来修复呢？Web应用防火墙就是处理这 个问题的理想工具：只要给一个安全专家不错的WAF和足够的漏洞信息，他就能在不到一个小时的时间内屏蔽掉这个漏洞。当然，这种屏蔽掉漏洞的方式不是非常 完美的，并且没有安装对应的补丁就是一种安全威胁，但我们在没有选择的情况下，任何保护措施都比没有保护措施更好。
及时补丁的原理可以更好的适用于基于XML的应用中，因为这些应用的通信协议都具规范性。
基于规则的保护和基于异常的保护
现在市场上大多数的产品是基于规则的WAF。其原理是每一个会话都要经过一系列的测试，每一项测试都由一个过多个检测规则组成，如果测试没通过，请求就会被认为非法并拒绝。
基于规则的WAFs很容易构建并且能有效的防范已知安全问题。当我们要制定自定义防御策略时使用它会更加便捷。但是因为它们必须要首先确认每一个威胁的特点，所以要由一个强大的规则数据库支持。WAF生产商维护这个数据库，并且他们要提供自动更新的工具。
这个方法不能有效保护自己开发的WEB应用或者零日漏洞（攻击者使用的没有公开的漏洞），这些威胁使用基于异常的WAF更加有效。
异常保护的基本观念是建立一个保护层，这个保护层能够根据检测合法应用数据建立统计模型，以此模型为依据判别实际通信数据是否是攻击。理论上，一但构建成 功，这个基于异常的系统应该能够探测出任何的异常情况。拥有了它，我们不再需要规则数据库而且零日攻击也不再成问题了。但基于异常保护的系统很难构建，所 以并不常见。因为用户不了解它的工作原理也不相信它，所以它也就不如基于规则的WAF应用广范。
状态管理
HTTP的无状态性对Web应用安全有很多负面影响。会话只能够在应用层上实现，但对许多应用来说这个附加的功能只能满足业务的需要而考虑不到安全因素了。Web应用防火墙则将重点放在会话保护上，它的特征包括：
强制登录页面。在大多数站点， 你可以从任何你所知道的URL上访问站点，这通常方便了攻击者而给防御增加了困难。WAF能够判断用户是否是第一次访问并且将请求重定向到默认登录页面并且记录事件。
分别检测每一个用户会话。如果能够区分不同的会话，这就带来了无限的可能。比如，我们能够监视登陆请求的发送频率和用户的页面跳转。通过检测用户的整个操作行为我们可以更容易识别攻击。
对暴力攻击的识别和响应。通常的Web应用网络是没有检测暴力攻击的。有了状态管理模式，WAF能检测出异常事件（比如登陆失败），并且在达到极限值时进行 处理。此时它可以增加更多的身份认证请求的时间，这个轻微的变化用户感觉不到，但对于足以对付自动攻击脚本了。如果一个认证脚本需要50毫秒完成，那它可 以发出大约每秒20次的请求。如果你增加一点延时，比如说，一秒种的延迟，那会将请求降低至每秒不足一次。与此同时，发出进一步检测的警告，这将构成一个 相当好的防御。
实现会话超时。超出默认时间会话将失效，并且用户将被要求重新认证。用户在长时间没有请求时将会自动退出登录。
会话劫持的检测和防御。许多情况下，会话劫持会改变IP地址和一些请求数据（HTTP请求的报头会不同）。状态监控工具能检测出这些异常并防止非法应用的发生。在这种情况下应该终止会话，要求用户重新认证，并且记录一个警告日志信息。
只允许包含在前一请求应答中的链接。一些WAF很严格，只允许用户访问前一次请求返回页面中的链接。这看上去是一个有趣的特点但很难得到实施。一个问题在于它不允许用户使用多个浏览器窗口，另一个问题是它令使用JavaScript自动建立连接的应用失效。
其他防护技术
WAF的另外一些安全增强的功能用来解决WEB程序员过分信任输入数据带来的问题。比如：
隐藏表单域保护。有时，内部应用数据通过隐藏表单变量实现，而它们并不是真的隐藏的。程序员通常用隐藏表单变量的方式来保存执行状态，给用户发送数据，以确保这些数据返回时未被修改。这是一个复杂繁琐的过程，WAF经常使用密码签名技术来处理。
Cookies保护。和隐藏表单相似的是，cookies经常用来传递用户个人的应用数据，而不一样的是，一些cookies可能含有敏感数据。WAFs 通常会将整个内容加密，或者是将整个cookies机制虚拟化。有了这种设置，终端用户只能够看到cookies令牌（如同会话令牌），从而保证 cookies在WAF中安全地存放
抗入侵规避技术。 基于网络的IDS对付WEB攻击的问题就是攻击规避技术。改写HTTP输入请求数据（攻击数据）的方式太多，并且各种改写的请求能够逃避IDS探测。在这 个方面如果能完全理解HTTP就是大幅度的改进。比如，WAF每次可以看到整个HTTP请求，就可以避免所有类型的HTTP请求分片的攻击。因为很好的了 解HTTP协议，因此能够将动态请求和静态请求分别对待，就不用花大量时间保护不会被攻击的静态数据。这样WAF可以有足够的计算能力对付各种攻击规避技 术， 而这些功能由NIDSs完成是很耗时的。
响应监视和信息泄露保护。信息泄露防护是我们给监视HTTP输出数据的一个名称。从原理上来说它和请求监视是一样的，目的是监视可疑的输出，并防止可疑的 http输出数据到达用户。最有可能的应用模式是监视信用卡号和社会保险号。另外，这个技术的另一项应用是发现成功入侵的迹象。因为有经验攻击者总会给信 息编码来防止监测，所以防止这样有决心并技术熟练的攻击者获取信息是很困难的。但是，在攻击者没有完全掌控服务器而仅仅尝试WEB应用的安全漏洞的情况 下，这项技术可以起到防护效果。
IIS 服务器防护：www.iisutm.com
英文原文：Web Application Firewalls Primer
Introduction to Web Application Firewalls, published in INSECURE Magazine 1.5.
2009年3月6日星期五
网站信誉及安全评估的在线工具
Norton Safe Web, from Symantec
http://safeweb.norton.com
WOT Security Scorecard | WOT Web of Trust
http://www.mywot.com/en/scorecard
McAfee SiteAdvisor
http://www.siteadvisor.com/
如果有熟悉的网站邀请或者是不确认的邮件中的连接，包括一些现在流行的社区，让你输入邮箱地址,MSN,QQ等信息和密码，有很高的网站诈骗和垃圾邮件风险，可以用上面的工具先检查下是否安全在进行浏览呢。
不然最好先用虚拟机或者沙盒一类的工具来浏览。
2008年12月31日星期三
这两天分析了一下这两个规则集，初步整理如下。
规则来源及版本：
getroot免费规则：
http://downloads.prometheus-group.com/delayed/rules/modsec-200809221633.tar.gz
modsecurity core rule：
http://www.modsecurity.org/download/modsecurity-core-rules_2.5-1.6.1.tar.gz
分析采用缺省规则进行，缺省注释掉没有启用的规则不分析。 getroot统计有效规则(含SecRule关键字的规则）5373条， modsecurity有效规则126条。
分析包括参数（Variables）统计、变换函数（Transformation functions）统计和规则关联关系统计（chian，skip）。参数统计是统计出现次数，一条有效规则中可能出现几次，比如ARGS，一条规则可能出现多次，出现几次统计几次。变换函数一条规则中只只出现一次，因此和规则条数统计一致。关联关系统计是统计chain，skip，skipafter的次数，反应规则之间相互联系的统计。
统计结果如下:
getroot参数出现次数及排名：
7959 ARGS
3647 REQUEST_URI
313 REQUEST_BODY
250 url
237 REQUEST_HEADERS
199 params
136 link
96 Referer
95 User-Agent
86 id
79 team
77 redirect
76 comment
73 website
73 return
73 referrer
72 referer
71 ref
71 body
71 helpbox
71 ureferrer
71 refertoyouby
70 bg_image
70 imageFile
70 media_gallery
70 outbound
70 product
70 oaparams
70 loc
70 out
70 filecontent
70 images
69 redirect_to
69 ajaxurl
69 base_url
69 helpurl
69 backurl
69 serverurl
68 refer
68 siteurl
68 introtext
68 Post
68 resource
68 url2send
68 basehref
67 userpicpersonal
67 fck_body
67 attach-url
66 last_msg
66 referredby
66 stories_cat
66 fulltext
66 sUrl
66 thelink
66 HOMEPAGE_URL
66 texty
66 view
66 ATTACHMENTS_URL
66 resource_box
66 fck_brief
66 comments_commentFind
66 altTag
66 pay_list_type
66 areaContent2
66 FULL_URL
66 linkdescr
66 website_link
66 _wp_original_http_referer
66 products_image
66 inc
66 oldmsg
66 templatePath
65 request_url
64 blog_url
64 x_receipt_link_url
64 lk_url
64 clickurl
64 return_link_url
64 config_helpurl
64 install_url
getroot规则变换函数及排名：
262 urlDecode
262 urlDecodeUni
181 lowercase
170 compressWhitespace
135 htmlEntityDecode
110 replaceNulls
106 normalisePath
100 hexDecod
100 base64Decode
21 replaceComments
1 none
1 length
getroot规则关联关系次数统计：
1649 chain
modsecurity变量出现次数统计及排名：
68 REQUEST_HEADERS
30 XML
29 REQUEST_FILENAME
29 ARGS
22 RESPONSE_BODY
22 ARGS_NAMES
21 Referer
8 User-Agent
6 REQUEST_METHOD
5 REQUEST_HEADERS_NAMES
5 REQUEST_HEADERS
5 Content-Length
4 RESPONSE_STATUS
3 REQUEST_COOKIES
3 X-OS-Prefs
3 Host
3 REQUEST_COOKIES_NAMES
3 REQUEST_LINE
3 REQUEST_URI
3 Cookie
2 Content-Type
2 Transfer-Encoding
2 &GLOBAL
2 REMOTE_ADDR
2 Accept
2 Content-Encoding
2 via
2 REQUEST_BODY
2 REQUEST_PROTOCOL
modsecurity规则变换函数出现次数及排名：
123 none
62 lowercase
47 htmlEntityDecode
31 urlDecode
30 urlDecodeUni
24 compressWhitespace
16 replaceComments
2 length
modsecurity规则关联关系统计次数及排名：
19 chain
13 skip
2008年12月26日星期五
(研討會)Web安全防範應用技術研討課程(資料下載)
台北場：
| 時間 | 內容 | 主講人 |
| 13:00~13:30 | 報到 | |
| 13:30~14:20 | 主題：網站安全防禦術
| 陶靖霖 (阿碼科技資安顧問) |
| 14:20~14:30 | 中場休息 | |
| 14:30~15:20 | 主題：網頁安全實務
| 李柏逸 (網駭科技技術顧問) |
| 15:20~15:30 | 中場休息 | |
| 15:30~16:20 | 主題：2008年度攻防手法整理探討
| 呂守箴 (漢昕科技資安顧問) |
| 16:20~16:30 | Q & A |
台中場：
| 時間 | 內容 | 主講人 |
| 13:00~13:30 | 報到 | |
| 13:30~14:20 | 主題：網站安全防禦術
| 陶靖霖 (阿碼科技資安顧問) |
| 14:20~14:30 | 中場休息 | |
| 14:30~15:20 | 主題：網頁瀏覽安全威脅與對策
| 林育民 (Cisco資深技術經理) |
| 15:20~15:30 | 中場休息 | |
| 15:30~16:20 | 主題：2008年度攻防手法整理探討
| 呂守箴 (漢昕科技資安顧問) |
| 16:20~16:30 | Q & A |
高雄場：
| 時間 | 內容 | 主講人 |
| 09:15~09:30 | 報到 | |
| 09:30~10:50 | 主題：網站安全防禦術
| 陶靖霖 (阿碼科技資安顧問) |
| 10:50~11:00 | 中場休息 | |
| 11:00~12:00 | 主題：網頁瀏覽安全威脅與對策
| 林育民 (Cisco資深技術經理) |
| 12:00~13:30 | 休息用餐 | |
| 13:30~14:45 |
| 余俊賢 (阿碼科技資安顧問暨ASF教育訓練總監) |
| 14:20~14:30 | 中場休息 | |
| 15:00~16:15 | 主題：2008年度攻防手法整理探討
| 呂守箴 (漢昕科技資安顧問) |
| 16:15~16:30 | Q & A |
2008年12月25日星期四
Clickjacking：最新的跨浏览器攻击漏洞引起恐慌
安全专家们最近发出警告，一个最新发现的跨浏览器攻击漏洞将带来非常可怕的安全问题，该漏洞影响所有主流桌面平台，包括，IE, Firefox, Safari, Opera 以及 Adobe Flash。
这个被称为 Clickjacking 的安全威胁，原本要在 OWASP NYC AppSec 2008 大会上公布，但包括 Adobe 在内的厂商请求暂时不要公开这个漏洞，直到他们开发出安全补丁。
发现这个漏洞的是两个安全研究专家，Robert Hansen 与 Jeremiah Grossman，他们已经略透露了一点相关信息以显示该安全威胁的严重性。
Clickjacking 到底是什么东西？
两为研究专家说，他们所发现的绝非小问题，事实上，很严重，他们在透露这些信息之前需要负起责任，这些问题一环套一环，至少已经有两家厂商表示会提供补丁，但日期未定，我们目前只和有限的几个厂家探讨这个问题，所以，问题很严重。
根据那些在 OWASP 参加过半公开性演示的人透露，这个漏洞非常紧急，将影响到所有浏览器，而且它和 JavaScript 并没有关系：
- 总的来说，当你访问一个恶意网站的时候，攻击者可以控制你的浏览器对一些链接的访问，这个漏洞影响到几乎所有浏览器，除非你使用 lynx 一类的字符浏览器。这个漏洞与 JavaScript 无关，即使你关闭浏览器的 JavaScript 功能也无能为力。事实上这是浏览器工作原理中的一个缺陷，无法通过简单的补丁解决。一个恶意网站能让你在毫不知情的情况下点击任意链接，任意按纽或网站上 任意东西。
如果这还不能让你恐慌的话，想想这样的情形，一个用户在被攻击的时候将毫不知情而且束手无策：
- 比如在 Ebay,因为可以嵌入 JavaScript，虽然攻击并不需要 JavaScript，但可以让攻击更容易进行。只用 lynx 字符浏览器才能保护你自己，同时不要任何动态的东西。该漏洞用到 DHTML，使用防 frame 代码可以保护你不受跨站点攻击，但攻击者仍可以强迫你点击任何链接。你所做的任何点击都被引导到恶意链接上，所以，那些 Flash 游戏将首当其冲。
据 Hansen 讲，他们已经同微软以及 Mozilla 谈论过这个问题，然而他们均表示这是个非常棘手的问题，目前没有简单的解决办法。
Grossman 确切表示，微软最新的 IE8 和 Mozilla 最新的 Firefox 3 均不能幸免。
- 当前，唯一的办法是禁用浏览器的脚本和插件功能。
Adobe 的 Serious Magic 网站遭 Asprox 僵尸网络 SQL 注射攻击
据 SophosLabs 报道，Adobe 拥有的 seriousmagic.com 网站刚刚遭受 Asprox 僵尸网络的 SQL 注射攻击，成为近来被攻击的最著名站点。
被感染的网页位于 hxxp://www.seriousmagic.com/help/tuts/tutorials.cfm?p=1, 访问该页的用户将被偷偷地安装一个恶意程序。Adobe 两年前宣布收购 Serious Magic，现在 Serious Magic 的 Whois 信息显示，Adobe 是它的新主人。
据反病毒厂商 Sophos 的一篇文章透露，Adobe 已经注意到自己的网页被感染，但 The Register 周四用虚拟机试图访问这个感染页的时候，发现仍被引导到一些恶意站点，包括 hxxp://abc.verynx.cn/ w.js 以及 hxxp://1.verynx.cn/w.js。目前，这两个地址已经失效，但攻击中使用的另外几个地址，包括 hxxp://jjmaobuduo.3322.org/csrss/ w.js 与 hxxp://www2.s800qn.cn/csrss/ new.htm 仍然有效。
Asprox 僵尸网络 5，6月期间曾成功攻击过 Redmond magazine，Sony Playstation 等著名站点，没过多久，Serious Magic 再成为牺牲品。
被感染的每一个网页都被无休止地执行一段 Javascript 代码并将用户引导到恶意站点或广告站点。同时，w.js 会尝试各种系统漏洞，并使用以下结构，将一个查杀率很低的病毒 Worm.Win32.AutoRun.qtg 安装到用户的系统。（该病毒的查杀率仅80.56%）
www2.s800qn.cn /csrss/ new.htm
www2.s800qn.cn /csrss/ flash.htm
www2.s800qn.cn /csrss/ i1.htm
www2.s800qn.cn /csrss/ f2.htm
www2.s800qn.cn /csrss/ i1.html
www2.s800qn.cn /csrss/ flash112.htm
www2.s800qn.cn /csrss/ ff.htm
www2.s800qn.cn /csrss/ xl.htm
www2.s800qn.cn /csrss/ mi.htm
www2.s800qn.cn /csrss/ real10.htm
www2.s800qn.cn /csrss/ real11.htm
bbexe.com /csrss/ rondll32.exe
目前，Adobe 似乎已经清除了这个病毒。
订阅 评论 [Atom]