这几天收到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通成可以看出一些端倪 可是那也要有经验真的都找不出来的话 资料备份 准备重做吧...