SSH- og VPN-inngangsreglar: kva tillatingslista eigentleg styrer

Kopla til éin gong før du endrar ein regel, og noter om klienten heng eller blir avvist med ein gong. Den eine skilnaden fortel deg kva avgjerd som sleppte pakken, og sparer ein time med å lese policyfiler. Resten av turen er kort: pakken kryssar ein krok, treffer ein regel og når anten ein lyttar eller ikkje. Ei tillatingsliste er berre bokføring rundt dei tre fakta.

Følg eitt SSH-forsøk til inngangskroken

Ein klient sender ein SYN til adressa til verten på port 22, og kjernen avgjer om pakken er for ei lokal teneste. Er han det, køyrer inngangsvegen, og regelsettet godtek pakken eller forkastar han. Stille betyr at SYN døydde før lyttaren såg han, medan ei rask avvising betyr at noko svara med ei tilbakestilling. Det er ulike kjennsler frå ulike reglar, og båe er legitime utfall.

Stadfest deretter lyttaren, for ingen regel reddar ei teneste som ikkje er der. Køyr ss -ltnp og kontroller at noko er bunde til porten og adressefamilien du ventar, og les så ssh -v på klienten for å sjå kvar han stoppar.

Vidaresending er ei eiga avgjerd

På ein VPN-server er den meir interessante kroken forward, fordi klienttrafikk blir ruta gjennom maskinen i staden for levert til han. Ein vert som berre køyrer sin eigen VPN-klient treng eit mykje mindre regelsett enn ein som vidaresender pakkane til andre. Å blande dei to designa på éin maskin gir reglar som ser riktige ut og slepp ingenting gjennom.

Skriv den indre policyen som eit eige spørsmål: kva klientadresser som kan nå kva mål gjennom tunnelen. Hald den administrative vegen, til dømes SSH, på inngangsvegen med si eiga kjeldeavgrensing. Ein ettergjevande forward-regel som blir lagd til under testing, er den klassiske feilen som overlever testen, så gå gjennom heile regelsettet etter ei endring i staden for linja du redigerte. Å opne tunnel-lyttaren er ikkje løyve for kvar tilkopla klient til å administrere verten.

Drop og reject er handlingar, ikkje policyar

Policyen til ein basiskjede godtek eller forkastar, og det er heile lista over val, slik nftables-referansen seier. Reject finst som ei regelhandling med eit valt svar, og difor feilar det å skrive han som policy både på nftables og på iptables. I praksis gir ein drop klienten ingen informasjon, medan ein reject gir han ein feil han 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 forma på ei avgjerd og ikkje som ei fil som skal limast inn, sidan adresseområda er døme. Ein eksplisitt reject på SSH-porten får ein uautorisert klient til å feile på eitt sekund i staden for å vente ut ein tidsavbrot, noko som forkortar di eiga feilsøking. Stille skræmer bort tilfeldig skanning og fortel ein autorisert brukar absolutt ingenting. Vel per teneste og skriv ned kvifor, elles endrar neste person det tilbake.

Hald kontrolltrafikken du faktisk treng

Å blokkere all ICMP er ein populær standard som bryt sti-MTU-oppdaging, og symptomet er ei tilkobling som blir etablert og deretter stoppar på større pakkar. Nabo-oppdaging på IPv6 er avhengig av sine eigne ICMPv6-typar, og å forkaste dei bryt lenkja før nokon TCP-regel blir spurd. Båe høyrer heime i tillatingslista som namngjevne avhengnader i staden for som breie løyve. Ein policy som stille bryt oppdaginga, er verre enn ein som slepp inn litt diagnostisk trafikk.

Tillat tilstandane established og related for tilkoblingar du sjølv starta, og la den tilstandsfulle motoren handsame svara. Stadfest deretter at svarvegen ikkje er blokkert lenger ute, fordi ei avgrensing berre på utgåande trafikk lenger opp gir same tidsavbrot som du var i ferd med å skylde på verten.

Prov gjenoppretting før du pensjonerer den gamle vegen

Hald ei konsolløkt open, bruk endringa og opne ei heilt ny administrasjonstilkobling frå ein annan terminal. Ei eksisterande økt provar ingenting, fordi ho kan overleve ein regel som blokkerer kvar ny innlogging, noko som gjer ho til den mest overtydande falske positive i brannmur-arbeid. Viss eit overvakingssystem sjekkar verten, legg til kjeldeadressa før endringa i staden for etter den første alarmen. Test deretter éin stor og éin liten pakke for å prove at oppdaginga framleis verkar.

For ei VPN-teneste blir det gjenteke frå ein klient som aldri har vore tilkopla, fordi ei gjenoppteken økt kan gjenbruke tilstand som ei fersk må forhandle. Skriv ned det nøyaktige regelsettet som bestod, med ein kontrollsum eller ei kopi, slik at ei seinare redigering kan samanliknast i staden for gjetast. Koordiner med den som eig regelrekkjefølgja, fordi ein tidlegare regel stille vinn over den du la til.