डीडीओएस हमले के तहत सर्वर - आईपी कैसे पता करें?


20

मेरा सर्वर डीडीओएस हमलों के तहत है और मैं आईपी को अवरुद्ध करना चाहता हूं जो यह कर रहा है, मुझे हमलावर के आईपी को निर्धारित करने के लिए कौन से लॉग की तलाश करनी चाहिए?


2
यह कैसे है कि आपने निर्धारित किया है कि सर्वर पर हमला हो रहा है? यह मुझे लगता है कि इस निर्धारण को करने के लिए आपको कुछ प्रकार की टीसीपी सत्र तालिका (विंडोज पर नेटस्टैट) देखने की आवश्यकता होगी और ऐसा करने पर मेजबानों के आईपी पते आपके सर्वर से जुड़ेंगे, जिससे आपका प्रश्न बन जाएगा। विवादास्पद।
जोवेवर्टी

जवाबों:


43
tail -n 10000 yourweblog.log|cut -f 1 -d ' '|sort|uniq -c|sort -nr|more

शीर्ष IP पते पर एक नज़र डालें। यदि कोई दूसरों से बाहर खड़ा है, तो वे फ़ायरवॉल वाले होंगे।

netstat -n|grep :80|cut -c 45-|cut -f 1 -d ':'|sort|uniq -c|sort -nr|more

यह वर्तमान में सक्रिय कनेक्शनों को देखने के लिए यह देखने के लिए कि क्या कोई आईपी 80 पोर्ट से जुड़ रहे हैं। आपको कट -c 45 को बदलने की आवश्यकता हो सकती है - क्योंकि आईपी पता कॉलम 45 पर शुरू नहीं हो सकता है। यदि कोई यूडीपी बाढ़ कर रहा था आपका वेबसर्वर, यह इसे भी उठाएगा।

इस मौके पर कि न तो इनमें से कोई भी आईपी आदर्श से बहुत अधिक है, आपको यह मानने की आवश्यकता होगी कि आपके पास एक बोटनेट है जो आप पर हमला कर रहा है और लॉग में विशेष पैटर्न देखने की जरूरत है कि वे क्या कर रहे हैं। WordPress साइटों के खिलाफ एक आम हमला है:

GET /index.php? HTTP/1.0

यदि आप अपनी वेबसाइट के एक्सेस लॉग के माध्यम से देखते हैं, तो आप कुछ ऐसा करने में सक्षम हो सकते हैं:

cut -f 2 -d '"' yourweblog.log|cut -f 2 -d ' '|sort|uniq -c|sort -nr|more

जो आपको सबसे अधिक हिट URL दिखाएगा। आप पा सकते हैं कि वे पूरी साइट को लोड करने के बजाय एक विशेष स्क्रिप्ट को मार रहे हैं।

cut -f 4 -d '"' yourweblog.log|sort|uniq -c|sort -nr|more

आप आम UserAgents देखने के लिए अनुमति देगा। यह संभव है कि वे अपने हमले में एक एकल UserAgent का उपयोग कर रहे हों।

चाल को आक्रमण ट्रैफ़िक के साथ सामान्य रूप से कुछ खोजना है जो आपके सामान्य ट्रैफ़िक में मौजूद नहीं है और फिर फ़िल्टर करें जो आपके वेबहोस्ट के साथ iptables, mod_rewrite या अपस्ट्रीम के माध्यम से होता है। यदि आप स्लोवरिस से प्रभावित हो रहे हैं, तो Apache 2.2.15 में अब reqtimeout मॉड्यूल है जो आपको Slowloris के खिलाफ बेहतर सुरक्षा के लिए कुछ सेटिंग्स कॉन्फ़िगर करने की अनुमति देता है।


बहुत बहुत धन्यवाद, मैं निश्चित रूप से इस सप्ताहांत में देखूंगा।
वेबनेट

अति उत्कृष्ट। बहुत उपयोगी और बहुत अच्छा .... इसे बनाए रखें और भगवान आपका भला करे। Allinonescript.com ( allinonescript.com ) ऑल ओवर वर्ल्ड के डेवलपर्स नॉलेज ज्ञान प्राप्त करते हैं।
वादिवेल एस

जब तक आप अपने एक्सेस_लॉग को सही तरीके से सेट करते हैं: टेल-एन 10000 / var / log / httpd / access_ | cut -f 1 -d '' | सॉर्ट | uniq -c | sort -nr | more यह काम करना चाहिए। मेरे लिए काम किया,
डस्टबस्टर

7

FYI करें - आपको यह देखने के लिए अपने ISP के साथ काम करने की कोशिश करनी चाहिए कि क्या वे इसे आपके ऊपर से रोक सकते हैं।


4

कुछ अच्छे टिप्स यहाँ। मैं इसे भी जोड़ूंगा:

netstat -an | grep ESTABLISHED | awk '\''{print $5}'\'' | awk -F: '\''{print $1}'\'' | sort | uniq -c | awk '\''{ printf("%s\t%s\t",$2,$1); for (i = 0; i < $1; i++) {printf("*")}; print ""}'\''

इसे एक उपनाम (nn, उदाहरण के लिए) के तहत रखें। यह आपको अधिक स्थापित कनेक्शन के साथ ips का "चित्रमय" परिप्रेक्ष्य देगा।

उम्मीद है की यह मदद करेगा।

जिन लोगों को यह काम नहीं मिल सका उनके लिए मैंने सिंटैक्स तय किया है इसलिए यह मेरे लिए उबंटू के तहत चलता है:

netstat -an|grep ESTABLISHED|awk '{print $5}'|awk -F: '{print $1}'|sort|uniq -c|awk '{ printf("%s\t%s\t",$2,$1); for (i = 0; i < $1; i++) {printf("*")}; print ""}'

3

डॉस के हमलों की जाँच करने के लिए मेरी पसंदीदा लॉग फाइलें / var / log / Secure (Redhat / Centos / Fedora .... के तहत) और /var/log/auth.log (ubuntu, debian ... के तहत) हैं। आप हमलावर के स्रोत आईपी से किए गए असफल लॉगिन प्रयास देखेंगे, अधिकांश समय शब्दकोश आधारित हमले।


1

अपने सर्वर की सुरक्षा के लिए मैं Fail2Ban को एक साधारण स्क्रिप्ट का उपयोग करता हूं

लॉग फ़ाइल जैसे / var / log / pwdfail या / var / log / apache / error_log और bans IP को स्कैन करता है जो बहुत अधिक पासवर्ड फेलियर करता है। यह IP पते को अस्वीकार करने के लिए फ़ायरवॉल नियम अपडेट करता है।

http://www.fail2ban.org/wiki/index.php/Main_Page


0

कौन सा डिस्ट्रो?

मुझे लगता है कि उबंटू के साथ लॉग / अंडर / क्लॉक/apache2/access.log है ... संभवतः डेबियन भी।

अद्यतन को sudo के रूप में चलाएँ फिर कमांड लाइन से access.log का पता लगाएं।

संपादित करें: मेरा मानना ​​है कि यह केवल तब होगा जब वे आपको या तो पृष्ठों का अनुरोध करके या सीधे पोर्ट 80 के माध्यम से मार रहे हों। यदि वे अन्य बंदरगाहों से टकरा रहे हैं तो आपको वह जानकारी नहीं दिखाई देगी जिसकी आपको आवश्यकता है, आपको यह देखने और देखने की आवश्यकता है कि कौन सी प्रक्रिया है उस बंदरगाह पर चल रहा है और उस प्रक्रिया के लिए कनेक्शन लॉग पर एक नज़र है।


0

यदि आप किसी विशेष पोर्ट पर संदेह करते हैं तो आप यह देखने के लिए कि यह $ tcpdump -vv पोर्ट X है, का उपयोग कर सकते हैं


0

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


2
वेब हमलों के लिए आईपी बनाना बहुत मुश्किल है। चूंकि वैध वेब कनेक्शन के लिए एक syn / ack handshake की आवश्यकता होती है, इसलिए आपको पर्याप्त भाग्यशाली होना होगा कि जाली पतों के लिए जाली पतों के साथ आपके पेलोड के लिए सही अनुक्रम संख्या के साथ काम करने के लिए जाली एड्रेस हो। यूडीपी / आईसीएमपी यातायात कनेक्शन रहित है और जाली पैकेटों की अनुमति देता है, लेकिन, अधिकांश होस्ट उन पैकेटों को अवरुद्ध कर देते हैं।
user6738237482

0

पहले आपको डॉस का प्रकार निर्धारित करना होगा। कुछ हमले बहुत चोरी-छिपे लेकिन प्रभावी (धीमे) होते हैं, उनमें से कुछ इतने भारी होते हैं कि एक आईएसपी को नीचे ला सकते हैं (आपके आईएसपी स्रोत की तुलना में अधिक बैंडविड्थ से आईसीएम बाढ़)।

जब आप डॉस का प्रकार निर्धारित करते हैं, तो अपने आईएसपी को कॉल करें और उनसे पूछें कि क्या वे ट्रैफ़िक को फ़िल्टर कर सकते हैं।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.