informazioni su aggiramento firewall

[foxmolder5]

sto facendo una ricerca per l'uni e devo reperire informazioni su varie tecniche di aggiramento dei firewall. ho analizzato e studiare il metodo dell'http-tunneling però mi è venuta una curiosità quando mi sono informato un pò meglio sull'ipv6, infatti mi è sembrato di capire che un metodo per l'aggiramento del firewall è l'incapsulamento dell'ipv4 in ipv6 in modo tale che il firewall non possa controllare il traffico effettuato. spero di aver capito bene.
in ogni caso, volevo sapere se qualcuno ha a disposizione o conosca qualche link che documenti tale procedura.
vi ringrazio per l'aiuto.
buona giornata

[foxmolder5]

sto facendo una ricerca per l'uni e devo reperire informazioni su varie tecniche di aggiramento dei firewall. ho analizzato e studiare il metodo dell'http-tunneling però mi è venuta una curiosità quando mi sono informato un pò meglio sull'ipv6, infatti mi è sembrato di capire che un metodo per l'aggiramento del firewall è l'incapsulamento dell'ipv4 in ipv6 in modo tale che il firewall non possa controllare il traffico effettuato. spero di aver capito bene.
in ogni caso, volevo sapere se qualcuno ha a disposizione o conosca qualche link che documenti tale procedura.
vi ringrazio per l'aiuto.
buona giornata

UP! per favore un aiuto!! :cry:

[W.S.]

Bhe non è detto, dipende dal firewall:
Il firewall può leggere tutto il pacchetto che gli passa tra le mani, se di questo controlla solo il protocollo e le porte potrebbe essere possibile fregarlo in quel modo, tieni però presente che può ispezionare il contenuto ed accorgersi quindi dell'incapsulamento. Per essere sicuri bisognerebbe cifrare il pacchetto ipv4, incapsularlo in ipv6 e spedirlo ad una macchina dall'altra parte del firewall tramite un protocollo autorizzato, a questo punto la macchina remota preleva l'ipv4, lo decifra e lo manda a chi deve facendo l'operazione inversa per le risposte. Per questo attacco c'è il problema di avere a disposizione una macchina remota e l'applicazione che rimbalza la connessione su di essa.
Non è comunque un modo infallibile (come tutti gli altri modi)! Alcuni firewall (proxy firewall) ispezionano anche il protocollo di alto livello (sopra il tcp o l'udp o quello che si usa) a quel punto bisogna camuffare il traffico "incapsulato" (potremmo anche camuffare una connessione telnet in una http, dipende solo dall'applicazione che ci rimbalza il traffico) per farlo corrispondere al protocollo autorizzato.

Questo è un metodo "generale" poi un singolo firewall può avere dei buchi che permettono di aggirare o modificare le regole, questo è un'altro discorso.

Altro modo può essere quello di sfruttare le debolezze di alcuni protocolli (FTP, msn e altri) che in alcune modalità necessitano di aprire connessioni nuove verso porte normalmente non abilitate. In quel caso nella trasmissione ci sono le informazioni dei nodi (ip, porta e quello che serve) della nuova connessione, quindi il firewall "capisce" che la nuova connessione è da abilitare in quanto associata ala precedente. Creando trasmissioni (e applicazioni) ad hoc è possibile far credere al firewall che la connessione che stiamo aprendo fa parte di quei protocolli (sempre con le limitazioni dei proxy firewall)

Materiale ne trovi in rete, cerca un po nei siti che si occupano di sicurezza e soprattutto usa la tua immaginazione partendo dalle tue conoscenze su come funzionano i firewall e i protocolli di rete (imagino tu ne sappia qualcosa se stai facendo una ricerca sulle debolezze dei firewall)

(azz, uscita lunghetta :) )

[manganese]

cut
(azz, uscita lunghetta :) )
Comunque interessante e soprattutto scritta molto chiaramente..pensa che ci ho capito qualcosa pure io :fagiano: ....complimenti!

[W.S.]

:D :cincin:

[foxmolder5]

Bhe non è detto, dipende dal firewall:
Il firewall può leggere tutto il pacchetto che gli passa tra le mani, se di questo controlla solo il protocollo e le porte potrebbe essere possibile fregarlo in quel modo, tieni però presente che può ispezionare il contenuto ed accorgersi quindi dell'incapsulamento. Per essere sicuri bisognerebbe cifrare il pacchetto ipv4, incapsularlo in ipv6 e spedirlo ad una macchina dall'altra parte del firewall tramite un protocollo autorizzato, a questo punto la macchina remota preleva l'ipv4, lo decifra e lo manda a chi deve facendo l'operazione inversa per le risposte. Per questo attacco c'è il problema di avere a disposizione una macchina remota e l'applicazione che rimbalza la connessione su di essa.
Non è comunque un modo infallibile (come tutti gli altri modi)! Alcuni firewall (proxy firewall) ispezionano anche il protocollo di alto livello (sopra il tcp o l'udp o quello che si usa) a quel punto bisogna camuffare il traffico "incapsulato" (potremmo anche camuffare una connessione telnet in una http, dipende solo dall'applicazione che ci rimbalza il traffico) per farlo corrispondere al protocollo autorizzato.

Questo è un metodo "generale" poi un singolo firewall può avere dei buchi che permettono di aggirare o modificare le regole, questo è un'altro discorso.

Altro modo può essere quello di sfruttare le debolezze di alcuni protocolli (FTP, msn e altri) che in alcune modalità necessitano di aprire connessioni nuove verso porte normalmente non abilitate. In quel caso nella trasmissione ci sono le informazioni dei nodi (ip, porta e quello che serve) della nuova connessione, quindi il firewall "capisce" che la nuova connessione è da abilitare in quanto associata ala precedente. Creando trasmissioni (e applicazioni) ad hoc è possibile far credere al firewall che la connessione che stiamo aprendo fa parte di quei protocolli (sempre con le limitazioni dei proxy firewall)

Materiale ne trovi in rete, cerca un po nei siti che si occupano di sicurezza e soprattutto usa la tua immaginazione partendo dalle tue conoscenze su come funzionano i firewall e i protocolli di rete (imagino tu ne sappia qualcosa se stai facendo una ricerca sulle debolezze dei firewall)

(azz, uscita lunghetta :) )


ora mi sto informando 1 pò. già ero a conoscenza del funzionamento dei firewall, ma purtroppo non riesco a trovare siti che facciano al caso mio, e soprattutto che descrivano queste tecniche.
se gentilmente mi puoi dare qualche sito che si occupa di sicurezza te ne sarei grato.
grazie 1000 :)

[W.S.]

bhe cosi su due piedi direi:
www.securityfocus.org e ci trovi sia bug sia (probabilmente) articoli sul pen-test di firewall

con google cerca bfi, è una ezine in cui ci son articoli veramente interessanti, son quasi certo troverai qualcosa pure li

ora nn posso guardare, ma se sul mio pc trovo qualcosa domattina te lo linko...

[foxmolder5]

bhe cosi su due piedi direi:
www.securityfocus.org e ci trovi sia bug sia (probabilmente) articoli sul pen-test di firewall

con google cerca bfi, è una ezine in cui ci son articoli veramente interessanti, son quasi certo troverai qualcosa pure li

ora nn posso guardare, ma se sul mio pc trovo qualcosa domattina te lo linko...

ti ringrazio. il primo sito l'ho trovato stamattina e vi era un casino di materiale che mi ha permesso di chiarire le idee, infatti ora ho anche individuato la scaletta dei metodi da discutere:
1) Fingerprint: spiegazione e tecniche
2) Tecniche aggiramento specifiche:
2.1) Differenziazione tecniche a seconda del livello di intervento (tunneling, Dll Injection, Dos, Spoofing)
3) Sfruttamento Vulnerabilità (SO, Firewall, Applicazioni, Web Server).

queste sono le linee guida, ed ora mi addentro sui vari metodi vedendo di trovarne altri. ti ringrazio.

[W.S.]

visto che hai pubblicato la scaletta ti sparo un po di idee, vedi tu cosa farne:

- Problemi dovuti a configurazioni errate: sia delle regole del firewall che della progettazione della rete stessa (server pubblici nella rete interna o server privati nella DMZ etc etc) ma anche problemi di traduzione da front-end user-friendly a regole vere.

- Problemi di "fiducia" verso gli utenti interni, inconsapevolmente possono scaricarsi l'ultima backdoor

- Problemi di gestione dei pacchetti malformati (xmas tree, length errate, ...)

- Dos generati dall'accumulo di LOG (si, capita pure questo, soprattutto se l'admin è alle prime armi e decide di loggare tutto) o dalla sottostima del carico che dovrà sopportare il FW

[foxmolder5]

visto che hai pubblicato la scaletta ti sparo un po di idee, vedi tu cosa farne:

- Problemi dovuti a configurazioni errate: sia delle regole del firewall che della progettazione della rete stessa (server pubblici nella rete interna o server privati nella DMZ etc etc) ma anche problemi di traduzione da front-end user-friendly a regole vere.

- Problemi di "fiducia" verso gli utenti interni, inconsapevolmente possono scaricarsi l'ultima backdoor

- Problemi di gestione dei pacchetti malformati (xmas tree, length errate, ...)

- Dos generati dall'accumulo di LOG (si, capita pure questo, soprattutto se l'admin è alle prime armi e decide di loggare tutto) o dalla sottostima del carico che dovrà sopportare il FW

ti ringrazio. alle prime non ci avevo proprio pensato, e l'ultima invece mi sorprende proprio.
per quanto riguarda la sottostima del carico, secondo quali criteri e con quali metodologie si può dimensionare un firewall? e quindi, io attaccante, come posso venire a conoscenza del limite superiore oltre il quale il firewall crasha?
perchè infatti proprio oggi pensavo ad una cosa simile e devo dire che il limite tra crash del firewall e crash della macchina su cui è ospitato è molto lieve, in quanto se il firewall, come spesso succede, rappresenta l'unico punto di transito del traffico tra la rete interna e quella esterna, e la macchina su cui risiede crasha, allora l'attacco è inutile poichè in ogni caso non si riesce + ad entrare nella rete interna.

[W.S.]

parlando di iptables:
Per ogni connessione che il firewall gestisce (sia che la natti sia che ne controlli lo stato: nuova/richiesta/invalida...) il kernel usa circa 250 bytes (prendila con le pinze sono abbastanza sicuro della cifra ma non certo).
Il numero di connessioni massime viene definito in un file (ip_conntrack_max in /proc/sys/net/ipv4) che viene impostato automaticamente all'installazione, a seconda delle risorse della macchina, per darti un'idea:
Pentium 75 Mhz, 32 MB RAM -> 2048 connessioni massime
Xeon 3,2 Ghz, 2 GB RAM -> 65535 connessioni massime

Ovviamente questo valore può essere modificato a seconda delle esigenze.

Una connessione rimane memorizzata finchè non termina o non va in timeout, gli attacchi di flooding cercano di riempire questa "tabella".
Hai ragione, buttar giu il firewall non permette all'attaccante di bypassarlo in quanto blocca la rete, normalmente è come tagliarsi fuori da soli. (con la struttura piena il sistema funziona ancora, manda tanti log, blocca tutte le connessioni ma è ancora utilizzabile).
Tipicamente però il sysadmin si trova, nel giro di pochi minuti, una marea di utenti che rompono per "avere internet" ed è costretto a far qualcosa, chissà che nella confusione non imposti qualche regola più permissiva?
Comunque è un DOS, come attacco mira principalmente a negare un servizio.

P.S.: quanto detto sopra è riferito al firewall integrato nel kernel linux, penso comunque sia abbastanza applicabile un po a tutti i casi, soprattutto in quelli derivati da unix.

[manganese]

Confermo l'efficacia del dos per accumulo di log.
Prima che il nostro admin capisse cosa era successo e riattivasse tutto sono passate + di 4 ore "al buio"...stupido ma efficace!

[foxmolder5]

Confermo l'efficacia del dos per accumulo di log.
Prima che il nostro admin capisse cosa era successo e riattivasse tutto sono passate + di 4 ore "al buio"...stupido ma efficace!

non pensavo mai che potesse succedere una cosa simile :D in ogni caso se ho capito bene quello che succede è che il log non venendo controllato continuamente e ripulito, diventa di dimensioni abnormi e a questo punto il firewall non lo riesce + a gestire e quindi crasha. giusto? ma crasha perchè non riesce a tenerlo tutto in memoria o per altri motivi?

[manganese]

Purtroppo quella parte non la gestisco io (anche perchè non ne sarei in grado) cmq quello che disse l'admin è stato "ci sono stati troppi log in troppo poco tempo" penso che ora abbia imposto una dimensione massima al file di log.
Deduco che prima ripuliva solo i più vecchi, ora ripulisce anche sul criterio del numero.
La cosa "stupefacente" è stato il tempo che ci è voluto per individuare il problema....ammettendo al buona fede :rolleyes:...spesso le cose più stupide sono le più rognose :p

[W.S.]

Se i log vengono scritti sulla stessa partizione del sistema si rischia di riempirla e bloccarlo completamente, ovviamente in casi in cui non si ha spazio da buttare.
Se non stiamo attenti a cosa loggare rischiamo di trovarci talmente tanta roba inutile da rendere i log inutilizzabili (-> offuscamento attacchi).
ma crasha perchè non riesce a tenerlo tutto in memoria o per altri motivi?
I log vengono gestiti dal sistema operativo, non dal firewall, lui si limita a generarli. Solitamente c'è un demone dedicato alla raccolta di questi messaggi ed alla loro scrittura sul disco. non ti so dire se sia possibile crearne talmente tanti da metterlo in ginocchio, non credo.
Personalmente ho visto solo casi di "saturazione della partizione" (mio errore :doh: ) in grado di buttar giu completamente la macchina tramite i log, comunque è probabile che ci siano altre possibilità.
I personal firewall ad esempio potrebbero gestire in prima persona i log e generalmente sono molto più fragili.

[nessunopiu]

Comunque interessante e soprattutto scritta molto chiaramente..pensa che ci ho capito qualcosa pure io :fagiano: ....complimenti!

Quoto e confermo, veramente molto interessante.
"L'incapsulamento" di cui leggo, ha nulla a che vedere con il
tunnelling ?

[W.S.]

Bhe, volendo si, può funzionare anche con il tunneling, nel caso di ipv4 in ipv6 "l'incapsulamento" viene fatto a livello 3 (ip) e quindi se il firewall filtra l'ipv4 in modo diverso rispetto all'ipv6 (con regole diverse) può essere che gli scappi qualcosa.
Il discorso di sopra invece è fatto a livello superiore (>= 4), viene fatto a livello applicazione e non necessita privilegi diversi da quelli dell'applicazione che normalmente gestisce la connessione. Come funzionamento è praticamente lo stesso, solo che non usando uno standard bisogna crearsi un'applicazione remota che gestisce e rimbalza la connessione.
Si, praticamente è un tunneling, solo che se di solito creiamo un tunnel ipv4 in cui far passare traffico ipv6 ed è il sistema operativo che lo gestisce, qui creiamo un tunnel HTTPS (dico https perchè è il + comodo) in cui far passare quello che vogliamo e siamo noi a gestirlo.

[nessunopiu]

[QUOTE=W.S.]Bhe, volendo si, può funzionare anche con il tunneling, nel caso di ipv4 in ipv6 "l'incapsulamento" viene fatto a livello 3 (ip) e quindi se il firewall filtra l'ipv4 in modo diverso rispetto all'ipv6 (con regole diverse) può essere che gli scappi qualcosa.


In effetti da quello che mi è capitato di vedere, è il caso
più frequente.
Grazie, lo credevo anch'io, ma non ne ero sicuro.
Sbaglio nel dire che relativamente alle "tracce" di un traffico socket
i due esempi si equivalgono. ?

[W.S.]

Spe, cosa intendi per traffico socket? Quello usato dai proxy socket o parli di socket a livello programmazione?

Comunque, in generale fin che stiamo sullo stesso protocollo di livello 3 (quindi nessun tunneling ipvX) le tracce sono identiche a quelle della connessione autorizzata, ovviamente è possibile che ci siano ids o simili di mezzo che segnalino traffico un po diverso dal solito ed è per questo che si predilige HTTPS in modo da avere il canale nascosto cifrato.
Se andiamo a chiedere al kernel di generare pacchetti diversi... bhe le cose sono rintracciabili da più punti.
Normalmente comunque non vengono rintracciate.

[W.S.]

Scusa il doppio post, non ho preso in considerazione il caso in cui si è root sulla macchina che genera il traffico.
In questo caso dipende tutto dagli ids nella rete (e sulla macchina remota se è il caso), se sono impostati per controllare l'ipv6 è probabile che generino allert altrimenti probabilmente si lasciano meno tracce.

P.S.: questo in generale, non ho capito bene cosa intendi per traffico socket :)

[nessunopiu]

Spe, cosa intendi per traffico socket? Quello usato dai proxy socket o parli di socket a livello programmazione?

Comunque, in generale fin che stiamo sullo stesso protocollo di livello 3 (quindi nessun tunneling ipvX) le tracce sono identiche a quelle della connessione autorizzata, ovviamente è possibile che ci siano ids o simili di mezzo che segnalino traffico un po diverso dal solito ed è per questo che si predilige HTTPS in modo da avere il canale nascosto cifrato.
Se andiamo a chiedere al kernel di generare pacchetti diversi... bhe le cose sono rintracciabili da più punti.
Normalmente comunque non vengono rintracciate.

Si mi riferivo al primo.
Ed in particolare alle tracce lasciate in HTTP. (V.programmi specifici)
Non HTTPS.

[W.S.]

Bhe, mascherare una connessione dentro l'http non la nasconde ne ai proxy-firewall ne (soprattutto) agli ids.
Comunque, solo delle regole specifiche di controllo del protocollo http possono rilevare la presenza del canale, poi sta a chi crea l'applicazione (quella che nasconde il canale) attenersi il più possiblie al protocollo con cui si vuole mascherare la connessione, se si sta attenti e si diluiscono i dati da trasmettere/ricevere in modo da nasconderli bene è estremamente difficile lasciare tracce. Portando il discorso all'estremo, la cosa che sarà rilevabile sarà la connessione http, ma sembrerà tutto normale.

[nessunopiu]

Bhe, mascherare una connessione dentro l'http non la nasconde ne ai proxy-firewall ne (soprattutto) agli ids.
Comunque, solo delle regole specifiche di controllo del protocollo http possono rilevare la presenza del canale, poi sta a chi crea l'applicazione (quella che nasconde il canale) attenersi il più possiblie al protocollo con cui si vuole mascherare la connessione, se si sta attenti e si diluiscono i dati da trasmettere/ricevere in modo da nasconderli bene è estremamente difficile lasciare tracce. Portando il discorso all'estremo, la cosa che sarà rilevabile sarà la connessione http, ma sembrerà tutto normale.

;)