Usa Nessus o concentrati sui test manuali?

4

Nessus analizza molte vulnerabilità, quindi dovrei concentrarmi sull'apprendimento di vulnerabilità che non sono coperte da Nessus, come gli attacchi directory traversal? Dovrei lavorare solo sulle vulnerabilità che non sono coperte da Nessus, o imparare tutte le vulnerabilità non coperte o meno da Nessus.

I 2 problemi sono:

  1. Nessus non fornisce un elenco delle vulnerabilità (tutte le vulnerabilità che controlla e in seguito ci dice che è vulnerabile a queste serie di vulnerabilità) che può trovare.
  2. Non abbiamo idea di quanto sia efficiente Nessus (come per l'attacco XSS, c'è una grande lista di metodi di evasione dei filtri su OWASP, non ho idea di quanti di questi siano coperti da Nessus).

Consiglia per favore.

    
posta ErrorrrDetector 30.04.2016 - 21:13
fonte

2 risposte

5

Mettendo da parte che stai usando Nessus, lascia che risponda in termini di utilizzo di qualsiasi web application scanner come strumento.

Gli scanner automatici sono ottimi strumenti per un test rapido e ripetibile che può trovare i problemi più comuni con i siti web. Non vorrei mai svilupparmi senza utilizzare strumenti automatici.

Ma bisogna sempre capire che questi strumenti hanno gravi limitazioni e punti deboli. Nessuno strumento è perfetto.

Quindi, dipende dal risultato che desideri. Se si desidera una comprensione completa del proprio codice, è necessario un processo completo per coprire il codice. Cose come:

  • recensioni di codice
  • modellazione delle minacce
  • scanner automatici
  • test manuali
  • Test manuali di terze parti

Per ogni cosa che decidi di non includere nel tuo processo, scegli anche di perdere quel livello di completezza di comprensione.

Se si dipende esclusivamente da strumenti automatici, si rinuncia a molto. Anche se si utilizzano strumenti, è comunque una buona idea comprendere tutti gli attacchi comuni sui siti Web e capire come controllarli manualmente. Se per nessun altro motivo, che controllare i falsi positivi.

    
risposta data 30.04.2016 - 21:30
fonte
1

Ecco un esempio del potenziale per (e contro) l'automazione nei test di penetrazione della rete:

  1. Inizia con un modo generale di organizzare le tue informazioni da più strumenti. Molti considerano Faraday , ma se non ti piace, commenta la tua esperienza e fornirò altri consigli. Esiste un servizio commerciale, Dradis Pro che molti considerano equivalente o migliore della maggior parte delle altre opzioni per l'organizzazione dei dati del test penna.
  2. Dai al pen-test un buon inizio con uno strumento come discover.sh . Ciò fornirà molta attenzione e coordinamento tra gli strumenti.
  3. Sfrutta nmap. Se vuoi vedere "tutti i vulns", prendi in considerazione l'utilizzo del rilevamento della versione, lo shodan-api dello script NSE e la categoria NSE vulneraria di script con gli argomenti dello script per mostrare tutte le vulnerabilità che potrebbero essere potenzialmente tentate.

nmap --open --randomize-hosts --min-rate 450 --script shodan-api,vuln,reverse-index --script-args vulns.showall -sSUV -pT:0-,U:7,9,11,13,17,19,36-37,42,49,53,67,69,88,111,123,135,137,139,161-162,177,213,259,260,407,445,464,500,523,623,1604,1645,1812,5353,5632,6481,6502,10080,17185,49152

  1. Utilizza altri script NSE di nmap, inclusi quelli di terze parti come vulscan . Trova di più su GitHub che si riferiscono ai tuoi obiettivi. Ora sentirai che stai facendo più lavoro manuale!
  2. Invece di iniziare con Nessus o Metasploit, integrali con ciò che hai fatto con nmap usando strumenti come nmap2nessus e < a href="https://github.com/milo2012/metasploitHelper"> metasploitHelper .
  3. Puoi perfino eseguire gli script Nessus manualmente, come quello visto qui - link
  4. Vai oltre! Prova più strong! Concentrati sui percorsi di attacco anziché sugli strumenti. Ad esempio, che dire di autenticazione o escalation di privilegi ? Che dire di LFI o IDOR , o come hai detto, Attraversamento del percorso . Solitamente vorrai esplorare questi problemi con Burp Suite Professional o con alternativa sul livello webapp, ma ci sono così tanti altri livelli che possono essere esplorati, ad esempio, DB, middleware, mobile, mainframe, veicolare (cioè CAN Bus), sistemi embedded, ecc.
risposta data 30.04.2016 - 22:18
fonte

Leggi altre domande sui tag