ModSecurity 2 Data Formats | Cerca per titolo, autore, parola chiave | ||||||||
ModSecurity 2 Data Formats ModSecurity 2 Data Formats. Lo scopo di questo documento è descrivere i formati dei messaggi di ModSecurity: gli alert, i log delle transazioni e i protocolli di comunicazione. Questo dovrebbe permettere una migliore comprensione di come opera ModSecurity ed una migliore integrazione con prodotti e tool di terze parti. ModSecurity™ è un modulo firewall open source e gratuito per il server Apache. Con il 70% degli attacchi sferrati al livello delle applicazioni web, le aziende e le organizzazioni hanno bisogno di un aiuto per mettere in sicurezza i loro sistemi. I firewall denominati Web Application Firewall ( WAF ) vengono proprio impiegati per creare un livello esterno di sicurezza, il cui fine è identificare e prevenire gli attacchi prima che possano raggiungere le applicazioni web. ModSecurity offre una protezione da una varietà di attacchi sferrati contro le applicazioni web, permette il monitoraggio e l'analisi, in tempo reale, del traffico HTTP, senza richiedere cambiamenti consistenti all'infrastruttura esistente. I server web, normalmente, sono ben forniti di strumenti di analisi del traffico web, utilizzati come veri e propri strumenti di marketing, ma, spesso, non sono in grado di registrare il traffico destinato alle applicazioni web. In particolare, molti server non hanno strumenti per catturare i messaggi di richiesta ( header e body ), inviati alle applicazioni residenti. I vostri avversari sanno tutto questo. Ecco perchè, oggi, molti attacchi vengono sferrati attraverso le richieste HTTP POST, rendendo i sistemi ciechi di fronte ad essi. ModSecurity può, invece, intercettare tutte le transazioni HTTP, permettendo di registrare tutte le richieste inviate al server e tutte le risposte spedite dal server. Inoltre, ModSecurity è in grado di monitorare, in tempo reale, il traffico HTTP e di identificare eventuali attacchi, proprio come un web "intrusion detection tool". ModSecurity, come parte integrante della sua attività, emette degli avvisi ( alert ), che possono essere dei semplici "warning" ( non fatali ) o veri e propri errori ( fatali: normalmente, comportano l'intercettazione della transazione in corso ). Un esempio: Access denied with code 505 (phase 1). Match of "rx ^HTTP/(0\\\\.9|1\\\\.[01])$" against "REQUEST_PROTOCOL" required. [id "960034"] [msg "HTTP protocol version is not allowed by policy"] [severity "CRITICAL"] [uri "/"] [unique_id "PQaTTVBEUOkAAFwKXrYAAAAM"]. Se l'avviso è un semplice "warning", la prima parte del messaggio dice, semplicemente, "warning". Se, invece, la transazione viene intercettata, la prima parte del messaggio inizierà con "Access denied". La seconda parte del messaggio spiega il motivo per il quale quell'avviso è stato generato. Visto che il messaggio viene generato in automatico, in base alle regole impostate precedentemente, questa seconda parte del messaggio potrebbe rivelarsi un pochino troppo tecnica, mostrando gli operatori ed i parametri riportati nella regola. E questo potrebbe non dirvi molto sulle reali condizioni in cui il messaggio è stato generato. Una regola ben scritta, quindi, dovrebbe sempre specificare un messaggio più esplicito ( MSG ) che offra maggiori informazioni ( nel nostro esempio: "HTTP protocol version is not allowed by policy" ). I campi di metadati ( offset, id, rev, msg, severity, unique_id, uri, logdata ) sono sempre posti alla fine del messaggio. Ciascuno di questi campi è un frammento di testo, composto da una parentesi quadra, seguita dal nome del campo, seguito dal valore del campo, seguito dalla parentesi di chiusura. Ogni messaggio di ModSecurity appare nel file error log di Apache e viene riportato in un singolo file Audit di ModSecurity.
|
|||||||||
ModSecurity 2 Data Formats | Disclaimer: questo è un link a contenuti ospitati su server esterni. |