Proč se výsledky skenování portů mění za výstupem VPN?

Spusťte stejnou kontrolu portu z kancelářské linky a z výstupu VPN a obě odpovědi se mohou rozejít ohledně adresy, kterou nikdo nezměnil. Ta mezera pochází z trasy a z toho, který hostitel odpověděl, ne z toho, zda služba běží. Tři otázky tyto výklady oddělují: na co se sonda vlastně ptala, který hostitel odpověděl a co zaznamenal váš vlastní server. Projděte je v tomto pořadí a každou odpověď zapište, než přejdete k další.

Opravte sondu, než porovnáte dva běhy

Slovo stavu lze srovnávat s jiným slovem stavu jen tehdy, když obě vzešla ze stejného experimentu. Pět polí to fixuje: zdrojová adresa, kterou vzdálená strana viděla, přeložený cíl, port, typ skenování a čas. Změňte kterékoli z nich a provedli jste druhý experiment, místo abyste první měřili dvakrát.

Zkontrolujte zdroj dřív než cokoli jiného, protože klient VPN může běžet, zatímco provoz stále odchází přes fyzické rozhraní. Zeptejte se vzdálené strany, co vidí, a potom se zeptejte jádra, které rozhraní zvolilo:

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

Dvě adresy v různých sítích znamenají, že vysvětlení už máte v ruce, a zbytek těchto kontrol ho jen potvrdí. Když se shodují, zachyťte sondu se zapnutým příznakem důvodu, aby se stav vrátil připojený k vysvětlení, místo aby stál sám jako holé slovo. Typ skenování patří do toho záznamu také, protože popisuje, na co se ptalo, ne co se vrátilo. Stav bez zdroje, bez metody a bez časového razítka nelze s ničím srovnat:

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

Uchovejte tento výstup vedle záznamu, ne v bufferu posouvání, který další člověk neuvidí. Dvě poctivá skenování, která se rozcházejí, jsou sporem jen tehdy, když nikdo nezapsal podmínky. Když jsou podmínky pevné, buď se výsledky shodují a otázka je uzavřená, nebo se liší a rozdíl je faktem o cestě.

Zjistěte, který hostitel dokončil navázání spojení

Dokončené navázání spojení dokazuje, že je dokončil nějaký hostitel, a tím hostitelem nemusí být proces, který máte na mysli. Nástroj pro vyvažování zátěže, reverzní proxy nebo SYN proxy mohou odpovědět dřív, než se skutečný server vůbec zapojí, což je běžný design, ne symptom. Platný certifikát pro očekávané jméno to také nezužuje, protože certifikát popisuje vztah služby a nic neříká o tom, který stroj spojení ukončil.

Referenční příručka Nmap ke stavům portů to považuje za základní: stav zaznamenává, co sonda mohla pozorovat z místa, odkud byla odeslána, ne vlastnost portu. Čtěte slovo stavu takto a dva běhy, které se rozcházely, začnou vypadat shodně, ne protikladně, zatímco otázka se posouvá od toho, zda je port otevřený, k tomu, kdo před ním stál.

Odpovězte na druhou otázku na backendu, ne zvenčí. Frontend, který přijímá spojení a potom nedosáhne svého upstreamu, vytváří přesně vnější obraz zdravé služby s pomalou aplikací. Jen vlastní záznam upstreamu odděluje oba případy:

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

Řádek v logu ukazuje adresu klienta, kterou aplikace skutečně viděla, a druhý příkaz ukazuje, zda proces držící port 443 je vaše aplikace, nebo něco před ní. Pokud se ty dva rozcházejí v tom, která adresa se připojila, díváte se na dvě nohy jednoho požadavku a tiket by to měl říct.

Zkontrolujte vlastní pravidla, než obviníte tunel

Záměrná politika je nejčastějším důvodem, proč port odpovídá v jedné síti a v jiné ne, a je to nejméně zajímavé dostupné vysvětlení. Přístupová pravidla existují proto, aby povolila jeden zdroj a ostatní zahodila, takže změna výstupu je přesně tou událostí, pro kterou byla napsána. Jiný stav přes VPN tedy neukazuje, že poskytovatel zkoumá provoz. Ukazuje, že vaše zdrojová adresa je nyní jiná, což je mnohem menší tvrzení.

Tato pravidla lze na serveru přečíst, tak si je přečtěte, místo abyste spekulovali o středu sítě. Vypište pravidla filtru, která zmiňují kterýkoli ze dvou rozsahů adres, a potom zkontrolujte, zda se spojení vůbec dostalo k daemonu:

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

Prázdný druhý výsledek je informativní, protože k daemonu nic nedorazilo a otázka patří filtru, bezpečnostní skupině nebo samotné cestě. Zásah znamená, že služba viděla váš zdroj a zvolila svou odpověď, a to rozhodnutí je obvykle zapsáno v pravidle, které si můžete přečíst. Ani jeden výsledek nepodporuje příběh o poskytovateli a oba se kontrolují levněji než zachytávání paketů.

Čtěte transport, certifikát a odpověď odděleně

Tři vrstvy vytvářejí tři pozorování a sonda, která testuje jedno z nich, nemůže referovat o ostatních dvou. Uchovejte je jako samostatné řádky v záznamu, místo abyste je složili do jediného verdiktu, protože každý řádek selhává po svém a režim selhání vám říká, kam se příště podívat.

Jeden příkaz vytvoří první tři řádky proti službě, kterou ovládáte. Dejte jeho výstup do záznamu vedle skenování, ne do chatové zprávy:

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

Čtěte výstup po řadě: navázání spojení odpovídá na otázku transportu, subjekt certifikátu na otázku jména a tělo odpovědi na otázku aplikace. Když řádek navázání spojení uspěje a řádek odpovědi ne, máte frontend s rozbitým upstreamem, ne blokovaný port. To je jiný tiket než ten, který jste otevřeli, a stojí za to to říct přímo.

Skončete zápisem čtyř faktů do tiketu: zdrojová adresa, typ skenování, hostitel, který odpověděl, a čas. Všechno, co pozdější srovnání potřebuje, žije v těchto čtyřech, a kdo případ převezme po vás, nebude mít historii vašeho terminálu. Pokud nedokážete vyplnit všechny čtyři, běh není dokončen.