Cloud Firewall:FAQ tentang kebijakan kontrol akses

Jika saya mengaktifkan WAF dalam mode proxy transparan dan firewall Internet secara bersamaan, apakah traffic melalui port forwarding 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 port forwarding.

Perlu diperhatikan bahwa audit log, analisis log, dan statistik traffic tidak tersedia untuk traffic port forwarding. 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.

Dapatkah saya 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:

Dapatkah Cloud Firewall 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 berbagai batas jaringan:

  • Internet firewall: mengontrol traffic di batas Internet

  • NAT firewalls: mengontrol traffic di batas NAT

  • VPC firewalls: mengontrol traffic di batas VPC

  • Internal firewalls: 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 menentukan port

• Kontrol akses berbasis nama domain — mengizinkan instans ECS mengirim permintaan hanya 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 internal firewalls 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 lolos dari 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 internal firewalls 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 groups and advanced security groups.

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

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

Saya telah mengonfigurasi kebijakan kontrol akses outbound HTTP atau HTTPS untuk 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 bertentangan. Untuk panduan, lihat Modify a security group rule. Jika memerlukan bantuan, ajukan tiket.

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

Ikon Quick Apply tidak tersedia ketika terdapat aturan security group yang bertentangan 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 Internet firewall.

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 menghubungkan paket ICMP ini dengan permintaan masuk, sehingga memperlakukannya sebagai koneksi outbound yang dimulai oleh server Anda. Jika alamat IP pemindai tersebut ada 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 Deny arah keluar untuk 0.0.0.0/0 pada firewall Internet, tetapi beberapa traffic masih diizinkan. Mengapa? {#deny-not-blocking-all}

Cloud Firewall sementara mengizinkan traffic ketika belum dapat mengidentifikasi nama domain atau tipe aplikasi traffic tersebut, agar kebijakan selanjutnya 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 diresolusi 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 Deny dikonfigurasi, traffic yang diidentifikasi sebagai Unknown akan ditolak. Untuk detailnya, lihat Configure the mode of the access control engine.

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 deny catch-all

Kebijakan allow yang spesifik dikonfigurasi (misalnya, hanya mengizinkan IP tertentu untuk mengakses SSH), tetapi alamat IP lain masih dapat mengakses layanan karena terdapat aturan allow prioritas lebih rendah atau aturan allow default. Tambahkan kebijakan deny catch-all dengan prioritas terendah (ditempatkan paling akhir dalam daftar kebijakan): atur Protocol ke All Protocols, Port ke 0/0, serta alamat IP sumber dan 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 IP sumber traffic tersebut tidak terdaftar dalam Buku alamat. Di Konsol Cloud Firewall, buka Protection Config > Policy Configuration > 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 deny, 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 deny Anda. Untuk mengatasinya, ubah alamat IP sumber kebijakan deny 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 deny untuk pola wildcard. Kebijakan allow harus memiliki prioritas lebih tinggi daripada kebijakan deny.

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

1. Buat kebijakan untuk block akses ke *.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 Configure access control policies in scenarios in which Cloud Firewall is deployed together with 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 berakhir 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 mulai 18:00 pada 20 Agustus 2024 hingga 08:00 pada 21 Agustus 2024.

Apa yang harus saya lakukan jika traffic satu arah 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 Deny 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 Deny. Traffic TCP tidak terpengaruh.

Solusi: Jika gangguan traffic jangka pendek tidak dapat diterima, konfigurasikan kebijakan sementara 0.0.0.0/0 Allow 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.