Cloud Firewall:FAQ tentang kebijakan kontrol akses

Jika saya mengaktifkan WAF dalam mode proxy transparan dan firewall Internet secara bersamaan, apakah traffic melalui forwarding port dapat dikontrol oleh kebijakan kontrol akses Cloud Firewall? {#waf-transparent-proxy}

Ya. Saat Web Application Firewall (WAF) dalam mode proxy transparan dan firewall Internet diaktifkan secara bersamaan, kebijakan kontrol akses yang Anda buat untuk firewall Internet berlaku untuk traffic melalui forwarding port.

Perlu diperhatikan bahwa audit log, analisis log, dan statistik traffic tidak tersedia untuk traffic forwarding port. Traffic melalui port lain tidak terpengaruh.

Apakah batas otorisasi untuk kebijakan kontrol akses dapat diperluas?

• Untuk metode penagihan langganan 1.0 lama, jika kuota untuk kebijakan kontrol akses di Batas Internet, Batas NAT, dan Batas VPC tidak mencukupi, Anda dapat membeli Quota for Additional Policy di halaman pembelian Cloud Firewall untuk memperluas kuota.

• Untuk metode penagihan bayar sesuai penggunaan 1.0 lama, Anda tidak dapat memperluas kuota untuk kebijakan kontrol akses.

• Untuk metode penagihan 2.0 baru, tidak ada biaya tambahan untuk Quota for Additional Policy.

Untuk informasi lebih lanjut, lihat Metode penagihan lama 1.0 dan instruksi peningkatan.

Apakah saya dapat meningkatkan bandwidth Protected VPC Traffic? {#vpc-bandwidth}

Ya. Jika kapasitas default Protected VPC Traffic tidak memenuhi kebutuhan Anda, konfigurasikan parameter Protected VPC Traffic untuk meningkatkan batas puncak traffic lintas-VPC:

Apakah Cloud Firewall dapat memblokir traffic dari blok CIDR IPv6? {#ipv6}

Ya. Buat kebijakan kontrol akses untuk firewall Internet guna mengontrol traffic blok CIDR IPv6. Dukungan IPv6 tersedia di semua edisi Cloud Firewall. Untuk detailnya, lihat Buat kebijakan kontrol akses untuk firewall Internet.

Apa perbedaan antara Cloud Firewall dan security group? {#cloud-firewall-vs-security-groups}

Cloud Firewall dan security group saling melengkapi: security group menyediakan penyaringan traffic tingkat host antar instans Elastic Compute Service (ECS), sedangkan Cloud Firewall menyediakan perlindungan terpusat di batas jaringan dan tingkat antar-instans. Gunakan keduanya untuk pertahanan berlapis (defense in depth).

Secara spesifik:

• security group adalah firewall host virtual yang disediakan oleh ECS yang mengontrol traffic antar instans ECS.

• Cloud Firewall beroperasi di beberapa batas jaringan:

  • Firewall Internet: mengontrol traffic di batas Internet

  • Firewall NAT: mengontrol traffic di batas NAT

  • Firewall VPC: mengontrol traffic di batas VPC

  • Firewall internal: mengontrol traffic antar instans ECS

Selain yang ditawarkan oleh security group, Cloud Firewall menambahkan:

• Kontrol akses berbasis aplikasi — mengontrol traffic berdasarkan protokol (seperti HTTP) tanpa perlu menentukan port

• Kontrol akses berbasis nama domain — mengizinkan instans ECS hanya mengirim permintaan ke nama domain tertentu

• Pencegahan Intrusi — perlindungan proaktif terhadap kerentanan umum dan serangan brute-force

• Mode Monitor — mengamati traffic tanpa memblokir, berguna untuk validasi kebijakan

• Log traffic lengkap dan analisis real-time

• Manajemen keamanan terpusat — kebijakan untuk firewall internal di Konsol Cloud Firewall secara otomatis disinkronkan ke security group ECS

Urutan pencocokan traffic: Untuk traffic inbound, Cloud Firewall dievaluasi terlebih dahulu, kemudian security group. Untuk traffic outbound, security group dievaluasi terlebih dahulu, kemudian Cloud Firewall. Traffic hanya diizinkan jika melewati kebijakan Cloud Firewall dan aturan security group.

Apa perbedaan antara kelompok kebijakan umum dan kelompok kebijakan perusahaan? {#common-vs-enterprise-policy-groups}

Kelompok kebijakan untuk firewall internal dipetakan ke security group ECS dan mengontrol traffic inbound serta outbound antar instans ECS. Kedua jenis ini berbeda dalam kapasitas dan perilaku lintas-kelompok:

Untuk detailnya, lihat Basic security group dan advanced security group.

Apakah menonaktifkan kebijakan default sistem akan memengaruhi akses internal Alibaba Cloud? {#disable-system-default-policies}

Tidak. Menonaktifkan kebijakan default sistem di tengah daftar kebijakan (seperti "System default. Allow ICMP requests") tidak memengaruhi akses internal normal Alibaba Cloud. Anda dapat mengaktifkan hanya kebijakan allow pertama dan kebijakan Drop terakhir untuk mencapai perilaku kontrol akses yang diinginkan.

Saya telah mengonfigurasi kebijakan kontrol akses outbound HTTP atau HTTPS untuk sebuah nama domain. Bagaimana cara memeriksa apakah kebijakan tersebut berlaku? {#check-http-https-policy}

Gunakan perintah curl untuk mengirim permintaan HTTP atau HTTPS nyata ke domain tersebut, lalu periksa jumlah hit kebijakan dan log audit di Konsol Cloud Firewall.

Contohnya:

curl -k "https://www.aliyundoc.com"

Saat saya menerapkan Kebijakan izin default, sistem memberi prompt bahwa konflik tidak dapat diselesaikan. Bagaimana cara memperbaikinya? {#conflict-cannot-be-resolved}

Hal ini terjadi ketika aturan security group yang terkait dengan alamat IP target memiliki prioritas, tipe protokol, range port, dan objek otorisasi yang sama dengan Kebijakan izin default yang Anda terapkan.

Buka halaman Security Groups di Konsol ECS dan sesuaikan prioritas aturan yang bertabrakan. Untuk panduan, lihat Ubah aturan security group. Jika Anda memerlukan bantuan, kirim tiket.

Mengapa ikon Quick Apply tidak tersedia? {#quick-apply-unavailable}

Ikon Quick Apply tidak tersedia ketika terdapat aturan security group yang bertabrakan untuk alamat IP target. Selesaikan konflik aturan di security group ECS yang terkait dengan alamat IP tersebut sebelum menerapkan Kebijakan izin default. Untuk detailnya, lihat Firewall Internet.

Ikon Quick Apply juga mungkin tidak tersedia karena alasan berikut:

• Security group yang terkait dengan alamat IP tersebut adalah advanced security group. Advanced security group tidak mendukung Kebijakan izin default.

• Firewall Internet dinonaktifkan untuk alamat IP tersebut.

Bagaimana cara menghilangkan false positive untuk koneksi outbound mencurigakan yang disebabkan oleh pemindaian berbasis Internet? {#false-positives}

Ini merupakan perilaku yang diketahui terjadi ketika akses inbound tidak dibatasi hanya pada port yang diperlukan.

Mengapa terjadi: Saat penyerang memindai port tertutup di server Anda, server (atau gerbang NAT) mengembalikan paket Protokol Pesan Kontrol Internet (ICMP) yang menunjukkan port tersebut tidak dapat dijangkau. Cloud Firewall tidak dapat mengaitkan paket ICMP ini dengan permintaan masuk, sehingga menganggap paket tersebut sebagai koneksi outbound yang dimulai oleh server Anda. Jika alamat IP pemindai muncul di pustaka intelijen ancaman, Cloud Firewall akan menghasilkan peringatan.

Sebaliknya, saat paket SYN mencapai port terbuka, server mengembalikan paket SYN-ACK dan Cloud Firewall memperlakukan keduanya sebagai bagian dari koneksi yang sama — tidak ada peringatan yang dihasilkan.

Solusi: Buat kebijakan kontrol akses inbound yang hanya mengizinkan traffic melalui port yang diperlukan oleh beban kerja Anda. Hal ini mencegah respons pemindaian port tertutup memicu peringatan palsu. Untuk detailnya, lihat Buat kebijakan kontrol akses untuk firewall Internet.

Saya telah mengonfigurasi kebijakan Drop outbound untuk 0.0.0.0/0 pada firewall Internet, tetapi beberapa traffic masih diizinkan. Mengapa? {#deny-not-blocking-all}

Cloud Firewall sementara mengizinkan traffic saat belum dapat mengidentifikasi nama domain atau tipe aplikasi traffic tersebut, agar kebijakan berikutnya dapat menyelesaikan identifikasi. Hal ini berlaku dalam dua skenario:

• Nama domain belum diidentifikasi: Terdapat kebijakan berbasis nama domain dengan prioritas tinggi, dan Cloud Firewall telah mengidentifikasi IP sumber, IP tujuan, dan tipe aplikasi — tetapi belum nama domain-nya. Cloud Firewall mengizinkan traffic untuk melanjutkan agar nama domain dapat diselesaikan oleh kebijakan berikutnya.

• Tipe aplikasi belum diidentifikasi: Terdapat kebijakan berbasis aplikasi dengan prioritas tinggi, dan Cloud Firewall telah mengidentifikasi IP sumber, IP tujuan, dan port — tetapi belum tipe aplikasinya. Cloud Firewall mengizinkan traffic untuk melanjutkan agar tipe aplikasi dapat diidentifikasi.

Untuk mencegah perilaku ini, gunakan salah satu pendekatan berikut:

Opsi 1: Aktifkan mode ketat

Dalam mode ketat, Cloud Firewall terus mengevaluasi kebijakan hingga tipe aplikasi atau nama domain diidentifikasi. Jika kebijakan Drop dikonfigurasi, traffic yang diidentifikasi sebagai Unknown akan ditolak. Untuk detailnya, lihat Konfigurasi mode mesin kontrol akses.

Opsi 2: Gunakan hanya kebijakan Lapisan 4

Buat kebijakan kontrol akses Lapisan 4 dengan Application diatur ke ANY dan tidak menentukan nama domain untuk Destination. Saat traffic cocok dengan kebijakan Lapisan 4, Cloud Firewall langsung menerapkan aksi kebijakan tanpa menunggu identifikasi lapisan aplikasi. Untuk detailnya, lihat Buat kebijakan kontrol akses untuk firewall Internet.

Mengapa kebijakan kontrol akses prioritas tinggi tidak sesuai dengan traffic? {#high-priority-policy-not-matching}

Jika kebijakan kontrol akses prioritas tinggi tidak sesuai dengan traffic seperti yang diharapkan, periksa penyebab umum berikut:

Penyebab 1: Ketidaksesuaian pembatasan sumber

Kebijakan prioritas tinggi menentukan pembatasan IP sumber, tetapi IP sumber aktual dalam log traffic tidak termasuk dalam rentang yang diizinkan. Tinjau IP sumber dalam log dan perbarui konfigurasi IP sumber kebijakan tersebut.

Penyebab 2: Tidak adanya kebijakan Drop catch-all

Kebijakan allow presisi (misalnya, hanya mengizinkan IP tertentu untuk mengakses SSH) dikonfigurasi, tetapi alamat IP lain masih dapat mengakses layanan karena terdapat aturan allow prioritas lebih rendah atau aturan allow default. Tambahkan kebijakan Drop catch-all dengan prioritas terendah (ditempatkan paling akhir dalam daftar kebijakan): atur Protocol ke ANY, Port ke 0/0, dan alamat IP sumber maupun tujuan ke 0.0.0.0/0. Hal ini memblokir semua traffic yang tidak cocok dengan kebijakan sebelumnya.

Untuk memverifikasi kebijakan berlaku, uji konektivitas dari host yang tidak berada dalam VPC atau wilayah yang sama dengan resource yang dilindungi.

Penyebab 3: Entri Buku alamat tidak lengkap

Kebijakan dikonfigurasi untuk menggunakan Buku alamat untuk alamat IP sumber, tetapi traffic yang diharapkan tidak cocok karena alamat IP sumber traffic tersebut tidak tercantum dalam Buku alamat. Di Konsol Cloud Firewall, buka Protect > Address Book untuk memeriksa entri Buku alamat dan tambahkan alamat IP yang hilang.

Penyebab 4: Gangguan kebijakan default sistem

Setelah mengonfigurasi kebijakan daftar putih dan kebijakan Drop, alamat IP di luar daftar putih masih dapat mengakses target ICMP (ping). Hal ini biasanya terjadi karena kebijakan bawaan "System default. Allow ICMP requests" memiliki prioritas lebih tinggi daripada kebijakan Drop Anda. Untuk mengatasinya, ubah alamat IP sumber kebijakan Drop terakhir Anda menjadi 0.0.0.0/0.

Bagaimana cara mengizinkan akses hanya ke subdomain tertentu sambil memblokir sisa domain tersebut? {#subdomain-access-control}

Gunakan dua kebijakan dengan prioritas berbeda — kebijakan allow untuk subdomain target dan kebijakan Drop untuk pola wildcard. Kebijakan allow harus memiliki prioritas lebih tinggi daripada kebijakan Drop.

Menggunakan xyz.com sebagai contoh untuk hanya mengizinkan abc.xyz.com:

1. Buat kebijakan Drop untuk *.xyz.com dan atur prioritasnya ke Lowest.

2. Buat kebijakan untuk allow akses ke abc.xyz.com dan atur prioritasnya ke Highest.

Karena kebijakan allow untuk abc.xyz.com memiliki prioritas tertinggi, kebijakan tersebut dievaluasi sebelum blokir wildcard. Semua subdomain lain mengenai kebijakan blokir wildcard. Untuk detailnya, lihat Buat kebijakan kontrol akses untuk firewall Internet.

Bagaimana cara menggunakan Cloud Firewall untuk memperkuat kontrol akses pada nama domain host bastion? {#bastionhost}

Bastionhost adalah platform manajemen operasi dan pemeliharaan (O&M) yang menangani otentikasi identitas, manajemen akun, dan audit. Karena menyimpan informasi akun sensitif dan mendukung akses berbasis nama domain, pengguna tidak sah yang mencapai halaman login host bastion berpotensi mengakses banyak aset.

Saat Anda membeli Bastionhost dan Cloud Firewall secara bersamaan, Bastionhost secara otomatis ditambahkan sebagai tipe aset di Cloud Firewall, dan host bastion yang dibeli secara otomatis disinkronkan ke daftar aset Cloud Firewall. Hal ini memungkinkan Anda menerapkan kontrol akses, pencegahan intrusi, dan analisis lalu lintas jaringan ke alamat IP publik host bastion dari satu lokasi.

Konfigurasikan kebijakan berikut:

• Kontrol akses inbound (firewall Internet): Izinkan traffic dari Internet atau Internet di area tertentu ke port terbuka host bastion.

• Kontrol akses outbound (firewall Internet): Izinkan traffic dari host bastion hanya ke alamat IP publik yang diperlukan.

• Pencegahan Intrusi: Aktifkan firewall untuk host bastion agar mengalihkan traffic inbound dan outbound-nya melalui Cloud Firewall untuk perlindungan.

Untuk panduan konfigurasi lengkap, lihat Konfigurasi kebijakan kontrol akses dalam skenario di mana Cloud Firewall diterapkan bersama Bastionhost.

Apakah kebijakan kontrol akses tetap berlaku jika rentang waktu pengulangan mencakup dua hari kalender? {#spanning-two-days}

Ya. Saat Recurrence Cycle mencakup dua hari kalender (misalnya, 18.00 hingga 08.00 hari berikutnya) dan waktu mulai Effective Date berada dalam rentang tersebut, waktu akhir kebijakan bergeser ke waktu yang ditentukan pada hari berikutnya.

Contoh: Recurrence Cycle = Setiap Selasa 18.00–08.00 (+1), Effective Date = 2024.08.20–2024.08.22.

Kebijakan berlaku dari pukul 18.00 tanggal 20 Agustus 2024 hingga pukul 08.00 tanggal 21 Agustus 2024.

Apa yang harus saya lakukan jika traffic unidireksional pada firewall VPC untuk router transit diblokir saat saya mengubah skenario pengalihan traffic-nya? {#unidirectional-traffic-blocked}

Hal ini disebabkan oleh asimetri perutean yang terjadi selama transisi saat Anda mengaktifkan atau menonaktifkan skenario pengalihan traffic.

Why it happens: Jika Anda memiliki kebijakan allow untuk traffic VPC 1 → VPC 2 dan kebijakan Drop default, mengaktifkan atau menonaktifkan skenario pengalihan sementara menciptakan perutean asimetris. Paket respons untuk traffic ICMP dan UDP diperlakukan sebagai traffic baru yang tidak diminta dan dialihkan ke Cloud Firewall. Karena IP sumber dan tujuan dibalik dalam paket respons ini, traffic tersebut tidak cocok dengan kebijakan allow dan diblokir oleh kebijakan Drop. Traffic TCP tidak terpengaruh.

Solusi: Jika gangguan traffic jangka pendek tidak dapat diterima, konfigurasikan kebijakan Allow sementara 0.0.0.0/0 dengan prioritas tertinggi pada firewall VPC untuk router transit Cloud Enterprise Network (CEN) sebelum mengaktifkan atau menonaktifkan firewall. Hal ini mengizinkan traffic balik selama transisi. Setelah firewall sepenuhnya diaktifkan atau dinonaktifkan, hapus kebijakan sementara tersebut.