 |
Menu principale |
 |
|
Cartoline virtuali |
|
Cartolina n° 463
Sono presenti 1307 cartoline virtuali. Entra ora
|
Giochi online |
|
|
News Reader |
|
|
-+-+-+-+-+-+-+-+-+-+H@-+-+-+-+-+-+-+-+-+-+
Tutto il contenuto di questo book è da ritenersi dannoso quindi non applicabile.
L'utente è pregato di non mettere in atto quanto scritto .Esso è solo stato
pubblicato per offrire una conoscenza maggiore in questo ambito ,NON per
altri scopi.Il testo non si puo' modificare ne tanto meno vendere senza
il consenso dell'autore.Se non si rispettano le norme l'utente avrà commesso
azione illegale.
===ooO===0===Ooo===oO Installazione di un Firewall. Oo===ooO===0===Ooo===
Il firewall è ,quasi certamente , lo strumento di sicurezza informatica che
gode di fama maggiore tra le masse.Un altro primato del firewall è quello
di essere ,in assoluto,uno degli strumenti che danno una forte "sensazione
di sicurezza",spesso non giustificata.Per la logica comune ,se un host
ha problemi di sicurezza,installando un firewall si risolve tutto:nulla
di piu' falso.Esistono piu' tipi di firewall,ma tutti,a prescindere dal
tipo,dalla marca e dalla configurazione non sono altro che dei filtri.Spesso
i firewalls sono classificati in due tipi:i proxy ed i packet filtering.
Quello che differenzia queste due tipologie di firewalls è il livello a
cui filtrano:i firewalls proxy filtrano a livello dell'applicazione
mentre i packet filtering filtrano a livello di trasporto e di rete.I packet
filtering sono in assoluto i piu diffusi ,poichè anche se forniscono una
protezione minore,sono estremamente piu'flessibili.L'altra motivazione che
ha decretato il poco successo dei firewalls proxy è il fatto che la tendenza
moderna della sicurezzqa informatica è quella di affidare il compito di
"filtrare" il livello applicativo all'applicazione stessa.Per tutte queste
ragioni questo testo tratta dei packet filtering.Per arricchire la teoria
con qualche applicazione saranno presentati degli esempi utilizzando
"ipchains" e dunque il firewallin del kernel 2.2.x del sistema operativo Linux.
-+-+IL CONCETTO DI REGOLA-+-+
Il firewall è un filtro e quindi ,per poterlo utilizzare bene , è necessario
conoscere perfettamente quello che si intende filtrare.Questa scelta è
fondamentale e determina l'efficacia del firewall.Nel caso dei firewall
proxy ad essere filtrati sono i pacchetti in entrata e quelli in uscita.
Un buon firewall ci dà la possibilita' di decidere la sorte dei pacchetti
in base alle seguenti caratteristiche:
Protocollo IP:
-indirizzo sorgente
-indirizzo di destinazione
-opzioni IP(non sempre purtroppo)
-protocollo
-frammentazione(bit more fragment settato?
Protocollo ICMP:
-tipo ICMP
-codice ICMP
Protocollo UDP/TCP:
-porta sorgente
-porta destinazione
-flags:SYN.ACK ecc. (solo TCP)
Alcuni firewalls,come ad esempio ipfilter (probabilmente il migliore in assoluto),
permettono di filtrare i pacchetti in relazione a tutti i campi dei protocolli
supportati ,anche in base allo " stato" delle connessioni.Anche se ipchains
non raggiunge questo livellodi dettaglio,costituisce un ottimo passo in avanti
nei confronti del vecchio ipfwadm (in effetti ipchains ed ipfwadm sono i nomi
dei programmi utilizzati per settare le regole.Parlando di "ipchains" si fa
riferimento al firewalling del kernel 2.2,mentre "ipfwadm" indica il firewaling
del kernel 2.0)La configurazione di un firewall non è altro che la definizione
delle "regole" che determineranno la sorte del pachetto.Eccovi un esempio di regola:
Blocca tutti i pacchetti TCP uscenti destinati alla porta 80 dell'host
www.microsoft.com
Per inserire questa regola con ipchains dovete eseguire il seguente comando
(da root):
# ipchains -A output -d www.microsoft.com 80 -p TCP -j DENY
Dopo l'inserimento di questo comando ,accederete alle pagine web del sito
www.microsoft.com diverra'impossibile (la porta 80 TCP è proprio la porta
sulla quale è in "ascolto" il demone httpd) .Bloccando tutti i pacchetti
destinati a quella porta,per il vostro host sara'impossibile inoltrare la
richiesta necessaria per visionare le loro pagine web.Vediamo meglio il
comando appena digitato:l'opzione -A d'ipchains indica di "appendere" la
regola alla fine della lista delle regole, output specifica che la regola
si riferisce ai soli pacchetti uscenti mentre l'opzione -d indica l'indirizzo
di destinazione di questi,in altre parole il campo destinazione del protocollo
IP,ed è seguito da "80" ,che nel caso del protocollo TCP indica che la porta
di destinazione è appunto la 80.L'opzione -p indica il protocollo dei pacchetti
,in altre parole il campo "protocol" dell'IP,infine l'opzione -j indica come
comportarsi con quel dato pacchetto ,in questo caso l'operazione richiesta è
"DENY" ,ovvero il pacchetto verra' semplicemente scartato.E' da notare che da
quando per destinazione si utilizza il nome di un host (invece che l'indirizzo
IP) saranno aggiunte tante regole uguali per tutti gli indirizzi in cui tale
nome risolve.Un esempio puo'chiarire meglio il concetto:
$ nslookup www.yahoo.com
Server: dns.tin.it
Address: 194.243.154.62
Non-authoritative answer:
Name: www.yahoo.com
Address: 204.71.200.67, 204.71.200.68, 204.71.200.75, 204.71.200.74
Com'è possibile osservare il nome www.yahoo.com risolve in piu' di un indirizzo IP.
E' per questo che digitare il comando:
$ ipchains -A output -d www.yahoo.com 80 -p TCP -j DENY
Equivale a digitare i seguenti quattro comandi :
# ipchains -A output -d 204.71.200.67 -p TCP -j DENY
# ipchains -A output -d 204.71.200.68 -p TCP -j DENY
# ipchains -A output -d 204.71.200.75 -p TCP -j DENY
# ipchains -A output -d 204.71.200.74 -p TCP -j DENY
La forma con il nome dell'host è preferibile:nel caso gli indirizzi IP di
www.yahoo.com venissero modificati la riga di comando necessaria rimarrebbe
immutata.
Un'alternativa valida puo' essere il seguente comando:
# ipchains -A output -d 204.71.200.0/24 80 -p TCP -j DENY
Che indica ad ipchains di bloccare qualunque pacchetto diretto verso la porta
80 di tutti gli Indirizzi IP the possiedono almeno i 24 bit plu a sinistra
uguali a 204.71.200.0 (ovvero gli indirizzi 204.71.200.0, 204.71.200.1,
204.71.200.255).
CEO equivale a dire che saranno bloccati tutti gli accessi verso la porta
80 di quella 'Classe C' (per informazioni suite classi degli indirizzi I
si consiglia la lettura del NET3-HOWTO).
-+-+LA RELAZIONE TRA LE REGOLE-+-+
Un concetto molto importante è quello della relazione tra le regole. Sì
Supponga un host su Internet, che nasconde una rete locale. Questo host
ê per l'internet un server www, ma per I rete locale è anche un server
ftp. Noi desideriamo che l'accesso a ftp sia garantito Solo dall'interno
ovvero dalla rete locale, mentre dall'esterno dove essere visibile solo
ls httpd. Supponiamo che lo scenario sia quel dl figura.
Come potete vedere PC1, PC2, PC5 sono i client sulla rete locale. Anche
il Server fa parte della rete locale ma ha due interfacce, una con un
indirizzo locale e l'altra con un indirizzo pubblico.
|-------|
| |-------------|
| PC1 | |
|-------| |
|
|-------| |
| | | ______________
| PC2 |-------------| | |
|-------| | | |
| | |
|-------| | | SERVER |
| | | | |
| PC3 |------------------ | |--------------- INTERNET
|-------| | | FIREWALL |
| | |
|-------| | | |
| | | | |
| PC4 |-------------| |_____________|
|-------| |
|
|-------| |
| | |
| PC5 |-------------|
|-------|
ammetta che Ia rete locale Sia 1g2,168.L.O e che l'indirizzo pubblico sia
195.120.28.100. Quello che serve e semplice: si desidera che da internet
sia accessibile solo II web server e che dalla rete locale sta accessibile
anche Il server ftp.
Una soluzione potrebbe essere quella di usare le seguenti regole:
. accetta tutta i pacchetti entranti provenienti dalla rete locale
e diretti verso la porta ftp del server
. blocca tutti i pacchetti entranti destinati alla porta ftp del server
Ovvero:
# ipchains -A input 195.168.2.0/24 -d 195.120.28.110 21 -p TCP -j ACCEPT
# ipchains -A input 195.120.28.100 21 -p TCP -j DENY
Queste due regole permettono di capire In che modo ipchains (e molti altri
firewalls) processa le regole e dunque la relazione né tra le regole stesse.
Quando Un pacchetto arriva II firewalling di linux controlla Se questo
riguarda la prima regola della lista di regole inserite Nel caso in cui
il pacchetto corrispondesse, verrebbe eseguita l'operazione che la regola
specifica (nel nostro caso ACCEPT), altrimenti si passerebbe alla regola
successiva (questo dà l'idea di quanto il firewalling affatichi Ia nostra
CPU, in presenza di molte regole e di elevati traffici) e così via.
E per questo che le due regole sopra riportate funzionano. Immaginate un
pacchetto TCP proveniente dalla rete locale e destinato alla porta 21 del
server. Un tale pacchetto interesserà la prima regola, infatti l'indirizzo
di provenienza rientra in 192.168.1.0/24 e quello di destinazione è proprlo
195.120.28.110, come Ia porta di destinazione è appunto la
21, ovvero quella dell'ftp il kernel eseguira' l'operazione descritta dalla
prima regola : ACCETT il pacchetto sarà accettato e tutte le altre regole
Ignorate. D'altra parte un pacchetto to TCP proveniente da un qualunque
altro indirizzo di Internet C diretto alta porta 21 del nostro server non
soddisfera' Ia prima regola, infatti l'indirizzo sorgente non corrisponderà
(spoofing permettendo, ma è un aftro discorso con 192 168.1.0/24.
II confronto proseguirá prendendo in esame la seconda regola, che dice dl
bloccare qualunque pacchetto destinato alla porta 21 del server. In questo
caso il pacchetto ha tutti i requisiti richiesti e l'operazione DENY sarà
eseguita, cosi il pacchetto verrà scartato.
Le due regole presentate sopra non sono dl certo le migliori:
non danno un grosso margine di sicurezza poiché filtrano solo I pacchetti
diretti alla porta 21. Ammettendo che per un erro re il servizio telnet
non sia stato rimosso dal server, questo continuerà ad essere accessibile
da parte dl Internet. Un insieme di regole piu' "selettive" è il seguente:
. accetta I pacchetti TCP entranti provenienti della rete loca le e
diretti alla porta 21(ftp) e 20(ftp-data) del server
. accetta I pacchetti TCP entranti provenienti da qualunque
destinazione diretti alla 80(web) del server
I blocca tutti I pacchetti TCP entranti dire W alle porte da 0 a 1024
del server (In modo da proteggere tutti gli eventuali altri servizi che
"ascoltano" su una porta privilegiata).
Ovvero:
# ipchains -A input -s 192.168.2.0/24 -d 195.120.28.100 21 -p TCP -j ACCEPT
# ipchains -A input -s 192.168.2.0/24 -d 195.120.28.100 20 -p TCP -j ACCEPT
# ipchains -A input -d 195.120.28.100 80 -p TCP -j ACCEPT
(ri.b. omettendo -s l'indirizzo sorgente viene impostato a 0/0, dunque 18
regola sarà va/Ida per gli ip con Qualunque indirizzo sorgente)
Coadiuvando questi brevi esempi con Ia man page di ipchains sarete capaci
di sfruttare al massimo le potenzialità del firewalling del kernel 22, ed
alla fine riuscirete a filtrare qualunque pacchetto IP, UDP, TCP ed ICMP
(limiti di ipchains permettendo).
-+-+COSA FILTRARE IN UN CONTESTO REALE-+-+
Imparare ad usare bene un determinato firewall cosi da essere In grado di
filtrare In maniera selettiva qualunque tipo di pacchetto non basta (ma è
una condizione necessaria) per garantire il funzionamento ottimale: serve
sapere cosa ti pare. Se pensi al caso specifico di un firewall "orientato"
all'host, ovvero the protegge solo ed esclusivamente 'host su cui e installato;
è II caso semplice poichè I firewalls che proteggono Intere reti sono dl piü
difficile comprensione e mettano Un articolo a parte.
Esistono anche casi molto complessi ed articolati, come le DM2, che saranno
trattate in futuro su queste pagine. Come dicevamo l'esempio riguarda H
classico host su Internet che fisicamente il computer su cut girano I
servizi dl rete ed anche quello su cui gira II firewall stesso.
Immaginiamo che su questo ipotetico host siano presenti sol tanto il
servizIo di ftp anonimo ed il server dns. La scelta dei demoni è importante
almeno quanto il firewalling : In questo caso sarebbe consigliabile
installare un ftp che permette solo l'accesso anonimo, ne esiste uno molto
buono di Marcus j Ranum. Per Il server dns useremo certamente il classico
bind. Le nostre regole dovranno permettere l'accesso da parte dl tutta
Internet verso la porta 20 e 21 del protocollo TCP e versa a porta 53 del
protocollo UDP deII'host.
Ipotizzando che il nostro host non abbia altro scopo oltre quello di far
girare questi due demoni potremmo pensare alla seguenti regole:
La - bloccare in entrata tutti I pacchetti con indirizzo Ip
sorgente 127.0.0.0/8
lb - bloccare in entrata tutti I pacchetti con indirizzo Ip
sorgente uguale al nostro p.
ic - bloccare in entrata tutti I pacchetti con indirizzo Ip
sorgente uguale a 192.168.1.0/24
2a - accettare in entrata I pacchetti TCP verso Ia porta 21
2b - accettare in entrata I pacchetti TCP verso Ia porta 20
2c - bloccare in entrata I pacchetti TCP versa le porte da 0 a
1023
2d o bloccare In entrata i pacchetti TCP con il solo flag SYN
settato verso le porte da 1024 a 65535
3. - accettare in entrata I pacchetti UDP versa a porta 53
3b . bloccare in entrata i pacchetti UDP verso le porte da 0 a
1023
4. - permettere In entrata I pacchetti ICMP di tipo 3, 4 e 11
4b - bloccare In entrata tutU i pacchetti ICMP
4c - permettere in uscita i pacchetti ICMP di tipo 4
4d - bloccare In uscita tutU i pacchetti ICMP
NB. Esaminando queste regole non dimenticate il modo In cui sono processate!
Vediamo di capire il perché di queste regole. Le regole la e lb servono a
prevenire lo spoofing dei pacchetti: non ce alcun motivo di accettare pacchetti
provenienti dall'indirizzo th Ioopb.ck, dal nostro stesso ip a dagli ip della
nostra rete locale (se mai ce ne fosse una). Ricordate che le seguenti regole
devono essere specificate utilizzando l'opzione -i di ipchains specificando
l'Interfaccia con cut siamo connessi ad Internet., infatti, non specificando
I'Interfaccia queste regole avrebbero Iteffetto indesiderato dl non permettere
le con-nessioni originate da quegli ip neppure nel caso fossero legittime.
Le regole 2a e 2b permettono le connessioni verso le porte del servizio ftp,
mentre le regole 2c e 2d bloccano rispettivamente ogni tipo di accesso alle
porte TCP privilegia te (da 0 a 1023) e inizio di una connessione verso le
porte non privilegiate da 1024 a 65535 (SYN flag settato).
Una piccola nota, Ia regola 2d costringerà ad usare I clients
ftp dell'host in passive mode. La regola 3a permette l'accesso al server dns,
mentre Ia regola 3b blocca l'accesso a tutte le porte UDP privilegiate. Le
regole 4a e 4b si occupano di permettere l'accesso ai soli pacchetti ICMP
di tipo destina tlon unreachable, source quench e time exceeded : tran
ne rail casi E utile non filtrare questi pacchetti almeno in entrata.
Infine le regole 4c e 4d permettono in uscita solo gli ICMP di tipo source
quench. Qualcuno potrebbe non essere d'accordo sul l'atto di bloccare il tipo
3 in uscita. In effetti biso gna valutare di volta in volta. Per un host
su cui girano solo ftp e dns mi pare una buona scelta, ed è un modo efficace
per bloccare li scan UDP.
-+-+CONCLUSIONE-+-+
Scegliere adeguate regole di firewalling non è una cosa semplice perché
non è un processo sdiematlco. Ogni caso è diverso dall'altro e si deve
5cegllere un compromesso tra lies eibilità e sicurezza. Non ci sono regole
di firewalling adeguate se chi le implementa non conosce in maniera
approfondita il TCP/IP ed i protocolli del servizi the girano sull'host.
Net caso di flrewalls che proteggono intere reti le cose sono piü complesse.
Solo una attenta valutazione e dei test accurata possono portare ad una
configurazione che aumenta redililente la sicurezza globale delta rete protetta. ~.
|
|
|
|
