案例描述
早上接到idc的**，說我們的乙個網段ip不停的向外發包，應該是被攻擊了，具體哪個ip不知道，讓我們檢查一下。
按理分析及解決辦法
首先我們要先確定是哪台機器的網絡卡在向外發包，還好我們這邊有zabbix監控，我就一台一台的檢查，發現有一台的流量跑滿了，問題應該出現在這台機器上面。
我登入到機器裡面，檢視了一下網絡卡的流量，我的天啊，居然跑了這個多流量。
這台機器主要是執行了乙個tomcat web服務和oracle資料庫，問題不應該出現在web服務和資料庫上面，我檢查了一下web日誌，沒有發現什麼異常，檢視資料庫也都正常，也沒有什麼錯誤日誌，檢視系統日誌，也沒有看到什麼異常，我趕緊檢視了一下目前執行的程序情況，看看有沒有什麼異常的程序，一檢視，果然發現幾個異常程序，不仔細看還真看不出來，這些程序都是不正常的。
這是個什麼程序呢，我每次ps -ef都不一樣，一直在變動，程序號一一直在變動中，我想看看程序開啟了什麼檔案都行，一時無從下手，想到這裡，我突然意識到這應該都是一些子程序，由乙個主程序進行管理，所以看這些子程序是沒有用的，即便我殺掉他們還會有新的生成，擒賊先擒王，我們去找一下主程序，我用top d1實時檢視程序使用資源的情況，看看是不是有異常的程序占用cpu記憶體等資源，發現了乙個奇怪的程序，平時沒有見過。這個應該是我們尋找的木馬主程序。
我嘗試殺掉這個程序，killall -9 ueksinzina，可是殺掉之後ps -ef檢視還是有那些子程序，難道沒有殺掉？再次top d1檢視，發現有出現了乙個其他的主程序，看來殺是殺不掉的，要是那麼容易殺掉就不是木馬了。
我們看看他到底是什麼，which obgqtvdunq發現這個命令在/usr/bin下面，多次殺死之後又重新在/usr/bin目錄下面生成，想到應該有什麼程式在監聽這個程序的狀態也可能有什麼定時任務，發現程序死掉在重新執行，我就按照目前的思路檢視了一下/etc/crontab定時任務以及/etc/init.d啟動指令碼，均發現有問題。
可以看到裡面有個定時任務gcc4.sh，這個不是我們設定的，檢視一下內容更加奇怪了，這個應該是監聽程式死掉後來啟動的，我們這邊把有關的配置全部刪掉，並且刪掉/lib/libudev4.so。
在/etc/init.d/目錄下面也發現了這個檔案。
裡面的內容是開機啟動的資訊，這個我們也給刪掉。
以上兩個是乙個在開機啟動的時候啟動木馬，乙個是木馬程式死掉之後啟動木馬，但是目前我們殺掉木馬的時候木馬並沒有死掉，而是立刻更換名字切換成另乙個程式檔案執行，所以我們直接殺死是沒有任何用處的，我們目的就是要阻止新的程式檔案生成，首先我們取消程式的執行許可權並把程式檔案成成的目錄/usr/bin目錄鎖定。
chmod 000 /usr/bin/obgqtvdunq
chattr +i /usr/bin
到此為止，沒有新的木馬程序生成，原理上說是結束掉了木馬程式，後面的工作就是要清楚這些目錄產生的檔案，經過我尋找，首先清除/etc/init.d目錄下面產生的木馬啟動指令碼，然後清楚/etc/rc#.d/目錄下面的連線檔案。
後來我檢視/etc目錄下面檔案的修改時間，發現ssh目錄下面也有乙個新生成的檔案，不知道是不是有問題的。
清理差不多之後我們就要清理剛才生成的幾個檔案了，乙個乙個目錄清楚，比如」chattr -i /tmp」，然後刪除木馬檔案，以此類推刪除/bin、/usr/bin目錄下面的木馬，到此木馬清理完畢。
快速清理木馬流程
假設木馬的名字是nshbsjdy，如果top看不到，可以在/etc/init.d目錄下面檢視
1、首先鎖定三個目錄，不能讓新木馬檔案產生
chmod 000 /usr/bin/nshbsjdy
chattr +i /usr/bin
chattr +i /bin
chattr +i /tmp
刪除定時任務及檔案
rm -f /etc/init.d/nshbsjdy
rm -f /etc/rc#.d/木馬連線檔案
killall -9 nshbsjdychattr -i /usr/bin
rm -f /usr/bin/nshbsjdy
本文出自 「小小水滴」 部落格，請務必保留此出處
一次難忘的 MTS 故障的排除過程
microsoft ole db provider for sql server 錯誤 8004d00a 不能在指定的事務處理器中獲得新事務。或者microsoft ole db provider for sql server 錯誤 8004d00a 新事務不能登記到指定的事務處理器中。我檢視了一下...
記錄一次app報病毒的問題
根據指引到安全檢測平台檢測 也同樣掃瞄出異常 但因為都沒有反饋哪乙個sdk或哪乙個模組，根本無法定位問題。而且最近 1還有就是報毒時間不確定，重新打包安裝，可能不會馬上報病毒，會等一段時間才會提示病毒，等待的時間還不固定 幾個小時到1天 但也只能硬著頭皮解決，這種問題由於無法定位 無法復現，無法確定...
記錄一次sql優化過程
對於我這種剛剛進入dba行業的人來說sql優化是一件很難的事情。所以今天看了一下別人優化的過程順手記錄的一筆。select distinct vi.policy no from odsdata.policy extend info ei,policy vehicle info vi,policy b...