总的来说，要判断主机是否正在或者已经遭受了攻击，需要以下几个步骤。
1、终结非授权用户。
2、找出并关闭非授权进程。
3、分析日志文件，寻找入侵者曾经试图入侵系统的蛛丝马迹。
4、检查系统文件是否有潜在受损情况。
接下来说说具体操作。
1、首先以root登录到tty下，用
root@mysun:~# w
14:14:10 up 43 days, 4:43, 1 user, load average: 0.13, 0.08, 0.04
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
lyychee pts/2 54.107.130.61.di 14:14 0.00s 0.01s 0.00s sshd: lyychee [priv] |
把所有当前登录到系统的用户列出来，可以根据各用户的用户名以及用户登录的源地址和他们正在运行的进程来判断他们是否为非法用户，
2、如果一旦发现有可疑用户，我们可以马上把它锁住
root@mysun:~# passwd -l username |
3、last命令是另外一个可以用来查找非授权用户登录事件的工具
lyychee pts/2 54.107.130.61.di Mon May 22 14:14 still logged in
lyychee pts/2 51.107.130.61.di Thu May 18 18:36 - 18:42 (00:05)
lyychee pts/2 61.130.107.51 Tue May 16 14:21 - 14:39 (00:18)
root pts/2 61.130.107.58 Sat May 13 15:40 - 15:43 (00:02)
lyychee pts/2 210.32.178.253 Fri May 12 00:53 - 01:16 (00:23)
root pts/2 58.107.130.61.di Wed May 10 15:33 - 15:35 (00:01)
root pts/2 61.130.107.58 Tue May 9 14:58 - 15:07 (00:08)
root pts/2 59.78.34.62 Sun May 7 07:40 - 07:45 (00:05)
lyychee pts/2 59.78.34.62 Sat May 6 23:50 - 00:27 (00:37)
lyychee pts/2 222.64.24.144 Sat May 6 10:56 - 10:56 (00:00)
root pts/2 192.168.0.111 Sat May 6 00:01 - 00:02 (00:01)
lyychee pts/2 222.64.22.144 Thu May 4 12:41 - 12:43 (00:0
root pts/2 59.78.34.62 Tue May 2 06:59 - 07:00 (00:00) |
last命令输入的信息来自/var/log/wtmp。这个文件详细地记录着每个系统用户的访问活动。但是有经验的入侵者往往会删掉/var/log/wtmp以清除自己非法行为的证据，但是这种清除行为还是会露出蛛丝马迹：在日志文件里留下一个没有退出操作与之对应的登录操作（因为在你删除wtmp的时候，你的登录记录就没有了，但是你待会儿登出，系统还是会把你记下来），不过再高明一点就用at或者cron等自己登出之后再删文件。（但是这种方法也还是可以查，总之linux没有一种操作是最强的，强到没有纰漏。就像古龙的小说一样，没有一个人是天下第一。这样看起来才有劲）
4、善于使用ps -aux跟netstat，这里有一个故事，曾经在一台被黑过的主机上，有人在/usr/lib里发现了一个貌似无害的文件，但在随后的调查中发现系统上有个后门，系统管理员发现主机重新启动后不久，就会有一个明为sndme的进程莫名其妙地开始运行，在执行了
root@mysun:~# netstat -ap |
之后发现了这么一条记录
udp 0 0 *:32145 *:* LISTEN 1118/sndme |
这说明一个进程正在UDP端口32145上监听什么。但是这个进程究竟是怎么起来的呢？
后来发现就是在/usr/lib里的一个文本文件搞的鬼，在系统init的时候，有一个脚本，做了一件很天才的事情，
a：首先，传见了一个名为/var/sndtmp的目录
b：再把这个文本文件复制到那，并mv成snd.Z
c：执行uncompress snd.Z
d：运行sh snd命令把解压得到的snd文件当作一个shell脚本来执行，这个脚本将提取出一个snd.c的文件
e：用gcc -o sndme snd.c对其进行编译，
f：把文件ln到/bin/sndme
g：执行之
h：再把刚刚创建，解压，编译的文件夹、文件统统都删除掉 |
sndme进程在等待一条来自32145端口的UDP消息，在接收到消息的时候，它将在系统上打开一个具备root权限的后门，狠啊。
5、/var/log/messages文件是一个系统信息源，如果在里面有连续登录失败事件的记录，往往就预示着有人在试图入侵这台主机。
我们就可以通过grep "fail"跟"repeat"这两个关键字来追踪：
root@mysun:~# grep fail /var/log/messages
root@mysun:~# grep repeat /var/log/messages |
6、检查文件系统的完好性，在redhat或者suse的系统中我们可以很方便地实现这一点
root@mysun:~# rpm -Va > /tmp/rpmVa.log |
这条命令将以一个文件的形式把安装到系统上的所有rpm包是否被改变输出成一份清单，清单中的标记含义如下：
S 文件长度发生了变化
M 文件的访问模式（包括权限和文件类型）发生了变化
5 MD5校验和发生了变化
D 设备节点的属性发生了变化
L 文件的符号链接发生了变化
U 文件/子目录/设备节点的owner发生了变化
G 文件/子目录/设备节点的group发生了变化
T 文件最后一次的修改时间发生了变化 |
比如当你看到下面这样的输出时，就应该采取行动了：
. M . . . . . . /usr/write，就说明wirte的可执行文件被篡改了，最简单的方法就是在确保其他安全工作已经补救好了的情况下重装该rpm
root@mysun:~# rpm -qf /usr/write // 找到文件所对应的rpm
root@mysun:~# rpm -Uvh --nodeps --force XXX.rpm // 强制无关联安装 |
7、另外硬件故障也不容忽视，曾经有一台主机，在用户符合没有上去的情况下性能下降了。于是就有人怀疑是遭到了外部攻击，于是就买了台防火墙，并且做了详细的入侵检测，没有发现任何不妥，最后发现是硬件出了故障。 我们可以通过
root@mysun:~# grep error /var/log/messages |
来查看关于硬件错误的记录。
