| 1 |
scen 11/01/25 22:01:54 |
| 2 |
|
| 3 |
Added: linux-24-stateful-fw-design.xml |
| 4 |
Log: |
| 5 |
Initial commit: version 1.3, revision 1.5 of EN CVS |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.1 xml/htdocs/doc/it/articles/linux-24-stateful-fw-design.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/doc/it/articles/linux-24-stateful-fw-design.xml?rev=1.1&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/doc/it/articles/linux-24-stateful-fw-design.xml?rev=1.1&content-type=text/plain |
| 12 |
|
| 13 |
Index: linux-24-stateful-fw-design.xml |
| 14 |
=================================================================== |
| 15 |
<?xml version='1.0' encoding="UTF-8"?> |
| 16 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 17 |
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/it/articles/linux-24-stateful-fw-design.xml,v 1.1 2011/01/25 22:01:54 scen Exp $ --> |
| 18 |
|
| 19 |
<guide lang="it" disclaimer="articles"> |
| 20 |
<title>Progettazione di un firewall stateful per Linux 2.4</title> |
| 21 |
<author title="Autore"> |
| 22 |
<mail link="drobbins@g.o">Daniel Robbins</mail> |
| 23 |
</author> |
| 24 |
<author title="Traduttore"> |
| 25 |
Alessandro Candini |
| 26 |
</author> |
| 27 |
|
| 28 |
<abstract> |
| 29 |
Questa guida mostra come utilizzare netfilter per configurare un potente |
| 30 |
firewall stateful (cioè a filtraggio dinamico dei pacchetti) per Linux. |
| 31 |
</abstract> |
| 32 |
|
| 33 |
<!-- La versione originale di questo articolo è stata pubblicata da IBM developerWorks |
| 34 |
ed è di proprietà di Westtech Information Services. Questo documento è una versione |
| 35 |
aggiornata dell'articolo originale, e contiene numerosi miglioramenti apportati dal Gentoo |
| 36 |
Linux Documentation team. Questo documento non è mantenuto attivamente. --> |
| 37 |
|
| 38 |
<version>1.3</version> |
| 39 |
<date>2005-10-09</date> |
| 40 |
|
| 41 |
<chapter> |
| 42 |
<title>Riguardo questa guida</title> |
| 43 |
<section> |
| 44 |
<title>Questa guida fa per me?</title> |
| 45 |
<body> |
| 46 |
|
| 47 |
<p> |
| 48 |
Questa guida mostra come utilizzare netfilter per configurare un potente |
| 49 |
firewall stateful per Linux. Quello che serve è un sistema Linux con kernel 2.4: |
| 50 |
un pc portatile, una workstation, un router o un server possono fare tutti al |
| 51 |
caso nostro. |
| 52 |
</p> |
| 53 |
|
| 54 |
<p> |
| 55 |
Dovreste essere abbastanza pratici con la terminologia standard di rete come |
| 56 |
indirizzi IP, numeri di porta per l'invio e la ricezione di dati, TCP, UDP, ICMP |
| 57 |
, ecc. Alla fine della guida, capirete come vengono costruiti i firewall |
| 58 |
stateful per Linux ed avrete diverse configurazioni d'esempio da poter |
| 59 |
utilizzare nei vostri progetti. |
| 60 |
</p> |
| 61 |
|
| 62 |
</body> |
| 63 |
</section> |
| 64 |
<section> |
| 65 |
<title>Riguardo l'autore</title> |
| 66 |
<body> |
| 67 |
|
| 68 |
<p> |
| 69 |
Per domande tecniche sul contenuto di questa guida, contattate l'autore Daniel |
| 70 |
Robbins all'indirizzo email <mail link="drobbins@g.o">drobbins@g.o</mail>. |
| 71 |
</p> |
| 72 |
|
| 73 |
<p> |
| 74 |
Risiedente ad Albuquerque, New Mexico (U.S.A.), Daniel Robbins è stato il |
| 75 |
Presidente/Amministratore Delegato di Gentoo Technologies Inc., nonché il |
| 76 |
creatore di Gentoo Linux, un avanzata versione di Linux per PC, e di Portage, un |
| 77 |
sistema di porting di nuova generazione. Ha inoltre contribuito ai libri |
| 78 |
Macmillan Caldera OpenLinux Unleashed, SuSE Linux Unleashed e Samba Unleashed. |
| 79 |
Daniel si è occupato in qualche modo di informatica fin dalla seconda elementare |
| 80 |
, quando venne avvicinato per la prima volta al linguaggio di programmazione |
| 81 |
Logo e ad una dose di Pac Man potenzialmente dannosa. Probabilmente questo |
| 82 |
spiega perché abbia poi lavorato come Principale Artista Grafico alla SONY |
| 83 |
Electronic Publishing/Psygnosis. A Daniel piace passare il tempo libero con sua |
| 84 |
moglie, Mary, e con la sua nuova bimba, Hadassah. |
| 85 |
</p> |
| 86 |
|
| 87 |
</body> |
| 88 |
</section> |
| 89 |
</chapter> |
| 90 |
|
| 91 |
<chapter> |
| 92 |
<title>Primi passi</title> |
| 93 |
<section> |
| 94 |
<title>Definire l'obiettivo</title> |
| 95 |
<body> |
| 96 |
|
| 97 |
<p> |
| 98 |
In questa guida, costruiremo un firewall stateful per Linux. Il firewall potrà |
| 99 |
funzionare su un pc portatile, una workstation, un server o un router Linux; il |
| 100 |
suo compito principale sarà quello di lasciar passare solo certi tipi di |
| 101 |
traffico di rete. Per incrementare la sicurezza, configureremo il firewall in |
| 102 |
modo che faccia cadere o rifiuti le connessioni alle quali non siamo interessati |
| 103 |
o che possano rappresentare una minaccia. |
| 104 |
</p> |
| 105 |
|
| 106 |
</body> |
| 107 |
</section> |
| 108 |
<section> |
| 109 |
<title>Ottenere gli strumenti</title> |
| 110 |
<body> |
| 111 |
|
| 112 |
<p> |
| 113 |
Prima di cominciare a progettare il firewall, dobbiamo fare due cose. Innanzi |
| 114 |
tutto bisogna essere sicuri che il comando <c>iptables</c> sia disponibile. Da |
| 115 |
root, digitate <c>iptables</c> e guardate se esiste. Se non esiste, allora prima |
| 116 |
bisogna installarlo. Ecco come: |
| 117 |
</p> |
| 118 |
|
| 119 |
<pre caption="Installare gli strumenti necessari"> |
| 120 |
# <i>emerge iptables</i> |
| 121 |
</pre> |
| 122 |
|
| 123 |
</body> |
| 124 |
</section> |
| 125 |
<section> |
| 126 |
<title>Configurazione del Kernel</title> |
| 127 |
<body> |
| 128 |
|
| 129 |
<p> |
| 130 |
Una volta installato, il comando <c>iptables</c> dovrebbe essere pronto all'uso, |
| 131 |
così come la sua pagina di manuale (<c>man iptables</c>). Bene, ora dobbiamo |
| 132 |
essere sicuri di avere le funzionalità necessarie all'interno del kernel. Questa |
| 133 |
guida presuppone che l'utente si compili il proprio kernel. Posizionatevi in |
| 134 |
<path>/usr/src/linux</path> e digitate <c>make menuconfig</c> o <c>make |
| 135 |
xconfig</c>: configureremo nel kernel alcune funzionalità di rete. |
| 136 |
</p> |
| 137 |
|
| 138 |
<p> |
| 139 |
Nella sezione "Networking options", assicuratevi di aver abilitato le seguenti |
| 140 |
opzioni: |
| 141 |
</p> |
| 142 |
|
| 143 |
<pre caption="Opzioni del kernel necessarie"> |
| 144 |
<*> Packet socket |
| 145 |
[*] Network packet filtering (replaces ipchains) |
| 146 |
<*> Unix domain sockets |
| 147 |
[*] TCP/IP networking |
| 148 |
[*] IP: advanced router |
| 149 |
[*] IP: policy routing |
| 150 |
[*] IP: use netfilter MARK value as routing key |
| 151 |
[*] IP: fast network address translation |
| 152 |
[*] IP: use TOS value as routing key |
| 153 |
</pre> |
| 154 |
|
| 155 |
<p> |
| 156 |
In seguito, nel menu "IP: Netfilter Configuration ->" abilitate ogni opzione, |
| 157 |
in modo da attivare tutte le funzionalità di netfilter. Non useremo tutte le sue |
| 158 |
potenzialità, ma è buona cosa abilitarle così da riuscire a fare qualche altro |
| 159 |
esperimento successivamente. |
| 160 |
</p> |
| 161 |
|
| 162 |
<p> |
| 163 |
C'è un'opzione sotto la categoria "Networking options" che <e>non dovete</e> |
| 164 |
abilitare: la notifica esplicita di congestione. Lasciate questa opzione |
| 165 |
disabilitata: |
| 166 |
</p> |
| 167 |
|
| 168 |
<pre caption="Opzione da lasciare disabilitata"> |
| 169 |
[ ] IP: TCP Explicit Congestion Notification support |
| 170 |
</pre> |
| 171 |
|
| 172 |
<p> |
| 173 |
Se questa opzione è abilitata, la vostra macchina Linux non riuscirà ad |
| 174 |
inoltrare le comunicazioni di rete oltre l'8% dell'estensione di Internet. |
| 175 |
Quando l'ECN è abilitato, qualche pacchetto spedito dalla vostra Linux box avrà |
| 176 |
il bit ECN settato; purtroppo, questo bit fa impazzire molti router Internet, |
| 177 |
quindi è molto importante che tale opzione sia disabilitata. |
| 178 |
</p> |
| 179 |
|
| 180 |
<p> |
| 181 |
Ok, adesso che il kernel è configurato correttamente per le nostre esigenze, |
| 182 |
compilatelo, installatelo e riavviate la macchina. E' ora di cominciare a |
| 183 |
giocare con netfilter :) |
| 184 |
</p> |
| 185 |
|
| 186 |
</body> |
| 187 |
</section> |
| 188 |
<section> |
| 189 |
<title>Basi per la progettazione del Firewall</title> |
| 190 |
<body> |
| 191 |
|
| 192 |
<p> |
| 193 |
Nel costruire il firewall, il comando <c>iptables</c> è nostro amico. È ciò che |
| 194 |
usiamo per interagire con le regole di filtraggio dei pacchetti all'interno del |
| 195 |
kernel. Useremo il comando <c>iptables</c> per creare nuove regole, elencare |
| 196 |
quelle esistenti, eliminarle ed impostare le politiche predefinite per la |
| 197 |
gestione dei pacchetti. Questo significa che per creare il firewall, inseriremo |
| 198 |
una serie di comandi iptables; ecco il primo a cui daremo un'occhiata (per |
| 199 |
favore non digitatelo ancora!)... |
| 200 |
</p> |
| 201 |
|
| 202 |
<pre caption="Cambiare la politica della catena a DROP"> |
| 203 |
# <i>iptables -P INPUT DROP</i> |
| 204 |
</pre> |
| 205 |
|
| 206 |
<p> |
| 207 |
State osservando un firewall "quasi" perfetto. Se lanciate questo comando, |
| 208 |
sarete incredibilmente ben protetti contro ogni forma di attacco malevolo |
| 209 |
entrante. Questo perché il comando dice al kernel di eliminare tutti i pacchetti |
| 210 |
entranti. Nonostante questo firewall sia estremamente sicuro, questa |
| 211 |
configurazione è un po' sciocca. Ma prima di andare avanti, diamo un'occhiata |
| 212 |
approfondita a come questo comando fa ciò che fa. |
| 213 |
</p> |
| 214 |
|
| 215 |
</body> |
| 216 |
</section> |
| 217 |
<section> |
| 218 |
<title>Impostare una politica per la catena</title> |
| 219 |
<body> |
| 220 |
|
| 221 |
<p> |
| 222 |
Il comando <c>iptables -P</c> viene usato per impostare la politica predefinita |
| 223 |
per una catena di regole di filtraggio pacchetti. In questo esempio <c>iptables |
| 224 |
-P</c> viene usato per impostare la politica predefinita per la catena INPUT, |
| 225 |
una catena di regole nativa che viene applicata ad ogni pacchetto entrante. |
| 226 |
Impostando la politica predefinita a DROP, diciamo al kernel che ogni pacchetto |
| 227 |
che raggiunge la fine della catena di regole INPUT deve essere lasciato cadere ( |
| 228 |
cioè deve essere scartato). E, poiché non abbiamo aggiunto nessuna altra regola |
| 229 |
alla catena INPUT, tutti i pacchetti raggiungono la sua fine e quindi tutti i |
| 230 |
pacchetti vengono scartati. |
| 231 |
</p> |
| 232 |
|
| 233 |
<p> |
| 234 |
Di nuovo, questo comando da solo è completamente inutile. Però mostra un buon |
| 235 |
approccio alla progettazione del firewall. Cominceremo eliminando tutti i |
| 236 |
pacchetti e poi, gradualmente, apriremo il firewall a seconda delle nostre |
| 237 |
esigenze. Questo ci assicurerà che il firewall sia il più sicuro possibile. |
| 238 |
</p> |
| 239 |
|
| 240 |
</body> |
| 241 |
</section> |
| 242 |
</chapter> |
| 243 |
|
| 244 |
<chapter> |
| 245 |
<title>Definire le regole</title> |
| 246 |
<section> |
| 247 |
<title>Un (piccolo) miglioramento</title> |
| 248 |
<body> |
| 249 |
|
| 250 |
<p> |
| 251 |
Nel nostro esempio, supponiamo di progettare un firewall per una macchina con |
| 252 |
due interfacce di rete, eth0 ed eth1. La scheda di rete eth0 è connessa alla |
| 253 |
nostra LAN, mentre la scheda di rete eth1 è connessa al router DSL, ovvero alla |
| 254 |
connessione ad Internet. In questo caso, possiamo migliorare il nostro "firewall |
| 255 |
estremo" aggiungendo una linea in più: |
| 256 |
</p> |
| 257 |
|
| 258 |
<pre caption="Miglioriamo il nosro firewall estremo"> |
| 259 |
# <i>iptables -P INPUT DROP</i> |
| 260 |
# <i>iptables -A INPUT -i ! eth1 -j ACCEPT</i> |
| 261 |
</pre> |
| 262 |
|
| 263 |
<p> |
| 264 |
La seconda linea <c>iptables -A</c> aggiunge una nuova regola di filtraggio alla |
| 265 |
fine della catena INPUT. Dopo aver aggiunto questa linea, la catena INPUT |
| 266 |
consiste di un'unica regola e di una politica scarta-per-default. Diamo ora |
| 267 |
un'occhiata a cosa fa il nostro firewall semi-completo. |
| 268 |
</p> |
| 269 |
|
| 270 |
</body> |
| 271 |
</section> |
| 272 |
<section> |
| 273 |
<title>Seguire la catena INPUT</title> |
| 274 |
<body> |
| 275 |
|
| 276 |
<p> |
| 277 |
Quando un pacchetto entra da qualsiasi interfaccia (lo, eth0 o eth1), viene |
| 278 |
diretto alla catena INPUT e controllato dal codice di netfilter per vedere se |
| 279 |
rispetta la prima regola. Se la rispetta, il pacchetto viene accettato, e non |
| 280 |
viene eseguito nessun altro processamento. Se non la rispetta, viene applicata |
| 281 |
la politica predefinita della catena INPUT ed il pacchetto viene scartato. |
| 282 |
</p> |
| 283 |
|
| 284 |
<p> |
| 285 |
Questa è l'idea di base. Nello specifico, la prima regola accetta tutti i |
| 286 |
pacchetti provenienti da eth0 e lo, permettendo immediatamente il loro ingresso. |
| 287 |
Ogni pacchetto proveniente da eth1 viene invece scartato. Quindi, se |
| 288 |
abilitassimo questo firewall sulla nostra macchina, essa riuscirebbe ad |
| 289 |
interagire con la LAN, ma sarebbe in pratica disconnessa da Internet. Diamo |
| 290 |
allora un'occhiata ad un paio di modi per abilitare il traffico Internet. |
| 291 |
</p> |
| 292 |
|
| 293 |
</body> |
| 294 |
</section> |
| 295 |
<section> |
| 296 |
<title>Firewall tradizionali</title> |
| 297 |
<body> |
| 298 |
|
| 299 |
<p> |
| 300 |
Ovviamente, affinché il nostro firewall sia utile, dobbiamo permettere a qualche |
| 301 |
pacchetto proveniente da Internet di raggiungere la nostra macchina, dopo averlo |
| 302 |
selezionato. Ci sono due approcci per aprire il nostro firewall in modo che sia |
| 303 |
utile: usando regole statiche oppure usando regole dinamiche, basate sullo stato |
| 304 |
dei pacchetti. |
| 305 |
</p> |
| 306 |
|
| 307 |
<p> |
| 308 |
Come esempio proviamo a scaricare qualche pagina Web. Se vogliamo che la nostra |
| 309 |
macchina riesca a scaricare delle pagine Web da Internet, possiamo aggiungere |
| 310 |
una regola statica che venga sempre rispettata per ogni pacchetto http entrante, |
| 311 |
indipendentemente da dove provenga: |
| 312 |
</p> |
| 313 |
|
| 314 |
<pre caption="Accettare tutti i pacchetti http entranti"> |
| 315 |
# <i>iptables -A INPUT --sport 80 -j ACCEPT</i> |
| 316 |
</pre> |
| 317 |
|
| 318 |
<p> |
| 319 |
Poiché tutto il traffico web standard passa attraverso la porta 80, questa |
| 320 |
regola permette efficacemente alla nostra macchina di scaricare pagine Web. Però |
| 321 |
questo approccio tradizionale, sebbene in alcuni casi accettabile, soffre di |
| 322 |
qualche problema. |
| 323 |
</p> |
| 324 |
|
| 325 |
</body> |
| 326 |
</section> |
| 327 |
<section> |
| 328 |
<title>Scocciature di un firewall tradizionale</title> |
| 329 |
<body> |
| 330 |
|
| 331 |
<p> |
| 332 |
Primo problema: sebbene la maggior parte del traffico web viene originato dalla |
| 333 |
porta 80, una minima parte no. Quindi, sebbene questa regola funzionerebbe quasi |
| 334 |
sempre, ci sarebbero dei rari casi in cui non sarebbe adatta. Ad esempio, magari |
| 335 |
vi é capitato di vedere URL come "http://www.foo.com:81". Un URL come questo |
| 336 |
punta ad un sito Web sulla porta 81 e non sull'80 e risulterebbe invisibile |
| 337 |
dietro al nostro attuale firewall. Tenere in considerazione tutti questi casi |
| 338 |
speciali, può trasformare velocemente un firewall abbastanza sicuro in un |
| 339 |
formaggio svizzero, riempiendo la catena INPUT con un sacco di regole per |
| 340 |
gestire sporadici siti Web stravaganti. |
| 341 |
</p> |
| 342 |
|
| 343 |
<p> |
| 344 |
Ma il maggior problema di questa regola è legato alla sicurezza. E' certamente |
| 345 |
vero che solo al traffico orginato sulla porta 80 verrà permesso di attraversare |
| 346 |
il nostro firewall, ma la porta sorgente di un pacchetto non è qualcosa su cui |
| 347 |
abbiamo il controllo e può essere facilmente alterata da un intruso. Ad esempio, |
| 348 |
se un intruso sapesse come è progettato il nostro firewall, potrebbe scavalcarlo |
| 349 |
assicurandosi semplicemente che tutte le sue connessioni entranti vengano |
| 350 |
originate dalla porta 80 di una delle sue macchine! Poiché questa regola statica |
| 351 |
è così facile da scavalcare, é necessario un più sicuro approccio dinamico. Per |
| 352 |
fortuna, iptables ed il kernel 2.4 forniscono tutto il necessario per definire |
| 353 |
un filtraggio dinamico, basato sullo stato dei pacchetti. |
| 354 |
</p> |
| 355 |
|
| 356 |
</body> |
| 357 |
</section> |
| 358 |
</chapter> |
| 359 |
|
| 360 |
<chapter> |
| 361 |
<title>Firewall stateful</title> |
| 362 |
<section> |
| 363 |
<title>Lo stato: le basi</title> |
| 364 |
<body> |
| 365 |
|
| 366 |
<p> |
| 367 |
Invece di aprire dei buchi nel nostro firewall, sulla base di caratteristiche |
| 368 |
statiche del protocollo, possiamo utilizzare la nuova funzionalità di Linux per |
| 369 |
il tracciamento della connessione in modo che il firewall prenda decisioni |
| 370 |
basate sullo stato dinamico di connessione dei pacchetti.Il tracciamento della |
| 371 |
connessione funziona associando ogni pacchetto ad un canale di comunicazione |
| 372 |
bidirezionale, o connessione. |
| 373 |
</p> |
| 374 |
|
| 375 |
<p> |
| 376 |
Ad esempio, considerate cosa succede se usate telnet o ssh verso una macchina |
| 377 |
remota. Se osservate il traffico di rete a livello di pacchetto, tutto ciò che |
| 378 |
potrete vedere sarà un insieme di pacchetti che sfreccia da una macchina |
| 379 |
all'altra. In realtà, ad un livello più alto, questo scambio di pacchetti è un |
| 380 |
canale di comunicazione bidirezionale tra la vostra macchina e la macchina |
| 381 |
remota. I firewall tradizionali (ormai fuori moda) si limitano ad osservare i |
| 382 |
singoli pacchetti, senza capire che in realtà essi fanno parte di un insieme più |
| 383 |
grande, cioè di una connessione. |
| 384 |
</p> |
| 385 |
|
| 386 |
</body> |
| 387 |
</section> |
| 388 |
<section> |
| 389 |
<title>Dentro al tracciamento della connessione (conntrack)</title> |
| 390 |
<body> |
| 391 |
|
| 392 |
<p> |
| 393 |
Ecco da dove viene la terminologia "tracciamento della connessione". La |
| 394 |
funzionalità conntrack di Linux può "osservare" le connessioni instaurate di più |
| 395 |
alto livello, riconoscendo la connessione ssh come una singola entità logica. |
| 396 |
Conntrack può anche riconoscere gli scambi di pacchetti UDP ed ICMP come |
| 397 |
"connessioni" logiche, sebbene sia UDP che ICMP siano per loro natura |
| 398 |
protocolli senza connessione; questo è di grande aiuto perché ci permette di |
| 399 |
usare conntrack per gestire anche gli scambi di pacchetti UDP ed ICMP. |
| 400 |
</p> |
| 401 |
|
| 402 |
<p> |
| 403 |
Se avete riavviato e state già usando il vostro nuovo kernel con netfilter |
| 404 |
abilitato, potete vedere la lista delle connessioni di rete attive sulla vostra |
| 405 |
macchina digitando <c>cat /proc/net/ip_conntrack</c>. Anche senza aver |
| 406 |
configurato un firewall, la funzionalità conntrack di Linux lavora dietro le |
| 407 |
quinte, tenendo traccia delle connessioni alle quali sta partecipando la vostra |
| 408 |
macchina. |
| 409 |
</p> |
| 410 |
|
| 411 |
</body> |
| 412 |
</section> |
| 413 |
<section> |
| 414 |
<title>Lo stato di connessione NEW</title> |
| 415 |
<body> |
| 416 |
|
| 417 |
<p> |
| 418 |
Conntrack non si limita a riconoscere le connessioni, ma classifica anche ogni |
| 419 |
pacchetto che si trova in uno dei quattro possibili stati di connesione. Il |
| 420 |
primo stato di cui parleremo è lo stato NEW. Quando digitate |
| 421 |
<c>ssh remote.host.com</c>, il pacchetto iniziale o la raffica di pacchetti |
| 422 |
originati dalla vostra macchina e destinati a remote.host.com sono nello stato |
| 423 |
NEW. Tuttavia, appena ricevete anche solo un pacchetto di risposta da |
| 424 |
remote.host.com, ogni ulteriore pacchetto che spedite a remote.host.com come |
| 425 |
parte di questa connessione non è più considerato NEW. Un pacchetto viene quindi |
| 426 |
considerato NEW solamente quando è coinvolto nella creazione di una nuova |
| 427 |
connessione ed ancora non è stato ricevuto nulla dalla macchina remota |
| 428 |
(ovviamente nel contesto di questa connessione). |
| 429 |
</p> |
| 430 |
|
| 431 |
<p> |
| 432 |
Ho descritto pacchetti NEW uscenti, ma è anche possibile (e comune) avere |
| 433 |
pacchetti NEW entranti. I pacchetti NEW entranti vengono originati generalmente |
| 434 |
da una macchina remota, e sono coinvolti nell'instaurazione di una connessione |
| 435 |
sulla vostra macchina. I pacchetti iniziali che il vostro Web server riceve come |
| 436 |
parte di una richiesta HTTP, vengono considerati pacchetti NEW entranti; |
| 437 |
tuttavia, una volta risposto ad anche un solo pacchetto NEW entrante, qualsiasi |
| 438 |
altro pacchetto ricevuto, collegato a questa particolare connessione, non si |
| 439 |
trova più nello stato NEW. |
| 440 |
</p> |
| 441 |
|
| 442 |
</body> |
| 443 |
</section> |
| 444 |
<section> |
| 445 |
<title>Lo stato ESTABLISHED</title> |
| 446 |
<body> |
| 447 |
|
| 448 |
<p> |
| 449 |
Una volta che la connessione ha osservato del traffico in entrambe le direzioni, |
| 450 |
i pacchetti successivi collegati ad essa vengono considerati in stato |
| 451 |
ENSTABLISHED. La distinzione tra NEW ed ENSTABLISHED è molto importante, come |
| 452 |
vedremo tra poco. |
| 453 |
</p> |
| 454 |
|
| 455 |
</body> |
| 456 |
</section> |
| 457 |
<section> |
| 458 |
<title>Lo stato RELATED</title> |
| 459 |
<body> |
| 460 |
|
| 461 |
<p> |
| 462 |
Il terzo stato di connessione è detto RELATED. I pacchetti RELATED sono quelli |
| 463 |
che iniziano una nuova connessione, ma sono in relazione ad un altra connessione |
| 464 |
già esistente. Lo stato RELATED può essere usato per regolare le connessioni che |
| 465 |
sono parte di un protocollo multi-connessione, come ftp, o come pacchetti di |
| 466 |
errore collegati a connessioni esistenti (come i pacchetti di errore ICMP |
| 467 |
collegati ad una connessione esistente). |
| 468 |
</p> |
| 469 |
|
| 470 |
</body> |
| 471 |
</section> |
| 472 |
<section> |
| 473 |
<title>Lo stato INVALID</title> |
| 474 |
<body> |
| 475 |
|
| 476 |
<p> |
| 477 |
Infine, ci sono i pacchetti INVALID: quelli che non possono essere classificati |
| 478 |
in una delle tre categorie descritte sopra. E' importante notare che se un |
| 479 |
pacchetto viene considerato INVALID, non viene automaticamente scartato; sta a |
| 480 |
voi inserire le regole appropriate ed impostare la catena delle politiche in |
| 481 |
modo da gestire correttamente questa situazione. |
| 482 |
</p> |
| 483 |
|
| 484 |
</body> |
| 485 |
</section> |
| 486 |
<section> |
| 487 |
<title>Aggiungere una regola basata sullo stato</title> |
| 488 |
<body> |
| 489 |
|
| 490 |
<p> |
| 491 |
Ok, ora che abbiamo una buona infarinatura del tracciamento di connessione, |
| 492 |
diamo un'occhiata alle singole regole addizionali che trasformano il nostro |
| 493 |
firewall non-funzionale in qualcosa di abbastanza utile: |
| 494 |
</p> |
| 495 |
|
| 496 |
<pre caption="Aggiungere una regola stateful"> |
| 497 |
# <i>iptables -P INPUT DROP</i> |
| 498 |
# <i>iptables -A INPUT -i ! eth1 -j ACCEPT</i> |
| 499 |
# <i>iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT</i> |
| 500 |
</pre> |
| 501 |
|
| 502 |
</body> |
| 503 |
</section> |
| 504 |
<section> |
| 505 |
<title>Come funziona la regola</title> |
| 506 |
<body> |
| 507 |
|
| 508 |
<p> |
| 509 |
Questa sola regola, se inserita alla fine della catena INPUT, ci permetterà di |
| 510 |
stabilire connessioni con macchine remote. Funziona come segue. Diciamo di |
| 511 |
volerci connettere tramite ssh a remote.host.com. Dopo aver digitato <c>ssh |
| 512 |
remote.host.com</c>, la nostra macchina invia un pacchetto all'esterno per |
| 513 |
instaurare la connessione. Questo pacchetto è nello stato NEW ed il firewall |
| 514 |
permette il suo ingresso, poiché stiamo bloccando solo i pacchetti in ingresso, |
| 515 |
non in uscita. |
| 516 |
</p> |
| 517 |
|
| 518 |
<p> |
| 519 |
Quando otteniamo una risposta da remote.host.com, questa viene filtrata dalla |
| 520 |
nostra catena INPUT. Il pacchetto di risposta non soddisfa la prima regola |
| 521 |
(poiché arriva da eth1), quindi si sposta sulla regola successiva, che è anche |
| 522 |
l'ultima. Se la soddisfa, verrà accettato, altrimenti cadrà alla fine della |
| 523 |
catena INPUT e verrà applicata al pacchetto la politica predefinita (DROP). Ma |
| 524 |
quindi, questo pacchetto di risposta entrante viene accettato oppure no? |
| 525 |
</p> |
| 526 |
|
| 527 |
<p> |
| 528 |
Risposta: viene accettato. Quando il kernel esamina questo pacchetto entrante, |
| 529 |
come prima cosa capisce che è parte di una connessione già esistente. |
| 530 |
Successivamente, il kernel deve decidere se questo è un pacchetto NEW o |
| 531 |
ENSTABLISHED. Poiché è un pacchetto entrante, controlla se questa connessione ha |
| 532 |
avuto del traffico uscente, trovandolo: esso consiste infatti nel pacchetto NEW |
| 533 |
spedito precedentemente. Perciò, questo pacchetto entrante viene marcato |
| 534 |
ENSTABLISHED, poiché ci sono stati altri paccheti ricevuti o spediti, associati |
| 535 |
a questa connessione. |
| 536 |
</p> |
| 537 |
|
| 538 |
</body> |
| 539 |
</section> |
| 540 |
<section> |
| 541 |
<title>Pacchetti NEW entranti</title> |
| 542 |
<body> |
| 543 |
|
| 544 |
<p> |
| 545 |
Consideriamo ora cosa succederebbe se qualcuno provasse da una macchina remota |
| 546 |
a connettersi in ssh alla nostra. Il primo pacchetto ricevuto verrebbe |
| 547 |
classificato come NEW e, non soddisfacendo la regola uno, passerebbe alla regola |
| 548 |
due. Poiché questo pacchetto non si trova in stato ENSTABLISHED o RELATED, |
| 549 |
cadrebbe alla fine della catena INPUT dove verrebbe applicata la politica |
| 550 |
predefinita, cioè DROP. La richiesta di connessione ssh entrante verrebbe |
| 551 |
eliminata senza che da noi parta una risposta (o reset TPC) per notificare ciò. |
| 552 |
</p> |
| 553 |
|
| 554 |
</body> |
| 555 |
</section> |
| 556 |
<section> |
| 557 |
<title>Un firewall quasi perfetto</title> |
| 558 |
<body> |
| 559 |
|
| 560 |
<p> |
| 561 |
Dunque, che tipo di firewall abbiamo costruito fino ad ora? Uno ottimo per il |
| 562 |
computer portatile o la workstation per cui non vogliamo nessuna connessione |
| 563 |
entrante dall'esterno, ma che ci permette di conneterci ai siti Internet. |
| 564 |
Riuscirete ad usare Netscape, Konqueror, ftp, ping, a fare ricerche DNS e molto |
| 565 |
altro. Ogni connessione che inizierete, ritornerà indietro attraverso il |
| 566 |
firewall. Però, ogni connessione non richiesta che cercherà di entrare da |
| 567 |
Internet verrà bloccata, a meno che non sia collegata ad una connessione già |
| 568 |
esistente che avete inizializzato voi. Fino a quando non avrete bisogno di |
| 569 |
fornire un servizio di rete all'esterno, questo è un firewall quasi perfetto. |
| 570 |
</p> |
| 571 |
|
| 572 |
</body> |
| 573 |
</section> |
| 574 |
<section> |
| 575 |
<title>Uno script base per il firewall</title> |
| 576 |
<body> |
| 577 |
|
| 578 |
<p> |
| 579 |
Ecco un semplice script che può essere usato per abilitare/disabilitare il |
| 580 |
nostro primo e basilare firewall per workstation: |
| 581 |
</p> |
| 582 |
|
| 583 |
<pre caption="Uno script base per il firewall"> |
| 584 |
#!/bin/bash |
| 585 |
<comment># Un basilare firewall stateful per una workstation o un laptop che non esegue nessun</comment> |
| 586 |
<comment># servizio di rete come un server web, un server SMTP, un server ftp, eccetera.</comment> |
| 587 |
|
| 588 |
if [ "$1" = "start" ] |
| 589 |
then |
| 590 |
echo "Starting firewall..." |
| 591 |
iptables -P INPUT DROP |
| 592 |
iptables -A INPUT -i ! eth1 -j ACCEPT |
| 593 |
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT |
| 594 |
elif [ "$1" = "stop" ] |
| 595 |
then |
| 596 |
echo "Stopping firewall..." |
| 597 |
iptables -F INPUT |
| 598 |
iptables -P INPUT ACCEPT |
| 599 |
fi |
| 600 |
</pre> |
| 601 |
|
| 602 |
</body> |
| 603 |
</section> |
| 604 |
<section> |
| 605 |
<title>Utilizzare lo script</title> |
| 606 |
<body> |
| 607 |
|
| 608 |
<p> |
| 609 |
Utilizzando questo script, potete disattivare il firewall digitando |
| 610 |
<c>./firewall stop</c> e ripristinarlo con <c>./firewall start</c>. Per |
| 611 |
disattivare il firewall, eliminiamo le regole dalla catena INPUT con un |
| 612 |
<c>iptables -F INPUT</c> e risistemiamo poi la politica INPUT predefinita con |
| 613 |
il comando <c>iptables -P INPUT ACCEPT</c>. Diamo ora un'occhiata ai |
| 614 |
miglioramenti che possiamo implementare. Dopo aver spiegato ogni miglioramento, |
| 615 |
illustrerò uno script per il firewall definitivo. Infine, personalizzeremo il |
| 616 |
nostro firewall per i server. |
| 617 |
</p> |
| 618 |
|
| 619 |
</body> |
| 620 |
</section> |
| 621 |
</chapter> |
| 622 |
|
| 623 |
<chapter> |
| 624 |
<title>Miglioramenti stateful</title> |
| 625 |
<section> |
| 626 |
<title>Disattivare esplicitamente l'ECN</title> |
| 627 |
<body> |
| 628 |
|
| 629 |
<p> |
| 630 |
Prima ho detto che è importante disabilitare la notifica esplicita di |
| 631 |
congestione (ECN, Explicit Congestion Notification) in modo che le comunicazioni |
| 632 |
su Internet funzionino correttamente. Nonostante abbiate disabilitato nel kernel |
| 633 |
l'ECN su mio suggerimento, è possibile che in futuro vi dimentichiate di farlo. |
| 634 |
Oppure, potreste passare lo script per il firewall a qualcuno che ha l'ECN |
| 635 |
abilitato. Per questi motivi, è una buona idea usare l'interfaccia |
| 636 |
<path>/proc</path> per disabilitare esplicitamente l'ECN come segue: |
| 637 |
</p> |
| 638 |
|
| 639 |
<pre caption="Disattivare esplicitamente l'ECN"> |
| 640 |
if [ -e /proc/sys/net/ipv4/tcp_ecn ] |
| 641 |
then |
| 642 |
echo 0 > /proc/sys/net/ipv4/tcp_ecn |
| 643 |
fi |
| 644 |
</pre> |
| 645 |
|
| 646 |
</body> |
| 647 |
</section> |
| 648 |
<section> |
| 649 |
<title>Inoltrare</title> |
| 650 |
<body> |
| 651 |
|
| 652 |
<p> |
| 653 |
Se state usando una macchina Linux come router, allora vorrete abilitare |
| 654 |
l'inoltro IP, che permetterà al kernel di accettare il passaggio di pacchetti |
| 655 |
tra eth0 ed eth1 e vice versa. Nel nostro esempio di configurazione, dove eth0 è |
| 656 |
connessa alla LAN ed eth1 è connessa ad Internet, abilitare l'inoltro IP è un |
| 657 |
passo necessario per permettere alla LAN di collegarsi ad Internet attraverso la |
| 658 |
nostra macchina Linux. Per abilitare l'inoltro IP, usate questa linea: |
| 659 |
</p> |
| 660 |
|
| 661 |
<pre caption="Inoltrare"> |
| 662 |
# <i>echo 1 > /proc/sys/net/ipv4/ip_forward</i> |
| 663 |
</pre> |
| 664 |
|
| 665 |
</body> |
| 666 |
</section> |
| 667 |
<section> |
| 668 |
<title>Gestire il rifiuto di connessione</title> |
| 669 |
<body> |
| 670 |
|
| 671 |
<p> |
| 672 |
Fin'ora abbiamo bloccato tutto il traffico non richiesto entrante da Internet. |
| 673 |
Sebbene questo sia un metodo efficace per impedire un'attività di rete non |
| 674 |
voluta, presenta qualche inconveniente. Il problema principale con questo |
| 675 |
approccio è che risulta facile per un intruso capire che stiamo eseguendo un |
| 676 |
firewall, poiché la nostra macchina non risponde con il reset TCP standard e con |
| 677 |
il messaggio ICMP "porta irraggiungibile": queste sono infatti le risposte che |
| 678 |
una macchina normale spedirebbe indietro per notificare un tentativo fallito di |
| 679 |
connessione ad un servizio inesistente. |
| 680 |
</p> |
| 681 |
|
| 682 |
<p> |
| 683 |
Piuttosto che far scoprire a dei potenziali intrusi che stiamo eseguendo un |
| 684 |
firewall (dandogli quindi il suggerimento che magari abbiamo qualche servizio |
| 685 |
prezioso che loro non possono avere), sarebbe meglio far sembrare di non avere |
| 686 |
proprio nessun servizio da offrire. Aggiungendo le due righe seguenti alla fine |
| 687 |
della catena INPUT, raggiungeremo con successo questo obiettivo: |
| 688 |
</p> |
| 689 |
|
| 690 |
<pre caption="Gestire il rifiuto di connessione"> |
| 691 |
# <i>iptables -A INPUT -p tcp -i eth1 -j REJECT --reject-with tcp-reset</i> |
| 692 |
# <i>iptables -A INPUT -p udp -i eth1 -j REJECT --reject-with icmp-port-unreachable</i> |
| 693 |
</pre> |
| 694 |
|
| 695 |
<p> |
| 696 |
La prima regola si occupa di eliminare correttamente le connessioni TCP, mentre |
| 697 |
la seconda gestisce l'UDP. Instaurando queste due regole, diventa molto |
| 698 |
difficile per un intruso capire se stiamo eseguendo un firewall; si spera che |
| 699 |
questo convinca l'intruso ad abbandonare la nostra macchina e a cercare altri |
| 700 |
bersagli più vulnerabili. |
| 701 |
</p> |
| 702 |
|
| 703 |
<p> |
| 704 |
Oltre a rendere il nostro firewall più "invisibile", queste regole eliminano |
| 705 |
anche il ritardo relativo alla connessione di certi server ftp ed irc. Questo |
| 706 |
ritardo è causato dal server stesso, il quale attua una ricerca dell'identità |
| 707 |
sulla vostra macchina (connettendosi alla porta 113), disconnettendosi |
| 708 |
eventualmente dopo circa 15 secondi. Ora, il nostro firewall restituisce un |
| 709 |
reset TCP immediatamente e la ricerca dell'identità cadrà immediatamente |
| 710 |
anch'essa, invece che ritentare per 15 secondi (durante i quali voi starete |
| 711 |
aspettando pazientemente una risposta dal server). |
| 712 |
</p> |
| 713 |
|
| 714 |
</body> |
| 715 |
</section> |
| 716 |
<section> |
| 717 |
<title>Protezione dalla falsificazione della provenienza (spoofing)</title> |
| 718 |
<body> |
| 719 |
|
| 720 |
<p> |
| 721 |
In diverse distribuzioni, quando le interfacce di rete vengono abilitate, |
| 722 |
vengono aggiunte al sistema anche alcune vecchie regole di catene IP. Queste |
| 723 |
speciali regole sono state aggiunte dai creatori della distribuzione per gestire |
| 724 |
un problema chiamato spoofing, nel quale l'indirizzo sorgente all'interno dei |
| 725 |
pacchetti è stato modificato in modo da contenere un valore non valido (un |
| 726 |
qualcosa creato da script spiritosi). Sebbene possiamo creare regole iptables, |
| 727 |
in modo da bloccare anche i pacchetti alterati, c'è un modo più facile. Oggi il |
| 728 |
kernel ha l'abilità integrata di eliminare i pacchetti alterati; tutto quello |
| 729 |
che bisogna fare è abilitarla tramite una semplice interfaccia <c>/proc</c>. |
| 730 |
Ecco come fare: |
| 731 |
</p> |
| 732 |
|
| 733 |
<pre caption="Protezione dallo spoofing"> |
| 734 |
for x in lo eth0 eth1 |
| 735 |
do |
| 736 |
echo 1 > /proc/sys/net/ipv4/conf/${x}/rp_filter |
| 737 |
done |
| 738 |
</pre> |
| 739 |
|
| 740 |
<p> |
| 741 |
Questo script di shell dirà al kernel di eliminare ogni pacchetto con |
| 742 |
provenienza alterata, sulle interfacce lo, eth0 ed eth1. Potete aggiungere |
| 743 |
queste linee al vostro script per il firewall o aggiungerle allo script che |
| 744 |
abilita le interfacce lo, eth0 ed eth1. |
| 745 |
</p> |
| 746 |
|
| 747 |
</body> |
| 748 |
</section> |
| 749 |
<section> |
| 750 |
<title>Mascheramento IP</title> |
| 751 |
<body> |
| 752 |
|
| 753 |
<p> |
| 754 |
Il NAT (Network Address Translation - Traduzione degli Indirizzi di Rete) ed il |
| 755 |
mascheramento IP, sebbene non direttamente collegati ai firewall, vengono spesso |
| 756 |
usati assieme ad essi. Osserveremo ora due comuni configurazioni di NAT e |
| 757 |
mascheramento che potreste aver bisogno di utilizzare. La prima regola si occupa |
| 758 |
di situazioni nelle quali avete un collegamento ad Internet su una linea |
| 759 |
commutata (come ppp0) che usa un IP dinamico: |
| 760 |
</p> |
| 761 |
|
| 762 |
<pre caption="Mascheramento"> |
| 763 |
# <i>iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE</i> |
| 764 |
</pre> |
| 765 |
|
| 766 |
<p> |
| 767 |
Se vi trovate in questa situazione, allora vorrete anche convertire i miei |
| 768 |
script per il firewall in modo che tutti i riferimenti ad eth1 (il nostro router |
| 769 |
DSL d'esempio) vengano cambiati in "ppp0". E va assolutamente bene aggiungere |
| 770 |
regole che si riferiscono ad una interfaccia "ppp0" che ancora non esiste. |
| 771 |
Appena ppp0 verrà abilitata, tutto funzionerà perfettamente. Assicuratevi anche |
| 772 |
di abilitare l'inoltro IP. |
| 773 |
</p> |
| 774 |
|
| 775 |
</body> |
| 776 |
</section> |
| 777 |
<section> |
| 778 |
<title>SNAT</title> |
| 779 |
<body> |
| 780 |
|
| 781 |
<p> |
| 782 |
Se usate la DSL per connettervi ad Internet, probabilmente avrete una di due |
| 783 |
possibili configurazioni. Una possibilità è che il vostro router o modem DSL |
| 784 |
abbia il proprio indirizzo IP e faccia per voi la traduzione degli indirizzi di |
| 785 |
rete. Se siete in questa situazione, non avete bisogno che Linux si occupi del |
| 786 |
NAT poiché lo fa già il router. |
| 787 |
</p> |
| 788 |
|
| 789 |
<p> |
| 790 |
Perciò, se volete avere più controllo sulla funzionalità NAT, dovete mettervi |
| 791 |
d'accordo con il vostro ISP sulla configurazione della vostra connessione DSL in |
| 792 |
modo che il router passi in modalità bridge. In modalità bridge, il vostro |
| 793 |
firewall diventerà ufficialmente parte della rete del vostro ISP ed il router |
| 794 |
inoltrerà trasparentemente il traffico IP avanti ed indietro tra l'ISP e la |
| 795 |
vostra macchina Linux senza far sapere a nessuno della sua esistenza. Esso non |
| 796 |
ha più un indirizzo IP; invece eth1 (nel nostro esempio) sfoggia il suo IP. Se |
| 797 |
qualcuno esegue un ping da Internet verso il vostro indirizzo IP, otterrà una |
| 798 |
risposta dalla vostra macchina Linux, non più dal vostro router. |
| 799 |
</p> |
| 800 |
|
| 801 |
<p> |
| 802 |
Con questo tipo di impostazione, dovreste usare lo SNAT (Source Nat) al posto |
| 803 |
del mascheramento. Ecco la linea da aggiungere al vostro firewall: |
| 804 |
</p> |
| 805 |
|
| 806 |
<pre caption="SNAT"> |
| 807 |
# <i>iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to 1.2.3.4</i> |
| 808 |
</pre> |
| 809 |
|
| 810 |
<p> |
| 811 |
In questo esempio, eth1 deve essere cambiata con l'interfaccia ethernet |
| 812 |
collegata direttamente al router DSL ed 1.2.3.4 con il vostro IP statico (l'IP |
| 813 |
della vostra interfaccia ethernet). Ricordatevi ancora una volta di abilitare |
| 814 |
l'inoltro IP. |
| 815 |
</p> |
| 816 |
|
| 817 |
</body> |
| 818 |
</section> |
| 819 |
<section> |
| 820 |
<title>Problemi con NAT</title> |
| 821 |
<body> |
| 822 |
|
| 823 |
<p> |
| 824 |
Fortunatamente il NAT ed il mascheramento vanno d'accordo con i firewall. Quando |
| 825 |
scrivete le vostre regole di filtraggio, basta che ignoriate il fatto che state |
| 826 |
usando il NAT. Le vostre regole dovrebbero accettare, far cadere o rifiutare i |
| 827 |
pacchetti basandosi sui loro "reali" indirizzi di sorgente e destinazione. Il |
| 828 |
codice di filtraggio del firewall vede l'indirizzo sorgente di un pacchetto e |
| 829 |
l'indirizzo di destinazione finale. Questo è ottimale, perché permette al nostro |
| 830 |
firewall di continuare a funzionare correttamente anche se disabilitiamo |
| 831 |
temporaneamente il NAT o il mascheramento. |
| 832 |
</p> |
| 833 |
|
| 834 |
</body> |
| 835 |
</section> |
| 836 |
<section> |
| 837 |
<title>Capire le tabelle</title> |
| 838 |
<body> |
| 839 |
|
| 840 |
<p> |
| 841 |
Negli esempi precedenti su NAT/mascheramento, abbiamo aggiunto regole ad una |
| 842 |
catena, ma abbiamo anche fatto qualcosa di leggermente diverso. Notate l'opzione |
| 843 |
"-t". Essa ci permette di specificare la tabella alla quale appartiene la nostra |
| 844 |
catena. Se omessa, la tabella predefinita si chiama "filter". Quindi, tutti i |
| 845 |
precedenti comandi non collegati al NAT, stavano modificando la catena INPUT che |
| 846 |
è parte della tabella "filter". La tabella "filter" contiene tutte le regole |
| 847 |
associate ai pacchetti accettati o rifiutati, mentre la tabella "nat" (come |
| 848 |
potete immaginare) contiene le regole connesse alla traduzione degli indirizzi |
| 849 |
di rete. Ci sono anche altre catene iptables predefinite, che sono descritte in |
| 850 |
dettaglio nella pagina di manuale di iptables e nelle guide di Rusty (guardate |
| 851 |
il collegamento nella sezione <uri link="#resources">Risorse</uri> alla fine di |
| 852 |
questa guida). |
| 853 |
</p> |
| 854 |
|
| 855 |
</body> |
| 856 |
</section> |
| 857 |
<section> |
| 858 |
<title>Il nostro script migliorato</title> |
| 859 |
<body> |
| 860 |
|
| 861 |
<p> |
| 862 |
Ora che abbiamo scorso una lista di possibili miglioramenti, diamo un'occhiata |
| 863 |
ad uno script più flessibile per accendere/spegnere il firewall: |
| 864 |
</p> |
| 865 |
|
| 866 |
<pre caption="Il nostro script migliorato"> |
| 867 |
#!/bin/bash |
| 868 |
|
| 869 |
<comment># Un firewall stateful migliorato per una workstation, un computer portatile o un</comment> |
| 870 |
<comment># router che non esegue nessun servizio di rete come server web, SMTP, ftp, eccetera.</comment> |
| 871 |
|
| 872 |
<comment># Cambiate questa variabile col nome dell'interfaccia che vi fornisce l'"uplink"</comment> |
| 873 |
<comment># (cioè la connessione ad Internet)</comment> |
| 874 |
|
| 875 |
UPLINK="eth1" |
| 876 |
|
| 877 |
<comment># Se dovete configurare un router (e quindi volete inoltrare i pacchetti IP tra le</comment> |
| 878 |
<comment># interfacce), impostate ROUTER="yes"; altrimenti ROUTER="no"</comment> |
| 879 |
|
| 880 |
ROUTER="yes" |
| 881 |
|
| 882 |
<comment># Modificate la linea seguente con l'IP statico della vostra interfaccia collegata</comment> |
| 883 |
<comment># ad Internet per lo SNAT statico o con "dynamic" se avete un IP dinamico. Se non avete</comment> |
| 884 |
<comment># bisogno del NAT, impostate "" in modo da disabilitarlo.</comment> |
| 885 |
|
| 886 |
NAT="1.2.3.4" |
| 887 |
|
| 888 |
<comment># Modificate la linea seguente in modo da listare tutte le vostre interfacce di rete, lo compresa</comment> |
| 889 |
|
| 890 |
INTERFACES="lo eth0 eth1" |
| 891 |
|
| 892 |
if [ "$1" = "start" ] |
| 893 |
then |
| 894 |
echo "Starting firewall..." |
| 895 |
iptables -P INPUT DROP |
| 896 |
iptables -A INPUT -i ! ${UPLINK} -j ACCEPT |
| 897 |
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT |
| 898 |
iptables -A INPUT -p tcp -i ${UPLINK} -j REJECT --reject-with tcp-reset |
| 899 |
iptables -A INPUT -p udp -i ${UPLINK} -j REJECT --reject-with icmp-port-unreachable |
| 900 |
|
| 901 |
<comment># Disabilitate esplicitamente l'ECN</comment> |
| 902 |
if [ -e /proc/sys/net/ipv4/tcp_ecn ] |
| 903 |
then |
| 904 |
echo 0 > /proc/sys/net/ipv4/tcp_ecn |
| 905 |
fi |
| 906 |
|
| 907 |
<comment># Disabilitate lo spoofing su tutte le interfacce</comment> |
| 908 |
for x in ${INTERFACES} |
| 909 |
do |
| 910 |
echo 1 > /proc/sys/net/ipv4/conf/${x}/rp_filter |
| 911 |
done |
| 912 |
|
| 913 |
if [ "$ROUTER" = "yes" ] |
| 914 |
then |
| 915 |
<comment># Avendo un router di qualsiasi tipo, abilitate l'inoltro IP</comment> |
| 916 |
echo 1 > /proc/sys/net/ipv4/ip_forward |
| 917 |
if [ "$NAT" = "dynamic" ] |
| 918 |
then |
| 919 |
<comment># Indirizzo IP dinamico, utilizzate il mascheramento</comment> |
| 920 |
echo "Enabling masquerading (dynamic ip)..." |
| 921 |
iptables -t nat -A POSTROUTING -o ${UPLINK} -j MASQUERADE |
| 922 |
elif [ "$NAT" != "" ] |
| 923 |
then |
| 924 |
<comment># Indirizzo IP statico, usate SNAT</comment> |
| 925 |
echo "Enabling SNAT (static ip)..." |
| 926 |
iptables -t nat -A POSTROUTING -o ${UPLINK} -j SNAT --to ${UPIP} |
| 927 |
fi |
| 928 |
fi |
| 929 |
|
| 930 |
elif [ "$1" = "stop" ] |
| 931 |
then |
| 932 |
echo "Stopping firewall..." |
| 933 |
iptables -F INPUT |
| 934 |
iptables -P INPUT ACCEPT |
| 935 |
<comment># Disabilitate il NAT/mascheramento, se sono abilitati</comment> |
| 936 |
iptables -t nat -F POSTROUTING |
| 937 |
fi |
| 938 |
</pre> |
| 939 |
|
| 940 |
</body> |
| 941 |
</section> |
| 942 |
</chapter> |
| 943 |
|
| 944 |
<chapter> |
| 945 |
<title>Server stateful</title> |
| 946 |
<section> |
| 947 |
<title>Vedere le regole</title> |
| 948 |
<body> |
| 949 |
|
| 950 |
<p> |
| 951 |
Prima di cominciare a personalizzare il firewall in modo che possa essere usato |
| 952 |
su un server, bisogna che vi mostri come listare le sue regole attive. Per |
| 953 |
visualizzare le regole nella tabella filter della catena INPUT, digitate: |
| 954 |
</p> |
| 955 |
|
| 956 |
<pre caption="Vedere le regole"> |
| 957 |
# <i>iptables -v -L INPUT</i> |
| 958 |
</pre> |
| 959 |
|
| 960 |
<p> |
| 961 |
L'opzione -v ci da un output verboso, in modo da poter vedere i pacchetti ed i |
| 962 |
bytes totali trasferiti per ogni regola. Possiamo guardare anche alla tabella |
| 963 |
nat POSTROUTING con il seguente comando: |
| 964 |
</p> |
| 965 |
|
| 966 |
<pre caption="Vedere le regole della tabella POSTROUTING"> |
| 967 |
# <i>iptables -t nat -v -L POSTROUTING</i> |
| 968 |
Chain POSTROUTING (policy ACCEPT 399 packets, 48418 bytes) |
| 969 |
pkts bytes target prot opt in out source destination |
| 970 |
2728 170K SNAT all -- any eth1 anywhere anywhere |
| 971 |
to:215.218.215.2 |
| 972 |
</pre> |
| 973 |
|
| 974 |
</body> |
| 975 |
</section> |
| 976 |
<section> |
| 977 |
<title>Pronti per il servizio</title> |
| 978 |
<body> |
| 979 |
|
| 980 |
<p> |
| 981 |
Fino qui, il nostro firewall non permette a chiunque di collegarsi a dei servizi |
| 982 |
sulla nostra macchina, poiché accetta solamente pachetti entranti ENSTABLISHED o |
| 983 |
RELATED. Poiché esso elimina ogni pacchetto NEW entrante, qualsiasi tentativo di |
| 984 |
connessione viene rifiutato incondizionatamente. Però, permettendo |
| 985 |
selettivamente a del traffico entrante di oltrepassare il firewall, possiamo |
| 986 |
permettere ad un utente generico di collegarsi a dei nostri servizi specifici. |
| 987 |
</p> |
| 988 |
|
| 989 |
</body> |
| 990 |
</section> |
| 991 |
<section> |
| 992 |
<title>HTTP stateful</title> |
| 993 |
<body> |
| 994 |
|
| 995 |
<p> |
| 996 |
Nonostante ci possa andare bene accettare qualche connessione entrante, |
| 997 |
probabilmente non vorremmo accettarle tutte. Ha senso cominciare con una |
| 998 |
politica di "divieto automatico" (come quella che abbiamo ora) e cominciare a |
| 999 |
permettere l'accesso a quei servizi che vorremmo rendere disponibili. Ad esempio |
| 1000 |
se stiamo eseguendo un server web, permetteremo l'ingresso di pacchetti NEW |
| 1001 |
sulla nostra macchina, se hanno nell'intestazione il riferimento alla porta 80 |
| 1002 |
(HTTP). Questo è tutto ciò che bisogna fare; una volta che abbiamo permesso |
| 1003 |
l'ingresso ai pacchetti NEW, abbiamo dato il permesso di stabilire una |
| 1004 |
connessione. Quando viene stabilita una connessione, entrano in azione le regole |
| 1005 |
per l'ingresso dei pacchetti ESTABLISHED e RELATED, permettendo liberamente la |
| 1006 |
connessione HTTP. |
| 1007 |
</p> |
| 1008 |
|
| 1009 |
</body> |
| 1010 |
</section> |
| 1011 |
<section> |
| 1012 |
<title>Esempio di HTTP stateful</title> |
| 1013 |
<body> |
| 1014 |
|
| 1015 |
<p> |
| 1016 |
Diamo un'occhiata al "cuore" del nostro firewall ed alle nuove regole che |
| 1017 |
permettono le connessioni HTTP entranti: |
| 1018 |
</p> |
| 1019 |
|
| 1020 |
<pre caption="Esempio di HTTP stateful"> |
| 1021 |
iptables -P INPUT DROP |
| 1022 |
iptables -A INPUT -i ! ${UPLINK} -j ACCEPT |
| 1023 |
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT |
| 1024 |
<comment># Seguono le nostre nuove regole</comment> |
| 1025 |
iptables -A INPUT -p tcp --dport http -m state --state NEW -j ACCEPT |
| 1026 |
iptables -A INPUT -p tcp -i ${UPLINK} -j REJECT --reject-with tcp-reset |
| 1027 |
iptables -A INPUT -p udp -i ${UPLINK} -j REJECT --reject-with |
| 1028 |
icmp-port-unreachable |
| 1029 |
</pre> |
| 1030 |
|
| 1031 |
<p> |
| 1032 |
Questa nuova regola permette l'ingresso ai pacchetti TCP NEW destinati alla |
| 1033 |
porta 80 (HTTP) della nostra macchina. Notate la sua posizione. E' importante |
| 1034 |
che si trovi prima dele regole di REJECT. Poiché iptables applicherà la prima |
| 1035 |
regola rispettata, posizionarla dopo le linee di REJECT avrebbe come effetto la |
| 1036 |
non esecuzione della regola stessa. |
| 1037 |
</p> |
| 1038 |
|
| 1039 |
</body> |
| 1040 |
</section> |
| 1041 |
<section> |
| 1042 |
<title>Il nostro script finale per il firewall</title> |
| 1043 |
<body> |
| 1044 |
|
| 1045 |
<p> |
| 1046 |
Diamo ora un'occhiata allo script finale per il firewall, il quale può essere |
| 1047 |
usato su un computer portatile, una workstation, un router o un server (o una |
| 1048 |
combinazione di questi!) |
| 1049 |
</p> |
| 1050 |
|
| 1051 |
<pre caption="Lo script finale per il firewall"> |
| 1052 |
#!/bin/bash |
| 1053 |
|
| 1054 |
<comment># Il nostro script completo per il firewall. Questo firewall può essere configurato</comment> |
| 1055 |
<comment># per un computer portatile, una workstation, un router o anche un server. :)</comment> |
| 1056 |
|
| 1057 |
<comment># Cambiate questa variabile col nome dell'interfaccia che vi fornisce l'"uplink"</comment> |
| 1058 |
<comment># (cioè la connessione ad Internet)</comment> |
| 1059 |
|
| 1060 |
UPLINK="eth1" |
| 1061 |
|
| 1062 |
<comment># Se dovete configurare un router (e quindi volete inoltrare i pacchetti IP tra le</comment> |
| 1063 |
<comment># interfacce), impostate ROUTER="yes"; altrimenti ROUTER="no"</comment> |
| 1064 |
|
| 1065 |
ROUTER="yes" |
| 1066 |
|
| 1067 |
<comment># Modificate la linea seguente con l'IP statico della vostra interfaccia collegata</comment> |
| 1068 |
<comment># ad Internet per lo SNAT statico o con "dynamic" se avete un IP dinamico. Se non avete</comment> |
| 1069 |
<comment># bisogno del NAT, impostate "" in modo da disabilitarlo.</comment> |
| 1070 |
|
| 1071 |
NAT="1.2.3.4" |
| 1072 |
|
| 1073 |
<comment># Modificate la linea seguente in modo da listare tutte le vostre interfacce di rete, lo compresa</comment> |
| 1074 |
|
| 1075 |
INTERFACES="lo eth0 eth1" |
| 1076 |
|
| 1077 |
<comment># Modificate la seguente linea in modo che vengano listati i numeri assegnati o i</comment> |
| 1078 |
<comment># nomi simbolici (da /etc/services) di tutti i servizi che vorreste fornire ad un'utenza</comment> |
| 1079 |
<comment># generica. Se non volete attivo nessun servizio, impostatela a ""</comment> |
| 1080 |
|
| 1081 |
SERVICES="http ftp smtp ssh rsync" |
| 1082 |
|
| 1083 |
if [ "$1" = "start" ] |
| 1084 |
then |
| 1085 |
echo "Starting firewall..." |
| 1086 |
iptables -P INPUT DROP |
| 1087 |
iptables -A INPUT -i ! ${UPLINK} -j ACCEPT |
| 1088 |
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT |
| 1089 |
|
| 1090 |
<comment># Abilitate un accesso pubblico a certi servizi</comment> |
| 1091 |
for x in ${SERVICES} |
| 1092 |
do |
| 1093 |
iptables -A INPUT -p tcp --dport ${x} -m state --state NEW -j ACCEPT |
| 1094 |
done |
| 1095 |
|
| 1096 |
iptables -A INPUT -p tcp -i ${UPLINK} -j REJECT --reject-with tcp-reset |
| 1097 |
iptables -A INPUT -p udp -i ${UPLINK} -j REJECT --reject-with icmp-port-unreachable |
| 1098 |
|
| 1099 |
<comment># Disabilitate esplicitamente l'ECN</comment> |
| 1100 |
if [ -e /proc/sys/net/ipv4/tcp_ecn ] |
| 1101 |
then |
| 1102 |
echo 0 > /proc/sys/net/ipv4/tcp_ecn |
| 1103 |
fi |
| 1104 |
|
| 1105 |
<comment># Disabilitate lo spoofing su tutte le interfacce</comment> |
| 1106 |
for x in ${INTERFACES} |
| 1107 |
do |
| 1108 |
echo 1 > /proc/sys/net/ipv4/conf/${x}/rp_filter |
| 1109 |
done |
| 1110 |
|
| 1111 |
if [ "$ROUTER" = "yes" ] |
| 1112 |
then |
| 1113 |
<comment># Avendo un router qualsiasi, abilitate l'inoltro IP</comment> |
| 1114 |
echo 1 > /proc/sys/net/ipv4/ip_forward |
| 1115 |
if [ "$NAT" = "dynamic" ] |
| 1116 |
then |
| 1117 |
<comment># Indirizzo IP dinamico, utilizzate il mascheramento</comment> |
| 1118 |
echo "Enabling masquerading (dynamic ip)..." |
| 1119 |
iptables -t nat -A POSTROUTING -o ${UPLINK} -j MASQUERADE |
| 1120 |
elif [ "$NAT" != "" ] |
| 1121 |
then |
| 1122 |
<comment># Indirizzo IP statico, usate SNAT</comment> |
| 1123 |
echo "Enabling SNAT (static ip)..." |
| 1124 |
iptables -t nat -A POSTROUTING -o ${UPLINK} -j SNAT --to ${UPIP} |
| 1125 |
fi |
| 1126 |
fi |
| 1127 |
|
| 1128 |
elif [ "$1" = "stop" ] |
| 1129 |
then |
| 1130 |
echo "Stopping firewall..." |
| 1131 |
iptables -F INPUT |
| 1132 |
iptables -P INPUT ACCEPT |
| 1133 |
<comment># Disabilitate il NAT/mascheramento, se sono abilitati</comment> |
| 1134 |
iptables -t nat -F POSTROUTING |
| 1135 |
fi |
| 1136 |
</pre> |
| 1137 |
|
| 1138 |
</body> |
| 1139 |
</section> |
| 1140 |
</chapter> |
| 1141 |
|
| 1142 |
<chapter> |
| 1143 |
<title>Costruire un migliore firewall per server</title> |
| 1144 |
<section> |
| 1145 |
<title>Miglioramenti al server</title> |
| 1146 |
<body> |
| 1147 |
|
| 1148 |
<p> |
| 1149 |
E' sempre possibile rendere un firewall un po' "migliore". Ovviamente, il |
| 1150 |
significato di "migliore" varia a seconda delle nostre necessità. Lo script che |
| 1151 |
abbiamo prodotto potrebbe soddisfare perfettamente le vostre, o magari avrete |
| 1152 |
bisogno di fare qualche aggiustamento. Questa sezione ha lo scopo di essere una |
| 1153 |
fonte di idee, mostrando modi di migliorare il vostro firewall stateful. |
| 1154 |
</p> |
| 1155 |
|
| 1156 |
</body> |
| 1157 |
</section> |
| 1158 |
<section> |
| 1159 |
<title>Tecniche di logging</title> |
| 1160 |
<body> |
| 1161 |
|
| 1162 |
<p> |
| 1163 |
Fino ad ora non abbiamo discusso di logging, ovvero della registrazione |
| 1164 |
cronologica delle operazioni man mano che vengono eseguite. C'è una speciale |
| 1165 |
opzione chiamata LOG che vi permette di gestirlo. Assieme a LOG, c'è un'altra |
| 1166 |
opzione chiamata <c>--log-prefix</c> che vi permette di specificare del testo |
| 1167 |
che apparirà nei log di sistema al passaggio di un pacchetto. Ecco un esempio di |
| 1168 |
regola di log: |
| 1169 |
</p> |
| 1170 |
|
| 1171 |
<pre caption="Regola di log di esempio"> |
| 1172 |
# <i> iptables -A INPUT -j LOG --log-prefix "bad input:"</i> |
| 1173 |
</pre> |
| 1174 |
|
| 1175 |
<p> |
| 1176 |
Questa linea non dovrà essere aggiunta come prima regola della catena INPUT, |
| 1177 |
altrimenti causerà il salvataggio di una riga di log per ogni pacchetto |
| 1178 |
ricevuto! Aggiungetela invece più in basso nella catena INPUT, con lo scopo di |
| 1179 |
registrare solo pacchetti strani ed altre anomalie. |
| 1180 |
</p> |
| 1181 |
|
| 1182 |
<p> |
| 1183 |
Ecco una nota importante per l'opzione LOG. Normalmente, quando una regola viene |
| 1184 |
soddisfatta, il pacchetto in oggetto può essere accettato, rifiutato o lasciato |
| 1185 |
cadere, senza che altre regole vengano analizzate. Però, quando viene |
| 1186 |
soddisfatta una regola di log, il pacchetto viene registrato. Esso non viene |
| 1187 |
accettato, rifiutato o lasciato cadere, ma prosegue verso la regola successiva, |
| 1188 |
oppure viene applicata la politica predefinita se la regola di log é l'ultima |
| 1189 |
della catena. |
| 1190 |
</p> |
| 1191 |
|
| 1192 |
<p> |
| 1193 |
L'opzione LOG può essere anche combinata con il modulo "limit" (descritto nel |
| 1194 |
manuale di iptables), per minimizzare le righe di log duplicate. Ecco un |
| 1195 |
esempio: |
| 1196 |
</p> |
| 1197 |
|
| 1198 |
<pre caption="Limitare le scritture nei log"> |
| 1199 |
# <i>iptables -A INPUT -m state --state INVALID -m limit --limit 5/minute -j LOG --log-prefix "INVALID STATE:"</i> |
| 1200 |
</pre> |
| 1201 |
|
| 1202 |
</body> |
| 1203 |
</section> |
| 1204 |
<section> |
| 1205 |
<title>Creare le vostre catene</title> |
| 1206 |
<body> |
| 1207 |
|
| 1208 |
<p> |
| 1209 |
<c>iptables</c> vi permette di creare delle catene personalizzate che possono |
| 1210 |
essere specificate nelle vostre regole. Se volete imparare come fare ciò, |
| 1211 |
spendete un po' di tempo col manuale di filtraggio pacchetti sulla home page del |
| 1212 |
progetto netfilter/iptables (<uri>http://www.netfilter.org/</uri>). |
| 1213 |
</p> |
| 1214 |
|
| 1215 |
</body> |
| 1216 |
</section> |
| 1217 |
<section> |
| 1218 |
<title>Far rispettare le politiche di utilizzo della rete</title> |
| 1219 |
<body> |
| 1220 |
|
| 1221 |
<p> |
| 1222 |
I firewall sono strumenti molto potenti per chi vuole rinforzare le politiche di |
| 1223 |
utilizzo della rete su una LAN aziendale o accademica. Potete controllare quali |
| 1224 |
pacchetti inoltrare dalla vostra macchina aggiungendo regole ed impostando le |
| 1225 |
politiche nella catena FORWARD. Aggiungendo regole alla catena OUTPUT potete |
| 1226 |
anche controllare cosa succede ai pacchetti che vengono generati localmente, |
| 1227 |
dagli utenti della macchina Linux stessa. iptables ha inoltre l'incredibile |
| 1228 |
capacità di filtrare i pacchetti creati localmente, basandosi sul proprietario |
| 1229 |
(tramite uid o gid). Per maggiori informazioni, cercate "owner" (proprietario) |
| 1230 |
nella pagina di manuale di iptables. |
| 1231 |
</p> |
| 1232 |
|
| 1233 |
</body> |
| 1234 |
</section> |
| 1235 |
<section> |
| 1236 |
<title>Altri aspetti di sicurezza</title> |
| 1237 |
<body> |
| 1238 |
|
| 1239 |
<p> |
| 1240 |
Nel nostro firewall d'esempio abbiamo assunto che tutto il traffico interno alla |
| 1241 |
LAN fosse affidabile e che dovesse essere controllato attentamente solo il |
| 1242 |
traffico proveniente da Internet. A seconda della vostra rete, questa |
| 1243 |
configurazione può fare al caso vostro o meno. Non c'è nulla che vi impedisca di |
| 1244 |
configurare il firewall in modo da proteggervi anche dal traffico entrante della |
| 1245 |
vostra LAN. Considerate altre "zone" della vostra rete che magari vorreste |
| 1246 |
proteggere. Potrebbe anche essere appropriato configurare 2 separate "zone" di |
| 1247 |
sicurezza all'interno della LAN, ognuna con le proprie politiche di sicurezza. |
| 1248 |
</p> |
| 1249 |
|
| 1250 |
</body> |
| 1251 |
</section> |
| 1252 |
</chapter> |
| 1253 |
|
| 1254 |
<chapter id="resources"> |
| 1255 |
<title>Risorse</title> |
| 1256 |
<section> |
| 1257 |
<title>tcpdump</title> |
| 1258 |
<body> |
| 1259 |
|
| 1260 |
<p> |
| 1261 |
In questa sezione, indicherò un po' di risorse che troverete utili per costruire |
| 1262 |
il vostro firewall stateful personale. Cominciamo con uno strumento molto |
| 1263 |
importante... |
| 1264 |
</p> |
| 1265 |
|
| 1266 |
<p> |
| 1267 |
<uri link="http://www.tcpdump.org/">tcpdump</uri> è uno strumento essenziale per |
| 1268 |
esplorare scambi di pacchetti ad un basso livello e verificare che il vostro |
| 1269 |
firewall stia funzionando correttamente. Se non ce l'avete, installatelo. Se ce |
| 1270 |
l'avete, incominciate ad usarlo. |
| 1271 |
</p> |
| 1272 |
|
| 1273 |
</body> |
| 1274 |
</section> |
| 1275 |
<section> |
| 1276 |
<title>netfilter.kernelnotes.org</title> |
| 1277 |
<body> |
| 1278 |
|
| 1279 |
<p> |
| 1280 |
Visitate la pagina del progetto iptables/netfilter |
| 1281 |
(<uri>http://www.netfilter.org/</uri>). Su questo sito troverete un sacco di |
| 1282 |
suggerimenti, il codice sorgente di iptables e |
| 1283 |
<uri link="http://www.netfilter.org/documentation/index.html#documentation-faq"> |
| 1284 |
le FAQ di netfilter</uri>. Anche <uri |
| 1285 |
link="http://people.netfilter.org/~rusty/unreliable-guides/index.html">le |
| 1286 |
Eccellenti Guide di Rusty</uri> sono ottime, ed includono un manuale sui |
| 1287 |
concetti basilari delle architetture di rete, uno su netfilter (iptables), uno |
| 1288 |
sul NAT ed anche un manuale approfondito su netfilter destinato agli |
| 1289 |
sviluppatori. |
| 1290 |
</p> |
| 1291 |
|
| 1292 |
</body> |
| 1293 |
</section> |
| 1294 |
<section> |
| 1295 |
<title>Pagine di manuale di iptables</title> |
| 1296 |
<body> |
| 1297 |
|
| 1298 |
<p> |
| 1299 |
Per fortuna su Internet ci sono un sacco di buone risorse per netfilter; |
| 1300 |
comunque, non dimenticatevi delle basi. La pagina di manuale di iptables è molto |
| 1301 |
dettagliata ed è un brillante esempio di come una pagina di manuale dovrebbe |
| 1302 |
essere. In realtà è anche una lettura piacevole. |
| 1303 |
</p> |
| 1304 |
|
| 1305 |
</body> |
| 1306 |
</section> |
| 1307 |
<section> |
| 1308 |
<title>Manuale avanzato sull'instradamento (routing) ed il controllo del |
| 1309 |
traffico su Linux</title> |
| 1310 |
<body> |
| 1311 |
|
| 1312 |
<p> |
| 1313 |
E' ora disponibile un <uri link="http://www.ds9a.nl/2.4Routing/">manuale |
| 1314 |
avanzato sull'instradamento (routing) ed il controllo del traffico su |
| 1315 |
Linux</uri>. C'è un'ottima sezione che mostra come usare iptables per marcare i |
| 1316 |
pacchetti ed utilizzare poi le funzionalità di routing di Linux per instradarli |
| 1317 |
sulla base di queste marcature. |
| 1318 |
</p> |
| 1319 |
|
| 1320 |
<note> |
| 1321 |
Questo manuale contiene dei riferimenti alla funzionalità per il controllo del |
| 1322 |
traffico (qualità del servizio) in Linux, attraverso il nuovo comando <c>tc</c>. |
| 1323 |
Questa nuova funzionalità, sebbene molto valida, è scarsamente documentata e |
| 1324 |
cercare di immaginarsi tutti gli aspetti del controllo del traffico in Linux può |
| 1325 |
risultare per ora un compito molto frustrante. |
| 1326 |
</note> |
| 1327 |
|
| 1328 |
</body> |
| 1329 |
</section> |
| 1330 |
<section> |
| 1331 |
<title>Mailing lists</title> |
| 1332 |
<body> |
| 1333 |
|
| 1334 |
<p> |
| 1335 |
Gli utenti che hanno domande su utilizzo, organizzazione o configurazione di |
| 1336 |
netfilter/iptables o chiunque voglia aiutare altri utenti condividendo la loro |
| 1337 |
conoscenza ed esperienza, possono contattare |
| 1338 |
<uri link="http://www.netfilter.org/mailinglists.html#ml-user">la mailing list |
| 1339 |
per gli utenti di netfilter</uri>. |
| 1340 |
</p> |
| 1341 |
|
| 1342 |
<p> |
| 1343 |
Gli sviluppatori di netfilter/iptables che hanno domande, suggerimenti o |
| 1344 |
contributi allo sviluppo di netfilter/iptables, possono invece contattare |
| 1345 |
<uri link="http://www.netfilter.org/mailinglists.html#ml-devel">la mailing list |
| 1346 |
per gli sviluppatori di netfilter</uri>. |
| 1347 |
</p> |
| 1348 |
|
| 1349 |
<p> |
| 1350 |
A questi indirizzi potete anche navigare tra gli archivi delle varie mailing |
| 1351 |
lists. |
| 1352 |
</p> |
| 1353 |
|
| 1354 |
</body> |
| 1355 |
</section> |
| 1356 |
<section> |
| 1357 |
<title>Building Internet Firewalls, Seconda Edizione</title> |
| 1358 |
<body> |
| 1359 |
|
| 1360 |
<p> |
| 1361 |
Nel Giugno 2000, O'Reilly ha pubblicato un libro eccellente -- <uri |
| 1362 |
link="http://www.oreilly.com/catalog/fire2/">Building Internet Firewalls, |
| 1363 |
Seconda Edizione</uri>. E' un ottimo libro di riferimento, specialmente per |
| 1364 |
quando volete configurare un firewall in modo da accettare (o rifiutare senza |
| 1365 |
mezzi termini) un protocollo poco noto col quale non avete familiarità. |
| 1366 |
</p> |
| 1367 |
|
| 1368 |
<p> |
| 1369 |
Bene, questo è tutto riguardo la lista delle risorse e la guida è terminata. |
| 1370 |
Spero che vi sia stata d'aiuto ed attendo i vostri commenti. |
| 1371 |
</p> |
| 1372 |
|
| 1373 |
</body> |
| 1374 |
</section> |
| 1375 |
<section> |
| 1376 |
<title>Le vostre opinioni</title> |
| 1377 |
<body> |
| 1378 |
|
| 1379 |
<p> |
| 1380 |
Aspettiamo di avere le vostre opinioni su questa guida. Inoltre potete |
| 1381 |
contattare direttamente l'autore, Daniel Robbins, all'indirizzo email <mail |
| 1382 |
link="drobbins@g.o">drobbins@g.o</mail>. |
| 1383 |
</p> |
| 1384 |
|
| 1385 |
</body> |
| 1386 |
</section> |
| 1387 |
</chapter> |
| 1388 |
|
| 1389 |
</guide> |
Archives