“海底捞肥牛”通过精心收集，向本站投稿了8篇检测和防御rootkit威胁，下面是小编为大家推荐的检测和防御rootkit威胁，欢迎大家分享。
篇1：检测和防御rootkit威胁
微软计划经理、作者和rootkit权威Kurt
Dillard在网络直播活动期间回答了观众有关检测和删除Windows中的rootkits的问题，
问：Rootkits无所不在：实际中受到间谍软件和病毒感染的系统有多大比例是由Rootkits引起的？
Dillard：我很高兴你问我这个特别的问题，因为有些阅读我的有关Rootkits指南的文章或者看到我的有关Rootkits问题的网络直播的人可能会错误地以为Rootkits无处不在。甚至微软内部的人有时候也认为，每次系统出现奇怪的现象都是Rootkits在作祟。现实是，虽然我对Rootkits着迷，但是，在 攻破的计算机中很少见到Rootkits。我们见到Rootkits的次数似乎是越来越少了，而这类恶意软件现在确实很少见了。这种趋势是幸运的，但是，安全软件厂商正在为它们的工具增加更有效地对付Rootkits的功能。例如，微软的恶意软件清除工具就能够检测和清除各种各样的Rootkits。这个软件每个月升级一次。
问：你如何知道一台计算机是否是被一个Rootkits攻破的？
Dillard：这是我在网络直播中谈的要点，也是我为SearchWindowsSecurity.com网站撰写的一系列文章的要点：没有简单的方法知道这个原因。安全产品厂商正在改善它们的检测工具。但是，要检测被Rootkits攻破的计算机仍是很困难的。
问：我不能确认我家的计算机是否正在运行一个用户Rootkits。但是，当我关闭我的笔记本电脑时，我看到一个称作“hiddenshell”的对话框，笔记本电脑并没有关闭。我记不起来这个文件的扩展名了。这是不是表明存在一个Rootkits？
Dillard：可能不是。但是，在我本人没有看到这个系统之前，我不能给你肯定的答复。由于我不能为访问这个网站的网友提供技术支持，我想你最好与微软免费的在线技术支持部门联系一下，以便消除消费者对可能出现的恶意软件感染的担心。
问：备份文件中的Rootkits：当一台电脑系统遇到严重的稳定性问题时，标准的做法是为消费者备份重要的数据文件，并设法恢复这个系统。这个备份数据有可能包含Rootkits本身的隐含文件吗？我主要是说应用程序数据文件和我的文档等文件。
Dillard：有这种可能性。被病毒感染的系统也会出现同样的情况，最近的备份也可能会包含病毒的拷贝。因此在系统恢复之后和重新开始使用数据之前，你必须要用反间谍软件和杀毒软件对备份的数据进行扫描。
问：处理rootkits的方法：如果理解的正确，你的建议是采取三个步骤检测和删除rootkits：1.缩小暴露范围（不要以管理员的权限运行）；2.监视行为（查找异常行为，特别是rootkits的行为）；3.修复外部操作系统。这有些过于简单了。不过，这是准确的评估方法吗？
Dillard：你说的不错。你极大地简化了这些事情。我同意你的意见。
问：映射网络以便发现rootkits：如果我映射一个被攻破的计算机的网络硬盘，我会看到隐含的文件吗？
Dillard：使用“HackerDefender”软件可以看到网络上的隐含文件。我认为，rootkit作者也可能隐藏连接到网络的计算机中的文件。
问：扫描rootkit文件的名称：如果rootkit隐藏其在注册表中的注册值和文件名等信息，有没有办法利用这个文件名的一部分信息搜索rootkit的信息？
Dillard：没有办法。至少使用任何内置的工具都不行。
问：检测HackerDefender：在你提到的HackerDefender的例子中，你说这个软件隐藏了以具体字符开头的可执行文件，我的理解对吗？如果我的理解是对的，我是否可以手工制作一个以这些字符开头的可执行文件，并把这个文件放在可疑的目录中，如果在查看目录的命令“DIR”列表中没有出现这个文件名，是不是有理由认为可能存在HackerDefender？
Dillard：这是一个很有趣的想法，
如果HackerDefender的INI文件配置为使用通配符，这种做法可能会有效。然而，我不知道这是不是一种可行的方法，因为你必须幸运地猜测出rootkit在使用什么字符串。
问：扫描注册表文件查找rootkits：有没有办法直接读出注册表文件（也就是.dat文件），找着rootkits的踪迹？
Dillard：有各种方法在正在使用之中的计算机系统中查看注册表中的数据文件。高级的rootkits能够过滤掉你可能从注册表中收到的信息。你在正在使用的电脑中不能看到注册表文件，因为这些文件被系统锁定了。你可以离线查看注册表文件，也就是从替代的操作系统启动，然后查看注册表中的.dat数据文件。
问：扫描多个版本的Windows操作系统查找rootkits：我的计算机中安装了多个版本的Windows操作系统。这能够让我扫描像HackerDefender一样的已知的rootkits，对不对？
Dillard：是的。我在我的演示中的确描绘过这种情况。但是，我在演示中指出发现隐藏目标的另一种方法是从一个替代的操作系统启动。使用这种方法查找恶意软件是很单调的，但是，却是可能的。
问：采用端口封锁方式防御rootkit：封锁路由器端口是不是一个好主意？
Dillard：采用多层防御措施是一个好主意。我把这种方法称作是纵深防御。对你的问题要提供完整的答案需要彻底了解你的网络和你的要求。如果你说的是家庭计算机，我建议你在家庭互联网连接和内部网络连接后面使用一个防火墙，然后在每一台电脑上运行一个防火墙软件。如果你说的是企业系统，你也要使用防火墙，但是根据你的独特的情况的不同，你的防火墙的配置也有多不同。我将在下个月发表的“Rootkits防御指南”的文章中讨论这个概念，并且提供具体的例子。
问：Rootkits对改变审计软件的影响：Rootkits能够绕过或者欺骗TripWire软件吗？
Dillard：是的。我认为Rootkits能够做到这一点。
问：Rootkits对中小企业的影响：你能不能根据现实的例子对Rootkits对中小企业的影响做一个威胁分析？也就是说，不要提供受害者的名字，就说一下由于Rootkits对Windows操作系统造成的影响，中小企业受到了哪一种损失，破坏和付出的代价，好吗？这是一个超级演示！
Dillard：你太客气了，非常感谢。恶意软件在这个水平上的威胁仍是非常小的。在设法保护你的网络安全的时候，不值得把重点过多地放在rootkits方面。在谈到防御rootkits的时候，你在防御恶意软件和恶意用户方便所采取的措施同样会有效地防御rootkits，减少受到感染的威胁。这些安全措施包括周边的防火墙、强有力的口令或者用于身份识别的智能卡、最新的杀毒软件和反间谍软件、在日常工作中不允许用户以管理员的权限登录等等。我将在下个月发表的“Rootkits防御指南”的文章中讨论这个概念，并且提供具体的例子。
问：Rootkit检测服务：考虑到以前的Rootkit的极端复杂性，家庭用户要检测出Rootkit是很困难的。微软能不能根据消费者的需求为消费者或者服务部门提供一项检测Rootkit的特别服务？如果能够提供这种服务的话，收费的标准是什么？
Dillard：又是一个大问题。微软的确为受到恶意软件危害的受害者提供了免费的技术支持。但是，这种技术支持不是专门针对Rootkit的。微软的技术支持包括各种类型的恶意软件，包括病毒、蠕虫、间谍软件和Rootkit。
问：Longhorn的反Rootkit软件功能：Longhorn将有反Rootkit的功能吗？
Dillard：很遗憾，对我来说，现在就对微软的与恶意软件作斗争的计划提出推测有点为时过早了。
篇2：Rootkit的基础知识和防御方法
Rootkit的基础知识和防御方法
好多人有一个误解，他们认为rootkit是用作获得系统root访问权限的工具，实际上，rootkit是攻击者用来隐藏自己的踪迹和保留root访问权限的工具。通常，攻击者通过远程攻击获得root访问权限，或者首先密码猜测或者密码强制破译的方式获得系统的访问权限。进入系统后，如果他还没有获得root权限，再通过某些安全漏洞获得系统的root权限。接着，攻击者会在侵入的主机中安装rootkit，然后他将经常通过rootkit的后门检查系统是否有其他的用户登录，如果只有自己，攻击者就开始着手清理日志中的有关信息。通过rootkit的嗅探器获得其它系统的用户和密码之后，攻击者就会利用这些信息侵入其它的系统。
一 全面认识rootkit：
Rootkit出现于二十世纪90年代初，在1994年2月的一篇安全咨询报告中首先使用了rootkit这个名词。这篇安全咨询就是CERT-CC的CA-1994-01，题目是Ongoing Network Monitoring Attacks，最新的修订时间是9月19日。从出现至今，rootkit的技术发展非常迅速，应用越来越广泛，检测难度也越来越大。
rootkit介绍Rootkit是一种奇特的程序，它具有隐身功能：无论静止时（作为文件存在），还是活动时，（作为进程存在），都不会被察觉。换句话说，这种程序可能一直存在于我们的计算机中，但我们却浑然不知，这一功能正是许多人梦寐以求的――不论是计算机 ，还是计算机取证人员。 可以在入侵后置入Rootkit，秘密地窥探敏感信息，或等待时机，伺机而动；取证人员也可以利用Rootkit实时监控嫌疑人员的不法行为，它不仅能搜集证据，还有利于及时采取行动。
二 了解Rootkit的攻击原理：
要了解Rootkit的攻击原理，就必须从系统原理说起，我们知道，操作系统是由内核（Kernel）和外壳（Shell）两部分组成的，内核负责一切实际的工作，包括CPU任务调度、内存分配管理、设备管理、文件操作等，外壳是基于内核提供的交互功能而存在的界面，它负责指令传递和解释。由于内核和外壳负责的任务不同，它们的处理环境也不同，因此处理器提供了多个不同的处理环境，把它们称为运行级别（Ring），Ring让程序指令能访问的计算机资源依次逐级递减，目的在于保护计算机遭受意外损害――内核运行于Ring 0级别，拥有最完全最底层的管理功能，而到了外壳部分，它只能拥有Ring 3级别，这个级别能操作的功能极少，几乎所有指令都需要传递给内核来决定能否执行，一旦发现有可能对系统造成破坏的指令传递（例如超越指定范围的内存读写），内核便返回一个“非法越权”标志，发送这个指令的程序就有可能被终止运行，这就是大部分常见的“非法操作”的由来，这样做的目的是为了保护计算机免遭破坏，如果外壳和内核的运行级别一样，用户一个不经意的点击都有可能破坏整个系统。
由于Ring的存在，除了由系统内核加载的程序以外，由外壳调用执行的一般程序都只能运行在Ring 3级别，也就是说，它们的操作指令全部依赖于内核授权的功能，一般的进程查看工具和杀毒软件也不例外，由于这层机制的存在，我们能看到的进程其实是内核 “看到”并通过相关接口指令（还记得API吗？）反馈到应用程序的，这样就不可避免的存在一条数据通道，虽然在一般情况下它是难以被篡改的，但是不能避免意外的发生，Rootkit正是“制造”这种意外的程序。简单的说，Rootkit实质是一种“越权执行”的应用程序，它设法让自己达到和内核一样的运行级别，甚至进入内核空间，这样它就拥有了和内核一样的访问权限，因而可以对内核指令进行修改，最常见的是修改内核枚举进程的API，让它们返回的数据始终 “遗漏”Rootkit自身进程的信息，一般的进程工具自然就“看”不到Rootkit了，
更高级的Rootkit还篡改更多API，这样，用户就看不到进程（进程API被拦截），看不到文件（文件读写API被拦截），看不到被打开的端口（网络组件Sock API被拦截），更拦截不到相关的网络数据包（网络组件NDIS API被拦截）了，幸好网络设备的数据指示不受内核控制，否则恐怕Rootkit要让它也不会亮了才好！我们使用的系统是在内核功能支持下运作的，如果内核变得不可信任了，依赖它运行的程序还能信任吗？ 三 rootkit的未来发展趋势：
未来的rootkit的发展趋势是与恶意软件越多地结合，或者说将自己隐藏于恶意软件之中。这种隐藏技术的最严重后果便是rootkit不但能够轻易的将僵尸隐藏于系统的“视线”之外，还可以避开检测rootkit的最后一道防线-网络检测。而多数公司需要开放着80号端口，因为其雇员需要使用互联网。一些恶意用户使用这个通道传输数据。作为网管员应当知道，这个端口主要用作进入的而不是发出的通信，因为网管员应当依靠网关设备上的过滤器来扫描发出的HTTP数据通信。当然，这需要好好调教你的过滤器。恶意的通信还可以借助可接受的发出数据通信来传输。例如，它可依附于发出的DNS数据包上。因此，建议管理员密切监视三种通信，一是突发的通信，二是大文件通信，三是其它的异常通信。这三者可能表明有人正在远程执行控制命令。
从传统上讲，检测系统上的rootkit要比检测隐藏于网络通信中的rootkit困难得多，因为多数rootkit要比反病毒软件有更高的特权。
不过，我们应当注意这样一个有趣的事实：近来，Vmware公司用其新的VMsafe安全扩展增加了对反病毒的支持，这样就可以在虚拟机监视程序的保护下运行反病毒产品，其特权更高。
四 rootkit的检查和防御：
检查：特定rootkit的检测工具，如RootkitRevealer可以找到内核系统调用和直接磁盘检查的差异，并可以据此检测隐藏的文件、注册表键值及其它属性。例如，在Windows计算机上，可以查找任务管理器的进程列表与内部系统任务列表的差异。
不过，要注意，这些工具的运行级别仍低于rootkit。运行于用户系统上的检测程序需要动态分析计算机，看看计算机是否撒谎。但最佳的方法是从一个完全干净的系统检测当前系统。或者用另外一个原来完全相同的系统对当前系统进行对比，找出其差异。
防御：rootkit要求深度防御，最新的内核级rootkit,将多种类型的恶意代码包装在内,它可以跳转到处理器,在BIOS检测时,再跳转到系统内核,在计算机被清除和恢复后也难于彻底根除。这种永久性rootkit已经成为最危险的rootkit，在两星期以前的黑帽大会上有研究人员已经清楚地演示了这一点。还有一种所谓的游戏僵尸，这种程序尤其喜欢多处理器，它可以运行多个线程，又能平衡负载。其中有些僵尸可通过自动的僵尸程序窃取虚拟币或虚拟货物，然后换卖真实的金钱。rootkit可以从多个方面来利用固件的漏洞，如可借助于启动加载程序、设备驱动程序、闪速固件更新等。
很显然，只有使你的网络非常安全让攻击者无隙可乘，才能是自己的网络免受rootkit的影响。不过，恐怕没有人能够提供这个保证，但是在日常的网络管理维护中保持一些良好的习惯，能够在一定程度上减小由rootkit造成的损失，并及时发现rootkit的存在。不要在网络上使用明文传输密码，或者使用一次性密码。这样，即使你的系统已经被安装了rootkit，攻击者也无法通过网络监听，获得更多用户名和密码，从而避免入侵的蔓延。
防止rootkit 进入您的系统是能够使用的最佳办法。为了实现这个目的，可以使用与防范所有攻击计算机的恶意软件一样的深入防卫策略。深度防卫的要素包括：病毒扫描程序、定期更新软件、在主机和网络上安装防火墙，以及强密码策略等
篇3：服务器实战rootkit检测
本文主要介绍linux上检测rootkit的两种工具: Rootkit Hunter和Chkrootkit.
第一种：Rootkit Hunter
下载地址：ncu.dl.sourceforge.net/project/rkhunter/rkhunter/1.3.6/rkhunter-1.3.6.tar.gz
[root@master ~]# tar zxvf rkhunter-1.3.6.tar.gz
[root@master ~]# cd rkhunter-1.3.6
[root@master rkhunter-1.3.6]# ./installer.sh --install
[root@master master]# rkhunter --update
[root@master master]# rkhunter -c
Checking system commands...
Performing 'strings' command checks
Checking 'strings' command [ OK ]
Performing 'shared libraries' checks
Checking for preloading variables [ None found ]
Checking for preloaded libraries [ None found ]
Checking LD_LIBRARY_PATH variable [ Not found ]
Performing file properties checks
Checking for prerequisites [ Warning ]
/bin/awk [ OK ]
/bin/basename [ OK ]
/bin/bash [ OK ]
/bin/cat [ OK ]
/bin/chmod [ OK ]
/bin/chown [ OK ]
/bin/cp [ OK ]
/bin/csh [ OK ]
/bin/cut [ OK ]
/bin/date [ OK ]
/bin/df [ OK ]
/bin/dmesg [ OK ]
/bin/echo [ OK ]
/bin/ed [ OK ]
/bin/egrep [ OK ]
/bin/env [ OK ]
/bin/fgrep [ OK ]
/bin/grep [ OK ]
/bin/kill [ OK ]
/bin/logger [ OK ]
/bin/login [ OK ]
/bin/ls [ OK ]
/bin/mail [ OK ]
/bin/mktemp [ OK ]
/bin/more [ OK ]
/bin/mount [ OK ]
/bin/mv [ OK ]
/bin/netstat [ OK ]
/bin/ps [ OK ]
/bin/pwd [ OK ]
/bin/rpm [ OK ]
/bin/sed [ OK ]
/bin/sh [ OK ]
/bin/sort [ OK ]
/bin/su [ OK ]
/bin/touch [ OK ]
/bin/uname [ OK ]
/bin/gawk [ OK ]
/bin/tcsh [ OK ]
/usr/bin/awk [ OK ]
/usr/bin/chattr [ OK ]
/usr/bin/curl [ OK ]
/usr/bin/cut [ OK ]
/usr/bin/diff [ OK ]
/usr/bin/dirname [ OK ]
/usr/bin/du [ OK ]
/usr/bin/elinks [ OK ]
/usr/bin/env [ OK ]
/usr/bin/file [ OK ]
/usr/bin/find [ OK ]
/usr/bin/groups [ Warning ]
/usr/bin/head [ OK ]
/usr/bin/id [ OK ]
/usr/bin/kill [ OK ]
/usr/bin/killall [ OK ]
/usr/bin/last [ OK ]
/usr/bin/lastlog [ OK ]
/usr/bin/ldd [ Warning ]
/usr/bin/less [ OK ]
/usr/bin/links [ OK ]
/usr/bin/locate [ OK ]
/usr/bin/logger [ OK ]
/usr/bin/lsattr [ OK ]
/usr/bin/lynx [ OK ]
/usr/bin/md5sum [ OK ]
/usr/bin/newgrp [ OK ]
/usr/bin/passwd [ OK ]
/usr/bin/perl [ OK ]
/usr/bin/pgrep [ OK ]
/usr/bin/pstree [ OK ]
/usr/bin/readlink [ OK ]
/usr/bin/runcon [ OK ]
/usr/bin/sha1sum [ OK ]
/usr/bin/sha224sum [ OK ]
/usr/bin/sha256sum [ OK ]
/usr/bin/sha384sum [ OK ]
/usr/bin/sha512sum [ OK ]
/usr/bin/size [ OK ]
/usr/bin/stat [ OK ]
/usr/bin/strings [ OK ]
/usr/bin/sudo [ OK ]
/usr/bin/tail [ OK ]
/usr/bin/test [ OK ]
/usr/bin/top [ OK ]
/usr/bin/tr [ OK ]
/usr/bin/uniq [ OK ]
/usr/bin/users [ OK ]
/usr/bin/vmstat [ OK ]
/usr/bin/w [ OK ]
/usr/bin/watch [ OK ]
/usr/bin/wc [ OK ]
/usr/bin/wget [ OK ]
/usr/bin/whatis [ Warning ]
/usr/bin/whereis [ OK ]
/usr/bin/which [ OK ]
/usr/bin/who [ OK ]
/usr/bin/whoami [ OK ]
/usr/bin/gawk [ OK ]
/sbin/chkconfig [ OK ]
/sbin/depmod [ OK ]
/sbin/fuser [ OK ]
/sbin/ifconfig [ OK ]
/sbin/ifdown [ Warning ]
/sbin/ifup [ Warning ]
/sbin/init [ OK ]
/sbin/insmod [ OK ]
/sbin/ip [ OK ]
/sbin/kudzu [ OK ]
/sbin/lsmod [ OK ]
/sbin/modinfo [ OK ]
/sbin/modprobe [ OK ]
/sbin/nologin [ OK ]
/sbin/rmmod [ OK ]
/sbin/runlevel [ OK ]
/sbin/sulogin [ OK ]
/sbin/sysctl [ OK ]
/sbin/syslogd [ OK ]
/usr/sbin/adduser [ OK ]
/usr/sbin/chroot [ OK ]
/usr/sbin/groupadd [ OK ]
/usr/sbin/groupdel [ OK ]
/usr/sbin/groupmod [ OK ]
/usr/sbin/grpck [ OK ]
/usr/sbin/kudzu [ OK ]
/usr/sbin/lsof [ OK ]
/usr/sbin/pwck [ OK ]
/usr/sbin/sestatus [ OK ]
/usr/sbin/tcpd [ OK ]
/usr/sbin/useradd [ OK ]
/usr/sbin/userdel [ OK ]
/usr/sbin/usermod [ OK ]
/usr/sbin/vipw [ OK ]
/usr/sbin/xinetd [ OK ]
/usr/local/bin/rkhunter [ OK ]
/etc/rkhunter.conf [ OK ]
[Press
第二种：Chkrootkit
下载 www.chkrootkit.org/download/
[root@master ~]# wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz
[root@master ~]# tar zxvf chkrootkit.tar.gz
[root@master ~]# cd chkrootkit-0.49/
Chkrootkit
Chkrootkit由Nelson Murilo和Klaus Steding Jessen开发. 与Rootkit Hunter程序不同的是, chrootkit不需要installer安装程序, 你只需解开软件包后执行chrootkit即可, 然后将对一些二进制文件进行一系列的测试, 除了与Rootkit Hunter相同的测试外, Chkrootkit还对一些重要的二进制文件进行检测, 比如搜索入侵者已更改日志文件的特征信息等等. 而且, 如果你想列出已经测试的所有项目, 你可以运行带有’-l’参数的命令:
# chkrootkit -l
在测试过程中, 如果你想在屏幕上看到更多有用的信息, 执行下面命令:
# chkrootkit -x
chkrootkit将在专家模式(expert mode)运行.
在Linux上组合使用Rootkit Hunter和Chkrootkit工具是检测rootkis不错的办法.
参考:
Various ways of detecting rootkits in GNU/Linux
篇4：防御网络威胁十要素
【IT专家网独家】目前互联网上存在各种威胁，企业要采取积极的措施提高网络安全。下面是企业防御网络威胁的十种方法。
1.封锁对恶意服务器的访问
当台式电脑用户请求访问已知的恶意服务器的HTTP和HTTPS网页的时候，你要立即封锁这个请求，节省带宽和扫描资源。
2.限制在可信赖的网站使用移动代码
虽然脚本和活跃代码等移动代码能够给网络更有兴趣和拥有更丰富的应用程序，但是，它也能够给 提供自动化的入侵方法，让 侵入台式电脑，运行可执行的
代码或者应用程序以便执行嵌入在文件中的脚本。
3.扫描Web网关
不要推测你的所有的台式电脑都有最新的杀毒软件或者来访的计算机都是得到很好的管理的。你要通过集中扫描恶意软件轻松地控制所有的Web通讯(HTTP、HTTPS和FTP)，要在Web通讯进入你的网络之前进行扫描，不要在通信已经进入台式电脑才进行扫描。
4.使用不同厂商的产品进行台式电脑和Web网关扫描
现代的攻击在发动之前都针对流行的杀毒软件进行测试。你的恶意软件扫描的多样性有助于提高阻止威胁的机会。
5.定期更新台式电脑和服务器补丁
大多数攻击和威胁是利用没有使用补丁的应用程序和系统传播的，
保护你的计算机避免受到已知的安全漏洞影响能够减少你的风险。
6.保持台式电脑安装杀毒软件并处于最新状态
自从启动扇区病毒出现以来，运行杀毒软件检查进来的文件、扫描内存、扫描现有的文件一直是一种标准的做法。没有任何运行Windows操作系统的计算机应该没有最新的杀毒软件。如果病毒避开了其它的网络防御，台式电脑中的杀毒软件就是最后一道防线。此外，还要采取强大的保护措施防止CD光盘或者优盘等非网络方式传播的任何恶意软件。
7.仅访问通过全部浏览器检查的HTTPS网站
大多数用户不理解三个SSL浏览器检查的重要性，或者不理解他们不应该访问没有通过这三项检查的网站。这三项SSL检查是过期的证书、不可信赖的发放者以及证书与请求的URL之间的主机名不匹配。
8.仅从可信赖的网站下载可执行程序
社会工程学还活着并且在互联网上活得很好。发布恶意软件的一个有效的方法就是利用一些有用的程序。当执行这些有用的程序时，恶意软件就可以自由地做自己喜欢的事情。这种攻击也称作木马攻击。
9.不要访问IP地址为服务器的网站
最近的攻击更多地利用安装简单的网络服务器软件的被攻破的家庭电脑。受害者经常被引导到网页地址中包含IP地址的新的家庭电脑服务器，而不是主机域名。合法的网站将在网页地址中使用主机名。
10.认真键入网站URL地址避免错误输入
用户永远不愿意访问恶意网站，但是，这种情况会意外发生。错误地输入流行网站的地址通常会导致用户访问等待那些不加防备的用户的恶意网站。如果你的浏览器没有完全使用补丁，你很容易在浏览网页时无意下载恶意软件。
篇5：级反主动防御rootkit设计思路
June 18,
关键字：rootkit，反主动防御，网络监控，ring0，mcafee8.5i，KIS6，ZoneAlarm Pro，实用级产品测试
目录：
反主动防御rootkit的产生背景及其必要性
反网络访问主动防御
反API钩子进程行为主动防御
反系统Notify进程行为主动防御
绕过监控进入ring0安装驱动
实用级反主动防御rootkit的通用性问题
反主动防御rootkit的产生背景及其必要性
当前随着新型木马，病毒，间谍软件对网络安全的威胁日益加重，传统的特征查杀型的安全产品和简单的封包过滤型防火墙已不能有效保护用户，因此各大安全公司纷纷推出自己的主动防御型安全产品，例如卡巴斯基kis6，mcafee8.5i，ZoneAlarm Pro等，这些产品应对未知的病毒木马都有很好的效果，若非针对性的作过设计的木马和rootkit，根本无法穿越其高级别防御，因此，反主动防御技术，作为矛和盾的另一方，自然被渗透者们提上日程；由于主动防御安全产品的迅速普及，为了不使后门木马被弹框报警，具有反主动防御能力的rootkit成为了一种必然选择。
反网络访问主动防御
几乎现在每个防火墙都具有应用程序访问网络限制功能。一个未知的程序反弹连接到外网，或者是在本地监听端口，基本上都会引起报警。而且对系统进程的行为也有了比较严格的审查，原先的注射代码到winlogon等系统进程，在向外反弹连接的方法，很多主动防御软件都会阻止了。
很多防火墙的应用程序访问网络限制，都可以通过摘除tcpip.sys上面的过滤驱动，并还原tcpip.sys的Dispatch Routines来绕过。据称这是因为在ndis层次取得进程id不方便而导致的。但是如果在一个实用级的rootkit里应用此方法则是不智之举，因为存在部分防火墙，如ZoneAlarm，其ndis过滤层必须和tdi过滤层协同工作，才会放行网络连接。至于ndis层次的中间层驱动的摘除，和 NDIS_OPEN_BLOCK的还原，则是一项不太可能完成的任务，因为无法从原始文件中读取的方法，获得NDIS_OPEN_BLOCK的原始值；即使能够成功恢复ndis钩子，也不能保证系统可以正常运行，很可能会出现各种不明症状。
到现在为止，绕过应用程序访问网络限制最好的选择，还是那两个：简单的一个，注射代码到一个ie进程，用它反弹连接出来，访问外网；复杂的选择则是应用内核驱动，如ndis hook/添加新的ndis protocol，来实现端口复用，或者使用tdi client driver反弹连接。已经有很多木马和rootkit使用前者，因其简单易行，在实际开发中工程量小，出现问题的可能性也少得多，产品成熟的时间代价也小。但是目前很多的主动防御已经注意到这一点，并且在程序行为监控中严密防范了其他程序对ie的感染行为。
如图，想要使用僵尸IE访问网络的木马被拦截
反API钩子进程行为主动防御
接下来是主动防御系统的很重要的一部分：进程行为监控。该部分主动防御软件一般通过两种解决方案来执行，一是API钩子，二是windows支持的notify routine。
大量的主动防御安全软件，如KIS6，ZoneAlarm Pro，使用API钩子来监控进程的危险行为。如注射远程线程，启动傀儡IE，加载驱动，注册服务，修改敏感系统注册表键值等。但是作为一个 rootkit，完全绕过这些操作，基本上是不可能的；于是摆放在面前的任务，就是如何击败这种主动防御。
对于特定种类的监控，总是有特定的方法可以绕过。比如注射远程线程，如果常用的CreateRemoteThread被监控了，可以尝试采用Debug API， SetThreadContext的方法绕过，也可以尝试采用hook其ntdll!ZwYieldExecution等频繁调用的函数来装载自己的 DLL模块。 注册表监控，我的朋友xyzreg曾经写过系列文章，提出了很多种方法，包括RegSaveKey, Hive编辑等方法绕过卡巴斯基的注册表监控，其Hive编辑的方法目前仍未能有任何主动防御系统拦截。
但是从一个通用型，为实战设计的实用型rootkit来说，采用这些特定的技术并不是一个非常好的选择；因为这些技术可以保证对付一个主动防御软件，却不能保证通用，甚至通用性很差。而且针对每一个可能被主动防御拦截的行为，都采用一套特定的绕过技术，从工程代价上来讲，太过巨大，开发耗时，等其成熟更是不知道要多少时间来测试和更改。因此我们需要的一个相对涵盖范围广，能够解决绝大多数主动防御技术的解决方案。
针对API钩子实现的进程行为监控，一个较好的通用解决方案就是卸载所有安全软件所安装的API钩子。为兼容性和稳定起见，几乎所有的安全软件在安装API钩子时都会选择hook SSDT表，例如KIS6，ZoneAlarm Pro。我们如果能够进入ring0，就可以使用一个驱动程序，读取系统文件 ntoskrnl.exe/ntkrnlpa.exe/ntkrpamp.exe，从中提出我们所希望的SSDT表的原始函数地址，替换被安全软件 hook的地址，用此方法可以通用性很好的解决绝大多数的API钩子实现的进程行为监控。不过此方法有一个前提，就是事先必须绕过监控进入ring0。关于如何实现此前提，请阅读第五部分，“绕过监控进入ring0安装驱动”。
如图，ZoneAlarm Pro更改了大量的SSDT函数地址来监控程序行为。
反系统Notify进程行为主动防御
部分主动防御安全软件不仅仅是用API钩子，同时使用了微软提供的Notify Routine，来监视进程的行为。使用该技术的安全软件不是太多，但是也不至于少到一个实用级别rootkit可以忽略的程度。
以下几个微软DDK函数，PsSetCreateProcessNotifyRoutine， PsSetCreateThreadNotifyRoutine，PsSetLoadImageNotifyRoutine，被用作支持主动防御软件监控新进程的建立，新线程的建立，和一个新的模块被加载。处理该种类型的防御不能简单的清空NotifyRoutine就完事，因为系统本身，还有一些第三方正常模块和驱动，可能添加和使用该链表。
解决方案，一是可以先将使用了该技术的主动防御系统的驱动程序模块做一个列表出来，然后遍历这三条链表，找出地址指向这些驱动模块的项，再将这些项删除脱链，
但是这需要对大量主动防御系统的研究和测试，并且通用型也不好。第二种方法，由于 Notify Routine的监控力度要远弱于API钩子，因此在纯ring3将程序做一些小的改动，就可以越过这种类型的监控。
另外还有几个SDK函数，可以提供对文件和注册表的更改的notify。不能排除也有部分主动防御软件使用了它们。例如国产的超级巡警 (AST.exe)，使用了RegNotifyChangeKeyValue，做了对注册表敏感键值修改的事后警告提示。如果仅仅使用了API钩子清除技术，那么在此时就会被AST报警。和以上介绍的三个内核notify类似的也是，有不少正常的notify在被使用，不分青红皂白的全部卸载，会导致系统异常。
因此可见，Notify类监控虽然使用的不多，但是其对付的难度和需要的工程量，比API监控还要大。
如图，已经处理了API钩子监控的rootkit仍然被notify方式的AST报警。
绕过监控进入ring0安装驱动
这部分是重中之重。由于几乎每个主动防御系统都会监控未知驱动的加载和试图进入ring0的举动，而我们在第一，第二和第三部分绕过主动防御要做的处理，都必须需要ring0权限。因此监控进入ring0，是一个独立的话题，也是我们实现前三个部分需要的条件。
直接添加注册表项，ZwLoadDriver安装驱动，是几乎要被任何主动防御系统报警。必须要采用一些隐蔽的或者是为人不知的方法。总结目前已经公布出来的进入ring0的办法，
有以下几种：
感染文件，例如win32k.sys，添加自己的代码到里面，启动的时候就会被执行。这种方法的优点是简单易行，稳定度和兼容性很好。但是最大的缺点就是必须重新启动以后，才能进入ring0，这是一个产品级别的后门所不能容忍的。而且微软自己的系统文件保护容易绕过，mcafee和卡巴斯基的文件监控可就不是那么容易了。
利用物理内存对象，来写入自己的代码到内核，并添加调用门来执行。这个是最早被人提出的不用驱动进入 ring0的办法。因为出来的时间太长了，所以有以下一些问题：更新的操作系统内核不支持，如SP1；很多的主动防御系统会拦截，例如KIS6。所以这个办法也不理想。
利用ZwSystemDebugControl。这个代码在国外有人放出来过，利用它写内存，挂钩 NtVdmControl，进入ring0。此法缺陷在于老的windows不被支持，最新的windows2003sp1上也取消了这个函数的此能力。不过好处在于，这个方法用的人少，基本上没有主动防御会注意到它，并进行拦截。
利用 ZwSetSystemInformation的SystemLoadAndCallImage功能号加载一个模块进入ring0。这个方法提出来比较久了，但是因为用的人少，仍未被主动防御软件所重视。用得少的原因是，它不好用。它只能加载一个普通的模块到内核并且调用，却不是加载一个驱动，因此没有一个DriverObject。这导致了非常多的麻烦。因为要想使用这个办法，必须先用这个办法安装一个简单的内核模块，再用这个模块添加调用门等方式，执行代码清除主动防御的监视驱动安装的钩子，安装一个正常的驱动，才能最终完成任务。而且这个方法似乎对windows2003sp1以上的系统也无效。
因此，要想有一个相对完美的进入ring0解决方案，最好是寻找别人不知道或者使用很少的方法，或者将上面的有缺陷的方法做一个综合，用多种方法通过判断情况来选择使用。我在这里有一个新的思路提供给大家，微软新公布了一部分文档，关于HotPatch的使用。HotPatch可以在执行中修改系统中存在的用户态公用dll的内容，甚至是修改内核模块的内容。具体代码和细节，在这里我不能多说。
要想开发一个好的反主动防御 rootkit，绕过监控进入ring0是必不可少的，然而这部分也是使用不成熟技术最多的，最容易出现严重问题的部分。作为一个负责任的实用级产品，一定要对这个部分作做详细的测试，来保证自己的产品不会在某些特殊的环境，比如64位CPU运行32位系统，多核处理器，HyperThread处理器上面，出现故障或者蓝屏。
实用级反主动防御rootkit的通用性问题
前文已述，本文的宗旨在于讨论一种实用级别rootkit开发的可行性。因此，工程量的大小，需要投入的人力，时间和金钱，也是我们需要考虑的内容。必须要考虑更好的兼容性通用性，和工程上的开发代价和稳定成熟周期不能无限大。因此，对于部分新技术，例如BiosRootkit，VirtualMachine-Rootkit，本文不做讨论，因为那些都属于如果要想做稳定通用，工程代价非常大，以至于他们只拥有技术上面的讨论价值，而不具备作为一个产品开发的可选解决方案的可能性。至少是目前来看是如此。
每个主动防御软件的原理和构造都是不相同的，因此不可能指望有某一种方法，从工程上可以解决一个主动防御系统，就可以无需测试的，保证无误的解决其他系统。因为这个原因，开发一个成熟稳定的反主动防御rootkit，必然要在兼容各种主动防御的系统的通用性上面下大功夫。按照不同的主动防御系统，在程序里switch case，应该是非常必要的，尽管绝大多数反主动防御代码原理上可以通用。基本上，在测试程序通用型的时候，常用的主动防御软件，是每种都要安装一个并且仔细测试的。
以下举例说明，几个常用主动防御系统各自需要注意的特点，这都是笔者在实际开发中遇到的比较典型的例子。
Mcafee8.5，该主动防御软件在最大化功能时会禁止在系统目录下创建可执行文件，光这一点就会让几乎全部rootkit安装失败，若非针对它做了设计。在这个系统下面，也不可能使用感染文件的方法来进入ring0。
KIS6，该系统会自动列举运行的隐藏进程，并且弹框警告。因此在这系统下，不太可能把自己的进程隐藏。而且它列举隐藏进程的手段很底层，很难绕过。
ZoneAlarm Pro，该系统下，如果一个其它的进程启动IE并且访问网络，安全报警仍然会以该进程本身访问网络为准执行，另外还会弹框警告，除非将自己的僵尸IE进程的父进程更改，或者不用IE来反弹连接。
国产的瑞星，总体来说这个系统的主动防御弱于国外产品，但是它特殊在于，会对IE作出非常严格的限制，默认不允许IE装载任何非系统的dll。因此在这个系统下基本不可能利用IE反弹。
其他的特殊情况还有很多。作为一个成熟产品开发者，这些都是必须要考虑的。
感谢：VXK（郭宏硕）， xyzreg（张翼）。
附录：提供几个录像，对本文的内容做一个展示录像，Rootkit穿越各种流行的主动防御系统。
篇6：杂谈入侵检测防御系统
几乎所有当前市场上的网络入侵检测系统都是基于一种被动数据收集方式的协议分析，我们可以预见，这种方式在本质上是有缺陷的，
毫无疑问，这样的入侵检测系统会监视整个网络环境中的数据流量，并且总是与一种预定义的可疑行为模式来进行对照，甚至所谓的入侵行为分析技术也只是简单地从单位时间状态事件技术上做了些组合工作，事实上离真正实用的复杂 入侵行为的剖析和理解还有很远的距离。
对于这种检测技术的可靠性，我们可以通过自定义的三种可行性很强的攻击方式来验证――插入攻击、逃避攻击和拒绝服务攻击。我们可以看到，当一个入侵者实施了这样的入侵策略以后，所谓的入侵检测系统便妥协了。我们的结论是这种入侵检测系统不是放之四海而皆准的，除非它们从根本上被重新设计过。
真正实用的入侵检测系统的存在价值就是能够察觉 的入侵行为并且进行记录和处理，当然，人们也会根据自己的需求提出需要强大的日志记录策略、入侵诱导等等。
不同的入侵检测系统存在不同的入侵分析特征。一个企图检测Web入侵的系统可能只会考虑那些常见的恶意HTTP协议请求；同样道理，一个监视动态路由协议的系统可能只会考虑网络是否存在RIP欺骗攻击等等。目前国内市场上的大部分入侵检测系统使用同一个入侵行为定义库，如著名的SNORT特征库，这说明我们在技术挖掘方面的投入还不够，事实上我国在基础研究设施的投入上也存在严重不足。
入侵检测系统现在已经成为重要的安全组件，它有效地补充和完善了其他安全技术和手段，如近乎快过时的基于协议和端口的防火墙。入侵检测系统为管理人员提供相应的警告信息、报告可能发生的潜在攻击，从而抵挡了大部分“只是对系统设计好奇”的普通入侵者。
世界上已经开发出了很多种入侵检测系统，我们可以用通用的入侵检测体系结构（CIDF:Common Intrusion Detection Framework）来定义常见的入侵检测系统的功能组件。这些功能组件通常包括事件产生器、分析引擎、存储机制、攻击事件对策。
许多入侵检测系统在设计之时就仅仅被考虑作为警报器。好在多数商业化的入侵检测系统配置了可用的防御性反攻击模块，起码可以切断TCP连接或动态地更改互动防火墙过滤规则。这样就可以阻止 沿着同一路径继续他的攻击行为。一些入侵检测系统还配置了很好的攻击诱骗模块，可以为系统提供进一步的防护，也为进一步深入研究 行为提供了依据。
对于比较普遍的两种入侵检测模式--基于网络的入侵检测和基于主机的入侵检测，我们可以这样考虑：基于主机的入侵检测系统对于特定主机给予了定制性的保护，对于发生在本地的、用户级的、特征性比较明显的入侵行为有防范作用。但是，这种模式对于发生在网络传输层的入侵通常是无可奈何的，想让应用级特征比较强的系统同时把系统级和网络底层技术实现得比较完善是不太现实的。虽然我们可以看到在伟大的Linux系统上实现了Lids，毕竟象Solaris，NT这样的系统，我们能够了解的只是皮毛。
基于网络的入侵检测系统需要监视整个网络的流量，匹配可疑行为特征。它的技术实现通常必须从网络和系统的底层入手，而且它同时保护的是网络上的一批主机，无论它们使用的什么系统。基于网络的入侵检测系统显然不会关心某一台主机之上正在进行着什么操作，只要这些操作数据不会扩散到网络上来。因为网络入侵检测系统是以行为模式匹配为基础的，我们可以断定它有匹配失误的可能，有因为不能确定某种行为是入侵而将其放行的可能。那么当一个“聪明”的入侵者骗过了这种系统，顺利地进入一台主机，该系统的厄运开始了。
被动的网络监视器通常利用网络的混杂模式工作，它们直接从网络媒介获得网络中数据包的拷贝，而不考虑这些包本来是不应该被它们接收的。当然，这种被动的网络底层协议分析总是“安静地”存在于网络的某个地方，它只是根据网络媒介提供的这种特征，在其他主机不知不觉的时候将网络数据拷贝一份。同时，需要考虑到，根据引擎端实现平台的不同，各平台实现的网络数据包捕获机制的不同，在混杂模式下丢包的程度是不同的。事实上，对于大多数还需要从内核读取数据的应用级包过滤系统，只能考虑以更快的方式把数据读取到用户空间，进而发送给其它进程。 这样处理的化，要求从技术上增加用户空间的缓冲区尺寸，如在BSD(BPF)的系统上，能够利用BIOCSBLEN ioctl调用来增加缓冲区尺寸。
入侵检测系统地最重要的特征莫过于其检测的“精确性”。因此IDS要对捕获到的数据包进行详细的分析，所以对IDS的攻击就是针对IDS在分析数据时的弱点和漏洞。
网络IDS捕获到网络上传输的数据包并进行分析，以便知道一个对象对另一个对象做了什么。IDS总是通过网络上交换的数据包来对终端系统上发生的信息行为进行判断。假设一个带有错误UDP校验和的IP数据包，大多数操作系统会丢弃这样的数据。某些比较陈旧的系统也可能会接受。IDS需要了解每一个终端系统的具体情况，否则IDS按照自己的方式构造出来的逻辑在终端系统上的应用会有不同。某些操作系统有可能会接受一个明显存在问题的数据包，如允许一个有错误的校验和的IP包。当然，IDS如果不进行分辨，必然会丢掉这些本来终端系统会接受的数据。
就算IDS系统知道网络都有些什么操作系统，它也没有办法通过查看一个包而知道是否一个终端系统会接受这个包。原因很简单，CPU耗尽、内存不足都可能导致系统发生丢包现象。
IDS全部的信息来源就是它捕获到的数据包。但是，IDS应该多了解一些关于终端系统的网络行为，应该了解终端系统如何处理各种网络数据。但是，实际上，这是不可能的。
在处理所谓的拒绝服务攻击时，存在两种常见的情况：某些IDS系统在自己处于停机状态时，可以保持网络正常的信息流通，这种属于“fail-open”型；另一种则是“fail-closed”型，即当IDS系统出现问题时，整个网络也随之瘫痪了。
网络检测系统是被动的。它们不控制网络本身，也不会以任何方式维护网络的连接。如果一个IDS系统是fail-open的，入侵者通过各种手段使IDS资源不可用了，那时IDS就没有任何防范入侵的作用了。正是因为这样，IDS系统加强自身抗拒绝服务攻击的能力显得极为重要。
当然，许多攻击方式讨论的都是针对基于嗅探模式的IDS系统。这些类型的攻击都企图阻止协议分析，阻止特征模式匹配，阻止IDS获得足够信息以得出结论。
针对入侵检测系统弱点的攻击探讨
有时IDS系统会接受终端系统丢弃了的数据包。因为IDS认为终端系统接受并且处理了这些数据，而事实上终端系统由于种种原因丢弃了这些数据包。一个入侵者就可以利用这一点，制造那种他所想要入侵的主机会丢弃而IDS系统将接受并作出判断的数据包，以使IDS与终端系统得到不同的结论。
我们可以把这种攻击称为“插入式”攻击。道理很简单，假设一个入侵者发往终端系统的数据是attack，但是，他通过精心构造在数据流中加入了一个多余的t。对于终端系统而言，这个t是被丢掉不被处理的；而对于IDS系统而言，它得到的最终上下文关系是atttack，这个结论使IDS认为这次行为并没有对终端系统形成攻击而不作处理，事实上，终端系统已经接受了attack数据。
现在让我们来分析一下这种方式的攻击如何阻止特征分析。特征分析通常的方式是根据固定模式判断某个特定的字串是否被存在于一个数据流中，例如，对待一个phf的HTTP攻击，IDS通常检查这个字串的存在与否，“GET /cgi-bin/phf?”, IDS系统判断这种情况很容易，只需要简单的子串搜索功能便可以做到，然而，但是，如果一个入侵者通过插入式攻击的思想在这次HTTP请求中增加了这样的内容，GET /cgi-bin/pleasedontdetectthisforme?,里面同样包含了phf,但是在IDS看来，味道已经不一样了。
插入式攻击的的结果就是IDS系统与终端系统重组数据后得到了不一样的内容。通常，插入式攻击在IDS没有终端系统处理数据那么严格的时候都存在。可能好的解决方法就是让IDS系统在处理网络中需要重组的数据的时候，作出严格的判断和处理，尽可能地与终端系统处理地效果一个样。可是，引来了另外一个问题，这便是另一种攻击方式，相对地叫做“逃避式“攻击模式。
相对的，有些数据包是IDS不会接受的，而终端系统却会对这些数据作出处理。当然，IDS由于不接受某些包，而会导致与这些数据相关的上下文关系无法了解。
问题的现象是因为IDS在对数据包进行审核处理的时候过于严格，使得往往某些数据在终端系统而言，是要进行接受重组处理的，而在IDS本身，仅仅是不作处理，导致许多攻击在这种严格的分析引擎的鼻子地下躲过。
逃避式攻击和插入式攻击都有效地愚弄了模式匹配引擎系统。结果都是入侵者使得IDS与终端系统接受处理了不同的数据流，在逃避式攻击中，终端系统比IDS接受了更多的内容而遭受攻击。
还是上面的phf的例子，入侵者发送了一个HTTP请求，使得原本的GET /cgi-bin/phf？在IDS处理的结论中变成了GET /gin/f，当然，这个结论对于大多数IDS系统来说，几乎没有任何意义。
从技术上来看, 插入式和逃避式这两种对付检测系统的方式也不是这容易就被入侵者所利用，因为实现这种攻击要求入侵具备相当的知识面和实践能力。
现在的许多网络协议是简单的并且容易分析的。比如一个普通的网络分析器就能够容易的判断一个UDP DNS请求的目的。
其它的一些协议则复杂的多，在得出实际传输的内容之前，需要对许多单个的数据包进行考虑。这样的话，网络监视器必须总是监视内容的数据流，跟踪包含在数据流中的信息。例如，为了解析出一个TCP连接中发生了什么，必须重组这次连接中的整个数据流。
象TCP这样的协议，允许在IP最大包尺寸范围内的任意大小的数据被包含于每一个分散的数据包中，数据可以无序地到达目的地，每个数据包都具有一个序列号来表明自己在数据流中的位置。TCP数据流的接受者有责任重新按照序列号进行数据包的重新排序和组合，并解析出数据发送者的意思。这有一套TCP的数据重组机制来完成。
在IP层，IP也定义了一种自己的机制，叫做“碎片“，这种机制允许主机把一个数据包切分为更小的数据分片。每一个片都有一个标记，标记自己原来属于原始数据包的什么相对位置，叫做”偏移值“。IP实现允许接受这样的IP碎片包，并且根据偏移值来重组原始数据包。
插入式攻击通过增加一些数据包到数据流中导致终端系统重组很困难。 入的数据包能够改变数据流的先后顺序，进而阻止IDS正确地处理紧跟着的正确的数据包。包的插入重叠了老的数据，在IDS系统上重写了数据流。某些情况下，插入数据包，改变了数据流原来的意思。
逃避式攻击则是导致IDS系统在进行流重组的时候错过了其中的部分关键内容，被IDS忽略的数据包可能对于数据流的顺序来说是至关重要的；IDS系统可能在逃避式攻击之后不知道该如何对这些数据下结论了。许多情况下，入侵者产生整个躲避IDS系统检测的数据流是相对简单的。
插入式和逃避式IDS攻击都不是很容易防范的，除非IDS通过了第二信息源的配合，能够对当前监视的网络拓扑结构以及对作为被监视对象的终端系统所能够接收什么样的数据包进行跟踪分析，否则问题依然存在，这是目前必须要提出来的对被检测网络的诠释技术，尽可能通过配合第二信息源的方式，让IDS对它所检测的网络中的终端系统以及网络实际环境有一个成熟的了解.
如果一个攻击能够造成实现插入任意的IP数据包，那么，插入一个UDP或者ICMP也是没有问题的。所以可以看出IDS系统在IP层实现对这两种入侵手段的免疫将是很重要的。
一个最容易的让终端系统丢弃IP数据包的方式是让数据包具有不正确的IP头部信息。如RFC731定义。入侵者所使用的这些头部信息有问题的数据包在现实中可能会遇到问题，除非攻击对象IDS系统处在同一个局域网之内，例如如果version域不是4，而是其他的值，这种数据包实际上是不会被路由的。当然，对于其他的一些域值，比如IP包长度或者IP头长度，一个不规范的长度将阻止IDS系统正确定位IP中的传输层的位置等。
在IP头域信息中，最容易被忽略的是校验值。似乎对于一个IDS系统去校验每一个捕获的IP数据包的校验是没有必要的。然而，一个带有病态的校验值的数据报对于大多数IP实现来说都是不会被处理的。一个IDS系统在设计的时候考虑到有问题的校验了么？如果没有考虑到校验的必要性，那么很难避免“插入式“攻击。
TTL域表示了一个数据包在到达目的系统的过程中需要经过多少路由器。每一次，一个路由器转发一个数据包，数据包所带的TTL信息将会被消耗。TTL消耗尽时，包也被丢弃了。所以，入侵者可以构建一个TTL的值，使得发送的数据包刚好可以到达IDS系统，但是TTL刚好耗尽了，数据本来应该到达的目标却没有到。
相类似的另一个问题与IP头部的DF标志有关。DF标志置位使得转发设备即便是在包超出标准大小尺寸的时候也不要对数据进行IP分片，紧紧通知简单的丢弃掉这些包。
这两个不明确的问题的解决要求IDS系统能够了解它所监视的网络拓扑结构。
IP校验和问题很好解决；一个IDS系统可以假设如果校验和是错误的，那么数据包将会被目标系统所不接受。而IP的选项域的存在又导致一些不同的可能性。
许多操作系统可以配置为自动拒绝源路由数据包。除非IDS了解是否一个源路由数据包的目标主机拒绝这样的数据包，否则不可能正确处理这样情况。
对IP数据包中的源路由项进行检查或许是一个明显的必要。然而，其他的一些选项也是必须应该考虑的。例如，“timestamp“选项要求特定的数据包的接受者在数据包里放置一个时间戳标记。如果这个选项出现问题，处理事件戳选项的代码将强迫丢弃这个包。如果IDS没有如同终端系统那样核实时间戳选项的话，便存在问题。
同一个LAN上的入侵者能够指引链路层的数据帧到IDS系统，不必允许作为IP目标的主机看到这个包。如果一个入侵者知道了IDS的MAC地址，他便能将他的欺骗包发往IDS系统，LAN上的其他系统不会处理这个数据包，但是，如果IDS不检查接受到的数据包的MAC地址，它是不会知道发生了什么情况的。
逃避式攻击则是导致IDS系统在进行流重组的时候错过了其中的部分关键内容，被IDS忽略的数据包可能对于数据流的顺序来说是至关重要的；IDS系统可能在逃避式攻击之后不知道该如何对这些数据下结论了。许多情况下，入侵者产生整个躲避IDS系统检测的数据流是相对简单的。
因为终端系统将重组IP碎片，所以IDS系统能够进行IP碎片重组也是重要的。一个不能正确的重组碎片的IDS系统将是容易受到攻击的，入侵者仅仅通过人工生产碎片的攻击方式便可以愚弄IDS。IP碎片的数据流通常有序到达。但是，协议允许碎片以任何次序到达。一个终端系统必须能够重组无序到达的数据包分片。
一个IDS系统如果不能处理IP碎片无序到达这种情况的话，也是存在问题的；一个入侵者能够故意捣乱他的碎片来逃避IDS检测。而且IDS必须在全部的碎片都被接收到以后才进行碎片重组。当然了，接收到的分片必须被存储下来，直到分片流可以被重组为一个完整的IP数据包。如果一个入侵者利用分片的形式来对网络进行flooding攻击，那么IDS系统通常会资源耗尽。每个终端系统也必须处理这个问题。许多系统根据TTL来丢弃分片，而避免这种由于大量碎片请求造成的内存不足。
许多入侵者能够刻意地通过构造病态的IP分片躲避传统的包过滤器，他们使用的是尽可能小的分片包，因为单个的分片所包含的数据不足以达到过滤规则对应的匹配长度。
另外，出现的问题是重叠的分片处理问题，可能性是这样的，具有不同尺寸的分片先后到达系统，并且分片的数据位置处于重叠状态，既是说，如果一个分片迟于另外一个分片达到系统，两个分片对于重组参数来说是同一个，这时新到的数据可能会覆盖掉已经先到达的老的一些数据。
这便又提出了一个问题，如果一个IDS系统没有能够以它所监视和保护的终端系统处理分片的方式处理分片包的话，可能面对同一个数据分片流，IDS系统将重组出与终端系统得到的玩全不同的数据包。一个了解这种IDS与终端系统之间矛盾的入侵者可能会采用这种入侵方式。
对于重叠分片的取舍是更加复杂的，对于这些有冲突的分片数据是否被采纳往往取决于他们所在的位置，而根据不同的操作系统对IP碎片重叠情况的不同处理也不一样。有些情况，新的数据被承认而有的时候则是旧的数据被承认，系统选择丢弃新的数据。当然，IDS不能正确分析这种情况，将面临“逃脱式”攻击。
就此问题而言，终端系统的IP驱动程序同样会有问题。或许正是因为IP碎片重组的困难和复杂性才使得出现了那么多不正确的处理方式。所以，除非一个IDS系统准确的知道它所监视的系统都是以何种方式来实现IP驱动的，否则要想精确地重组得到每一个终端系统都接受的数据是不可能的，
例如：Windows NT在处理重叠分片时，总是保留最先到达系统并且被接受的数据包。这与BSD4.4刚好相反。
IP包的选项域是应该被考虑到的。当一个IP包被分片时，来自于原始数据包的选项域信息是否应该被携带到全部的分片中去。RFC791声明某些IP选项如（security）将出现在每一个分片里，而其他的一些必须只出现在第一个分片中。
对于严格的IP实现将丢弃那些具有不正确选项的分片。但是事实上许多系统不是这样处理的。如果IDS没能象终端系统那样精确的处理这种情况的话，将也会面临前面提到的两类攻击。
在面向连接的协议中，象TCP这样的连接协议使用了序列号机制，这种机制提供了一种确认方法。可是，对于无连接协议，这种相对严格的确认机制却是没有的；可以看到，一个入侵DNS的破坏者其实可以是来自任何地方，因为就目前的Ipv4协议，可以简单就伪造出源通讯地址。看来，IDS系统的管理者对于IDS系统给出的网络地址的准确性是应该仔细考虑的。
事实上，被IDS检测到的大部分攻击是通过TCP连接的。所以，IDS对TCP会话数据流的重组能力成为关键问题。但是，到目前为止，我们可以肯定，IDS的这种数据重组能力应该与终端系统重组数据包的方式相一致。对于正常的TCP连接，就像一次由远程登录发起的连接，这很容易做到的。
IDS系统为了能够重建TCP连接会话的信息，TCP片段使用的序列号信息是必须知道的。我们可以把这种IDS去判断当前连接的可用序列号的过程叫“同步”。当然，在判断序列号时出现问题，可以叫“失去同步”。
当IDS系统在一次TCP连接中失去序列号同步了，就不能够对这次连接的信息数据进行有效的跟踪和重组了。在许多情况下，IDS系统由此不能够再接着处理这一次连接中的任何数据信息。所以，入侵者通常把让IDS系统“失去同步”作为一个主要攻击目标。
TCP标准定义了一个流控制机制，用来阻止建立连接的一方发送过多的数据到连接的另外一方；IDS追踪TCP连接的每一方的window域的值。TCP也允许数据流中发送所谓的OOB数据（带外数据），它利用了定义的紧急指针选项。
对于网络中的终端系统，与之相关的每次连接的状态信息的收集处理是没有问题的，每种TCP实现必须管理自己的TCB――TCP会话控制块，以便理解那一次建立的连接情况。一个网络IDS系统也必须能够维护它所监视的每一次连接对应的TCB。
任何网络IDS系统都定义了针对所探测到的新的TCP连接而产生TCB的机制，同时也对那些不再有关的连接进行释放和消除工作。
在讨论IDS的TCP问题中，我们独立地分析三个方面，可以看到，在IDS处理这三种情况时可能出现问题。首先是TCB产生，通过它，IDS决定对一个新探测到的TCP连接产生TCB；其次是数据流重组，IDS根据它所维护地TCB信息对数据流进行重组，当然这一步受到上一步地关联；再者是TCB拆卸，IDS通过它撤销一个TCB。
通过分析可以看到，“插入式”攻击的实现将影响到以上提到的几个方面，插入式攻击使得IDS系统分不清到底什么数据事实上到达了终端系统。比如在数据流重组上下文关系中，数据插入式攻击使得一次可靠的TCP会话监视几乎成为不可能的事；所以说IDS能够针对插入式攻击做处理是非常重要的也是很难实现的。
对于IP协议，可以有几种不同的方法可以实现往IDS系统中插入数据包，而对于TCP，问题会复杂一些，但是同样有一些手段能够导致IDS去主动丢弃某些特定的数据包，以达到入侵者的目的，无论如何，如果一个IDS系统不能够以它所监视的终端相同的方式来处理TCP包的话，对待”插入式“将受到威胁。
在一次TCP交互中，如果接收方对应回应了一个信息，那么一个TCP片段就是被认可的，我们进一步可能分析回应的是RST信息还是ACK信息。IDS能够通过对这些认可信息的辨识判断一个片段是否是存在问题的
包含在TCP包里面的数据能够被提取出来进行重组，而不去考虑TCP的头域的某些部分。
这种不严格的处理方式使得 “插入式“攻击手段得以成功，所以，在处理TCP数据的时候，先严格考虑TCP头域的信息可用性显得很重要了。
一个极易被忽略的头域是“CODE“，这个头域决定了TCP片段中发送的信息的类型。这个域是一系列二进制标志位。可以看到，某些标志位的组合是不正常的，通常在网络中导致包被丢弃掉。另外，许多TCP实现就不去接收没有ACK位被设置的TCP片段中的数据信息。
根据TCP的标准定义，TCP应该接受包含在SYN类型片段中的数据信息。而对这种定义的理解却变成了多种味道，导致一些TCP实现没有正确地处理这类信息。如果一个IDS系统没能考虑SYN数据，那么一个随便的“逃避式”攻击就可以对它进行威胁；反之，如果这个IDS系统能够很好地考虑SYN数据了，在针对某些没有正确实现这种定义的终端系统的时候，它显得当不住入侵者刻画的“插入式”攻击。
另外，经常被忽略的TCP输入处理问题是校验和，全部的TCP实现被强制性地要求验证网络校验，许多IDS系统不能做这种检查；所以通过构建有错误校验值的TCP片段就可以简单地插入数据包到IDS系统。
就像处理IP的选项域一样，IDS能够正确的处理TCP的选项域也是十分重要的。可是不幸的是，由于TCP的选项域某些内容被产生和利用的时间还比较短，如timestamp、windows scale这些选项；另外对于何时TCP的选项能够出现在连接的上下文中，TCP标准有专门的规定。某些选项在某些连接状态或许就是不可用或者是非法的。
RFC1323[13]中介绍了两个TCP的选项，这两个选项被设计来增加TCP在高速环境下的可靠性和性能。但是规定这些选项仅仅可以出现在非SYN的分段之中。
因为某些TCP实现会拒绝包含了这些没有见过的选项的非SYN片段，所以IDS也不可盲目的都接受这些有选项的数据包。另外，也有一些终端系统通过忽略这些选项，继续处理这些数据包；所以，可见IDS必须清楚地知道终端系统是如何处理各种数据包的，才能以相对于特定的终端系统正确的处理方式来进行处理而避免如插入和逃避式攻击。
RFC1323 定义了的另外一个叫做PAWS的概念，全称是“protection against wrapped sequence numbers”。使用PAWS的系统将会跟踪分段中的timestamps选项；根据分段中的timestamps响应值判断数据包是否被丢弃，一个入侵者可以很简单的产生一个人工的timestamp值，目的是使得支持PAWS的TCP堆栈不用作出进一步的处理就丢弃这个数据包。
IDS不仅仅需要知道是否终端系统支持PAWS，而且还需要知道终端系统对于timestamps的threshold的值是什么。如果没有这些信息，IDS将会错误地处理不正确地TCP片段，或者对一个片段的合法性作出错误的猜测。
如前面提到的三点，一个IDS系统TCB创造策略决定了IDS如何开始记录一次给定的TCP连接的数据信息，比如象序列号等。这使得IDS可以同步一次需要监视的TCP会话。
然而TCB创造是个麻烦的问题。可以用多种方法可以被利用来判断何时打开一个TCB，但是，这些方法中的每一个似乎证明都是有问题的。TCB创造建立一次连接的初始化状态，包括了连接序列号等信息；通过对IDS的TCB的欺骗行为，入侵者能够破坏那些与这一次被利用的连接具有相同连接参数的将来产生的连接。
作为一个概念，TCB创造对TCP的三次握手是重要的，它其实是一种在主动客户端和被动服务端之间的TCP包的交流。三次握手建立某次连接的初始序列号，还要同时考虑其它的重要的连接参数，如时间戳参数。
通常，在终端系统的TCP实现上，除非三次握手成功，否则TCB建立不起来，也没有必要考虑那么多。没有三次握手，交互的两端没有双方承认的用于继续交换数据的序列号，数据交流是建立不起来的。
但是，在IDS系统中就存在不一样的地方了。IDS或许仅仅通过包含在SYN包中的序列号来判断序列号，或者也可以完全依赖于三次握手给出的信息。当然，如果可能的话，其他方法也可以利用。通常，IDS没有必要在打开一个TCB之前等待完整的TCP三次握手。我们企图概括出一些直接的IDS建立需要的TCB的机制，在一些典型的IDS系统中可以看到。
首先，IDS的设计人员必须作出的决定是是否他的IDS要依赖于完整的三次握手来建立起TCB初始化。一个依赖于三次握手的IDS系统不会记录那些它没有检测到握手信息的数据包的数据。
这有几个较明显的不足，事实上IDS将错失那些它没有发现三次握手的TCP连接。IDS将仅仅能够看到它准备好监视以后产生的连接信息，同样，上面谈到的“逃脱式“攻击将发挥作用，入侵者只要能够让IDS不能发现三次握手就可以绕过IDS检测而入侵终端系统。
为了能够正确的处理TCP的一些扩展特征，例如PAWS，IDS系统必须分析三次握手，三次握手决定了是否某些TCP选项在连接中是合法的。否则，对于IDS要保护某些操作系统如BSD，将会受到“插入式”攻击的威胁。
对于这种要求具备完整的三次握手信息的IDS系统，除非它检测到了并且接受了全部的用于握手的三个数据包，否则它不记录连接数据。当然，我们知道，这三个包当中，有两个来自主动客户端，仅仅有一个来自被动的服务器端，故而，对于对服务器的攻击，攻击的主动权掌握在入侵者手里。使用TCP的术语来说就是，IDS系统直到真正的连接进入了ESTABLISHED状态以后，才开始对连接数据进行记录。
如前所述，由于“逃脱式”入侵技术的存在，这类要求完全建立三次握手的IDS系统是受到威胁的，主要是因为被动造成的IDS丢弃数据包现象使得入侵者的入侵数据逃脱了IDS的监视而到达终端系统。
那种要求至少有部分三次握手信息产生的IDS系统也是需要检测到有某种握手信息后才开始对连接数据进行记录的。三次握手可以使得TCB具有足够的初始化信息，我们也将看到为了同步数据流而盲目地产生TCB而出现的问题，完全地三次握手也使得入侵者哄骗IDS产生失效地TCB的可能性减小了。
然后产生的问题是“三次握手的哪一个部分在IDS产生对应的TCB之前是需要被检测到的？”.一个IDS系统在检测到一个客户端初始连接请求的SYN包时，能够产生一个TCB，或者当IDS检测到服务器返回了一个SYN＋ACK时。在具有一个内外包过滤器作为屏障时，入侵者欺骗服务器的响应是困难的；因此对于一次连接的产生，服务器的SYN+ACK响应是更可靠些的。如果一个入侵者不能欺骗服务器响应，SYN+ACK也包含了正确的连接序列号，IDS将更准确地初始化TCB。
一个IDS系统唯一能够知道一次连接被欺骗的指示是客户端返回给服务器SYN+ACK数据包，这个ACK确认了服务器的初始序列号。如果一个IDS仅仅利用了部分握手信息打开TCB，那么入侵者可以哄骗它为不存在的连接打开TCB。
IDS并不是一个网络连接的积极参与者，通过完整的三次握手而打开TCB可以推断出一次连接的初始状态。当然，IDS完全可以不用考虑三次握手的数据包，对于正常的连接仅仅检测ACK的数据包就可以工作了。
对于一个IDS系统最困难的事应该是对一个TCP连接上被交换的数据流进行精确的重新组合了。当然对于不同的终端系统来说，这些都有精确的定义。
就像对IP碎片重叠的解决，许多操作系统的TCP重组代码中还存在许多不一致的地方，例如，WindowsNT系统往往通过承认重叠数据中老的数据来解决，而4.4BSD系统按照RFC的规定，通常通过承认重叠数据中新的数据来解决。当然，还是一样的，除非IDS系统知道它所监视的网络中的各个系统是如何来处理这些包含了冲突分段的数据流的，否则将不能正确的监视某些类型的终端系统。
这些问题对于大多数连接来说没有表现出些什么问题；正常连接中的大部分TCP分段是顺序地达到，并没有恶意地欺骗性地TCP分段 入到指定地连接流中企图去捣乱IDS系统。然而，在真实地网络中，一个企图逃避IDS监视地入侵者能够使得IDS在监视TCP流的时候尽可能的困难，他们通常会利用现在协议的种种矛盾和限制来达到目的。
存在于IDS的TCP重组代码中问题可能会仅仅当IDS系统接受了某些病态序列的输入的时候才看得出来。大多数时间，IDS看起来都是正在正确的重组着TCP流的。
IDS系统TCB的拆卸策略决定了何时IDS系统停止记录一次连接的数据。TCB的拆卸是必需的，因为跟踪状态信息是很消耗资源的；一个IDS系统如果没有很好地释放TCB占用的资源的话，一个入侵者将会利用这个弱点轻易耗尽IDS资源，只需要作一些无意义的洪流攻击直到IDS不能再跟踪新的连接。
在TCP中，连接在收到明确的要求关闭请求后关闭。两个TCP的信息(RST和FIN)被明确地利用来中断一次连接。除了连接双方的意外中断以外，TCP连接仅仅通过这些信息来中断。TCP明确提出了这些方式，所以IDS利用这些信息来判断何时关闭一次TCB也是合乎逻辑的。
TCP提供了一种周期性交换信息的机制，用来确认连接的双方依然处于连接状态，但是并没有被普遍地利用，同时也需要付出太长的时间来知道一次处于睡眠状态的连接正在被使用。所以，IDS在处理这些没有被明确中断的连接时，也是容易收到洪流攻击的。
对于基于模式匹配的情况，必然要维护上下文的完整性和相关性，如果IDS系统被欺骗而关闭了一个依然处于连接状态的TCB，对于IDS来说，输入流突然中断。一个入侵者能够导致这种TCB不正常中断，而阻止TCB进一步跟踪他的行为，使得入侵者的进一步的攻击信号通过网络到达终端，而这一次连接的TCB已经失效了，模式匹配引擎已经接收不到入侵的进一步上下文关联信息。
另一方面, 对于一个事实上已经关闭的连接，IDS系统不能够成功地拆卸相对应的TCB的话，也是一个脆弱点；一旦端对端的TCP连接被正常关闭，连接参数就能够被重新利用于新的具有完全不同序列号的连接（技术实现上，系统必须等待一段时间才重用连接参数，但是并不是所有的系统都等待）。如果没有同步恢复技术的话，这将导致IDS对于整个连接都将不可分析。
对于IDS系统，判断何时停止跟踪一次连接的一个可能的方式是：监听TCP的表示连接正在被关闭的控制信息。这样做允许一个IDS系统很快恢复那些用于事实上已经中断了的连接的资源，同时也防止了新连接使用同样的连接参数引来的异步问题。不幸的是，因为某些连接中断请求信息可能被控制在入侵者手里，所以完全信任这些信息也是有风险的。
TCP提供了两个连接拆卸消息，第一个信息考虑“顺序的”连接拆卸，连接的两端承认连接的终止并且确信他们所传输的数据在连接关闭之前已经传输完毕。第二个信息是由于某些错误意外终止连接。
借助于FIN消息，TCP提供了顺序地拆卸连接的方法。一个发送FIN消息的系统表示它已经结束发送数据了，并且准备关闭这次连接。当FIN消息被确认了，连接的每一端发送一个消息来结束连接。
每一次连接直到连接的双方都发送一个FIN消息，并且彼此确认了对方的消息之后被关闭。一个入侵者必须构造看起来是从服务器发出的伪造数据包来欺骗这类FIN的连接关闭机制。
对于IDS系统，仅利用FIN消息来判断中断连接TCB是不足够的。TCP提供了一种方式，利用RST消息来通报连接的另一端连接已经关闭了。RST分段不被通过ACK消息验证；如何知道一个RST消息已经被终端系统接受，唯一的方法是观察是否终端系统继续在此连接上发送数据，而在IDS系统中，这样做的唯一的方法是在观察到一个RST消息之后等待连接超时；然而，这样做意味着一个IDS系统可能潜在地、错误地关闭一个处于睡眠状态的连接。
RST带来的问题由于终端系统的TCP实现bugs而显得更加严重。一个RST消息在技术上来讲，仅仅在具有正确的序列号信息才是可用的，具有错误的序列号的RST消息应该被忽略掉。但是，问题是并不是所有的操作系统都检查RST消息中的序列号信息。
利用TCP连接拆卸消息的另外一个方法是在连接变为睡眠状态一段极限时间规定为超时。这样将阻止IDS被错误的TCP拆卸消息所愚弄，同时也潜在地简单化了IDS的TCP代码。
当然，这也有代价――依赖于超时机制的TCB拆卸的系统是容易被欺骗的，某些攻击者，专门利用了IDS将因为超时而关闭一个TCB的弱点，刻意在一次连接中等待IDS超时。
目前针对IDS种种弱点刻意进行的攻击都不是容易防范的，除非IDS系统通过了第二信息源的配合，能够对当前监视的网络拓扑结构以及对作为被监视对象的终端系统所能够接收和处理什么样的数据包进行跟踪分析，否则问题依然存在
篇7：简单小方法 让你远离来自Rootkit的威胁
Rootkit已经不是什么新玩意儿了，其祖宗可追寻到UNIX系统，
简单小方法 让你远离来自Rootkit的威胁
。然而，这几年的发展已经使它“日新月异”，我们总是对这种暗藏于系统内部的恶意软件惶恐不已。不过心中想得最多的是要增强对它的防范和斗 争。
魔高一尺 道也高一尺。Rootkit的制造者不断地研究新的方法，以保持其恶意程序的隐藏性；而安全软件设计公司不断地开发、发布其反恶意程序的措施来保护其客户端。总之，两者无休止地进行着这场无硝烟的战争。
检测技术
总体说来，纵观现在的安全领域，我们可以看出有四种技术可以检测系统中存在的Rootkit：
1.基于特征的检测：这是一种成熟的技术，它已经由反病毒公司成功地运用了好多年了。这种技术以成功扫描文件为基础，并将文件与已知恶意软件的特征相比较从而查找并清除Rootkit。
2.基于行为的检测：这种技术通过识别计算机正常活动中的任意背离正常操作的活动而确认Rootkit。
3.比较检测：这种方法将由操作系统返回的结果与通过低级调用所获得的结果相比较，如果有任何的不同，就会展示出系统中存在的Rootkit。
4.集成式检测：这种技术采用一种可靠的测试方法来比较文件和内存中的内容，从而揭示Rootkit的存在，
《简单小方法 让你远离来自Rootkit的威胁》()。
这些技术都有其局限性，为此笔者强烈建议集成不同的技术。还要注意到，有一些阴险的Rootkit进行了特别的设计，目的是避开反病毒公司推向市场的产品检测技术。
防御方法
防御Rootkit的第一道防线就是要阻止其进入你的计算机中。为此，请谨记以下几条抵御恶意软件的基本建议：
安装优良的反恶意软件解决方案，并保持其活动性和最新，及时升级，最好是每天升级。在此笔者对那些使用盗版软件的同志要说一句，千万不要上网随便下载一个杀毒软件就以为万事大吉了，即使能升级也最好不用。由此造成的后果可能要比你省下的金钱要多得多。最好多支持国产的安全软件！
最好安装一个防火墙，它可以帮助你限制那些对计算机的未授权的访问。同样，最好不要用盗版的。
确保安装到计算机上的应用程序能及时安装来自厂商的最新安全补 丁。
不过，万万不可对防范Rootkit的任务看得太简单了，也不能局限于几项普通的保护措施。比如，上网时用普通用户登录而不是用管理员（超级用户）也是个好主意。
篇8：高级WIN2K ROOTKIT检测技术WEB安全
--背景知识
一个在计算机安全领域中重要的问题是,如何判断给定的主机是否已被入侵.由于以下两点这项工作变的非常困难:
1.攻击者可以利用未知漏洞进入系统.
2.当进入系统后,入侵者可通过安装rootkit和后门来隐藏自身(例如:隐藏进程,通讯渠道,文件等).本文将集中讨论在Win2K系统下rootkit的检测问题.
--传统rootkit检测技术中的一些问题
传统的rootkit检测程序(那些我们经常在UNIX系统中见到的)只能检测一些已知的rootkit(这点使它变的像反病毒程序)或进行一些内核存储的扫描.例如Linux中就有一些工具扫描内核中的syscall table.这显然不够好,因为已经有了很多并不更改syscall table的rootkit,而Win2k下也可开发出类似的rootkit.
那检测程序是不是还应该扫描内核代码空间?这样我们就有了一个运行在内核模式中的Tripwire.但这还不够好,因为在大多数的操作系统中,我们可以写出即不更改SST(syscall table)也不更改代码的内核级rootkit.在系统中有很多可以勾连的函数指针(例见[2]).
以我看,存储扫描技术决不会成为rootkit检测的终结.这主要是因为我们不能确定具体的监测存储区域.
那到底怎样检测出我们系统中的入侵者呢?
首先我们以rootkit中所使用的技术,将其分为两类:
*通过更改系统结构来隐藏某对象的(如运行的进程)和
*更改内核执行路径(例:勾连那些负责枚举活动进程的内核函数)来达到同样目的的.
--更改系统数据结构的rootkit
这类的rootkit不太多.有意思的例子包括fu rootkit(见[3]),通过删除内核中PsActiveProcessList链上的进程对象来隐藏进程.ZwQuerySystemInformation等函数是不能发现这些隐藏进程的.但同时,因为Windows的线程分派器(dispatcher, scheduler)使用另外的数据结构,这些“隐藏”进程仍可运行(被分配到CPU使用时间).Windows的线程分派器使用以下三个(注1)数据结构:
*pKiDispatcherReadyListHead
*pKiWaitInListHead
*pKiWaitOutListHead
后两个是处于“等待”状态的线程链头.他们之间稍有不同,但对我们来说并不重要.
从上面的信息我们可以找到一种检测隐藏进程的方法.及读取线程分派器使用的数据结构,而不是PsActiveProcessList.
当检测rootkit时我们应该尽可能的触及更底层的内核数据结构.
有一点应该注意,直接从线程分派器使用的链中删除要隐藏的进程是不可能的,因为隐藏的进程将分配不到CPU使用时间.
--更改执行路径的rootkit
这类的rootkit较为普及.他们通过修改或增加内核或系统DLL中的指令来达到目的.检测这类rootkit的问题是,我们不知道rootkit在什么地方做了那些修改.它可以勾连DLL中的函数,系统服务列表(System Service Table),改变内核函数的内容或修改内核中一些奇怪的函数指针.
--执行路径分析(Execution Path Analysis)
EPA关注这样一个事实:如果入侵者通过修改执行路径隐藏了一些对象,那么当调用一些典型的系统和库的函数时,系统将运行一些多余的指令.
举个例子,如果入侵者为了隐藏文件和进程而修改了ZwQueryDirectoryFile()和ZwQuerySysteminformation(),那样和干净的系统相比,这些系统函数就会执行更多的指令.不管入侵者采用勾连或在代码中加入jmp指令,或其他任何方法.指令增加的原因是rootkit必须进行它的任务(在这个例子中是隐藏文件和进程).
但是Windows 2000的内核是一个非常复杂的程序,即使在干净的系统中,某些系统函数每次运行的指令个数也是不同的.然而我们可以用统计学来解决这个问题.但首先,我们需要一种测定指令个数的方法......
--指令计数器的实现
单步执行模式是Intel处理器的一个好的特性,我们可以用它来实现指令计数.当处理器处在这个模式时,每执行完一条指令,系统将产生一个除错异常(debug exception, #DB).要进入这个模式,需要设置EFLAGS寄存器中的TF位(详见[6]).
当执行int指令时,处理器会自动清TF位并进行权限切换.这意味着,如果要进行内核模式下的指令计数,则必须在中断处理程序开头设置TF位.因为我们将要测定一些系统服务中的指令个数,勾连中断向量0x2e,也就是Windows 2000下的系统服务调用门会变得很有效.
但是,因为存在用户模式的rootkit,也应该测定在ring3级运行的指令个数.只要在用户模式下设置TF位一次就可以了,从内核返回时,处理器会自动恢复这一位.
以上的计数方法通过内核驱动器实现.如图2所示,驱动加载后勾连IDT 0x1和0x2e.为和用户级程序交互.驱动勾连一个系统调用,用户级程序通过这个特定的系统调用来开关计数器.
--一些测试
我们可以使用上一段中描述的方法来测定任意系统服务中执行的指令个数.
例如,来检查是否有人试图隐藏任意文件,我们可以开始一个简单的测试:
pfStart();
FindFirstFile(“C://WINNT//system32//drivers”, &FindFileData);
int res = pfStop();
如果有rootkit隐藏任意文件,则执行的指令数要比干净的系统多.
如果运行这个测试上百次,并计算执行指令数的平均值,我们会发现这个值是非常不确定的.考虑Win2k的复杂性,这一点也不让人吃惊.但对于我们的检测目的来说,这种现象是不能接受的.但如果我们将得到的那些值的频率分布用条形图表示出来,会发现图中有一个明显的频率高点.如图4和5中所表示那样的,即使是在系统负载很大时,频率高点所对应的数值保持不变.很难解释这个令人吃惊的现象,可能是因为在循环中同一个系统服务被调用几百次后,与这个系统服务相关的缓冲最后会被填入固定的值.
假想现在有人安装了隐藏文件的rootkit,如果我们重复测试并绘制相应的条形图,就会发现频率高点向右移了,这是因为rootkit需要进行隐藏文件的工作.
在现在的代码实现中,只进行了少量的测试,包括典型的服务如:文件系统读取,枚举进程,枚举注册表项以及Socket读取.
这些测试将有效地检测出著名的NTRootkit(见[1]),或最近比较流行的Hacker Defender(见[4]),包括它自带的网络后门,当然还包括很多其他的后门.但要检测出一些更好的后门还要加入一些新的测试.
--误报和执行路径跟踪
虽然对频率高点的检测有助于我们处理系统的不确定因素,但有时会发现测试得到的值有小的差值,一般来说不大于20.
有时这会是一个很严重的问题,因为我们不能确定那些多出来的指令意味着被入侵或只是正常的误差.
为解决这个问题,我们使用了执行路径记录模式.和单一的EPA模式比较,系统增加了对执行路径的记录(包括地址和运行的指令),首先,系统记录下正常情况下的执行路径,以后的每一次运行将产生diff文件(正常系统和现行系统之间的比较).
我们应该使用好的反编译器来分析那些不一样的地方,以此判定他们是否可疑.图6是一个diff文件的例子.
现阶段的diff文件只记录下指令的地址,以后可能将两次测试的不同结果存为PE格式文件,并可用IDA等工具分析.
--检测 ”offset-in-the-code” 的变化
想象有这样一个rootkit,它基本和上面提到的 fu rootkit (见[3]) 一样,但不从PsActiveProcessList中,而是从分派器使用的数据结构中移除进程.我说过那不可能,因为隐藏的进程将分配不到运行时间......
然而,rootkit可以同时更改分派器代码中所使用数据结构的地址(offset),换句话说,就是使其使用不同的链表.但只有分派器使用这个”新的” 链表,而系统其他地方还是使用”旧的”链表...... (见图7).
虽然这种技术不会改变执行指令的个数,我们还是能检测到它,但需要进一步的完善现有的工具.这项功能现在还没有实现,但应该不是很难.
--针对EPA的攻防
我们可以想到一些能骗过EPA类检测工具的方法,先把它们分为两类.
1. 针对特定工具的欺骗
2. 对EPA类技术的通用攻击
首先,我们考虑一下通用的攻击方法和怎样防止这类攻击.接着讨论针对特定工具的攻击以及怎样通过多态来预防.
--对EPA类技术的通用攻击
首先,恶意程序可以勾连包含除错处理程序(debug handler)地址的IDT入口1,这样将暂停记录运行的指令数.当它完成工作时,再恢复 IDT入口1.这样rootkit中所执行的指令数不会被记录.
我们可以使用intel的除错寄存器来防止这类的攻击.可以使用DR0和DR1寄存器对IDT入口1进行写保护.并且为防止rootkit向除错处理程序的开始处写入Jmp指令,还需对其进行读保护.换句话说,我们不想让rootkit发现除错处理程序的地址.但单纯对IDT入口进行读保护是不行的,系统会蓝屏.但有一简单的解决方法,就是增加额外的一层.见图9.
还有一种攻击的方法,在rootkit运行时,其将TF位清零,并在恶意操作完成时恢复TF位,这样检测工具也只能发现运行的指令数和正常的系统有细微差别.
另外,rootkit还能检查TF位, 如发现被跟踪,则不进行恶意操作.这种行为并不会影响rootkit的正常工作,因为只有被检测的进程才被设置TF位.
我们可以防止这种攻击,应该注意到的是运行每一个系统指令前,都会运行我们的除错处理程序.以下是简单的防预方法:
如果除错处理程序发现上一个运行指令是pushf(将EFLAGS寄存器压入堆栈),则运行如下操作.
and [esp], 0xfffffeff;
及清TF位.同样,如果下一条指令是popf(从堆栈载入EFLAGS的值),则运行如下操作.
or [esp],0x100;
及设TF位.这样rootkit就不能更改TF位.
这样的预防几乎可够了,但还不充分.Rootkit仍能以以下方法发现其被跟踪:
setTFbit();
if (checkTFbit()!=1) {
//we are traced!
}
所以我们需要更改反检测部分的操作,使其可以记录TF位有没有被rootkit更改(比如增加一个TFbitset变量).
popf/pushf不是存取EFLAGS寄存器的唯一指令,其它像iret/int等指令也可以[注2],因此还要加入对这些指令的检测.
对EGLAGS寄存器的防护部分还没有被实现.一部分原因是通过对diff文件的分析也可以发现这类攻击.但以后会增加相应代码.
--对特定工具的攻击
如果攻击者了解关于特定检测工具的一切,他会有很多种欺骗的手段.比如,可以更改保存指令数的那个变量.
不过这类攻击具有很强的针对性,如果有很多不同(或非单一版本)的EPA类工具,这样的攻击将不会有效.
当然,我们还是希望可以阻止这类攻击,强大的多态代码生成器可能是唯一的方法.当管理员安装检测工具是,会产生一个独特的内核驱动和测试程序.
多态代码生成器部分还没有被实现.
--相关工作
像文章开头所述,笔者还没有发现任何对rootkit的检测方法,不是基于存储扫描的.
EPA技术并不被OS所局限,笔者在linux下也实现了一相关工具,参5中有对其的详述以及简单的代码实现.
References
[1] Greg Hoglund, et al, ROOTKIT home, telnet://rootkit.com,
[2] palmers, Sub proc_root Quando Sumus, Phrack Magazine, issue 58, 2001.
[3] fuzen_op, fu rootkit, telnet://rootkit.com,
[4] Holy Father, Hacker Defender Home, rootkit.host.sk,
[5] Jan Rutkowski, Execution path analysis, Phrack Magazine, issue 59, 2002.
[6] IA-32 Intel Architecture Software Developer’s Manual, vol1-3.
注1: 作者相信这三个链表包含了系统中所有的线程.但还需进一步研究.
注2: 参6上列举了所有和EFLAGS寄存器交互的指令
