文章来源:名易软件 注:这是一篇基础的应急工具介绍文档。适合经验不多者。限于水平,不足之处请指出。整个文章分三个系列介绍对于OpenBSD,Linux,或者Solaris系统的应急响应和取证过程中有用的工具。本部份聚焦在系统工具上,第二部份主要是介绍文件系统工具,最后部分则主要是网络工具。本文用到的都是基于OpenBSD3.2,DebianGNULinux3.0(woody),RedHat8.0(psyche),andSolaris9(akaSolaris2.9orSunOS5.9)的。 依赖于你所使用的操作系统,本文讨论的许多软件可能不是默认安装的。这种情况下,请根据文章后面的参考部分获得这些工具。 TheSoapbox
那些可以用来处理入侵威胁的工具不在本系列讨论内容中,本文只覆盖在入侵发生之后使用的工具。入侵通常是可以防止的。使用一些比如保证系统更新安装最新补丁的技术,按照最小化服务配置系统,使用设计为安全的操作系统,使用能够加固系统的核心补丁等等,这些来防范入侵的技术可能让你根本就从来不会使用在本系列文章中介绍到的这些工具。 读者应该命令,一旦攻击者获得了系统控制权,这个系统就基本不应该被信任。我们讨论的工具多数都操作在用户方式。一个欺骗的核心模块可能不会让你正常地检查系统,比如,这个系统已经被入侵的情况下。这些欺骗的模块会采用多种办法来隐藏自己,比如根据系统设计来让自己在系统运行的时候不能轻易检测到。这意味着,你不应该相信你使用的那些工具的输出结果。这意味着在响应入侵事件中,应该采取怀疑、研究和谨慎的方式。 你用于分析系统的工具应该是你可以去信任,而且没有被修改的。下面讨论了一些技术,比如将工具保存在离线的只读介质中,这样,你就更可以信赖,而不是那些在已经被入侵的系统上的二进制程序。 你已经做了所有正确的事情,可以进行下面的一些练习,你的系统已经被入侵了。现在怎么办呢? BreakingOuttheToolbelt 现在首先应该检查那些我们后面需要用到的工具。这里不说man(1)提供的信息,特别是因为命令参数因为系统不同而不同。检查这样的信息是留给读者的一种练习。 vmstat-这是可以快速察看内存、CPU和磁盘子系统的命令。vmstat通常执行一个短时间,以便可以察看子系统利用的趋势。vmstat经常可以在系统性能有一些问题的时候帮助我们知道哪些地方应该去深究。 mpstat-这个命令在Linux和Solaris上都有,可以用它察看处理器利用的统计。mpstat提供一个选项,允许在多处理器系统中察看指定CPU的统计。vmstat没有这个功能。 iostat-显示比vmstat更详细的跟子系统相关的统计信息。 sar,sa,lastcomm,last-这些是检查历史数据和一些近来的系统事件。sar是一个Solaris和Linux的系统性能分析工具。这些可以用于检查的性能数据类似于vmstat,mpstat和iostat的显示。sar的数据是一段时间保存的内容,因此可以察看过去的信息。lastcomm可以现在系统最近被执行的命令。这些可以用在系统审计中。sa可以在*BSD和Linux中找到,它给用户在系统审计中更多的选项来收集信息。 ps-立足于进程状态,用于显示系统执行的进程和他们的信息。 top-显示的信息同ps接近,但是top可以了解到CPU消耗,可以根据用户指定的时间来更新显示。 lsof-列举打开的文件,显示系统当前打开的所有文件。Unix系统的所有东西几乎都可以看作是文件,因此lsof也显示了系统的状态中有重要意义的内容。 file-判断文件是什么,不同的文件格式可以16进制的形式现实文件的内容 readelf-显示二进制文件的ELF(可执行链接和格式)头的细节。这些内容可以判断可执行提供的函数。 od-以用户指定的格式输出文件内容。od对于在文件内容中有一些解释的情况下察看原始内容是有帮助的。 ldd-读取ELF头的内容,并显示可执行文件依赖的对象库。 string-现实文件中的ASCII字符串。对于在二进制文件中查找其中可读的字符串是非常有用处的。 find-用于在文件系统中查找指定的对象。 strace-这个工具开始或者附加到一个当前运行的进程中,显示这个进程所作的所有系统调用。这可以用来判断程序运行的行为,并且来决定是否是合适的程序。strace存在于Linux上。在Solaris上是truss,*BSD提供的ktrace可以达到相似的功能。 sudo-可以让管理员给用户以其他用户的权限执行命令的能力,而不用给该用户密码。 grep-用于按照用户指定的模式查询。grep用匹配规则。 less-页面调度程序,用来按页显示文本。 在参考部分中的"CD-ROMandFloppydistributions"[3]中,一些站点介绍了怎么编译这些工具以便用于不同的操作系统,并放置在CD-ROM。现在,开始检查运行的系统了。 运气就是在机会面前有所准备 运气对于技术来说,并不是可求解的。攻击者可以采用很多方法来危及OS的安全。威胁系统安全的漏洞可能是OS提供商,也可以是那些应用软件。当漏洞还没有大面积公布,或者还没有让它的相关提供商自己知道的时候,攻击者已经在IRC里面知道那种系统可以被入侵了。作为一个安全管理员,你必须在这场游戏中表现一直出色。但是,攻击者则只需要一次就足够。 然而,你需要做许多前期的准备工作。你应该有一个应急响应的策略。你必须有一张CD-ROM或者软盘什么的,来存储检查系统中需要的工具,而不是使用被入侵的系统中的工具。如果正使用软盘,让他们处于写保护模式,你可以在取证[5]中获得非常优秀的资源。 现在回到机器上。把事件响应的日期和时间都纪录在记录本上。并且纪录采取的每一步的所有细节和时间。装载CD-ROM或者软盘,并且使用纪录在这些介质上的软件,紧记按照易失性的顺序[6]保存相关的信息到安全的地方。 按照易失性顺序的重要原因是因为入侵事件发生后与之相关信息的数量和自量都将随时间增加而迅速减少。那些经验丰富的攻击者制造的事件则可能让曲线更陡,下降速度更快。 了解自己
可能在入侵事件之前,你已经在系统上花费了大量时间。你了解这些系统的里里外外,进行了相当多的文档工作,并且做了备份。在系统上,开启了进程审计(或者*BSD的系统审计),进行了系统实时数据(sadc[8])来保存系统的性能数据。管理日志的时候,可能没有足够的空间来频繁存储这些数据,你可以发送syslog数据到安全的日志服务器上。 你接到webmaster的电话,他发现某个web服务器上CPU负载很高,而这个服务器每天的浏览量仅仅几千而已。webmaster确信服务器存在有什么问题。 vmstat和mpstat(只在*BSD系统上)表明CPU被用户空间的一个或者多个进程消耗掉了,但是内存和IO子系统还没有大量使用。iostat也显示出磁盘系统不正常。 $vmstat14 procsmemoryswapiosystemcpu rbwswpdfreebuffcachesisobiboincsussyid 10037677562977257096000734413978758 5003766728297725709600000498124910000 600376724029772570960000065215639730 600376760429772570960000053613239730 $mpstat14 20:51:21CPU%user%nice%system%idleintr 20:51:22all100.000.000.000.00479.00 20:51:23all100.000.000.000.00496.00 20:51:24all100.000.000.000.00499.00 20:51:25all97.000.003.000.00481.00 Average:all98.000.601.400.00486.60 $iostat-dk14 Device:tpsBlk_readBlk_wrtnBlk_readBlk_wrtn dev3-00.000.000.01731296 dev3-00.000.000.0000 dev3-00.000.000.0000 dev3-00.000.000.0000 sar(*BSD的sa)显示CPU从早些晚上03:17就开始被使用。lastcomm显示FTP客户端在03:17以root运行了几次,last这个命令显示最近的登录,没有显示出这个时间段有root从什么地方登录进来。另外,这个服务器又使用sudo来管理root权限。这里有两个系统管理员账号可以用root登录,但是他们并没有登录过,特别是在AM3这个时间附近。根据这一点,你决定使用CD上准备好的二进制工具。现在运行top-d1,并且发现apache这个进程占用了100%的CPU。 现在用grep检查apche的错误日志,这个GNU工具可以有更多有用的参数,-A,-B和-C可以让你指定想从哪一个匹配的行的开始,之前或者周围看。grep可以通过-E来使用扩展的模式匹配表达式。可以检查系统日志。但是并没有在这些日志里面检查到什么奇怪的地方。 现在继续进行检查。运行ps-eflcyL(Solaris9),ps-eflcym--headers(Deb3.0,RH8.0)或者psauwxhkwvl(OBSD3.2)。找到进程apache,而这一次发现有问题了。这里只有一个apache进程和多个httpd进程。httpd实际上是Apache服务器,因为httpd是在apachectl文件执行的二进制,运行的apache是前派生的,因此,如果二进制文件被重命名为"apache",那么也应该有多个进程存在。这就是问题所在。 使用lsof-p[9],发现这个apache进程打开了一个叫john.pot的文件。立刻通过google,查询这是一个叫"JohntheRipper"的密码破解工具,正是这个东西让CPU满负荷了。现在来检查这个所谓的apache程序。通过fileapache,表明这个文件是ELF可执行的。现在进行进一步的挖掘,执行readelf-aapache,确信这是一个ELF可执行程序。od-xcapache|less现实ELF魔法数字(7f454c46),ldd显示apache连接的共享对象库比实际的httpd进程小一些,这里面一定有文章: $ldd.apache libc.so.6=>liblibc.so.6(0x4001f000) libld-linux.so.2=>libld-linux.so.2(0x40000000) $lddusrbinhttpd libm.so.6=>liblibm.so.6(0x7002c000) libcrypt.so.1=>liblibcrypt.so.1(0x700c4000) libdb.so.2=>liblibdb.so.2(0x70100000) libdb2.so.2=>liblibdb2.so.2(0x70120000) libexpat.so.1=>usrliblibexpat.so.1(0x70180000) libdl.so.2=>liblibdl.so.2(0x701b4000) libc.so.6=>liblibc.so.6(0x701c8000) libld-linux.so.2=>libld-linux.so.2(0x70000000) 执行:strings|grep-ijohn,显示如下: $stringsapache|grep-ijohn usrharejohnpassword.lst etcjohn.ini ~john.pot etcjohn.ini john JohntheRipperVersion1.6Copyright(c)1996-98bySolarDesigner etcjohn.ini etcjohn.ini etcjohn.ini 用strace-fp"pgrepapache"(Deb3.0,RH8.0),truss-fp"pgrepapache"(Sol9),或者ktrace-dip(OBSD3.2),来察看apache进程到底在做什么。 #strace-fp`pgrepapache` ---SIGALRM(Alarmclock)--- sigreturn()=?(masknow[]) ---SIGALRM(Alarmclock)--- sigreturn()=?(masknow[]) ---SIGALRM(Alarmclock)--- sigreturn()=?(masknow[]) _llseek(4,65536,[65536],SEEK_SET)=0 read(4,"2YUz 2Z 241 2ZA1dkmnr 2ZDa 2ZElnrd"...,4096)=4096 read(4,"25Ma 25Te 26n( 26>% 210n&
|