Cara Menggunakan Mod "Under Attack" Cloudflare di Situs yang Terkena Serangan DDoS

Mod "Under Attack" Cloudflare di situs yang sedang mengalami serangan DDoS adalah pengaturan pertahanan darurat yang menyaring lalu lintas bot dengan menampilkan verifikasi keamanan singkat kepada pengunjung. Dengan memilih situs Anda di panel Cloudflare dan mengaktifkan fitur Under Attack Mode di bagian Security, Anda dapat memperlambat permintaan yang tinggi di tingkat HTTP/HTTPS dalam beberapa menit, menjaga akses pengguna yang sebenarnya ke situs, dan mengurangi beban pada server Anda. Namun, mod ini bukanlah solusi permanen; harus digunakan bersamaan dengan pengaturan proxy DNS yang benar, aturan WAF, pembatasan laju, konfigurasi cache, dan keamanan server asal.

Dalam panduan ini, kami akan membahas langkah demi langkah bagaimana cara mengaktifkan mod Under Attack Cloudflare, kapan harus digunakan, pengaturan apa yang mendukungnya, dan bagaimana cara kembali ke kondisi aman setelah serangan berakhir. Tujuannya adalah untuk memberikan daftar kontrol yang dapat diterapkan dalam situasi panik dan memulihkan aksesibilitas situs Anda dalam waktu sesingkat mungkin.

Apa Itu Mod Under Attack Cloudflare?

Mod Under Attack Cloudflare adalah tingkat keamanan darurat yang ditawarkan oleh Cloudflare. Ketika diaktifkan, Cloudflare akan memverifikasi browser para pengunjung yang datang ke situs dalam waktu singkat. Verifikasi ini biasanya berlangsung beberapa detik dan membuatnya lebih sulit bagi bot otomatis, alat serangan HTTP yang sederhana, atau klien jahat di luar browser untuk memberikan beban langsung pada situs.

Tujuan dasar dari mod ini adalah untuk mengurangi serangan di tingkat aplikasi, yaitu level Layer 7. Misalnya, jika terdapat ribuan permintaan GET per detik ke halaman utama, percobaan POST yang intensif di halaman login WordPress, kueri yang mahal di halaman pencarian, atau lalu lintas palsu di halaman keranjang belanja, mod Under Attack memberikan intervensi awal secara cepat.

Penting untuk dicatat bahwa: mod Under Attack menyaring permintaan web; namun, jika alamat IP server Anda menjadi target langsung, layanan Anda di luar proxy Cloudflare tetap terekspos, atau jika serangan dilakukan di level Layer 3/4, langkah tambahan diperlukan. Oleh karena itu, sangat penting untuk memastikan bahwa catatan DNS tersambung melalui Cloudflare dalam keadaan proxied, alamat IP asal disembunyikan, dan tindakan keamanan yang tepat diterapkan di sisi hosting. Untuk pemilihan infrastruktur yang aman, bisa dihubungkan dengan konten Perkhidmatan hosting web yang selamat dan Pemasangan sijil SSL.

Tanda-Tanda Serangan DDoS: Apa yang Harus Diperiksa Sebelum Beralih ke Mod Under Attack?

Tidak semua perlambatan adalah DDoS. Kadang-kadang, plugin yang error, penguncian basis data, tugas cron yang menggunakan CPU tinggi, atau pengaturan cache yang salah juga dapat menyebabkan hasil serupa. Oleh karena itu, bermanfaat untuk melakukan diagnosis cepat sebelum mengaktifkan mod Under Attack. Namun, jika server sulit memberikan respons, pengguna mendapatkan error 502, 503, 504, dan terdapat lonjakan permintaan yang tidak biasa dalam log, mod darurat tidak boleh ditunda.

Tanda-Tanda Umum DDoS

• Peningkatan lalu lintas normal sebanyak 5, 10, atau 50 kali dalam waktu singkat.
• Permintaan yang masuk ke satu halaman atau endpoint mencapai ratusan per detik.
• Pangkalan lalu lintas dari negara yang berbeda tetapi dengan nilai user-agent yang serupa.
• Menargetkan URL mahal seperti admin, login, search, cart di WordPress, WooCommerce, OpenCart, atau perangkat lunak khusus.
• Keterisian batas koneksi CPU, RAM, PHP-FPM worker, atau MySQL di server.
• Peningkatan mendadak dalam error 4xx dan 5xx di layar Analitik Cloudflare.
• Pengguna yang nyata dapat mengakses situs secara sporadis, tetapi lalu lintas bot terus mengirim permintaan.

Contohnya, jika situs e-commerce yang biasanya mendapatkan 2.000 permintaan per menit tiba-tiba melonjak menjadi 80.000 permintaan dalam sepuluh menit dan 70% permintaan tersebut pergi ke halaman keranjang atau pencarian, ini adalah tanda jelas serangan Layer 7. Dalam skenario ini, mod Under Attack harus diaktifkan dalam lima menit pertama, diikuti dengan penambahan aturan WAF dan pembatasan laju yang disesuaikan dengan URL target.

Kapan Harus Menggunakan Mod Under Attack Cloudflare?

Mod Under Attack Cloudflare bukanlah pengaturan keamanan standar yang harus selalu aktif. Karena hal ini juga menampilkan layar tunggu singkat kepada pengunjung nyata. Situasi ini terutama dapat mempengaruhi pengalaman pengguna di halaman yang berfokus pada konversi, langkah pembayaran, atau struktur yang menggunakan API. Penggunaan yang paling tepat adalah mengaktifkannya sementara selama serangan dan menyesuaikan tingkat keamanan kembali setelah lalu lintas normal kembali.

Situasi yang Cocok untuk Penggunaan

• Jika situs menerima permintaan HTTP/HTTPS yang tinggi dan abnormal.
• Jika sumber daya server cepat habis dan terdapat peningkatan error 502/503.
• Jika WAF Cloudflare belum dikonfigurasi dengan aturan khusus dan diperlukan perlindungan cepat.
• Jika lalu lintas bot jauh lebih banyak daripada lalu lintas pengguna nyata.
• Jika halaman web, formulir, layar login, atau endpoint pencarian menjadi target serangan.

Situasi yang Perlu Diperhatikan

• Jika aplikasi mobile, penyedia pembayaran, webhook, atau lalu lintas API digunakan secara intensif.
• Jika Anda berada dalam periode kritis di mana bot mesin pencari sedang merayapi.
• Jika pengguna korporat Anda mengakses situs melalui browser lama atau di lingkungan jaringan yang terbatas.
• Jika terdapat subdomain di situs Anda yang tidak terletak di belakang proxy Cloudflare.

Jika mod Under Attack diterapkan untuk situs yang memiliki lalu lintas API, beberapa integrasi bisa gagal. Oleh karena itu, jika memungkinkan, aturan WAF khusus, allowlist, atau tingkat keamanan yang berbeda harus direncanakan untuk subdomain API. Untuk panduan rinci tentang keamanan API, dapat merujuk pada Panduan Keselamatan API dan Had Kadar.

Bagaimana Cara Mengaktifkan Mod Under Attack Cloudflare? Panduan Langkah demi Langkah

Langkah-langkah berikut adalah daftar kontrol praktis yang disiapkan untuk bertindak cepat saat serangan terjadi. Antarmuka Cloudflare mungkin mengalami sedikit perubahan seiring waktu; tetapi logika dasarnya tetap sama: Anda memilih domain Anda, meningkatkan tingkat keamanan, dan memvalidasi lalu lintas yang datang melalui Cloudflare.

1. Login ke akun Cloudflare Anda

Pertama, masuk ke akun Cloudflare Anda dan pilih domain yang sedang diserang. Jika Anda mengelola beberapa domain, pastikan Anda melakukan tindakan di zona yang benar. Mengaktifkan mod Under Attack di domain yang salah dapat membuang waktu dan serangan utama tetap berlanjut.

2. Periksa bahwa catatan DNS dalam keadaan proxied

Agar mod Under Attack efektif, lalu lintas web harus melewati Cloudflare. Di bagian DNS, pastikan catatan A, AAAA, dan CNAME dalam keadaan cloud oranye, yaitu proxied. Catatan DNS yang berwarna abu-abu atau DNS only tidak akan melewati lapisan keamanan Cloudflare. Terutama www, nama domain root, dan subdomain yang digunakan harus diperhatikan.

Jika alamat IP asal Anda terlihat publik, penyerang dapat melewati Cloudflare dan menyerang langsung ke server. Oleh karena itu, memberikan izin hanya untuk lalu lintas HTTP/HTTPS yang berasal dari rentang IP Cloudflare di firewall server Anda adalah langkah perlindungan yang kuat. Anda dapat meminta dukungan dari penyedia hosting Anda untuk hal ini atau merujuk ke panduan bagaimana untuk mengatur tetapan DNS Cloudflare.

3. Aktifkan fitur Under Attack Mode dari bagian Security

Setelah membuka domain yang relevan di panel Cloudflare, cari opsi Under Attack Mode di layar Security atau Overview. Ketika Anda mengaktifkan opsi ini, Cloudflare akan mulai menampilkan halaman verifikasi singkat kepada pengunjung yang datang ke situs. Pada beberapa panel, pengaturan ini mungkin juga muncul di bawah Security Level sebagai I am Under Attack.

Setelah diaktifkan, perubahan biasanya berlaku dalam waktu singkat. Dalam beberapa menit pertama, perlu untuk memantau Cloudflare Analytics, Kejadian Keamanan dan penggunaan sumber daya server secara bersamaan. Jika jumlah CPU dan koneksi mulai menurun, ini berarti mod berfungsi. Namun, jika tingkat kesalahan tetap tinggi, aturan tambahan perlu ditetapkan.

4. Uji pengalaman pengguna nyata

Setelah mengaktifkan mod, uji situs dari berbagai jaringan. Halaman utama, halaman produk, halaman login, dan alur pembayaran harus diuji dari internet seluler, jaringan kantor, dan jika mungkin, dari lokasi yang berbeda. Jika setelah layar verifikasi pengguna dapat mengakses situs, itu adalah perilaku yang diharapkan. Namun, jika pengguna terjebak dalam siklus verifikasi tanpa akhir, pengaturan yang memblokir cookie, kompatibilitas browser, atau konflik aturan keamanan Cloudflare perlu ditinjau.

5. Tentukan URL yang menjadi target serangan

Mod Under Attack menyediakan pelindung umum; tetapi hasil terbaik diperoleh dengan aturan yang khusus ditetapkan di target. Temukan jalur yang paling banyak mendapatkan permintaan dari Cloudflare Security Events, Web Analytics, log akses hosting, dan log aplikasi. Misalnya, URL seperti /wp-login.php, /xmlrpc.php, /search, /cart, /api/login, atau /checkout mungkin menjadi target serangan.

Setelah URL target ditentukan, Anda dapat mengambil tindakan berdasarkan WAF Custom Rules berdasarkan negara, user-agent, metode permintaan, URI path, atau skor bot. Misalnya, untuk endpoint login tertentu yang mengirimkan permintaan di atas jumlah yang wajar per menit, managed challenge dapat diterapkan pada IP tersebut. Untuk situs WordPress, tautan Langkah-langkah Keselamatan WordPress adalah peluang tautan internal yang alami.

Perbedaan antara Under Attack Mode dan Opsi Keamanan Cloudflare Lainnya

Alat keamanan Cloudflare memiliki tujuan yang berbeda. Mod Under Attack adalah filter darurat yang cepat dan umum; sedangkan WAF dan Pembatasan Laju menawarkan solusi yang lebih terarah, berkelanjutan, dan seimbang dari segi pengalaman pengguna.

Dalam praktiknya, pendekatan pertahanan yang baik bergerak seperti berikut: Pertama, tekan mod Under Attack untuk mengurangi tekanan darurat, kemudian analisis pola serangan, tambahkan aturan WAF dan pembatasan laju, dan terakhir, perkuat struktur permanen dengan pengaturan cache dan firewall asal.

Pengaturan Cloudflare Tambahan yang Direkomendasikan Selama Serangan

Meskipun mod Under Attack dapat diaktifkan dengan satu tombol, keberhasilan pertahanan DDoS sangat tergantung pada pengaturan tambahan. Berikut adalah rekomendasi yang paling sering efektif dalam praktik.

Buat perlindungan terarah dengan aturan WAF

Cloudflare WAF memungkinkan Anda untuk mengambil tindakan berdasarkan kondisi tertentu. Misalnya, Anda dapat menerapkan tantangan hanya untuk permintaan POST yang datang ke halaman /wp-login.php dari negara tertentu. Dengan cara ini, Anda mengisolasi target serangan tanpa memperberat seluruh situs.

• Buka halaman admin dan login hanya untuk negara atau rentang IP tertentu.
• Blokir endpoint yang tidak digunakan seperti XML-RPC.
• Terapkan managed challenge untuk nilai user-agent yang mencurigakan.
• Batasi klien yang mengirimkan terlalu banyak permintaan di URI path tertentu dengan pembatasan laju.

Atur tingkat cache dengan benar

Jika server asal harus merespons setiap permintaan selama DDoS, sumber daya cepat habis. Berkas statis, gambar, CSS, JavaScript, dan halaman yang dapat di-cache harus dilayani melalui edge Cloudflare. Dalam sistem dinamis seperti WordPress, tambahan plugin cache, aturan cache Cloudflare, dan header cache-control yang sesuai dapat digunakan bersama.

Misalnya, di situs yang berfokus pada berita atau blog, halaman yang ditampilkan kepada pengunjung anonim dapat di-cache selama 5 hingga 30 menit. Pengaturan sederhana ini, bahkan di luar periode serangan, dapat mengurangi nilai TTFB dan meringankan sumber daya hosting. Untuk performa, dapat merujuk pada Panduan Mempercepat Laman Web.

Tentukan ambang batas pembatasan laju yang realistis

Pembatasan laju sangat efektif terutama pada endpoint yang mahal. Namun, jika ambang batas ditentukan secara acak, pengguna yang nyata dapat terblokir. Misalnya, seorang pengguna biasa dapat melakukan 5-15 pencarian per menit di halaman pencarian produk; 100 pencarian per menit adalah aneh. Di halaman login, 10 upaya gagal dalam lima menit dalam kebanyakan skenario sudah mencurigakan.

Contoh pendekatan: untuk /wp-login.php, berikan managed challenge pada IP yang mengirim lebih dari 10 permintaan dalam satu menit, dan blokir sementara IP yang mengirim lebih dari 50 permintaan dalam lima menit. Untuk endpoint API, ambang batas yang lebih rinci berdasarkan sesi pengguna, IP, token, dan metode harus dipilih.

Sembunyikan alamat IP asal dan batasi dengan firewall

Salah satu kesalahan paling kritis saat menggunakan Cloudflare adalah membiarkan alamat IP asal terpapar. Catatan DNS lama, subdomain yang berfungsi langsung dengan IP, layanan web yang bercampur dengan catatan email, atau konfigurasi yang terkompromi dapat menyebabkan penyerang mengakses server Anda dari luar Cloudflare.

Dari sisi server, membuka port 80 dan 443 hanya untuk rentang IP Cloudflare memberikan perlindungan yang kuat. Selain itu, port SSH, panel, basis data dan manajemen seharusnya tidak dibiarkan terbuka untuk internet; penggunaan pembatasan IP, kata sandi yang kuat, 2FA, dan jika memungkinkan, VPN merupakan praktik yang baik. Untuk keamanan hosting, dapat merujuk pada tetapan keselamatan cPanel dan Konfigurasi firewall VPS.

Poin perhatian khusus untuk Situs WordPress, WooCommerce, dan Korporat

Tidak semua situs web memiliki struktur lalu lintas yang sama. Sebuah situs blog, toko WooCommerce, dan panel SaaS dapat memberikan hasil yang berbeda saat menggunakan mod Under Attack Cloudflare. Oleh karena itu, jalur kritis harus ditentukan berdasarkan jenis situs.

Situs WordPress

File yang paling sering menjadi target di WordPress adalah jalur /wp-login.php dan /xmlrpc.php. Jika Anda tidak menggunakan XML-RPC, biasanya aman untuk memblokirnya. Pembatasan berdasarkan negara atau IP dapat diterapkan untuk panel admin. Selain itu, aturan Cloudflare tidak boleh bertentangan dengan plugin keamanan; terlalu banyak mekanisme tantangan sekaligus dapat membuat pengguna terjebak dalam siklus verifikasi.

Toko WooCommerce

Keranjang, pembayaran, dan halaman akun di WooCommerce memerlukan perhatian khusus. Karena halaman-halaman ini dinamis, tidak boleh diterapkan cache agresif. Pastikan bahwa callback atau webhook URL penyedia pembayaran berfungsi ketika mod Under Attack aktif. Jika perlu, rentang IP penyedia pembayaran harus dimasukkan dalam allowlist atau aturan khusus harus ditetapkan untuk endpoint terkait.

Situs Korporat dan yang Menggunakan API

Portal korporat, integrasi CRM, dan API aplikasi mobile mungkin tidak dapat menangani layar tantangan JavaScript. Dalam struktur seperti ini, lebih tepat untuk mengelola mod Under Attack secara terpisah dari subdomain API daripada menerapkannya ke seluruh domain. Misalnya, ketika mod Under Attack diaktifkan untuk www.example.com, pengaturan terkait keamanan berbasis token, pembatasan laju, dan allowlist dapat diterapkan untuk api.example.com.

Metrik yang Perlu Dipantau Setelah Mengaktifkan Mod Under Attack

Penting untuk memonitor secara numerik untuk menentukan apakah langkah keamanan berhasil. Hanya memastikan situs dapat diakses tidak cukup; tingkat kesalahan, beban server, dan perilaku pengguna nyata harus dinilai secara bersamaan.

• Cloudflare Security Events: Menunjukkan berapa banyak permintaan yang telah ditantang atau diblokir oleh aturan mana.
• Kode status HTTP: Perubahan dalam error 403, 429, 502, 503, dan 504 harus dipantau.
• Pemakaian CPU dan RAM server: Penurunan diharapkan setelah mod Under Attack.
• PHP-FPM dan koneksi MySQL: Menunjukkan relaksasi di tingkat aplikasi.
• Lebar pita dan jumlah permintaan: Rasio volume lalu lintas dibandingkan dengan permintaan yang difilter harus dilakukan.
• Konversi pengguna nyata: Pengiriman formulir, pesanan, login, dan langkah pembayaran harus diuji.

Misalnya, bahkan jika jumlah total permintaan tetap sama setelah mod Under Attack diaktifkan, jika permintaan yang mencapai asal berkurang sebesar 60%, ini menandakan bahwa lapisan Cloudflare menyerap sebagian besar beban. Namun, jika penggunaan CPU MySQL tetap tinggi, serangan mungkin memicu kueri dinamis yang spesifik; dalam kasus ini, log aplikasi perlu ditinjau.

Bagaimana Menutup Mod Under Attack Setelah Serangan Berakhir?

Ketika lalu lintas serangan kembali normal, meninggalkan mod Under Attack dalam keadaan aktif secara permanen tidak disarankan untuk banyak situs. Karena menunjukkan verifikasi tambahan kepada setiap pengunjung dapat mempengaruhi tingkat konversi, efisiensi pemindai, dan kepuasan pengguna. Proses penutupan juga harus dilakukan dengan hati-hati seperti saat mengaktifkannya.

Langkah-langkah Kembali ke Normal Dengan Aman

• Tunggu setidaknya 30-60 menit untuk memastikan tingkat lalu lintas kembali normal.
• Verifikasi di layar Cloudflare Security Events bahwa jumlah tantangan dan blokir berkurang.
• Sebelum menutup mod Under Attack, pastikan aturan WAF dan pembatasan laju yang ditargetkan aktif.
• Sesuaikan tingkat keamanan menjadi High atau Medium yang lebih seimbang.
• Uji situs dari perangkat berbeda dan pantau tingkat kesalahan 5xx.
• Pantau logs selama 24 jam berikutnya untuk mengecek jika serangan kembali terjadi.

Sebagai praktik yang baik, sebuah laporan insiden setelah serangan harus disusun. Dalam laporan tersebut, jam mulai serangan, URL target, jumlah permintaan paling tinggi, tindakan yang diambil, aturan efektif, dan perbaikan permanen harus dicatat. Dokumen ini dapat secara signifikan memperpendek waktu respons untuk insiden berikutnya.

Kesalahan Umum dan Hal yang Harus Dihindari

Keputusan cepat diperlukan saat DDoS terjadi; namun, pengaturan yang salah dapat memblokir pengguna nyata. Kesalahan berikut ini sering terjadi terutama di bawah tekanan tinggi.

• Berpikir bahwa mod Under Attack dapat memberikan perlindungan tanpa menjadikan catatan DNS proxied.
• Membiarkan alamat IP asal terekspos dan tidak memblokir akses di luar rentang IP Cloudflare dengan firewall.
• Menerapkan tantangan pada seluruh domain sebelum menguji API, webhook, dan alamat callback pembayaran.
• Menulis aturan blokir WAF yang terlalu luas sehingga memblokir pelanggan nyata.
• Menerapkan cache agresif pada halaman keranjang, pembayaran, atau panel pengguna yang tidak boleh dicache.
• Meninggalkan mod terbuka selama berminggu-minggu setelah serangan berakhir.
• Memberi keputusan hanya berdasarkan tampilan layar Cloudflare tanpa memeriksa logs server.

Terutama di situs e-commerce, memblokir callback pembayaran dapat menyebabkan kerugian pendapatan yang serius. Oleh karena itu, saat menulis aturan keamanan, lebih baik untuk menguji dengan log atau managed challenge sebelum melakukan pemblokiran. Setelah dampak aturan terlihat, langkah yang lebih ketat dapat diambil.

Bagaimana Merencanakan Pertahanan yang Lebih Tangguh di Infrastruktur Hostragons?

Cloudflare memberikan lapisan depan yang kuat; tetapi untuk pertahanan DDoS yang efektif tidak hanya berakhir di sisi CDN. Infrastruktur hosting, optimisasi perangkat lunak, konfigurasi SSL, manajemen DNS, dan strategi pencadangan harus dipertimbangkan bersama-sama. Pendekatan dasar untuk situs yang dihosting di Hostragons haruslah: Cloudflare menyaring lalu lintas, lapisan hosting hanya berhadapan dengan lalu lintas bersih, dan aplikasi dioptimalkan agar tidak menghasilkan beban basis data yang tidak perlu.

Sebelum meluncurkan proyek baru, penting untuk mengelola nama domain dengan catatan DNS yang benar, memastikan pemasangan sertifikat SSL tanpa masalah, dan memilih sumber daya server web yang sesuai dengan profil lalu lintas Anda. Pada titik ini, tautan Semakan domain dan pendaftaran nama domain, Pakej Penyimpanan Web, penyelesaian hosting korporat, dan Sijil SSL percuma dapat membantu pengguna.

Untuk proyek dengan lalu lintas tinggi atau risiko serangan yang tinggi, pertimbangkan untuk menggunakan VPS atau server yang terkelola daripada hosting bersama yang standar. Dengan demikian, pengaturan firewall, server web, PHP-FPM, Redis, caching objek, dan basis data dapat dikonfigurasi dengan lebih fleksibel. Namun, terlepas dari infrastruktur yang dipilih, mod Under Attack Cloudflare hanya harus diposisikan sebagai alat darurat; arsitektur keamanan permanen harus didukung dengan WAF, analisis log, dan pembaruan rutin.

Daftar Kontrol Cepat: 15 Menit Pertama Saat DDoS

Waktu sangat penting saat serangan terjadi. Daftar di bawah ini merangkum apa yang bisa dilakukan oleh tim teknis atau pemilik situs dalam 15 menit pertama.

• Masuk ke panel Cloudflare dan pilih nama domain yang benar.
• Periksa bahwa catatan DNS dalam keadaan cloud oranye yaitu proxied.
• Aktifkan mod Under Attack.
• Uji halaman utama, login, keranjang, pembayaran, dan endpoint API.
• Tentukan URL target serangan dari layar Cloudflare Security Events.
• Tambahkan aturan WAF atau pembatasan laju khusus pada jalur yang paling banyak diserang.
• Periksa status CPU, RAM, PHP-FPM, dan MySQL server.
• Uji akses langsung ke alamat IP asal.
• Periksa apakah diperlukan allowlist untuk penyedia pembayaran, webhook, dan integrasi kritis lainnya.
• Catat semua tindakan dengan timestamp.

Jika daftar ini dilakukan secara reguler, kepanikan saat serangan nyata dapat berkurang dan kualitas intervensi meningkat. Untuk situs besar, disarankan agar proses ini didokumentasikan sebagai rencana tanggap insiden.

FAQ

Apakah mod Under Attack Cloudflare melindungi situs sepenuhnya?

Tidak. Mod Under Attack Cloudflare terutama efektif untuk mengurangi lalu lintas bot dan serangan flood di tingkat HTTP/HTTPS; tetapi tidak memberikan perlindungan penuh jika digunakan sendirian. Catatan DNS harus dalam keadaan proxied, alamat IP asal harus disembunyikan, dan harus digunakan bersama dengan aturan WAF, pembatasan laju, serta pengaturan firewall server.

Apakah mod Under Attack dapat merusak SEO?

Penggunaan singkat umumnya tidak menyebabkan kerusakan SEO yang serius. Namun, jika mod tetap aktif untuk waktu yang lama, efisiensi pemindaian mesin pencari dan pengalaman pengguna dapat terpengaruh. Oleh karena itu, setelah serangan selesai, disarankan untuk mematikan mod dan melanjutkan dengan aturan keamanan yang lebih terarah.

Berapa lama mod Under Attack harus tetap aktif?

Mod dapat aktif hingga intensitas serangan menurun; dalam praktiknya, disarankan untuk memantau setidaknya 30-60 menit setelah lalu lintas kembali normal dan kemudian menutupnya secara bertahap. Pastikan aturan seperti WAF dan pembatasan laju tersedia sebelum menutup mod.

Apakah mod Under Attack mempengaruhi API atau sistem pembayaran?

Ya, dapat memengaruhi. Karena beberapa klien API, layanan webhook, dan sistem callback pembayaran mungkin tidak dapat menyelesaikan verifikasi keamanan berbasis browser. Oleh karena itu, endpoint kritis harus diuji dan jika perlu, allowlist atau aturan Cloudflare khusus harus didefinisikan.

Apakah saat menggunakan Cloudflare diperlukan tindakan keamanan lain di sisi hosting?

Ya. Cloudflare memberikan perlindungan yang kuat di tingkat depan; namun, alamat IP server asal harus disembunyikan, firewall hanya harus mengizinkan lalu lintas yang diperlukan, perangkat lunak harus senantiasa diperbarui, dan konfigurasi cache harus dilakukan dengan benar. Infrastruktur hosting yang aman adalah bagian penting dari ketahanan DDoS.

Kesimpulan

Mod Under Attack Cloudflare adalah alat darurat yang efektif untuk memberikan napas cepat bagi situs yang sedang mengalami serangan DDoS. Ketika diaktifkan dengan pengaturan proxy DNS yang benar, mod ini mengurangi lalu lintas bot, menurunkan beban server, dan meningkatkan kemungkinan pengguna nyata untuk mengakses situs. Untuk hasil terbaik, mod ini harus didukung oleh aturan WAF, pembatasan laju, optimisasi cache, dan keamanan firewall asal.

Jika Anda ingin memastikan situs web Anda berfungsi dengan lebih tahan terhadap serangan, secara rutin tinjau infrastruktur Anda, manajemen DNS, dan konfigurasi SSL. Menjelajahi solusi hosting, domain, dan SSL dari Hostragons dapat memberikan dasar yang lebih aman dan berkelanjutan untuk situs Anda.