Sådan begrænser du adgangen mellem to VPN-forbundne kontorer

En tunnel mellem lokationer svarer på ét spørgsmål, om de to kontorer kan udveksle pakker, og lader det vigtige stå åbent: hvilken filialenhed der må nå hvilken central tjeneste. At behandle tunnelen som gensidig tillid er måden, hvorpå en gæstelaptop ender på samme vej som finansserveren. Løsningen er ikke en bedre tunnel, men en udtrykkelig tilladelsesliste, der håndhæves efter dekryptering. Denne vejledning tager listen fra definition til en bevist afvisning.

Arbejd i denne rækkefølge, og udvid ikke tunnelruten, før politiktrinnene nedenfor består.

Skriv matricen, før du rører gatewayen

En brugbar række nævner tre ting: en kildegruppe, en målmaskine eller et tjenestenetværk og den protokol og port, som applikationen faktisk bruger. Filialen og datacentret er ikke poster. Private DNS- og godkendelsestjenester fortjener egne rækker, kun når applikationen ikke kan fungere uden dem.

Gruppér kilder efter rolle frem for efter subnetbekvemmelighed: personale, gæster, administration. Når alle tre deler et fladt LAN, kan gatewayen ikke skelne dem på netværkslaget, så identitetskontroller eller segmentering skal komme først. Sæt derefter matricen på skrift med en ejer og en revisionsdato på hver række.

Håndhæv der, hvor pakkerne dekrypteres

Reglerne, der tillader IKE og ESP, bygger kun den ydre tunnel. Den indre trafik ankommer i klartekst på tunnelinterfacet, og det er der, tilladelseslisten hører til: en videresendelseskæde på den dekrypterende enhed, standarddrop, én regel pr. matrixrække. På Linux-gateways betyder det videresendelse aktiveret og filterregler på tunnelenheden, ikke på det fysiske uplink, som strongSwans vejledning om videresendelse forklarer.

Trafikvælgere er en routingbeslutning, ikke en autorisationsbeslutning. En bred vælger, der dækker begge subnets, kan være rigtig til routing, mens firewallen stadig kun tillader TCP 443 til én vært. Vælgeren forhandles til tunnelen og beskriver, hvad der må komme ind i den, ikke hvad en given enhed må bruge. Udvid aldrig en firewallregel, fordi vælgeren er bred.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT og overlappende subnets ændrer reglerne

Når filialens gateway oversætter hver vært til én adresse før tunnelen, falder hver kildebaseret række sammen i den ene adresse. Enten stop med at oversætte tunneltrafik, eller accepter at regler skal hvile på noget andet, fx den oprindelige kildeadresse, der er registreret før oversættelsen. Den fjerne ende har samme problem, fordi målværten ser adressen efter NAT og ikke den oprindelige.

Overlappende områder er den anden fælde. To kontorer, der begge bruger 192.168.1.0/24, kan ikke beskrives i én politiktabel uden at mappe en side, og en mapping er ikke en erstatning for adressering, der ikke kolliderer. Ret planen, før du skriver regler, du senere skal vikle ud igen.

Bevis en afvisning, ikke bare en succes

At teste den tilladte applikation alene beviser meget lidt, fordi en eftergivende regel et sted længere oppe giver samme resultat.

Fra en almindelig filialenhed nås den tilsigtede tjeneste, og bekræft at hele sessionen virker. Prøv derefter et mål, der skal forblive lukket, fx en administrativ port på en server, som filialen ikke har noget at gøre med, og læs den tæller eller logpost, der droppede den. At slå regelsættet fra for at se, om det virker, ugyldiggør testen og efterlader gatewayen åben, mens du kigger.

Hold listen levende

Applikationer flytter sig, og en regel, der overlever sin applikation, bliver et hul, som ingen ejer. Sæt revisionsdatoen på rækken, og ændr vælgerens omfang og firewallreglen i samme vedligeholdelsestrin, når en tjeneste skifter adresse.

Begrænsninger på værtsniveau betyder stadig noget bag tunnelen: serverens egen firewall bør kun acceptere filialens område for den tjeneste, den udstiller. To lag, der er enige, er lettere at revidere end ét lag, der stoles fuldt ud.