網(wǎng)站建設安全DDOS攻擊與防御
另外,我們發(fā)現(xiàn)大型的企業(yè)都有遭受攻擊的案例,但是大家遭受攻擊之后的應對措施及學到的經(jīng)驗卻分享都比較少,這導致各家都是自行的摸索經(jīng)驗,依然停留在一家企業(yè)對抗整個互聯(lián)網(wǎng)的攻擊的局面,而對于攻擊者卻是此次攻擊針對你,下次攻擊卻是針對他了,而且攻擊之后無論是技術還是資源都沒有任何的損耗,這也是導致這種攻擊頻繁并且肆無忌憚的原因。
我們來嘗試做一些改變:)
常見ddos攻擊及防御
繼續(xù)秉承80sec的”Know it then hack it”,這里簡單談一下ddos攻擊和防御方面的問題。ddos的全稱是分布式拒絕服務攻擊,既然是拒絕服務一定是因為某些原因而停止服務的,其中最重要的也是最常用的原因就是利用服務端方面資源的有限性,這種服務端的資源范圍很廣,可以簡單的梳理一個請求正常完成的過程:
1 用戶在客戶端瀏覽器輸入請求的地址
2 瀏覽器解析該請求,包括分析其中的dns以明確需要到達的遠程服務器地址
3 明確地址后瀏覽器和服務器的服務嘗試建立連接,嘗試建立連接的數(shù)據(jù)包通過本地網(wǎng)絡,中間路由最終艱苦到達目標網(wǎng)絡再到達目標服務器
4 網(wǎng)絡連接建立完成之后瀏覽器根據(jù)請求建立不同的數(shù)據(jù)包并且將數(shù)據(jù)包發(fā)送到服務器某個端口
5 端口映射到進程,進程接受到數(shù)據(jù)包之后進行內(nèi)部的解析
6 請求服務器內(nèi)部的各種不同的資源,包括后端的API以及一些數(shù)據(jù)庫或者文件等
7 在邏輯處理完成之后數(shù)據(jù)包按照之前建立的通道返回到用戶瀏覽器,瀏覽器完成解析,請求完成。
上面各個點都可以被用來進行ddos攻擊,包括:
1 某些著名的客戶端劫持病毒,還記得訪問百度跳搜狗的事情么?:)
2 某個大型互聯(lián)網(wǎng)公司發(fā)生的dns劫持事件,或者直接大量的dns請求直接攻擊dns服務器,這里可以使用一些專業(yè)的第三方dns服務來緩解這個問題,如Dnspod
3 利用建立網(wǎng)絡連接需要的網(wǎng)絡資源攻擊服務器帶寬使得正常數(shù)據(jù)包無法到達如udp的洪水攻擊,消耗前端設備的cpu資源以使得數(shù)據(jù)包不能有效轉(zhuǎn)發(fā)如icmp和一些碎片包的洪水攻擊,消耗服務器方建立正常連接需要的資源如syn flood或者就是占用大量的連接使得正常的連接無法發(fā)起,譬如這次的TCP flood
4 利用webserver的一些特點進行攻擊,相比nginx來說,apache處理一個請求的過程就比較笨重。
5 利用應用程序內(nèi)部的一些特性攻擊程序內(nèi)部的資源如mysql,后端消耗資源大的接口等等,這也就是傳統(tǒng)意義上的CC攻擊。
這里涉及到攻防的概念,但是實際上如果了解對方的攻擊點和攻擊手法,防御會變成簡單的一個拼資源的過程,不要用你最弱的地方去抗人家最強的地方,應該從最合適的地方入手把問題解決掉,譬如在路由器等設備上解決應用層攻擊就不是一個好的辦法,同理,在應用層嘗試解決網(wǎng)絡層的問題也是不可能的,簡單來說,目標是只讓正常的數(shù)據(jù)和請求進入到我們的服務,一個完善的防御體系應該考慮如下幾個層面:
1 作為用戶請求的入口,必須有良好的dns防御
2 與你的價值相匹配的帶寬資源,并且在核心節(jié)點上布置好應用層的防御策略,只允許你的正常應用的網(wǎng)絡數(shù)據(jù)包能夠進入,譬如封殺除了80以外的所有數(shù)據(jù)包
3 有支持你的服務價值的機器集群來抵抗應用層的壓力,有必要的話需要將一個http請求繼續(xù)分解,將連接建立的過程壓力分解到其他的集群里,這里似乎已經(jīng)有一般的硬件防火墻能做這個事情,甚至將正常的http請求解析過程都進行分解,保證到達后端的是正常的請求,剔除掉畸形的請求,將正常的請求的請求頻度等行為進行記錄和監(jiān)控,一旦發(fā)生異常就在這里進行應用層的封殺
每個公司都有自己對自己價值的評估從而決定安全投入上的大小,每一次攻擊也會涉及到利益的存在,正如防御因為種種原因譬如投入上的不足和實施過程中的不完美,有著天生的弱點一樣,攻擊也是有著天生的弱點的,因為每一次攻擊涉及到不同的環(huán)節(jié),每個環(huán)節(jié)都可能由不同水平的人完成,他所擁有的資源,他使用的工具和技術都不會是完美的,所以才有可能進行防御,另外,我相信進行DDOS攻擊的人是一個固定的行業(yè),會有一些固定的人群,對于其中使用的技術,工具,資源和利益鏈都是比較固定的,與之相對的是各個企業(yè)卻缺乏相應的溝通,以個人企業(yè)對抗一個產(chǎn)業(yè)自然是比較困難,而如果每一個企業(yè)都能將自己遭受攻擊時的經(jīng)驗分享出來,包括僵尸網(wǎng)絡的大小及IP分布,攻擊工具的特征,甚至有能力的可以去分析背后的利益點及操作者,那么每一次攻擊都能讓大家的整體防御能力上升,讓攻擊者的攻擊能力有損失,我們很愿意來做這個事情。
應急響應
在攻擊發(fā)生后,第一個現(xiàn)象是我們的網(wǎng)站上不去了,但是依然可以訪問到管理界面,我們登陸上去簡單執(zhí)行了命令:
netstat -antp
我們看到有大量的鏈接存在著,并且都是ESTABLISHED狀態(tài),正常狀態(tài)下我們的網(wǎng)站訪問量沒有這么高,如果有這么高我們相信中國的信息安全就有希望了,對于這樣的情況其實處理就比較簡單,這是一次四層的攻擊,也就是所有ip都是真實的,由于目前為止只是消耗了webserver的網(wǎng)絡連接資源,所以我們只需要簡單的將這些ip在網(wǎng)絡層封禁就可以,很簡單,用下面的命令即可:
for i in `netstat -an | grep -i ‘:80 ‘|grep ‘EST’ | awk ‘{print $5}’ | cut -d : -f 1 | sort | uniq -c | awk ‘{if($1 > 50) {print $2}}’`
echo $i
echo $i >> /tmp/banip
/sbin/iptables -A INPUT -p tcp -j DROP -s $i
done
然后作為計劃任務一分鐘執(zhí)行一次即可,很快,iptables的封禁列表就充斥了大量的封禁ip,我們簡單的統(tǒng)計了下連接數(shù)最大的一些ip發(fā)現(xiàn)都來自韓國。為了保證系統(tǒng)的性能,我們調(diào)大了系統(tǒng)的可接受的連接數(shù)以及對Nginx進行了每個連接能夠進行的請求速率,系統(tǒng)于是恢復了正常的運行。
正常狀態(tài)一直持續(xù)到第二天,但是到中午之后我們發(fā)現(xiàn)訪問又出現(xiàn)了問題,網(wǎng)絡很慢,使用ping發(fā)現(xiàn)大概出現(xiàn)了70%左右的丟包,在艱難的登陸到系統(tǒng)上之后,發(fā)現(xiàn)系統(tǒng)已經(jīng)很少有TCP的正常連接,為了查明原因,我們對系統(tǒng)進行了抓包:
tcpdump -w tmp.pcap port not 22
tcpdump -r tmp.pcap -nnA
我們發(fā)現(xiàn)攻擊已經(jīng)從應用層的攻擊調(diào)整到了網(wǎng)絡層的攻擊,大量的目標端口是80的udp和icmp包以極快的速度充滿了網(wǎng)絡,一個包大小大概在1k左右,這次占據(jù)的資源純粹是帶寬資源了,即使在系統(tǒng)上做限制也解決不了這個問題,不過也沒有關系,對于網(wǎng)絡層的問題我們可以在網(wǎng)絡層上做限制,我們只需要在網(wǎng)絡上把到達我們ip的非TCP的所有包如UDP和ICMP等協(xié)議都禁止掉即可,但是我們沒有自己的服務器也缺乏對網(wǎng)絡設備的控制權(quán),目前是由工信部CERT提供支持的,由于臨時無法協(xié)調(diào)進行相應的操作,后果如大家看到,我們的服務很慢,基本上停止了服務,在一段時間之后攻擊者停止了攻擊,服務才進行了恢復,很憋屈是么?但是同時我們得到了很多熱心朋友的幫助,得到了更好的網(wǎng)絡和服務器資源,在網(wǎng)絡資源方面的能力得到了很大的提升,緩解了這方面的問題,這里對他們表示感謝。
根源及反擊
我困惑的是一點,攻擊我們并不能得到實際的好處為什么還是有人來攻擊,而且聽說其他公司都有被攻擊的情況,我覺得有一點原因就是攻擊我們的確得不到什么好處,但是實際上攻擊者也并不損失什么,無論是資源上還是法律風險上,他不會因為一次攻擊而損失太多,而相比之下,服務提供者損失的東西卻太多了,這從經(jīng)濟學角度來講就是不平衡的,我們處于弱勢。
一般而言,的確對于作惡者是沒有什么懲罰措施,但是這次,我們覺得我們是可以做一些事情的,我們嘗試挖掘背后的攻擊者,甚至清除這個僵尸網(wǎng)絡。
首先這次攻擊起源于應用層的攻擊,所以所有的ip都是真實的,經(jīng)過與CERT溝通,也發(fā)現(xiàn)這些ip都是韓國的,并且控制端不在國內(nèi),因為期間沒有與國內(nèi)有過通訊,即使在后面換成了udp+icmp的flood,但是依然是那些韓國的ip,這很有意思,正常情況下udp+icmp的數(shù)據(jù)包是可以偽造的,但是這里居然沒有偽造,這在后面大概被我們證實了原因。
這些ip是真實存在的ip,而且這些ip肯定在攻擊完我們之后一定依然跟攻擊者保持著聯(lián)系,而一般的聯(lián)系方式因為需要控制的方便都是dns域名,既然如此,如果我們能挖掘到這個dns域名我們就可能間接的挖掘出真正幕后黑手在哪里。首先,我們迅速的找出了這次攻擊ip中開放了80端口的機器,因為我們對80端口上的安全問題比較自信,應該很快可以獲知這些ip背后的細節(jié)(80sec名稱由來),我們發(fā)現(xiàn)大部分是一些路由器和一些web的vpn設備,我們猜測這次攻擊的主要是韓國的個人用戶,而個人用戶的機器操作系統(tǒng)一般是windows所以在較高版本上發(fā)送數(shù)據(jù)包方面可能有著比較大的限制,這也解釋了為什么即使是udp+icmp的攻擊我們看到的大都是真實ip。發(fā)現(xiàn)這些路由設備之后我們嘗試深入得更多,很快用一些弱口令譬如admin/admin登陸進去,果然全世界的網(wǎng)民都一樣,admin/admin是天生的入口。
登陸進去一些路由之后我們發(fā)現(xiàn)這些路由器里面存在一個功能是設置自己的dns,這意味著這下面的所有dns請求都可以被定向到我們自己設置的dns服務器,這對于我們?nèi)チ私鈨?nèi)部網(wǎng)絡的細節(jié)會很有用,于是我們建立了一個自己的dns服務器,并且開啟了dns請求的日志功能以記錄所有請求的細節(jié)。我們大約控制了20臺路由器的dns指向,并且都成功重定向到我們自己的服務器。
剩下的就是簡單的數(shù)據(jù)分析,在這值錢我們可以對僵尸網(wǎng)絡的控制域名做如下的猜測:
1 這個dns應該為了靈活的控制域名的緩存時間TTL一般不會特別長
2 這個dns應該是定期的被請求,所以會在dns請求里有較大的出現(xiàn)比例
3 這個dns應該是為了控制而存在的,所以域名不應該在搜索引擎以及其他地方獲得較高的訪問指數(shù),這與2中的規(guī)則配合起來會比較好確定,是一個天生的矛盾。
4 這個dns應該在各個路由下面都會被請求
這些通過簡單的統(tǒng)計就很容易得出答案,我們發(fā)現(xiàn)了一些3322的通用惡意軟件域名但是發(fā)現(xiàn)它并不是我們需要的,因為只有少數(shù)機器去訪問到,經(jīng)過一些時間之后最后我們發(fā)現(xiàn)一個域名訪問量與naver(韓國的一個門戶)的訪問量持平,workgroup001.snow****.net,看起來似乎對自己的僵尸網(wǎng)絡管理很好嘛,大概有18臺機器訪問過這個域名,這個域名的主機托管在新加坡,生存時間TTL在1800也就是半小時,這個域名在所有的搜索引擎中都不存在記錄,是一個韓國人在godady一年前才注冊的,同時我們訪問這個域名指向主機的3389,簡單的通過5下shift就判斷出它上面存在著一個典型的windows后門,似乎我們找到它了,不是么?經(jīng)過后續(xù)的觀察,一段時間后這個域名指向到了127.0.0.1,我們確信了我們的答案,workgroup001.snow****.net,看起來似乎對自己的僵尸網(wǎng)絡管理很好嘛:)
這是一次典型的ddos攻擊,攻擊之后我們獲得了參與攻擊的主機列表和控制端的域名及ip,相信中國和韓國的cert對于清理這次的攻擊源很有興趣,我們是有一些損失,但是攻擊者也有損失了(大概包括一個僵尸網(wǎng)絡及一個控制端域名,甚至可能包括一次內(nèi)部的法律調(diào)查),我們不再是不平等的了,不是么?
北京網(wǎng)站制作公司總結(jié):正如一個朋友所講的,所有的防御是不完美的正如攻擊是不完美的一樣,好的防御者在提升自己的防御能力趨于完美的同時也要善于尋找攻擊者的不完美,尋找一次攻擊中的漏洞,不要對攻擊心生恐懼,對于Ddos攻擊而言,發(fā)起一次攻擊一樣是存在漏洞的,如果我們都能夠擅長利用其中的漏洞并且抓住后面的攻擊者那么相信以后的ddos攻擊案例將會減少很多,在針對目標發(fā)起攻擊之前攻擊者也會做更多的權(quán)衡,損失,利益和法律。
本文發(fā)布于北京網(wǎng)站建設公司尚品中國http://xjjufeng.cn/
建站流程
-
網(wǎng)站需求
-
網(wǎng)站策劃方案
-
頁面設計風格
-
確認交付使用
-
資料錄入優(yōu)化
-
程序設計開發(fā)
-
后續(xù)跟蹤服務
-
聯(lián)系電話
010-60259772
熱門標簽
- 網(wǎng)站建設
- 食品網(wǎng)站建設
- 微信小程序開發(fā)
- 小程序開發(fā)
- 無錫網(wǎng)站建設
- 研究所網(wǎng)站建設
- 沈陽網(wǎng)站建設
- 廊坊網(wǎng)站建設
- 鄭州網(wǎng)站建設
- 婚紗攝影網(wǎng)站建設
- 手機端網(wǎng)站建設
- 高校網(wǎng)站制作
- 天津網(wǎng)站建設
- 教育網(wǎng)站建設
- 品牌網(wǎng)站建設
- 政府網(wǎng)站建設
- 北京網(wǎng)站建設
- 網(wǎng)站設計
- 網(wǎng)站制作
最新文章
推薦新聞
更多行業(yè)-
網(wǎng)絡營銷市場細分的意義和作用
20世紀50年代,美國著名的市場營銷學家溫德爾·史密斯提...
2014-06-13 -
網(wǎng)站的制作流程
一、策劃一個網(wǎng)站的建設首先必然是策劃,由策劃人員決定這個網(wǎng)站的主旨及欄...
2015-03-19 -
SEO網(wǎng)站優(yōu)化之拿什么拯救你我的關鍵詞排名
SEO網(wǎng)站優(yōu)化之拿什么拯救你我的關鍵詞排名網(wǎng)站上線后由于權(quán)重不夠?qū)е玛P...
2012-01-03 -
DIV+CSS網(wǎng)頁布局及網(wǎng)站設計常犯錯誤
1、不恰當?shù)厥褂脠D片 為了網(wǎng)站制作美觀,經(jīng)常會到處貼滿圖片,這樣做是...
2012-07-17 -
優(yōu)酷起訴土豆不正當競爭索賠480萬 法院已受理
TechWeb2月3日消息,優(yōu)酷起訴土豆不正當競爭一案日前已經(jīng)得到海淀...
2012-02-03 -
生物醫(yī)藥網(wǎng)站建設要考慮什么?如何進行建設?
在生物醫(yī)藥網(wǎng)站建設的時候,不管是什么樣的企業(yè),基本上對于這方面的網(wǎng)站建...
2022-10-19
預約專業(yè)咨詢顧問溝通!
免責聲明
非常感謝您訪問我們的網(wǎng)站。在您使用本網(wǎng)站之前,請您仔細閱讀本聲明的所有條款。
1、本站部分內(nèi)容來源自網(wǎng)絡,涉及到的部分文章和圖片版權(quán)屬于原作者,本站轉(zhuǎn)載僅供大家學習和交流,切勿用于任何商業(yè)活動。
2、本站不承擔用戶因使用這些資源對自己和他人造成任何形式的損失或傷害。
3、本聲明未涉及的問題參見國家有關法律法規(guī),當本聲明與國家法律法規(guī)沖突時,以國家法律法規(guī)為準。
4、如果侵害了您的合法權(quán)益,請您及時與我們,我們會在第一時間刪除相關內(nèi)容!
聯(lián)系方式:010-60259772
電子郵件:394588593@qq.com