SSH un VPN ieejas noteikumi: ko atļauto saraksts patiešām kontrolē

Izveidojiet savienojumu vienreiz pirms noteikuma maiņas un pierakstiet, vai klients uzkaras vai tiek nekavējoties atteikts. Šī vienīgā atšķirība pasaka, kurš lēmums nometa paketi, un ietaupa stundu politikas failu lasīšanas. Pārējais ceļš ir īss: pakete šķērso āķi, atbilst noteikumam un vai nu sasniedz klausītāju, vai ne. Atļauto saraksts ir tikai uzskaite ap šiem trim faktiem.

Izsekojiet vienam SSH mēģinājumam līdz ieejas āķim

Klients sūta SYN uz resursdatora adresi 22. portā, un kodols izlemj, vai šī pakete ir paredzēta vietējam servisam. Ja tā, ieejas ceļš darbojas un noteikumu kopa paketi pieņem vai izmet. Klusums nozīmē, ka SYN nomira pirms tam, kad klausītājs to ieraudzīja, bet ātrs atteikums nozīmē, ka kaut kas atbildēja ar atiestatīšanu. Tie ir dažādu noteikumu dažādi spriedumi, un abi ir likumīgi iznākumi.

Pēc tam apstipriniet klausītāju, jo neviens noteikums neizglābs servisu, kas neeksistē. Palaidiet ss -ltnp un pārbaudiet, vai kaut kas ir piesaistīts gaidītajam portam un adrešu saimei, pēc tam izlasiet ssh -v klientā, lai redzētu, kur tas apstājas.

Pārsūtīšana ir atsevišķs lēmums

VPN serverī interesantākais āķis ir forward, jo klienta trafiks tiek maršrutēts caur mašīnu, nevis piegādāts tai. Resursdatoram, kurā darbojas tikai paša VPN klients, vajadzīga daudz mazāka noteikumu kopa nekā tam, kas pārsūta citu cilvēku paketes. Abu dizainu sajaukšana vienā mašīnā rada noteikumus, kas izskatās pareizi un neko nelaiž cauri.

Rakstiet iekšējo politiku kā atsevišķu jautājumu: kuras klienta adreses var sasniegt kādus galamērķus caur tuneli. Turiet administratīvo ceļu, piemēram, SSH, ieejas ceļā ar savu avota ierobežojumu. Testēšanas laikā pievienotais atļaujošais forward noteikums ir klasiskais defekts, kas pārdzīvo testu, tāpēc pēc izmaiņām pārskatiet visu kopu, nevis to vienu rindu, ko rediģējāt. Tuneļa klausītāja atvēršana nav atļauja katram pievienotajam klientam pārvaldīt resursdatoru.

Nomešana un atteikšana ir darbības, nevis politikas

Bāzes ķēdes politika pieņem vai nomet, un tas ir viss izvēļu saraksts, kā norāda nftables dokumentācija. Atteikums pastāv kā noteikuma darbība ar izvēlētu atbildi, tāpēc tā rakstīšana kā politika neizdodas gan nftables, gan iptables gadījumā. Praksē drop klientam nesniedz nekādu informāciju, bet reject dod tam kļūdu, ar ko tas var strādāt.

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
    }
}

Lasiet šo skici kā lēmuma formu, nevis kā failu ielīmēšanai, jo adrešu diapazoni ir piemēri. Nepārprotams reject SSH portā liek neatļautam klientam neizdoties sekundes laikā, nevis gaidīt noildzi, un tas saīsina jūsu pašu atkļūdošanu. Klusums attur no nejaušas skenēšanas un neatļautam lietotājam nepasaka absolūti neko. Izvēlieties pēc pakalpojuma un pierakstiet kāpēc, citādi nākamais cilvēks to pārslēgs atpakaļ.

Saglabājiet vadības trafiku, kas jums patiešām vajadzīgs

Visu ICMP bloķēšana ir populārs noklusējums, kas salauž ceļa MTU atklāšanu, un simptoms ir savienojums, kas izveidojas un pēc tam iestrēgst pie lielākām paketēm. Kaimiņu atklāšana IPv6 ir atkarīga no saviem ICMPv6 tipiem, un to nomešana pārtrauc saiti pirms jebkura TCP noteikuma izskatīšanas. Abi pieder atļauto sarakstam kā nosauktas atkarības, nevis kā vispārīgas atļaujas. Politika, kas klusi salauž atklāšanu, ir sliktāka par to, kas pieļauj nedaudz diagnostikas trafika.

Atļaujiet stāvokļus established un related savienojumiem, ko sākāt paši, un ļaujiet stāvokli izsekojošajam dzinējam apstrādāt atbildes. Pēc tam apstipriniet, ka atbildes ceļš nav bloķēts tālāk, jo ierobežojums tikai izejošajam trafikam augstāk rada to pašu noildzi, ko grasījāties vainot resursdatorā.

Pierādiet atjaunošanu pirms vecā ceļa pamešanas

Turiet atvērtu konsoles sesiju, piemērojiet izmaiņas un atveriet pilnīgi jaunu pārvaldības savienojumu no cita termināļa. Esošā sesija neko nepierāda, jo tā var pārdzīvot noteikumu, kas bloķē katru jaunu pieteikšanos, un tas padara to par pārliecinošāko viltus pozitīvo ugunsmūra darbā. Ja uzraudzības sistēma pārbauda resursdatoru, pievienojiet tās avota adresi pirms izmaiņām, nevis pēc pirmā brīdinājuma. Pēc tam pārbaudiet vienu lielu un vienu mazu paketi, lai pierādītu, ka atklāšana joprojām darbojas.

VPN pakalpojumam atkārtojiet no klienta, kas nekad nav savienojies, jo atsākta sesija var atkārtoti izmantot stāvokli, par ko svaigai jāvienojas. Pierakstiet precīzo noteikumu kopu, kas izturēja, ar kontrolsummu vai kopiju, lai vēlāku labojumu varētu salīdzināt, nevis minēt. Saskaņojiet ar to, kam pieder noteikumu secība, jo agrāks noteikums klusi uzvar jūsu pievienoto.