Rregullat e hyrjes SSH dhe VPN: çfarë kontrollon në të vërtetë lista e lejeve
Ndiqni një lidhje nga klienti te hosti: cilin grep kalon, pse ngecja dhe refuzimi nënkuptojnë rregulla të ndryshme dhe pse refuzimi nuk është kurrë politikë.
Lidhuni një herë para se të ndryshoni një rregull dhe vini re nëse klienti ngec ose refuzohet menjëherë. Ky ndryshim i vetëm ju tregon cili vendim e hodhi paketën dhe kursen një orë lexim të skedarëve të politikës. Pjesa tjetër e udhëtimit është e shkurtër: paketa kalon një grep, përputhet me një rregull dhe ose arrin te një dëgjues ose jo. Lista e lejeve është thjesht kontabilitet rreth këtyre tre fakteve.
Ndiqni një përpjekje SSH deri te grepi i hyrjes
Klienti dërgon një SYN në adresën e hostit në portën 22, dhe kerneli vendos nëse ajo paketë është për një shërbim lokal. Nëse po, shtegu i hyrjes ekzekutohet dhe grupi i rregullave e pranon paketën ose e hedh. Heshtja do të thotë që SYN vdiq para se dëgjuesi ta shihte, ndërsa një refuzim i shpejtë do të thotë që diçka u përgjigj me një rivendosje. Këto janë verdikte të ndryshme nga rregulla të ndryshme dhe të dyja janë rezultate legjitime.
Më pas verifikoni dëgjuesin, sepse asnjë rregull nuk shpëton një shërbim që nuk ekziston. Ekzekutoni ss -ltnp dhe kontrolloni nëse diçka është e lidhur me portën dhe familjen e adresave që prisni, pastaj lexoni ssh -v në klient për të parë ku ndalon.
Përcjellja është një vendim më vete
Në një server VPN grepi më interesant është forward, sepse trafiku i klientit rrugëtohet përmes makinës në vend që t'i dorëzohet asaj. Një host që drejton vetëm klientin e vet VPN ka nevojë për një grup rregullash shumë më të vogël sesa ai që përcjell paketat e njerëzve të tjerë. Përzierja e të dyja modeleve në një makinë të vetme prodhon rregulla që duken të sakta dhe nuk lënë asgjë të kalojë.
Shkruani politikën e brendshme si një pyetje më vete: cilat adresa klienti mund të arrijnë cilat destinacione përmes tunelit. Mbani shtegun administrativ, si SSH, në shtegun e hyrjes me kufizimin e vet të burimit. Një rregull forward lejues i shtuar gjatë testimit është defekti klasik që mbijeton testin, prandaj pas një ndryshimi rishikoni të gjithë grupin e rregullave dhe jo rreshtin që redaktuam. Hapja e dëgjuesit të tunelit nuk është leje që çdo klient i lidhur të administrojë hostin.
Hedhja dhe refuzimi janë veprime, jo politika
Politika e një zinxhiri bazë pranon ose hedh dhe kjo është e gjithë lista e zgjedhjeve, siç thotë referenca e nftables. Refuzimi ekziston si veprim rregulli me një përgjigje të zgjedhur, prandaj shkrimi i tij si politikë dështon si në nftables ashtu edhe në iptables. Në praktikë drop nuk i jep klientit asnjë informacion, ndërsa reject i jep një gabim mbi të cilin mund të veprojë.
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
}
}
Lexojeni atë skicë si formën e një vendimi dhe jo si skedar për t'u ngjitur, sepse intervalet e adresave janë shembuj. Një reject i qartë në portën SSH e bën një klient të paautorizuar të dështojë në një sekondë në vend që të presë një afat, gjë që shkurton korrigjimin tuaj. Heshtja pengon skanimin rastësor dhe nuk i thotë absolutisht asgjë një përdoruesi të autorizuar. Zgjidhni për çdo shërbim dhe shkruani përse, përndryshe personi tjetër do ta kthejë mbrapsht.
Mbani trafikun e kontrollit që ju nevojitet vërtet
Bllokimi i të gjithë ICMP është një parazgjedhje popullore që prish zbulimin e MTU-së së shtegut, dhe simptomi është një lidhje që vendoset dhe pastaj ngec në paketat më të mëdha. Zbulimi i fqinjëve në IPv6 varet nga llojet e veta ICMPv6, dhe hedhja e tyre e prish lidhjen para se të konsultohet ndonjë rregull TCP. Të dyja i përkasin listës së lejeve si varësi të emërtuara dhe jo si leje të përgjithshme. Një politikë që prish zbulimin në heshtje është më e keqe sesa një që lejon pak trafik diagnostik.
Lejoni gjendjet established dhe related për lidhjet që keni nisur vetë, dhe lëreni motorin me gjendje të merret me përgjigjet. Pastaj verifikoni që shtegu i përgjigjes nuk është i bllokuar më tej, sepse një kufizim vetëm për trafikun dalës më lart prodhon të njëjtin afat që po bëheshit gati t'ia ngarkonit hostit.
Provoni rikuperimin para se të hiqni dorë nga shtegu i vjetër
Mbani hapur një sesion konsol, zbatoni ndryshimin dhe hapni një lidhje administrimi plotësisht të re nga një terminal tjetër. Një sesion ekzistues nuk provon asgjë, sepse mund t'i mbijetojë një rregulli që bllokon çdo hyrje të re, gjë që e bën atë pozitivin e rrejshëm më bindës në punën me mure zjarri. Nëse një sistem monitorimi kontrollon hostin, shtoni adresën e burimit të tij para ndryshimit dhe jo pas alarmit të parë. Pastaj provoni një paketë të madhe dhe një të vogël për të provuar se zbulimi ende funksionon.
Për një shërbim VPN, përsëriteni nga një klient që nuk është lidhur kurrë, sepse një sesion i rifilluar mund të ripërdorë një gjendje që një i re duhet të negociojë. Shkruani grupin e saktë të rregullave që kaloi, me një checksum ose një kopje, që një redaktim i mëvonshëm të krahasohet dhe jo të hamendësohet. Koordinoni me atë që zotëron renditjen e rregullave, sepse një rregull i mëparshëm fiton në heshtje mbi atë që shtuat.