FAQ onboarding - Web Application Firewall - Alibaba Cloud Documentation Center

Artikel ini mencantumkan isu umum yang mungkin Anda temui saat melakukan onboarding website ke Web Application Firewall (WAF) 3.0.

Ikhtisar

Pertanyaan mengenai kemampuan dan konfigurasi sebelum onboarding
Isu yang mungkin Anda temui selama proses onboarding
Isu yang mungkin Anda temui setelah onboarding

Apa perbedaan antara alamat IP asal dan alamat IP back-to-origin di WAF?

IP back-to-origin WAF: Rentang IP yang digunakan WAF untuk meneruskan traffic yang dilindungi ke server asal Anda. IP-IP ini dialokasikan oleh Alibaba Cloud dan mengidentifikasi WAF sebagai sumber saat membuat permintaan ke server asal Anda.
- Rentang IP back-to-origin biasanya merupakan sekumpulan alamat IP tetap.
- Dari perspektif server asal, semua permintaan klien dicegat dan diteruskan oleh WAF. IP klien yang sebenarnya dicatat dalam field header HTTP seperti X-Forwarded-For atau header kustom.
IP asal: Alamat IP publik dari server backend yang benar-benar menjalankan bisnis Anda, atau alamat IP yang di-resolve dari domain Anda. Ini adalah tujuan yang akhirnya menerima permintaan dan mengembalikan respons saat pengguna mengakses website.
- IP asal dapat berupa satu alamat IP atau beberapa alamat IP (mendukung load balancing).
- IP asal adalah alamat layanan aktual website Anda, yang mungkin diterapkan di Alibaba Cloud ECS, SLB, OSS, atau penyedia cloud lainnya.

Dapatkah domain yang sama menggunakan onboarding produk cloud dan onboarding CNAME secara bersamaan?

Tidak disarankan. Setiap domain hanya dapat menggunakan satu mode onboarding—baik onboarding produk cloud maupun onboarding CNAME. Melakukan onboarding domain yang sama dua kali menyebabkan konflik penerusan dan menonaktifkan perlindungan. Jika Anda perlu mengganti domain yang sudah dilindungi oleh WAF melalui onboarding CNAME ke mode onboarding produk cloud, Anda harus terlebih dahulu menghapus konfigurasi onboarding CNAME untuk domain tersebut, lalu melakukan onboarding ulang dalam mode produk cloud.

Apakah WAF melindungi beberapa IP server asal di bawah satu domain?

Ya. Anda dapat mengonfigurasi hingga 20 alamat IP asal untuk satu domain WAF.

Apakah WAF melakukan pemeriksaan kesehatan pada server asal?

WAF mengaktifkan pemeriksaan kesehatan secara default. WAF memeriksa aksesibilitas semua IP asal. Jika suatu IP asal menjadi tidak responsif, WAF meneruskan permintaan ke IP asal lain yang sehat.

Ketika suatu IP asal menjadi tidak responsif, WAF secara otomatis menetapkan periode diam untuk IP tersebut. Setelah periode diam berakhir, permintaan baru mungkin tetap diteruskan ke IP tersebut untuk pengujian.

Dapatkah IP eksklusif di WAF meredam serangan DDoS?

IP eksklusif mencegah situasi di mana serangan DDoS volume besar pada satu domain membuat semua domain lain yang di-onboard menjadi tidak dapat diakses. Untuk informasi lebih lanjut, lihat Manfaat alamat IP eksklusif.

Dapatkah WAF diintegrasikan dengan CDN atau Anti-DDoS Proxy?

WAF sepenuhnya kompatibel dengan layanan CDN dan Anti-DDoS Proxy. Saat digunakan bersama, cukup konfigurasikan alamat CNAME WAF sebagai origin untuk Anti-DDoS Proxy atau CDN Anda. Hal ini memungkinkan traffic diteruskan melalui Anti-DDoS Proxy atau CDN ke WAF, lalu melalui WAF ke server asal, sehingga memberikan keamanan komprehensif bagi origin Anda. Untuk informasi lebih lanjut, lihat Lindungi website Anda dengan Anti-DDoS Pro/Premium dan WAF dan Lindungi domain yang dipercepat CDN dengan WAF.

Apakah WAF mendukung penggunaan lintas akun untuk arsitektur CDN + Anti-DDoS Proxy + WAF?

Ya. Anda dapat menggunakan CDN, Anti-DDoS Proxy, dan WAF di berbagai akun Alibaba Cloud yang berbeda untuk membangun arsitektur keamanan terhadap serangan DDoS dan serangan aplikasi web.

Bagaimana WAF memastikan keamanan sertifikat dan kunci privat yang diunggah? Apakah WAF mendekripsi traffic HTTPS dan mencatat konten permintaan?

Saat melindungi traffic HTTPS, Alibaba Cloud WAF mengharuskan Anda mengunggah Sertifikat SSL dan kunci privat yang sesuai untuk mendekripsi traffic HTTPS dan mendeteksi signature serangan. Kami menggunakan Key Server khusus untuk menyimpan dan mengelola sertifikat serta kunci. Key Server ini dibangun di atas Alibaba Cloud Key Management Service (KMS), memastikan keamanan data, integritas, dan ketersediaan sertifikat serta kunci Anda sesuai dengan persyaratan regulasi dan perlindungan terklasifikasi. Untuk detail tentang KMS, lihat Apa itu Key Management Service?.

WAF menggunakan Sertifikat SSL dan kunci privat yang Anda unggah untuk mendekripsi traffic HTTPS hanya demi deteksi real-time. Kami hanya mencatat bagian permintaan yang mengandung signature serangan (muatan) untuk pelaporan serangan dan analisis statistik. Kami tidak mencatat konten permintaan atau respons lengkap tanpa otorisasi Anda.

Alibaba Cloud WAF telah memperoleh berbagai sertifikasi otoritatif internasional, termasuk ISO 9001, ISO 20000, ISO 22301, ISO 27001, ISO 27017, ISO 27018, ISO 27701, ISO 29151, BS 10012, CSA STAR, Perlindungan Terklasifikasi Level 3, SOC 1/2/3, C5, Keuangan Hong Kong, OSPAR, dan PCI DSS. Sebagai produk standar Alibaba Cloud, WAF memiliki kualifikasi kepatuhan keamanan yang sama dengan platform Alibaba Cloud di tingkat platform cloud. Untuk detailnya, lihat Alibaba Cloud Trust Center.

Website saya dilindungi oleh WAF, tetapi tidak muncul dalam daftar domain

Pendaftaran ICP domain Anda mungkin telah kedaluwarsa, sehingga tidak memenuhi persyaratan onboarding, dan WAF secara otomatis menghapusnya. Anda harus menyelesaikan pendaftaran ICP untuk domain tersebut dan melakukan onboarding ulang ke WAF. Untuk informasi tentang pendaftaran ICP Alibaba Cloud, lihat Proses pendaftaran ICP.

Penting

Sebelum melakukan onboarding website Anda ke instans WAF di Tiongkok daratan, Anda harus memastikan domain tersebut memiliki pendaftaran ICP yang valid. Untuk mematuhi undang-undang dan peraturan yang berlaku, instans WAF di Tiongkok daratan secara berkala membersihkan domain dengan pendaftaran ICP yang kedaluwarsa.

Bagaimana WAF memperoleh IP sumber klien dan mencatat IP klien melalui header kustom?

Memperoleh IP sumber klien dari header kustom: Jika bisnis website Anda memiliki layanan proxy Lapisan 7 lain (seperti Anti-DDoS Proxy atau CDN) sebelum WAF, untuk mencegah penyerang memalsukan field XFF guna menghindari aturan deteksi WAF dan meningkatkan keamanan bisnis, Anda dapat menggunakan header kustom untuk membawa IP klien. Tempatkan IP sumber klien dalam field header kustom (misalnya, X-Client-IP atau X-Real-IP), lalu konfigurasikan WAF untuk membaca dari field header tersebut. WAF menggunakan nilai dari field header yang ditentukan sebagai IP sumber klien. Jika Anda mengonfigurasi beberapa field header, WAF akan mencoba membaca IP klien dari field-field tersebut secara berurutan.

Mencatat IP klien dalam header kustom: Saat menambahkan website ke WAF, aktifkan penandaan traffic sehingga WAF menulis IP klien ke dalam header kustom dalam permintaan klien. Server backend kemudian dapat membaca IP klien dari field header yang ditentukan dalam permintaan back-to-origin. Ini berlaku untuk skenario di mana server backend perlu memperoleh IP klien dari header kustom tertentu untuk analisis bisnis.

Apakah WAF mendukung onboarding untuk protokol TCP Lapisan 4?

WAF mendukung pengaktifan perlindungan WAF untuk traffic protokol HTTP dan HTTPS yang didengarkan oleh port CLB Lapisan 4 (TCP) dan instans ECS. WAF tidak mendukung penerusan dan perlindungan traffic pada port yang menggunakan protokol non-HTTP/HTTPS lainnya.

Sebagai firewall aplikasi web, WAF terutama melindungi traffic web, yaitu traffic HTTP dan HTTPS. Oleh karena itu, ketika traffic yang dipantau oleh port CLB Lapisan 4 (TCP) atau instans ECS merupakan traffic web, WAF dapat memberikan perlindungan penerusan. Namun, jika instans produk cloud Lapisan 4 membawa traffic protokol lapisan aplikasi lain (seperti FTP, SMTP, dll.), WAF tidak dapat meneruskan traffic tersebut.

Bagaimana cara melakukan ekspor batch daftar informasi domain yang telah di-onboard melalui CNAME?

Anda dapat memanggil API DescribeInstance untuk memperoleh ID instans WAF Anda, lalu memanggil API DescribeDomains untuk mengkueri daftar semua domain yang telah di-onboard melalui CNAME.

Selama onboarding CNAME, bagaimana WAF melakukan load balancing terhadap origin berbasis domain (seperti CNAME)?

Dalam mode onboarding CNAME, ketika origin Anda memiliki beberapa alamat server, Anda dapat memilih opsi Load Balancing Algorithm yang berbeda sehingga WAF meneruskan permintaan back-to-origin ke server yang sesuai, mencapai load balancing.

Ketika Alamat Server diatur ke Domain Name (Such as CNAME), jika resolusi domain ini mengembalikan beberapa alamat IP, WAF melakukan load balancing permintaan klien di seluruh alamat IP yang di-resolve. Jika Anda memasukkan beberapa domain, WAF memperluas semua hasil resolusi dan melakukan load balancing di antara semuanya.

Namun, jika Anda hanya memasukkan satu domain dan setiap resolusi domain hanya mengembalikan satu alamat IP, WAF tidak melakukan load balancing dan hanya meneruskan back-to-origin ke satu hasil resolusi tersebut.

Nama domain yang sama mengarah ke beberapa instans produk cloud. Bagaimana cara melakukan onboarding?

Gunakan onboarding produk cloud: Anda harus melakukan onboarding semua instans produk cloud ini secara bersamaan (misalnya, port layanan instans CLB) sehingga WAF mengalihkan traffic ke semuanya.

Gunakan onboarding CNAME: Setelah melakukan onboarding domain melalui CNAME, semua instans produk cloud dilindungi oleh kebijakan perlindungan default WAF.

Beberapa nama domain mengarah ke instans produk cloud yang sama. Bagaimana cara melakukan onboarding?

Gunakan onboarding produk cloud: Setelah melakukan onboarding instans produk cloud, semua domain pada instans tersebut secara otomatis dilindungi oleh kebijakan default WAF. Namun, jika Anda ingin mengonfigurasi aturan perlindungan terpisah untuk domain individual, Anda harus menambahkan setiap domain secara manual sebagai objek yang dilindungi. Untuk detailnya, lihat Menambahkan objek yang dilindungi secara manual.

Gunakan onboarding CNAME: Lakukan onboarding setiap domain secara individual.

Apa saja akhiran nama domain yang didukung untuk onboarding CNAME?

WAF 3.0 mendukung sebagian besar akhiran nama domain, termasuk akhiran nama domain dalam bahasa Mandarin. Untuk daftar lengkap akhiran Mandarin yang didukung, lihat iana.org.

WAF 3.0 mendukung lebih banyak akhiran domain dibandingkan WAF 2.0. Jika suatu akhiran domain tidak didukung di WAF 2.0, kami merekomendasikan untuk melakukan upgrade ke WAF 3.0.

Apakah WAF mendukung otentikasi timbal balik HTTPS (mTLS)?

Onboarding CNAME dan onboarding transparan tidak mendukung otentikasi timbal balik HTTPS. Solusi onboarding berbasis layanan di WAF 3.0 mendukung fitur ini. Saat ini, produk cloud yang mendukung onboarding berbasis layanan meliputi ALB, MSE, FC, dan SAE. Anda dapat mengonfigurasi fitur ini di bagian onboarding produk cloud pada konsol WAF.

Apakah WAF mendukung protokol WebSocket, HTTP/2, atau SPDY?

Protokol WebSocket: Penerusan traffic didukung. Perlindungan keamanan tidak disediakan.
Protokol HTTP/2: Pendengaran dan back-to-origin didukung.
Protokol SPDY: Tidak didukung.

Untuk mencegah penyerang menggunakan penyelundupan cleartext HTTP/2 (h2c) guna melewati WAF, Anda dapat membuat aturan kustom untuk mencegat permintaan di mana nama Header adalah Upgrade dan nilainya adalah h2c. Untuk detailnya, lihat Membuat aturan kustom untuk mempertahankan terhadap permintaan tertentu.

Apakah WAF mendukung website yang menggunakan autentikasi protokol NTLM?

Tidak. Jika sebuah website menggunakan autentikasi protokol NTLM, permintaan akses yang diteruskan oleh WAF mungkin gagal dalam autentikasi NTLM di server asal, menyebabkan prompt autentikasi berulang di sisi klien. Kami merekomendasikan menggunakan metode autentikasi lain untuk website Anda.

Apakah batas QPS WAF diterapkan pada seluruh instans WAF atau pada setiap domain secara individual?

Batas QPS WAF berlaku untuk seluruh instans WAF.

Sebagai contoh, jika Anda mengonfigurasi tiga domain pada instans WAF, total QPS gabungan mereka tidak boleh melebihi batas yang ditentukan. Jika QPS melebihi batas instans WAF yang Anda beli, instans tersebut mungkin masuk ke sandbox. Ketika QPS aktual melebihi spesifikasi atau instans memasuki sandbox, WAF tidak lagi menjamin kepatuhan terhadap Perjanjian Tingkat Layanan (SLA).

Apakah instans WAF yang telah dibeli mendukung migrasi lancar ke akun Alibaba Cloud lain?

Instans WAF tidak mendukung migrasi lancar langsung ke akun Alibaba Cloud lain. Jika Anda perlu menggunakan WAF lintas akun, gunakan salah satu solusi alternatif berikut:

Berhenti berlangganan dan beli ulang: Hentikan langganan untuk melepas instans WAF di bawah akun saat ini, lalu beli ulang di bawah akun target.
Manajemen multi-akun terpadu: Gunakan fitur Manajemen multi-akun untuk mengelola akun target di bawah sistem WAF akun saat ini.

Bagaimana cara melihat rentang IP back-to-origin WAF dan CNAME yang disediakan oleh WAF?

Anda dapat menemukan rentang IP back-to-origin WAF dan alamat CNAME yang disediakan oleh WAF untuk setiap domain yang di-onboard di lokasi yang ditunjukkan pada gambar berikut di halaman daftar onboarding.

Pemecahan masalah ketika instans CLB, instans NLB, atau instans ECS yang ingin Anda onboard tidak ditemukan di halaman konfigurasi onboarding

Kemungkinan penyebab	Tindakan terkait
Instans CLB, instans NLB, atau instans ECS yang ingin Anda onboard tidak memenuhi kondisi onboarding.	Periksa instans terhadap kondisi onboarding. Untuk detailnya, lihat Kondisi onboarding instans CLB, Kondisi onboarding instans NLB, dan Kondisi onboarding instans ECS.
Instans CLB yang ingin Anda onboard tidak memiliki pendengar yang sesuai dikonfigurasi.	Untuk menambahkan pendengar pada instans CLB Lapisan 7, lihat Menambahkan pendengar HTTP dan Menambahkan pendengar HTTPS. Untuk menambahkan pendengar pada instans CLB Lapisan 4, lihat Menambahkan pendengar TCP.
WAF belum menyinkronkan instans CLB, NLB, atau ECS.	Untuk langkah-langkah menyinkronkan aset secara manual, lihat Menyinkronkan aset secara manual.

Saat menambahkan port pengalihan lalu lintas HTTPS, muncul pesan "Sertifikat CLB tidak lengkap". Bagaimana cara menanganinya?

Gejala

Saat Anda menambahkan port pengalihan lalu lintas HTTPS, WAF memvalidasi sumber sertifikat untuk port tersebut. Setelah menambahkan port, pesan berikut mungkin muncul: Sertifikat CLB untuk port XXX tidak lengkap. Harap pilih ulang sertifikat dari SSL Certificate Service di konsol CLB.

Kemungkinan penyebab

Sertifikat tidak dibeli melalui Certificate Management Service (Original SSL Certificate) Alibaba Cloud dan belum diunggah ke Certificate Management Service (Original SSL Certificate) Alibaba Cloud.
Sertifikat untuk pendengar port HTTPS pada instans CLB diunggah melalui konsol CLB. Namun, metode unggah ini tidak secara otomatis menyinkronkan informasi sertifikat ke Digital Certificate Management Service (sebelumnya SSL Certificate Management). Karena WAF hanya mengambil informasi sertifikat dari Digital Certificate Management Service, hal ini menyebabkan pesan sertifikat tidak lengkap.
Sertifikat yang sebelumnya diunggah ke Digital Certificate Management Service telah dihapus secara manual, dan Certificate Management Service (Original SSL Certificate) tidak lagi berisi sertifikat Anda.

Solusi

Unggah sertifikat Anda ke Certificate Management Service (Original SSL Certificate). Untuk langkah-langkahnya, lihat Mengunggah sertifikat SSL.
Di konsol CLB, buat sertifikat dan pilih sertifikat yang dikeluarkan Alibaba Cloud sebagai sumber sertifikat. Untuk langkah-langkahnya, lihat Menggunakan sertifikat dari Alibaba Cloud SSL Certificates Service.
Di konsol CLB, pilih sertifikat server yang diunggah. Untuk langkah-langkahnya, lihat Langkah 2: Mengonfigurasi sertifikat SSL.

Untuk alamat IP asal di WAF, apakah saya harus menggunakan IP publik atau IP privat dari instans ECS?

Gunakan IP publik. WAF melakukan back-to-origin melalui jaringan publik dan tidak mendukung alamat IP privat.

Mengapa penambahan beberapa sertifikat tambahan gagal selama onboarding produk cloud?

Kemungkinan penyebabnya adalah salah satu sertifikat tidak valid. Saat menambahkan beberapa sertifikat tambahan, pastikan setiap sertifikat yang Anda pilih valid. Sertifikat yang kedaluwarsa akan menyebabkan kegagalan penambahan.

Setelah melakukan onboarding produk cloud ke WAF, apakah saya masih perlu mengonfigurasi objek yang dilindungi?

Secara default, setelah produk cloud di-onboard ke WAF, WAF secara otomatis menghasilkan objek yang dilindungi, sehingga tidak diperlukan konfigurasi tambahan. Namun, jika beberapa domain mengarah ke instans produk cloud yang sama dan Anda ingin mengonfigurasi aturan perlindungan terpisah untuk setiap domain, Anda harus menambahkan setiap domain secara manual sebagai objek yang dilindungi. Untuk detailnya, lihat Menambahkan objek yang dilindungi.

Setelah menambahkan objek yang dilindungi, pilih domain yang sesuai sebagai objek efektif saat mengonfigurasi aturan perlindungan untuk mencapai perlindungan detail halus untuk beberapa domain.

Selama onboarding CNAME, mengapa muncul prompt ERR_TOO_MANY_REDIRECTS setelah mengonfigurasi HTTP back-to-origin?

HTTP back-to-origin berarti WAF menggunakan protokol HTTP untuk meneruskan permintaan back-to-origin ke server asal, dengan port back-to-origin default adalah 80. Setelah mengaktifkan fitur ini, terlepas dari apakah klien mengakses WAF di port 80 atau 443, WAF secara default menggunakan protokol HTTP dan port 80 untuk back-to-origin. Jika port 80 di server asal Anda tidak memiliki bisnis aktual, mengaktifkan fitur ini akan menyebabkan masalah akses website.

Jika port 80 di server asal tidak memiliki bisnis aktual dan pengalihan dikonfigurasi untuk port 80 (misalnya, mengembalikan kode status 301 untuk mengalihkan ke port 443), akses klien akan terus-menerus dialihkan, sehingga muncul prompt ERR_TOO_MANY_REDIRECTS.

Mengapa terjadi error InvalidTLS saat melakukan onboarding instans CLB melalui onboarding produk cloud?

Saat melakukan onboarding instans CLB melalui onboarding produk cloud, error Waf.Pullin.InvalidTLS (TLS tidak valid) mungkin muncul. Kemungkinan besar karena instans CLB merupakan instans performa bersama. WAF tidak mendukung pengambilan informasi konfigurasi TLS untuk instans performa bersama. Anda harus mengubah instans tersebut menjadi instans performa terjamin sebelum onboarding produk cloud didukung. Untuk informasi lebih lanjut, lihat Jenis instans CLB.

IP publik server asal saya terpapar. Bagaimana cara mencegah penyerang melewati WAF dengan langsung menyerang IP publik asal?

Metode 1: Dalam mode onboarding CNAME, konfigurasikan server asal Anda untuk menerima traffic hanya dari rentang IP back-to-origin WAF, memastikan bahwa hanya WAF yang dapat berkomunikasi dengan server asal. Untuk detailnya, lihat Mengizinkan rentang IP back-to-origin WAF.

Metode 2: Gunakan onboarding produk cloud.

Berbagai skenario error 502 setelah onboarding ke WAF

Gejala

Setelah onboarding ke WAF, mengakses layanan backend mengembalikan kode status 502, atau log menunjukkan permintaan dengan kode status 502.

Penyebab dan solusi

Skenario 1: Error 502 dalam mode onboarding CNAME

Dalam mode onboarding CNAME, error 502 terjadi dalam beberapa kasus ketika server asal (seperti instans ECS atau instans CLB) tidak dapat dijangkau oleh WAF. Kami merekomendasikan untuk memeriksa aturan grup keamanan, iptables, firewall, atau perangkat lunak keamanan server asal Anda (seperti Safedog atau Yunsuo) yang mungkin memblokir akses WAF. Misalnya, Anda mungkin perlu Mengizinkan akses dari blok CIDR back-to-origin WAF di grup keamanan ECS Anda.

Anda juga perlu memastikan bahwa informasi nama domain dan server asal yang dikonfigurasi di konsol WAF sesuai dengan layanan aktual Anda. Ketidaksesuaian juga akan menyebabkan error ini.

Skenario 2: Error 5XX intermiten dengan CLB Lapisan 7 dalam mode onboarding produk cloud

Analisis penyebab detail

Timeout idle koneksi back-to-origin WAF: 3.600 detik (1 jam)

Deskripsi: Ketika koneksi antara CLB dan WAF tidak memiliki transmisi data selama 1 jam, WAF secara otomatis menutup koneksi.

Timeout idle koneksi menghadap klien CLB: 15 detik

Deskripsi: Ketika koneksi antara klien (instans WAF dalam kasus ini) dan CLB tidak memiliki transmisi data selama 15 detik, CLB secara otomatis menutup koneksi.

Dalam kasus ekstrem, pada saat koneksi persisten habis masa berlakunya di sisi CLB (tidak ada transmisi data selama lebih dari 15 detik), WAF menggunakan kembali koneksi tersebut untuk mengirim permintaan back-to-origin baru ke CLB. Karena CLB tidak lagi memiliki status koneksi, CLB mengirim paket RST untuk menghentikan permintaan. Hal ini menghasilkan log kode status 502 di sisi WAF.

Solusi

Sesuaikan Timeout koneksi persisten idle dalam konfigurasi onboarding produk cloud CLB Lapisan 7 ke nilai yang kurang dari timeout idle koneksi menghadap klien CLB — misalnya, 14 detik.

Skenario 3: Error 502 intermiten karena URI terlalu panjang

Analisis penyebab detail

CLB Lapisan 7 adalah lompatan berikutnya setelah WAF meneruskan traffic. Namun, batas panjang URI CLB adalah 32 KB. Ketika URI permintaan WAF melebihi panjang yang dapat diurai oleh CLB, CLB menolak melayani permintaan tersebut. CLB mencatat kode status 414 dan WAF mengembalikan kode status 502.

Solusi

Persingkat panjang URI. Jika muatan data besar, gunakan POST untuk transmisi data.

Skenario 4: Error 502 intermiten saat WAF mengirim permintaan back-to-origin ke beberapa CLB Lapisan 4

Arsitektur jaringan saat ini

Dalam arsitektur saat ini, WAF di-onboard dalam mode reverse proxy dengan back-to-origin ke beberapa instans CLB Lapisan 4. RealServer (RS) backend mendengarkan pada port yang sama dan dipasang di belakang beberapa instans CLB Lapisan 4.

Analisis penyebab detail

Ketika instans ECS berfungsi sebagai server backend untuk beberapa instans CLB Lapisan 4 (protokol TCP) yang dikonfigurasi dengan port layanan backend yang sama, isu berikut mungkin terjadi: Jika permintaan dari node WAF yang sama dikirim back-to-origin ke instans CLB menggunakan alamat IP node instans WAF yang sama secara konkuren, beberapa koneksi mungkin gagal atau timeout.

Kasus 1: Konflik 5-tupel, tabrakan aliran TCP

Ketika WAF melindungi beberapa node CLB, permintaan dari node tersebut mungkin berasal dari alamat IP back-to-origin WAF yang sama.

Ketika node WAF mengirim permintaan back-to-origin ke CLB1, koneksi (WIP:CPORT->VIP1:VPORT1) dikonversi menjadi (WIP:CPORT->DIP:DPORT) saat mencapai ECS backend.
Ketika node WAF mengirim permintaan back-to-origin ke CLB2, koneksi (WIP:CPORT->VIP2:VPORT2) juga dikonversi menjadi (WIP:CPORT->DIP:DPORT) saat mencapai ECS backend.
Karena nomor urut dan status kedua koneksi TCP bertabrakan di server backend, pembentukan koneksi gagal. Secara spesifik, kedua koneksi TCP yang dimulai dianggap memiliki 5-tupel yang sama (TCP:WIP:CPORT:DIP:DPORT) di server backend. Konflik 5-tupel ini mungkin menyebabkan paket SYN dijatuhkan.

Kasus 2: Kesalahan routing paket respons

Dalam jalur permintaan lengkap, node CLB yang memulai permintaan berbeda dari node CLB yang menerima paket respons.

WAF mengirim paket SYN back-to-origin melalui CLB2, dengan 5-tupel WIP:CPORT->VIP1:VPORT1. Saat mencapai ECS2 backend, dikonversi menjadi WIP:CPORT->DIP:DPORT.
Jika ECS2 memiliki koneksi TIME-WAIT pada titik ini, 5-tupelnya adalah TCP:WIP:CPORT:DIP:DPORT. Setelah menerima paket SYN dari langkah 1, ECS2 menentukan SYN tersebut valid dan merespons dengan paket SYN-ACK.
Karena ECS2 dipasang di belakang beberapa instans SLB, ECS2 mungkin mengirim paket SYN-ACK kembali ke CLB1. Jika CLB1 tidak memiliki sesi untuk 5-tupel ini, CLB1 mengirim paket Reset dua arah, menyebabkan WAF mengembalikan error 502.

Solusi

Solusi 1 (Direkomendasikan)

Ubah arsitektur jaringan, misalnya, gunakan beberapa instans CLB Lapisan 7 sebagai server asal, untuk menghindari beberapa node load balancer CLB Lapisan 4 yang berbeda meneruskan permintaan ke port yang sama pada layanan backend yang sama.

Solusi 2

Migrasi dari CLB ke NLB dan nonaktifkan Client IP Affinity dalam konfigurasi NLB untuk menyelesaikan konflik 5-tupel. Terapkan Protokol Proxy pada layanan backend untuk memperoleh IP klien yang sebenarnya. Untuk detailnya, lihat Mengaktifkan protokol Proxy.

Langkah-langkah

Login ke Konsol Network Load Balancer (NLB).Di bilah navigasi atas, pilih wilayah tempat instans NLB diterapkan.
Di panel navigasi kiri, pilih Network Load Balancer (NLB) > Server Groups.
Pilih grup server Anda, lalu di kolom Aksi, klik Edit Informasi Dasar. Di kotak dialog Edit Informasi Dasar, nonaktifkan Client IP Affinity dan simpan perubahan.

Solusi 3 (Tidak direkomendasikan)

Anda dapat mengajukan Tiket untuk mengaktifkan mode FULLNAT. Ketika beberapa instans CLB meneruskan permintaan ke port yang sama pada server backend yang sama, FullNAT memodifikasi alamat sumber, sehingga membuat 5-tupel setiap koneksi unik dan menghindari konflik. Aktifkan mode FULLNAT pada pendengar CLB untuk menghindari konflik 5-tupel.

Skenario 5: Masalah parameter kernel Linux menyebabkan permintaan mengembalikan error 502

Beberapa versi Linux lama memiliki parameter kernel net.ipv4.tcp_tw_recycle. Parameter ini telah ditinggalkan di versi Linux yang lebih baru. Ketika parameter ini diaktifkan, meskipun TIME-WAIT dapat diklaim kembali lebih cepat, koneksi baru mungkin gagal dibentuk secara normal. Misalnya, ketika beberapa mesin internal mengakses melalui SNAT dengan perbedaan timestamp, kegagalan koneksi dan reset permintaan mungkin terjadi.

Periksa apakah nilai parameter ini adalah 1. Jika ya, kami merekomendasikan mengubahnya menjadi 0. Untuk detailnya, lihat Memodifikasi parameter.

Unggahan file gagal setelah onboarding ke WAF

Hal ini mungkin terjadi karena unggahan file melebihi batas maksimum 2 GB. WAF saat ini mendukung unggahan file hingga 2 GB. Ketika badan permintaan melebihi 2 GB, WAF mengembalikan kode status 413. Anda dapat menggunakan kode status yang dikembalikan untuk menentukan apakah batas ukuran transfer file telah tercapai.

Bagaimana cara memperbarui sertifikat yang akan kedaluwarsa?

Metode pembaruan bervariasi tergantung pada mode onboarding Anda:

Untuk onboarding CNAME, lihat Memperbarui sertifikat domain.
Untuk onboarding produk cloud dengan instans ECS, lihat Memperbarui sertifikat yang terikat ke port pengalihan lalu lintas ECS.
Untuk onboarding produk cloud dengan instans CLB, lihat Memperbarui sertifikat yang terikat ke port pengalihan lalu lintas CLB.
Untuk onboarding produk cloud dengan instans NLB, lihat Memperbarui sertifikat yang terikat ke port pengalihan lalu lintas NLB.
Untuk onboarding produk cloud dengan instans ALB, tidak diperlukan pembaruan di konsol WAF. Cukup terapkan sertifikat ke instans ALB dari konsol Digital Certificate Management Service (sebelumnya SSL Certificate). Untuk langkah-langkahnya, lihat Memilih metode penerapan sertifikat.

Setelah onboarding produk cloud, dapatkah server asal memperoleh IP klien yang sebenarnya?

Ya. WAF menyediakan IP klien yang sebenarnya langsung ke instans produk cloud.

Paket sandi lemah dilaporkan saat memindai domain yang telah di-onboard ke WAF. Bagaimana cara mengonfigurasi versi protokol TLS dan paket sandi agar memenuhi persyaratan keamanan?

Untuk memastikan website HTTPS yang di-onboard ke WAF memenuhi persyaratan keamanan dan kepatuhan, kami merekomendasikan mengonfigurasi protokol TLS versi tinggi dan paket sandi kuat.

Penting

Protokol TLS dan paket sandi berkeamanan tinggi mungkin mengurangi kompatibilitas klien. Setelah konfigurasi, pengguna dengan klien lama (seperti Internet Explorer) mungkin tidak dapat mengakses website. Harap evaluasi secara menyeluruh kompatibilitas klien sebelum mengaktifkan.

Langkah 1: Menentukan lokasi konfigurasi

Entri konfigurasi untuk versi protokol TLS dan paket sandi bergantung pada mode onboarding WAF.

Onboarding CNAME

Dalam mode onboarding CNAME, lokasi konfigurasi bergantung pada target pemindaian. Harap konfigurasikan di lokasi yang sesuai berdasarkan target pemindaian spesifik.

Memindai domain yang di-onboard: Di tab CNAME Record, temukan domain target dan klik Edit di kolom Aksi. Di halaman Edit Domain Name, di bagian Protocol Type > HTTPS, perluas Advanced Settings, lalu temukan TLS Version dan HTTPS Cipher Suite.
Memindai VIP WAF: Di tab CNAME Record, klik Default SSL/TLS Settings di sisi kanan, unggah sertifikat default, lalu konfigurasikan TLS Version dan HTTPS Cipher Suite.

Onboarding produk cloud

Dalam mode onboarding produk cloud, untuk instans ECS, instans CLB Lapisan 4 (protokol pendengar adalah TCP), dan instans NLB, konfigurasikan di sisi WAF. Untuk skenario onboarding produk cloud lainnya, konfigurasi harus diselesaikan di konsol produk masing-masing.

Catatan

Saat melakukan onboarding instans CLB Lapisan 7 melalui onboarding produk cloud, paket sandi kustom tidak didukung. Anda hanya dapat memilih kebijakan keamanan TLS yang disediakan sistem.
Saat melakukan onboarding instans ALB melalui onboarding produk cloud, jika Anda perlu menyesuaikan paket sandi, Anda harus membuat kebijakan keamanan TLS secara manual. Untuk informasi lebih lanjut, lihat Kebijakan keamanan TLS.

ECS, CLB Lapisan 4 (protokol listening adalah TCP), NLB: Pada tab Cloud Native, temukan instans target, klik ikon , pilih port target, lalu klik Actions di kolom Actions dan pilih Modify. Konfigurasikan pengaturan pada bagian TLS Version dan Cipher Suite.
ALB: Di konsol ALB, setelah menemukan instans target, buka tab Listener, temukan pendengar target, lalu konfigurasikan TLS Security Policy.
CLB Lapisan 7 (protokol pendengar adalah HTTPS): Di konsol CLB, setelah menemukan instans target, buka tab Listener, temukan pendengar target, klik Manage Certificates, lalu konfigurasikan TLS Security Policy di kotak dialog yang muncul.
FC, MSE, APIG, SAE: Konfigurasikan di konsol produk yang sesuai.

Langkah 2: Memilih versi protokol TLS

Untuk menghindari risiko keamanan dari versi protokol TLS lama, kami merekomendasikan memilih TLS 1.2 atau yang lebih baru. Jika website Anda mendukung TLS 1.3, pilih Support TLS 1.3.

Langkah 3: Memilih paket sandi

Untuk menghindari risiko keamanan dari paket sandi lemah, kami merekomendasikan memilih paket sandi kuat dari daftar berikut.

Paket sandi kuat	Paket sandi lemah
ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-SHA256 ECDHE-ECDSA-AES256-SHA384 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES256-SHA ECDHE-RSA-CHACHA20-POLY1305	AES128-GCM-SHA256 AES256-GCM-SHA384 AES128-SHA256 AES256-SHA256 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA AES128-SHA AES256-SHA DES-CBC3-SHA ECDHE-RSA-RC4-SHA

Catatan

Rekomendasi keamanan paket sandi: Paket sandi ECDHE-RSA-AES128-SHA256 dan ECDHE-RSA-AES256-SHA384 menggunakan ECDHE untuk pertukaran kunci, RSA untuk autentikasi, dan mode enkripsi AES-CBC. Dibandingkan dengan paket sandi yang menggunakan mode enkripsi terautentikasi seperti AES-GCM, paket sandi ini menawarkan keamanan dan kinerja yang lebih rendah. Beberapa alat pemindaian keamanan mungkin mengidentifikasi paket sandi ini sebagai paket sandi lemah. Jika hal ini terjadi, pilih paket sandi kustom dan secara manual mengecualikan kedua paket sandi ini.
Konvensi penamaan paket sandi: Karena konvensi penamaan paket sandi berbeda, WAF menampilkan paket sandi dalam format OpenSSL, sedangkan beberapa alat pemindaian mungkin menggunakan standar IANA. Misalnya, ECDHE-ECDSA-AES256-SHA384 dalam OpenSSL sesuai dengan TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 dalam IANA. Untuk mencari pemetaan dengan cepat, kunjungi ciphersuite.info atau gunakan alat pencarian TLS lainnya.

Mengapa field upstream_addr menampilkan "-" dalam log setelah onboarding?

Ketika field upstream_addr dalam log menampilkan -, artinya WAF tidak mengirim permintaan back-to-origin ke server asal — misalnya, ketika permintaan diblokir oleh WAF. Kami merekomendasikan memeriksa field lain seperti upstream_status dan upstream_response_time untuk analisis lebih lanjut.