Sto progettando un sistema di rilevamento delle intrusioni basato su anomalie in java. Fondamentalmente consiste in uno sniffer che identifica i campi dell'intestazione HTTP e li analizza in base a un precedente file XML configurato.
La mia domanda è: cosa succede se il mio sistema utilizza HTTPS? come posso leggere i campi dell'intestazione HTTPS se sono tutti crittografati?
Modifica: solo così prevedo i commenti lungo le linee non sai nulla su come funziona IPS, lo stabilirò e indirizzerò invece la mia risposta al metodo generale di ispezione del traffico HTTPS.
La risposta breve è che non puoi.
La lunga risposta è che dovresti eseguire attacchi MITM contro le connessioni. Questo può essere fatto nei casi in cui si hanno solo connessioni HTTPS autenticate da server se si può forzare tutti i client a fidarsi di un certificato sotto il proprio controllo. Viene spesso utilizzato, ma secondo me è una cattiva pratica di sicurezza, poiché di solito qualunque certificato utilizzi, avrà minori garanzie di sicurezza rispetto a quelle solitamente utilizzate dai browser e dagli utenti. Anche se non lo stai aggiungendo un nuovo punto di attacco.
Se devi utilizzare l'attacco MITM, assicurati di controllare almeno che i certificati che ricevi (dai server) siano corretti, applicabili per i server attendibili e non sui CRL.
Un altro sottoprodotto di questo approccio è che probabilmente stai insegnando ai tuoi utenti pratiche di sicurezza discutibili dal momento che saranno disposti a fidarsi ovviamente di certificati falsi per i server con cui comunicano. Poi, quando vanno in un hotel e vedono lo stesso problema, potrebbero semplicemente presumere di fare la stessa cosa e divulgare felicemente tutti i segreti aziendali su connessioni insicure.
Gli IDS classici funzionano a livello di rete e quindi non possono gestire connessioni crittografate come HTTPS che si verificano a livello di applicazione o di presentazione (vedi modello OSI ). Tuttavia, dal momento che sei interessato solo a rilevare gli attacchi controllando i campi di intestazione HTTP (cioè gli attacchi a livello di applicazione) potresti invece creare un proxy HTTP (trasparente) e poi fare analisi direttamente a livello di applicazione senza preoccuparti del livello di rete. A questo livello si può anche fare intercettazione SSL e ci sono vari esempi su come questo può essere fatto (come mitmproxy ).
Ovviamente, in questo modo non si esegue più un'analisi passiva della rete, ma si è invece un'applicazione attiva nel percorso di rete che inoltra i dati dopo averlo verificato. Solitamente questo non viene chiamato IDS ma invece un gateway a livello di applicazione (ALG).
Secondo NIST - Pubblicazione speciale 800-94 Guida al rilevamento delle intrusioni e sistemi di prevenzione IDPS :
Network-based IDPSs cannot detect attacks within en crypted network traffic, including virtual private network (VPN) connections, HTTP over SSL (HTTPS), and SSH sessions. As previously mentioned, some network-based IDPSs can do some analysis of the setup of encrypted connections, which can identify that the client or server software has known vulnerabilities or is misconfigured. To ensure that sufficient analysis is performed on payloads within encrypted network traffic, organizations should use IDPSs that can analyze the payloads before they are encrypted or after they are decrypted. Examples include placing network-based IDPS sensors to monitor unencrypted traffic (e.g., traffic that entered an organization through a VPN gateway and has since been decrypted) and using host-based IDPS software to monitor activity within the source or destination host.
Continuerò a sviluppare il mio IDS solo per ascoltare la porta 80. Il mio IDS è basato sull'anomalia poiché utilizza le reti bayesiane per ridurre i tassi di falsi positivi. Dal momento che Snort è basato sulla firma, non avrebbe partecipato ai miei obiettivi.
Forse non mi sono reso chiaro ma il riferimento principale è del mio lavoro può essere trovato qui .