|
l-wx------ 1 root root 64 Aug 10 21:03 12 -> /var/log/httpd/access_log (deleted)
...
我们可以看到,第一个文件描述符被删除了.我们要做到事就是将此文件用netcat工具传送到远程主机上.
(remote)# nc -l -p port > deleted_access_log
(compromised)# /mnt/cdrom/cat /proc/3137/fd/1 | /mnt/cdrom/nc (remote) port
这不是恢复此文件的唯一方法.我们也可以在离线分析的时候寻找未分配的节点和数据块来恢复.
2.6 关键字查找
在本文的第一部分我向你展示了一种分析进程和内存镜像的一种方法.记住,整个过程是在远程主机上完成的,并且此时内存镜像已经完成.整个方法的最大好处是我我们不用知道低级语言的使用.
我将用下面的简单的工具去寻找入侵者的信号.
●strings
●less
●grep
我将用字符串工具收集所有在镜像文件中的可打印字符.工具的默认设置使我们可以显示所有的可打印字符,这些字符至少有四个.我们用-t参数使其从文件的开始进行统计.
$ strings -t d kcore > kcore_strings
$ md5sum kcore_strings > kcore_strings.md5
在最初的分析中grep工具和规则的操作很重要.几分钟后我们就可以找到入侵者明显的痕迹.必须考虑的是我们要寻找什么类型的数据----比如是否在寻找入侵者使用过的命令,IP地址,密码或者甚至很明显的恶意代码的明文？
下面有一些要寻找的关键字的例示.我们用这些关键字在kocre_string文件中找出入侵者的明显痕迹.
● host name or prefix of the compromised system
$ grep "root@manhunt" kcore_strings
$ grep "]#" kcore_strings
11921096 [root@manhunt]#
16643784 [root@manhunt root]#
30692969 ]#]#
上面的结果是我们列举的一些字符串的偏移.下一步是用文本编辑器打开文件并跳到接近于直接偏移地址的地方.如果幸运的话我们可以找到以前使用过的命令.但是我们也必须意识到的是物理内存中虚拟内存的页面和交换分区是被无规则的写入的,所以我们的结论也许是完全不正确的.
$ less kcore_strings
/11921096
11921096 [root@manhunt]#
11921192 /usr/bin/perl
11921288 perl apache_mod_exploit.pl
...
上面的例子展示了非安全系统曾被键入的一些命令.
● 文件和目录名
$ grep -e "\/proc\/" -e "\/bin\/" -e "\/bin\/.*?sh" kcore_strings
$ grep -e "ftp" -e "root" kcore_strings
$ grep -e "rm -" kcore_strings
$ grep -e ".tgz" kcore_strings
● IP地址和域名
$ grep -e "[0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+" kcore_strings
$ grep -e "\.pl" kcore_strings
2.7 高级定性分析
在最后一节我来展示怎样分析用gdb工具来分析kcore文件的副本.开始让我描述一下怎样检测系统调用在系统调用表中的地址值是否合适.改变系统调用地址是在系统中安装了LKM工具的最简单的方法.下一个例子我将向你展示如何列举出所有在非安全性它是曾经运行过的进程.这个例子可以和第八步和第九步中所得结果进行比较.
为了分析我们必须了做到以下要求::
● 以ELF格式纪录的内存镜像
● 一个内核镜像的副本(我们必须挂载非安全系统的景象并且从/boot目录拷贝一个vmlinux文件
● 输出列表(System.map文件在/boot目录下或者我们可以利用ksyms文件---参看第七步)
● 所使用的系统的源代码
下一步是运行gdb工具:
#gdb vmlinux kcore
GNU gdb Red Hat Linux (5.1.90CVS-5)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
warning: core file may not match specified executable file.
Core was generated by `ro root=/dev/sda2 hdc=ide-scsi''''.
#0 0x00000000 in ?? ()
(gdb)
现在我们开始分析.
例1:系统调用地址核实
第一步是找出系统调用表的调用地址值.几乎所有的Linux操作系统都会将此信息输出,可以在Symbol.map中找到这些信息.
# cat Symbol.map | grep sys_call_table
c02c209c D sys_call_table
现在,我们可以列举地址调用表的所有入口地址.每个入口地址就是系统调用的地址.
为了得到正确的入口地址参数我们要察看内核源代码中的entry.s文件.这个文件记录了系统调用的顺序.
ENTRY(sys_call_table)
.long SYMBOL_NAME(sys_ni_syscall) /* 0 - old "setup()" system call*/
.long SYMBOL_NAME(sys_exit)
.long SYMBOL_NAME(sys_fork)
.long SYMBOL_NAME(sys_read)
.long SYMBOL_NAME(sys_write)
.long SYMBOL_NAME(sys_open) /* 5 */
.long SYMBOL_NAME(sys_close)
...
在sys_call_table中也有同样的顺序.下面列举十个开始的系统调用地址值:
(gdb) x/10x 0xc02c209c
0xc02c209c <sys_call_table>: 0xc01217c0 0xc011ac50 0xc0107510 0xc0138d50
0xc02c20ac <sys_call_table+16>: 0xc0138e50 0xc0138880 0xc01389b0 0xc011b010
上一页 [1] [2] [3] [4] [5] 下一页
[MySql]联机的Linux的系统分析（第一部分）（第一版）
| 
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
