總的來說，要判斷主機是否正在或者已經遭受了攻擊，需要以下幾個步驟。
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 |
來查看關于硬件錯誤的記錄。
