Web App Esegue la scansione delle scansioni attraverso il firewall di rete?

2

Ho uno scenario. Voglio eseguire la scansione di un'app Web collocata in un'altra CC dietro un firewall diverso (non firewall per applicazioni Web). Possiamo avere porte aperte per raggiungere l'applicazione. Gli strumenti generalmente utilizzati dai tester sono Acunetix, Appscan, burp e webinspect. Il server Web non è dietro un PAT o Nat. Potrebbe essere stato tuttavia bilanciato.

C'è una seria preoccupazione che questi scanner aziendali possano DOSare il firewall o degradare la rete? Le scansioni delle app Web non dovrebbero mai essere eseguite attraverso un firewall di rete? Il firewall non dovrebbe essere in grado di gestire il traffico da una singola istanza dello scanner Web?

Ho cercato di trovare qualche ricerca online, ma quasi tutti gli scenari hanno parlato di scenari NAT o PAT per uno scanner di porte (nmap) o uno scanner di vulnerabilità (qualys), che non è il caso qui.

    
posta Sanchit Sharma 31.01.2017 - 06:48
fonte

1 risposta

2

Alcuni scanner webappsec sono in realtà più lenti di un utente che utilizza un browser basato su XP.

Se Burp Suite Pro Intruder (o Scanner o Spider) è ottimizzato su oltre 100 thread, ad esempio 175 thread, le cose iniziano a cadere, ma solitamente la memoria dei server di destinazione prima di bilanciamento del carico o firewall nel mezzo. Il massimo utilizzato per essere 175 thread, ma è cambiato in 999 thread nel 2014.

Alcuni firewall basati su software cadranno sotto il carico di uno scanner webappsec ottimizzato crudelmente, ma non di appliance o hardware. Ad esempio, un Palo PA-3020 continuerà a spingere il traffico verso le destinazioni se si dispone di 20 o addirittura 30 tester di penetrazione utilizzando gli scanner webappsec. Tuttavia, un Palo VM-100 potrebbe cadere solo a 2 o 3 tester di penetrazione perché è per lo più basato su software.

WebInspect, AppScan e Acunetix sono più belli della configurazione massima di Burp Suite Pro Intruder (ad esempio, WebInspect consente solo un massimo di 80 thread simultanei). Anche quando ho ottimizzato questi altri scanner con i max thread supportati dalla loro configurazione, il peggiore che sia mai accaduto è che un server web o due si blocchino. Non è mai stato bloccato WAF, IPS o bilanciamento del carico nello stesso modo. Fingi che questo mi sia successo dieci volte nella mia vita e che metà del tempo un server web è stato bloccato e l'altra metà del tempo due server web bloccati. Ogni volta, indipendentemente dal numero di server Web bloccati, la causa principale dell'errore era dovuta al fatto che il server Web aveva solo 256 M, 512 M o 768 M di vDRAM. In ogni caso questi erano sistemi operativi guest di un hypervisor basato su virtualizzazione del server o un ambiente di hosting condiviso. Era abbastanza semplice chiedere all'amministratore di sistema IT remoto di spegnere il server, dargli un po 'di più di vDRAM (di solito 1G era sufficiente) e riavviarlo.

Di solito il modo migliore per determinare se c'è un problema è quello di ospitare la tua infrastruttura di pen-test (i tuoi host attaccanti) con un gateway su cui è in esecuzione Linux. Quindi, puoi sfruttare ntop o tcptrace per cercare ritrasmissioni . Se non ricevi alcuna ritrasmissione, o una quantità molto piccola, allora nessun danno, nessun fallo. A volte vedrai che gli strumenti abbreviano le ritrasmissioni come retrans, rexmit o rexmt. Controlla il libro, TCP / IP Illustrated, Volume I: I protocolli, Seconda edizione per ulteriori informazioni sull'interoperabilità di TCP.

    
risposta data 31.01.2017 - 07:28
fonte

Leggi altre domande sui tag