UDP-VPN stil by in poarteskans? Wêrom dat bart
WireGuard en hurde OpenVPN smite datagrammen dy't net autentisearje fuort sûnder te antwurdzjen. Stilte fan in skanner is ferwachte gedrach, net in sletten poarte.
Jo skanne de VPN-poarte, krije gjin antwurd en konkludearje dat de tsjinst del is of dat de firewall sletten is. By WireGuard, en by OpenVPN-kontrôlekanalen dy't har eigen autentikaasje drage, folget dy konklúzje net. In datagram sûnder jildich autentikaasjemateriaal wurdt fuortsmiten sûnder antwurd, dus stilte is hoe't in sûne tsjinst der fan bûten útsjocht. De probe is ferkeard foardat de tunnel dat is.
Stilte is it protokoll, net in flater
UDP hat gjin ferbiningsoppbou, dus der is gjin SYN en gjin befêstiging dy't in skanner helpe soe om in iepen poarte fan in filtere te ûnderskieden. In probe komt as in isolearre datagram oan, en de tsjinst kontrolearret oft it by it protokoll past dat se ferwachtet. As dat net sa is, wurdt it pakket fuortsmiten, en fuortsmiten is it dokumintearre gedrach ynstee fan in steuring.
WireGuard falidearret syn handshake-berjochten kryptografysk en negearret alles wat mislearret. OpenVPN mei tls-auth of tls-crypt docht itselde foar syn kontrôlekanaal. Yn beide gefallen berikt in willekeurige lading nea in stadium dat nei de brûker rjochte is, dus der is neat om mei te antwurdzjen en gjin flater om werom te jaan.
TCP soe jo in reset fan in sletten poarte jûn hawwe. UDP lit jo efter mei ûndúdlikheid, dy't skanners oplosse troch iepen of filtere te printsjen ynstee fan te rieden.
Wat in skanner wol en net konkludearje kin
It resultaat fan in skans is mar sa ynformtyf as de lading dy't it stjoerd hat. Sortearje de mooglike waarnimmings nei wat elk derfan feitlik stipet:
| 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 |
Lês de tredde rige as de iennichste positive test yn 'e list. It freget it echte profyl, de echte kaai en it juste einpunt, en dat is krekt wat in generike skanner net hat.
Sjoch nei beide einen fan it paad
Foar in server dy't jo beheare, meitsje in opname op 'e ynterface foardat jo in konklúzje lûke, en freegje dan de tsjinst wat se seach. Beide kommando's hawwe root nedich op 'e gateway:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showAs der gjin pakket op 'e ynterface ferskynt, hat it paad it fuortsmiten foardat de tsjinst eat seach, en de folgjende stop is routing en filtering. As pakketten oankomme mar gjin handshake foltôget, is de tsjinst berikber en sit de misferhâlding yn kaaien, einpuntkonfiguraasje of protokolfersje. Dy ferliking beantwurdet de fraach dy't de skanner net koe. Rin it wylst in echte klant besiket te ferbinen, net wylst de skanner himsels werhellet.
Feroarje de test, net de beskerming
De ferliedlike fluchste wei is om de beskerming fan it kontrôlekanaal út te setten sadat in diagnostyk antwurd krijt. Dat ruilet in echte feiligensseigenskip foar in moaier skansresultaat, en it is de ferkearde rjochting. Brûk ynstee in jildich profyl fan in goedkarde netwurk, en notearje it einpunt en de tiid sadat de ferliking werhellber is.
De meast brûkbere test is in differinsjele: itselde profyl op in paad dat wurket en op it paad dat net wurket. As it wurkjende paad in handshake produsearret en it mislearjende paad neat op 'e ynterface produsearret, hawwe jo de breuk fûn sûnder eat te ferswakjen.
In ûnbeantwurde UDP-pakket bewiist dus net dat de server offline is en ek net dat er feilich is. It bewiist dat dizze probe, op dit paad, op dit stuit, net akseptearre is.