Cloudovna varnostna skupina za VPN: odprite poslušalca, ne vse

Strežnik VPN teče, odjemalec doživi časovno omejitev in prvi impulz je dodati varnostni skupini pravilo, ki dovoli vse. Včasih to povzroči, da deluje, in to je najslabši izid, ker zdaj nihče ne ve, katera meja je bila v resnici zaprta. Med odjemalcem in demonom stojijo štirje ločeni filtri, in le eden od njih je varnostna skupina.

Poimenujte protokol pred pravilom

Pravilo je protokol, obseg vrat in vir. WireGuard posluša na UDP, običajno 51820. OpenVPN je običajno UDP ali TCP 1194, odvisno od konfiguracije. IPsec potrebuje izmenjavo IKE na UDP 500 in 4500 ter sam protokol ESP, ki je številka protokola in ne vrata. Ugibanje TCP, ker so druga pravila TCP, vodi do pravila, ki je videti pravilno in se ne ujema z ničimer.

Poslušalca berite iz delujoče storitve, ne iz priročnika. Demon, vezan na en naslov, ne bo sprejel prometa, ki prispe na drugega.

Omejite vir na obseg odjemalcev, ki ga zasnova dovoljuje, namesto na cel internet.

Varnostne skupine ohranjajo stanje; podomrežni ACL ga ne

Varnostne skupine ohranjajo stanje in samo dovoljujejo: dovoljen vhodni tok samodejno prejme odgovore, in ni pravila zavrnitve, o katerem bi bilo treba razmišljati. Podomrežni ACL so brezstanjski in se ocenjujejo v obeh smereh, zato vhodno dovoljenje brez ustreznega izhodnega efemernega obsega še vedno ne uspe. Ta razlika pojasnjuje veliko pravil, ki so v konzoli videti pravilna.

Preverite tudi, katera politika je pritrjena na delujočo končno točko, ker ima lahko primerek več kot eno skupino, in pravilo v nepritrjeni skupini ne spremeni ničesar.

Učinkovita politika je unija pritrjenega, ne datoteka, ki ste jo urejali.

Požarni zid gostitelja je ločena meja

Cloudova politika spusti promet do omrežnega vmesnika, nato pa operacijski sistem odloči, ali ga demon vidi. Požarni zid gostitelja s privzeto politiko zavrnitve bo zavrgel paket, ki ga je varnostna skupina dovolila, in cloudova konzola ne bo pokazala nobene zavrnitve, ker nikoli ni imela mnenja. Preverite oboje, v vrstnem redu, v katerem paket naleti nanju.

Če gostitelj uporablja vmesnik požarnega zidu iz distribucije, preverite osnovna pravila in ne imena profila, ker je profil lahko aktiven, medtem ko so vrata zaprta.

Zajem na vmesniku vam pove, katera meja je paket zavrgla.

Dovoliti poslušalca ni usmerjanje odjemalcev

Prehod VPN, ki posreduje promet odjemalcev, potrebuje več kot odprta vrata. Potrebuje posredovanje IP, politiko, ki dovoljuje tok od vmesnika tunela do ciljnega omrežja, in pogosto na vmesniku izklopljeno preverjanje vira in cilja, da platforma ne zavrže prometa, ki mu ni naslovljen. Ničesar od tega ne ustvari pravilo poslušalca.

Tu se ločita delujoče rokovanje in pokvarjena podatkovna pot, zato je lahko stanje tunela videti zdravo, medtem ko se nič ne nalaga.

Usmerjanje popravite kot ločeno spremembo z lastnim preverjanjem in upoštevajte, da posredovalni prehod potrebuje tudi izhodno politiko, ki dovoli cilj.

Ohranite pot nazaj, nato zožite pravilo

Preden spremenite politiko oddaljenega požarnega zidu, preverite, ali obstaja neodvisna pot upravljanja, na primer upravitelj sej, serijska konzola ali omrežje zunaj pasu. Če edina pot upravljanja poteka skozi pravilo, ki ga urejate, nimate obnovitve. Nato uporabite ozko pravilo, preizkusite s pravega odjemalca in poskus povežite z dokazi na strani strežnika. Odgovor druge storitve na istem stroju ni dokaz, da je bil poslušalec dosežen.

Odstranite vsako eksperimentalno široko dovoljenje takoj, ko ozko deluje, in zabeležite, zakaj pravilo obstaja. AWS dokumentira stanjsko vedenje varnostnih skupin, in prav ta dokument je treba citirati, ko kdo predlaga širok obseg kot bližnjico.

Dokumentirajte tudi pritrditev, sicer bo nadomestni vmesnik tiho izgubil politiko.