Pertanyaan Berurusan dengan serangan HTTP w00tw00t


Saya memiliki server dengan apache dan saya baru saja menginstal mod_security2 karena saya banyak 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 mengonfigurasi 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:\)"

Hal 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. Ada yang punya saran?

Perbarui 1

Saya melihat bahwa tidak ada yang bisa memecahkan masalah ini menggunakan mod_security. Sejauh ini menggunakan ip-tables sepertinya merupakan pilihan terbaik untuk melakukan ini tetapi saya pikir file tersebut akan menjadi sangat besar karena ip mengubah waktu serveral sehari.

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

  1. Solusi pertama yang terlintas dalam pikiran saya adalah mengecualikan serangan ini dari log kesalahan apache saya. Ini akan membuat lebih mudah bagi saya untuk melihat kesalahan mendesak lainnya saat terjadi dan tidak perlu meludahi log yang panjang.

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

Perbarui 2

Setelah melalui jawaban saya sampai pada kesimpulan berikut.

  1. Untuk memiliki custom logging untuk apache akan mengkonsumsi beberapa sumber yang tidak perlu, dan jika memang ada masalah Anda mungkin akan ingin melihat log lengkap tanpa ada yang hilang.

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

Pemikiran akhir tentang masalah ini

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

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

Mencegah hal ini terjadi dengan cara apa pun akan merugikan sumber daya Anda dan merupakan praktik yang baik untuk tidak membuang-buang sumber daya Anda untuk hal-hal yang tidak penting.

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

Terima kasih atas bantuannya, dan semoga postingan ini dapat bermanfaat bagi orang lain juga.


80
2018-03-24 05:33






Jawaban:


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

Coba sendiri:

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

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

Permintaan yang tepat harus terlihat seperti:

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

Pekerjaan di sekitar untuk masalah ini bisa dengan menambal mod_uniqueid, untuk menghasilkan ID unik bahkan untuk permintaan yang gagal, agar apache mengirimkan permintaan ke penangan permintaannya. URL berikut adalah diskusi tentang pekerjaan ini di sekitar, dan termasuk patch 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 benar-benar diperlukan.


34
2018-03-29 13:17



Saya melihat masalahnya sekarang. Apakah Anda merekomendasikan solusi yang disediakan dalam artikel, atau apakah Anda pikir lebih baik membiarkannya seperti apa adanya. Ini adalah pemindai untuk semua pintu belakang dalam sistem. Jika saya membiarkannya hanya memindai, saya bisa suatu hari diserang. - Saif Bechan
Halo Saif, saya pikir selama Anda menjaga instalasi apache Anda up-to-date dengan patch keamanan distribusi Anda (atau manual) Anda harus baik-baik saja. Permintaan HTTP / 1.1 yang tidak terstruktur dengan baik (seperti yang Anda lihat) seharusnya tidak mengembalikan apa pun selain kesalahan 400 dari apache. Itu terlihat seperti itu mungkin telah menjadi semacam pemindaian kerentanan yang difokuskan pada router DLink. (Menurut beberapa sumber lain) - Imo
Apakah ada setidaknya cara mendapatkan bidang-bidang ini dari apache error_log saya - Saif Bechan
Kamu mungkin dapat melakukannya melalui mod_log :: httpd.apache.org/docs/2.2/mod/mod_log_config.html#customlog - Imo
Petunjuk tambahan saya adalah: konfigurasikan Anda default virtualhost di sebelah yang benar-benar digunakan. Upaya yang disebutkan di atas akan berakhir di log untuk default virtualhost. - Koos van den Hout


Memfilter IP bukanlah ide yang baik, 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

15
2018-05-09 16:21



spamcleaner.org/en/misc/w00tw00t.html solusi serupa, tetapi sedikit lebih rinci. - Isaac
Satu masalah dengan penyaringan string di firewall adalah "cukup lambat". - Alexis Wilke
@AlexisWilke apakah Anda memiliki bukti yang menunjukkan bahwa iptables string filtering lebih lambat daripada pemfilteran pada level apache? - jrwren


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

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

[Tue Aug 16 02:35:23 2011] [kesalahan] [klien] File tidak ada: /var/www/skraps/w00tw00t.at.blackhats.romanian.anti-sec :) === apache w00t w00t pesan 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

Filter

 # 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



Memang benar bahwa Anda dapat memblokir mereka, tetapi tidak perlu karena itu hanya permintaan yang buruk. Lebih baik untuk mengabaikan mereka, menyelamatkan Anda bekerja dan Anda akan membebaskan beberapa sumber. - Saif Bechan
Benar @Saif Bechan, jika seseorang khawatir tentang "serangan pengujian" untuk menjadi sukses, dia harus lebih baik memperbaiki aplikasi sendiri daripada membuang-buang waktu untuk menemukan cara untuk memblokir itu. - Thomas Berger
Memberi Anda memberi +1, terima kasih atas jawabannya. - Saif Bechan
@SaifBechan, saya tidak setuju. w00tw00t adalah pemindai kerentanan, dan mesin yang mengeluarkan permintaan seperti itu tidak dapat dipercaya dengan mencoba jenis permintaan lain, jadi jika saya seorang administrator sistem dan dibutuhkan waktu 2 menit untuk melarang klien tersebut selama berhari-hari, saya akan melakukannya. Saya tidak akan mendasarkan seluruh implementasi keamanan saya pada pendekatan semacam itu. - Isaac


w00tw00t.at.blackhats.romanian.anti-sec adalah upaya peretasan dan menggunakan spoof IP sehingga pencarian seperti VisualRoute akan melaporkan China, Polandia, Denmark dll sesuai dengan IP yang diperbantukan pada waktu itu. Jadi menyiapkan Deny IP atau Nama Host yang dapat diatasi hampir tidak mungkin karena akan berubah dalam satu jam.


3
2018-06-01 11:20



Pemindaian kerentanan ini tidak menggunakan alamat IP palsu. Jika mereka melakukannya, handshake TCP 3-way tidak akan selesai dan Apache tidak akan mencatat permintaan. Untuk peringatan (rogue ISP, operator router, dll), lihat security.stackexchange.com/q/37481/53422 - Anthony Geoghegan


Saya pribadi menulis skrip Python untuk menambahkan aturan IPtables otomatis.

Ini adalah versi yang sedikit disingkat tanpa pencatatan 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)

2
2018-03-24 07:06



Apakah ini untuk mencegah serangan w00tw00t - Saif Bechan
Ya, saya sudah memindai log kesalahan Apache untuk setiap "w00tw00t" IP dan menambahkannya jika mereka tidak ada, meskipun untuk kesederhanaan saya tidak menambahkan cek untuk duplikat. - Xorlev
Skrip ini mungkin harus menggunakan tabel, menambahkan banyak aturan tambahan ke rantai iptables akan memperlambat pemrosesan cukup sedikit. - Eric
Itu menggunakan meja. Namun saya menyederhanakan banyak karena disesuaikan dengan sistem saya. - Xorlev
apakah Anda pikir ini adalah solusi yang lebih baik yang menggunakan mod_security - Saif Bechan


Saya percaya alasan mod_security tidak bekerja untuk Anda adalah Apache belum dapat menguraikan sendiri permintaan, mereka tidak spesifik. Saya tidak yakin Anda memiliki masalah di sini - apache adalah penebangan aneh yang terjadi di internet, jika tidak masuk, Anda tidak akan menyadari itu bahkan terjadi. Sumber daya yang diperlukan untuk mencatat permintaan mungkin minimal. Saya memahami frustrasinya bahwa seseorang sedang mengisi log Anda - tetapi akan lebih membuat frustrasi jika Anda menonaktifkan logging hanya untuk menemukan Anda benar-benar membutuhkannya. Seperti seseorang masuk ke server web Anda dan Anda perlu log untuk menunjukkan bagaimana mereka masuk.

Salah satu solusinya adalah dengan men-setup ErrorLogging melalui syslog, dan kemudian menggunakan rsyslog atau syslog-ng Anda dapat secara khusus menyaring dan membuang pelanggaran RFC ini mengenai w00tw00t. Atau sebagai alternatif Anda bisa menyaringnya menjadi file log terpisah hanya agar ErrorLog utama Anda mudah dibaca. Rsyslog sangat kuat dan fleksibel dalam hal ini.

Jadi di httpd.conf Anda mungkin melakukan:

ErrorLog syslog:user 

kemudian di rsyslog.conf Anda mungkin memiliki:

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

Sadarilah, pendekatan ini akan benar-benar digunakan berkali-kali lebih banyak sumber daya dari yang semula digunakan untuk masuk langsung ke file. Jika server web Anda sangat sibuk, ini bisa menjadi masalah.

Praktik terbaiknya adalah meminta semua log dikirim ke server penebangan jarak jauh sesegera mungkin dan ini akan menguntungkan Anda jika Anda pernah terpecah 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 itu sendiri. Apakah ada pola di alamat IP, atau berasal dari botnet besar yang didistribusikan? Diperlukan X% duplikat sebelum Anda mendapat manfaat dari iptables.


2
2018-03-30 11:09



Jawaban bagus, saya suka pendekatan yang berbeda. Berpikir tentang hal itu, setelah custom logging akan membuat penggunaan recourse lebih, karena semuanya harus diperiksa terlebih dahulu, saya kira opsi ini juga jatuh. Sekarang saya telah mengaktifkan logwatch. Ini mengirimkan saya laporan 2 kali sehari dengan ringkasan keseluruhan sistem. Log apache juga diperiksa dan hanya mengatakan w00tw00t mencoba 300 kali. Saya pikir saya akan meninggalkan setup seperti untuk saat ini. - Saif Bechan


Anda mengatakan di Pembaruan 2:

Masalah yang masih ada   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 yang paling direkomendasikan. Masalahnya tetap bahwa jika Anda memiliki file ini di server Anda entah bagaimana suatu hari, Anda berada dalam masalah.

Dari jawaban saya sebelumnya, kami mengumpulkan 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 tidak mengecek dua kali RFC - mungkin RFC2616 memberitahu kami).

Memiliki w00tw00t.at.ISC.SANS.DFind: di server Anda beberapa di mana tidak secara mistis berarti "Anda berada dalam masalah" ... Jika Anda membuat file w00tw00t.at.ISC.SANS.DFind: 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 dalam file w00tw00t.at.ISC.SANS.DFind: tidak akan dilayani.

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

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


1
2018-03-31 08:52



Saya tidak berpikir apache menolaknya, itu hanya melempar kesalahan tetapi pencarian masih lewat. Saya telah mendapatkan w00tw00t.at.ISC.SANS.DFind yang sama di log akses. Itu melakukan GET. Jadi pencarian dilakukan dan jika Anda memiliki file di komputer Anda maka akan dijalankan. Saya dapat memposting entri log akses tetapi mereka terlihat sama dengan log kesalahan hanya dengan GET di depannya. Apache melempar kesalahan tetapi permintaannya lewat. Itu sebabnya saya bertanya apakah itu akan menjadi ide yang baik untuk memblokir permintaan ini tanpa nama host. Tapi saya tidak ingin memblokir pengguna normal. - Saif Bechan
Tentu, Anda mendapatkan entri yang sama di log akses tetapi melihat kode kesalahan ... 400. Ini tidak diproses. HTTP / 1.1 (hostname) digunakan untuk memberi tahu apache mana virtual host untuk mengirim permintaan ke ... tanpa bagian hostname dari permintaan HTTP / 1.1 apache tidak tahu kemana harus mengirim permintaan dan mengembalikan kesalahan "400 permintaan buruk" kembali ke klien. - Imo
Cobalah sendiri ... buat sendiri halaman html di server web Anda dan coba gunakan secara manual menggunakan "telnet hostname 80" ... langkah-langkah lain ada dalam jawaban pertama saya. Saya akan menaruh banyak hadiah di atasnya sehingga Anda tidak bisa mendapatkan file html untuk ditampilkan menggunakan HTTP / 1.1 tanpa nama host. - Imo
Ah ya ya itu untuk menunjukkan itu padaku. Saya selalu berpikir access_log adalah entri yang melewati log kesalahan dan benar-benar masuk ke 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 masalah, senang telah membantu. Hormat, Imo - Imo


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
2017-08-09 08:23