Prečo sa výsledky skenovania portov menia za výstupom VPN?

Spustite rovnakú kontrolu portu z kancelárskej linky a z výstupu VPN a obe odpovede sa môžu rozísť v adrese, ktorú nikto nezmenil. Tá medzera pochádza z trasy a z toho, ktorý hostiteľ odpovedal, nie z toho, či služba beží. Tri otázky tieto vysvetlenia oddeľujú: na čo sa sonda vlastne pýtala, ktorý hostiteľ odpovedal a čo zaznamenal váš vlastný server. Prejdite ich v tomto poradí a každú odpoveď zapíšte, skôr než prejdete k ďalšej.

Opravte sondu, skôr než porovnáte dva behy

Slovo stavu možno porovnávať s iným slovom stavu len vtedy, keď obe vzišli z rovnakého experimentu. Päť polí to fixuje: zdrojová adresa, ktorú videla vzdialená strana, preložený cieľ, port, typ skenovania a čas. Zmeňte ktorékoľvek z nich a vykonali ste druhý experiment, namiesto toho, aby ste prvý merali dvakrát.

Skontrolujte zdroj predovšetkým ostatným, pretože klient VPN môže bežať, zatiaľ čo premávka stále odchádza cez fyzické rozhranie. Opýtajte sa vzdialenej strany, čo vidí, a potom sa opýtajte jadra, ktoré rozhranie si vybralo:

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

Dve adresy v rôznych sieťach znamenajú, že vysvetlenie už máte v ruke, a zvyšok týchto kontrol ho len potvrdí. Keď sa zhodujú, zachyťte sondu so zapnutou príznakovou vlajkou dôvodu, aby sa stav vrátil prepojený s vysvetlením, namiesto toho, aby stál sám ako holé slovo. Typ skenovania patrí do toho záznamu tiež, pretože opisuje, na čo sa pýtalo, a nie čo sa vrátilo. Stav bez zdroja, bez metódy a bez časovej pečiatky sa nedá s ničím porovnať:

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

Uložte tento výstup vedľa záznamu a nie do bufferu posúvania, ktorý ďalší človek neuvidí. Dve poctivé skenovania, ktoré sa rozchádzajú, sú sporom len vtedy, keď nikto nezapísal podmienky. Keď sú podmienky pevné, buď sa výsledky zhodujú a otázka je uzavretá, alebo sa líšia a rozdiel je faktom o ceste.

Zistite, ktorý hostiteľ dokončil podanie ruky

Dokončené podanie ruky dokazuje, že ho dokončil nejaký hostiteľ, a tým hostiteľom nemusí byť proces, ktorý máte na mysli. Vyvažovač záťaže, reverzný proxy alebo SYN proxy môžu odpovedať skôr, než sa zapojí skutočný server, čo je bežný dizajn, nie príznak. Platný certifikát pre očakávané meno to tiež nezúžuje, pretože certifikát opisuje vzťah služby a nič nehovorí o tom, ktorý stroj spojenie ukončil.

Referenčná príručka Nmap k stavom portov to považuje za základné: stav zaznamenáva, čo sonda mohla pozorovať z miesta odoslania, nie vlastnosť portu. Čítajte slovo stavu takto a dva behy, ktoré sa rozchádzali, začnú vyzerať zhodne, nie protikladne, zatiaľ čo otázka sa posúva od toho, či je port otvorený, k tomu, kto pred ním stál.

Odpovedzte na druhú otázku v backendu, nie zvonku. Frontend, ktorý prijíma spojenia a potom nedosiahne svoj upstream, vytvára presne vonkajší obraz zdravej služby s pomalou aplikáciou. Iba vlastný záznam upstreamu oddeľuje oba prípady:

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

Riadok v logu ukazuje adresu klienta, ktorú aplikácia skutočne videla, a druhý príkaz ukazuje, či proces, ktorý drží port 443, je vaša aplikácia alebo niečo pred ňou. Ak sa tí dvaja rozchádzajú v tom, ktorá adresa sa pripojila, pozeráte sa na dve nohy jednej požiadavky a tiket by to mal povedať.

Skontrolujte vlastné pravidlá, skôr než obviníte tunel

Úmyselná politika je najčastejším dôvodom, prečo port odpovedá v jednej sieti a v inej nie, a je to najmenej zaujímavé dostupné vysvetlenie. Prístupové pravidlá existujú preto, aby povolili jeden zdroj a ostatné zahodili, takže zmena výstupu je presne tou udalosťou, pre ktorú boli napísané. Preto iný stav cez VPN neukazuje, že poskytovateľ skúma premávku. Ukazuje, že vaša zdrojová adresa je teraz iná, čo je oveľa menšie tvrdenie.

Tie pravidlá sa dajú čítať na serveri, tak si ich prečítajte, namiesto špekulovania o strede siete. Vypíšte pravidlá filtra, ktoré spomínajú ktorýkoľvek z dvoch rozsahov adries, a potom skontrolujte, či sa spojenie vôbec dostalo k daemonovi:

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

Prázdny druhý výsledok je informatívny, pretože k daemonovi sa nič nedostalo a otázka patrí filtru, bezpečnostnej skupine alebo samotnej ceste. Zásah znamená, že služba videla váš zdroj a vybrala si svoju odpoveď, a to rozhodnutie je zvyčajne zapísané v pravidle, ktoré si môžete prečítať. Ani jeden výsledok nepodporuje príbeh o poskytovateľovi a oba sa kontrolujú lacnejšie než zachytenie paketov.

Čítajte transport, certifikát a odpoveď oddelene

Tri vrstvy vytvárajú tri pozorovania a sonda, ktorá testuje jedno z nich, nemôže referovať o ostatných dvoch. Uchovajte ich ako samostatné riadky v zázname, namiesto skladania do jediného verdiktu, pretože každý riadok zlyháva po svojom a režim zlyhania vám povie, kam sa nabudúce pozrieť.

Jeden príkaz vytvorí prvé tri riadky voči službe, ktorú ovládate. Dajte jeho výstup do záznamu vedľa skenovania, nie do chatovej správy:

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

Čítajte výstup po poradí: podanie ruky odpovedá na otázku transportu, subjekt certifikátu na otázku mena a telo odpovede na otázku aplikácie. Keď riadok podania ruky uspeje a riadok odpovede nie, máte frontend s rozbitým upstreamom, nie blokovaný port. To je iný tiket než ten, ktorý ste otvorili, a stojí za to to povedať priamo.

Skončite zápisom štyroch faktov do tiketu: zdrojová adresa, typ skenovania, hostiteľ, ktorý odpovedal, a čas. Všetko, čo neskoršie porovnanie potrebuje, žije v týchto štyroch, a kto prípad prevezme po vás, nebude mať históriu vášho terminálu. Ak nedokážete vyplniť všetky štyri, beh nie je dokončený.