Nmap – Rezultat intens vs. rezultat rapid (Securitatea informațiilor, Firewall-Uri, Nmap, Porturi, Iptables)

kiltek a intrebat.
a intrebat.

Am moștenit o rețea mică și, în prezent, evaluez performanțele de securitate ale acesteia.

Am început să scanez portul unei gazde (să o numim Weirdo) din acea rețea mică și, din punctul meu de vedere, se pare că acea gazdă specifică are un fel de detector de scanare a porturilor și/sau obfuscator al rezultatelor scanării cu iptables pentru că rezultatul care vine de la intensă diferă atât de mult de cel al scanării rapidă rapidă.

Deci, aici rapidă rezultatul scanării rapide [email protected]:~# nmap -T4 -F 12.34.56.78:

Starting Nmap 7.01 ( https://nmap.org ) at 2017-04-18 11:48 CEST
Nmap scan report for 12.34.56.78
Host is up (0.57s latency).
Not shown: 93 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
25/tcp   open  smtp
53/tcp   open  domain
80/tcp   open  http
3306/tcp open  mysql
8080/tcp open  http-proxy
8443/tcp open  https-alt

Nmap done: 1 IP address (1 host up) scanned in 4.15 seconds

Acesta arată de fapt același rezultat ca și în cazul scanării rapide de la Weirdo localhost [email protected]:~# nmap -T4 -F localhost.

Dar aceasta este intensă scanare [email protected]:~# nmap -T4 -A -v 12.34.56.78:

1/tcp     open  tcpmux?
...(every port is shown as open, except a few)
49155/tcp open  unknown
...
9102/tcp  open  jetdirect?
... 
65389/tcp open  tcpwrapped
...
Completed SYN Stealth Scan at 11:49, 18.22s elapsed (1000 total ports) 
... 
Not shown: 120 closed ports

Notă: ... înseamnă repetarea liniei anterioare cu un număr de port diferit.

Deci, în esență intensă găsește că sunt deschise mult mai multe porturi, dar acest lucru este paradoxal, deoarece scanarea intensă pe Weirdo localhost [email protected]:~# nmap -T4 -A -v localhost oferă, de asemenea, exact aceeași listă de porturi deschise ca și scanarea rapidă.

Când mă uit la traceroute atunci văd următoarele:

TRACEROUTE (using port 199/tcp)
HOP RTT     ADDRESS
1   1.52 ms 12.99.34.255
2   1.37 ms 12.99.0.3
3   1.09 ms 12.34.56.78

Port Scanning the two ips with [email protected]:~# nmap -sV -T4 -O -F --version-light 12.99.34.255 12.99.0.3 văd că 12.99.34.255 este un Firewall Netgear FVS336Gv2 accesibil cu browserul (portul 80, este deschis deci).

O scanare consecutivă (la 1 secundă după), rapidă (după scanarea intensă) are ca rezultat același rezultat ca și scanarea intensă.

După câteva secunde de așteptare și după ce se face din nou scanarea rapidă, rezultatul este același ca la scanarea rapidă inițială.

Probabil că acest firewall joacă feste cu scanarea intensă?

Încă o mică adăugare:

Pe Weirdo am verificat firewall-ul iptables și am obținut următoarele:

[email protected]:~# iptables -vL -t filter
Chain INPUT (policy DROP 25288 packets, 1768K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 101K   54M ACCEPT     all  --  lo     any     anywhere             anywhere            
 189K   12M ACCEPT     all  --  eth1   any     anywhere             anywhere            
  285  9686 ACCEPT     icmp --  eth0   any     anywhere             anywhere             icmp echo-request
  297 30354 garbage    all  --  eth0   any     anywhere             anywhere             state INVALID
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: FIN,SYN,RST,PSH,ACK,URG/NONE
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: FIN,SYN/FIN,SYN
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: SYN,RST/SYN,RST
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: FIN,RST/FIN,RST
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: FIN,ACK/FIN
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: PSH,ACK/PSH
    0     0 garbage    tcp  --  eth0   any     anywhere             anywhere             tcpflags: ACK,URG/URG
1968K 2742M ACCEPT     all  --  eth0   any     anywhere             anywhere             state RELATED,ESTABLISHED
 9564  391K ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:http
  463 27508 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:domain
   45  2392 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:8443
    0     0 ACCEPT     tcp  --  eth0   any     anywhere             anywhere             tcp dpt:9422
25288 1768K garbage    all  --  eth0   any     anywhere             anywhere            

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1361K packets, 501M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain garbage (9 references)
 pkts bytes target     prot opt in     out     source               destination 

Sunt aceste filtre care joacă feste la scanarea intensă?

Ce înseamnă să ai o regulă cu țintă garbage ?

Comentarii

  • Pentru a verifica rezultatele scanărilor sistemului în cauză („weirdo”), capturați toate datele de rețea pe care le produc cu ajutorul unui analizor de protocol precum wireshark. Examinarea datelor de rețea brute din captură vă va permite să determinați dacă nmap produce falsuri pozitive pentru porturi deschise sau interpretează incorect rezultatele scanărilor. –  > Por julian.
1 răspunsuri
bonsaiviking

În primul rând, să corectăm câteva ipoteze și terminologie care vor face înțelegerea rezultatelor mult mai ușoară:

  • -F opțiunea este o scanare „rapidă” deoarece scanează doar 100 de porturi. Este echivalentă cu --top-ports 100. Fără această opțiune, Nmap scanează 1000 de porturi TCP.
  • Opțiunea -A opțiune nu este „intensă”, ci mai degrabă „Toate caracteristicile”. Este echivalentă cu -sV -sC -O --traceroute.

Așadar, ați efectuat o scanare a 100 de porturi și o comparați cu o scanare a porturilor cu detectarea versiunilor și amprentarea sistemului de operare pentru 1000 de porturi. Este de înțeles că veți avea mai multe rezultate la cea de-a doua scanare. Dar să presupunem că ați vrut să spuneți literalmente „fiecare port este deschis” în cea de-a doua scanare. Care ar putea fi cauza și cum putem ști cu siguranță?

În primul rând, ar fi interesant de știut dacă -F produce rezultate diferite dacă se execută după -A scanare. Bănuiesc că da. Acest lucru ar arăta atunci că ceva (probabil firewall-ul) a schimbat modul în care pachetele sunt transmise între sistemul de scanare și țintă. Iată indiciile pe care le văd în cea de-a doua scanare:

  • mai multe porturi deschise
  • servicii neidentificate (tcpmux?) și tcpwrapped servicii
  • porturi deschise listate care nu se regăsesc într-o scanare localhost a țintei

Iptables nu este suficient de inteligent de unul singur pentru a adapta un astfel de comportament și nici în regulile dumneavoastră nu există nimic care să arate acest lucru. Așadar, interferența provine probabil de la un sistem diferit pe traseul de rețea dintre scaner și țintă. Dacă ați fi salvat ieșirea XML (-oX sau -oA) sau dacă ați fi folosit opțiunea --reason (activată și ea de asemenea de -vv sau -d), atunci ați fi putut vedea detalii despre de ce Nmap a considerat fiecare port deschis sau închis. Cea mai interesantă parte a acestui aspect este reason_ttl care înregistrează valoarea câmpului IP Time-To-Live primit, care este în mod normal decrementată o dată pentru fiecare salt IP de pe calea rețelei. Astfel, pentru o țintă Linux, răspunsurile încep cu TTL 64 și, cu 2 salturi între ele, ar trebui să fie reduse la 62. Indiferent de ceea ce vedeți în cea mai precisă versiune a scanării (și anume, versiunea -F scanare cu majoritatea porturilor închise) este linia dvs. de bază. Dacă începeți să vedeți valori mai mari decât aceasta, cel mai probabil ar însemna că ceva între dumneavoastră și țintă trimite răspunsuri în locul țintei. Exemplu (portul 27 este „fake-open”):

PORT   STATE    SERVICE REASON
25/tcp open     smtp    syn-ack ttl 60
27/tcp open     nsw-fe  syn-ack ttl 61
80/tcp open     http    syn-ack ttl 60

Pentru a evita acest lucru, va trebui probabil să încetiniți scanarea pentru a evita declanșarea pragului de alertă „scanare port”. Evitarea măsurilor adaptive de acest tip este complicat. Dar, odată ce ați declanșat pragul, puteți face unele lucruri interesante pentru a cartografia regulile firewall-ului.

Dacă în prezent sunteți „blocat” în acest mod cu o mulțime de porturi deschise, dar puteți accesa în continuare serviciile reale din spatele setului original de porturi (ssh, smtp, http etc.), atunci puteți încerca să setați o valoare TTL foarte mică în pachetele de ieșire. Atunci când un router scade TTL la 0, acesta va trimite un mesaj ICMP Time Expired, ceea ce face ca portul să fie etichetat ca fiind filtered. Dacă putem alege un TTL care expiră după firewall-ul, dar înainte de ținta, putem obține o listă de porturi „deschise” care sunt cauzate de firewall și un set de porturi „filtrate” care sunt probabil permise. În exemplul dvs., pe baza rezultatului traceroute, aș folosi --ttl 2 deoarece --ttl 3 ar ajunge de fapt la țintă. Astfel, scanarea ar arăta astfel: nmap -sS --ttl 2 -Pn example.com. Folosind -Pn nu este de obicei recomandată, dar în acest caz este necesară, deoarece sondele nu vor ajunge niciodată la țintă. Reamintim: această scanare va produce rezultate utile numai dacă sunteți blocat în prezent de firewall și dacă blocajul nu se referă la fiecare port, ci lasă să treacă o parte din trafic:

PORT   STATE    SERVICE REASON
25/tcp filtered smtp    time-exceeded from 12.99.34.255 ttl 252
27/tcp open     nsw-fe  syn-ack ttl 61
80/tcp filtered http    time-exceeded from 12.99.34.255 ttl 252

În această ieșire, portul 27 a primit un syn-ack falsificat pentru a părea că provine de la țintă, deși știm din datele noastre de la --ttl 2 că sonda noastră nu ar fi ajuns niciodată la țintă. Celelalte două porturi sunt permise, deoarece primim mesajele de depășire a timpului din momentul în care au expirat. În cazul în care firewall-ul nu permite mesajele de ieșire cu timp depășit, atunci acestea ar apărea ca fiind filtered cu un no-response motiv.

Comentarii

  • Așadar, baza dumneavoastră este că există un mecanism care face această „amestecare a rezultatelor”. M-a ajutat foarte mult. –  > Por kiltek.