سؤال التعامل مع هجمات HTTP w00tw00t


لدي خادم يحتوي على apache وقمت مؤخرًا بتثبيت mod_security2 لأنني أتعرض للهجوم كثيرًا بهذا:

إصدار اباتشي هو apache v2.2.3 وأستخدم mod_security2.c

هذه هي الإدخالات من سجل الأخطاء:

[Wed Mar 24 02:35:41 2010] [error] 
[client 88.191.109.38] client sent HTTP/1.1 request without hostname 
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:47:31 2010] [error] 
[client 202.75.211.90] client sent HTTP/1.1 request without hostname 
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:47:49 2010] [error]
[client 95.228.153.177] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:48:03 2010] [error] 
[client 88.191.109.38] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

فيما يلي الأخطاء من access_log:

202.75.211.90 - - 
[29/Mar/2010:10:43:15 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
211.155.228.169 - - 
[29/Mar/2010:11:40:41 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
211.155.228.169 - - 
[29/Mar/2010:12:37:19 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-" 

لقد حاولت تهيئة mod_security2 مثل هذا:

SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind"
SecFilterSelective REQUEST_URI "\w00tw00t\.at\.ISC\.SANS"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:\)"

الشيء في mod_security2 هو أنه لا يمكن استخدام SecFilterSelective ، فإنه يعطيني أخطاء. بدلاً من ذلك ، استخدم قاعدة مثل هذه:

SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind"
SecRule REQUEST_URI "\w00tw00t\.at\.ISC\.SANS"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:\)"

حتى هذا لا يعمل. أنا لا أعرف ما يجب القيام به بعد الآن. أي شخص لديه أي نصيحة؟

تحديث 1

أرى أنه لا أحد يستطيع حل هذه المشكلة باستخدام mod_security. حتى الآن ، يبدو أن استخدام ip-tables هو أفضل خيار للقيام بذلك ، لكنني أعتقد أن هذا الملف سيصبح كبيرًا للغاية نظرًا لأن عنوان IP يغير أوقات الخدمة كل يوم.

لقد توصلت إلى حلّين آخرين ، هل يمكن لأحدهم التعليق على كونه جيدًا أم لا.

  1. الحل الأول الذي يتبادر إلى ذهني هو استبعاد هذه الهجمات من سجلات الأخطاء في apache. هذا سيجعل من الأسهل بالنسبة لي للكشف عن الأخطاء العاجلة الأخرى عند حدوثها وليس من الضروري أن يبصق من خلال سجل طويل.

  2. الخيار الثاني هو أفضل وأعتقد ، وهذا هو منع المضيفين الذين لم يتم إرسالها بالطريقة الصحيحة. في هذا المثال ، يتم إرسال الهجوم w00tw00t بدون اسم مضيف ، لذلك أعتقد أنه يمكنني حظر المضيفات غير الموجودة في النموذج الصحيح.

تحديث 2

بعد الذهاب الإجابات من خلال جئت إلى الاستنتاجات التالية.

  1. من أجل الحصول على تسجيلات مخصصة لـ apache سوف تستهلك بعض الموارد غير الضرورية ، وإذا كانت هناك مشكلة بالفعل ، فمن المحتمل أنك تريد البحث في السجل الكامل دون أي شيء مفقود.

  2. من الأفضل تجاهل النتائج والتركيز على طريقة أفضل لتحليل سجلات الأخطاء. استخدام الفلاتر لسجلاتك نهجا جيدا لهذا.

الأفكار النهائية حول هذا الموضوع

لن يصل الهجوم المذكور أعلاه إلى جهازك إذا كان لديك على الأقل نظام حديث حتى لا يكون هناك أي قلق.

قد يكون من الصعب تصفية كافة الهجمات المزيفة من الهجمات الحقيقية بعد فترة ، لأن كل من سجلات الأخطاء وسجلات الوصول تحصل على أكبر عدد ممكن.

إن منع حدوث ذلك بأي شكل من الأشكال سيكلفك الموارد ، ومن الممارسات الجيدة عدم إهدار مواردك على أشياء غير مهمة.

الحل أنا استخدم الآن سجل لينكس. يرسل لي ملخصات للسجلات ويتم تصفيتها وتجميعها. بهذه الطريقة يمكنك بسهولة فصل المهم من غير مهم.

شكرا لكم جميعا على المساعدة ، وآمل أن تكون هذه المشاركة مفيدة لشخص آخر أيضا.


80
2018-03-24 05:33


الأصل




الأجوبة:


من سجل الأخطاء ، يرسلون طلب HTTP / 1.1 بدون المضيف: جزء من الطلب. من ما قرأته ، يرد Apache بخطأ 400 (طلب سيء) إلى هذا الطلب ، قبل تسليمه إلى mod_security. لذلك ، لا يبدو أن قواعدك ستتم معالجتها. (أباتشي تتعامل معها قبل أن تطلب تسليمها إلى الأمن)

جرب بنفسك:

telnet hostname 80
GET /blahblahblah.html HTTP / 1.1 (إدخال)
(أدخل)

يجب أن تحصل على الخطأ 400 وترى نفس الخطأ في سجلاتك. هذا طلب سيئ و apache يعطي الجواب الصحيح.

يجب أن يكون الطلب الصحيح كما يلي:

GET /blahblahblah.html HTTP / 1.1
المضيف: blah.com

قد يكون حل بديل لهذه المشكلة هو تصحيح mod_uniqueid ، لإنشاء معرف فريد حتى بالنسبة لطلب فاشل ، لكي يمرر apache الطلب إلى معالجات الطلب الخاصة به. عنوان URL التالي عبارة عن مناقشة حول هذا العمل ، ويتضمن تصحيحًا لـ mod_uniqueid يمكنك استخدامه:   http://marc.info/؟l=mod-security-users&m=123300133603876&w=2

لا يمكن العثور على أي حلول أخرى لها وتتساءل عما إذا كان هناك حاجة إلى حل في الواقع.


34
2018-03-29 13:17



أرى المشكلة الآن. هل توصي بالحل المقدم في المقالة ، أو تعتقد أنه من الأفضل تركه كما هو. وهو عبارة عن ماسح ضوئي لأية أبواب خلفية في النظام. إذا تركتها مجرد مسح ، يمكن أن أتعرض للهجوم يومًا ما. - Saif Bechan
مرحباً سيف ، أعتقد أنه طالما حافظت على تثبيت أباتشي مُحدّثًا مع تصحيحات الأمان الخاصة بالتوزيع (أو اليدوي) ، فيجب أن تكون بخير. يجب أن لا يؤدي طلب HTTP / 1.1 المنظم بشكل سيئ (كما رأيت) إلى إرجاع أي شيء بخلاف الخطأ 400 من apache. يبدو أنه قد كانت نوعًا ما من نقاط الضعف التي تركز على أجهزة توجيه DLINK. (وفقا لبعض المصادر الأخرى) - Imo
هل هناك على الأقل طريقة للحصول على هذه الحقول من بلدي apache error_log - Saif Bechan
أنت يمكن قادرة على القيام بذلك عبر mod_log :: httpd.apache.org/docs/2.2/mod/mod_log_config.html#customlog - Imo
قد يكون تلميحا إضافية: تكوين الخاص بك الافتراضي virtualhost بجوار تلك الموجودة بالفعل قيد الاستخدام. المحاولات المذكورة أعلاه سوف ينتهي في سجلات ل الافتراضي استضافة افتراضية. - Koos van den Hout


تصفية IPs ليست فكرة جيدة ، imho. لماذا لا تحاول تصفية السلسلة التي تعرفها؟

انا اعني:

iptables -I INPUT -p tcp --dport 80 -m string --to 60 --algo bm --string 'GET /w00tw00t' -j DROP

15
2018-05-09 16:21



spamcleaner.org/en/misc/w00tw00t.html حل مماثل ، ولكن قليلا أكثر تفصيلا. - Isaac
مشكلة واحدة مع تصفية سلسلة في جدار الحماية هو أنه "بطيء إلى حد ما". - Alexis Wilke
AlexisWilke هل لديك أدلة تشير إلى أن تصفية سلسلة iptables أبطأ من التصفية على مستوى اباتشي؟ - jrwren


بدأت Iv أيضًا بمشاهدة هذه الأنواع من الرسائل في ملفات السجل الخاصة بي. إحدى طرق منع هذه الأنواع من الهجمات هي الإعداد fail2ban ( http://www.fail2ban.org/ ) وإعداد مرشحات محددة للقائمة السوداء لعنوان IP هذا في قواعد iptables الخاصة بك.

هيريس مثال على مرشح من شأنه أن يحجب عنوان بروتوكول الإنترنت المقترن بصنع هذه الرسائل

[الثلاثاء أغسطس 16 02:35:23 2011] [خطأ] [العميل] الملف غير موجود: /var/www/skraps/w00tw00t.at.blackhats.romanian.anti-sec :) === apache w00t w00t messages jail - regex and filter === سجن

 [apache-wootwoot]
 enabled  = true
 filter   = apache-wootwoot
 action   = iptables[name=HTTP, port="80,443", protocol=tcp]
 logpath  = /var/log/apache2/error.log
 maxretry = 1
 bantime  = 864000
 findtime = 3600

منقي

 # Fail2Ban configuration file
 #
 # Author: Jackie Craig Sparks
 #
 # $Revision: 728 $
 #
 [Definition]
 #Woot woot messages
 failregex = ^\[\w{1,3} \w{1,3} \d{1,2} \d{1,2}:\d{1,2}:\d{1,2} \d{1,4}] \[error] \[client 195.140.144.30] File does not exist: \/.{1,20}\/(w00tw00t|wootwoot|WootWoot|WooTWooT).{1,250}
 ignoreregex =

11
2017-08-19 17:46



صحيح أنه يمكنك منعهم ، ولكن ليس هناك حاجة لأنهم مجرد طلبات سيئة. من الأفضل أن تتجاهلهم وحفظوا عملك وأنك ستفرج عن بعض المصادر. - Saif Bechan
حق @ سىيف Bechan ، إذا كان شخص ما يقلق حول أن "هجمات الاختبار" ليكون ناجحا ، فيجب عليه إصلاح التطبيق الخاص به بدلاً من ذلك في إضاعة الوقت للعثور على طريقة لمنع ذلك. - Thomas Berger
أعطاك +1 ، شكرا على الجواب. - Saif Bechan
SaifBechan ، وأنا أختلف. w00tw00t عبارة عن برنامج فحص ثغرات أمنية ، ولا يمكن الوثوق بجهاز يصدر هذه الطلبات بمحاولة أنواع أخرى من الطلبات ، لذلك إذا كنت مسؤولاً عن النظام ويأخذني دقيقتين لحظر مثل هؤلاء العملاء لأيام في كل مرة ، تفعل ذلك. أنا لا أستند في تنفيذي الأمني ​​بالكامل على هذا النهج ، مع ذلك. - Isaac


w00tw00t.at.blackhats.romanian.anti-sec هو محاولة قرصنة ويستخدم عمليات محاكاة ساخرة IP بحيث سوف VisualRoute تقرير الصين وبولندا والدنمارك وغيرها وفقا للملكية الفكرية التي أعير في ذلك الوقت. لذا ، فإن إعداد عنوان IP رفض أو اسم مضيف قابل للحل يصبح مستحيلاً تمامًا لأنه سيتغير خلال ساعة.


3
2018-06-01 11:20



لا تستخدم عمليات الفحص هذه الثغرات عناوين IP spoofed. إذا فعلوا ذلك ، فلن تكتمل عملية تأكيد اتصال TCP ثلاثي الاتجاهات ولن يقوم Apache بتسجيل الطلب. لمحاذير (مزعج ISP ، ومشغلي جهاز التوجيه ، الخ) ، انظر security.stackexchange.com/q/37481/53422 - Anthony Geoghegan


أنا شخصيا كتبت برنامج Python النصي لإضافة قواعد IPtables تلقائيًا.

إليك إصدارًا مختصرًا إلى حدٍ ما دون تسجيل الدخول وغير المرغوب فيه:

#!/usr/bin/python
from subprocess import *
import re
import shlex
import sys

def find_dscan():
        p1 = Popen(['tail', '-n', '5000', '/usr/local/apache/logs/error_log'], stdout=PIPE)
        p2 = Popen(['grep', 'w00t'], stdin=p1.stdout, stdout=PIPE)

        output = p2.communicate()[0].split('\n')

        ip_list = []

        for i in output:
                result = re.findall(r"\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b", i)
                if len(result):
                        ip_list.append(result[0])

        return set(ip_list)

for ip in find_dscan():
        input = "iptables -A INPUT -s " + ip + " -j DROP"
        output = "iptables -A OUTPUT -d " + ip + " -j DROP"
        Popen(shlex.split(input))
        Popen(shlex.split(output))

sys.exit(0)

2
2018-03-24 07:06



هل هذا لمنع هجوم w00tw00t - Saif Bechan
نعم ، لقد قمت بمسح سجلات أخطاء Apache لأي عناوين IP "w00tw00t" وإضافتها إذا لم تكن موجودة ، على الرغم من بساطة عدم إضافة التحقق من التكرارات. - Xorlev
من المحتمل أن يستخدم هذا البرنامج النصي جدولاً ، إضافة كمية كبيرة من القواعد الإضافية إلى سلاسل iptables ستؤدي إلى إبطاء المعالجة قليلاً. - Eric
انها لا تستخدم جدول. ومع ذلك أنا بسطت الكثير منه كما تم تصميمه لنظامي. - Xorlev
هل تعتقد أن هذا هو الحل الأفضل لاستخدام mod_security - Saif Bechan


أعتقد أن سبب عدم نجاح الأمان هو أن Apache لم يتمكن من تحليل الطلبات بأنفسهم ، فهي خارج نطاق المواصفات. لست متأكداً من أن لديك مشكلة هنا - اباتشي تقوم بتسجيل شذوذ غريب يحدث على الشبكة ، إذا لم تسجله فلن تكون على دراية بحدوثه حتى. الموارد المطلوبة لتسجيل الطلبات من المحتمل أن تكون ضئيلة. أدرك أنه من المحبط أن يقوم شخص ما بملء سجلاتك - ولكن سيكون من المحبط أكثر إذا قمت بتعطيل التسجيل فقط لتجد أنك تحتاج إليه بالفعل. مثل شخص ما اقتحم خادم الويب الخاص بك وكنت في حاجة إلى سجلات لإظهار كيف اندلعت في.

يتمثل أحد الحلول في إعداد ErrorLogging خلال syslog ، ثم استخدام rsyslog أو syslog-ng يمكنك تحديدًا تصفية هذه التهم RFC المتعلقة بـ w00tw00t وتجاهلها. أو يمكنك بدلاً من ذلك ترشيحهم في ملف سجل منفصل بكل بساطة حتى يسهل عليك قراءة ErrorLog الرئيسي. Rsyslog قوية بشكل لا يصدق ومرنة في هذا الصدد.

لذلك في httpd.conf قد تفعل:

ErrorLog syslog:user 

ثم في rsyslog.conf قد يكون لديك:

:msg, contains, "w00tw00t.at.ISC.SANS.DFind" /var/log/httpd/w00tw00t_attacks.log

كن على علم ، سوف يستخدم هذا النهج بالفعل عدة مرات المزيد من الموارد مما كان يستخدم في الأصل لتسجيل الدخول مباشرةً إلى ملف. إذا كان خادم الويب الخاص بك مشغولاً للغاية ، فقد يصبح هذا مشكلة.

من أفضل الممارسات أن يتم إرسال جميع السجلات إلى خادم تسجيل بعيد في أي وقت ممكن ، وهذا سوف يفيدك في حال تم اختراقه حيث أنه من الصعب للغاية محو سجل التدقيق لما تم إنجازه.

حظر IPTables هو فكرة ، ولكن قد ينتهي بك الأمر مع قائمة كتل iptables كبيرة جدا والتي يمكن أن يكون لها آثار الأداء في حد ذاته. هل هناك نمط في عناوين IP ، أم أنها تأتي من بوتيتات كبيرة موزعة؟ ستحتاج إلى X٪ من التكرارات قبل أن تحصل على فائدة من iptables.


2
2018-03-30 11:09



إجابة لطيفة ، أنا أحب المناهج المختلفة. بالتفكير في الأمر ، فإن تسجيل الدخول المخصص سيخلق مزيدًا من استخدام الملاذ ، لأنه يجب التحقق من كل شيء أولاً ، أعتقد أن هذا الخيار يقع أيضًا. لدي الآن تمكين تسجيل الدخول. هذا يرسل لي تقريرا مرتين في اليوم مع ملخصات للأنظمة بأكملها. الحصول على فحص سجلات اباتشي أيضا ويقول فقط محاولات w00tw00t 300 مرة. أعتقد أنني سأترك الإعداد كما هو في الوقت الحالي. - Saif Bechan


أنت تقول في التحديث 2:

المشكلة التي لا تزال قائمة   المشكلة التي لا تزال قائمة هي كما يلي. هذه الهجمات من البوتات التي تبحث عن ملفات معينة على الخادم الخاص بك. يبحث هذا الماسح الضوئي الخاص بالملف /w00tw00t.at.ISC.SANS.DFind :).

الآن يمكنك فقط تجاهل ذلك الذي هو الأكثر الموصى بها. تبقى المشكلة أنه إذا كان لديك هذا الملف على الخادم الخاص بك بطريقة ما يومًا ما ، فأنت في مشكلة ما.

من رداتي السابقة ، جمعنا أن Apache تقوم بإرجاع رسائل خطأ بسبب استعلام HTML 1.1 الذي تم تكوينه بشكل سيء. يجب أن تعرض جميع خوادم الويب التي تدعم HTTP / 1.1 خطأً عندما تتلقى هذه الرسالة (لم أقم بالتحقق من RFC - ربما يخبرنا RFC2616).

وجود w00tw00t.at.ISC.SANS.DFind: على الخادم الخاص بك في مكان ما لا يعني بشكل خفي "أنك في ورطة ما" ... إذا قمت بإنشاء ملف w00tw00t.at.ISC.SANS.DFind: في DocumentRoot أو حتى DefaultDocumentRoot لا يهم ... يقوم الماسح بإرسال طلب HTTP / 1.1 معطل و apache يقول "لا ، هذا طلب سيئ ... وداعا". البيانات في w00tw00t.at.ISC.SANS.DFind: لن يتم تقديم الملف.

استخدام mod_security لهذه الحالة غير مطلوب إلا إذا كنت تريد حقا (لا جدوى؟) ... وفي هذه الحالة ، يمكنك إلقاء نظرة على التصحيح يدويًا (رابط في إجابة أخرى).

شيء آخر يمكن أن ننظر به هو استخدام ميزة RBL في mod_security. ربما يكون هناك RBL على الإنترنت حيث يوفر ذلك عناوين IP w00tw00t (أو عناوين IP خبيثة أخرى معروفة). هذا يعني أن mod_security يقوم ببحث DNS لكل طلب.


1
2018-03-31 08:52



لا أظن أن أباتشي ترفضهم ، بل تكمن فقط في الخطأ ، لكن البحث لا يزال يمر. لقد حصلت على نفس w00tw00t.at.ISC.SANS.DFind في سجل الوصول. انها تفعل GET. لذلك يتم إجراء البحث ، وإذا كان لديك الملف على جهازك سيتم تنفيذه. يمكنني نشر إدخالات سجل الوصول لكنهم يشبهون سجل الأخطاء فقط مع GET أمامهم. يقوم Apache بطرح الخطأ ولكن يمرر الطلب. هذا هو السبب في أنني سألت إذا كان من المستحسن حظر هذا الطلب بدون أسماء المضيفين. لكنني لا أريد حجب المستخدمين العاديين. - Saif Bechan
بالتأكيد ، تحصل على نفس الإدخال في سجل الوصول ولكن انظر إلى رمز الخطأ ... 400. لم تتم معالجته. يتم استخدام HTTP / 1.1 (hostname) لإخبار apache أي مضيف ظاهري لإرسال الطلب إلى ... بدون جزء اسم المضيف من apache طلب HTTP / 1.1 لا يعرف مكان إرسال الطلب وإرجاع خطأ "400 طلب سيئ" العودة إلى العميل. - Imo
جرب بنفسك ... قم بإنشاء صفحة html على خادم الويب الخاص بك وحاول الوصول إليه يدويًا باستخدام "telnet hostname 80" ... أما الخطوات الأخرى فهي في أول إجابة. لقد وضعت فضل كبير على أنه لا يمكنك الحصول على ملف html للعرض باستخدام HTTP / 1.1 بدون اسم المضيف. - Imo
آه نعم نعم ذلك للإشارة إلى ذلك. اعتقدت دائما أن access_log كانت ادخالات تم تمريرها من خلال سجل الأخطاء ودخلت فعليا جهازك. نشكرك على توجيه هذا إليّ وسأعدّل مشاركتي. انا فعلا اقدر مساعدتك. - Saif Bechan
مرحبا سيف ، لا توجد مشاكل ، سعيد أن يساعد. التحيات ، ايمو - Imo


ماذا عن إضافة قاعدة إلى modsecurity؟ شيء من هذا القبيل:

   SecRule REQUEST_URI "@rx (?i)\/(php-?My-?Admin[^\/]*|mysqlmanager
   |myadmin|pma2005|pma\/scripts|w00tw00t[^\/]+)\/"
   "severity:alert,id:'0000013',deny,log,status:400,
   msg:'Unacceptable folder.',severity:'2'"

1
2017-08-09 08:23