403 Kesalahan terlarang saat mengerjakan situs web Anda? Firewall, firewall, firewall

Kesalahan terlarang 403 paling sering terjadi saat sistem keamanan kami melindungi situs Anda. Lebih sering daripada tidak, firewall aplikasi web kami (disebut Mod Security atau modsec) melindungi situs web Anda dari upaya peretasan otomatis.

Namun, dalam beberapa kasus, tindakan sah dapat salah diidentifikasi sebagai serangan dan tindakan Anda akan diblokir. Ini disebut positif palsu. Berikut beberapa skenario umum saat hal ini terjadi:

• Menggunakan pembuat situs web apa pun, perubahan Anda mungkin gagal disimpan
• Jika Anda menggunakan tema/pembangun Divi untuk WordPress, ini akan menunjukkan sesuatu seperti “Kesalahan saat menyimpan halaman” lalu memberikan daftar penyebab potensial.
• Saat menambahkan kode javascript atau PHP melalui panel admin situs web Anda (dan bukan Pengelola File Plesk atau FTP).

Jika Anda mendapatkan kesalahan terlarang 403 yang tidak cocok dengan salah satu tindakan di atas, Anda mungkin ingin terlebih dahulu membaca panduan umum kami untuk memecahkan masalah kesalahan 403.

Tampaknya hal ini dapat terjadi secara tiba-tiba karena aturan firewall kami diperbarui setiap minggu; berpotensi menambahkan aturan baru setiap minggu yang dapat memengaruhi pengoperasian situs Anda. Perhatikan bahwa aturan kemungkinan besar akan memengaruhi pengiriman data ke server, seperti saat mengirimkan formulir atau memperbarui data di backend situs Anda.

Cara Menemukan &Menafsirkan Log Firewall

Langkah pertama adalah memeriksa log server untuk mencari tahu mengapa kesalahan tersebut terjadi. Lihat panduan kami tentang cara menggunakan pengelola file Plesk untuk menganalisis log situs web Anda.

Karena firewall aplikasi web kami membantu memblokir serangan umum, Anda mungkin melihat banyak entri ModSecurity di log . Penting untuk mengidentifikasi entri log yang secara langsung sesuai dengan tindakan yang Anda ambil, jika tidak, Anda akan berakhir dengan melemahkan firewall dan tidak menyelesaikan masalah pada saat yang bersamaan.

Kesalahan terkait firewall akan terlihat seperti ini:

ModSecurity: Access denied with code 403 (phase 2). 
Pattern match "(asfunction|data|javascript|livescript|mocha|vbscript):" at ARGS:input_5_7_data_canvas. 
[file "/etc/httpd/conf/modsecurity.d/rules/comodo/07_XSS_XSS.conf"] [line "227"] 
[id "212770"] [rev "4"] 
[msg "COMODO WAF: XSS Attack Detected||customerdomain.tld|F|2"] 
[data "Matched Data: data: found within ARGS:input_5_7_data_canvas: data:image/png;base64,{{{{snipped}}}}] 
[severity "CRITICAL"] [hostname "customerdomain.tld"] 
[uri "/specific_uri_requested/"] 

Contoh entri log kami di atas adalah false-positive yang terjadi saat mengirimkan formulir Gravity Forms dengan lampiran gambar.

Kami telah memotong banyak gobbledygook dan menggantinya dengan {{{{snipped}}}} agar lebih mudah dibaca. Kami juga telah membuat bagian tertentu menjadi tebal untuk menunjukkan apa yang paling relevan bagi kami.

Membaca bagian yang dicetak tebal secara berurutan, kesalahan ini menyatakan bahwa firewall menemukan:

• Akses ditolak dengan kesalahan terlarang (kode 403 ) (Catatan:jika Anda tidak melihat 'kode 403' atau 'Akses ditolak', maka entri log ModSecurity yang Anda lihat tidak relevan:lanjutkan ke yang berikutnya. Beberapa entri untuk debugging atau informasi umum, bukan semuanya untuk pemblokiran.)
• Semacam skrip (javascript, livescript , dll)
• Menggunakan ID Aturan 212770
• Itu dianggap sebagai Serangan XSS (Skrip Lintas Situs)
• Saat mengirimkan gambar dalam format base64 yang disandikan (data:image/png;base64 )
• Dengan keseriusan “PENTING” (Perhatikan jika Anda melihat tingkat keparahan DEBUG atau WARNING, kemungkinan besar itu bukan penyebab kesalahan 403 yang terlihat)
• Di URI /specific_uri_requested/

Firewall menjadi sangat gugup tentang itu! Dapat dimengerti:ini adalah skrip acak dengan data yang tampak aneh…

Karena kami mengetahui bahwa masalah terjadi saat pengguna yang sah mengirimkan Formulir Gravitasi, dan memang ada gambar yang terlibat, ini mungkin kasus penggunaan yang sah dan oleh karena itu kesalahannya adalah false positive.

Silakan buka tiket jika Anda membutuhkan bantuan untuk menerjemahkan! Pastikan untuk menyertakan entri log agar kami dapat menganalisisnya dengan cepat untuk Anda.

Di bawah ini Anda akan menemukan dua cara untuk mengatasi kesalahan ini:1) menonaktifkan firewall (hanya disarankan dalam kasus tertentu), dan 2) mengecualikan aturan tertentu yang menghasilkan false positive.

Solusi 1 (sementara):Berkembang? Nonaktifkan Firewall

Jika saat ini Anda sedang mengembangkan situs, sebaiknya nonaktifkan firewall seluruhnya, karena Anda mungkin akan menemui sejumlah hambatan saat mengirimkan kode ke server melalui HTTP (yaitu:menyimpan perubahan CSS) di dalam WordPress.

Harap ingat untuk mengaktifkan kembali firewall setelah Anda selesai mengedit situs, jika tidak, situs Anda tidak akan terlindungi dari sejumlah besar serangan umum.

Berikut cara menonaktifkannya:

• Di Plesk, kembali ke “Situs Web dan Domain” atau “Domain” dan klik domain.
• Klik “Web Application Firewall”.
• Di bawah “Mode firewall aplikasi web” Pilih “Mati”.
  Catatan:jika Anda memilih "Hanya Deteksi", firewall level TCP kami akan tetap mengambil entri log dan menerapkan larangan sementara. Nonaktif adalah yang terbaik selama pengembangan.
• Klik Oke atau Terapkan untuk menyimpan.

Setelah selesai mengembangkan, aktifkan kembali firewall dengan mengikuti langkah yang sama, tetapi pilih "Aktif" daripada "Nonaktif".

Solusi 2 (permanen):Mengecualikan Aturan ModSec

Jika pengguna situs Anda akan melakukan tindakan yang sama seperti yang Anda lakukan yang memicu 403 secara rutin, maka menonaktifkan firewall sepenuhnya tidak akan berhasil!

Sebagai gantinya, mari lanjutkan dan kecualikan aturan ini dari firewall untuk domain. Dalam contoh kami di atas, kami mengidentifikasi aturan keamanan ID 212770, tetapi Anda pasti akan berbeda. Pindai melalui entri log hingga Anda menemukan ID, akan terlihat seperti ini:[id “212770”] lalu…

• Di Plesk, kembali ke “Situs Web dan Domain”
• Klik “Web Application Firewall”.
• Di bagian “Nonaktifkan aturan keamanan”, masukkan nomor ID yang Anda temukan di log (biasanya satu per baris, jika Anda memiliki lebih dari satu).
• Klik Oke atau Terapkan untuk menyimpan.

Sekarang coba lakukan tindakan yang menyebabkan masalah sebelumnya.

Jika masalah BELUM teratasi, dan Anda masih mendapatkan error 403, kemungkinan tindakan tersebut telah memicu beberapa aturan firewall. Ulangi proses di atas hingga Anda menemukan dan mengecualikan semua ID aturan yang menyebabkan masalah. Perhatikan bahwa jika ada beberapa ID aturan yang menyebabkan kesalahan ini, mereka cenderung sangat mirip, jadi perhatikan baik-baik saat memeriksa entri log terbaru untuk memastikan yang Anda lihat sedikit berbeda dari yang telah Anda kecualikan.

Pengecualian paling banyak yang harus kami kecualikan dalam sekali duduk adalah 5, jadi ada kemungkinan besar Anda akan memperbaikinya hanya dalam 2 atau 3 pengecualian.

Pemecahan masalah

Jika Anda mengecualikan banyak aturan, Anda akan menemui kesalahan seperti ini yang tidak memiliki ID terkait:

ModSecurity: Output filter: Response body too large (over limit of 524288, total not specified).

Itu berarti Anda harus meningkatkan batas tersebut. Jika Anda memiliki akses admin ke Plesk, Anda dapat memasukkan yang berikut di bawah Alat &Pengaturan> ModSecurity> tab Pengaturan> Arahan khusus:

SecResponseBodyLimit 546870912
SecRequestBodyInMemoryLimit 546870912

Jika Anda tidak memiliki akses admin ke Plesk dan Anda dihosting bersama kami, buka tiket dan kami akan mengurusnya untuk Anda!