UDP-VPN stil tydens 'n poortskandering? Hoekom dit gebeur
WireGuard en geharde OpenVPN laat datagramme val wat nie authentiseer nie, sonder om te antwoord. Stilte van 'n skandeerder is verwagte gedrag, nie 'n geslote poort nie.
Jy skandeer die VPN-poort, kry geen antwoord nie en maak die gevolgtrekking dat die diens af is of die firewall gesluit is. Met WireGuard, en met OpenVPN-beheerkanaale wat hul eie verifikasie dra, volg daardie gevolgtrekking nie. 'n Datagram sonder geldige verifikasieboustof word sonder 'n antwoord weggegooi, so stilte is hoe 'n gesonde diens van buite lyk. Die toets is verkeerd voordat die tonnel verkeerd is.
Stilte is die protokol, nie 'n fout nie
UDP het geen verbindingsopstelling nie, so daar is geen SYN en geen bevestiging wat 'n skandeerder sou laat onderskei tussen 'n oop poort en 'n gefiltreerde een nie. 'n Peiling kom as 'n geïsoleerde datagram aan, en die diens kyk of dit by die protokol pas wat hy verwag. Wanneer dit nie pas nie, word die pakket laat val, en laat val is die gedokumenteerde gedrag eerder as 'n fout.
WireGuard verifieer sy handshake-boodskappe kriptografies en ignoreer enigiets wat misluk. OpenVPN met tls-auth of tls-crypt doen dieselfde vir sy beheerkanaal. In beide gevalle bereik 'n willekeurige las nooit 'n gebruikersgerigte stadium nie, so daar is niks om mee te antwoord nie en geen fout om terug te gee nie.
TCP sou vir jou 'n reset van 'n geslote poort gegee het. UDP laat jou met onduidelikheid, wat skandeerders oplos deur oop of gefiltreer te druk eerder as om te raai.
Wat 'n skandeerder kan en nie kan aflei nie
Die uitslag van 'n skandering is net so insiggewend soos die las wat dit gestuur het. Rangskik die moontlike waarnemings volgens wat elkeen werklik ondersteun:
| 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 |
Lees die derde ry as die enigste positiewe toets in die lys. Dit vereis die regte profiel, die regte sleutel en die regte eindpunt, wat juis is wat 'n generiese skandeerder nie het nie.
Kyk na beide kante van die pad
Vir 'n bediener wat jy beheer, vang op die koppelvlak voordat jy enige gevolgtrekking maak, en vra dan die diens wat hy gesien het. Albei opdragte benodig root op die gateway:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showAs geen pakket by die koppelvlak verskyn nie, het die pad dit laat val voordat die diens iets gesien het, en die volgende stop is roetering en filtering. As pakkette aankom maar geen handshake voltooi nie, is die diens bereikbaar en die wanverhouding lê in sleutels, eindpuntkonfigurasie of protokolweergawe. Daardie vergelyking beantwoord die vraag wat die skandeerder nie kon nie. Voer dit uit terwyl 'n regte kliënt probeer koppel, nie terwyl die skandeerder homself herhaal nie.
Verander die toets, nie die beskerming nie
Die aanloklike kortpad is om beheerkanaalboskerming af te skakel sodat 'n diagnose 'n antwoord kry. Dit verruil 'n werklike sekuriteitseienskap vir 'n mooier skandeeruitslag, en dit is die verkeerde rigting. Gebruik eerder 'n geldige profiel van 'n goedgekeurde netwerk, en noteer die eindpunt en tyd sodat die vergelyking herhaalbaar is.
Die nuttigste toets is 'n differensiële een: dieselfde profiel op 'n pad wat werk en op die pad wat nie werk nie. As die werkende pad 'n handshake lewer en die falende pad niks by die koppelvlak lewer nie, het jy die breekpunt gevind sonder om enigiets te verswak.
'n Onbeantwoorde UDP-pakket bewys dus nie dat die bediener aflyn is nie en ook nie dat dit veilig is nie. Dit bewys dat hierdie peiling, op hierdie pad, op hierdie oomblik, nie aanvaar is nie.