SSH- og VPN-inngangsregler: hva tillatelseslisten egentlig styrer

Koble til én gang før du endrer en regel, og noter om klienten henger eller blir avvist med en gang. Den ene forskjellen forteller deg hvilken beslutning som slapp pakken, og sparer en time med å lese policyfiler. Resten av turen er kort: pakken krysser en krok, treffer en regel og når enten en lytter eller ikke. En tillatelsesliste er bare bokføring rundt de tre faktaene.

Følg ett SSH-forsøk til inngangskroken

En klient sender en SYN til vertens adresse på port 22, og kjernen avgjør om pakken er for en lokal tjeneste. Er den det, kjører inngangsveien, og regelsettet godtar pakken eller forkaster den. Stillhet betyr at SYN døde før lytteren så den, mens en rask avvisning betyr at noe svarte med en tilbakestilling. Det er ulike kjennelser fra ulike regler, og begge er legitime utfall.

Bekreft deretter lytteren, for ingen regel redder en tjeneste som ikke er der. Kjør ss -ltnp og kontroller at noe er bundet til porten og adressefamilien du forventer, og les så ssh -v på klienten for å se hvor den stopper.

Videresending er en egen beslutning

På en VPN-server er den mer interessante kroken forward, fordi klienttrafikk rutes gjennom maskinen i stedet for å leveres til den. En vert som bare kjører sin egen VPN-klient trenger et mye mindre regelsett enn en som videresender andres pakker. Å blande de to designene på én maskin gir regler som ser riktige ut og ikke slipper noe gjennom.

Skriv den indre policyen som sitt eget spørsmål: hvilke klientadresser som kan nå hvilke mål gjennom tunnelen. Hold den administrative veien, for eksempel SSH, på inngangsveien med sin egen kildebegrensning. En ettergivende forward-regel som legges til under testing, er den klassiske feilen som overlever testen, så gjennomgå hele regelsettet etter en endring i stedet for linjen du redigerte. Å åpne tunnel-lytteren er ikke tillatelse for hver tilkoblet klient til å administrere verten.

Drop og reject er handlinger, ikke policyer

Policyen til en basiskjede godtar eller forkaster, og det er hele listen over valg, slik nftables-referansen sier. Reject finnes som en regelhandling med et valgt svar, og derfor feiler det å skrive den som policy både på nftables og på iptables. I praksis gir en drop klienten ingen informasjon, mens en reject gir den en feil den kan handle på.

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

Les den skissen som formen på en beslutning i stedet for en fil som skal limes inn, siden adresseområdene er eksempler. En eksplisitt reject på SSH-porten får en uautorisert klient til å feile på et sekund i stedet for å vente ut en tidsavbrudd, noe som forkorter din egen feilsøking. Stillhet avskrekker tilfeldig skanning og forteller en autorisert bruker absolutt ingenting. Velg per tjeneste og skriv ned hvorfor, ellers endrer neste person det tilbake.

Behold kontrolltrafikken du faktisk trenger

Å blokkere all ICMP er en populær standard som bryter sti-MTU-oppdagelse, og symptomet er en forbindelse som etableres og deretter stopper på større pakker. Nabo-oppdagelse på IPv6 avhenger av sine egne ICMPv6-typer, og å forkaste dem bryter lenken før noen TCP-regel blir spurt. Begge hører hjemme i tillatelseslisten som navngitte avhengigheter i stedet for som brede tillatelser. En policy som stille bryter oppdagelsen, er verre enn en som slipper inn litt diagnostisk trafikk.

Tillat tilstandene established og related for forbindelser du selv startet, og la den tilstandsfulle motoren håndtere svarene. Bekreft deretter at svarveien ikke er blokkert lenger ute, fordi en begrensning bare på utgående trafikk lenger opp gir samme tidsavbrudd som du var i ferd med å skylde på verten.

Bevis gjenoppretting før du pensjonerer den gamle veien

Hold en konsolløkt åpen, bruk endringen og åpne en helt ny administrasjonsforbindelse fra en annen terminal. En eksisterende økt beviser ingenting, fordi den kan overleve en regel som blokkerer hver ny innlogging, noe som gjør den til den mest overbevisende falske positive i brannmur-arbeid. Hvis et overvåkingssystem sjekker verten, legg til kildeadressen før endringen i stedet for etter den første alarmen. Test deretter én stor og én liten pakke for å bevise at oppdagelsen fortsatt virker.

For en VPN-tjeneste gjentas det fra en klient som aldri har vært tilkoblet, fordi en gjenopptatt økt kan gjenbruke tilstand som en fersk må forhandle. Skriv ned det nøyaktige regelsettet som besto, med en kontrollsum eller en kopi, slik at en senere redigering kan sammenlignes i stedet for gjettes. Koordiner med den som eier regelrekkefølgen, fordi en tidligere regel stille vinner over den du la til.