डबरो हबब्रहा पर हमला: पोस्टमार्टम

26 जुलाई को, पास ने हमारे साथ अप्रिय समाचार दिया: हबर पर फिर से हमला किया जा रहा है। स्वाभाविक रूप से, हमने हमें स्विच करने की सलाह दी।

जब डीएनएस को अपडेट किया जा रहा था, हमने युद्ध के मैदान का प्रारंभिक ब्लैकबॉक्स मूल्यांकन किया:

ximaera@endeavour:14#487:~$ nc habrahabr.ru 80 <<EOF
> GET / HTTP/1.1
> Host: habrahabr.ru
>
> EOF
^C

real 0m19.020s
user 0m0.000s
sys 0m0.024s
ximaera@endeavour:14#488:~$ ping habrahabr.ru
64 bytes from ***: icmp_req=1 ttl=54 time=53.5 ms
64 bytes from ***: icmp_req=2 ttl=54 time=53.1 ms
64 bytes from ***: icmp_req=3 ttl=54 time=53.1 ms
^C
--- *** ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 53.126/53.300/53.598/0.340 ms
ximaera@endeavour:14#489:~$

तो, सर्वर एक स्वीकार्य समय के लिए जिम्मेदार है, लेकिन कनेक्शन स्थापित नहीं है। जाहिरा तौर पर, हमला टीसीपी प्रोटोकॉल या एप्लिकेशन लेयर पर जाता है। हाल ही में 50-गीगाबिट हमले के बाद, हमें मुश्किल ग्राहकों के लिए संगरोध मिला, लेकिन इस मामले में हमने इसका उपयोग नहीं करने का फैसला किया - शायद यातायात की एक छोटी राशि है।

शाम के साढ़े सात बजे, DNS स्विच किया गया।



यह ग्राफिक एक लोमड़ी को दिखाता है। कार्यशील वेब संसाधन के मामले में, आउटगोइंग ट्रैफ़िक की मात्रा परिमाण के एक क्रम से आने वाले ट्रैफ़िक की मात्रा से अधिक हो जाती है। यदि वे कई प्रतिशत प्रतिशत से भिन्न होते हैं - मुसीबत।

आखिरी बार हैबर लंबे समय तक हमारी सुरक्षा, हम्म, के अधीन रहा। वैध उपयोगकर्ता व्यवहार का व्यावहारिक रूप से कोई संचित इतिहास नहीं है, आपको मैन्युअल रूप से फ़िल्टर नियंत्रित करना होगा। सबसे पहले, हम टीसीपी कनेक्शन ऑटोमोटन के एक मोटे विश्लेषण को शामिल करते हैं।



यह पता चला है कि वे कनेक्शन और अनुरोधों की उच्च दर के साथ हमला कर रहे हैं जो समयबद्ध हैं। कनेक्शन ट्रैकिंग, निश्चित रूप से, नरक में उड़ान भरी, डेटाबेस भी खराब था। बोट्स बड़ी संख्या में अवरुद्ध हैं।



हैबरसेवर मृत की तुलना में अधिक जीवित होने लगता है। लेकिन कचरा अनुरोध हैं, यह दिखाई दे रहा है।



परीक्षण और मामले के दौरान, एक महत्वपूर्ण द्रव्यमान क्लासिफायरियर में जमा हो गया है। संक्रमण विश्लेषण चलाएं। "रेड ज़ोन" में तुरंत आईपी पते का एक बादल उड़ता है जो इन अनुरोधों को पूरा करते हैं:

178.120.56.144 - - [26/Jul/2011:20:00:59 +0400] "GET /search/?q=intel HTTP/1.0" 200 14443 "http://www.live.com/" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 5.0)" [habrahabr.ru]
85.173.219.240 - - [26/Jul/2011:20:00:59 +0400] "GET /search/?q=intel HTTP/1.0" 200 14443 "http://www.alexa.com/" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 6.0)" [habrahabr.ru]
178.94.52.22 - - [26/Jul/2011:20:00:59 +0400] "GET /search/?q=intel HTTP/1.0" 200 14443 "http://www.google.com/" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 6.1)" [habrahabr.ru]
46.36.130.136 - - [26/Jul/2011:20:00:59 +0400] "GET /search/?q=intel HTTP/1.0" 200 14443 "http://www.live.com/" "Opera/7.51 (Windows NT 5.2; U) [en]" [habrahabr.ru]
46.7.52.14 - - [26/Jul/2011:20:00:59 +0400] "GET /search/?q=intel HTTP/1.0" 200 14443 "http://www.live.com/" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 5.2)" [habrahabr.ru]

क्वेरी हमेशा समान होती है: GET / खोज? Q = Intel। संदर्भ अलग हैं: Google, Ask.com और अन्य खोज इंजन। इन अवैध अनुरोधों के लेखकों ब्लॉक किए गए हैं।

चिंता न करें: भले ही उस समय आप Google से हैबर के खोज पृष्ठ पर "इंटेल" क्वेरी के साथ आए थे, यह संभावना नहीं है कि आपको तुरंत प्रतिबंधित कर दिया गया था। उपयोगकर्ता की वैधता की गणना कई प्रश्नों पर आधारित है।



कृपया ध्यान दें: जैसे ही नकली ट्रैफ़िक को फ़िल्टर किया गया, वैध उपयोगकर्ताओं द्वारा उत्पन्न ट्रैफ़िक तुरंत थोड़ा बढ़ गया (यदि केवल साइट काम कर रही थी) और आउटगोइंग ट्रैफ़िक तुरंत जाग गया। खरोंच से सुरक्षा को सक्षम करने के एक घंटे के भीतर, साइट पूरी तरह से चालू स्थिति में आ गई।

हम HTTP QRATOR 503 surviveled!



इस बिंदु पर, हमला मूल रूप से बंद हो गया। इसका मतलब यह नहीं है कि जो साइट इसके विपरीत काम करती है, उस पर किसी भी तरह के ट्रैफ़िक को रखना बेहतर है, किसी और पर पैसा बनाना बेहतर है।

हमले की शक्ति का अनुमान लगाएं। निम्नलिखित हानिकारक घटक उपलब्ध हैं:
- कनेक्शन की संख्या;
- डेटाबेस में प्रश्नों की संख्या।

तदनुसार, आने वाले ट्रैफ़िक की मात्रा या आईपी पते पर हमला करने की संख्या का मूल्यांकन करने के लिए व्यर्थ है, मुख्य बात प्रति यूनिट समय खुले कनेक्शन की संख्या है। हमले के चरम पर, लगभग 9000 अनुरोध / एस किए गए थे, जो वास्तव में हमले की शक्ति है। प्रत्येक अनुरोध एक अलग टीसीपी-सिलसिले में किया जाता है। ध्यान दें कि डिफ़ॉल्ट लिनक्स मान CONNTRACK_MAX (यह मानते हुए कि सर्वर में 1 जीबी से अधिक रैम है) इस प्रकार हमले से 7.29 के बाद समाप्त हो जाएगा; आधार पर भार अधिक।

मुसीबत, जैसा कि आप जानते हैं, अकेले नहीं आती है, किसी भी मामले में, इस क्षेत्र में नहीं। 0:20 पर, हमलावर फिर से आए, और बॉटनेट की मात्रा 19:30 से थोड़ी बड़ी थी। लेकिन हम इसके लिए पहले से ही तैयार थे और हमला अपने आप बंद हो गया। किसी हमले से बचना एक बहुत ही सामान्य बात है, कभी-कभी आयोजक विशेष रूप से साइट के व्यवहार की निगरानी करते हैं और जैसे ही इसके प्रतिभागी "जाने देना" शुरू करते हैं, बॉटनेट को सक्रिय कर देते हैं। यहां यह आसान था, फिर से हमला बंद हो गया, जैसे पहले, तुरंत, जैसे ही सभी बॉट अवरुद्ध हो गए।

EDIT 14:52 वास्तव में न्यूनतम नुकसान के साथ, हमले की तीसरी लहर समाप्त हो गई है। लगभग 4,500 अटैकिंग बॉट्स, 4,000 अनुरोध चरम पर हैं। संक्रमित मशीनें अब न केवल इंटेल, बल्कि ऐप्पल और Google में भी रुचि रखती हैं। हम घटनाक्रम पर नजर रखते हैं।