===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 livello di 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 IP 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 esse­re 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.