UDP bidezko VPNa isilik portu-eskanean? Zergatik gertatzen da
WireGuardek eta gogortutako OpenVPNek autentifikazioa gainditzen ez duten datagramak baztertzen dituzte erantzun gabe. Eskaner baten isiltasuna espero den portaera da, ez portu itxi bat.
VPNaren portua eskaneatzen duzu, ez duzu erantzunik jasotzen eta zerbitzua behera dagoela edo suebakia itxita dagoela ondorioztatzen duzu. WireGuardekin eta beren autentifikazioa daramaten OpenVPN kontrol-kanalekin, ondorio horrek ez du balio. Autentifikazio-material baliozkorik gabeko datagrama erantzunik gabe baztertzen da, beraz isiltasuna da zerbitzu osasuntsu batek kanpotik duen itxura. Zunda oker dago tunela baino lehen.
Isiltasuna protokoloa da, ez akatsa
UDPk ez du konexio-ezarpenik, beraz ez dago SYNik ez eta eskaner batek portu irekia eta iragazitakoa bereizteko aukera emango lukeen aitortzarik. Zunda datagrama isolatu gisa iristen da, eta zerbitzuak egiaztatzen du espero duen protokoloarekin bat datorren. Bat ez datorrenean, paketea baztertu egiten da, eta baztertzea dokumentatutako portaera da, ez matxura.
WireGuardek kriptografikoki baliozkotzen ditu bere handshake mezuak eta huts egiten duen guztia ez du aintzat hartzen. OpenVPN tls-auth edo tls-crypt-ekin gauza bera egiten du bere kontrol-kanalarentzat. Bi kasuetan karga arbitrarioa ez da inoiz erabiltzaileari zuzendutako etapara iristen, beraz ez dago erantzuteko ezer eta ez dago itzultzeko errorerik.
TCPk reset bat emango zizuke portu itxi batetik. UDPk anbiguotasunean uzten zaitu, eta eskaneatzaileek irekia edo iragazia inprimatuta ebazten dute, asmatu beharrean.
Zer ondoriozta dezakeen eskaner batek eta zer ez
Eskaneatze-emaitza bidalitako kargak adina informazio du. Sailkatu behagarri diren behaketak bakoitzak benetan zer babesten duen kontuan hartuta:
| Probe | Observed result | What it supports |
|---|---|---|
| Empty datagram | No reply | Nothing beyond the fact that UDP was used |
| Random payload | No reply | Consistent with an authenticated service |
| Valid handshake from a real client | A protocol reply | The service is alive and reachable |
| ICMP port unreachable | Unreachable message | The host answered, usually because nothing listens |
Irakurri hirugarren errenkada zerrendako proba positibo bakarra bezala. Profil erreala, gako erreala eta amaiera-puntu egokia behar ditu, eta hori da eskaner generiko batek ez duena.
Begiratu bidearen bi muturrei
Kudeatzen duzun zerbitzari batentzat, har ezazu interfazean ondorio bat atera aurretik, eta gero galdetu zerbitzuari zer ikusi zuen. Bi komanduek root behar dute gatewayan:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showInterfazean paketerik agertzen ez bada, bideak baztertu zuen zerbitzuak ezer ikusi aurretik, eta hurrengo geldialdia bideratzea eta iragaztea da. Paketeak iristen badira baina handshake bat ere ez bada osatzen, zerbitzua irisgarria da eta desadostasuna gakoetan, amaiera-puntuaren konfigurazioan edo protokoloaren bertsioan dago. Konparazio horrek eskanerrak ezin zuen galderari erantzuten dio. Exekutatu benetako bezero bat konektatzen saiatzen ari den bitartean, ez eskanerra bere burua errepikatzen ari den bitartean.
Aldatu proba, ez babesa
Lasterbide tentagarria kontrol-kanalaren babesa desgaitzea da, diagnostiko batek erantzuna jaso dezan. Horrek benetako segurtasun-propietate bat eskaneatze-emaitza ederrago baten truke aldatzen du, eta norabide okerra da. Erabili horren ordez sare onartu bateko profil baliodun bat, eta idatzi amaiera-puntua eta ordua konparazioa errepikagarria izan dadin.
Probarik erabilgarriena diferentziala da: profil bera funtzionatzen duen bide batean eta funtzionatzen ez duen bidean. Bide lanegileak handshake bat sortzen badu eta huts egiten duen bideak interfazean ezer sortzen ez badu, haustura lokalizatu duzu ezer ahuldu gabe.
Beraz, erantzunik gabeko UDP pakete batek ez du frogatzen zerbitzaria lineaz kanpo dagoenik ez eta segurua denik ere. Frogatzen du zunda hau, bide honetan, une honetan, ez zela onartu.