Firewalk attraverso un firewall sulla nostra sottorete

5

Problemi con la camminata sul fuoco. Sto cercando di determinare tutte le porte aperte sul mio firewall / gateway. Ecco il diagramma di rete del mio laboratorio:

(Vaiallafinedellaseguentespiegazioneperunelencodirettodellemiedomande)

Dettaglidiconfigurazione:

  • FirewallèunASA5505conroutestatiche.
  • IlfirewallrisponderàallerichiesteechoICMPa192.168.1.2.
  • IlfirewallhalaportaTCP31337lasciataintenzionalmenteapertainmodochepossiamorilevarlacomepartedell'esercizio.
  • L'"host" a 192.168.1.4 agisce da "attaccante" nel tentativo di determinare le porte aperte.
  • L '"attaccante" esegue Kali linux.
  • L'host "Target" esegue Windows Web Server 2008 (non è sicuro che sia importante).

Metodi tentati:

Ho provato sia lo strumento "Firewalk" di Packetfactory che anche script firewalk Nmap . Ecco alcuni esempi della sintassi che sto usando:

Nmap: nmap --traceroute --script=firewalk --script-args=firewalk.max-probed-ports=-1 192.168.3.11

SINTASSI CORRETTI PER NMAP: (risolto questo!) nmap --traceroute --script=firewalk 192.168.3.11 -p1-65535

  • NMAP esegue solo la scansione delle porte comuni per impostazione predefinita. È necessario specificare l'intervallo di porte completo.

Ho semplicemente dovuto aggiungere gli switch di scansione delle porte nmap in quanto questi non sono argomenti che possono essere passati allo script del firewalk. Sto ancora imparando ...

Firewalk: firewalk 192.168.1.2 192.168.3.11

Risultati attuali dei metodi di firewalking:

Nmap (questa lista è incompleta ma non dovrebbe essere - la porta 31337 è stata aperta intenzionalmente su questo firewall)

 Starting Nmap 6.47 ( http://nmap.org ) at 2015-03-17 11:15 EDT
 Nmap scan report for 192.168.3.11
 Host is up (0.0026s latency).
 Not shown: 987 closed ports
 PORT      STATE    SERVICE
 80/tcp    open     http
 111/tcp   filtered rpcbind
 135/tcp   filtered msrpc
 139/tcp   filtered netbios-ssn
 445/tcp   filtered microsoft-ds
 1720/tcp  filtered H.323/Q.931
 2000/tcp  filtered cisco-sccp
 5060/tcp  filtered sip
 49152/tcp filtered unknown
 49153/tcp filtered unknown
 49154/tcp filtered unknown
 49155/tcp filtered unknown
 49156/tcp filtered unknown

 Host script results:
 | firewalk: 
 | HOP  HOST          PROTOCOL  BLOCKED PORTS
 |_0    192.168.1.43  tcp       111,135,139,445,1720,2000,5060,49152-49156

 TRACEROUTE (using port 1025/tcp)
 HOP RTT     ADDRESS
 1   3.19 ms 192.168.3.11

Firewalk

 Firewalk 5.0 [gateway ACL scanner]
 Firewalk state initialization completed successfully. UDP-based scan.
 Ramping phase source port: 53, destination port: 33434
 Hotfoot through 192.168.1.2 using 192.168.3.11 as a metric.
 Ramping Phase:
 1 (TTL  1): *no response*
 2 (TTL  2): *no response*
 ...
 25 (TTL 25): *no response*
 Scan aborted: hopcount exceeded.

Domande:

  • Perché lo strumento "Firewalk" non vede mai il gateway di destinazione (firewall su 192.168.1.2)? Sembra che Nmap sia in grado di
  • Perché lo script di Nmap Firewalk non mostra tutte le porte aperte?
  • Come posso configurare gli argomenti degli script di Firewall Nmap per SOLO controllare il firewall per la porta 31337 TCP? ( trovato questo! -p31337 o -p1-65535 . Duh - vedi la sintassi corretta sopra)

P.S. anche grazie a "Gliffy" per il fantastico strumento per la creazione di diagrammi di rete online:)

    
posta Shrout1 17.03.2015 - 18:21
fonte

1 risposta

2

Secondo man page , il firewalk sembra avere bisogno dei seguenti flag per poter scansionare correttamente quando sei un hop dal tuo gateway (come si vede nella tua bella immagine di Gliffy).

firewalk -d 49152 -r 192.168.1.2 192.168.3.11

    
risposta data 17.03.2015 - 19:36
fonte

Leggi altre domande sui tag