Soru HTTP w00tw00t saldırılarıyla uğraşmak


Apache'li bir sunucum var ve son zamanlarda mod_security2'yi kurdum, çünkü buna çok saldırdım:

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

Bu, hata günlüğünden gelen girdilerdi:

[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:)

İşte access_log'daki 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 yaramıyor. Artık ne yapacağımı bilmiyorum. Herhangi bir tavsiyesi olan var mı?

1. Güncelleme

Görüyorum ki bu sorunu mod_security kullanarak çözemezsin. Şimdiye kadar ip tabloları kullanarak bunu yapmak için en iyi seçenek gibi görünüyor ama bence dosya son derece büyük olacak çünkü ip günde birkaç kez değişiyor.

Diğer iki çözümle geldim, biri iyi olup olmadığına dair yorum yapabilir.

  1. Aklıma gelen ilk çözüm, bu saldırıları apache hata günlüklerimden hariç tutuyor. Bu, ortaya çıktıkça diğer acil hataları saptamam ve daha uzun bir kütüğe tükürmek zorunda kalmamamı kolaylaştırır.

  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ı hostname olmadan gönderilir, bu yüzden doğru formda olmayan hostları engelleyebileceğimi düşünüyorum.

2. Güncelleme

Cevapları inceledikten sonra aşağıdaki sonuçlara vardım.

  1. Apache için özel günlüğe kaydetme bazı gereksiz kaynakları tüketecektir ve eğer gerçekten bir problem varsa, muhtemelen eksik günlüğün tam günlüğüne bakmak isteyeceksiniz.

  2. İsabetleri 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 bahsedilen saldırı en azından güncel bir sisteminiz varsa makinenize ulaşmayacaktır, bu nedenle temelde endişe yoktur.

Bir süre sonra tüm sahte saldırıları filtrelemek zor olabilir, çünkü hem hata günlükleri hem de erişim kayıtları aşırı derecede büyüktür.

Bunun herhangi bir şekilde gerçekleşmesini engellemek, size maliyetler katacak ve kaynaklarınızı önemsiz şeylere dökmemek için iyi bir uygulamadır.

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

Yardımlarınız için hepinize teşekkür ederim. Umarım bu yazı başka birine de yardımcı olabilir.


80
2018-03-24 05:33


Menşei




Cevaplar:


Hata günlüğünüzden, istekte Host: bölümü olmadan bir HTTP / 1.1 isteği gönderiyorlar. Okuduklarımdan Apache, mod_security'ye teslim edilmeden önce bu istek için 400 (hatalı istek) hatası ile yanıt veriyor. Yani, kuralların işlenecek gibi görünmüyor. (Apache mod_security'ye teslim edilmeden önce onunla ilgileniyor)

Kendini dene:

telnet ana bilgisayar adı 80
GET /blahblahblah.html HTTP / 1.1 (giriş)
(girmek)

400 hatayı almalı ve kayıtlarınızda 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 sorunla ilgili bir çalışma, apache'nin isteklerini istek sahiplerine iletmesi için, başarısız bir istek için bile benzersiz bir kimlik oluşturmak için mod_uniqueid'in eklenmesi olabilir. Aşağıdaki URL, bu çalışma hakkında bir tartışmadır ve kullanabileceğiniz mod_uniqueid için bir yama içerir:   http://marc.info/?l=mod-security-users&m=123300133603876&w=2

Bunun için başka bir çözüm bulamadı ve bir çözümün gerçekten gerekli olup olmadığını merak etti.


34
2018-03-29 13:17



Şimdi sorunu görüyorum. Makalede sunulan çözümü önerir misiniz, yoksa sadece onu olduğu gibi bırakmanın daha iyi olduğunu düşünüyor musunuz? Sistemdeki herhangi bir arka kapı için bir tarayıcıdır. Eğer onu sadece taramadan bırakırsam, bir gün saldırıya uğrayabilirim. - Saif Bechan
Merhaba Saif, apache kurulumunuzu dağıtımlarınız (veya manuel) güvenlik yamalarınızla güncel tuttuğunuz sürece bence 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 hatadan başka bir şey döndürmemelidir. Öyle görünüyor Mayıs ayı DLink yönlendiricilerine odaklanmış bir çeşit güvenlik açığı taraması olmuştur. (Diğer bazı kaynaklara göre) - Imo
Bu alanları apache error_log'ımdan çıkarmanın en az bir yolu var mı - Saif Bechan
Sen olabilir mod_log üzerinden yapabilme :: httpd.apache.org/docs/2.2/mod/mod_log_config.html#customlog - Imo
Ek ipucum: varsayılan Aslında kullanımda olanların yanında virtualhost. Yukarıda belirtilen girişimler, varsayılan virtualhost. - Koos van den Hout


IP'leri filtrelemek iyi bir fikir değil, imho. Neden bildiğiniz dizeyi filtrelemeyi denemiyorsunuz?

Demek istediğim:

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 benzer bir çözüm, ama biraz daha detaylı. - Isaac
Güvenlik duvarında dize filtreleme ile ilgili bir sorun, "oldukça yavaş" olmasıdır. - Alexis Wilke
@AlexisWilke iptables string filtrelemesinin apache düzeyinde filtrelemeden daha yavaş olduğunu gösterecek kanıtınız var mı? - jrwren


Iv ayrıca bu tür iletileri günlük dosyamda görmeye başladı. Bu tür saldırıları önlemenin bir yolu fail2ban'ı kurmaktır ( http://www.fail2ban.org/ ) ve iptables kurallarınızda bu ip adresini kara listeye almak için belirli filtreleri ayarlayın.

Heres, bu mesajları yapmakla ilişkili ip adresini engelleyen bir filtreye örnek

[Sal Ağustos 16 02:35:23 2011] [error] [client] Dosya mevcut değil: /var/www/skraps/w00tw00t.at.blackhats.romanian.anti-sec :) === apache w00t w00t iletileri hapis - regex ve filtre === 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 =

11
2017-08-19 17:46



Onları engelleyebileceğiniz doğru, ama gerek yok çünkü onlar sadece kötü istekleri. Onları görmezden gelmek, işinizi kurtarmanız ve bazı kaynaklardan kurtulmanız daha iyidir. - Saif Bechan
Right @Saif Bechan, eğer birisi bu "test saldırılarını" başarılı olmak için endişelendiriyorsa, bunu engellemenin bir yolunu bulmak için zaman harcamak yerine kendi uygulamasını daha iyi düzeltmelidir. - Thomas Berger
Size +1 verdi, cevabınız için teşekkürler. - Saif Bechan
@ SabifBechan, katılmıyorum. w00tw00t bir güvenlik açığı tarayıcısıdır ve bu tür istekleri yayınlayan bir makine diğer tür istekleri denemekle güvenilir olamaz; bu yüzden bir sistem yöneticisi olursam ve bu tür istemcileri bir seferde günlerce yasaklamaya 2 dakika sürer öyle yap. Güvenlik uygulamamın tamamını böyle bir yaklaşıma dayandırmayacağım. - Isaac


w00tw00t.at.blackhats.romanian.anti-sn, bir hack girişimi ve sahte IP 'nin VisualRoute gibi aramalarını, o tarihte çalıştırılan IP'ye göre Çin, Polonya, Danimarka vb. Öyleyse, bir Deny IP ya da çözümlenebilir Ana Bilgisayar Adı kurmak, bir saat içinde değişeceğinden neredeyse imkansızdır.


3
2018-06-01 11:20



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


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

Günlüğe kaydetme ve diğer önemsiz bir şekilde 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)

2
2018-03-24 07:06



Bu w00tw00t saldırısını önlemek için mi - Saif Bechan
Evet, "w00tw00t" IP'leri için Apache hata kütüklerini taradım ve eğer mevcut değilse, onları eklerim, ancak basitlik için çekleri kontrol etmedim. - Xorlev
Bu betik muhtemelen bir tablo kullanmalı, iptables zincirlerine fazladan kurallar ekleyerek işlem biraz yavaşlatacaktır. - Eric
Bir tablo kullanıyor. Bununla birlikte, sistemime göre uyarlanmış bir çok şeyi basitleştirdim. - Xorlev
Bu mod_security kullanmak için daha iyi bir çözüm olduğunu düşünüyor musunuz - Saif Bechan


Mod_security'nin sizin için çalışmamasının nedeninin Apache'nin istekleri kendi başlarına çözümleyemediğine inanıyorum. Burada bir problemin olduğundan emin değilim - apache, ağda meydana gelen garip pisliği günlüğe kaydetmekte, eğer kayıt olmuyorsa, bunun gerçekleşmesinin farkında olmayacaksınız. İstekleri kaydetmek için gereken kaynaklar muhtemelen minimumdur. Birisinin günlüklerinizi doldurduğunu hayal kırıklığına uğrattığını anlıyorum - ancak gerçekten ihtiyacınız olanı bulmak için günlüğe kaydetmeyi devre dışı bırakırsanız daha da sinir bozucu olacaktır. Birisi web sunucunuza girdi ve nasıl girdiklerini göstermek için günlüklere ihtiyacınız var.

Bir çözüm, syslog üzerinden ErrorLogging'i kurmak ve daha sonra rsyslog veya syslog-ng kullanarak, w00tw00t ile ilgili olarak bu RFC ihlallerini özellikle filtreleyip atabilmenizdir. Veya alternatif olarak bunları ayrı bir günlük dosyasına filtreleyebilirsiniz, böylece ana ErrorLog'unuzun okunması kolay olur. Rsyslog bu konuda inanılmaz derecede güçlü ve esnektir.

Yani httpd.conf'ta şunları yapabilirsiniz:

ErrorLog syslog:user 

sonra rsyslog.conf içinde olabilir:

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

Dikkat edin, bu yaklaşım aslında birçok kez kullanacaktır daha fazla kaynak Orijinal olarak bir dosyaya doğrudan giriş yapmaktan daha iyidir. Web sunucunuz çok meşgulse, bu sorun olabilir.

Tüm günlükleri en kısa sürede uzak bir kayıt sunucusuna göndermenin en iyi yolu budur ve bu, ne yaptığının denetim izini silmenin çok daha zor olduğundan, bu işin içine girmeniz gerekir.

IPTable engelleme bir fikirdir, ancak kendi başına performans etkilerine sahip olabilecek çok büyük bir iptables blok listesiyle sonuçlanabilir. IP adreslerinde bir desen var mı yoksa büyük bir dağıtılmış botnet'ten mi geliyor? Iptables'den faydalanmadan önce kopyaların% X'i olmalıdır.


2
2018-03-30 11:09



Güzel cevap, farklı yaklaşımları seviyorum. Bunu düşünürsek, özel günlüğe kaydetme daha fazla rücu kullanımı yaratacaktır, çünkü her şey ilk önce kontrol edilmelidir, sanırım bu seçenek de düşüyor. Artık günlüğüm etkin. Bu bana tüm sistemlerin özetleri ile günde 2 kez bir rapor gönderir. Apache günlükleri de kontrol edilir ve sadece w00tw00t 300 kez denir diyor. Kurulumu şimdilik olduğu gibi bırakacağımı düşünüyorum. - Saif Bechan


Güncelleme 2'de diyorsunuz:

Sorun hala devam ediyor   Hala kalan problem şu şekildedir. Bu saldırılar, sunucunuzdaki belirli dosyaları arayan botlardan gelir. Bu belirli tarayıcı /w00tw00t.at.ISC.SANS.DFind :) dosyasını arar.

Şimdi en çok tavsiye edilenleri görmezden gelebilirsiniz. Sorun şu ki, bu dosyayı sunucunuzda bir şekilde bir gün varsa, bazı sorunlarınız var demektir.

Önceki cevabımızdan, Apache'nin kötü oluşturulmuş bir HTML 1.1 sorgusu nedeniyle bir hata iletisi döndürdüğünü topladık. HTTP / 1.1'i destekleyen tüm web sunucuları muhtemelen bu mesajı aldıklarında bir hata döndürmelidir (RFC'yi iki kez kontrol etmedim - belki de RFC2616 bize bildirir).

W00tw00t.at.ISC.SANS.DFind sahip olmak: sunucunuzda bazı nerede mistik olarak "bazı sorun vardır" anlamına gelmez ... Eğer w0tw00t.at.ISC.SANS.DFind: dosya DocumentRoot veya hatta oluşturmak DefaultDocumentRoot önemli değil ... 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 dosyasındaki veriler sunulmayacaktır.

Bu durum için mod_security kullanmak gerçekten (hiçbir noktaya?) İstemediğiniz sürece gerekli değildir. Bu durumda, el ile düzeltme eki olarak bakabilirsiniz (diğer cevapta bağlantı).

Kullanabileceğiniz başka bir şey de mod_security'deki RBL özelliğidir. Belki de, bazı yerlerde w00tw00t IP'leri (veya diğer bilinen zararlı IP'ler) sağlayan bir RBL çevrimiçi var. Bu, mod_security'nin her istek için bir DNS araması yaptığı anlamına gelir.


1
2018-03-31 08:52



Apache'nin onları reddettiğini sanmıyorum, sadece hatayı atıyor ama arama hala geçiyor. Erişim günlüğünde aynı w00tw00t.at.ISC.SANS.DFind var. Bir GET yapar. Böylece arama yapılır ve makinenizde dosya varsa çalıştırılır. Erişim günlüğü girişlerini gönderebilirim, ancak hata günlüğü ile aynı görünürler, önlerinde yalnızca bir GET bulunur. Apache hatayı atar ancak istek geçer. Bu yüzden, bu talebi hostname olmadan engellemek iyi bir fikir olup olmadığını sordum. Ama normal kullanıcıları engellemek istemiyorum. - Saif Bechan
Tabii ki, erişim girişinde aynı girişi elde edersiniz, ancak hata koduna bakın ... 400. İşlenmez. HTTP / 1.1 (hostname), apache'nin HTTP / 1.1 istemcisinin hostname kısmı olmadan isteği göndermek için hangi apache'ye gönderileceğini anlatmak için kullanılır. Apache, isteği nereye göndereceğini bilmez ve "400 kötü istek" hatası döndürür müşteriye geri. - Imo
Kendiniz deneyin ... web sunucunuzda kendinize bir html sayfası oluşturun ve "telnet hostname 80" kullanarak manuel olarak almayı deneyin ... diğer adımlar benim ilk cevabımda. Üzerinde html dosyasının ana makine adı olmadan HTTP / 1.1 kullanılarak görüntülenmesini sağlayamayacağınız büyük bir ödül verirdim. - Imo
Ah evet evet, bunu bana işaret ettiğin için. Ben her zaman access_log hata günlüğünden geçirilen ve aslında makinenize girilen girişler olduğunu düşündüm. Bunu bana ilettiğiniz için teşekkür ederim ve mesajımı düzenleyeceğim. Yardımın için sağol. - Saif Bechan
Selam Saif, sorun yok, yardım ettiğim için memnun oldum. Saygılar, Imo - Imo


Modsecurity'ye bir kural eklemeye ne dersiniz? Böyle 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
2017-08-09 08:23





Çözümlerin çoğunun zaten yukarıda olduğunu görüyorum ancak şunu belirtmek isterim. istemci, hostname olmadan HTTP / 1.1 isteği gönderdi saldırıları doğrudan sunucunuza hedefleniyor. Sunucudan önce gelen ağ sistemini parmak izleyip / veya sömürmek için birçok farklı girişimde bulunur, yani:

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

Linksys yönlendiricileri vb. hedeflemek. Yani bazen odaklanmanızı genişletmeye ve savunma çabalarınızı tüm sistemler arasında eşit bir payla paylaştırmaya yardımcı olur, örneğin: yönlendirici kurallarını uygulamak, güvenlik duvarı kurallarını uygulamak (umarız ağınız birdir), sunucu güvenlik duvarı / IP tablosu uygulayın kurallar ve ilgili hizmetler, yani mod_security, fail2ban vb.


1
2017-10-08 18:10