Peraturan masuk SSH dan VPN: apa yang sebenarnya dikawal oleh senarai putih

Sambung sekali sebelum anda menukar peraturan dan catat sama ada klien tergantung atau ditolak serta-merta. Perbezaan tunggal itu memberitahu anda keputusan mana yang menggugurkan paket dan menjimatkan sejam membaca fail dasar. Baki perjalanan itu singkat: paket melintasi sesuatu cangkuk, sepadan dengan peraturan dan sama ada sampai kepada pendengar atau tidak. Senarai putih hanyalah perakaunan di sekitar ketiga-tiga fakta itu.

Jejaki satu percubaan SSH sehingga cangkuk input

Klien menghantar SYN ke alamat hos pada port 22, dan kernel memutuskan sama ada paket itu untuk perkhidmatan tempatan. Jika ya, laluan input berjalan dan set peraturan menerima paket itu atau membuangnya. Kesenyapan bermakna SYN mati sebelum pendengar melihatnya, manakala penolakan pantas bermakna sesuatu menjawab dengan tetapan semula. Itu keputusan berbeza daripada peraturan berbeza, dan kedua-duanya hasil yang sah.

Seterusnya sahkan pendengar, kerana tiada peraturan dapat menyelamatkan perkhidmatan yang tiada. Jalankan ss -ltnp dan semak sama ada sesuatu terikat pada port dan keluarga alamat yang anda jangkakan, kemudian baca ssh -v pada klien untuk melihat di mana ia berhenti.

Pemajuan ialah keputusan berasingan

Pada pelayan VPN cangkuk yang lebih menarik ialah forward, kerana trafik klien dihalakan melalui mesin itu dan bukan diserahkan kepadanya. Hos yang hanya menjalankan klien VPN sendiri memerlukan set peraturan yang jauh lebih kecil daripada hos yang memajukan paket orang lain. Mencampurkan kedua-dua reka bentuk pada satu mesin menghasilkan peraturan yang kelihatan betul dan tidak melepaskan apa-apa.

Tulis dasar dalaman sebagai soalan tersendiri: alamat klien mana yang boleh mencapai destinasi mana melalui terowong. Kekalkan laluan pentadbiran, seperti SSH, pada laluan input dengan sekatan sumbernya sendiri. Peraturan forward permisif yang ditambah semasa ujian ialah kecacatan klasik yang hidup lebih lama daripada ujian, jadi selepas perubahan semak seluruh set peraturan dan bukan baris yang anda sunting. Membuka pendengar terowong bukan kebenaran untuk setiap klien bersambung mentadbir hos.

Drop dan reject ialah tindakan, bukan dasar

Dasar rantaian asas menerima atau membuang dan itulah keseluruhan senarai pilihan, seperti yang dinyatakan rujukan nftables. Penolakan wujud sebagai tindakan peraturan dengan respons yang dipilih, sebab itulah menulisnya sebagai dasar gagal pada nftables dan iptables. Dalam amalan drop tidak memberi klien sebarang maklumat, manakala reject memberinya ralat yang boleh 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 lakaran itu sebagai bentuk keputusan dan bukan fail untuk ditampal, kerana julat alamat ialah contoh. Reject eksplisit pada port SSH menyebabkan klien tanpa kebenaran gagal dalam satu saat dan bukan menunggu tamat masa, yang memendekkan penyahpepijatan anda sendiri. Kesenyapan menghalang pengimbasan kasual dan tidak memberitahu pengguna yang dibenarkan apa-apa. Pilih mengikut perkhidmatan dan catat sebabnya, jika tidak orang seterusnya akan menukarnya kembali.

Kekalkan trafik kawalan yang benar-benar anda perlukan

Menyekat semua ICMP ialah lalai popular yang merosakkan penemuan MTU laluan, dan gejalanya ialah sambungan yang terbentuk kemudian tersekat pada paket lebih besar. Penemuan jiran pada IPv6 bergantung pada jenis ICMPv6 sendiri, dan membuangnya memutuskan pautan sebelum mana-mana peraturan TCP dirujuk. Kedua-duanya tergolong dalam senarai putih sebagai kebergantungan bernama dan bukan sebagai kebenaran menyeluruh. Dasar yang merosakkan penemuan secara senyap lebih buruk daripada yang menerima sedikit trafik diagnostik.

Benarkan keadaan established dan related untuk sambungan yang anda mulakan sendiri, dan biarkan enjin sedar keadaan mengendalikan balasan. Kemudian sahkan bahawa laluan balasan tidak disekat lebih jauh di luar, kerana sekatan keluar sahaja di huluan menghasilkan tamat masa yang sama yang anda hendak salahkan pada hos.

Buktikan pemulihan sebelum anda berhenti menggunakan laluan lama

Biarkan sesi konsol terbuka, gunakan perubahan dan buka sambungan pengurusan yang benar-benar baharu dari terminal lain. Sesi sedia ada tidak membuktikan apa-apa, kerana ia mungkin bertahan daripada peraturan yang menyekat setiap log masuk baharu, yang menjadikannya positif palsu paling meyakinkan dalam kerja tembok api. Jika sistem pemantauan memeriksa hos, tambahkan alamat sumbernya sebelum perubahan dan bukan selepas amaran pertama. Kemudian uji satu paket besar dan satu paket kecil untuk membuktikan penemuan masih berfungsi.

Untuk perkhidmatan VPN, ulangi daripada klien yang tidak pernah bersambung, kerana sesi yang disambung semula boleh menggunakan semula keadaan yang sesi baharu mesti rundingkan. Catat set peraturan tepat yang lulus, dengan checksum atau salinan, supaya suntingan kemudian dapat dibandingkan dan bukan diteka. Selaraskan dengan pemilik susunan peraturan, kerana peraturan lebih awal secara senyap mengalahkan yang anda tambah.