Wêrom feroarje de resultaten fan poartskenning efter in VPN-útgong?

Rin deselde poartkontrôle fan in kantoarline en fan in VPN-útgong, en de beide antwurden kinne ferskille oer in adres dat nimmen feroare hat. Dat gat komt fan ’e rûte en fan hokker host antwurde, net fan oft de tsjinst oan of út is. Trije fragen skiede dy ferklearrings: wat de probe echt frege, hokker host it beantwurde, en wat jo eigen server registrearre. Wurkje se yn dy folchoarder troch en skriuw elk antwurd op foardat jo nei de folgjende geane.

Reparearje de probe foardat jo twa rinnen fergelykje

In steatswurd is allinnich fergelykber mei in oar steatswurd as beide út itselde eksperimint komme. Fiif fjilden sette dat fêst: it boarneadres dat de fiere kant seach, de oploste bestimming, de poarte, it skenningstype en de tiid. Feroarje ien fan har en jo hawwe in twadde eksperimint dien ynstee fan it earste twa kear te mjitten.

Kontrolearje de boarne foar al it oare, want in VPN-klant kin oan wêze wylst ferkear noch altyd oer de fysike ynterface fuortgiet. Freegje de fiere kant wat it sjocht, freegje dan de kernel hokker ynterface it keas:

curl -s https://ifconfig.me
ip route get 203.0.113.20

Twa adressen op ferskillende netwurken betsjutte dat de ferklearring al yn ’e hân is, en de rest fan dizze kontrôles sil it allinnich befêstigje. As se oerienkomme, fange de probe mei de redenflagge oan, sadat de steat weromkomt ferbûn mei in ferklearring ynstee fan allinnich as in bleat wurd te stean. It skenningstype heart ek by dat record, want it beskriuwt wat frege is, net wat weromkaam. In steat sûnder boarne, sûnder metoade en sûnder tiidstimpel kin mei neat fergelike wurde:

nmap -sT -p 443,8443 --reason 203.0.113.20

Hâld dy útfier nêst it record ynstee fan yn in rôlbuffer dy’t de folgjende persoan net sjen kin. Twa earlike skenningen dy’t ferskille binne allinnich in argumint as nimmen de betingsten opskreaun hat. Mei de betingsten fêst, of de resultaten komme oerien en de fraach is sletten, of se ferskille en it ferskil is in feit oer it paad.

Fyn út hokker host de hânskud foltôge

In foltôge hânskud bewiist dat in host it foltôge, en dy host hoecht net it proses te wêzen dat jo yn ’t sin hawwe. In loadbalancer, in omkearde proxy of in SYN-proxy kinne antwurdzje foardat de echte server belutsen is, wat gewoane foarmjouwing is en gjin symptoom. In jildich sertifikaat foar de ferwachte namme beheint dat ek net, want in sertifikaat beskriuwt in tsjinstferhâlding en seit neat oer hokker masine de ferbining beëinige.

De Nmap-referinsje foar poartsteaten beskôget dit as basis: in steat registrearret wat in probe fan syn stjoerpunt ôf waarnimme koe, net in eigenskip fan ’e poarte. Lês in steatswurd sa en twa rinnen dy’t ferskilden begjinne konsekwint te lykjen ynstee fan tsjinstridich, wylst de fraach ferskoot fan oft de poarte iepen is nei wa’t der foar stie.

Beäntwurdzje de twadde fraach by de backend en net fan bûten. In frontend dy’t ferbiningen oannimt en dan syn upstream net berikt, produsearret krekt it uterlike byld fan in sûne tsjinst mei in stadige applikaasje. Allinnich it eigen record fan ’e upstream skiedt de twa gefallen:

tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'

De logrigel lit it klantadres sjen dat de applikaasje echt seach, en it twadde kommando lit sjen oft it proses dat poarte 443 hâldt jo applikaasje is of eat foar it. As dy twa ferskille oer hokker adres ferbûn, sjogge jo nei twa skonken fan ien fersyk en it ticket soe dat sizze moatte.

Kontrolearje jo eigen regels foardat jo de tunnel de skuld jouwe

Bewust belied is de meast foarkommende reden dat in poarte op ien netwurk antwurdet en op in oar net, en it is de minst nijsgjirrige ferklearring dy’t beskikber is. Tagongsregels besteane om ien boarne ta te litten en de rest fuort te smiten, dus in feroaring fan útgong is krekt de barren dêr’t se foar skreaun binne. In oare steat fia in VPN lit dus net sjen dat de oanbieder ferkear ynspektearret. It lit sjen dat jo boarneadres no oars is, wat in folle lytsere bewearing is.

Dy regels binne op de server te lêzen, dus lês se ynstee fan te spekulearjen oer it midden fan it netwurk. List de filterregels op dy’t ien fan ’e beide adresberikken neame, kontrolearje dan oft de ferbining de daemon berikt hat:

nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113

In leech twadde resultaat is ynformatyf, want der hat neat de daemon berikt en de fraach heart by in filter, in feiligensgroep of it paad sels. In treffer betsjut dat de tsjinst jo boarne seach en syn antwurd keas, en dy beslissing stiet meastentiids skreaun yn in regel dy’t jo lêze kinne. Net ien fan ’e útkomsten stipet in ferhaal oer de oanbieder, en beide binne goedkeaper te kontrolearjen as in pakketopname.

Lês ferfier, sertifikaat en antwurd apart

Trije lagen produsearje trije waarnimmingen, en in probe dy’t ien dêrfan testet kin net oer de oare twa rapportearje. Hâld se as aparte rigels yn it record ynstee fan se yn ien oardiel te folden, want elke rigel falt op syn eigen wize en de falmodus fertelt jo wêr’t jo folgjende kear sjen moatte.

Ien kommando produsearret de earste trije rigels tsjin in tsjinst dy’t jo kontrolearje. Set syn útfier yn it record nêst de skenning en net yn in chatberjocht:

curl -v --resolve office.example:443:203.0.113.20 https://office.example/

Lês de útfier yn folchoarder: it hânskud beantwurdet de fraach fan ferfier, it sertifikaatûnderwerp beantwurdet de fraach fan ’e namme, en it antwurdlichem beantwurdet de fraach fan ’e applikaasje. As de hânskudrigel slagget en de antwurdrigel net, hawwe jo in frontend mei in brutsen upstream ynstee fan in blokkearre poarte. Dat is in oar ticket as dat jo iepene hawwe, en it is de muoite wurdich om dat dúdlik te sizzen.

Einigje troch fjouwer feiten yn it ticket te skriuwen: boarneadres, skenningstype, de host dy’t antwurde, en de tiid. Alles wat in lettere fergeliking nedich hat libbet yn dy fjouwer, en wa’t de saak folgjende oannimt hat net jo terminalskiednis. As jo net alle fjouwer ynfolje kinne, is de rin net klear.