這幾天收到AWS的通知
說我的EC2 Instance 去攻擊別人
說我在05/30中午, 05/31早上這兩天攻擊別人
除了攻擊別人的80port 也有攻擊其它的port
我查了幾個log
nginx/access.log
nginx/error.log
syslog
auth.log
因為網站上有架很多網站
然後透過nginx來做虛擬伺服器
目前有以下幾個疑點
1.wordpress
因為先前有傳出xmlrpc的漏洞攻擊
有架wordpress會被當僵屍來攻擊別人
在30號時我查了跟xmlrpc.php有關的請求
log裏只有在19號跟25號有請求過
請求數也才11個
在30號時我從wordpress的設定、function code、跟nginx去阻擋一切有關
xmlrpc請求的服務
但是在31號早上時還是收到警告，說我們還在攻擊別人
2.ssh
因為原本是使用Key pair來登入vps
port也沒改
過去在查auth.log也的確有很多的hack想要試探登入
但沒有被登入的紀錄(我也知道真的被登入也早被洗掉了= =)
在30號收到通知後
我去把port改掉
想說要是真的是駭入
又要有key pair又要猜port
應該沒這麼容易吧？
但31號...嗯
3.被我們攻擊的伺服器ip
我去cat |grep log都沒查到我們有去攻擊aws所說的ip
4.magento
在30號前幾天，我們測試用的PHP套件magento
我用後台做了線上更新
而不是用下載回來的package去覆蓋升級
另外，此套件我們的後台帳密設的還蠻簡單的(因為測試用)
5. cat xxx.log | grep ooo
我查了aws所說的攻擊時間點附近的log
都沒看到什麼異常
6.netstat -ntu | awk xxxxxxx
有下這指令看有什麼異常的傳輸
但是hack發起的時間點又不是一直持續的
所以我下這指令時，server並沒有在攻擊別人
也查不出個所以然...
7.利用Xss來做Dos?
最後有想到是不是這個可能
目前是想到wordpress跟magento
可能更新時被人植入後門
再透過這後門來做Dos攻擊別人
另外magento要是後台被登入的話
hack也可以從後台去更改html code
以上
目前就想到這些
不知道還有哪些地方需要加強防範
或是有什麼指令方法可以更明確的查到我們到底是怎麼去攻擊別人的紀錄
還麻煩請教一下

關於第2點 其實port不用猜啊 nmap掃下就知道了www建議是先確定時間點吧 把相關的記錄清查過這樣才能確定是怎麼攻擊的

通常hacker只有植入木馬那次才需要入侵系統,植好木馬你每次重開機都會幫他跑攻擊服務.若確定被入侵,從源頭重灌有時是必要的.全系統備份可能都帶有木馬.你目前的狀況是無法確認(都是別人告知),既然頻率很高,守株查兔定時檢查系統是否有不明對外站連線(最好就是被告知DOS的攻擊對象)植入木馬不一定走ssh,只要任何一個對外有開port接受連入的service有漏洞能讓遠端執行指令就是入侵的門戶,這個只能檢查你用的service有沒有vulnerability沒有更新或修正的例如:http://nginx.org/en/security_advisories.html我剛看了一下第一個vulnerability,時間很新,程度是嚴重等級,又是惡名昭彰的buffer over/underflow 來做到入侵者設計的code execution,這是很可能的入侵管道,如果你沒修這個新出沒多久的漏洞,那就趕快修一下,其它的major一定要修,後面的如果advisory裏有提到code execution的也都要修.然後每個有對外服務的service (如ssh)或plug-in(如php等)都要類似處理另外就是最近很紅的heartbleed,看看你的版本有沒有中標?從上述漏洞入侵的,log一定沒東西,log就像大門的攝影機,但小偷是挖密道進來的忘了講如果你的系統沒有隨時接收distribution的安全性更新(一般production server不會隨便更新,所以很可能沒有),更要優先考慮各項service的vulnerabilities

其實你可以問問AWS有沒有詳細點資訊就是

你有ssh,但沒開ssl？你要先確定你的ssh不是用openssl或者版本不在中槍的那些版本.ssl的後續稱為TLS,只是library延用ssl舊名自問自補:剛才查了一下ubuntu 12.04的ssh的dependency,發現它和openssl都是依賴libssl,所以看來ssh在linux的實作是直接依賴更底層的libssl,建議原po檢查你系統的ssh依賴關係heartbleed出包的是openssl而非libssl,所以在前述相依狀況下應該未影響ssh,不過若openssl是https所依賴,若版本有問題還是一定要換,因為仍然可透過heartbleed攻擊得知server的機密資料(當然可能包括你的key)另外所有web server(nginx)的plugin或extension,只要是執行動態網頁會動用到的,都必須做安全漏洞檢查(到套件官網查是否有安全漏洞,需要更新或更版)

就算用openssl ssh還是沒heartbleed問題...SSH並沒有heartbeat功能好嗎SSH只用了ssl中的加密函式而已

樓上,我不是有自問自補了嗎?另外會不會中heartbleed,主要是看相依性以及入侵管道,倒和ssh本身功能範圍不見得有關.顧名思義漏洞和後門本來就不在原設計內,單純是實作疏失所造成,不是走normal path

SSH是用22 port嗎？是的話你也太大膽了，佩服佩服。

heartbleed是因為heartbeat實作疏失導致問題SSH根本沒heartbeat這功能要從哪疏失?同樣1.0(含)以前的openssl也因為沒heartbeat這功能所以也根本完全免疫

我說了要看相依性和入侵路徑,所以目前linux以相依性看,ssh沒依賴openssl,就算有相依,還要看入侵路徑(這個要看sourcecode,不過既然沒相依就不需要看,而且不是專業者也看沒有)有相依性代表有叫用某library的部分功能,當叫用的這部分功能有漏洞,叫用者就會受影響,即使受影響也要看這漏洞是否能被外部駭客運用.這都不是一般人能分析的,最好的方法就是一但有相依性就修正或更新才是上策.另外我前面有提,ssh沒用到openssl,但https大概都會用到,所以只要有網站用https網址,就要檢查openssl版本關於 ssh,ssl,heartbleed http://ppt.cc/VkSg 這篇講得簡單明瞭,然後我更正我最面的話,ssh確實沒架在ssl之上,它們只是共用加解密功能(所以萬一漏洞出在這部分的程式,就可能受影響,不過這次的heartbleed出問題的部分,沒有被openssh叫用,至於我Ubuntu上的ssh,是連openssl都沒相依)

第7點的話,那應該是DDos, 對方看到的不會是你的server ip吧你不應該只查server ,看看你有哪些process在run 吧

看PROCESS通成可以看出一些端倪 可是那也要有經驗真的都找不出來的話 資料備份 準備重做吧...