HTTP w00tw00t saldırılarıyla ilgilenmek


82

Apache'li bir sunucum var ve son zamanlarda mod_security2'yi kurdum çünkü bu konuda çok fazla saldırıya uğradım:

Apache sürümüm apache v2.2.3 ve mod_security2.c kullanıyorum

Bu hata günlüğündeki girişlerdi:

[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 dosyasındaki hatalar:

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'yi şu şekilde yapılandırmayı denedim:

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'deki şey SecFilterSelective'in kullanılamaması, bana hatalar vermesidir. Bunun yerine böyle bir kural kullanıyorum:

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:\)"

Bu bile işe yaramaz. Artık ne yapacağımı bilemiyorum. Bir tavsiyesi olan var mı?

Güncelleme 1

Bu sorunu kimsenin mod_security kullanarak çözemediğini görüyorum. Şimdiye kadar ip-tabloları kullanmak, bunu yapmak için en iyi seçenek gibi gözüküyor, ancak dosyanın günlük kullanımda sıkça değiştiği için dosyanın çok büyük olacağını düşünüyorum.

2 çözüm daha buldum, birileri iyi olup olmadıklarına dair yorum yapabilir.

  1. Aklıma gelen ilk çözüm, bu saldırıları apache hata kayıtlarımın dışında bırakmak. Bu, diğer acil hataları ortaya çıktıkça fark etmem için kolaylaştıracak ve uzun bir günlüğe tükürmek zorunda kalmayacak.

  2. İkinci seçenek daha iyi olduğunu düşünüyorum ve bu doğru şekilde gönderilmeyen ana bilgisayarları engelliyor. Bu örnekte w00tw00t saldırısı ana bilgisayar adı olmadan gönderilir, bu nedenle doğru biçimde olmayan ana bilgisayarları engelleyebileceğimi düşünüyorum.

Güncelleme 2

Cevaplardan geçtikten sonra aşağıdaki sonuçlara vardım.

  1. Apache için özel bir günlük kaydı yapmak, bazı gereksiz kaynakları tüketir ve gerçekten bir sorun varsa, muhtemelen herhangi bir eksiklik olmadan tam kütüğe bakmak isteyebilirsiniz.

  2. Sadece isabetleri görmezden gelmek ve hata günlüklerinizi analiz etmenin daha iyi bir yoluna odaklanmak daha iyidir. Günlükleriniz için filtreler kullanmak bunun için iyi bir yaklaşım.

Konuyla ilgili son düşünceler

Yukarıda belirtilen saldırı, en azından güncel bir sisteminiz varsa makinenize ulaşamayacağından temelde endişelenmeyin.

Bir süre sonra gerçek olanlardan gelen tüm sahte saldırıları filtrelemek zor olabilir, çünkü hem hata günlükleri hem de erişim günlükleri çok büyük olur.

Bunun bir şekilde olmasını engellemek size kaynaklara mal olacak ve kaynaklarınızı önemsiz şeylere harcamamak iyi bir uygulamadır.

Şimdi kullandığım çözüm Linux logwatch . Bana günlüklerin özetlerini gönderir ve filtrelenir ve gruplandırılır. Bu sayede önemli olanı önemsizden kolayca ayırabilirsiniz.

Yardımlarınız için hepinize teşekkür ederim ve umarım bu yazı başkalarına da yardımcı olabilir.

Yanıtlar:


34

Hata günlüğünüzden, Host: isteğin bir kısmı olmadan bir HTTP / 1.1 isteği gönderiyorlar. Okuduklarımdan itibaren, Apache mod_security'e geçmeden önce bu talebe 400 (hatalı istek) hatasıyla cevap veriyor. Yani, kurallarınız işlenecek gibi görünmüyor. (Apache, mod_security'e teslim etmeden önce uğraşıyor)

Kendin dene:

telnet ana bilgisayar adı 80
/ Glahblahblah.html HTTP / 1.1 al (gir)
(giriş)

400 hatasını almalı ve günlüklerinizde aynı hatayı görmelisiniz. Bu kötü bir istek ve apache doğru cevabı veriyor.

Uygun istek şöyle görünmelidir:

GET /blahblahblah.html HTTP / 1.1
Ev sahibi: blah.com

Bu soruna geçici bir çözüm, ap_d'nin isteği işleyenlere iletmesi için mod_uniqueid'in yamalanması, başarısız bir istek için bile benzersiz bir kimlik oluşturmak olabilir. Aşağıdaki URL, bu çalışma hakkında bir tartışmadır ve kullanabileceğiniz mod_uniqueid için bir düzeltme eki içerir: http://marc.info/?l=mod-security-users&m=123300133603876&w=2

Bunun için başka bir çözüm bulunamadı ve gerçekten bir çözüm gerekip gerekmediğini merak ediyorum.


Şimdi problemi görüyorum. Makalede sunulan çözümü önerir misiniz, yoksa olduğu gibi bırakmanın daha iyi olduğunu mu düşünüyorsunuz? Sistemdeki arka kapılar için bir tarayıcıdır. Sadece taramayı bırakırsam, bir gün saldırıya uğrayabilirim.
Saif Bechan,

1
Merhaba Saif, apache kurulumunu dağıtım (veya manuel) güvenlik yamalarınızla güncel tuttuğunuz sürece iyi olmalısınız. Kötü yapılandırılmış bir HTTP / 1.1 isteği (gördüğünüz gibi) apache'den 400 hata dışında bir şey döndürmemelidir. O gibi görünüyor olabilir DLink yönlendiriciler de duruldu açığı taraması çeşit olmuştur. (Diğer bazı kaynaklara göre)
Imo

En azından bu alanları apache hatamdan çıkarmanın bir yolu var mı?
Saif Bechan

Sen belki mod_log :: yoluyla bunu yapmak mümkün httpd.apache.org/docs/2.2/mod/mod_log_config.html#customlog
Imo

Ek ipucum şuydu : varsayılan sanal sunucunuzu gerçekte kullanımda olanların yanında yapılandırın . Yukarıda belirtilen girişimler varsayılan sanal ana bilgisayar günlüklerinde sona erecek .
Koos van den Hout,

16

IP'leri filtrelemek iyi bir fikir değil, yani. Bildiğiniz ipi neden filtrelemeyi denemiyorsunuz?

Demek istediğim:

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

spamcleaner.org/en/misc/w00tw00t.html benzer bir çözüm, ancak biraz daha ayrıntılı.
Isaac,

Güvenlik duvarında dize filtreleme ile ilgili bir sorun "oldukça yavaş" olmasıdır.
Alexis Wilke

@AlexisWilke iptables string filtrelemenin apache seviyesinden filtrelemekten daha yavaş olduğunu öneren kanıtınız var mı?
jrwren

@jrwren Aslında, aramayı durdurmak için paket ofsetini geçemezseniz, yani burada "--to 60" gibi oldukça yavaş olabilir. Varsayılan olarak, tüm paket boyunca arama yapacaktır, maksimum sınır 65.535 bayt olarak ayarlanmıştır, maksimum IP paket uzunluğu: blog.nintechnet.com/… El kitabı " Geçilmezse , varsayılan paket boyutu" ifadesini açıkça gösterir.
10'da,

Bu teorik bir max. İnternet üzerinden daha gerçekçi bir maksimum uzunluk ~ 1500.
jrwren

11

Iv ayrıca günlük dosyalarımda bu tür mesajları görmeye başladı. Bu tür saldırıları önlemenin bir yolu fail2ban'ı ( http://www.fail2ban.org/ ) ayarlamak ve iptables kurallarınızda bu ip adresini kara listeye almak için özel filtreler ayarlamaktır.

Heres bu mesajları yapmakla ilişkili ip adresini engelleyebilecek bir filtre örneği

[Sal Ağustos 16 02:35:23 2011] [hata] [müşteri] Dosya mevcut değil: /var/www/skraps/w00tw00t.at.blackhats.romanian.anti-sec :) === apache w00t w00t mesajları - regex ve filter === Hapis

 [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

filtre

 # 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 =

2
Onları engelleyebildiğiniz doğrudur, ancak buna gerek yoktur çünkü bunlar sadece kötü isteklerdir. Onları görmezden gelmek daha iyi, işinizi kurtardı ve bazı kaynaklardan kurtulacaksınız.
Saif Bechan

Right @ Saif Bechan, birisi bu "test saldırıları" konusunda başarılı olmaktan endişeleniyorsa, bunu engellemenin bir yolunu bulmak için zaman kaybetmek yerine kendi başvurusunu daha iyi düzeltmelidir.
Thomas Berger

Verdin +1, cevap için teşekkürler.
Saif Bechan

4
@ SaifBechan, katılmıyorum. w00tw00t bir güvenlik açığı tarayıcısıdır ve bu tür istekleri bildiren bir makine diğer istekleri denemekle güvenilir olamaz, bu yüzden bir sistem yöneticisiysem ve bu tür müşterileri bir kerede yasaklamak 2 dakika sürerse, yapardım. Yine de tüm güvenlik uygulamamı böyle bir yaklaşıma dayandırmam.
Isaac

3

w00tw00t.at.blackhats.romanian.anti-sec bir bilgisayar korsanlığı girişimidir ve sahte IP'leri kullanır, bu nedenle VisualRoute gibi aramalar Çin, Polonya, Danimarka vb. Dolayısıyla, bir Reddet IP veya çözülebilir bir Ana Bilgisayar Adı ayarlamak, bir saat içinde değişeceğinden hemen hemen imkansızdır.


Bu güvenlik açığı taramaları, sahte IP adresleri kullanmaz. Bunu yaparlarsa, TCP 3 yollu el sıkışma tamamlanmayacak ve Apache isteği kaydetmeyecekti. Uyarılar için (hileli ISS, yönlendirici operatörleri, vb.) Bkz. Security.stackexchange.com/q/37481/53422
Anthony Geoghegan

2

Kişisel olarak IPtables kurallarını otomatik olarak eklemek için bir Python betiği yazdım.

İşte kayıt ve diğer önemsiz olmadan biraz kısaltılmış bir sürümü:

#!/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)

Bu w00tw00t saldırısını önlemek için mi
Saif Bechan

Evet, herhangi bir "w00tw00t" IP'si için Apache hata günlüklerini taramasını sağladım ve basit olmadıkça bunları ekleyin, ancak basitlik için kopyaları kontrol etmedim.
Xorlev

Bu betik muhtemelen bir tablo kullanmalı, iptables zincirlerine tonlarca ilave kural ekleyerek işlemeyi biraz yavaşlatıyor.
Eric

Bir masa kullanıyor. Ancak, sistemime uyarlandığı için çoğunu basitleştirdim.
Xorlev

Bunun mod_security'i kullanmak için daha iyi bir çözüm olduğunu düşünüyor musunuz
Saif Bechan 28:10

2

Mod_security'in sizin için çalışmamasının sebebinin Apache'nin talepleri kendileri ayrıştıramadığına, spesifik dışı olduklarına inanıyorum. Burada bir problemin olduğundan emin değilim - apache ağda olan garip şeyleri kaydediyor, eğer giriş yapmazsa, onun bile olduğunu farketmeyeceksin. İstekleri günlüğe kaydetmek için gereken kaynaklar muhtemelen minimumdur. Birinin günlüklerinizi doldurması sinir bozucu olduğunu anlıyorum - ancak yalnızca gerçekten ihtiyacınız olduğunu bulmak için günlük kaydını devre dışı bırakmanız daha sinir bozucu olacaktır. Birisi web sunucunuza girmiş ve nasıl girdiklerini göstermek için günlüklere ihtiyacınız var.

Bir çözüm, ErrorLogging'i syslog aracılığıyla ayarlamak ve ardından rsyslog veya sysloging kullanarak w00tw00t ile ilgili bu RFC ihlallerini özel olarak filtreleyebilir ve atabilirsiniz. Veya alternatif olarak, onları ana ErrorLog'unuzun okuması kolay olacak şekilde ayrı bir günlük dosyasına filtreleyebilirsiniz. Rysyslog bu açıdan inanılmaz derecede güçlü ve esnektir.

Yani httpd.conf içinde şunları yapabilirsiniz:

ErrorLog syslog:user 

o zaman rsyslog.conf dosyasında şunlar olabilir:

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

Unutmayın, bu yaklaşım aslında başlangıçta doğrudan bir dosyaya giriş yapmaktan çok daha fazla kaynak kullanacaktır . Web sunucunuz çok meşgulse, bu bir sorun olabilir.

Tüm günlüklerin bir uzak kayıt sunucusuna mümkün olan en kısa sürede gönderilmesini sağlamak en iyisidir ve bu, yaptığınız denetim izini silmek çok daha zor olduğu için size zarar vermeniz durumunda size fayda sağlayacaktır.

IPTables engelleme bir fikirdir, ancak kendi içinde performans etkileri olabilecek çok büyük bir iptables blok listesi ile sonuçlanabilir. IP adreslerinde bir kalıp var mı, yoksa geniş bir dağıtılmış botnet'ten mi geliyor? İptables'dan faydalanabilmeniz için önce kopyaların% X'inin olması gerekir.


Güzel cevap, farklı yaklaşımları seviyorum. Bunun hakkında düşünmek, özel kayıtlara sahip olmak daha fazla kullanım yaratacaktır, çünkü önce her şey kontrol edilmeli, sanırım bu seçenek de düşüyor. Artık logwatch etkin durumda. Bu bana tüm sistemlerin özetlerini içeren günde 2 kez bir rapor gönderir. Apache günlükleri de kontrol edilir ve sadece w00tw00t'nin 300 kez denediğini söyler. Kurulumu şu an olduğu gibi bırakacağımı düşünüyorum.
Saif Bechan

1

Güncelleme 2’de diyorsunuz:

Hala kalan sorun Hala kalan sorun aşağıdaki gibidir. Bu saldırılar, sunucunuzdaki belirli dosyaları arayan botlardan geliyor. Bu özel tarayıcı /w00tw00t.at.ISC.SANS.DFind :) dosyasını arar.

Şimdi, en çok önerilen olanı görmezden gelebilirsiniz. Sorun şu ki, eğer bir gün sunucunuzda bu dosya varsa, bir gün başınız belada demektir.

Önceki cevabımdan, Apache'nin zayıf bir şekilde oluşturulmuş HTML 1.1 sorgusu nedeniyle bir hata mesajı döndürdüğünü belirledik. HTTP / 1.1'i destekleyen tüm web sunucuları bu mesajı aldıklarında büyük olasılıkla bir hata döndürmelidir (RFC'yi iki kez kontrol etmedim - belki de RFC2616 bize söyler).

Sahip olmak w00tw00t.at.ISC.SANS.DFind: Sunucunuzda bazılarının mistik olarak "bazı sıkıntılarda bulunduğunu" kastetmediği anlamına gelir ... DefaultDocumentRoot farketmez ... tarayıcı bozuk bir HTTP / 1.1 isteği gönderiyor ve apache "hayır, bu kötü bir istek ... güle güle" diyor. W00tw00t.at.ISC.SANS.DFind: içindeki veriler dosyaya verilmeyecek.

Bu durumda mod_security kullanmak, gerçekten istemediğiniz sürece (anlamı yoktur?) ... bu durumda, el ile düzeltme ekine bakabilirsiniz (diğer cevaba bağlantı).

Muhtemelen kullanabileceğiniz bir başka şey mod_security'deki RBL özelliğidir. Belki de W00Tw00t IP'leri (veya bilinen diğer kötü amaçlı IP'leri) sağlayan çevrimiçi bir RBL vardır. Ancak bu, mod_security'nin her istek için bir DNS araması yaptığı anlamına gelir.


Apache'nin onları reddettiğini sanmıyorum, sadece hatayı fırlatıyor ama arama hala geçiyor. Erişim günlüğünde aynı w00tw00t.at.ISC.SANS.DFind bulduk. Bir GET yapar. Böylece arama yapılır ve eğer makinenizde bir dosya varsa, yürütülür. Erişim günlüğü girişlerini kaydedebilirim, ancak hata günlüğü ile yalnızca önlerinde bir GET ile aynı görünüyorlar. Apache hatayı atar ancak istek geçer. Bu nedenle, bu isteği ana bilgisayar adları olmadan engellemenin iyi bir fikir olup olmadığını sordum. Ancak normal kullanıcıları engellemek istemiyorum.
Saif Bechan

1
Tabii ki, erişim günlüğüne aynı girişi aldınız ancak hata koduna bakın ... 400. İşlenmedi. HTTP / 1.1 (ana bilgisayar adı) apache'ye, isteğin gönderileceği sanal ana makineye ... HTTP / 1.1 istek apache'sinin ana bilgisayar adı olmadan, isteğin nereye gönderileceğini bilmediğini ve "400 kötü istek" hatası döndürdüğünü bildirmek için kullanılır. müşteriye geri dön.
Imo

Kendiniz deneyin ... web sunucunuzda kendinize bir html sayfası oluşturun ve "telnet hostname 80" i kullanarak el ile almaya çalışın ... diğer adımlar ilk cevabımda. Ana bilgisayar adı olmadan HTTP / 1.1 kullanarak gösterilecek html dosyasını alamadığınıza büyük bir ödül alırdım.
Imo

Ah evet evet bunu bana gösterdiğin için. Access_log dosyasının her zaman hata günlüğünden geçen ve aslında makinenize girilen girdiler olduğunu düşündüm. Bunu bana gösterdiğin için teşekkür ederim, ben de yazımı düzenleyeceğim. Yardımın için sağol.
Saif Bechan

Selam Saif, sorun yok, yardımcı olduğum için mutluyum. Saygılarımızla, Imo
Imo

1

Modsecurity için bir kural eklemeye ne dersiniz? Bunun gibi bir şey:

   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

Çözümlerin çoğunun yukarıda ele alındığını görüyorum, ancak ana bilgisayar adı saldırıları olmadan HTTP / 1.1 isteği gönderen tüm istemcilerin doğrudan sunucunuza yönelik olmadığını belirtmek isterim . Sunucunuzdan önceki ağ sisteminden parmak izi almak ve / veya istifade etmek için birçok girişimde bulunulmaktadır;

client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /tmUnblock.cgi

Linksys yönlendiricilerini vb. hedeflemek. Bazen, odak noktanızı genişletmeye ve savunma çabalarınızı tüm sistemler arasında eşit bir payla bölmeye yardımcı olur; kurallar ve ilgili servisler yani mod_security, fail2ban vb.


1

buna ne dersin ?

iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.DFind' -j DROP
iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.DFind' -j LOG --log-level 4 --log-prefix Hacktool.DFind:DROP:

benim için iyi çalışıyor.


OWASP_CRS / 2.2.5 veya mod_security için ayarlanan rende kuralını tavsiye ettim
Urbach-Webhosting

Bu gerçekten iyi bir fikir değil. Sonunda asılı bağlantılarla son bulacaksın. Artı, sitenizin bu talepler hakkında herhangi bir tartışması varsa, yanlış pozitiflerle sonuçlanabilirsiniz.
kasperd

0

Eğer kullanırsanız hiawathaweb sunucusu olarak bir reverse proxybu taramalar otomatik çöp & olarak bırakılır clientyasaklandı. Aynı zamanda filtreler XSSve CSRFistismarlar.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.