Ny UFW-regel, gamal tilkopling: den etablerte tilstanden vinn

Å leggje til ein avvisningsregel og sjå ei open nedlasting halde fram er ikkje ein UFW-feil. Regelen du la til, står etter reglar som alt har godteke straumen, og ei tilkopling som vart etablert tidlegare, held fram med å passe med dei. Å rette det tyder å setje han inn på rett plass og forstå kva dei tidlegare reglane lovar. Den smale versjonen av den endringa følgjer.

Rekkjefylgja avgjer, ikkje det at regelen finst

UFW er eit grensesnitt som skriv netfilter-reglar i trinn: ein rammedel som køyrer før brukarreglane, deretter sjølve brukarreglane, deretter ein del som køyrer etter dei. Standardreglane føre godtek trafikk frå etablerte og relaterte tilkoplingar, og desse reglane vert vurderte før noko du legg til med ein vanleg allow eller deny. UFW-kommandoreferansen dokumenterer innsetjingssyntaksen og den nummererte statusvisinga som denne endringa er avhengig av.

Den rekkjefylgja forklarer overraskinga. Den nye regelen din er ekte, og han står i rett tabell, men han er ikkje den første avgjerda pakken møter. Ei tilkopling som alt vert spora som etablert, når aldri fram til han.

Bruk route-reglar til denne jobben, fordi pakken vert vidaresend gjennom gatewayen i staden for å vere adressert til gatewayen sine eigne tenester. Ein inndataregel ville filtrert feil trafikk og sett ut som han ikkje gjorde noko.

Set inn over den breie løyva

Førehandsvis innsetjinga før du brukar henne, og stadfest at regelen ikkje alt finst ein annan stad i lista. Å duplisere ein identisk policy gjer seinare fjerning tvitydig, og den som fjernar feil kopi, merkar det ikkje på veker.

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

Viser førehandsvisinga nøyaktig éin regel på posisjonen du ventar, brukar du same kommandoen utan dry-run-flagg. Posisjon 1 plasserer han over dei breiare brukarløyva, ikkje over rammereglane som vart gjennomgått tidlegare. Stadfest at grensesnittnamnet samsvarar med tunnel-eininga på denne gatewayen, fordi ein regel som er bunden til eit grensesnitt som ikkje finst lenger, vil stå i lista og sjå rett ut medan han ikkje passar med noko. Gi einingreferansen nytt namn før du brukar han, ikkje etter at testen feilar.

Det står inga målport i den regelen, så han avviser kvar TCP-port på den adressa i staden for berre HTTPS. Er hensikta éin teneste, nemn porten; ein regel som er breiare enn policyen, er ein framtidig hending som ventar på sin første lesar.

Avgrens kjelda til éi adresse berre om den adressa er bunden til den tiltenkte identiteten. Ein VPN-pool med dynamisk tildeling kan gi same adresse til ein annan klient i morgon, og avvisinga vil følgje adressa i staden for personen.

Etablerte straumar overlever den nye regelen

Tilkoplingssporing er grunnen til at den eksisterande økta held fram. Når ein straum er registrert som etablert, godtek reglane føre pakkane hans før avvisinga di vert konsultert, og overføringa vert ferdig som om ingenting var endra. Derfor seier ein test med ein nettlesar som brukar ei open tilkopling på nytt deg ingenting om den nye policyen. Ei avvising kan verke ubrukeleg minutt etter utrulling og vere heilt effektiv for den neste brukaren som koplar til.

Om kravet inneber å kutte levande trafikk, kan denne brukarregelendringa ikkje levere det. Å kalle tilbake spora tilstand er ei eiga handling med eigen radius, og ho høyrer til brannmureigaren snarare enn den som la til regelen. Å tøme alle tilkoplingar på ein gateway for å få éi økt til å forsvinne er den typen retting som skapar ei anna hending.

Hugs grensene òg. Denne regelen seier ingenting om ICMP, UDP eller IPv6, så ein vellukka ping er ikkje prov på at avvisinga mislukkast. Éi IPv4-adresse er heller ikkje eit nettstad: eit namn kan slåast opp til fleire adresser, og berre den du nemnde, er dekt.

Test med ein fersk straum

Les dei nummererte brukarreglane og den effektive rå visinga, og opne deretter ei ny tilkopling frå den valde klienten:

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

Den rå visinga er viktig fordi status utelèt rammereglar som er skrivne for hand, så ho kan få rekkjefylgja til å sjå annleis ut enn det kjernen handhevar. Samanlikn dei to før du konkluderer med at ein regel står på feil stad.

Kontroller deretter dei to kontrollane som viser at regelen er avgrensa og ikkje brei: ein tillaten destinasjon frå same klient verkar framleis, og ein annan klient når framleis den avviste destinasjonen om policyen hans tillèt det. Ei avvising som bryt båe testane, er ei policyendring, ikkje ei målretta handling.

Når testen er over, fjernar du berre regelen du la til, ved å gjenta han nøyaktig. Er policyen permanent, overleverer du han til brannmureigaren med klientidentiteten, eigaren av destinasjonen og ein revisjonsdato, slik at ei gjenbrukt tunneladresse ikkje etterlèt ei forelda avvising.