Reguloj pri eniro por SSH kaj VPN: kion la permeslisto vere regas

Konektiĝu unufoje antaŭ ol ŝanĝi regulon kaj notu, ĉu la kliento pendas aŭ estas tuj rifuzata. Tiu unu diferenco diras al vi, kiu decido forĵetis la paketon, kaj ŝparas horon da legado de politikaj dosieroj. La resto de la vojo estas mallonga: la paketo trapasas hokon, kongruas kun regulo kaj aŭ atingas aŭskultanton aŭ ne. Permeslisto estas nur librotenado ĉirkaŭ tiuj tri faktoj.

Sekvu unu SSH-provon ĝis la enira hoko

Kliento sendas SYN al la adreso de la gastiganto sur pordo 22, kaj la kerno decidas, ĉu tiu paketo estas por loka servo. Se jes, la enira vojo ruliĝas kaj la reguloaro aŭ akceptas la paketon aŭ forĵetas ĝin. Silento signifas, ke la SYN mortis antaŭ ol la aŭskultanto vidis ĝin, dum rapida rifuzo signifas, ke io respondis per restarigo. Tiuj estas malsamaj verdiktoj el malsamaj reguloj, kaj ambaŭ estas legitimaj rezultoj.

Poste konfirmu la aŭskultanton, ĉar neniu regulo povas savi servon, kiu ne ĉeestas. Rulu ss -ltnp kaj kontrolu, ke io estas ligita al la pordo kaj adresfamilio, kiun vi atendas, poste legu ssh -v ĉe la kliento por vidi, kie ĝi haltas.

Plusendado estas aparta decido

Sur VPN-servilo la pli interesa hoko estas forward, ĉar klienta trafiko estas enkursigata tra la maŝino anstataŭ liverata al ĝi. Gastiganto, kiu rulas nur sian propran VPN-klienton, bezonas multe pli malgrandan reguloaron ol unu, kiu plusendas paketojn de aliaj homoj. Miksi la du dezajnojn sur unu maŝino produktas regulojn, kiuj aspektas ĝustaj kaj trapasigas nenion.

Skribu la internan politikon kiel apartan demandon: kiuj klientaj adresoj rajtas atingi kiujn celojn tra la tunelo. Tenu la administran vojon, ekzemple SSH, sur la enira vojo kun propra fontlimigo. Permesema forward-regulo aldonita dum testado estas la klasika difekto, kiu postvivas la teston, do post ŝanĝo revizu la tutan reguloaron anstataŭ la unu linion, kiun vi redaktis. Malfermi la tunelan aŭskultanton ne estas permeso por ĉiu konektita kliento administri la gastiganton.

Forĵeti kaj rifuzi estas agoj, ne politikoj

La politiko de baza ĉeno akceptas aŭ forĵetas, kaj tio estas la tuta listo de elektoj, kiel diras la nftables-referenco. Rifuzo ekzistas kiel regula ago kun elektita respondo, kaj tial skribi ĝin kiel politikon malsukcesas kaj ĉe nftables kaj ĉe iptables. Praktike forĵeto donas al la kliento neniun informon, dum rifuzo donas al ĝi eraron, pri kiu ĝi povas agi.

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

Legu tiun skizon kiel la formon de decido, ne kiel dosieron por alglui, ĉar la adresaj intervaloj estas ekzemploj. Eksplicita rifuzo sur la SSH-pordo igas neaŭtorizitan klienton malsukcesi en sekundo anstataŭ atendi temporabon, kio mallongigas vian propran sencimigadon. Silento malinstigas hazardan skanadon kaj diras al rajtigita uzanto absolute nenion. Elektu laŭ servo kaj skribu kial, ĉar alie la sekva homo ŝanĝos ĝin reen.

Konservu la stiran trafikon, kiun vi vere bezonas

Bloki ĉiun ICMP estas populara defaŭlto, kiu rompas malkovron de voja MTU, kaj la simptomo estas konekto, kiu establiĝas kaj poste blokiĝas ĉe pli grandaj paketoj. Najbarmalkovro ĉe IPv6 dependas de propraj ICMPv6-tipoj, kaj forĵeti ilin rompas la ligon antaŭ ol iu ajn TCP-regulo estas konsultita. Ambaŭ apartenas al la permeslisto kiel nomitaj dependecoj, ne kiel ĝeneralaj permesoj. Politiko, kiu silente rompas malkovron, estas pli malbona ol unu, kiu enlasas iom da diagnoza trafiko.

Permesu la statojn established kaj related por konektoj, kiujn vi mem iniciatis, kaj lasu la statokonscian motoron pritrakti la respondojn. Poste konfirmu, ke la responda vojo ne estas blokita pli ekstere, ĉar limigo nur por elira trafiko pli supre produktas la saman temporabon, kiun vi pretis kulpigi al la gastiganto.

Pruvu reakiron antaŭ ol emeritigi la malnovan vojon

Tenu konsolan sesion malfermita, apliku la ŝanĝon kaj malfermu tute novan administran konekton el alia terminalo. Ekzistanta sesio pruvas nenion, ĉar ĝi povas postvivi regulon, kiu blokas ĉiun novan ensaluton, kio faras ĝin la plej konvinka falsa pozitivo en fajroŝirma laboro. Se monitora sistemo kontrolas la gastiganton, aldonu ĝian fontadreson antaŭ la ŝanĝo, ne post la unua alarmo. Poste testu unu grandan kaj unu malgrandan paketon por pruvi, ke malkovro ankoraŭ funkcias.

Por VPN-servo ripetu el kliento, kiu neniam konektiĝis, ĉar daŭrigita sesio povas reuzi staton, kiun freŝa devas interkonsenti. Notu la ĝustan reguloaron, kiu sukcesis, kun kontrolsumo aŭ kopio, por ke posta redakto povu esti komparata anstataŭ divenata. Kunordiĝu kun tiu, kiu posedas la regulordon, ĉar pli frua regulo silente venkas tiun, kiun vi aldonis.