Zein VPN ataka ireki suebaki batean: protokoloz protokolo

Bi arau berezik erabakitzen dute VPN tunel batek suebakia gaindituko duen: bezeroak markatzen duen ataka eta karga daraman protokoloa. Lehenengoa bakarrik irekiz gero, tunelak autentifikazioa egiten du, baina gero ez du daturik mugitzen. Gutxienekoa TCP ataka bat eta GRE da PPTPrako, UDP ataka bi eta ESP L2TP/IPsec eta IKEv2rako, eta ataka bakarra SSTP, OpenVPN eta WireGuarderako. Norabideak, egoeraren jarraipenak eta NATek erabakitzen dute gainerakoa.

Hasi bezeroak markatzen duen ataketatik

Familia bakoitzak sarrera-puntu bat du, bezeroak lehenengo ukitzen duena, eta sarrera-puntu horixe izan behar du zure baimen-arauak izendatu behar duena. PPTP bezeroak TCP 1723ra konektatzen dira. L2TP/IPsec UDP 500ean hasten da IKErekin eta UDP 4500era pasatzen da NAT zeharkatzea erabiltzen denean, L2TP markoa bera tunelaren barruan UDP 1701ean dagoelarik. SSTPk saioa TLSen biltzen du TCP 443n, IKEv2k UDP 500 eta 4500ean negoziatzen du, OpenVPNek lehenespenez UDP 1194 erabiltzen du baina maiz TCP 443ra eramaten da, eta WireGuardek UDP 51820n entzuten du.

Hartu zenbaki horiek balio lehenetsi gisa, ez ezaugarri finko gisa. WireGuard interfaze batek bere konfigurazioak adierazten duen entzute-ataka erabiltzen du, eta OpenVPN zerbitzari bat administratzaileak aukeratutako edozein atakatan egon daiteke. Irakurri zerbitzariaren konfigurazioa araua idatzi aurretik, 1194rako irekitako suebaki batek ez baitu ezer egiten 443ra mugitu den zerbitzari baterako.

Hirugarren zutabea da aldaketa-txartel gehienak okertzen diren tokia. Araua badago, baina helmuga okerrean, norabide okerrean edo garraio okerrean erakusten du.

GRE eta ESP protokolo-zenbakiak dira, ez atakak

GREek eta ESPk ez dute atakarik, beraz ataka-zenbakiak soilik onartzen dituen suebaki-inprimaki batek ezin ditu adierazi. GRE IP protokolo 47 da eta ESP IP protokolo 50, biak IP goiburuaren protokolo-eremuaren bidez parekatzen dira. TCP ataka 47 gisa idatzitako arau batek ez du ezer parekatzen, eta horrela PPTP politika zuzena dirudi eta, hala ere, esku-ematearen ondorengo pakete guztiak botatzen ditu.

Etxeko bideratzaileek pasabide-kaxa baten atzean ezkutatzen dute hau, protokolo-araua instalatzen duena eta, GREren kasuan, fluxua mapatzeko behar den NAT laguntzailea ere bai. Benetako suebaki batean zeuk gehitzen duzu protokoloa: baimendu IP protokolo 47 PPTP zerbitzarira, baimendu IP protokolo 50 IPsec atebidera. Plataformak protokolo-eremurik eskaintzen ez duenean, kapsulatzea da irtenbidea, horregatik IKEv2k UDP 4500era atzera egin dezake eta horregatik OpenVPNek eta WireGuardek ez dute inoiz arazoa topatzen.

Egiaztatu arauak zer parekatzen duen bezeroari errua bota aurretik. Atebidean zeroan geratzen den pakete-kontagailu batek araua inoiz ez zela piztu esaten du, eta bezeroaren aldean berriz instalatzeak ez du hori aldatzen.

Norabideak, egoerak eta NATek erantzuna aldatzen dute

Kanpora markatzen duen bezero bat eta barrura entzuten duen atebide bat baldintza desberdinak dira, eta ataka-zerrenda bera zuzena izan daiteke norabide batean eta okerra bestean. Egoera duen suebaki batek UDP fluxua jarraitzen du 500 eta 4500ean eta erantzunak itzultzen uzten ditu bigarren araurik gabe. ESPk eta GREk ez dute atakarik, beraz NAT gailu batek ez du ezer heltzeko eta laguntzaile bat edo kapsulatze bat behar du saioa jarraitzeko.

NAT zeharkatzea da ahazten den zatia. IKEv2 UDP 500ean hasten da, NAT gailu bat detektatzen du eta UDP 4500ean jarraitzen du, beraz 500 soilik baimentzen duen politika batek ezartzen den eta gero isiltzen den tunel bat ematen du. L2TP/IPsec-ek mugimendu bera egiten du. Zure harrapaketak lehen trukea erakusten badu baina trafiko iraunkorrik ez, bilatu 500ean gelditzen den arau bat.

Erregistratu norabidea arau bakoitzarekin. «Baimendu UDP 4500» ez du ezer esan nahi nondik nora esan arte, eta bezero ibiltari baterako zuzena den araua okerra izaten da gunez guneko pare baterako.

Egiaztatu bide bakoitza harrapaketa batekin

Exekutatu harrapaketa atebidean, ez bezeroan: bezeroak iritsi dena soilik erregistratzen du. Iragazki hauek goiko familiak hartzen dituzte eta zein etapa falta den erakusten dute:

sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50

Irakurri irteera segida gisa. Negoziazioa agertzen denean baina karga-protokoloa ez, deskartzea bezeroaren eta atebidearen artean gertatzen da. Biak agertzen direnean eta orriak huts egiten jarraitzen duenean, suebakia ez da susmagarria jada; begiratu bideratzea, DNSa edo bezeroari emandako helbide-multzoa.

tcpdump ez duen makinan, froga berak interfaze- eta arau-kontagailuetatik datoz. Byteak sartu baina irten ez tunelaren interfazean — horrek itzulera-bidera seinalatzen du, hasierako baimen-araura ez.

Utzi defenda dezakezun arau-multzo bat

TCP 443ko SSTP ez da HTTPS arruntetik bereizten atakan oinarritutako iragazki batentzat, eta hori da kontua sare batek web trafika soilik baimentzen duenean. Horregatik 443rako arauak atebidea izendatu behar du helmuga gisa, internet osoa beharrean. Ezabatu aldi baterako edozein-ezegozinerako arauak tunela funtzionatzen duen bezain laster. Idatzi zein arau parekatu zen, protokolo-zenbakia dagoen tokian, eta norabidea, hurrengo pertsonak frogatatik has dadin.

Hodeiko puntutik gunera atebideek hautua ikusgai egiten dute: deskargatutako profilek SSTP erabiltzen du 443n edo IKEv2 500 eta 4500ean, eta profileak benetan aukeratzen duena soilik ireki behar duzu. PPTPk ez du merezi GREren salbuespena sare moderno batean, operadore mugikorrek 47 protokoloa maiz botatzen baitute zure suebakia edozein dela ere. Txartela itxi aurretik, egiaztatu araua zerbitzariaren konfigurazioko atakarekin bat datorrela, protokolo-eremua familia horrek behar duen tokian ezarrita dagoela eta helmuga atebidea dela, ez edozein helbide.