Aturan masuk SSH dan VPN: apa yang sebenarnya dikendalikan daftar izin

Ikuti satu koneksi dari klien ke host: hook mana yang dilewatinya, mengapa menggantung dan penolakan berarti aturan berbeda, dan mengapa reject tidak pernah menjadi kebijakan.

Hubungkan sekali sebelum Anda mengubah aturan dan catat apakah klien menggantung atau langsung ditolak. Perbedaan tunggal itu memberi tahu Anda keputusan mana yang menjatuhkan paket dan menghemat satu jam membaca berkas kebijakan. Sisa perjalanannya singkat: paket melewati sebuah hook, cocok dengan aturan, lalu mencapai listener atau tidak. Daftar izin hanyalah pembukuan di sekitar tiga fakta itu.

Ikuti satu percobaan SSH sampai ke hook input

Klien mengirim SYN ke alamat host pada port 22, dan kernel memutuskan apakah paket itu untuk layanan lokal. Jika ya, jalur input berjalan dan kumpulan aturan menerima paket atau membuangnya. Keheningan berarti SYN mati sebelum listener melihatnya, sedangkan penolakan cepat berarti ada sesuatu yang menjawab dengan reset. Itu adalah putusan berbeda dari aturan berbeda, dan keduanya hasil yang sah.

Konfirmasikan listener berikutnya, karena tidak ada aturan yang bisa menyelamatkan layanan yang tidak ada. Jalankan ss -ltnp dan periksa bahwa sesuatu terikat pada port dan keluarga alamat yang Anda harapkan, lalu baca ssh -v di klien untuk melihat di mana ia berhenti.

Penerusan adalah keputusan terpisah

Di server VPN hook yang lebih menarik adalah forward, karena lalu lintas klien dirutekan melalui mesin alih-alih dikirimkan kepadanya. Host yang hanya menjalankan klien VPN-nya sendiri membutuhkan kumpulan aturan yang jauh lebih kecil daripada yang meneruskan paket orang lain. Mencampur kedua desain pada satu mesin menghasilkan aturan yang tampak benar dan tidak meloloskan apa pun.

Tulis kebijakan dalam sebagai pertanyaan tersendiri: alamat klien mana yang boleh mencapai tujuan mana melalui terowongan. Pertahankan jalur administratif, seperti SSH, pada jalur input dengan batasan sumbernya sendiri. Aturan forward permisif yang ditambahkan saat pengujian adalah cacat klasik yang bertahan lebih lama daripada pengujian, jadi tinjau seluruh kumpulan aturan setelah perubahan, bukan satu baris yang Anda edit. Membuka listener terowongan bukan izin bagi setiap klien yang terhubung untuk mengelola host.

Drop dan reject adalah tindakan, bukan kebijakan

Kebijakan rantai dasar menerima atau membuang, dan itulah seluruh daftar pilihan, seperti yang dinyatakan referensi nftables. Reject ada sebagai tindakan aturan dengan respons yang dipilih, karena itu menulisnya sebagai kebijakan gagal baik di nftables maupun iptables. Dalam praktiknya drop tidak memberi klien informasi apa pun, sedangkan reject memberinya kesalahan yang bisa ditindaklanjuti.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

Baca sketsa itu sebagai bentuk keputusan, bukan berkas untuk ditempel, karena rentang alamat adalah contoh. Reject eksplisit pada port SSH membuat klien tak berwenang gagal dalam satu detik alih-alih menunggu batas waktu, yang memperpendek proses debug Anda sendiri. Keheningan mencegah pemindaian biasa dan sama sekali tidak memberi tahu pengguna yang berwenang. Pilih per layanan dan tuliskan alasannya, karena jika tidak orang berikutnya akan mengubahnya kembali.

Pertahankan lalu lintas kendali yang benar-benar Anda butuhkan

Memblokir semua ICMP adalah bawaan populer yang merusak penemuan MTU jalur, dan gejalanya adalah koneksi yang terbentuk lalu tersendat pada paket yang lebih besar. Penemuan tetangga pada IPv6 bergantung pada tipe ICMPv6-nya sendiri, dan membuangnya memutus tautan sebelum aturan TCP mana pun diperiksa. Keduanya termasuk dalam daftar izin sebagai dependensi bernama, bukan sebagai izin menyeluruh. Kebijakan yang diam-diam merusak penemuan lebih buruk daripada yang mengizinkan sedikit lalu lintas diagnostik.

Izinkan status established dan related untuk koneksi yang Anda mulai sendiri, dan biarkan mesin yang sadar status menangani balasannya. Lalu pastikan jalur balasan tidak diblokir lebih jauh ke luar, karena pembatasan hanya-keluar di hulu menghasilkan batas waktu yang sama dengan yang hendak Anda salahkan pada host.

Buktikan pemulihan sebelum Anda menghentikan jalur lama

Biarkan sesi konsol tetap terbuka, terapkan perubahan, dan buka koneksi manajemen yang benar-benar baru dari terminal lain. Sesi yang sudah ada tidak membuktikan apa pun, karena bisa bertahan dari aturan yang memblokir setiap login baru, yang membuatnya menjadi positif palsu paling meyakinkan dalam pekerjaan firewall. Jika sistem pemantauan memeriksa host, tambahkan alamat sumbernya sebelum perubahan, bukan setelah peringatan pertama. Lalu uji satu paket besar dan satu paket kecil untuk membuktikan penemuan masih bekerja.

Untuk layanan VPN, ulangi dari klien yang belum pernah terhubung, karena sesi yang dilanjutkan dapat memakai ulang status yang harus dinegosiasikan sesi baru. Catat kumpulan aturan persisnya yang lolos, dengan checksum atau salinan, agar penyuntingan berikutnya bisa dibandingkan alih-alih ditebak. Koordinasikan dengan siapa pun yang memiliki urutan aturan, karena aturan yang lebih awal secara diam-diam mengalahkan aturan yang Anda tambahkan.

Artikel terkait