Berurusan dengan serangan HTTP w00tw00t


82

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.

Jawaban:


34

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.


Saya melihat masalahnya sekarang. Apakah Anda merekomendasikan solusi yang disediakan dalam artikel, atau menurut Anda lebih baik membiarkannya begitu saja? Ini adalah pemindai untuk setiap pintu belakang dalam sistem. Jika saya membiarkannya hanya memindai, suatu hari saya bisa diserang.
Saif Bechan

1
Halo Saif, saya pikir selama Anda memperbarui instalasi apache dengan patch keamanan distribusi (atau manual) Anda, Anda akan baik-baik saja. Permintaan HTTP / 1.1 yang terstruktur dengan buruk (seperti yang telah Anda lihat) seharusnya tidak mengembalikan apa pun selain 400 kesalahan dari apache. Sepertinya itu mungkin semacam pemindaian kerentanan yang difokuskan pada router DLink. (Menurut beberapa sumber lain)
Imo

Apakah setidaknya ada cara untuk mengeluarkan bidang ini dari apache saya error_log
Saif Bechan

Anda mungkin dapat melakukannya melalui mod_log :: httpd.apache.org/docs/2.2/mod/mod_log_config.html#customlog
Imo

Petunjuk tambahan saya adalah: konfigurasikan virtualhost default Anda di sebelah yang benar-benar digunakan. Upaya yang disebutkan di atas akan berakhir di log untuk virtualhost default .
Koos van den Hout

16

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

spamcleaner.org/en/misc/w00tw00t.html solusi serupa, tetapi sedikit lebih detail.
Isaac

Satu masalah dengan penyaringan string di firewall adalah bahwa itu "cukup lambat".
Alexis Wilke

@AlexisWilke apakah Anda memiliki bukti yang menunjukkan bahwa penyaringan string iptables lebih lambat daripada penyaringan di tingkat apache?
jrwren

@ jrwren Sebenarnya, ini bisa sangat lambat jika dan hanya jika Anda tidak melewati paket offset untuk berhenti mencari, yaitu "- hingga 60" di sini. Secara default, ini akan mencari seluruh paket, batas maksimum ditetapkan 65.535 byte, panjang paket IP maksimum: blog.nintechnet.com/... Manual ini dengan jelas mengatakan "Jika tidak dilewati, standarnya adalah ukuran paket".
gouessej

itu adalah teori max. panjang maks lebih realistis melalui internet adalah ~ 1500.
jrwren

11

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 =

2
Memang benar bahwa Anda dapat memblokir mereka, tetapi tidak perlu karena mereka hanya permintaan yang buruk. Lebih baik mengabaikannya, menyelamatkan Anda bekerja dan Anda akan membebaskan beberapa sumber.
Saif Bechan

Benar @ Saif Bechan, jika seseorang khawatir tentang "pengujian serangan" untuk menjadi sukses, dia harus lebih baik memperbaiki aplikasi sendiri daripada membuang-buang waktu untuk menemukan cara untuk memblokir itu.
Thomas Berger

Memberi Anda +1, terima kasih atas jawabannya.
Saif Bechan

4
@ SaifBechan, saya tidak setuju. w00tw00t adalah pemindai kerentanan, dan mesin yang mengeluarkan permintaan semacam itu tidak dapat dipercaya dengan mencoba jenis permintaan lainnya, jadi jika saya seorang administrator sistem dan perlu waktu 2 menit untuk melarang klien seperti itu selama berhari-hari, saya akan melakukannya. Saya tidak akan mendasarkan seluruh implementasi keamanan saya pada pendekatan seperti itu.
Isaac

3

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.


Pemindaian kerentanan ini tidak menggunakan alamat IP palsu. Jika mereka melakukannya, jabat tangan TCP 3 arah tidak akan selesai dan Apache tidak akan mencatat permintaan. Untuk peringatan (ISP jahat, operator router, dll), lihat security.stackexchange.com/q/37481/53422
Anthony G - keadilan untuk Monica

2

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)

Apakah ini untuk mencegah serangan w00tw00t
Saif Bechan

Ya, saya memilikinya memindai log kesalahan Apache untuk setiap IP "w00tw00t" dan menambahkannya jika tidak ada, meskipun untuk kesederhanaan saya tidak menambahkan cek untuk duplikat.
Xorlev

Script ini mungkin harus menggunakan tabel, menambahkan banyak aturan tambahan ke rantai iptables akan memperlambat pemrosesan sedikit.
Eric

Itu menggunakan tabel. Namun saya menyederhanakan banyak hal karena disesuaikan dengan sistem saya.
Xorlev

apakah Anda pikir ini adalah solusi yang lebih baik untuk menggunakan mod_security
Saif Bechan

2

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.


Jawaban yang bagus, saya suka pendekatan yang berbeda. Berpikir tentang itu, memiliki pembuatan log kustom akan menciptakan lebih banyak penggunaan bantuan, karena semuanya harus diperiksa terlebih dahulu, saya kira opsi ini juga jatuh. Saya sekarang telah mengaktifkan logwatch. Ini mengirimkan saya laporan 2 kali sehari dengan ringkasan seluruh sistem. Log apache juga diperiksa dan hanya dikatakan upaya w00tw00t 300 kali. Saya pikir saya akan meninggalkan pengaturan seperti saat ini.
Saif Bechan

1

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.


Saya tidak berpikir apache menolak mereka, itu hanya melempar kesalahan tetapi pencarian masih berlalu. Saya sudah mendapatkan w00tw00t.at.ISC.SANS.DFind yang sama di log akses. Itu GET. Jadi pencarian selesai dan jika Anda memiliki file di mesin Anda itu akan dieksekusi. Saya bisa memposting entri log akses tetapi mereka terlihat sama dengan log kesalahan hanya dengan GET di depannya. Apache melempar kesalahan tetapi permintaan lewat. Itulah mengapa saya bertanya apakah itu ide yang bagus untuk memblokir permintaan ini tanpa nama host. Tapi saya tidak ingin memblokir pengguna normal.
Saif Bechan

1
Tentu, Anda mendapatkan entri yang sama di log akses tetapi lihat kode kesalahan ... 400. Itu tidak diproses. HTTP / 1.1 (nama host) digunakan untuk memberi tahu apache host virtual mana untuk mengirim permintaan ke ... tanpa bagian nama host dari permintaan HTTP / 1.1 apache tidak tahu ke mana harus mengirim permintaan dan mengembalikan kesalahan "400 permintaan buruk" kembali ke klien.
Imo

Coba sendiri ... buat sendiri halaman html di server web Anda dan coba dapatkan secara manual menggunakan "telnet hostname 80" ... langkah-langkah lain ada di jawaban pertama saya. Saya akan memberi hadiah besar agar Anda tidak bisa menampilkan file html menggunakan HTTP / 1.1 tanpa nama host.
Imo

Ah ya ya itu untuk menunjukkan itu padaku. Saya selalu berpikir access_log adalah entri yang dikirimkan melalui log kesalahan dan benar-benar memasuki mesin Anda. Terima kasih telah menunjukkan ini kepada saya dan saya akan mengedit posting saya. Saya sangat menghargai bantuan Anda.
Saif Bechan

Hai Saif, tidak ada masalah, senang bisa membantu. Salam, Imo
Imo

1

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

1

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.


1

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.


saya merekomendasikan OWASP_CRS / 2.2.5 atau aturan parutan ditetapkan untuk mod_security
Urbach-Webhosting

Ini benar-benar bukan ide yang bagus. Anda akan berakhir dengan banyak koneksi yang menggantung. Plus jika situs Anda memiliki diskusi tentang permintaan tersebut, Anda dapat berakhir dengan positif palsu.
kasperd

0

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

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.