Berurusan dengan serangan HTTP w00tw00t

Saya memiliki server dengan apache dan saya baru saja menginstal mod_security2 karena saya sering diserang oleh ini:

Versi apache saya adalah apache v2.2.3 dan saya menggunakan mod_security2.c

Ini adalah entri dari log kesalahan:

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

Berikut adalah kesalahan dari 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 "-" "-" 

Saya mencoba mengkonfigurasi mod_security2 seperti ini:

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

Masalahnya di mod_security2 adalah bahwa SecFilterSelective tidak dapat digunakan, itu memberi saya kesalahan. Sebagai gantinya saya menggunakan aturan seperti ini:

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

Bahkan ini tidak berhasil. Saya tidak tahu harus berbuat apa lagi. Adakah yang punya saran?

Perbarui 1

Saya melihat bahwa tidak ada yang bisa menyelesaikan masalah ini menggunakan mod_security. Sejauh ini menggunakan ip-tables sepertinya pilihan terbaik untuk melakukan ini, tetapi saya pikir file akan menjadi sangat besar karena perubahan ip serveral kali sehari.

Saya datang dengan 2 solusi lain, dapatkah seseorang mengomentari mereka tentang menjadi baik atau tidak.

1. Solusi pertama yang muncul di pikiran saya adalah mengecualikan serangan ini dari log kesalahan apache saya. Ini akan membuat saya lebih mudah untuk menemukan kesalahan mendesak lainnya saat terjadi dan tidak perlu meludah melalui log yang panjang.

2. Pilihan kedua lebih baik menurut saya, dan itu adalah memblokir host yang tidak dikirim dengan cara yang benar. Dalam contoh ini, serangan w00tw00t dikirim tanpa nama host, jadi saya pikir saya dapat memblokir host yang tidak dalam bentuk yang benar.

Perbarui 2

Setelah menjawab, saya sampai pada kesimpulan berikut.

1. Agar log kustom untuk apache akan menggunakan beberapa sumber daya yang tidak perlu, dan jika memang ada masalah, Anda mungkin ingin melihat log lengkap tanpa ada yang hilang.

2. Lebih baik mengabaikan klik dan berkonsentrasi pada cara yang lebih baik untuk menganalisis log kesalahan Anda. Menggunakan filter untuk log Anda pendekatan yang bagus untuk ini.

Pikiran akhir tentang subjek

Serangan yang disebutkan di atas tidak akan mencapai mesin Anda jika Anda setidaknya memiliki sistem yang terbaru sehingga pada dasarnya tidak ada kekhawatiran.

Mungkin sulit untuk menyaring semua serangan palsu dari yang asli setelah beberapa saat, karena log kesalahan dan log akses menjadi sangat besar.

Mencegah hal ini terjadi dengan cara apa pun akan membebani Anda sumber daya dan merupakan praktik yang baik untuk tidak menyia-nyiakan sumber daya Anda pada hal-hal yang tidak penting.

Solusi yang saya gunakan sekarang adalah Linux logwatch . Ini mengirimkan saya ringkasan log dan mereka disaring dan dikelompokkan. Dengan cara ini Anda dapat dengan mudah memisahkan yang penting dari yang tidak penting.

Terima kasih semua atas bantuannya, dan saya harap posting ini dapat membantu orang lain juga.

Dari log kesalahan Anda, mereka mengirim permintaan HTTP / 1.1 tanpa bagian Host: dari permintaan. Dari apa yang saya baca, Apache membalas dengan kesalahan 400 (permintaan buruk) untuk permintaan ini, sebelum diserahkan ke mod_security. Jadi, sepertinya aturan Anda tidak akan diproses. (Apache menghadapinya sebelum harus menyerahkan mod_security)

Coba sendiri:

telnet hostname 80
GET /blahblahblah.html HTTP / 1.1 (masukkan)
(memasukkan)

Anda harus mendapatkan kesalahan 400 dan melihat kesalahan yang sama di log Anda. Ini permintaan yang buruk dan apache memberikan jawaban yang benar.

Permintaan yang tepat akan terlihat seperti:

GET /blahblahblah.html HTTP / 1.1
Tuan rumah: blah.com

Sebuah solusi untuk masalah ini bisa berupa patch mod_uniqueid, untuk menghasilkan ID unik bahkan untuk permintaan yang gagal, agar apache meneruskan permintaan ke penangan permintaannya. URL berikut adalah diskusi tentang pekerjaan ini, dan termasuk tambalan untuk mod_uniqueid yang dapat Anda gunakan: http://marc.info/?l=mod-security-users&m=123300133603876&w=2

Tidak dapat menemukan solusi lain untuk itu dan bertanya-tanya apakah solusi sebenarnya diperlukan.

Memfilter IP bukan ide yang bagus, imho. Mengapa tidak mencoba memfilter string yang Anda tahu?

Maksudku:

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

Saya juga mulai melihat jenis pesan ini di file log saya. Salah satu cara untuk mencegah jenis serangan ini adalah dengan mensetup fail2ban ( http://www.fail2ban.org/ ) dan mengatur filter khusus untuk membuat daftar hitam alamat ip ini dalam aturan iptables Anda.

Inilah contoh filter yang akan memblokir alamat ip yang terkait dengan pembuatan pesan-pesan itu

[Sel 16 Agustus 02:35:23 2011] [kesalahan] [klien] File tidak ada: /var/www/skraps/w00tw00t.at.blackhats.romanian.anti-sec :) === apache w00t w00t messages jail - regex dan filter === Penjara

 [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

Saring

 # 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 adalah upaya peretasan dan menggunakan spoof IP sehingga pencarian seperti VisualRoute akan melaporkan China, Polandia, Denmark dll menurut IP yang diperbantukan pada waktu itu. Jadi pengaturan IP Tolak atau Nama Host yang dapat diatasi hampir tidak mungkin karena akan berubah dalam satu jam.

Saya pribadi menulis skrip Python untuk menambahkan aturan IPtables secara otomatis.

Berikut versi yang sedikit disingkat tanpa masuk dan sampah lainnya:

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

Saya percaya alasan mod_security tidak bekerja untuk Anda adalah karena Apache belum dapat menguraikan permintaan sendiri, mereka di luar spesifikasi. Saya tidak yakin Anda memiliki masalah di sini - apache sedang mencatat hal-hal aneh yang terjadi di internet, jika tidak mencatatnya, Anda tidak akan menyadari bahwa ini terjadi. Sumber daya yang diperlukan untuk mencatat permintaan mungkin minimal. Saya mengerti ini membuat frustasi bahwa seseorang mengisi log Anda - tetapi akan lebih membuat frustasi jika Anda menonaktifkan logging hanya untuk menemukan Anda benar-benar membutuhkannya. Seperti seseorang membobol server web Anda dan Anda perlu log untuk menunjukkan bagaimana mereka membobolnya.

Salah satu solusinya adalah mengatur ErrorLogging melalui syslog, dan kemudian menggunakan rsyslog atau syslog-ng Anda bisa secara khusus menyaring dan membuang pelanggaran RFC ini tentang w00tw00t. Atau Anda juga bisa memfilternya menjadi file log terpisah sehingga ErrorLog utama Anda mudah dibaca. Rsyslog sangat kuat dan fleksibel dalam hal ini.

Jadi di httpd.conf Anda mungkin melakukannya:

ErrorLog syslog:user 

kemudian di rsyslog.conf Anda mungkin memiliki:

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

Ketahuilah, pendekatan ini sebenarnya akan menggunakan sumber daya berkali-kali lebih banyak daripada yang sebelumnya digunakan untuk masuk langsung ke file. Jika server web Anda sangat sibuk, ini bisa menjadi masalah.

Praktik terbaiknya adalah mengirimkan semua log ke server logging jarak jauh sesegera mungkin dan ini akan bermanfaat jika Anda pernah membobolnya karena jauh lebih sulit untuk menghapus jejak audit dari apa yang telah dilakukan.

Pemblokiran IPTables adalah sebuah ide, tetapi Anda mungkin berakhir dengan daftar blok iptables yang sangat besar yang dapat memiliki implikasi kinerja dalam dirinya sendiri. Apakah ada pola dalam alamat IP, atau apakah itu berasal dari botnet besar yang didistribusikan? Diperlukan X% duplikat sebelum Anda mendapatkan manfaat dari iptables.

Anda mengatakan di Pembaruan 2:

Masalah yang masih tersisa Masalah yang masih tersisa adalah sebagai berikut. Serangan ini berasal dari bot yang mencari file tertentu di server Anda. Pemindai khusus ini mencari file /w00tw00t.at.ISC.SANS.DFind :).

Sekarang Anda bisa mengabaikannya mana yang paling direkomendasikan. Masalahnya tetap bahwa jika Anda memiliki file ini di server Anda entah bagaimana suatu hari, Anda dalam masalah.

Dari balasan saya sebelumnya, kami mengetahui bahwa Apache mengembalikan pesan kesalahan karena kueri HTML 1.1 yang dibentuk dengan buruk. Semua webservers yang mendukung HTTP / 1.1 mungkin harus mengembalikan kesalahan ketika mereka menerima pesan ini (saya belum mengecek RFC - mungkin RFC2616 memberitahu kami).

Memiliki w00tw00t.at.ISC.SANS.DFind: di server Anda di mana tidak berarti "Anda berada dalam masalah" ... Jika Anda membuat w00tw00t.at.ISC.SANS.DFind: cari file di DocumentRoot Anda atau bahkan DefaultDocumentRoot tidak masalah ... pemindai mengirim permintaan HTTP / 1.1 yang rusak dan apache mengatakan "tidak, itu permintaan yang buruk ... selamat tinggal". Data di w00tw00t.at.ISC.SANS.DFind: file tidak akan dilayani.

Menggunakan mod_security untuk kasus ini tidak diperlukan kecuali Anda benar-benar ingin (tidak ada gunanya?) ... dalam hal ini, Anda dapat melihat menambalnya secara manual (tautan dalam jawaban lain).

Hal lain yang mungkin bisa Anda lihat adalah fitur RBL di mod_security. Mungkin ada RBL online di mana ada yang menyediakan IP w00tw00t (atau IP jahat lainnya yang dikenal). Namun ini berarti mod_security melakukan pencarian DNS untuk setiap permintaan.

Bagaimana kalau menambahkan aturan ke modsecurity? Sesuatu seperti ini:

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

Saya melihat bahwa sebagian besar solusi sudah dibahas di atas namun saya ingin menunjukkan bahwa tidak semua klien mengirim permintaan HTTP / 1.1 tanpa serangan nama host ditujukan langsung ke server Anda. Ada banyak upaya berbeda untuk sidik jari dan / atau mengeksploitasi sistem jaringan sebelum server Anda yaitu menggunakan:

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

untuk menargetkan router Linksys dll. Jadi kadang-kadang membantu untuk memperluas fokus Anda dan membagi upaya pertahanan Anda antara semua sistem dengan bagian yang sama yaitu: mengimplementasikan aturan router, mengimplementasikan aturan firewall (mudah-mudahan jaringan Anda memiliki satu), mengimplementasikan server firewall / tabel IP aturan dan layanan terkait yaitu mod_security, fail2ban dan sebagainya.

bagaimana dengan ini ?

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:

bekerja dengan baik untuk saya.

Jika Anda menggunakan hiawathaserver web sebagai reverse proxypindaian ini secara otomatis dijatuhkan sebagai sampah & clientdilarang. Ini juga menyaring XSS& CSRFmengeksploitasi.