CDN:Atasi masalah kontrol akses

• Penyebab: Otentikasi URL diaktifkan di CDN, tetapi URL yang sebenarnya diakses tidak membawa parameter penandatanganan.

• Solusi: Jika Anda membutuhkan fitur otentikasi, ikuti Konfigurasikan Penandatanganan URL untuk menghasilkan dan membawa parameter penandatanganan yang benar untuk permintaan. Jika Anda tidak membutuhkan fitur otentikasi, login ke Konsol CDN dan nonaktifkan otentikasi URL untuk nama domain tersebut.

• Penyebab: URL membawa parameter penandatanganan, tetapi timestamp dalam parameter tersebut telah kedaluwarsa. Periode validitas URL yang ditandatangani ditentukan oleh durasi validitas yang Anda konfigurasikan. Penandatanganan menjadi tidak valid setelah durasi validitas berakhir.

• Solusi: Lihat Konfigurasikan Penandatanganan URL untuk membuat ulang URL yang ditandatangani. Jika halaman bisnis Anda membutuhkan waktu lama untuk dimuat, Anda dapat memperpanjang durasi validitas penandatanganan secara tepat.

• Penyebab: Nilai MD5 dari parameter penandatanganan dihitung secara salah. Hal ini biasanya disebabkan oleh ketidaksesuaian antara algoritma signature kode penandatanganan Anda dan persyaratan metode otentikasi CDN.

• Solusi: Kami menyarankan Anda terlebih dahulu menggunakan Pembuat URL di Konsol CDN untuk menghasilkan URL yang ditandatangani, bandingkan field demi field dengan URL yang dihasilkan oleh kode penandatanganan Anda sendiri, lalu identifikasi perbedaan signature-nya. Untuk algoritma signature setiap metode otentikasi, lihat Penandatanganan Tipe A. Untuk contoh kode penandatanganan, lihat Contoh penandatanganan URL.

• Penyebab: Referer yang dibawa oleh permintaan tidak ada di daftar putih, atau sesuai dengan daftar hitam. Hal ini sering terjadi ketika daftar putih tidak mencantumkan nama domain situs yang sebenarnya mereferensikan resource tersebut.

• Diagnosis: Di Konsol CDN, periksa konfigurasi Daftar hitam/putih Referer untuk nama domain yang dipercepat dan tentukan apakah Referer dari permintaan yang diblokir sesuai dengan aturan tersebut. Anda juga dapat mengunduh log CDN untuk menemukan header Referer dari catatan akses yang sesuai.

• Solusi: Tambahkan Referer yang diblokir ke daftar putih (atau hapus dari daftar hitam). Untuk metode konfigurasinya, lihat Konfigurasikan Daftar hitam atau putih Referer.

• Penyebab: Permintaan dalam skenario berikut tidak membawa Referer (Referer kosong): mengakses URL resource langsung dari bilah alamat browser; membuat permintaan di aplikasi atau program client tanpa mengatur header Referer; halaman HTTPS mereferensikan resource HTTP, di mana browser tidak mengirim Referer berdasarkan Referrer-Policy default; halaman secara eksplisit mengatur Referrer-Policy: no-referrer; serta penggunaan alat command-line seperti curl atau wget, yang secara default tidak membawa Referer. Jika opsi Allow direct access to resource URLs from the browser address bar tidak dipilih dalam konfigurasi Daftar hitam/putih Referer, permintaan dengan Referer kosong akan diblokir.

• Solusi: Jika bisnis Anda perlu mengizinkan akses dengan Referer kosong, pilih Allow direct access to resource URLs from the browser address bar dalam konfigurasi Daftar hitam/putih Referer. Jika Anda sengaja memblokir permintaan Referer kosong untuk mencegah pencurian trafik, jangan izinkan akses tersebut, dan lihat Anomali trafik dan pencurian trafik berbahaya untuk mengonfigurasi kebijakan mitigasi yang lebih detail halus. Untuk metode konfigurasinya, lihat Konfigurasikan Daftar hitam atau putih Referer.

Setelah Anda mengonfigurasi Daftar hitam/putih IP, node CDN menolak permintaan dan mengembalikan error 403 jika alamat IP client sesuai dengan daftar hitam atau tidak ada di daftar putih. Header respons X-Tengine-Error: denied by IP ACL = blacklist menunjukkan bahwa alamat IP sesuai dengan daftar hitam IP, sedangkan X-Tengine-Error: denied by IP ACL = not in whitelist menunjukkan bahwa alamat IP tidak ada di daftar putih IP.

• Diagnosis: Pertama-tama konfirmasi alamat IP publik sebenarnya dari client (Anda dapat menanyakannya dengan menjalankan curl ifconfig.me atau curl myip.ipip.net). Jika permintaan melewati proxy atau load balancer, alamat IP client yang diperoleh CDN mungkin merupakan alamat IP proksi, bukan alamat IP end user, sehingga Anda perlu mengonfirmasi alamat IP client yang sebenarnya dikenali oleh node CDN. Di Konsol CDN, periksa konfigurasi Daftar hitam/putih IP untuk nama domain tersebut dan pastikan apakah alamat IP tersebut sesuai dengan aturan.

• Solusi: Pertama-tama pastikan apakah pemblokiran tersebut disengaja. Jika Anda perlu mengizinkan alamat IP tersebut, pada halaman Domain Names di Konsol CDN, klik Manage untuk nama domain target. Di panel navigasi sebelah kiri, klik Access Control, lalu sesuaikan aturan pada bagian IP Blacklist/Whitelist. Untuk metode konfigurasinya, lihat Konfigurasikan Daftar hitam atau putih IP. Jika alamat IP dalam daftar hitam masih dapat mengakses resource, lihat Mengapa alamat IP dalam daftar hitam masih dapat mengakses resource saya?.

Setelah Anda mengonfigurasi Daftar hitam/putih UA, node CDN menolak permintaan dan mengembalikan error 403 jika User-Agent dalam header permintaan sesuai dengan daftar hitam UA atau tidak ada di daftar putih UA. Header respons X-Tengine-Error: black ua menunjukkan bahwa User-Agent sesuai dengan daftar hitam UA, sedangkan X-Tengine-Error: not in white ua menunjukkan bahwa User-Agent tidak ada di daftar putih UA.

• Diagnosis: Jalankan curl -v <URL resource yang dipercepat> untuk memeriksa nilai User-Agent yang sebenarnya dikirim oleh permintaan, atau periksa header permintaan di developer tools browser. Di Konsol CDN, periksa aturan Daftar hitam/putih UA untuk nama domain tersebut dan pastikan apakah User-Agent tersebut sesuai. Perhatikan bahwa Daftar hitam/putih UA mendukung pencocokan wildcard, jadi periksa apakah User-Agent tersebut tidak sengaja sesuai dengan aturan wildcard.

• Solusi: Pertama-tama pastikan apakah pemblokiran tersebut disengaja. Jika Anda perlu mengizinkan permintaan tersebut, pada halaman Domain Names di Konsol CDN, klik Manage untuk nama domain target. Di panel navigasi sebelah kiri, klik Access Control, lalu sesuaikan aturan pada tab UA Blacklist/Whitelist. Untuk metode konfigurasinya, lihat Konfigurasikan Daftar hitam atau putih User-Agent.

Setelah otentikasi jarak jauh diaktifkan, node CDN meneruskan permintaan ke server otentikasi yang Anda tentukan untuk verifikasi. Permintaan diblokir dan error 403 dikembalikan dalam dua kasus berikut:

• Server otentikasi mengembalikan Authentication Failure Status Code yang ditentukan dalam konfigurasi (misalnya, 403). CDN menentukan bahwa otentikasi gagal dan menolak permintaan tersebut.

• Otentikasi timeout (interaksi antara node CDN dan server otentikasi tidak selesai dalam periode timeout yang dikonfigurasi), dan Action After Authentication Timeout diatur ke Reject.

• Diagnosis: Jika error 403 tidak termasuk dalam kategori otentikasi URL, Referer, IP ACL, atau UA ACL yang dijelaskan di atas (nilai X-Tengine-Error pada header respons tidak sesuai dengan salah satunya), dan otentikasi jarak jauh diaktifkan untuk nama domain tersebut, Anda harus melakukan troubleshooting otentikasi jarak jauh terlebih dahulu. Di Konsol CDN, periksa Authentication Failure Status Code, Authentication Timeout Settings, dan Action After Authentication Timeout dalam konfigurasi otentikasi jarak jauh untuk nama domain tersebut, lalu periksa log akses server otentikasi untuk mengonfirmasi kode status yang sebenarnya dikembalikan oleh server otentikasi dan apakah terjadi timeout.

• Solusi: Jika pemblokiran tersebut tidak disengaja, sesuaikan logika verifikasi server otentikasi atau konfigurasi kode status kegagalan otentikasi. Jika otentikasi sering mengalami timeout, lakukan troubleshooting performa server otentikasi (periode timeout dapat diatur hingga maksimal 3.000 milidetik), atau atur Action After Authentication Timeout ke Allow berdasarkan penilaian risiko bisnis Anda. Untuk metode konfigurasinya, lihat Konfigurasikan otentikasi jarak jauh.

Error 403 dikembalikan oleh server origin OSS. Terdapat tiga pesan error umum:

• Error You have no right to access this object because of bucket acl: Bucket memiliki izin baca privat, dan permintaan pengambilan asal CDN tidak lolos otentikasi OSS. Kami menyarankan Anda mengaktifkan otorisasi pengambilan asal untuk bucket OSS pribadi di Konsol CDN. Untuk metode konfigurasinya, lihat Konfigurasikan pengambilan asal dari bucket OSS pribadi.

• Error You are denied by bucket referer policy: Daftar hitam/putih Referer dikonfigurasi untuk bucket tersebut, dan Referer dari permintaan pengambilan asal CDN tidak sesuai dengan aturan bucket tersebut. Periksa pengaturan Daftar hitam/putih Referer bucket di Konsol OSS dan izinkan akses dari permintaan pengambilan asal CDN (misalnya, izinkan Referer kosong, atau tambahkan Referer yang dibawa oleh permintaan pengambilan asal CDN ke daftar putih).

• Error You are forbidden to list buckets: Pengambilan asal bucket pribadi CDN dan hosting situs web statis OSS diaktifkan secara bersamaan, sehingga kedua fitur tersebut saling bertentangan. Nonaktifkan salah satu fitur: nonaktifkan otorisasi pengambilan asal untuk bucket CDN pribadi, atau nonaktifkan fitur hosting situs web statis OSS. Untuk penjelasan konfliknya, lihat Apa yang harus saya lakukan jika muncul error setelah saya mengaktifkan akses ke bucket OSS pribadi dan hosting situs web statis?.

• Penyebab: Saat CDN melakukan pengambilan asal, host asal menentukan situs mana pada alamat IP server origin yang diakses oleh permintaan pengambilan asal. Jika host asal dikonfigurasi secara salah, permintaan tersebut mungkin dicocokkan ke situs yang tidak menyediakan layanan atau memiliki batasan akses di server origin, sehingga server origin mengembalikan error 403. Selain itu, aturan firewall, kebijakan WAF, atau kontrol akses tingkat aplikasi dari server origin itu sendiri juga dapat memblokir permintaan pengambilan asal CDN.

• Diagnosis: Petakan nama domain yang dipercepat ke alamat IP server origin dengan mengikat file hosts, akses langsung server origin, dan verifikasi apakah server tersebut juga mengembalikan error 403. Periksa konfigurasi host asal di Konsol CDN dan pastikan bahwa host tersebut mengarah ke situs yang benar-benar menyediakan layanan di server origin.

• Solusi: Perbaiki konfigurasi host asal untuk memastikan bahwa host tersebut mengarah ke situs yang benar-benar menyediakan layanan di server origin. Jika firewall atau WAF server origin memblokir permintaan pengambilan asal CDN, tambahkan rentang alamat IP pengambilan asal CDN ke daftar putih server origin. Untuk metode troubleshooting umum di sisi server origin, lihat Panduan troubleshooting pengambilan asal.

Lakukan konfirmasi awal dengan cara berikut:

• Login ke Konsol CDN dan periksa tren bandwidth dan trafik nama domain di Monitoring Reports. Periksa apakah terjadi lonjakan abnormal di luar jam operasional bisnis.

• Unduh log akses CDN untuk nama domain tersebut, analisis distribusi alamat IP, distribusi Referer, dan distribusi User-Agent dari sumber akses, lalu identifikasi rentang alamat IP dengan frekuensi sangat tinggi, sumber Referer abnormal, atau User-Agent mirip crawler.

• Periksa di CloudMonitor apakah peringatan bandwidth atau trafik telah dipicu.

Kami menyarankan Anda mengambil langkah perlindungan sejak dini: konfigurasikan aturan alarm untuk bandwidth puncak dan trafik downstream melalui fitur pengaturan alarm agar Anda segera diberi tahu ketika ambang batas tercapai; dan konfigurasikan kebijakan kontrol akses seperti daftar hitam IP, daftar hitam Referer, daftar hitam UA, atau otentikasi URL berdasarkan karakteristik serangan untuk memblokir serangan tersebut. Untuk solusi pemblokiran terhadap skenario pencurian trafik, lihat Cegah penyalahgunaan trafik.

Jika nama domain telah dipindahkan ke sandbox, tunggu hingga trafik serangan mereda, lalu kirim tiket untuk meminta penghapusan dari sandbox. Untuk menghindari pemicuan ulang, kami menyarankan Anda mengonfigurasi kebijakan kontrol akses sebelum penghapusan dilakukan.