Pilven tietoturvaryhmä VPN:lle: avaa kuuntelija, älä kaikkea

VPN-palvelin käy, asiakas aikakatkaisee, ja ensimmäinen vaisto on lisätä tietoturvaryhmään sääntö, joka sallii kaiken. Joskus se saa sen toimimaan, ja se on huonoin lopputulos, koska nyt kukaan ei tiedä, mikä raja todella suljettiin. Asiakkaan ja daemonin välissä on neljä erillistä suodatinta, ja vain yksi niistä on tietoturvaryhmä.

Nimeä protokolla ennen sääntöä

Sääntö on protokolla, porttialue ja lähde. WireGuard kuuntelee UDP:llä, yleensä 51820. OpenVPN on yleensä UDP tai TCP 1194 kokoonpanosta riippuen. IPsec tarvitsee IKE-vaihdon UDP 500 ja 4500 -portilla sekä itse ESP-protokollan, joka on protokollanumero eikä portti. TCP:n arvaaminen siksi, että muut säännöt ovat TCP, johtaa sääntöön, joka näyttää oikealta eikä vastaa mitään.

Lue kuuntelija käynnissä olevasta palvelusta, älä opetusohjeesta. Yhteen osoitteeseen sidottu daemon ei hyväksy toiseen osoitteeseen saapuvaa liikennettä.

Rajoita lähde suunnittelun sallimaan asiakasalueeseen koko internetin sijaan.

Tietoturvaryhmät ovat tilallisia; aliverkon ACL:t eivät ole

Tietoturvaryhmät ovat tilallisia ja vain sallivia: sallittu saapuva yhteys saa vastauksensa automaattisesti, eikä ole hylkäyssääntöä, jota miettiä. Aliverkon ACL:t ovat tilattomia ja ne arvioidaan molempiin suuntiin, joten saapuva sallinta ilman vastaavaa lähtevää hetkellistä aluetta epäonnistuu silti. Tämä ero selittää monet säännöt, jotka näyttävät konsolissa oikeilta.

Varmista myös, mikä käytäntö on liitetty käynnissä olevaan päätepisteeseen, sillä instanssilla voi olla useampi kuin yksi ryhmä, eikä liittämättömän ryhmän sääntö muuta mitään.

Voimassa oleva käytäntö on liitettyjen yhdistelmä, ei tiedosto, jota muokkasit.

Isäntäkoneen palomuuri on erillinen raja

Pilvikäytäntö päästää liikenteen verkkoliitäntään, ja sitten käyttöjärjestelmä päättää, näkeekö daemon sen. Isäntäkoneen palomuuri oletushylkäyskäytännöllä pudottaa paketin, jonka tietoturvaryhmä salli, eikä pilvikonsoli näytä hylkäystä, koska sillä ei ollut koskaan mielipidettä. Tarkista molemmat siinä järjestyksessä, jossa paketti kohtaa ne.

Jos isäntäkone käyttää jakelun palomuurin käyttöliittymää, varmista taustalla olevat säännöt eikä profiilin nimeä, sillä profiili voi olla aktiivinen, vaikka portti on suljettu.

Kaappaus liitännällä kertoo, mikä raja pudotti paketin.

Kuuntelijan salliminen ei ole asiakkaiden reitittämistä

Asiakasliikennettä edelleenlähettävä VPN-yhdyskäytävä tarvitsee muutakin kuin avoimen portin. Se tarvitsee IP-edelleenlähetyksen, käytännön, joka sallii virtauksen tunneliliitännästä kohdeverkkoon, ja usein liitännältä poiskytketyn lähde-kohde-tarkistuksen, jotta alusta ei hylkää liikennettä, joka ei ole sille osoitettu. Mitään tästä ei luo kuuntelijan sääntö.

Tässä eroavat toimiva kättely ja rikkinäinen datapolku, ja siksi tunnelin tila voi näyttää terveeltä, vaikka mikään ei lataudu.

Korjaa reititys erillisenä muutoksena omalla varmennuksellaan ja huomauta, että edelleenlähettävä yhdyskäytävä tarvitsee myös lähtökäytännön, joka sallii kohteen.

Pidä paluureitti auki ja kavenna sitten sääntöä

Ennen etäpalomuurin käytännön muuttamista varmista, että riippumaton hallintareitti on olemassa, kuten istunnonhallinta, sarjakonsoli tai vyöhykkeen ulkopuolinen verkko. Jos ainoa hallintareitti kulkee muokattavan säännön kautta, sinulla ei ole palautusta. Käytä sitten kapeaa sääntöä, testaa todelliselta asiakkaalta ja yhdistä yritys palvelinpuolen todisteisiin. Vastaus toiselta palvelulta samalla koneella ei ole todiste siitä, että kuuntelija tavoitettiin.

Poista kaikki kokeellinen laaja sallinta heti, kun kapea toimii, ja kirjaa, miksi sääntö on olemassa. AWS dokumentoi tietoturvaryhmien tilallisen käyttäytymisen, ja juuri tuota asiakirjaa pitää siteerata, kun joku ehdottaa laajaa aluetta oikotienä.

Dokumentoi myös liittäminen, muuten korvaava liitäntä menettää käytännön ääneti.