Kāpēc portu skenēšanas rezultāti mainās aiz VPN izejas?
Nomainiet izeju, un ports var atbildēt citādi, pat ja pakalpojums nekur nepārvietojas. Atdaliet ceļa novērojumu no inventāra, kas jums patiešām nepieciešams.
Palaidiet to pašu porta pārbaudi no biroja līnijas un no VPN izejas, un abas atbildes var nesaskanēt par adresi, ko neviens nav mainījis. Šī atšķirība nāk no maršruta un no tā, kurš resursdators atbildēja, nevis no tā, vai pakalpojums darbojas. Trīs jautājumi šķir šos skaidrojumus: ko zonde patiešām jautāja, kurš resursdators atbildēja un ko ierakstīja jūsu pašu serveris. Iziet cauri tiem šajā kārtībā un pierakstiet katru atbildi pirms pārejas uz nākamo.
Izlabojiet zondi pirms divu palaišanu salīdzināšanas
Stāvokļa vārdu var salīdzināt ar citu stāvokļa vārdu tikai tad, ja abi nāk no viena un tā paša eksperimenta. Pieci lauki to fiksē: avota adrese, ko redzēja tālā puse, atrisinātais galamērķis, ports, skenēšanas tips un laiks. Mainiet jebkuru no tiem, un esat veicis otru eksperimentu, nevis pirmo nomērījis divreiz.
Pārbaudiet avotu pirms visa cita, jo VPN klients var būt ieslēgts, kamēr trafiks joprojām iziet caur fizisko saskarni. Pajautājiet tālajai pusei, ko tā redz, pēc tam pajautājiet kodolam, kuru saskarni tas izvēlējās:
curl -s https://ifconfig.me
ip route get 203.0.113.20Divas adreses dažādos tīklos nozīmē, ka skaidrojums jau ir rokā, un pārējās pārbaudes to tikai apstiprinās. Kad tās sakrīt, fiksējiet zondi ar ieslēgtu iemesla karodziņu, lai stāvoklis atgrieztos piesaistīts skaidrojumam, nevis stāvētu viens kā kails vārds. Skenēšanas tips arī pieder šim ierakstam, jo tas apraksta, ko jautāja, nevis ko atdeva. Stāvokli bez avota, metodes un laika zīmoga nevar ar neko salīdzināt:
nmap -sT -p 443,8443 --reason 203.0.113.20Glabājiet šo izvadi blakus ierakstam, nevis ritināšanas buferī, ko nākamais cilvēks nevar redzēt. Divas godīgas skenēšanas, kas nesakrīt, ir strīds tikai tad, kad neviens nav pierakstījis nosacījumus. Kad nosacījumi fiksēti, vai nu rezultāti sakrīt un jautājums ir slēgts, vai tie atšķiras un atšķirība ir fakts par ceļu.
Noskaidrojiet, kurš resursdators pabeidza rokasspiedienu
Pabeigts rokasspiediens pierāda, ka kāds resursdators to pabeidza, un šim resursdatoram nav jābūt procesam, kuram jūs domājat. Slodzes balansētājs, apgrieztais starpniekserveris vai SYN starpniekserveris var atbildēt pirms īstā servera iesaistīšanās, kas ir parasts dizains, nevis simptoms. Derīgs sertifikāts sagaidāmajam nosaukumam arī to nesašaurina, jo sertifikāts apraksta pakalpojuma attiecības un neko nesaka par to, kura mašīna pārtrauca savienojumu.
Nmap portu stāvokļu uzziņa to uzskata par pamata lietu: stāvoklis ieraksta, ko zonde varēja novērot no nosūtīšanas vietas, nevis porta īpašību. Lasiet stāvokļa vārdu tā, un divas palaišanas, kas nesaskanēja, sāk izskatīties konsekventas, nevis pretrunīgas, kamēr jautājums pārvietojas no tā, vai ports ir atvērts, uz to, kas stāvēja tā priekšā.
Atbildiet uz otro jautājumu backendā, nevis no ārpuses. Frontends, kas pieņem savienojumus un pēc tam nenokļūst savā upstreamā, rada tieši veselīga pakalpojuma ar lēnu lietojumprogrammu ārēju ainu. Tikai paša upstream ieraksts šķir abus gadījumus:
tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'Žurnāla rinda parāda klienta adresi, ko lietojumprogramma patiešām redzēja, un otrā komanda parāda, vai process, kas tur portu 443, ir jūsu lietojumprogramma vai kaut kas tā priekšā. Ja abi nesakrīt par to, kura adrese savienojās, jūs skatāties uz viena pieprasījuma divām kājām, un biļetei tas būtu jāsaka.
Pārbaudiet savus noteikumus pirms tuneļa vainošanas
Apzināta politika ir visbiežākais iemesls, kāpēc ports atbild vienā tīklā un ne otrā, un tas ir vismazāk interesantais pieejamais skaidrojums. Piekļuves noteikumi pastāv, lai atļautu vienu avotu un izmestu pārējos, tāpēc izejas maiņa ir tieši tas notikums, kuram tie tika rakstīti. Tāpēc citāds stāvoklis caur VPN neparāda, ka pakalpojumu sniedzējs pārbauda trafiku. Tas parāda, ka jūsu avota adrese tagad ir citāda, kas ir daudz mazāks apgalvojums.
Šos noteikumus var nolasīt serverī, tāpēc izlasiet tos, nevis spekulējiet par tīkla vidu. Uzskaitiet filtra noteikumus, kas piemin kādu no diviem adrešu diapazoniem, pēc tam pārbaudiet, vai savienojums vispār sasniedza dēmonu:
nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113Tukšs otrais rezultāts ir informatīvs, jo nekas nesasniedza dēmonu un jautājums pieder filtram, drošības grupai vai pašam ceļam. Trāpījums nozīmē, ka pakalpojums redzēja jūsu avotu un izvēlējās savu atbildi, un šis lēmums parasti ir ierakstīts noteikumā, ko varat izlasīt. Neviens rezultāts neatbalsta stāstu par pakalpojumu sniedzēju, un abus ir lētāk pārbaudīt nekā uztvert paketes.
Lasiet transportu, sertifikātu un atbildi atsevišķi
Trīs slāņi rada trīs novērojumus, un zonde, kas pārbauda vienu no tiem, nevar ziņot par pārējiem diviem. Turiet tos kā atsevišķas rindas ierakstā, nevis salokiet vienā spriedumā, jo katra rinda neizdodas savā veidā, un kļūmes veids pasaka, kur skatīties tālāk.
| Observation | What it settles | What it leaves open |
|---|---|---|
| Connection completed | A host on the path accepted the handshake | Which host, and whether its upstream is reachable |
| Certificate valid for the name | The endpoint holds a credential for that name | Whether the process behind it is the one you meant |
| Expected response body | The application handled the request | Anything about other ports or other paths |
| Connection refused | A host replied and nothing was listening | Whether a filter sits ahead of the refused port |
| Timeout | No reply arrived before the deadline | Drop, blackhole route or an overloaded host |
Viena komanda rada pirmās trīs rindas pret pakalpojumu, ko kontrolējat. Ielieciet tās izvadi ierakstā blakus skenēšanai, nevis tērzēšanas ziņojumā:
curl -v --resolve office.example:443:203.0.113.20 https://office.example/Lasiet izvadi secībā: rokasspiediens atbild uz transporta jautājumu, sertifikāta subjekts uz vārda jautājumu, un atbildes pamatteksts uz lietojumprogrammas jautājumu. Kad rokasspiediena rinda izdodas un atbildes rinda ne, jums ir frontends ar salauztu upstream, nevis bloķēts ports. Tā ir cita biļete nekā tā, ko atvērāt, un to ir vērts pateikt skaidri.
Pabeidziet, ierakstot biļetē četrus faktus: avota adresi, skenēšanas tipu, resursdatoru, kas atbildēja, un laiku. Viss, kas nepieciešams vēlākam salīdzinājumam, dzīvo šajos četros, un tam, kurš pārņems lietu tālāk, nebūs jūsu termināļa vēstures. Ja nevarat aizpildīt visus četrus, palaidiena nav pabeigta.