Grup keamanan cloud untuk VPN: buka pendengar, bukan semua

Server VPN berjalan, klien kehabisan waktu, dan naluri pertama adalah menambahkan aturan yang mengizinkan semua ke grup keamanan. Kadang itu membuatnya berfungsi, dan itulah hasil terburuk, karena sekarang tidak ada yang tahu batas mana yang benar-benar ditutup. Ada empat filter terpisah antara klien dan daemon, dan hanya satu di antaranya adalah grup keamanan.

Sebutkan protokol sebelum aturan

Aturan adalah protokol, rentang port, dan sumber. WireGuard mendengarkan di UDP, biasanya 51820. OpenVPN biasanya UDP atau TCP 1194 tergantung konfigurasinya. IPsec memerlukan pertukaran IKE di UDP 500 dan 4500 plus protokol ESP itu sendiri, yang merupakan nomor protokol dan bukan port. Menebak TCP karena aturan lain TCP adalah cara orang berakhir dengan aturan yang terlihat benar dan tidak cocok dengan apa pun.

Baca pendengar dari layanan yang berjalan, bukan dari tutorial. Daemon yang terikat ke satu alamat tidak akan menerima lalu lintas yang tiba di alamat lain.

Batasi sumber ke rentang klien yang diizinkan desain, bukan ke seluruh internet.

Grup keamanan bersifat stateful; ACL subnet tidak

Grup keamanan bersifat stateful dan hanya mengizinkan: aliran masuk yang diizinkan otomatis mendapat balasannya, dan tidak ada aturan penolakan yang perlu dipikirkan. ACL subnet bersifat stateless dan dievaluasi di kedua arah, jadi izin masuk tanpa rentang efemeral keluar yang sesuai tetap gagal. Perbedaan itu menjelaskan banyak aturan yang terlihat benar di konsol.

Pastikan juga kebijakan mana yang terpasang pada endpoint yang berjalan, karena satu instans bisa memiliki lebih dari satu grup dan aturan di grup yang tidak terpasang tidak mengubah apa pun.

Kebijakan efektif adalah gabungan dari yang terpasang, bukan berkas yang Anda sunting.

Firewall host adalah batas terpisah

Kebijakan cloud mengizinkan lalu lintas ke antarmuka jaringan, lalu sistem operasi memutuskan apakah daemon melihatnya. Firewall host dengan kebijakan tolak bawaan akan menjatuhkan paket yang diizinkan grup keamanan, dan konsol cloud tidak akan menampilkan penolakan karena tidak pernah punya pendapat. Periksa keduanya, dalam urutan paket bertemu keduanya.

Jika host memakai antarmuka depan firewall distribusi, pastikan aturan dasarnya, bukan nama profilnya, karena profil bisa aktif sementara port tertutup.

Tangkapan pada antarmuka memberi tahu Anda batas mana yang menjatuhkan paket.

Mengizinkan pendengar bukan merutekan klien

Gateway VPN yang meneruskan lalu lintas klien butuh lebih dari port terbuka. Butuh penerusan IP, kebijakan yang mengizinkan aliran dari antarmuka terowongan ke jaringan tujuan, dan sering pemeriksaan sumber-tujuan yang dimatikan pada antarmuka agar platform tidak membuang lalu lintas yang tidak dialamatkan kepadanya. Tidak ada satu pun yang dibuat oleh aturan pendengar.

Di sinilah jabat tangan yang berfungsi dan jalur data yang rusak berpisah, dan karena itu status terowongan bisa terlihat sehat sementara tidak ada yang termuat.

Perbaiki perutean sebagai perubahan terpisah dengan verifikasinya sendiri, dan catat bahwa gateway penerus juga butuh kebijakan keluar yang mengizinkan tujuan.

Pertahankan jalur kembali, lalu sempitkan aturannya

Sebelum mengubah kebijakan firewall jarak jauh, pastikan ada jalur manajemen independen, seperti manajer sesi, konsol serial, atau jaringan di luar jalur. Jika satu-satunya jalur manajemen melewati aturan yang Anda sunting, Anda tidak punya pemulihan. Lalu terapkan aturan sempit, uji dari klien nyata, dan korelasikan percobaan dengan bukti di sisi server. Jawaban dari layanan lain di mesin yang sama bukan bukti bahwa pendengar tercapai.

Hapus izin luas eksperimental begitu yang sempit berfungsi, dan catat mengapa aturan itu ada. AWS mendokumentasikan perilaku stateful grup keamanan, dan dokumen itulah yang dirujuk ketika seseorang mengusulkan rentang lebar sebagai jalan pintas.

Dokumentasikan juga keterpasangannya, atau antarmuka pengganti akan kehilangan kebijakan itu diam-diam.