Apakah mungkin melayani halaman tertentu berdasarkan alamat IP?

8

Saya telah menjadi target serangan brute force di dua situs WordPress yang saya miliki. Penyerang menggunakan hal XML-RPC lama yang baik untuk memperkuat serangan kata sandi brute-force. Untungnya kami memiliki kata sandi yang dihasilkan dengan sangat baik, jadi saya sangat meragukan dia akan pernah berhasil.

Saya baru saja menggunakan iptables untuk memblokir permintaannya setiap kali dia muncul lagi (selalu dari penyedia cloud virtual yang sama), tapi saya lebih suka memodifikasi server sehingga setiap kali alamat IP-nya meminta halaman apa pun , dia mendapat respons dengan mengatakan kepadanya untuk mendapatkan kehidupan. Sebagian besar permintaan adalah POST, jadi saya idealnya hanya ingin memodifikasi tajuk tanggapan untuk memasukkan sesuatu seperti "Keberuntungan yang lebih baik lain kali!" atau sesuatu yang sama memuaskannya.

Apakah ini mungkin? Saya jauh dari ahli dengan Apache, jadi saya tidak yakin seberapa sulit ini untuk diterapkan. Tetapi bahkan jika itu membutuhkan waktu berjam-jam, kepuasan itu akan sangat berharga.

Sebagai referensi, saya menjalankan Ubuntu 16.04.2 LTS, dengan Apache 2.4.18 hosting Wordpress 4.7.3.

apache-2.4 http-headers Aurelius
sumber
"selalu dari penyedia cloud virtual yang sama" OVH? Saya perhatikan banyak skrip kiddies menggunakan layanan mereka untuk beberapa alasan.
hd.
Tidak, online.net ... mereka sejauh ini tidak menanggapi satu pun dari laporan penyalahgunaan saya. Juga, pertama kali saya mengirim permintaan penyalahgunaan, saya menemukan bahwa mereka secara otomatis meneruskan keluhan kepada pelanggan. Karenanya bagaimana dia menemukan situs web pribadi saya. Kerja bagus, online.net ....
Aurelius

Jawaban:

25

Cukup instal fail2ban dengan jail yang sesuai dan selesai dengannya. Jangan repot-repot memberikan respons khusus, karena kemungkinan besar itu tidak akan pernah terlihat.

EEAA
sumber
1
Tentunya. Tapi ini pasti sesuatu yang selalu ingin saya lakukan. Bahkan jika dia tidak pernah melihatnya, hanya kemungkinan membuatku tertawa begitu keras sampai aku hampir menangis.
Aurelius
14
Nah: 1) IMHO mencari tahu cara menampilkan penghinaan kecil ke script kiddie di luar topik di sini. 2) Melakukan hal itu masih akan menghabiskan sumber daya apache Anda, sedangkan fail2ban / iptables memblokir permintaan di hulu sehingga aplikasi Anda tidak perlu menghadapinya.
EEAA
1
Oh tentu saja. Tapi saya ingin bersenang-senang sebelum perma-ban. Baik kecil atau tidak, saya hanya ingin tertawa, dan ini atas permintaan orang yang bisnisnya menggunakan server.
Aurelius
4
@ Aurelius, jika Anda tahu ip, dan orang ini tidak menutupinya, mengapa Anda tidak melakukan ini di app itu sendiri, php dalam hal ini. Cukup verifikasi apakah itu ip xx.xx.xx.xx dan jika itu hanya membunuh script dengan respons,die("blah blah");
Miguel
Diterima sebagai jawabannya, sebagian besar karena saya tidak tahu tentang fail2ban dan itu sangat membantu secara umum. Jawaban Miguel di atas, serta jawaban BlackWebWolf di bawah, adalah dua hal yang akan saya perhatikan!
Aurelius
5

Ada kemungkinan, dan kami melakukannya cukup banyak, untuk membalikkan kemungkinan serangan. Gunakan iptables untuk mengarahkan penyedia cloud (kisaran alamat) ke port yang berbeda - dan di sana melayani penyerang respons, bahkan dalam header biasa.

Di Apache Anda dapat memodifikasi tajuk dengan contoh:

Header set GetOut "Better luck next time!"
BlackWebWolf
sumber
Hehehe!! Nah, itu yang saya bicarakan. Ide bagus! Saya akan melihat ini.
Aurelius
5
strategi ini mungkin akan menjadi bumerang bagi respons, karena itu memungkinkan penyerang tahu apa yang bekerja dan apa yang tidak, itu jauh lebih baik untuk secara diam-diam mengabulkan permintaan kepada apa-apa dan tidak membuat bendera peringatan dalam perangkat lunak serangan botnya. Idealnya mengembalikan html halaman yang diminta, misalnya. mereka tidak pernah tahu Anda menangkapnya, tidak ada yang terjadi, dan situs Anda lebih aman. Tahan keinginan untuk memberi tahu mereka, itu adalah KESALAHAN, selalu. Ini hanya membantu mereka men-debug masalah. Dalam kasus Anda, cukup beralih ke rentang IP yang lebih dinamis, dll, membuat masalah JAUH lebih sulit untuk diselesaikan.
Lizardx
1
Anda benar, itu tidak direkomendasikan - bahkan mungkin berbahaya. Strategi dengan honeypot selalu lebih baik, namun pertanyaannya jelas - bagaimana cara
mengendalikan
Saya tidak benar-benar peduli apakah itu kesalahan - saya telah menginstal fail2ban, dan dia akan tetap dilarang. Saya sangat meragukan dia akan benar-benar mendapatkan apa pun; Sejauh yang saya tahu, rilis terbaru WordPress benar-benar memperbaiki bug keamanan ini? Belum lagi, brute forcing passwords yang lebih panjang dari 20 karakter .... ya, tidak terjadi seumur hidup di jagat raya kita.
Aurelius
blackwebwolf, ini mirip dengan seseorang yang bertanya bagaimana menerapkan ekstensi mysql_ php yang sudah usang, sementara orang dapat secara teknis menjawab pertanyaan itu, jawaban itu salah karena jawaban sebenarnya berarti melakukannya dengan benar, dalam hal itu, misalnya, menggunakan mysqli_ atau xpdo. Hanya gagasan, yang banyak dari kita telah lakukan di masa lalu kita juga, bahwa menanggapi dengan cara apa pun seperti troll adalah apa pun selain negatif besar, harus diperbaiki, karena itu adalah kesalahan serius, dan jika seseorang pernah menderita karena kesalahan itu, orang akan segera mengerti mengapa pertanyaan itu salah.
Lizardx
3

Ini sangat mudah dengan ModSecurity yang merupakan modul WAF pihak ketiga untuk Apache. Meskipun itu melibatkan belajar sintaks bahasa aturannya.

Anda juga dapat menggunakan ModSecurity untuk hanya menjatuhkan koneksi daripada merespons sama sekali.

Mengatakan itu, menginstal ModSecurity hanya untuk ini, ketika, seperti yang orang lain sarankan, kemungkinan responsnya akan diabaikan mungkin terlalu banyak.

Barry Pollard
sumber
2

Saya akan pergi dengan fail2ban dan membatalkan permintaan dari lokasi penyalahgunaan yang diketahui. Dan jika Anda merasa bahwa penyedia layanan penyerang tidak bisa disalahkan, laporkan serangan ke alamat email penyalahgunaan mereka.

Jika Anda ingin menghabiskan waktu membuat sesuatu yang akan memperlambat penyerang, Anda mungkin ingin mencoba membuat tarpit . Pertama, Anda tentu harus tahu dari mana serangan itu berasal. Kemudian Anda bisa menggunakan apache untuk mengarahkan permintaan dari ip (rentang?) Ke skrip tertentu. Ini mungkin melakukan trik walaupun saya belum mencobanya sendiri. Kemudian cukup laksanakan skrip yang, misalnya, mencetak titik (atau sesuatu dari / dev / null) setiap 15 detik untuk menjaga koneksi penyerang tetap terbuka tanpa batas.

Karena penyerang kemungkinan besar menggunakan skrip untuk menyerang situs Anda, mungkin perlu waktu untuk memperhatikan bahwa serangan telah terhenti, karena koneksi semua tampaknya aktif, tidak akan ada batas waktu dan permintaan tidak ditolak di tempat.

Masalahnya adalah Anda mencurahkan waktu dan sumber daya untuk sesuatu yang mungkin tidak akan membantu seperti masalah yang lebih penting: mengamankan login Anda. Sulit untuk menyerang ketika Anda tidak tahu harus menyerang ke mana. Pertimbangkan beberapa hal berikut ini:

  • batasi akses ke halaman login (hanya intranet? rentang ip? vpn? lainnya?).
  • tambahkan reCaptcha atau pertanyaan verifikasi lainnya untuk masuk.
  • gunakan otentikasi multi-faktor .
  • sembunyikan halaman login Anda. Jika memungkinkan, jangan menautkannya dari halaman utama Anda dan jangan gunakan / login atau lokasi lain yang jelas.
Komunitas
sumber
Terimakasih atas infonya! Jadi, untuk membereskannya, A) dua pengguna yang dapat login memiliki kata sandi panjang yang dibuat secara acak. B) Ada semacam captcha di halaman login. C) Saya mencoba agar .htaccess berfungsi untuk mencegah akses ke halaman itu. Namun tampaknya standar untuk .htaccess telah berubah beberapa kali - saya terus melihat sintaks yang berbeda di mana-mana dan sejauh ini htaccess nyaris tidak berfungsi sama sekali.
Aurelius
Juga, saya telah melaporkan semua serangan ke online.net tanpa respons apa pun.
Aurelius
Beberapa tips bermanfaat untuk htaccess: stackoverflow.com/questions/6441578/… (Saya sangat merekomendasikan digest digest).
Melihat komentar di halaman ini, intisari sepertinya bukan ide yang bagus? httpd.apache.org/docs/2.4/mod/mod_auth_digest.html
Aurelius
1
Anda membuat saya di sana. Ya, saya ingat itu sejak saya menggunakan otentikasi digest dan kemudian kami tidak memiliki https di mana-mana. Alasan mengapa kami tidak menggunakan kata sandi htacces adalah karena itu bukan solusi jangka panjang. Tidak apa-apa menggunakannya untuk menyembunyikan sesuatu seminggu sebelum penerbitan, tetapi untuk penggunaan sehari-hari Anda tidak ingin level kata sandi yang lain. Itu bahkan tidak jauh lebih aman. Ketika sumber daya ada di tempat yang sama sekali tidak muncul di Internet publik, maka kita berada di jalur yang benar.