进入21世纪的信息时代以来,随着计算机网络技术的进步,给人们的生活带来很大的便利。然而在人们越来越依赖网络的同时,网络安全形势日趋严峻,大规模互联网攻击事件频繁发生。如2000年Yahoo等网站遭到大规模拒绝服务攻击,2001年爆发了红色代码等蠕虫事件,2002年全球的根域名服务器遭到大规模拒绝服务攻击,2003年又爆发了SQL Slammer等蠕虫事件,其间还频繁发生着网页篡改和黑客竞赛等安全事件。与此同时,我国的广大互联网使用者还只是刚刚充分享受到互联网的乐趣,网民的整体安全意识薄弱,技术水平很低,加上国家在网络安全方面的法律法规不健全,与互联网攻击相应的法律法规的制定明显滞后。另外在组织体系以及协调机制方面都存在很多不和谐不规范的地方,为此加强国内的网络安全建设是一件紧急迫切的任务。
在常见的安全保障模型中,有一个很著名的PDR模型,其中“P”是protection(防护),“D”是detection(检测),“R”是 response(响应),安全保障的主要操作环节被分为防护、检测、响应这几个主要部分。其中应急响应是安全保障工作中一个非常重要的环节。由于在防护和检测环节,通常比较成熟的应用都是针对已知特征来识别的,因此应急响应可以弥补前面各环节的不足的必要部分:在攻击和防御的对抗中,攻击方通常掌握着主动性和主观能动性,而防御方只有应急响应这个环节可能具备能够和攻击方相抗衡的智能。
我们先来介绍一下应急响应的基本概念和基本内容。英文中紧急响应有两种表示法,即Emergency Response和Incident Response,其含义是指安全技术人员在遇到突发事件后所采取的措施和行动。而突发事件则是指影响一个系统正常工作的情况。这里的系统包括主机范畴内的问题,也包括网络范畴内的问题,例如黑客入侵、信息窃取、拒绝服务攻击、网络流量异常等。一般来讲,在攻击开始以后,如果能够做到在系统被攻克之前发现攻击并进行有效的应对处理,使得攻击不能奏效或被化解,则可以说实现了安全。可见,是否能够做到及时发现和快速响应是实现安全的关键。
在现实生活中应急响应这个环节往往没有得到用户真正的重视。用户总是觉得已经投入了很多购置了全套的设备,不能理解为什么还要不断地支出一笔似乎看不到回报的费用。可是实际上现实经验越来越证明,缺少了高质量的应急响应,整个安全保障环节就好比一个上了大锁的监视系统但是却没有配备保卫人员的住所,攻击者总是可以想办法进入住所的。
应急响应通常需要达到的目标首先是要确认或排除突发事件的发生。在实际的工作中,用户大量的报警被发现是“虚惊一场”。用户可能把各种由于其他原因导致的异常现象都归咎于受到某种攻击所带来的结果。在一个案例中,有一个用户甚至用绝对肯定的口气说,他能够感觉到有人在他的计算机没有任何接口连入网络的情况下,被别人通过电源线实施了监控。从网管的角度来看,经常会面临各种流量异常的情况,其中有时候只是网络中用户应用情况的反映,而有时候确是网络中正在发生某种大量的攻击行为造成的。
应急响应的第一项任务就是要尽快恢复系统或网络的正常运转。在有些情况下,用户最关心的是多长时间能恢复正常,因为系统或网络的中断是带来损失的主要方面。这时候应急工作的一个首要任务就是尽快使一切能够相对正常地运行。
应急响应的第二项任务就是要使系统和网络操作所遭受的破坏最小化。通过收集积累准确的数据资料,获取和管理有关证据。在应急的过程中注意记录和保留有关的原始数据资料,为下一阶段的分析和处理提供准确可信的资料。
最后应急响应要提供准确的分析统计报告和有价值的建议。在响应工作结束时提交的分析。
应急响应的主要阶段
我国在应急响应方面的起步较晚,按照国外有关材料的总结,通常把应急响应分成几个阶段的工作,即准备、事件检测、抑制、根除、恢复、报告等阶段。
准备阶段
在事件真正发生之前应该为事件响应作好准备,这一阶段十分重要。准备阶段的主要工作包括建立合理的防御/控制措施、建立适当的策略和程序、获得必要的资源和组建响应队伍等。
检测阶段
检测阶段要做出初步的动作和响应,根据获得的初步材料和分析结果,估计事件的范围,制订进一步的响应战略,并且保留可能用于司法程序的证据。
抑制阶段
抑制的目的是限制攻击的范围。
抑制措施十分重要,因为太多的安全事件可能迅速失控。典型的例子就是具有蠕虫特征的恶意代码的感染。可能的抑制策略一般包括:关闭所有的系统;从网络上断开相关系统;修改防火墙和路由器的过滤规则;封锁或删除被攻破的登录账号;提高系统或网络行为的监控级别;设置陷阱;关闭服务;反击攻击者的系统等。
根除阶段
在事件被抑制之后,通过对有关恶意代码或行为的分析结果,找出事件根源并彻底清除。对于单机上的事件,主要可以根据各种操作系统平台的具体的检查和根除程序进行操作就可以了;但是大规模爆发的带有蠕虫性质的恶意程序,要根除各个主机上的恶意代码,是十分艰巨的一个任务。很多案例的数据表明,众多的用户并没有真正关注他们的主机是否已经遭受入侵,有的甚至持续一年多,任由他感染蠕虫的主机在网络中不断地搜索和攻击别的目标。造成这种现象的重要原因是各网络之间缺乏有效的协调,或者是在一些商业网络中,网络管理员对接入到网络中的子网和用户没有足够的管理权限。
恢复阶段
恢复阶段的目标是把所有被攻破的系统和网络设备彻底还原到它们正常的任务状态。恢复工作应该十分小心,避免出现误操作导致数据的丢失。另外,恢复工作中如果涉及到机密数据,需要额外遵照机密系统的恢复要求。对不同任务的恢复工作的承担单位,要有不同的担保。如果攻击者获得了超级用户的访问权,一次完整的恢复应该强制性地修改所有的口令。
报告和总结阶段
这是最后一个阶段,但却是绝对不能够忽略的重要阶段。这个阶段的目标是回顾并整理发生事件的各种相关信息,尽可能地把所有情况记录到文档中。这些记录的内容,不仅对有关部门的其他处理工作具有重要意义,而且对将来应急工作的开展也是非常重要的积累。
以上总结了应急响应的重要性和必要性,下面介绍一下linux下应急响应的方法和流程,本文的测试系统为redhat9.0.
在linux上进行应急响应时,有必要创建自己的应急响应工具箱,这些工具包括如下命令,
ls dd des file
find cat lsof md5 sum nc
netstat pcat perl ps strace
strings truss df vi
cat kstat ifconfig chkrootkit
more gzip last w rm
script bash modinfo lsmod
在Linux上创建响应工具包时,可以用gcc的–static参数编译源代码,或者用ldd检查动态连接库,在响应工具包存储介质上建立库文件目录,并拷贝所有工具需要的动态连接库的副本,最后设置环境变量。当然现在网上也有很多很优秀的应急响应工具,例如knoppix-std就是一款很优秀的应急响应工具,大家可以从http://s-t-d.org/download.html下载到knoppix-std的最新版本。
当有了自己的应急工具箱之后,我们就可以进行具体的应急响应步骤了,这里我们分如下几个步骤:
查看登陆系统的用户:
我们用w命令显示当前所有登陆系统的用户,如图1所示,输出标题行显示了当前系统时间,该系统已运行的时间,当前登陆用户数,最近1分钟,5分钟和15分钟内的平均系统负载。
USER字段显示当前登陆的用户名。TTY字段显示了会话的控制终端,tty表示从控制台登陆,pts/typ则可以表示通过一个网络连接,
图1:w命令显示当前登陆系统的用户
查看系统开放的端口:
我们用netstat –an命令来显示当前系统开放的端口,有时系统开放的端口比较多,一页显示不了,我们可以用|more这个管道命令使结果分页显示,便于我们查看,如图2 所示,输出行有5个结果,其中比较重要的是proto显示了使用协议,local address显示了使用的本地ip,这对于NAT地址转换的情况比较有用,还有foreign address显示了外部ip,
state显示了当前这个连接的状态。
图2:netstat –an查看系统开放的端口
查看系统进程:
我们用ps –aux来查看系统的进程列表,如果进程很多,我们同样用|more管道来分页显示结果,如图3所示,ps命令输出中的START字段显示了程序开始运行的时间,对于查出攻击时间很有帮助。有时仅通过时间就能识别可疑进程。
图3:ps –aux显示系统的进程
检测rootkit:
仅仅做了以上工作是不够的,Linux和几乎所有的UNIX都支持LKM(Loadable Kernel Modules),用普通的方法无法检测其存在,这给应急响应带来了极大的挑战性。对于我们来说,解决的办法是找到那些rootkit.所谓 rootkit, 就是有心人士, 整理一些些常用的木马程序, 做成一组程序套件, 以方便 黑客攻入主机时, 在受害的主机上, 顺利地编译和安装木马程序。有时lkm rootkit虽然被成功装载,但在系统的某些细节上会出现“异常”,甚至可能使系统在运行一段时间后彻底崩溃。还有,lkm虽然活动在ring0核心态,但是攻击者往往会在系统的某处留下痕迹,比如攻击者为了让系统每次关闭或重启后能自动装入他安置的内核后门,可能会改写 /etc/modules.conf或/etc/rc.local等。我们可以通过chkrootkit来检测。
chkrootkit检测系统常用命令以及系统的日志和文件,查看是否有恶意程序侵入系统,并且寻找关联到不同恶意程序的信号。使用chkrootkit非常简单。编译程序,解压tar.gz文件,然后如下执行:
# make sense 即可编译。
在完成这个过程之后,你就会看到一个可执行程序:chkrootkit.把这个可执行程序的路径加入系统PATH路径,定期地运行这个程序,就可以定期检测机器上是否有恶意rootkit软件。检测过程如图4所示。
图4:chkrootkit检测rootkit
获取系统日志:
大多数UNIX的日志在/var/log和/var/adm目录下,各种UNIX派生系统日志的具体位置有所不同。
在此之前,有必要了解针对特定系统的日志存贮位置。
比较重要的二进制日志文件:
utmp,用w工具访问;
wtmp,用last工具访问;
lastlog,用lastlog工具访问;
进程记账日志,用astcomm工具访问
在这些日志文件中,最有用的是messages,secure这两个,图5是用more secure 加上|more这个管道的部分显示结果,从日志中我们可以看到哪些时候哪些用户从哪些地方登陆进系统,这对我们的响应取证非常有用。
图5:more secure显示secure的日志
以上是进行应急响应的最重要的一些步骤,当然针对具体的情况需要具体的分析,有时我们需要对包含用户账号的/etc/passwd文件进行检查,以查看是否有陌生的账号成为系统用户。我们也可以使用md5软件对系统中的重要命令和配置文件进行检查和定期对比,以发现潜在的入侵和攻击。另外我们还可以使用 portsentry这个工具进行检测,PortSentry在被保护的机器上是以daemon的形式运行的。在它运行期间,它会监听你指定的 TCP/UDP端口。假如它检测到一个端口扫描行为,它就会根据对方的IP地址,阻塞这个扫描主机与你机器之间的所有连接。总之Portsentry 就是一个反扫描工具。它可以实时发现并分析记录对本机的扫描, 它主要做以下工作:
通过 syslog 做记录
将扫描的主机加入 /etc/hosts.deny
马上禁止所有通向扫描主机的网络流量
过滤掉所有来自扫描主机的网络流量
Portsentry可以从http://www.psionic.com/abacus/portsentry这个网站下载相应文件,当前portsentry的最新版本为1.0版,下载后,需要进行解压,如下:
#gzip -d portsentry-1.0.tar.gz
#tar xvf portsentry-1.0.tar
这样会生成一个名为portsentry-1.0的目录,我们进入这个目录,可以看到内有README.install等相关文件,为了顺利安装它,我们主要需要关注两个配置文件,portsentry_config.h和portsentry.conf.
"/usr/psionic/portsentry/portsentry.conf"是 portsentry 的主配置文件。您可以在这个文件中设置您所要监听的端口,以及哪些 ip 地址被拒绝,哪些被忽略等等信息。如果您了解详细的信息,可以查看 "README.install" 文件。
"/usr/psionic/portsentry/portsentry.ignore" 文件定义了在执行端口扫描分析时必须要忽略的主机,也就是说即使这些主机进行了扫描活动,portsentry 也不会采取任何行动。
Portsentry 有以下6种启动方式,如下图6所示:
portsentry -tcp (basic port-bound TCP mode)
portsentry -udp (basic port-bound UDP mode)
portsentry -stcp (Stealth TCP scan detection)
portsentry -atcp (Advanced TCP stealth scan detection)
portsentry -sudp ("Stealth" UDP scan detection)
portsentry -audp (Advanced "Stealth" UDP scan detection)
建议您可以使用下面两种方式启动 portsentry:
portsentry -atcp (Advanced TCP stealth scan detection)
portsentry -sudp ("Stealth" UDP scan detection)
然后我们在/etc/rc.d/rc.local中加入/usr/local/psionic/portsentry/portsentry –atcp就可以在每次启动时自动启动portsentry了,这样系统就可以自动对一些端口进行检测,如果发现扫描就自动就ip加入 /etc/hosts.deny中,拒绝这台ip对机器的访问。
图6:portsentry的启动模式
以上是应急响应的一些主要的步骤和流程,希望通过这些总结,给大家带来帮助。
原文链接:http://www.ccw.com.cn/server/yyjq/htm2006/20060830_206720.htm
上一页 [1] [2] [3]