HTTP w00tw00t saldırılarıyla ilgilenmek

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.

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.

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

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 =

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.

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)

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ü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.

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'"

Çö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.

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.

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.