Archivi tag: attack

Configurare un firewall Cisco PIX 501 come IDS

Premesso che i PIX 501 sono molto limitati come IDS, in quanto supportano soltanto circa 70 signature (piuttosto datate), può tornare comunque utile configurarli come Intrusion Detection System di prima linea, a cui associare dei sistemi più sofisticati, basati ad esempio su snort.

PIX-501.gif.jpg

Ovviamente, affinchè l’IDS possa svolgere il suo compito è necessario abilitare il logging dei pacchetti “sospetti”, reindirizzandoli su un’altra macchina (aka logserver), in modo da non causare eventuali memory leak al nostro piccolo firewall (soprattutto se la mole di traffico che deve esaminare è piuttosto elavata).

Ma veniamo alla configurazione del PIX. Per prima cosa digitiamo il comando (in modalità enable):

NightFirewall# sh run | i ip audit

il cui output sarà:

ip audit info action alarm
ip audit attack action alarm

Esso rappresenta le due tipologie di signature che possono essere gestite dal firewall, ovvero info ed attack, con le rispettive azioni di default (che in entrambi i casi è alarm).

Definiamo adesso delle nuove policy di audit digitando:

NightFirewall# conf t
NightFirewall(config)# ip audit name esterna info 
NightFirewall(config)# ip audit name interna attack action drop

La prima policy è di tipo info, la seconda è di tipo attack a cui è associata l’azione drop nel caso in cui vengano individuati dei pacchetti sospetti.

Associamo le policy di audit appena create alle interfacce del nostro PIX:

NightFirewall(config)# ip audit interface outside esterna
NightFirewall(config)# ip audit interface inside interna

ed infine lanciamo un write mem per salvare la nuova configurazione:

NightFirewall(config)# write mem

Ora il nostro PIX si comporterà come un IDS.

A presto.

PS: i log generati dal firewall avranno sa seguente struttura:

Oct 22 17:57:26 nightfirewall.*.org %PIX-4-400014: IDS:2004 ICMP echo request from 172.16.*.* to 172.16.*.* on interface inside
Oct 22 17:59:16 nightfirewall.*.org %PIX-4-400014: IDS:2004 ICMP echo request from 172.16.*.* to 192.168.*.* on interface inside
Oct 22 17:59:16 nightfirewall.*.org %PIX-4-400010: IDS:2000 ICMP echo reply from 192.168.*.* to 192.168.*.* on interface outside

In questo caso l’IDS ha generato dei falsi positivi, in quanto trattasi semplicemente di alcuni ping lanciati da nagios per i suoi check.

Ho quindi proceduto a disattivare le signature coinvolte utilizzando i seguenti comandi:

NightFirewall(config)# ip audit signature 2000 disable
NightFirewall(config)# ip audit signature 2004 disable

Attacco log injection

L’analisi dei log rappresenta una delle operazioni più importanti dell’ambito della sicurezza dei sistemi, in quanto consente di individuare eventuali tentativi di attacco provenienti dall’esterno (Internet) o dall’interno (la nostra LAN oppure il nostro stesso PC). Inultile dire che, affinchè l’identificazione degli attacchi ed eventualmente degli attaccanti abbia buon fine, è assolutamente necessario che i log siano integri e non siano soggetti a possibili operazioni di tampering (alterazione), il cui scopo è proprio quello di confondere le acque e rendere più difficile il lavoro del sys/net admin di turno.

Ora, esistono sostanzialmente due metodi per attaccare direttamente i file di log: il primo consiste nall’alterazione diretta degli stessi attraverso l’inserimento di stringhe forgiate appositamente per rispecchiare la sintassi dei log creati dall’applicazione vittima; il secondo ha come obiettivo quello di inviare un numero molto elevato di attempt in modo da far aumentare le dimensioni dei file di log e provocare una sorta di attacco DoS basato sull’esaurimento di una risorsa fondamentale, ovvero la memoria di massa (leggasi spazio sull’hard disk).

Affinchè la manomissione dei log possa avvenire nonostante l’attaccante non abbia i permessi di scrittura su tale tipo di file, è indispensabile identificare la sintassi utilizzata in fase di logging dall’applicazione che si vuole attaccare.

Facciamo un esempio pratico. Supponiamo che l’attaccante, dopo una scansione mediante nmap, identifichi apache tra i servizi attivi sulla nostra macchina. L’accesso al sito Web è inoltre subordinato e vincolato dall’inserimento delle giuste credenziali (username e password), misura di sicurezza realizzata attraverso un file .htaccess. La prima cosa che farà l’attaccante sarà quella di studiarsi la sintassi che caratterizza i file di log dell’applicazione in questione. Una volta identificata tale sintassi, creerà delle righe apposite da inserire nei campi di input visualizzati dal browser ed il cui scopo è quello di permettere ad un utente di autenticarsi e quindi accedere ai contenuti del sito Web.

Un file di log non alterato potrebbe apparire nel seguente modo:

 User login failed for: guest
 User login failed for: admin

Nel caso in cui, però, l’attaccante inserisse nei campi di input la seguente stringa:

guest (backslash)nUser login succeeded for: admin

otterrebbe come risultato:

 User login failed for: guest
 User login succeeded for: admin

proprio grazie all’ausilio del carattere di newline (backslash)n.

Inutile dire che una semplice contromisura a questa tipologia di attacco si basa sulla validazione dell’input e sul whitelisting di determinati caratteri (ad esempio mediante l’uso delle espressioni regolari).

Per ciò che concerne invece gli attacchi DoS menzionati in precedenza, una valida contromisura è rappresentata da un uso corretto del logrotate, il quale consente di archiviare i file di log solo per un certo lasso di tempo, provvedendo anche alla compressione degli stessi per risparmiare spazio sull’hard disk.

Fine del post. See ya.

PS: mi dispiace per l’assenza del carattere backslash, ma a quanto pare myblog lo rifiuta categoricamente (credo per motivi di sicurezza).