 | |
Il progetto dsy.it è l'unofficial support site dei corsi di laurea del Dipartimento di Scienze dell'Informazione e del Dipartimento di Informatica e Comunicazione della Statale di Milano. E' un servizio degli studenti per gli studenti, curato in modo no-profit da un gruppo di essi. I nostri servizi comprendono aree di discussione per ogni Corso di Laurea, un'area download per lo scambio file, una raccolta di link e un motore di ricerca, il supporto agli studenti lavoratori, il forum hosting per Professori e studenti, i blog, e molto altro...
In questa sezione è indicizzato in textonly il contenuto del nostro forum |
[domanda] firewall
Clicca QUI per vedere il messaggio nel forum |
| kokorina |
Stavo studiando sugli appunti la parte che riguarda il fw.
mi sembra di capire che esistono 4 tipi di firewall rispatto al livello a cui lavorano:
- data link
- rete
- trasporto
- applicazione
poi però ho appunti su questi tipi di fw:
- packet filter (che metterei nel livello trasporto)
- fw transport gateway (che metteri anche lui a livello trasporto)
- proxy (che metterei a livello applicazione)
- host gate (??? o based??? ho appunti contrastanti) che è un fw a sè stante che lavora con i processi e non può essere inserito nei 4 tipi sopra descritti.
è giusto quello che ho scritto?
non sono stati quindi fatti esempio su FW a livello data link e a livello rete?
grazie
koko |
| sullivan |
Ciao,
Originally posted by kokorina
Stavo studiando sugli appunti la parte che riguarda il fw.
mi sembra di capire che esistono 4 tipi di firewall rispatto al livello a cui lavorano:
- data link
- rete
- trasporto
- applicazione
poi però ho appunti su questi tipi di fw:
- packet filter (che metterei nel livello trasporto)
- fw transport gateway (che metteri anche lui a livello trasporto)
- proxy (che metterei a livello applicazione)
- host gate (??? o based??? ho appunti contrastanti) che è un fw a sè stante che lavora con i processi e non può essere inserito nei 4 tipi sopra descritti.
I firewall packet filter possono lavorare anche a livello datalink e rete; nel primo caso, possono specificare regole che vanno ad ispezionare, ad esempio, il mac address sorgente e/o destinazione.
In genere, comunque, regole a livello datalink non sono cosi` diffuse, ma regole che vanno a esaminare informazioni che si trovano a livello rete e trasporto decisamente si. Pensa ad esempio ad una regola che faccia passare solo i segmenti TCP con flag SYN (e solo quello) attivato, destinati ad una porta particolare, soltanto se provengono da un certo indirizzo IP; le informazioni devono essere reperite a livello rete (IP) e trasporto (TCP).
L'ultimo che hai citato e` host-based; pensa ai personal firewall che possono, per loro natura, operare a tutti i livelli perche` hanno a disposizione piu` informazioni, in genere, rispetto ad altre tipologie di firewall in quanto le regole si riferiscono alla macchina sulla quale sono eseguiti (possibilita` di determinare l'applicazione che sta tendando di "comunicare" in rete, etc etc)
Ultima cosa e` da non dimenticare e` che i firewall packet filtering possono essere stateless o stateful.
è giusto quello che ho scritto?
non sono stati quindi fatti esempio su FW a livello data link e a livello rete?
grazie
koko [/B]
In sostanza, cmq, e` giusto quello che hai scritto nel senso che hai "visto" la classificazione dei firewall da due punti di vista: 1. livelli ai quale un dato tipo di firewall puo` operare e 2. tipologie di firewall (che operano a livelli differenti).
bye,
Lorenzo |
| citrus |
mm ricapitolando....
a quello che ho capito (e studiato) io ci possono essere sostanzialmente 3 tipi di firewall:
- packet filter che lavorano a livello di rete (ip)
- packet filter che lavorano a livello di trasporto (tcp/udp)
- proxy che filtrano i pacchetti in base al contenuto applicativo (livello applicazione).
per ciascuna delle prime due tipologie poi il firewall può essere stateless o stateful, in quest'ultimo caso il firewall stesso è detto anche dinamico (dynamic packet filter).
Originally posted by sullivan
... Pensa ad esempio ad una regola che faccia passare solo i segmenti TCP con flag SYN (e solo quello) attivato, destinati ad una porta particolare...
così però qualcosa non mi quadra....
permettere il passaggio di pacchetti SYN significa abilitare connessioni tcp in ingresso (cosa che in genere è sconsigliata). se poi addirittura accetti SOLO pacchetti SYN (bloccando quindi gli ACK) significa impedire il completamento delle connessioni intasando così la tabella delle connessioni semi-aperte.
in parole povere questa regola "forzerebbe" attacchi DoS verso la tua macchina.... il che non sembra essere molto simpatico :)
se mi sbaglio correggetemi :P |
| kokorina |
Originally posted by citrus
- packet filter che lavorano a livello di rete (ip)
- packet filter che lavorano a livello di trasporto (tcp/udp)
in realtà da quello che ho capito io il fw packet filter lavora con entrambi i livelli...
- proxy che filtrano i pacchetti in base al contenuto applicativo (livello applicazione).
se a livello applicativo intendi a livello di protocolli applicativi (HTTP, FTP ecc) è corretto, se intendi a livello di processi (es IE) no.
così però qualcosa non mi quadra....
permettere il passaggio di pacchetti SYN significa abilitare connessioni tcp in ingresso (cosa che in genere è sconsigliata). se poi addirittura accetti SOLO pacchetti SYN (bloccando quindi gli ACK) significa impedire il completamento delle connessioni intasando così la tabella delle connessioni semi-aperte.
in parole povere questa regola "forzerebbe" attacchi DoS verso la tua macchina.... il che non sembra essere molto simpatico :)
se mi sbaglio correggetemi :P
Bhe non è detto, se è un fw packet filter stateful stai semplicemente permettendo che un host possa solo fare richieste di aperture di connessioni, ma che non possa mai rispondere ad un'apertura di connessione di qualcun'altro (se la regola implementa il SYN esclusivo e non un eventuale risposta con SYN/ACK)
Quindi in questo caso invece non lo "esponi" ad eventuali attacchi DoS SYN flood.
L'host a cui manda il SYN potrà invece stabilire la connessione in quanto il FW "memorizza" la sessione e non nega le risposte fino a quando la sessione non risulta conclusa.
se sbaglio io, correggetemi :) |
| sullivan |
Ciao,
Originally posted by citrus
così però qualcosa non mi quadra....
permettere il passaggio di pacchetti SYN significa abilitare connessioni tcp in ingresso (cosa che in genere è sconsigliata). se poi addirittura accetti SOLO pacchetti SYN (bloccando quindi gli ACK) significa impedire il completamento delle connessioni intasando così la tabella delle connessioni semi-aperte.
in parole povere questa regola "forzerebbe" attacchi DoS verso la tua macchina.... il che non sembra essere molto simpatico :)
L'intento dell'esempio era quello di evidenziare i livelli dai quali queste informazioni vengono reperite e non definire una regola efficace; cmq, colpa mia in quanto avrei potuto scegliere un esempio piu` significativo o piu` corretto :-)
Comunque, il fatto che il firewall faccia passare segmenti con flag SYN attivato non e` un errore se tali segmenti sono destinati a servizi che devono essere raggiunti (server, dietro firewall, magari in DMZ). Sicuramente, come hai fatto notare, non ha senso avere una regola che, per una data porta (servizio) faccia passare SOLO segmenti con SYN attivato e solo quello e nient'altro, perche` poi non ci sarebbe possibilita` di scambio dati, anzi, neanche di completamento della 3-way handshake (sarebbe completata sulla macchina che e` dietro il firewall [e` un server, per quanto detto fin qui] ma non sulla macchina fuori, quella che ha iniziato il tentativo di connessione).
Come nota riguardo all'accenno di DoS fatto, il kernel di Linux supporta una protezione contro gli attacchi DoS Syn Flood, chiamata TCP Syn Cookies che deve essere abilitata nel kernel (in fase di configurazione) e anche a run time (echo 1 > /proc/sys/net/ipv4/tcp_syncookies).
Anche se l'intento del post precedente era un altro, chiedo venia per l'esempio poco significativo, nella speranza di non aver confuso le idee :-)
bye,
Lorenzo |
| kokorina |
Originally posted by sullivan
Sicuramente, come hai fatto notare, non ha senso avere una regola che, per una data porta (servizio) faccia passare SOLO segmenti con SYN attivato e solo quello e nient'altro, perche` poi non ci sarebbe possibilita` di scambio dati, anzi, neanche di completamento della 3-way handshake (sarebbe completata sulla macchina che e` dietro il firewall [e` un server, per quanto detto fin qui] ma non sulla macchina fuori, quella che ha iniziato il tentativo di connessione).
Perchè??
se è stateful non riesce comunque a concludere il 3-way handshake e lo scambio dati? |
| citrus |
Originally posted by kokorina
in realtà da quello che ho capito io il fw packet filter lavora con entrambi i livelli...
si certo, poi le varie implementazioni dei firewall commerciali lavorano su più livelli contemporaneamente, ma credo sia cmq giusto fare una distinzione...
Originally posted by kokorina
se a livello applicativo intendi a livello di protocolli applicativi (HTTP, FTP ecc) è corretto, se intendi a livello di processi (es IE) no.
stiamo dicendo la stessa cosa....
infatti IE lavora su http,ftp,file ecc....
si tratta sempre del livello applicativo, quale sia poi il processo che gestisce il protocollo al firewall non interessa. :)
Originally posted by kokorina
Bhe non è detto, se è un fw packet filter stateful stai semplicemente permettendo che un host possa solo fare richieste di aperture di connessioni, ma che non possa mai rispondere ad un'apertura di connessione di qualcun'altro (se la regola implementa il SYN esclusivo e non un eventuale risposta con SYN/ACK)
Quindi in questo caso invece non lo "esponi" ad eventuali attacchi DoS SYN flood.
L'host a cui manda il SYN potrà invece stabilire la connessione in quanto il FW "memorizza" la sessione e non nega le risposte fino a quando la sessione non risulta conclusa.
nel caso di firewall stateful non è necessario impostare nessun flag, infatti i filtri dinamici sono in grado di riconoscere e gestire da soli le connessioni (questa è proprio la loro peculiarità).
l'uso dei flag è un "escamotage" per gestire il problema su firewall stateless (ovviamente solo per connessioni tcp).
...
premettendo quindi che la regola sia definita su un firewall semplice rimane cmq sbagliata (a mio parere).
infatti, sia che la regola sia rivolta ai pacchetti in entrata che a quelli in uscita, tu consenti l'inizializzazione di una connessione tcp ma non permetti che questa venga portata a termine.
e questo è il classico comportamento degli attacchi DoS.
la soluzione quindi potrebbe essere:
permettere tutti i pacchetti tcp in uscita (SYN,ACK e FIN) e bloccare solo i pacchetti SYN in entrata.
in questo modo permetti le connessioni verso l'esterno e consenti alla macchina remota di rispondere con dei pacchetti ack.
d'altro canto impedendo i pacchetti SYN in entrata impedisci alle macchine esterne di connettersi alla macchina locale.
dico bene?
:) |
| sullivan |
Ciao,
Originally posted by kokorina
Perchè??
se è stateful non riesce comunque a concludere il 3-way handshake e lo scambio dati?
se e` stateful dipende da come e` configurato. L'esempio "incriminato" non si riferiva ad una regola di firewall stateful (che operasse in modalita` stateful), per come e` stata posta.
Se la regola stateful dice di far passare in ingresso sull'interfaccia esterna del firewall tutti i pacchetti nuovi (tentativi di apertura di connessione), quelli che si scambiano una volta completata la 3-way handshake e anche altri correlati (necessari per alcuni protocolli o in caso di errori) destinati ad una macchina e.g. in DMZ, allora non ci sono problemi.
Ora, quanto appena detto sopra e` un po' diverso da "far passare in ingresso (sull'interfaccia esterna -- mancava :-)) tutti i segmenti TCP verso una porta particolare aventi SYN attivato e SOLO quello" sempre ovviamente nel caso in cui non ci siano altre regole. Quest'ultimo caso non mi sembra tanto stateful e nel caso lo si consideri come tale beh, vanno fatte un po' di assunzioni o perlomeno va esplicitato qualcosa in piu`...
bye,
Lorenzo |
| citrus |
Originally posted by sullivan
Ciao,
L'intento dell'esempio era quello di evidenziare i livelli dai quali queste informazioni vengono reperite e non definire una regola efficace; cmq, colpa mia in quanto avrei potuto scegliere un esempio piu` significativo o piu` corretto :-)
bye,
Lorenzo
come non detto :D
cmq è stato interessante chiarire questi concetti :)
così almeno si fa un po' di ripasso no? :D |
|
|
|
|
