Web Version
Print Version
Esercitazioni (Risposte)
Esempi di configurazioni

Linux Firewall con Iptables

Corso intensivo e pratico su Linux usato in infrastrutture di rete eterogenee con funzioni di firewall e router.

Scheda Corso

Programma- Principi di Internetworking e gestione delle reti su Linux
- Logica e sintassi di iptables
- Principi di sicurezza delle reti
- Design di infrastrutture di firewalling e natting
- Esempi operativi di firewall per diversi scenari
- Monitoraggio e analisi dei logGiorni2Targetl corso è indirizzato a System Administrator, Network Administrator e Professionisti IT che devono configurare e gestire infrastrutture di firewalling basate su LinuxPrerequisiti- Discreta conoscenza di amministrazione di sistemi Unix o Linux
- Buona conoscenza di networking e protocolli TCP/IP
- Buona conoscenza dei principali servizi di rete su LinuxObiettivo- Conoscere le problematiche di sicurezza di un sistema interconnesso
- Conoscere i principali metodi di protezione e le strutture di rete sicure
- Conoscere la logica di iptables per firewalling e natting
- Creare un firewall con iptables: analisi di scenari di rete
- Disegnare, configurare e gestire strutture di firewalling eterogennMaterialiAi partecipanti verranno forniti:
- Macchine virtuali usate nel corso
- Esempi, configurazioni e settaggi utilizzati
- Manuale del corso

Programma

Installazione di Linux e introduzione alla sicurezza

Pianificazione dell'installazione di un sistema Linux sicuro usando procedure di installazione e aggiornamento dei pacchetti via rete. Check-list post installazione.
Introduzione al mondo della sicurezza per server in rete. Le problematiche, le risorse, i vari aspetti che riguardano il mondo della sicurezza informatica.

Obiettivo:
- Installare Linux via rete con attenzione alla sicurezza del sistema
- Eseguire procedure standard di hardening post-installazione
- Configurare l'aggiornamento (automatico) del sistema
- Comprendere il quadro d'insieme sulla sicurezza informatica
- Usare terminologia e riferimenti tipici della IT Security
- Conoscere i siti e le risorse più significativi

Installazione di Linux via rete

Kickstart, Jumpstart e sistemi di installazione centralizzata via rete.

Introduzione alla sicurezza

Introduzione alle problematiche di sicurezza su Internet

Linux post-installation check-list

Operazioni da compiere su un sistema Linux dopo averlo installato dal CDROM. Security fixes e patches.

Aggiornamento di un sistema Linux

I metodi e le tecniche per l'upgrade manuale e automatico di un sistema Linux

Link e documentazione sulla security

Libri, risorse, siti sulla sicurezza


Network security

Linux, la sicurezza e le reti.
Metodi di scanning e fingerprinting di sistemi in rete, pratiche di packet sniffing e firewalling su Linux tramite iptables.

Obiettivo:
- Comprendere le problematiche di sicurezza a livello di rete
- Conoscere i metodi di network scanning e fingerprinting
- Pratiche di packet sniffing
- Utilizzare iptables per utilizzare Linux come firewall

Linux Internetworking

Overview del networking su Linux

Network scanning: strumenti e tecniche

Strumenti e tecniche di network e vulnerability scanning. Information gathering.

Network sniffing: strumenti e tecniche

Teoria e pratica sulla subdola arte dello sniffing. Anti-sniffer tools. Arp spoofing e tecniche di prevenzione.


Linux Firewalling

Obiettivo:
Comprendere Iptables:
- La sintassi del comando
- La logica di gestione di un pacchetto nel kernel
- I campi di applicazione e le soluzioni possibili
Approfondimenti su funzionalità sperimentali
Sistemi di logging e gestione
Soluzioni di alta affidabilità

Linux firewalling: Introduzione a Iptables

Overview, gestione, utilizzo di iptables su Linux per packet filtering

iptables - Linux natting e packet mangling

Utilizzo di iptables per natting, masquerading e mangling di pacchetti.

Esempi di configurazione di Iptables

Esempi di configurazioni di un firewall Linux con iptables

Iptables Avanzato

Funzionalità avanzate di iptables.



Installazione di Linux e introduzione alla sicurezza


Installazione di Linux via rete

Kickstart, Jumpstart e sistemi di installazione centralizzata via rete.

Metodi di Installazione via Rete di Linux

Autore: al - Ultimo Aggiornamento: 2005-05-06 16:54:37 - Data di creazione: 2004-08-18 09:45:56
Tipo Infobox: DESCRIPTION - Skill: 1- NOVICE

Sebbene praticamente ogni distribuzione Linux venga distribuita tramite CDROM è possibile pianificare una installazione via rete, risparmiando tempo e automatizzando le operazioni.

Fondamentalmente esistono 4 diversi metodi di installazione, con livelli di automazione crescente:
1- Normale Installazione via CD
E' la procedura standard, si fa il boot da un CD e si procede alla configurazione del sistema rispondendo alle varie domande fatte dal tool di installazione. I pacchetti installati vengono prelevati direttamente dai CD forniti.

2- Normale installazione con scaricamento dei pacchetti via rete
E' una procedura leggermente più comoda, si presenta come una normale installazione ma si fa in modo di scaricare tutti i pacchetti via rete (locale, di solito) da un proprio repository creato appositamente. Di fatto questo rende più rapida l'installazione e non costringe, una volta fatte le configurazioni iniziali, a presiedere il sistema per cambiare il CD.
Su sistemi tipo RedHat va digitato al prompt di boot del CDROM linux askmethod per poter avere, successivamente, la richiesta su quale fonte di installazione scegliere.
Su Debian esiste il CD Network Install con il minimo necessario per installare un sistema che al primo riavvio procede allo scaricamento via rete di tutti il software che si sceglie.
E' inoltre possibile, ma ormai meno comodo, fare il boot da un floppy e scaricare il resto via rete (il kernel caricato dal floppy deve avere i driver per la propria scheda di rete).
Anche Gentoo prevede un minimal CD che permette il setup iniziale per poi gestire il resto dell'installazione via rete.

3- Installazione via kickstart o analoghi
Ha un livello di automazione maggiore, perchè permette di definire al boot un file da cui prendere tutti i settaggi che normalmente vengono configurati a mano. In questo modo gran parte dell'installazione avviene automaticamente e senza necessità di presidio, anche se il boot iniziale va fatto dal CD ufficiale.
RedHat e derivati usano KickStart, su Debian è disponibile FAI  (Fully Automatic Installation), Suse ha il suo AutoYaST

4- Installazione tramite PXE
E' la forma più automatica, ma prevedere la configurazione di una adeguata infrastruttura. E' possibile solo per le schede di rete che permettono il boot via rete (supportando la funzionalità PXE, Pre Execution Environment) che, oltre a poter essere usata per thin client senza hard disk locale, si può usare per automatizzare completamente una installazione, senza nemmeno la necessità di inserire il CDROM.

Descrizione di RedHat Kickstart

Autore: neo - ( Revisione: al ) - Ultimo Aggiornamento: 2005-05-06 16:21:59 - Data di creazione: 2003-08-19 15:08:05
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Kickstart è un sistema che permette di automatizzare e standardizzare il processo di installazione di Linux e risulta particolarmente utile quando si ha a che fare con un parco macchine particolarmente esteso. E' disponibile nelle distribuzioni di RedHat (Fedora e Enterprise Linux) e nelle derivate.
Permette di installare Linux sia tramite i media tradizionali (cd-rom) sia via network (http,ftp,nfs).
Il vantaggio nell'utilizzo di kickstart deriva dalla possibilità di:
- Rendere più facili e veloci i processi di installazione.
- Customizzare e rendere omogenee le installazioni.
- Automatizzare le attività di post-installazione.
- Installare sistemi con pacchetti RPM già aggiornati.

Risulta dunque essere la scelta ideale se si vuole avere un parco macchine uniforme o si deve prevedere un considerevole numero di nuove installazioni.

Tutto quello che si deve avere a disposizione è:
- Un server kickstart (Servizio Web, NFS, FTP o SMB che rende disponibili via rete gli rpm necessari all'installazione)
- Un dischetto o un cdrom per il primo boot della macchina
- Il file di configurazione (default ks.cfg) contenente tutte le opzioni per l'installazione ed eventuali script pre/post-installazione. Questo file può risiedere direttamente sul kickstart server (ce ne possono essere diversi con configurazioni per sistemi di diversa natura).

Creazione di un file di configurazione di kickstart

Autore: neo - ( Revisione: al ) - Ultimo Aggiornamento: 2005-05-06 16:01:41 - Data di creazione: 2003-01-27 14:24:10
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE

Creare il file di kickstart con i parametri da impostare via rete è semplice e può seguire due strade, fra loro non alternative:
- Fare una normale installazione su un sistema "master" e poi creare comodi cloni con le stesse impostazioni
- Creare da zero un file di configurazione con gli strumenti forniti dal sistema

Clonare una installazione
Ad ogni installazione di RedHat Linux, viene creato in modo automatico il file di configurazione per kickstart in /root/anaconda-ks.cfg con i parametri e i settaggi relativi alla installazione appena conclusa.
Editandolo a seconda delle proprie esigenze ci si ritrova con un file di configurazione kickstart utilizzabile su macchine clone (che avranno stesse impostazioni e possibilmente hardware simile).

Creazione di un file di configurazione di kickstart
RedHat rende disponibile un front-end grafico avviabile dal menu di gnome o kde (KickStart Configurator) oppure tramite shell lanciando il comando /usr/sbin/system-config-kickstart. Questo strumento permette di definire tutti i parametri relativi ad una installazione di Fedora/RedHat, con una interfaccia che ha gli stessi elementi di Anaconda (l'installer di RedHat), e quindi rende particolarmente semplice la creazione di uno o più file di kickstart da usare per scenari diversi.

Avvio dell'installazione via kickstart

Autore: neo - ( Revisione: al ) - Ultimo Aggiornamento: 2005-05-06 16:09:42 - Data di creazione: 2003-09-20 11:05:07
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE

Creato un file di configurazione .ks e messo a disposizione sul kickstart server o su un floppy, è possibile avviare l'installazione tramite kickstart.
L'operazione comune per qualunque media che verrà utilizzato per l'installazione è l'avvio del sistema con il boot dai device tradizionali come cd-rom o dischetto.

Al prompt di boot, specificando alcuni parametri è possibile indicare al sistema quale media dovrà utilizzare ma soprattutto dove risiede il file di configurazione per iniziare l'installazione.

Ammettiamo di avere un dischetto contenente sia l'immagine sia il file di configurazione, il comando al boot sarà:
boot: linux ks=floppy
oppure se il file di configurazione si chiama in modo diverso da quello di default (ks.cfg) è possibile specificarlo nel seguente modo:
boot: linux ks=hd:fd0/pippo.cfg
Nel caso in cui il file risieda nel cd-rom lanciare il seguente comando:
boot: linux ks=cdrom:/[path]
Comando di avvio in caso il file di configurazione risieda su un web o NFS server:
boot: linux ks=nfs:[server]:/[path]
boot: linux ks=http://[server]/[path]
In entrambi i casi sarà un dhcp server ad assegnare un indirizzo di rete.

Gli esempi sopra illustrati sono gli esempi delle modalità più utilizzate ma è possibile caricare il file di configurazione sia da un file system locale oppure tramite il dhcp server il quale assegnerà un ip e tutti i parametri necessari per raggiungere il file di configurazione.

Nel caso in cui il sistema preveda più interfacce di rete è possibile specificare tramite la seguente opzione quale interfaccia abilitare per l'installazione.
ksdevice=[device]
Esempio:
boot: linux ks=http://192.168.0.10/distro/servermail.ks ksdevice=eth2


Introduzione alla sicurezza

Introduzione alle problematiche di sicurezza su Internet

Information Security: definizioni e contesti

Autore: al - Ultimo Aggiornamento: 2003-05-02 11:59:32 - Data di creazione: 2003-05-02 11:59:32
Tipo Infobox: DESCRIPTION - Skill: 1- NOVICE

La sicurezza informatica è un argomento vasto che può essere considerato da diversi punti di vista e richiede un approccio globale e sistematico.
La necessità di proteggere un sistema informatico ha le stesse motivazioni di quella richiesta per edifici, documenti, oggetti e presenta aspetti simili.

Il tipo di problematiche da fronteggiare, a prescindere dal valore e dalla natura di quanto si intende proteggere, sono raggruppabili in poche categorie:
- Accesso a dati, documenti, oggetti, edifici e informazioni da parte di persone non autorizzate a farlo (concorrenti, governi stranieri, nemici, curiosi...). In questi casi le problematiche a cui si va incontro riguardano il controllo degli accessi e la verifica dell'identità di chi è autorizzato.
- Integrità di dati o oggetti, per evitare la manomissione, la modifica o la distruzione degli stessi. Per garantirla si deve avere la fiducia nelle persone autorizzate alle modifiche e la protezione da parte di estranei o persone non autorizzate (che potrebbero al contempo avere diritti e necessità di consultazione o accesso).
- Disponibilità dei dati, delle strutture che li forniscono, degli oggetti e di qualsiasi cosa che per essere utilizzata deve essere, in primo luogo, disponibile. Per questi compiti ci si deve difendere anche da elementi naturali o accidentali (terremoti, incendi, inondazioni, black out...).

In campo informatico la sicurezza riguarda essenzialmente dati disponibili su computer. La capacità di leggerli, modificarli e lo stessa possibilità di accedere ad essi grazie alla funzionalità dei sistemi in cui sono tenuti.
Una prima basilare distinzione va fatta fra computer in rete e computer accessibili solo direttamente.
In entrambi i casi l'accesso fisico alla console dei computer è un punto importante ma su macchine non in rete è una conditio sine qua non. Per sistemi in rete le problematiche aumentano notevolmente e se questi sono su Internet diventano particolarmente estese e varie, in quanto si deve provvedere a difendersi da maggiori quantità e diverse qualità di minacce possibili.

Per sistemi su Internet, in particolare, le minacce e il tipo di ostilità da cui difendersi sono:
- Virus, worm e altri agenti automatici, che si diffondono autonomamente su sistemi non aggiornati, senza volontà e intervento umano e possono causari danni di entità variabili;
- Scan su larga scala alla ricerca indiscriminata di sistemi vulnerabili sfruttando buchi di sicurezza generalmente noti. Questi scan possono essere fatti da script kiddies (individui normodotati che usano programmi noti, non particolarmente complicati) o cracker più esperti allo scopo di individuare rapidamente sistemi da violare ed utilizzare per svariati scopi (deposito di warez, host di appoggio per attacchi o scan ad altri server, defacing di siti web...).
- Attacchi mirati determinati alla penetrazione di uno o più host di un entità specifica per modalità varie (spionaggio industriale, furto di numeri di carta di credito, rappresaglia politica, vendetta... ). Sono insidiosi e i più pericolosi, perchè se effettuati da cracker capaci e determinati possono compromettere anche sistemi ben protetti.

Le protezioni e quindi le policy di sicurezza da adottare hanno diversi livelli di complessità e approfondimento: se è relativamente semplice difendersi dai primi due tipi di minacce, impostando una struttura che espone solo i servizi strettamente necessari e tenendo aggiornato il software che gestisce questi servizi, diventa molto più impegnativo realizzare una struttura estremamente sicura, in grado di resistere agli attacchi più smaliziati, sia tramite Internet che per vie indirette, come la stessa manomissione da parte di personale autorizzato, a vari livelli, all'accesso ai sistemi.

Introduzione al design di una infrastruttura di rete sicura

Autore: al - Ultimo Aggiornamento: 2003-05-02 12:08:46 - Data di creazione: 2003-05-02 12:08:46
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Non esistono certezze nel campo dell'Information Security, non esiste un sistema in rete sicuro al 100%: di un software che oggi appare sicuro, domani potranno essere trovati buchi sfruttabili per intrusioni esterne; una rete per quanto protetta deve essere amministrabile e chi la amministra o la utilizza con privilegi particolari, può essere esso stesso una minaccia.
Per quanto le problematiche di sicurezza siano quindi vaste e abbiano fattori diversi (accesso fisico ai sistemi, livello di fiducia nelle persone che li amministrano, potenziale insicurezza dei software usati...) si possono definire alcune linee guida minime per disegnare una rete il più possibile protetta da quelle che di fatto sono le maggiori minacce: l'intrusione di ignoti da Internet.
L'accesso da remoto ad un sistema può avvenire quasi esclusivamente tramite una porta TCP o UDP aperta su un host in rete, per cui a livello di networking il controllo e l'attenzione vanno posti su quali porte lasciare accessibili e come.
Realizzare una rete con un design di base sicuro richiede l'applicazione di alcune semplici regole di base, che vanno adattate ai diversi contesti specifici:

- Chiudere le porte su IP pubblico non utilizzate
Ogni tentativo di intrusione remoto può avvenire solo tramite eventuali porte aperte su un host. La prima, fondamentale, comoda e utile procedura da adottare per iniziare a proteggere il proprio network è quella di non lasciare varchi inutili ai potenziali intrusori.
La chiusura delle porte può essere fatta sia a livello dei singoli host (consigliata in ogni caso), rimuovendo tutti i servizi che non servono, sia a livello di firewall perimetrale, con un rigoroso packet filtering.
Le due soluzioni non sono alternative, anzi possono tranquillamente coesistere: sull'host si rimuovono i servizi inutili, sul firewall si possono gestire quali indirizzi IP sorgenti possono accedere a determinati servizi.
Questo si ricollega al secondo punto chiave:

- Centralizzare i punti di controllo del traffico
Tipicamente una rete aumenta la sua complessità con la sua naturale crescita, ma se non viene strutturata dall'inizio in modo lungimirante, rischia di diventare una matassa di router e firewall su cui si deve intervenire in caso di problemi o "aperture di porte".
Centralizzare i punti di routing e firewalling aiuta a implementare più facilmente modifiche alle configurazioni esistenti e a dignosticare problemi di rete, oltre a ridurre i point of failure della nostra infrastruttura.
Il firewall perimetrale (lo trattiamo come entità unica, ma può essere tranquillamente una coppia o una "nuvola" di firewall in failover) dovrebbe, di default, bloccare ogni tipo di pacchetto dall'esterno e prevedere regole specifiche per ogni server in produzione. Queste regole possono essere di 2 tipi:
- regole che aprono una determinata porta di un dato host a tutta Internet. Queste sono quelle necessarie per i servizi pubblici in produzione (server web, server di posta, DNS ecc.) ed è bene che "aprano" sono le porte strettamente necessarie e non tutto un indirizzo IP (anche se su questo risponde una macchina con tutti i servizi inutili disattivati). Sui firewall che gestiscono regole di filtraggio in modo sequenziale (le catene di iptables, le ACL del Cisco IOS o del PIX...) è sempre meglio mettere per prime le regole che riguardano i flussi di traffico maggiori, per diminuire l'impatto sulle risorse evitando inutili controlli su regole di filtering poco usate.
- regole che aprono l'accesso a determinate porte e IP da specifici IP sorgenti. Possono essere necessarie per aprire l'accesso FTP a dei data feed provider o permettere l'accesso in VPN da una determinata sede o l'accesso ad un database da un server remoto. Queste tipicamente tendono a rendere più verbosa e complicata la configurazione di un firewall, dal momento che devono adattarsi a IP sorgenti specifici, ma visto che sono necessarie è opportuno centralizzarle.
Nell'applicare simili regole, che tendono per il loro numero ad appesantire il firewall, si consiglia buon senso e tendenza al raggruppamento: se ci sono più IP da "aprire" della stessa subnet, si può considerare l'apertura dell'intera subnet, se ci sono più porte da aprire (sopratutto porte che di fatto permettono l'accesso al sistema, come telnet e ssh) può aver senso aprire l'accesso all'intero IP dell'host di destinazione, senza specificarne le singole porte.

- Controllare tutti i punti di accesso
In termini di sicurezza informatica, l'anello debole, quello meno controllato e sicuro, riduce la sicurezza di tutta l'infrastruttura. Per questo motivo è fondamentale identificare e ponderare ogni punto di accesso ai nostri sistemi da remoto. Questo include router e linee di partner, clienti e fornitori, macchine per permettono l'accesso via modem alla rete da proteggere ma anche dipositivi meno comuni come gateway X25 per pagamenti elettronici.
A prescindere quindi da tutte le protezioni del caso da prendere sia a livello fisico, che a livello dei client degli utenti (sviluppatori, sistemisti, redattori ecc) che in qualche modo possono accedere in modo privilegiato alla nostra rete, vanno verificati anche tutti i punti di entrata accessibili pubblicamente.
Come sempre, se questi prevedono un accesso via password, la coppia login-password dovrebbe non essere facilmente intuibile e il relativo traffico dovrebbe essere criptato.

- Design multilayer in caso di reti complesse
Se la rete da gestire comprende decine di host, di diversi utilizzi (macchine in produzione di front-end, cioè che devono interagire direttamente con Internet, macchine di backend come database o sistemi di monitoring, macchine di stage e pre-produzione, macchine di sviluppo, client di sistemisti e sviluppatori ecc) è opportuno valutare una suddivisione della nostra rete in più livelli, cercando di proteggere quelli più interni e delicati (il backend) e limitando allo stretto necessario l'accesso a queste macchine da parte di altre macchine più esposte (per esempio i server pubblici di front-end, i server di sviluppo, i client vari).
In strutture complesse, inoltre, le macchine di frontend, se possibile, non dovrebbero avere accesso in scrittura ai dati: un web server per esempio non dovrebbe poter scrivere sulla directory in cui sono contenute le sue pagine web, eventualmente generate da un Content Management System sul backend.
Con reti più semplici è comunque buona norma cercare di limitare allo stretto necessario le possibilità di comunicazione di una macchina con qualciasi altra macchina del nostro network, in modo da limitare i potenziali danni su tutti i sistemi dopo l'intrusione in uno degli host.

- Diversificare le difese
Il Tipico Esperto di Sicurezza, per definizione, solleva una quantità di problematiche enormi, non del tutto ingiustificate invero, e arriva ad analizzare molteplici aspetti, dalla sicurezza fisica al training del personale, dal logging di ogni bit sospetto alla gestione di un verbosissimo IDS, che nella realtà spesso diventano di difficile attuazione.
Un'altra delle Tipiche Raccomandazioni del suddetto Esperto è la diversificazione delle difese: non basta il firewall, non basta l'IDS, non basta la password sul Bios: ogni possibile mezzo per rendere difficile la vita ad un cracker è un buon mezzo, anche se a volte rende la vita difficile anche ad un sysadmin.
Un esempio tipico è la rimozione di ogni programma non strettamente necessario da un server in produzione: nessun comando per scaricare un file da remoto (wget, ftp, lynk, irc, curl ecc), nessun compilatore che permetta ad un intrusore di compilarsi i suoi sorgenti maligni direttamente sul nostro sistema, sistema di Mandatory Access Control che impedisca ad un qualsiasi processo di fare qualcosa di diverso da quello che è stato configurato per fare.
Dal punto di vista della sicurezza sono tutti buoni mezzi che aumentano la solidità del sistema e al contempo ne aumentano la difficoltà di gestione.
Come al solito, nel mezzo e nelle nostre specifiche esigenze, sta la soluzione ideale.

A queste indicazioni generali, che si applicano considerando solo a livello di rete le nostre problematiche di sicurezza si affiancano tutte le altre procedure volte a rendere sicuri i servizi che si lasciano aperti in rete.
Questo è un argomento ben più complesso e articolato, che riguarda i singoli sistemi operativi, i software utilizzati e le proprie implementazioni specifiche.
Come si è potuto intravedere, quindi, realizzare un sistema estremamente sicuro è complicato e richiede sforzi e risorse notevoli, ma realizzare una struttura di rete "ragionevolmente" sicura, che ci possa proteggere dalla maggior parte delle insidie non è eccessivamente gravoso e si può riassumere, semplificando all'estremo, in tre principi fondamentali:
- ridurre al massimo le porte esposte a Internet;
- avere software aggiornati in ascolto sulle porte esposte;
- non configurare in modo scorretto i servizi pubblici.

Definizioni e termini comuni nell'information security

Autore: al - Ultimo Aggiornamento: 2003-05-02 12:25:44 - Data di creazione: 2003-05-02 12:25:44
Tipo Infobox: DESCRIPTION - Skill: 1- NOVICE

Quando si inizia a parlare di sicurezza il gergo informatico si fa particolarmente pittoresco e rigoglioso, al punto che può essere utile definire in modo chiaro alcuni termini comuni.

Quando si parla di minacce possibili, si possono incontrare termini quali:

Virus
Un pezzo di codice in grado di diffondersi e duplicarsi in modo autonomo, legandosi ad un programma, ad una libreria condivisa, ad un messaggio di posta elettronica ecc. Esistono migliaia di virus diversi, raggruppabili in alcune categorie base. In comune hanno la capacità di duplicarsi automaticamente, la possibilità di eseguire operazioni potenzialente dannose sui sistemi infetti, la possibilità di attivarsi in contesti o momenti determinati.
Un antivirus è un software in grado di intercettare un virus prima che entri sulla macchina locale (via posta elettronica, tramite un flopppy disk infetto, tramite una condivisione di rete...) e di controllare ed eventualmente riparare i file infetti presenti sul computer.

Worm
Un worm ha caratteristiche simili ad un virus: si duplica automaticamente e può farlo in modo estremamente rapido. A differenza di un virus non si attacca ad altri programmi ma tende a mantenersi autonomo e non necessariamente fa danni diretti (tipo cancellare dei file) ma con la sua esistenza può seriamente limitare banda e risorse a disposizione.
Tipicamente, inoltre, un worm si diffonde fra server in rete, sfruttando vulnerabilità note per penetrare in sistemi non protetti.

Trojan Horse
Il cavallo di Troia è un programma modificato che esegue funzioni particolari e potenzialmente nocive all'insaputa del possessore, a cui il programma appare funzionare normalmente. Lo scopo di un Trojan Horse, fedele al mito ellenico, è spesso quello di permettere dall'esterno un accesso, ovviamente non autorizzato, al sistema su cui viene eseguito.

Bomb
Una bomba può essere un virus, un worm o qualcosa di analogo che si attiva in un determinato momento, dando luogo all'azione nociva per cui è stata realizzata. I meccanismi di attivazione possono essere legati ad una data, un giorno della settimana o un'ora specifici (time bomb) o correlati a qualche evento specifico di varia natura (logic bomb).

Back door
Una back door (o trap door) è un meccanismo (incorporato dal momento della creazione in software esistente o introdotto in tempi successivi come un trojan horse su del software locale) con cui si permette l'accesso al sistema a prescindere dai metodi di accesso noti e conosciuti del possessore.
La backdoor può essere inserita dallo sviluppatore di un programma per operazioni di manutenzione o, in visione hollywoodiana, per ricattare chi ne fa uso, oppure, più comunemente di questi tempi, può essere predisposta su un sistema esistente da parte di un intrusore, che dopo aver violato la macchina sfruttando una vulnerabilità non protetta, vuole garantirsi la possibilità di rientrare sul sistema per vie autonome, senza dover riutilizzare la vulnerabilità usata la prima volta.

I personaggi che popolano l'underground informatico hanno nomi quali:

Hacker
Da sempre, in gergo informatico, l'hacker è lo smanettone ingenioso e curioso che affronta un oggetto o un problema da un punto di vista diverso da quello inizialmente previsto riuscendo a farne un utilizzo nuovo.
Meno estesamente, un hacker è un programmatore o tecnico informatico in grado di realizzare software particolarmente innovativo o valido.
Nonostante questa definizione tutt'altro che maligna, i media hanno spesso abusato del termine hacker per indicare un "pirata informatico", che penetra su sistemi remoti o sprotegge software protetto da diritti d'autore.
Un termine più corretto per questa definizione è cracker.

Cracker
Chi attacca sistemi remoti al fine di violarne le protezione e prenderne il controllo o chi rimuove le protezione di un software o, ancora, coerentemente con il significato della parola inglese, chi riesce a "rompere" e superare una qualsiasi forma di protezione informatica.

Script kiddie
Si definisce tale, con nemmeno molto velato spregio, il ragazzino (anagraficamente o mentalmente) che utilizzando strumenti e software comuni nell'ambiente underground attacca sistemi remoti in modo sistematico.
Tradizionalmente lo script kiddie (letteralmente ragazzino da script) non ha le capacità tecniche di un cracker esperto, ma può essere ugualmente pericoloso per il carattere sistematico su larga scala dei suoi "scan" automatizzati.

Lamer, loozer, l0zer...
Termini generici e molto soggettivi per indicare un "perdente", un ignorante o comunque una persona da poco. Il tutto ovviamente è strettamente relativo a chi utilizza il termine e alla sua scala di valori e metri di valutazione.
All'opposto di ciò che è lame c'è il cool, kewl o simili variazioni sintattiche sullo stesso fonema.
Anche in questo caso ciò che è "cool" per qualcuno può non esserlo per altri, ma a prescindere dal merito, "lame" è aggettivo con forte connotazione negativa e "cool" ha connotazione positiva.

Azioni tipiche da cracker sono:

Spoofing
L'atto di modificare una connessione o un passaggio di dati in modo da far credere al destinatario di comunicare con un'entità diversa da quella che crede. Tipicamente lo spoofing viene fatto sull'indirizzo IP sorgente, inviano pacchetti ad un dato destinatario che si presentano con un IP sorgente arbitrario o scelto appositamente per bypassare firewall e controlli di accesso. La risposta a simili IP, ovviamente, viene fatta all'IP sorgente "spoofato" per cui, per portare avanti una connessione, l'attaccante deve poter essere in grado di intercettare anche le risposte.

Sniffing
Il controllo e il monitoraggio del contenuto di pacchetti che transitano su una rete. Tramite lo sniffing tutte le informazioni che vengono inviate in plain text sono visibili, quindi se si tratta di informazioni sensibili come una login e una password, possono essere visualizzate.

Defacing
La modifica dell'home page, o di altre pagine, di un sito web, da parte di un cracker dopo un intrusione eseguita con successo. Può essere una azione dimostrativa volta a veicolare un messaggio di qualsiasi tipo o una semplice esibizione delle proprie capacità e di essere riusciti a craccare un sistema.

Scanning
L'analisi di un sistema remoto finalizzata all'individuazione di vulnerability note.
La forma di scanning più basilare è quella rivolta all'individuazione delle porte aperte sul sistema remoto, a sua volta, è possibile eseguire degli scanning più specifici alla ricerca di vulnerabilità sui servizi disponibili sulle porte aperte trovate.

Altri termini che si incontrano spesso quando si parla di sicurezza informatica:

Plaintext - cleartext
Un testo in chiaro, leggibile così come è stato scritto. Se qualcuno è in grado di accedere a questo testo è quindi in grado di leggerne il contenuto.

Cipher text
Un testo criptato, il cui contenuto deve essere decriptato per essere leggibile. In termini generici di sicurezza usare delle connessioni o dei messaggi cifrati è raccomandabile in quanto anche nel caso in cui il testo giunga ad occhi non autorizzati a leggerlo, questi non potranno decodificarlo senza le opportune chiavi di decriptazione.
La lunghezza delle chiavi di crittazione è direttamente proporzionale al tempo computazionale necessario per decriptare un file usando tentativi brutali e sistematici.

Access Control List - ACL
Un elenco di regole volte a individuare dei pacchetti secondo diverse caratteristiche (IP sorgente, porta di destinazione, IP destinazione ecc.) al fine di eseguire determinate azioni come permetterne il flusso o interromperlo. Vengono tipicamente implementate su dei firewall ma si possono riferire in ogni contesto in cui l'accesso ad una data risorsa è limitata in qualche modo.

Trusted
"Fidato". E' un aggettivo che si riferisce a qualsiasi elemento in rete (Indirizzo IP sorgente, host, network...) da cui ci si possono aspettare connessioni non ostili. Tipicamente da certe sorgenti fidate si permette l'accesso a servizi di un host che sono impediti a tutti gli altri indirizzi IP.

Vulnerability
Una vulnerability è un bug nell'implementazione di un protocollo o di un software che permette azioni ostili che possono intaccare la sicurezza di un sistema. Le vulnerabilità possono essere "note", cioè descritte in mailing list o su appositi archivi, oppure anche ignote, cioè non comunemente conosciute ma già scoperte ed eventualmente utilizzate da qualche cracker.
Molti prodotti di security scanning si basano proprio sugli archivi delle vulnerabilità note.

Buffer overflow
E' una tecnica di hacking che consiste nell'inserire, in qualsiasi contesto possibile (una GET http, il campo di un form html, le dimensioni di un pacchetto o di un campo della sua intestazione ecc) una grande quantità di caratteri in modo da cercare di mettere in difficoltà il programma che deve gestirli qualora non preveda meccanismi di controllo sulla lunghezza delle variabili che gestisce. Quello che può accadere è che, da un certo byte in poi, il testo in eccesso venga scritto in locazioni arbitrarie di memoria.
Questo può essere sfruttato in vari modi e può causare dal crash del software ad una intrusione vera e propria.

Rootkit
E' un insieme di tool e programmi che vengono utilizzati da un cracker dopo un intrusione allo scopo di cancellare le proprie tracce e assicurarsi la possibilità di ritornare sul sistema violato anche senza dover riutilizzare la vulnerability usata la prima volta.


Linux post-installation check-list

Operazioni da compiere su un sistema Linux dopo averlo installato dal CDROM. Security fixes e patches.

Procedure di post-installazione su server

Autore: al - Ultimo Aggiornamento: 2002-10-14 17:53:20 - Data di creazione: 2002-10-14 17:53:20
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

L'installazione di un sistema Unix o Linux con il CD-ROM ufficiale è solo la prima fase della preparazione di un server per essere messo in produzione.

A questa vanno fatte seguire alcune customizzazioni quali:
- Aggiornamento dei pacchetti, per evitare di avere programmi con bug o buchi.
- Rimozione dei servizi non utilizzati e potenzialmente pericolosi
- Ricompilazione del kernel. Non indispensabile ma raccomandabile.
- Customizzazione del sistema secondo policy congruenti e generali.
- Intervento su alcune configurazioni riguardanti la sicurezza del sistema.
- Installazione e configurazione dei servizi di produzione.

Sono indicazioni di massima generiche che possono essere evitate su macchine desktop o sistemi senza problematiche di sicurezza ma che diventano fondamentali su sistemi direttamente su Internet.

Aggiornamento del software installato

Autore: al - Ultimo Aggiornamento: 2005-05-06 12:10:29 - Data di creazione: 2003-02-01 10:27:11
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Utilizzare software opensource ha vantaggi e svantaggi.
Uno degli svantaggi, o quantomeno effetti collaterali, è che relativamente spesso vengono rilasciati aggiornamenti di software comuni, caratteristica per'altro comune anche a software proprietario.
Le nuove versioni possono avere nuove feature, dei bug corretti o dei buchi di sicurezza tappati.
Abituarsi a sapere quali software vengono utilizzati sui server in produzione e sapere che è fisiologico doverli aggiornare è fondamentale per un approccio sicuro all'uso di Linux su server pubblici.

Ogni sistema Linux DEVE (dovrebbe?) essere aggiornato appena dopo l'installazione ed essere mantenuto costantemente aggiornato, almeno per i programmi che offrono servizi accessibili dalla rete.
Ogni distribuzione Linux seria prevede il rilascio regolare di pacchetti di aggiornamento (alcuni li chiamano "errata") per il software fornito con i CD ufficiali.

Possono essere diversi gli strumenti utilizzati in diverse distribuzioni (i principali sono: apt per Debian e derivate, yum per Fedora e derivate, swaret per Slackware, yast2 per Suse, urpmi per Mandrake...) ma simile è la loro logica: permettere l'aggiornamento, anche automatico, di tutti i pacchetti installati sul sistema, appoggiandosi a mirror pubblici ufficiali.
In linea con la logica conservativa dei sistemi di pacchettizzazione del software su Linux, gli aggiornamenti generalmente non generano disservizi:
- Se si sono dipendenze, queste vengono gestite coerentemente;
- I file di configurazione modificati dall'utente non vengono sovrascritti;
- I servizi vengono patchati e riavviati;
- Tutto funziona esattamente come è giusto che funzioni (e non si deve riavviare il sistema se non per l'aggiornamento del kernel stesso).

E' possibile valutare e decidere, sulla base della criticità, del numero e di quanto sia aderente agli standard della propria distribuzione, se gestire in modo automatico gli aggiornamento (tipicamente tramite schedulazione notturna) o farlo manualmente.
In ogni caso è buona norma, soprattutto se si devono amministrare più server Linux, avere in un proprio repository locale un mirror con tutti gli aggiornamenti che vengono rilasciati.
Fa risparmiare parecchio tempo e, se ben mantenuto, facilita l'ordinaria amministrazione e l'aggiornamento dei server.

Selezione dei servizi da avviare su Linux

Autore: al - Ultimo Aggiornamento: 2005-05-06 12:56:21 - Data di creazione: 2003-05-07 12:53:52
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE

Ogni distribuzione Linux installa una quantità di servizi che vengono automaticamente avviati al boot.
Alcuni sono necessari per il funzionamento generale del sistema, altri funzionali ai servizi che il server deve offrire, alcuni possono essere inutili per la sua attività e quindi andrebbero disattivati.
L'amministratore del sistema, a seconda della distribuzione usata, ha a disposizione diversi strumenti per gestire quali servizi far avviare al boot. Questi possono essere tool grafici, integrati nelle interfacce di amministrazione di default o comandi shell e variano:
Su Fedora, RedHat e derivati: ntsysv, chkconfig e tool grafico system-config-services
Su Debian: update-rc.d
Su Suse: chkconfig e Yast2
Su Mandrake: chkconfig e Mandrake Control Center
Su Gentoo: rc-update
Strumenti di ammnistrazione generici come Webmin o Linuxconf permettono altresì la gestione dei servizi da avviare ai vari run level del sistema.

Segue una lista, non completa, dei principali servizi che si trovano di default su installazioni Linux, alcuni nomi sono comuni anche in altri Unix. Viene indicato quando è il caso di disattivarli e quando sono sempre necessari, ovviamente sono indicazioni di massima, che vanno adattate alle singole situazioni.
E' basata sui servizi di una RedHat ormai datata, su nuove e altre distribuzioni possono variare i nomi e la quantità, ma in questo caso è importante considerare quali sono i servizi strettamente indispensabili.
anacron Controlla il demone di pianificazione anacron - Comodo su workstation, inutile su un server
apmd Controllo dell'alimentazione e del login - Utile in un portatile  
arpwatch Monitora le variazioni di arp entry. Utile per individuare azioni di arp poisoning
atd Controlla il demone at - Evitabile in un server
autofs Controlla il demone per l'automount di Filesystem - Utile in una workstation
crond Controlla il demone di pianificazione di sistema cron - Sempre attivo
ctm SNMP Traffic monitor - Utile per monitoring  
httpd Controlla il server Web Apache e i servizi HTTP - Solo su server web
identd Server Ident - Solo in casi particolari  
(x)inet Superdemone Inet - Da attivare solo se configurato per lanciare altri servizi (telnet, ftp, ecc.)
innd Server News - Solo su server news
keytable Controlla il caricamento della mappa di tastiera - Sempre attivo
kudzu Controlla e verifica la presenza di nuovo hardware - Utile per una workstation
linuxconf Permette l'accesso via web all'interfaccia di linuxconf - Da evitare su un server
lpd Controlla i servizi dello spooling di stampa - Da evitare su un server  
mars-nwe Controlla i servizi di sistema compatibili Netware - Da attivare solo se si utilizzano sistemi Netware
named Controlla l'avvio e l'arresto del Domain Name Service - Solo su server DNS
netfs Controlla i Mount e Umount di tutti i Network Filesystem  - Solo se si usano FS di rete
network Controlla l'avvio e l'arresto dei sistemi di rete - Sempre attivo
nfs Controlla i servizi del Network File System - Solo su server NFS
nfslock Controlla i servizi del Network File System - Solo su server NFS
pcmcia Controlla i servizi delle schede per computer portatili - Solo su portatili
portmap Controlla i servizi per la procedura di chiamata remota - Necessario per NFS, NIS+ ecc.
postgresql Controlla il demone di PostgreSQL database - Solo su un SQL Server
random Controlla la generazione dei numeri casuali - Sempre attivo
routed Controlla un RIP router daemon - Solo su un router, se serve
rstatd Controlla il demone delle statistiche del kernel di rete rpc.statd. - Da evitare
rusersd Controlla i servizi di rete dell'rpc.rusersd. - Da evitare
rwhod Controlla il demone di rete rwhod per i servizi di rwho - Da evitare
sendmail Controlla i servizi di trasporto di posta - Solo su server SMTP
smb Controlla i demoni Samba smbd e nmbd - Solo su file server CIFS-SMB
snmpd Controlla il demone del protocollo Simple Network Management - Utile per monitoring  
syslog Avvia e arresta i servizi di logging di sistema - Sempre attivo
xfs Avvia e arresta il server font X11 - Necessario per l'uso di Xwindows
*bind Controlla i servizi di binding NIS - Solo su sistemi NIS

Esempi di customizzazione del sistema

Autore: al - Ultimo Aggiornamento: 2005-05-06 13:13:05 - Data di creazione: 2002-10-13 22:25:56
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE

Esempi di customizzazioni post-installazione praticabili su sistemi Linux - Unix.

Sincronizzare l'ora con un time server
E' sempre buona cosa avere l'ora sincronizzata su tutti i server che si gestiscono. Il modo migliore di farlo è utilizzare un NTP server centrale per la propria rete (può essere un router Cisco, particolarmente semplice da configurare, o un ntp server Linux) e usarlo come time server da parte di tutti gli host.
Su Linux il comando ntpdate time.server.com (presente nel pacchetto ntp-*.rpm|dep ) esegue la sincronizzazione dell'ora locale con quella di time.server.com.
Si consiglia di crontabbare questo comando e di eseguirlo ad ogni boot.

Redirezionare le mail per root
La maggior parte delle mail che invia il sistema o i singoli programmi vengono redirezionate alla mailbox dell'utente root.
Se si hanno diverse macchine da amministrare risulta scomodo dover controllare la mail di root su ogni sistema.
Una possibilità è forwardare tutte tutte le mail destinate all'utente root ad un account di posta che si controlla regolarmente con il proprio client favorito. Per farlo basta creare il file /root/.forward e inserire nella prima riga l'indirizzo e-mail a cui si vuole forwardare la mail destinata a root, oppure aggiungere a /etc/alias una riga tipo: root: [email protected].

Invio periodico di mail di stato  
Può capitare che un sistema venga "dimenticato" dopo essere stato messo in produzione. L'amministratore non lo controlla e eventuali problemi vengono a galla solo troppo tardi, quando sono già avvenuti. Il miglior modo per gestire diversi server sarebbe quello di avere un sistema centralizzato di management e monitoring.
In mancanza di una soluzione esistono comodi e rapidi strumenti che analizzano i log di sistema e mandano, per esempio, una mail di report. Uno dei più usati è Logwatch installato di default in qualche distribuzione, che genera un report quotidiano sullo stato del sistema e lo invia via mail a root (altro buon motivo per leggere le mail di root).

Se si vuole procedere con una soluzione custom, segue un esempio di cosa può essere contenuto nello script che raccoglie info sullo stato del sistema (in questo caso crea un file, con il nome uguale alla data corrente, nella directory /home/getdata, questo file può poi essere inviato via mail tramite cron con mail root < /home/getdata/nomefile):

#!/bin/sh
home=/home/getdata
file=$(date '+%Y-%m-%d')
touch $home/$file
/bin/uname -a >> $home/$file Nome del sistema
/bin/df -k >> $home/$file Spazio su disco disponibile
/bin/netstat -rn >> $home/$file Tabella di routing
/sbin/ifconfig >> $home/$file Statistiche su interfacce di rete
/bin/netstat -lp >> $home/$file Programmi con porte aperte
/bin/netstat -s >> $home/$file Statistiche sul TCP/IP
cat /etc/resolv.conf >> $home/$file Nameserver utilizzato
cat /etc/hosts >> $home/$file Mapping statici nome host - IP
ps -adef >> $home/$file Processi in esecuzione
/sbin/iptables -L -n -v >> $home/$file Stato del firewall
/usr/bin/who >> $home/$file Utenti connessi al sistema
/bin/cat /root/.bash_history >> $home/$file History dell'utente root
/usr/bin/sar -A >> $home/$file
Se è installato sar, fornisce numerose statistiche sull'utilizzo delle risorse

Linux security check-list

Autore: al - Ultimo Aggiornamento: 2002-10-13 22:54:54 - Data di creazione: 2002-10-13 22:54:54
Tipo Infobox: DESCRIPTION - Skill: 4- ADVANCED

Riassumiamo qui una serie di configurazioni e ottimizzazioni post-installazione che possono aumentare il livello di sicurezza del sistema.

Non ci addentriamo nei particolari, ci si limita a dare indicazioni operative, lasciando a chi legge gli approfondimenti del caso.
Alcune indicazioni sono necessarie solo per server fisicamente posizionati in luoghi non sicuri ed in qualche modo accessibili da estranei (PHYSICAL), altre sono particolarmente pignole e dedicate a chi ha particolarmente a cuore la sicurezza del sistema o è particolarmente paranoico (PARANOID), altre ancora in qualche modo possono compromettere le funzionalità di parti del sistema per cui vanno adottate e testate adeguatamente (DISFUNCTION?), alcune sono particolarmente raccomandate (RECCOMENDED).
Queste impostazioni si riferiscono ad una distribuzione RedHat 7.2 standard. Su altre distribuzioni le posizioni dei file possono essere diverse e le indicazioni date vanno adattate.
In ogni caso queste indicazioni NON bastano a rendere un server sicuro, ma vanno affiancate ad altre precauzioni (aggiornamento costante di programmi e kernel - esposizione solo dei servizi strettamente necessari - utilizzo di IPTABLES adeguate - controllo della sicurezza dei servizi pubblici - installazione di un IDS e di un file integrity checker - log check regolare - BACKUP!).

Settare una password sul BIOS - PHYSICAL - RECCOMENDED
Necessario per impedire che si possa modificare il device di boot, impedendo la possibilità di fare password recovery o accesso non protetto ai dati bootando da floppy o CDROM estranei. Considerare che la password del BIOS è resettabile switchando un jumper sulla scheda madre. Il vero paranoico impedisce anche l'apertura del case se la macchina si trova in luoghi fisicamente non sicuri.

Strong password policy - RECCOMENDED
Le password di fatto sono il baluardo principale per permettere l'accesso al sistema. Se sono semplici, triviali, recuperabili da un dizionario o brevi sono password deboli.
E' possibile forzare il numero minimo di caratteri composti da una password editando /etc/login.defs e forzando a 8 il numero minimo di caratteri della password con PASS_MIN_LEN 8.
Altra opzione interessante presente nello stesso file è PASS_MAX_DAYS 99999 dove 99999 è la durata della password. Ha senso inserire un PASS_MAX_DAYS 180 per forzare il cambio della password ogni 180 giorni. Attenzione: Queste modifiche vanno fatte PRIMA di aggiungere utenti alla macchina. PASS_MAX_DAYS 99999 e altri parametri sono comunque modificabili successivamente in /etc/shadow.

Cript a lot - RECCOMENDED
E' fondamentale per un server pubblico che si gestisce via Internet rimuovere l'accesso telnet e sostituirlo con SSH, che cripta i dati trasmessi (e quindi login e password per l'accesso). SSH comunque non è esente da difetti, la versione 1 del protocollo ha potenziali buchi e in passato ci sono state serie vulnerabilities su alcuni software SSH. Si raccomanda di usare una versione recente di OpenSSH con supporto di SSH2, chiave di almeno 1024 bit e con accesso root diabilitato.

Permission restriction - PARANOID - DISFUNCTION?
In molte distribuzioni, spesso, alcuni file hanno di default permessi in lettura per tutti gli utenti anche quando non è necessario.
Non è una brutta idea restringere questi permessi, lasciando che sia root Colui Che Può:
chmod 600 /etc/inetd.conf Se presente inetd.conf. Ovviamente è pure necessario editarlo per rimuovere tutti i servizi inutili.
chmod 600 /etc/xinetd.conf Se presente Xinetd invece di inetd. Stesse raccomandazioni.
chmod 700 /etc/xinetd.d La directory dove Xinetd ha il file di configurazione per i singoli servizi.
chmod -R 700 /etc/&rc.d/init.d/* La directory dove sono presenti gli script di avvio. Perchè un normale utente dovrebbe vederlI?

Restrizione /etc/aliases - PARANOID - DISFUNCTION?
/etc/aliases gestisce gli alias di posta, spesso di default si forwardando a root la posta di altri utenti. E' opportuno commentare alcuni alias, inseriti di default, per evitare potenziali exploit tramite il loro utilizzo (in particolare l'alias decode). Segue una lista delle righe di /etc/aliases che si possono commentare o rimuovere. Dopo la modifica del file va eseguito il comando newaliases per rendarla effettiva:
# uucp: root
# operator: root
# games: root
# ingres: root
# system: root
# toor: root
# manager: root
# dumper: root
# decode: root


Boot loader password - PHYSICAL - RECCOMENDED
Impedire l'accesso alle opzioni del bootloader è fondamentale in un server fisicamente non custodito.
Se si usa lilo aggiungere a /etc/lilo.conf la riga password= e assicurarsi che lilo.conf sia leggibile solo da root.
Se si usa grub aggiungere a /etc/grub.conf la riga password  e assicurarsi che grub.conf sia leggibile solo da root o, meglio, usare l'opzione password --md5  

Disabilitare CTRL-ALT-CANC - PHYSICAL - RECCOMENDED
Sicuramente non ci piace l'idea che chiunque possa riavviare il nostro server con un comodo CTRL+ALT+CANC, per renderlo impossibile commentare in /etc/inittab la riga: ca::ctrlaltdel:/sbin/shutdown -t3 -r now

Stampare i log! - PARANOID
La prima cosa che fa un intrusore una volta preso possesso del sistema e coprire le proprie tracce, modificando e cancellando i log che ne possano rilevare l'entrata.
Questo è evitabile se si ha molta carta da sprecare: è possibile configurare syslog per stampare (su stampante a feed continuo) i log che si vogliono. E' semplice, basta aggiungere una riga come quella che segue ed avere una stampante funzionante su /dev/lp0
authpriv.* /dev/lp0

Usare un syslog server
Leggermente meno sicuro e definitivo del metodo precedente è quello di loggare i propri log su un syslog server remoto, opportunamente blindato, che risulti, per quanto possibile, inattaccabile per l'intrusore. Sul syslog locale aggiungere/modifcare:
authpriv.* @nomesyslogserver
Sul syslog server configurare /etc/rc.d/init.d/syslog per lanciare syslogd con l'opzione di accettare messaggi dalla rete, aggiungendo -r alle opzioni di startup.
In RedHat 7.2 modificare la riga: SYSLOGD_OPTIONS="-m 0" con SYSLOGD_OPTIONS="-r -m 0"
Buona scelta è anche usare alternative più sicure (paranoiche?) a syslogd.

Limitare la history della shell
E' possibile limitare la history predefinita della bash per ridurre i rischi che un hacker, leggendola, possa vederci delle password digitate per sbaglio.
Caso tipico è l'utente che prova a diventare superuser e scrive la password al momento sbagliato, passandola come comando shell (che probabilmente non verrà trovato) invece che come input alla richiesta della password. Tale leggerezza resta immortalata nella history della sua shell.
Editare /etc/profile per ridurre la dimensione della history. Modificare HISTSIZE=1000 in HISTSIZE=25 (o il valore che si preferisce).

Non urlare la proria identità - RECCOMENDED
Nonostante esistano tool come queso in grado di rivelare il sistema operativo installato su una macchina, è sempre buona norma fornire il minor numero possibile di informazioni sul sistema ed i suoi servizi. Questo non basta per fermare un bravo hacker, ma può essere abbastanza per fuorviare lo scan di uno script kiddie.
Per quanto riguarda i singoli servizi (web, dns, ssh, smtp ecc) riferirsi alle relative documentazioni per trovare il modo di nascondere versione e nome del programma utilizzato. Per quanto riguarda il sistema si può evitare di mostrare a console o via telnet/ssh un verboso banner introduttivo con nome distribuzione e versione del kernel.
Su RedHat7.2 editare rispettivamente /etc/issue e /etc/issue.net per mascherare versioni di kernel e distribuzione.
Su RedHat più vecchi uno sciagurato script di avvio (/etc/rc.d/rc.local) riscriveva ogni volta questi file con le informazioni originarie. In questo caso è necessario commentare le righe dello script che riscrivono /etc/issue e /etc/issue.net.

Rimuovere RPM, GCC e altri comandi utili - DISFUNCTION?
Se si vuole rendere la vita difficile ad un intrusore, e anche complicarsi un po' la propria, considerare la possibilità di spostare il comando RPM in una directory non standard (meglio cambiandogli anche il nome per evitare che un find lo trovi) o metterlo direttamente in un luogo inaccessibile (floppy estraibile).
Analogamente si può pensare di rimuovere dal sistema tutti i tool necessari per compilare del codice come gcc, make e le relative libraries (utili all'hacker che vuole crearsi delle backdoor) e i comandi che si possono usare per prendere un file dalle rete (lynx, ftp, irc, ncftp, wget, scp, rcp ...) e che si possono impropriamente essere utilizzare per caricare sulla macchina programmi estranei.
Queste precauzioni, seppur efficaci in un contesto di sicurezza estrema, rendono molto meno comoda e pratica la vita dell'amministratore.

Restringere le opzioni di mount del file-system - DISFUNCTION?
Il file /etc/fstab contiene le informazioni su quali dispotivi possono essere montati sulla macchina e può definire delle opzioni che introducono limitazioni sul file-system montato.
Per esempio un /etc/fstab con queste righe:
/dev/hda2 /tmp ext2 defaults 1 2
/dev/hdc1 /home ext2 defaults 1 1

può essere modificato con opzioni che restringono, sui file system montati, la possibilità di eseguire binari (noexec), di onorare i bit setUID e setGID su file che li hanno (nosuid), di interpretare caratteri o dispositivi a blocchi speciali (nodev):
/dev/hda2 /tmp ext2 nosuid,nodev,noexec 1 2
/dev/hdc1 /home ext2 nosuid,nodev 1 1


Limitare gli utenti che possono fare SU - RECCOMENDED
Qualsiasi utente con una shell sul sistema con il comando su, può diventare root (sapendo la password). Si può stroncare alla radice questa velleità editando il file /etc/pam.d/su e scommentando la riga:
auth required /lib/security/pam_wheel.so use_uid.
Una volta fatto, solo gli utenti appartenti al gruppo wheel (è un gruppo speciale, non si possono usare altri gruppi arbitrari per questa operazione) possono fare su, per cui editare /etc/group ed aggiungere al gruppo wheel gli utenti abilitati ad eseguire su.


Aggiornamento di un sistema Linux

I metodi e le tecniche per l'upgrade manuale e automatico di un sistema Linux

Strumenti di aggiornamento del software su Linux

Autore: al - ( Revisione: al ) - Ultimo Aggiornamento: 2006-03-23 11:52:41 - Data di creazione: 2004-10-22 19:06:37
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

L'aggiornamento di un sistema operativo è un operazione fondamentale per la sua sicurezza, sia in ambito aziendale che domestico, sia su server che su desktop.
L'unica differenza sostanziale saranno i mezzi, le necessità e le modalità ma l'obbiettivo è comune: proteggere i propri sistemi aggiornandone il software regolarmente per eliminare possibili vie di intrusione tramite vulnerabilità note.
Esistono molteplici vie per eseguire l'update di sistemi Linux:
- utilizzare tool automatici o semi-automatici per il download e l'installazione di pacchetti rpm o deb,
- installare manualmente nuovi pacchetti binari per l'aggiornamento dei programmi installati,
- compilare i sorgenti con le patch del software da aggiornare.

L'uso di strumenti (semi)automatici, generalmente consigliabile quando si deve gestire un parco macchine considerevole, può basarsi su mirror distribuiti nel mondo o su un servizio, generalmente a pagamento, offerto dal produttore della distribuzione che si usa.
Ogni distribuzione Linux ha i propri metodi preferenziali per l'aggiornamento del software.

REDHAT
La versione commerciale di RedHat (Enterprise edition) si aggiorna tramite il RedHat Network (RHN) che permette di gestire e aggiornare facilmente anche via Web una moltitudine di sistemi. up2date, utilizzabile sia via command line che tramite interfaccia grafica, è il programma utilizzato per aggiornarsi tramite RHN.
Fedora, la distribuzione free di RedHat, aperta alla community, si aggiorna tramite yum (tool di aggiornamento derivato da Yellow Dog Linux) che si appoggia a svariti mirror worldwide.
Sono disponibili, ma non inclusi dei CD ufficiali, altri strumenti di aggiornamento come autorpm o la versione per rpm di apt.

DEBIAN
I pacchetti .dep di Debian vengono gestiti e aggiornati tramite il potente apt che appoggiandosi ad un elenco di mirror distribuiti permette di scaricare e aggiornare software sia del ramo "stable" che quello "testing". Con il comando apt-get di fatto si gestisce ogni attività.

MANDRIVA
L'aggiornamento e la gestione dei pacchetti rpm avviene tramite l'interfaccia grafica rpmdrake o il tool testuale urpmi. Entrambi si appoggiano a dei mirror configurabili e sono presenti di default sul sistema.

NOVELL - SUSE
Tramite il tool grafico di configurazione Yast2, strettamente integrato in ogni distribuzione Suse, è possibile gestire e automatizzare gli aggiornamenti dai mirror selezionati.

SLACKWARE
I pacchetti tgz di Slackware possono essere aggiornati dai mirror ufficiali tramite tool come swaret e slapt-get, che vanno scaricate a parte.

GENTOO
E' fortemente radicato nel sistema di gestione dei portage di Gentoo l'aggiornamento (tramite scaricamento dei sorgenti e ricompilazione automatica degli stessi) e l'installazione del software. Il comando emerge provvede a tutto.

Patching dei Sorgenti
Tramite utility come patch o diff, o semplicemente ricompilando i sorgenti presenti nel tar.gz (./configure ; make ; make install), è possibile applicare o creare patch (file contenenti modifiche da apportare ai file originari) al software installato sul sistema senza l'utilizzo di pacchetti. Questa operazione viene eseguita principalmente quando si lavora direttamente dai sorgenti, ricompilandoli una volta applicata la patch e può applicarsi a qualsiasi distribuzione.
Non essendo legata ad uno specifico sistema di packaging, va fatta manualmente.

RedHat Network (RHN)

Autore: neo - ( Revisione: al ) - Ultimo Aggiornamento: 2003-05-05 23:08:20 - Data di creazione: 2003-05-05 23:08:20
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

RedHat Network è nata per gestire con più facilità gli aggiornamenti software di uno o più sistemi RedHat, anche di vecchia data.
La sua prima comparsa risale nella distribuzione RedHat 6.0, tramite l'utility up2date.

Attualmente oltre all'utility testuale up2date si ha disposizione una GUI (interfaccia grafica) e un demone (RHNSD) che si occupa di gestire in via del tutto automatica i check periodici per gli upgrade.
Il principio su cui si basa RHN è molto semplice, di fatto RedHat mette a disposizione dei repository da cui poter scaricare gli aggiornamenti tramite un client specifico, up2date.
Questo client si occupa di scaricare gli aggiornamenti in modo "intelligente", ovvero facendo ricerche incrociate per downlodare solo i RPM necessari.
Da sottolineare che lo scambio dei dati fra client e server RHN viene effettuato tramite il protocollo SSL e che sui pacchetti scaricati vengono fatti controlli di integrità attraverso il checksum GPG per evitare spiacevoli problemi di intercettazione dati e malformazione dei pacchetti.
Inoltre l'utility è estremamente flessibile poichè da la possibilità al sistem administrator di configurare molteplici opzioni, come ad esempio la possibilità di creare liste di rpm che non dovranno mai essere aggiornati oppure la creazione di più utenti per la gestione dei singoli canali (Es RedHat 8.0 i386 e RedHat 6.2 sparc sono due canali diversi) con permessi differenti, oppure decidere semplicemente di downlodare e non installere gli upgrade.

Esistono anche soluzioni per ottimizzare e velocizzare tutte le procedure di automatizzazione dell'upgrade di più sistemi come:

RHN proxy
RHN proxy, come si può intendere dal nome stesso è un sistema che permette di usufruire del servizio RHN tramite un proxy, il quale avrà il compito di scaricare e mettere in cache tutti gli aggiornamenti necessari per i sistemi della propria network. Il vantaggio risiede nella riduzione del traffico (Es. l'aggiornamento del RPM del kernel viene scaricato una volta, salvato sul proxy ma utilizzato da tutti i sistemi che lo richiedono) oltre alla possibilità di propagare rpm personalizzati o che non sono stati rilasciati ufficialmente dallo staff di RedHat.

RHN Satellite
RHN Satellite, oltre a tutti i vantaggi di RHN Proxy, permette di avere nella propria network un vero e proprio server RHN con tutti i vantaggi del caso.
Per usufruire di questa possibilità vengono richiesti sforzi maggiori per quanto riguarda i requisiti di sistema (ES: Installazione di Oracle e di RedHat Advanced Server).
Anche in questo caso si ha la possibilità di configurare nei minimi dettagli tutte le singole opzioni oltre che utilizzare questo sistema anche come server kickstart per effettuare installazioni personalizzate direttamente via rete.
Questa soluzione risulta essere vantaggiosa solo in caso di reti aziendali molto grosse, nell'ordine di 1000 host e più.

up2date

Autore: neo - ( Revisione: al ) - Ultimo Aggiornamento: 2003-04-19 18:45:02 - Data di creazione: 2003-04-19 18:45:02
Tipo Infobox: COMMANDS - Skill: 3- INTERMEDIATE

up2date è l'utility testuale che permette di usufruire del servizio RedHat Network per aggiornare gli RPM del sistema.

up2date [opzioni] [nome RPM]
up2date-nox  [opzioni] [nome RPM]
up2date-config [opzioni] [nome RPM]

Opzioni:
--configure Abilita la modalità configurazione, attraverso un menu in shell. (update-config)
-d, --download Esegue il download dei RPM ma non li installa.
-f, --force Forza l'installazione dei RPM.
-i, --install Installa tutti gli RPM scaricati.
-k, --packagedir Specifica la direcory che funge da repository di RPM, per evitare di scaricare più volte lo stesso package.
--nosig Evita il check con gpg dei singoli rpm.
--tmpdir=directory Specifica la directory temporanea. Default /var/spool/up2date.
--justdb Non installa gli RPM sul sistema, ma li aggiunge nel db di RPM.
--dbpath=dir Specifica il path del db di RPM.
-l, --list Mostra l'elenco dei vari RPM disponibili.
--showall Mostra l'elenco di tutti gli RPM scaricabili.
--undo Esegue l'undo dell'ultimo update.
-u, --update Esegue l'update di tutti i RPM disponibili.
--register Registra il server al servizio RHN.
--show-channels Visualizza i canali disponibili.

Paths utili (RedHat):
/var/spool/up2date - Directory in cui vengono scaricati gli rpm.
/etc/sysconfig/rhn/up2date - Il file di configurazione principale.
/etc/sysconfig/rhn/up2date-uuid - Il codice unico che identifica il proprio sistema su RHN

Creazione di un repository di RPM per Fedora 3

Autore: al - Ultimo Aggiornamento: 2005-04-26 16:49:38 - Data di creazione: 2005-02-10 17:08:42
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE

La procedura per la creazione di un repository di RPM (usando i CD ufficiali e un mirror degli update) è simile a quella utilizzabile per un repository di Fedora2.
Prevede diverse fasi:
1- Installazione del software necessario per creare un repository (createrepo) ed esportarlo via Web (apache)
2- Creazione di uno script che esegua il mirror degli rpm da un sito ufficiale su una directory locale e che provveda a ricreare, ogni volta, gli indici dei pacchetti presente nel repository (repodata);
3- Mount in loopback sul sistema delle iso dei CD ufficiali e creazione, una tantum, dei repodata
4- Configurazione di apache per esportare tutto via web
5 (Sui Client) - Configurazione di yum per scaricare i pacchetti dal proprio repositoy locale.

1 - Installazione software
Per creare un proprio repository essenzialmente basta il pacchetto createrepo, per condivederlo via web basta Apache e per usare lo script sotto riportato per sincronizzare il proprio sistema con un mirror ufficiale, è necessario rsync:
yum install createrepo
yum install apache
yum install rsync

E' probabile che sul proprio sistema siano già installati sia Apache che Rsync.

2 - Script di sincronizzazione e creazione repository
Il seguente script scarica via rete, dall'url definito in REMOTE_UPDATES i pacchetti di tipo rpm (sono esclusi pacchetti di sorgenti, di debug o per sistemi non i386, per evitare tempi di download eccessivi) e li copia della directory locale definita in LOCAL.
Dopo il download (eseguito tramite rsync) viene eseguito in comando createrepo passandogli come argomento la directory in cui si trova la directory packages contenenti gli rpm. Allo stesso livello di questa directory viene creata la directory repodata con tutti i metadati necessari a yum.
Notare che rispetto a Fedora 2, qui c'è una sostanziale differenza: i metadati vengono creati con l'utility createrepo (più veloce) invece dell'ormai superato yum-arch.
Notare altresì che questo script, oltre a scaricare gli update, fa anche il mirror di due interessanti repository con RPM aggiuntivi (extra e livna).

#!/bin/sh
#### FEDORA 3 ######

## DEFINE LOCAL DIRECTORY
LOCAL=/distro/fedora3/

## DEFINE OFFICIAL FEDORA UPDATES MIRROR
REMOTE_UPDATES=rsync://ftp.join.uni-muenster.de/fedora-linux-core

## DEFINE FEDORA.US EXTRAS MIRROR
REMOTE_EXTRA=rsync://mirrors.kernel.org/fedora.us/fedora
# REMOTE_EXTRA=rsync://ftp-stud.fht-esslingen.de/fedora
# REMOTE_EXTRA=rsync://sunsite.mff.cuni.cz/fedora.us

## DEFINE LIVNA MIRROR
REMOTE_LIVNA=rsync://rpm.livna.org/rlo/fedora

# Fedora 3 Updates (RPM i386)
/usr/bin/rsync --ignore-existing -v $REMOTE_UPDATES/updates/3/i386/*.rpm $LOCAL/updates/packages/
/usr/bin/createrepo $LOCAL/updates

## Optional extra RPM packages repositories

## Fedora 3 Extras
#/usr/bin/rsync --ignore-existing -av $REMOTE_EXTRA/fedora/3/i386/RPMS.extras/*.rpm $LOCAL/extras/packages/
#/usr/bin/createrepo $LOCAL/extras

## Fedora 3 Livna
#/usr/bin/rsync --ignore-existing -v $REMOTE_LIVNA/3/i386/RPMS.stable/*.rpm $LOCAL/livna/packages/
#/usr/bin/createrepo $LOCAL/livna


3- Creazione repository per i pacchetti dei CD  
Per quanto riguarda il contenuto dei CD ufficiali di Fedora, uno dei metodi più rapidi ed efficaci è di montare in loop le rispettive iso e creare gli indici (visto che i pacchetti sono sempre gli stessi, i repodata vengono generati una volta soltanto.
Nel nostro esempio abbiamo le iso nella directory /distro/iso e vogliamo montarle nelle directory /distro/fedora3/cd/disc1, disc2 ecc.
Creazione delle directory su cui montare ed "esplodere" il contenuto delle iso.
E' molto importante chiamare le directory in questo modo (disc1, disc2, disc3 e disc4) per poter gestire anche installazioni centralizzate via rete:
mkdir -p /distro/fedora3/cd/disc1
mkdir -p /distro/fedora3/cd/disc2
mkdir -p /distro/fedora3/cd/disc3
mkdir -p /distro/fedora3/cd/disc4

Mount in loop delle iso (che vanno ovviamente copiate precedentemente in /distro/iso/ o directory analoga):
mount -t auto -o loop /distro/iso/FC3-i386-disc1.iso /distro/fedora3/cd/disc1
mount -t auto -o loop /distro/iso/FC3-i386-disc2.iso /distro/fedora3/cd/disc2
mount -t auto -o loop /distro/iso/FC3-i386-disc3.iso /distro/fedora3/cd/disc3
mount -t auto -o loop /distro/iso/FC3-i386-disc4.iso /distro/fedora3/cd/disc4

Creazione del repository:
createrepo /distro/fedora3/cd/
Questo comando crea la directory /distro/fedora3/main/repodata/con tutti i metadati relativi ai pacchetti contenuti nei CD (nelle directory incluse in main).

4- Configurazione di Apache
Esportare via web i pacchetti rpm e i metadati è necessario sia per eventuali installazioni via rete che per gli aggiornamenti tramite yum dei client.
Fermo restando che nomi delle directory, path e indirizzi possono essere variati secondo i propri sistemi possiamo configurare in modo semplice Apache creando un file di configurazione, chiamato, per esempio, /etc/httpd/conf.d/yumrepository.conf con simili contenuti (accesso da qualsiasi IP e possibilità di browsing delle directory):
Alias distro /distro

Options + Indexes
AllowOverride None
Order allow,deny
Allow from all

In questo modo, ipotizzando che il nostro server abbia IP 10.42.42.1, all'URL http://10.42.42.1/distro/ troveremo i contenuti della directory /distro locale, in cui esiste una sottodirectory iso, con le iso dei CD, e la sottodirectory fedora3 con i vari pacchetti e i relativi metadati.

5- Configurazione dei client
A questo punto la configurazione del server centrale con le funzioni di repository è completa. Possiamo procedere alla configurazione dei client, cioè dei sistemi (desktop o server che siano) che useranno questo repository locale (accessibili a velocità da LAN) per tutte le operazioni di installazione e aggiornamento dei pacchetti RPM.

Su ogni host su cui si è installato Fedora 3 (o in genere ogni sistema RedHat o basato su RPM) è opportuno importare le chiavi pubbliche GPG con cui sono stati firmati i pacchetti ufficiali. Questo permette di forzare l'aggiornamento e l'installazione solo dei pacchetti di cui la fonte è certa e validata.
Per farlo, su Fedora3, scrivere:
rpm --import /usr/share/doc/fedora-release-3/RPM-GPG-KEY
(questa è la chiave GPG con cui sono firmati tutti i pacchetti degli aggiornamenti) e:
rpm --import /usr/share/doc/fedora-release-3/RPM-GPG-KEY-fedora
(la chiave con cui sono firmati i pacchetti di base presenti nei CD ufficiali).

Notare che questa attività va fatta anche su un sistema Fedora che si vuole aggiornare normalmente via Internet, senza usare un repository locale, in quanto, di default, nessuna chiave GPG è importata e viene automaticamente impostato l'obbligo di fare un check della presenza della firma GPG (opzione gpgcheck=1 allinterno del file di configurazione /etc/yum.conf e dei singoli file di configurazione dei repository)

Il passo successivo, e l'ultimo per avere l'infrastruttura di aggiornamento centralizzata, è quello di modificare gli URL da cui il sistema preleva i suoi rpm.
Modificare il file /etc/yum.repos.d/fedora.repo (relativo al repository base, con gli rpm presenti nei cd ufficiali) in qualcosa tipo:
[base]
name=Fedora Core $releasever - $basearch - Base
#baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/$releasever/$basearch/os/
# mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-$releasever
baseurl=http://10.42.42.1/distro/fedora3/cd/
enabled=1
gpgcheck=1

In pratica si sono solamente commentate le righe esistenti (meglio commentarle che cancellarle, potrebbero essere utili in caso di problemi con il repository locale) e si è aggiunta la righa che punta al proprio server (ovviamente l'IP 10.42.42.1 e il path possono cambiare).

Analogamente, per il file /etc/yum.repos.d/fedora-updates.repo (relativo agli aggiornamenti ufficiali) scrivere:
[updates-released]
name=Fedora Core $releasever - $basearch - Released Updates
#baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/updates/$releasever/$basearch/
#mirrorlist=http://fedora.redhat.com/download/mirrors/updates-released-fc$releasever
baseurl=http://10.42.42.1/distro/fedora3/updates/
enabled=1
gpgcheck=1


Gestione repository aggiuntivi
Oltre ai repository ufficiali (base e updates) è possibile aggiungere al proprio sistema uno o più dei molteplici repository di pacchetti rpm per software aggiuntivo, che estendono considerevolmente la facilità di installazione di pacchetti interessanti o utili che non sono presenti nel CD ufficiale.
Nello script sopra riportato sono presenti, commentate, delle righe per eseguire il mirror e la creazione dei metadati, per i repository Extras (pacchetti RPM extra, semi-ufficiali, gestiti dalla community e ospitati da RedHat) e Livna (altri pacchetti, basati e con dipendenze da quelli Extra, particolarmente interessanti).
Per includere anche questi repository, oltre a scommentare le righe dello script di mirror e a creare le directory utilizzate sul server, sui client vanno creati file come: /etc/yum.repos.d/extras.repo contentente:
[extras]
name=Fedora Core $releasever - $basearch - Extra
baseurl=http://10.42.42.1/distro/fedora3/extras/
enabled=1
gpgcheck=1


E il file /etc/yum.repos.d/livna.repo con:
[livna]
name=Fedora Core $releasever - $basearch - Livna
baseurl=http://10.42.42.1/distro/fedora3/livna/
enabled=1
gpgcheck=1


Ricordarsi che anche per questi due repository vanno importate le chiavi GPG:
rpm --import http://download.fedora.redhat.com/pub/fedora/linux/extras/RPM-GPG-KEY-Fedora-Extras
rpm --import http://rpm.livna.org/RPM-LIVNA-GPG-KEY-i386

apt-cache

Autore: neo - Ultimo Aggiornamento: 2003-03-14 22:30:25 - Data di creazione: 2003-03-14 22:30:25
Tipo Infobox: COMMANDS - Skill: 4- ADVANCED

Utility di APT per la gestione della cache di supporto.

apt-cache [opzioni] comando
apt-cache [opzioni] add file1 [file2 ...]
apt-cache [opzioni] showpkg pkg1 [pkg2 ...]
apt-cache [opzioni] showsrc pkg1 [pkg2 ...]


Comandi:
add  Aggiunge un pacchetto alla cache
showpkg  Visualizza informazioni generali di un singolo pacchetto (versione,dipendenze etc..)
showsrc  Visualizza i sources record (descrizione, mantainer del package etc.. )
stats  Visualizza alcune statistiche
dump  Mostra il contenuto della cache
search  Abilita la ricerca di un package per il nome
show  Mostra tutto il contenuto di un package
depends  Visualizza le dipendenze di un package
pkgnames  Visualizza l'elenco di tutti i package scaricabili

Opzioni:
-p=? Specifica il file per salvare la cache dei package.
-s=? Specifica il file per salvare la source cache.
-q   Abilita il quiet mode.
-c=? Specifica quale file di configurazione utilizzare.
-o=? Permette di settare un opzione.

Import delle chiavi GPG per installare i pacchetti rpm

Autore: neo - Ultimo Aggiornamento: 2005-05-06 11:53:22 - Data di creazione: 2003-07-29 17:07:23
Tipo Infobox: TIPS - Skill: 4- ADVANCED

I pacchetti rpm che venongo distribuiti da chi produce una distribuzione o da chi gestisce repository alternativi, sono quasi sermpre "firmati" con una chiave GPG che certifica l'autore del pacchetto, assicurandone la fonte.
E' bene, al termine di una installazione Linux, importare le chiavi pubbliche (rpm --import) dei packager che forniscono gli aggiornamenti o i pacchetti che si intendono utilizzare. Questa operazione potrebbe rendersi indispensabile quando si utilizzano tool di aggiornamento automatici come yum o autorpm se sono configurati per eseguire il gpgcheck dei pacchetti da aggiornare.

Se si prova ad installare un pacchetto creato da un packager di cui non si è importata la chiave GPG pubblica si ottiene un output di questo genere:
[root@zoe root]# rpm -Uhv httpd-2.0.40-21.3.i386.rpm
warning: httpd-2.0.40-21.3.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60e
Preparing...                ########################################### [100%]
   1:httpd                  ########################################### [100%]


Le chiavi GPG pubbliche sono comunemente rintracciabili nella directory principale del primo CD di installazione o in /usr/share/doc/, ad esempio su Fedora in /usr/share/doc/fedora-release-XX/RPM-GPG-KEY:
[root@zoe root]# rpm --import /usr/share/doc/fedora-release-2/RPM-GPG-KEY
[root@zoe root]# rpm -Uhv httpd-manual-2.0.40-21.3.i386.rpm
Preparing...                ########################################### [100%]
   1:httpd-manual           ########################################### [100%]

apt-get

Autore: neo - Ultimo Aggiornamento: 2003-03-14 22:34:23 - Data di creazione: 2003-03-14 22:34:23
Tipo Infobox: COMMANDS - Skill: 4- ADVANCED

Utility per la gestione dei package di un sistema tramite command line.

apt-get [opzioni] comando
apt-get [options] install|remove pkg1 [pkg2 ...]
apt-get [options] source pkg1 [pkg2 ...]


Comandi:
update Scarica la nuova package list
upgrade Esegue l'upgrade dei package
install Installa un nuovo pacchetto
remove Rimuove un pacchetto
source Scarica i sorgenti del pacchetto specificato
build-dep Configura le build dependency
clean Cancella tutti  i vecchi file
autoclean - Cancella i vecchi file scaricati e archiviti
check - Verifica che tutte le dependency siano presenti

Opzioni:
-qq Abilita il quiet mode, visualizza solo gli errori (utile in script schedulati)
-d I package vengono solo scaricati e non installati
-y Risponde Yes in modo automatico a tutte le domande presentate (utile in script schedulati)
-D Abilita la rimozione di un package con tutte le sue dipendenze
-c=? Specifica la lettura di un file do configurazione
-o=? Permette di settare alcune opzioni specifiche


Link e documentazione sulla security

Libri, risorse, siti sulla sicurezza

Link essenziali sulla security

Autore: Eberk - ( Revisione: al ) - Ultimo Aggiornamento: 2003-04-14 16:00:00 - Data di creazione: 2003-04-14 16:00:00
Tipo Infobox: DESCRIPTION - Skill: 1- NOVICE

In rete si trova una miriade di siti che trattano a diversi livelli di sicurezza informatica.
Si elencano qui i siti più significativi e utili.

http://www.infosyssec.net
InfoSysSec Security Portal. Ricco portale sulla sicurezza. Ben organizzato e completo, contiene link, info e news su ogni aspetto della sicurezza: advisories, patch dei vendor, news, statistiche sugli attacchi correnti, virus, ricerche in rete. E' l'home page ideale di un professionista della security.

http://www.securityfocus.com/
Security Focus (ora aquisita da Symantec) e la sua storica mailing list Bugtraq sono un punto di riferimento per chi si occupa di sicurezza informatica. Interessante per gli Advisory, i tool, i Vulnerability Archivi e molte altre risorse.

http://www.sans.org/
Sans Institute è importante per il training e la certificazione sulla sicurezza informatica. Oltre ad un dettagliato programma di corsi fornisce numerose informazioni e risorse: statistiche sule vulnerabilità più sfruttate e gli errori più comuni, template predefiniti di policy aziendali per vari aspetti della sicurezza e altro.

http://isc.incidents.org/
Internet Storm Center (Incidents.org) è un interessante sito dove si possono visualizzare statistiche in tempo reale sugli attacchi correnti più comuni, su quali IP sorgenti e destinazione sono utilizzati ecc.
Comodo anche per verificare se qualcuno sta usando un nostro IP per eseguire attacchi in rete (evidente sintomo di compromissione del proprio sistema).

http://www.packetstormsecurity.org
PacketStorm è uno dei punti di riferimento più noti per l'underground digitale. Contiene news e informazioni oltre ad un completo ed aggiornato elenco di exploit e hacking tools direttamente scaricabili.

http://www.linuxsecurity.com
Linux Security è uno dei più completi siti fra quelli espressamente dedicati alla sicurezza su Linux. Fra le altre informazioni riporta i Security Advisory delle principali distribuzioni.

Siti sulla sicurezza in italiano

Autore: al - Ultimo Aggiornamento: 2003-04-14 15:57:28 - Data di creazione: 2003-04-14 15:57:28
Tipo Infobox: DESCRIPTION - Skill: 1- NOVICE

Fra i vari siti in lingua italiana che trattano di sicurezza si segnalano.

Portazero - http://www.portazero.info
News aggiornate e articoli interessanti sulla sicurezza.

Infosecurity - http://www.infosecurity.it
Una delle più importanti fiere in Italia esclusivamente dedicata all'Information Security

Sikurezza.org - http://www.sikurezza.org/
Home page di alcune delle più diffuse mailing list sulla sicurezza in italiano.

ClusIT - http://www.clusit.it/
Home Page della ASSOCIAZIONE ITALIANA PER LA SICUREZZA INFORMATICA, con documenti vari.

Bismark - http://www.bismark.it/
Portale su undeground, hacking e sicurezza informatica.

Viaggio minimo nell'underground digitale

Autore: al - Ultimo Aggiornamento: 2003-05-08 13:32:23 - Data di creazione: 2003-05-08 13:32:23
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Ogni system administrator attento alla sicurezza dei propri sistemi dovrebbe conoscere il più possibile l'underground digitale, un variopinto mondo dove si intrecciano, ma non necessariamente si mischiano, attività illegali e slanci ideologici, arte e cultura cyberpunk e attivismo digitale, ricercatori di porno/warez e hacker nudi e puri che mai si sognerebbero di cercare di entrare su sistemi altrui.
In questo marasma esistono gruppi, slogan, sigle, gerghi, nicknames, codici etici, party, raduni, rivalità, alleanze.
In termini di sicurezza è utile trovare le risorse effettivamente utili, gli strumenti e le informazioni usati dai cracker, cercando di sfuggire all'invasione di porno/warex popup che si scateno cliccando da Astalavista in poi.

AntiOnline - http://www.antionline.com/
Ottimo punto di partenza per forum, informazioni, tools, exploits, news dall'underground digitale.

2600 - http://www.2600.com/
Storica magazine di hacking, phreaking e cultura underground.

Phrack - http://www.phrack.org/
Altra storica newszine sulle varie forme di hacking e hacktivism.

Attrition - http://www.attrition.org/
Informazioni e strumenti su hacking e altro.

HERT - http://www.hert.org/
Hacker Emergency Response Team, la risposta di veri hackers al più ingessato CERT

ZONE-H - http://www.zone-h.com/
News, informazioni e un completo archivio di defacing fatti nel mondo.

Oltre ai siti web pubblici esistono luoghi di ritrovo, reali e virtuali, in cui ci si scambiano informazioni e tecniche, nuovi exploit e informazioni riservate. Possono essere lan party o irc rooms, bbs o chat, ovunque informazioni e scambi di opinione possono fluire ed intrecciarsi.


Network security


Linux Internetworking

Overview del networking su Linux

Configurare la rete su Linux

Autore: al - Ultimo Aggiornamento: 2002-09-29 10:47:14 - Data di creazione: 2002-09-29 10:47:14
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Tipicamente la configurazione di un host in rete prevede pochi dati fondamentali: Indirizzo IP, subnet mask, default gateway e DNS server.

Esistono molteplici metodi per configurare il servizio di rete in Linux, molto di quanto viene qui riportato si applica a tutti gli Unix:
- editare i singoli file di configurazione del networking (ristartare il servizio per applicare le modifiche);
- usare comandi shell come ifconfig, route
- utilizzare strumenti di configurazione con interfaccia a finestra come netconfig, linuxconf, webmin e altri facilmente individuabili su desktop KDE o GNOME.

File di configurazione:
/etc/sysconfig/network  Contiene le principali configurazioni per il Networking: hostname, domainname, default gateway (tipico di RedHat).
/etc/sysconfig/network-script/ifcfg-XXX Directory contenente i file di configurazione delle singole interfacce (tipico di RedHat).
/etc/hosts Contiene il mapping statico fra indirizzi e hostname ed alias. Segue un esempio.
/etc/services Contiene il mapping tra i numeri di porta e i nomi dei servizi.
E' un file che solitamente non si modifica, salvo l'aggiunta di porte e protocolli custom.
/etc/host.conf Specifica l'ordine secondo il quale il sistema effettuerà la ricerca di informazioni per risolvere gli indirizzi. Usato dalla resolver library in sistemi con libc versione 5.
order hosts,bind ; specifica di usare prima /etc/hosts e poi il DNS per risolvere gli IP.
/etc/nsswitch.conf Stessa funzione di host.conf nei sistemi con libc versione 6 (glibc). In pratica è sempe meglio avere entrambi i file correttamente configurati.
/etc/resolv.conf File di configurazione del client DNS ovvero contiene gli indirizzi del server DNS e un possibile dominio dell'host e l'ordine di ricerca

Comandi comuni
Tipicamente su Linux e su Unix i comandi che bastano per configurare la rete (con privilegi da root (sono:
ifconfig [interface] [options] | address Permette di configurare le interfacce di rete dell'host. Es: ifconfig eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255 up. NOTA: Non esiste nessun controllo sulla corrispondenza fra netmask e broadcast.
route [ opzioni ] [comando] [parametri] Permette di manipolare la tabella di routing del kernel. Es: route add -net 0.0.0.0/0 gw 192.168.0.1
/etc/init.d/network Script di avvio/stop del networking. Es: Per riavviare il subsystem rete dopo una riconfigurazione basta scrivere /etc/init.d/network restart.
ip [ opzioni ] oggetto { comando } Comando estremamente potente e flessibile disponibile a chi ha installato i tool iproute2
E' possibile associare più indirizzi ip appartenenti alla stessa rete su un'unica interfaccia, ovvero è possibile associare più Alias a interfacce di rete.

netstat

Autore: neo - ( Revisione: al ) - Ultimo Aggiornamento: 2004-05-23 16:10:35 - Data di creazione: 2004-05-23 16:10:35
Tipo Infobox: COMMANDS - Skill: 2- JUNIOR

Netstat è un comando polifunzionale che ti permettere di verificare le connessioni, le route e statistiche del proprio sistema. Un comando che ogni sys adm deve conoscere alla perfezione, utile per diagnostica e controllo del sistema.

netstat [information-type] [options]
netstat {--help|-h} Richiama l'help

Per selezionare il tipo di informazioni da visualizzare, bisogna mettere come primo argomento una delle seguenti opzioni. Se non si specifica nulla il comando visualizzera' la lista delle socket aperte, opzione di default.

Information Type
--route , -r Visualizza le route impostate sul sistema
--groups , -g Visualizza informazioni riguardanti i multicast group membership (ipv4 e ipv6)
--interface=iface , -i Visualizza le statistiche di tutte le interfacce o della singola interfaccia specificata
--masquerade , -M Verifica le connessioni che hanno subito masquerading
--statistics , -s Visuallizza un sommario di statistiche

Options
--verbose , -v Abilita il verbose mode.
--numeric , -n Non risolve gli Ip e il numero delle porte, risparmiando i tempi per query DNS.
--protocol=family , -A Opzione per  specificare l'address family quando si vuole visualizzare le connessioni.
-c, --continuous Esegue il comando ogni secondo (o ogni intervallo di secondi specificato).
-p, --program Mostra il PID, ed il nome del programma proprietario della socket. Utile per capire, per esempio, quale programma utilizza una specifica porta TCP.
-l, --listening Mostra solo le conessioni in LISTENING
-a, --all  Mostra tutte le connessioni (LISTENING e non), se abbinato al flag -i visualizza  le informazioni per tutte le interfacce

Network troubleshooting - Introduzione

Autore: al - Ultimo Aggiornamento: 2002-10-16 23:13:18 - Data di creazione: 2002-10-16 23:13:18
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Diagnosticare problemi di rete è attività che difficilmente si spiega a parole.
Per essere in grado di affrontare problematiche di rete complesse (ma anche quelle relativamente triviali) sono necessari diversi skill, non tutti tramandabili facilmente:

1 - Solide basi teoriche e conoscenza dello stack TCP/IP.
Inutile fingere, si deve poter diagnosticare in fretta un problema di DNS rispetto a quello dovuto ad un cavo scollegato, un problema di routing rispetto ad un problema dovuto a troppi errori su una interfaccia.
Per farlo, a prescindere dai sistemi usati, è sempre necessario avere in mente network layers e protocolli.

2 - Esperienza.
Come sempre, i trucchi migliori sono quelli che si acquisiscono sul campo e la familiarità con ambienti e dispositivi specifici ci rende più efficaci e rapidi nelle scelte e nelle implementazioni.

3 - Conoscenza degli strumenti a disposizione.
Qui possiamo dare qualche indicazione utile, valida per quasi tutti gli Unix e anche sistemi Windows:
- ping, traceroute, telnet sono utili per diagnosticare problemi di raggiungibilità di sistemi remoti
- ifconfig, route servono per identificare la configurazione di rete corrente ed evidenziare routing particolari o problemi di errori a livello di interfaccia fisica.
- arp e le arp cache sono sempre da considerare quando si cambia IP di una macchina o la macchina associata ad un IP
- netstat è uno strumento flessibile per identificare connessioni di rete attive e errori e statistiche di traffico su IP, TCP, UDP e ICMP.
- tcpdump, snoop e altri sniffer sono fondamentali quando si devono analizzare nel dettagli dei flussi di pacchetti in rete
- nslookup e dig sono fondamentali per diagnosticare problemi di DNS.

arp

Autore: neo - Ultimo Aggiornamento: 2002-10-12 20:02:55 - Data di creazione: 2002-10-12 20:02:55
Tipo Infobox: COMMANDS - Skill: 2- JUNIOR

Comando che ti permette di visualizzare e manipolare le voci di arp nella cache del sistema.
Come la maggior parte dei comandi relativi alla network ottiene informazioni dal proc file-system (/proc/net/arp)

Visualizzazione del contenuto di tutta la cache, oppure specificando l'host solo l'arp del suddetto host
arp [opzioni]  -a [hostname]
Cancellazzione dell'arp di uno specifico host
arp [opzioni]  -d hostname
Creazione manuale di uno specifico arp di un host
arp  [opzioni] -s hostname hw_addr [opzioni]

Options
-v, --verbose Abilita il verbose mode
-n, --numeric Non esegue il DNS lookup degli indirizzi ip
-H type, --hw-type type, -t type Specifica quale classe di arp deve visualizzare,cancellare inserire. ( ARCnet (arc­net) , PROnet (pronet) , AX.25 (ax25)  and  NET/ROM (netrom). Default=ether)
-i If, --device If Specifica l'interfaccia
-e Visualizza il risultato in linux standard

ifconfig

Autore: fargo - ( Revisione: al ) - Ultimo Aggiornamento: 2002-10-16 19:36:13 - Data di creazione: 2002-10-16 19:36:13
Tipo Infobox: COMMANDS - Skill: 2- JUNIOR

Ifconfig serve essenzialmente a configurare l'indirizzo ip di un'interfaccia di rete, tipicamente una ethernet.
Un computer può avere più di un indirizzo IP. Ad ogni interface può corrispondere uno o più indirizzi IP.
per esempio potremmo avere un computer con due ethernet interface e avremmo quindi una eth0 e una eth1 (quindi due indirizzi), ma potremmo avere anche degli alias, quindi eth0:1, eth0:2 e così via.

Con ifconfig si possono configurare altri aspetti di un'interface, anche se molti parametri saranno difficilmente cambiati. Per esempio si possono cambiare e MTU e metrica, abilitare o disabilitare il multicast e la modalità promiscqua (di solito attivata automaticamente da programmi di sniffing). Sulla manuale (man ifconfig) si possono trovare queste opzioni, che consiglio di leggere.
Sicuramente i comandi dati sono sufficienti ad una configurazione standard.

Vediamo una panoramica dei principali comandi per utilizzare ifconfig:

ifconfig [interface] options | address
ifconfig -a mostra la configurazione IP di tutte le interface. Su molti sistemi è sufficiente digitare ifconfig, senza l'opzione -a. Un esempio dell'output di ifconfig può essere questo (i commenti spiegano le varie righe):
eth0      Link encap:Ethernet  HWaddr 00:50:8B:B0:15:7F
          indica il tipo di hardware e il suo indirizzo fisico (MAC address)
              inet addr:192.168.0.1  Bcast:192.168.1.255  Mask:255.255.255.0
          indica indirizzo IP, indirizzo di broadcast e maschera della rete.
             UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
            Indica lo stato (UP) e le opzioni attive (accetta broadcast e multicast) l'MTU e la Metrica.
              RX packets:2590603 errors:0 dropped:0 overruns:0 frame:0
            TX packets:2713120 errors:0 dropped:0 overruns:1 carrier:0
            collisions:0 txqueuelen:100
            RX bytes:987732693 (941.9 Mb)  TX bytes:1198865677 (1143.3 Mb)

          Mostra le statistiche in ricezione (RX) e trasmissione (TX)
            Interrupt:12 Base address:0x6100
            Mostra l'indirizzo hardware della scheda

ifconfig interface mostra la configurazione della interface specificata. Per esempio ifconfig eth0.
ifconfig interface ip netmask broadcast up/down attiva disattiva una determinata interface. Con questo comando possiamo facilmente configuare e attivare una interface. Questo si applica sia come indirizzo primario che come alias, consentendoci di creare più alias alla stessa interfaccia.

Vediamo qualche esempio:
ifconfig eth0 192.168.0.1 up assegna l'indirizzo IP 192.168.0.1 e attiva l'interface (di default viene assegnata la classe C in questo caso, che sarebbe stata una classe A se avessimo usato 10.0.0.1)
ifconfig eth0:1 192.168.0.1 up assegna l'indirizzo IP 192.168.0.1 alla eth0:1 e attiva l'interface. Eseguendo questo comando di fatto assegniamo un'altro indirizzo IP alla interface.
ifconfig eth0 192.168.0.1 netmask 255.255.255.128 broadcast 192.168.0.127 up assegna l'indirizzo IP 192.168.0.1 e attiva l'interface, creando una mask 192.168.0.0/25 (In questo modo la Classe C è divisa in due subnet di 126 indirizzi) e assegnando come indirizzo di broadcast 192.168.0.127.

tcpdump

Autore: neo - Ultimo Aggiornamento: 2003-04-04 22:44:28 - Data di creazione: 2003-04-04 22:44:28
Tipo Infobox: COMMANDS - Skill: 3- INTERMEDIATE

Tcpdump è un ottimo sniffer che permette di monitorare il traffico di rete con filtri flessibili per limitare l'output a video secondo varie regole di matching di pacchetti.

tcpdump [ options ] [ expression ]
-a Tenta di risolvere  network e broadcast address
-c [count] Esegue l'exit dopo aver raccolto tot pacc
-F [file] Specifica di utilizzare un file in input per le expression
-i Specifica l'interfaccia da cui sniffare
-n Non risolve gli indirizzi ip
-nn Non risolve ne gli ip ne il numero delle porte
-p Non abilita il promiscuous  mode sull'interfacce da cui tcpdump e' in ascolto
-v,-vv,-vvvAbilita il verbose mode
-x Printa ogni paccheto sniffato

Le expression servono per limitare il matching dei pacchetti
proto Specifica il protocollo [tcp,udp,ether etc...]
dst host [host] Specifica l'host di destinazione dei pacchetti
dst net Specifica la network di destinazione dei pacchetti
dst port Specifica la porta di destinazione dei pacchetti
src host [host] Specifica l'host sorgente dei pacchetti
src netSpecifica la network sorgente dei pacchetti
src port Specifica la porta sorgente dei pacchetti
`!' o `not' Simbolo di negazione, ovvero inverte il matching
`&&' or `and' Simbolo di concatenazione, visualizza il pacchetto che fa il match di tutte le regole concatenate
`||' or `or Simbolo di alternanza, visualizza il paccheto o con questa opzione o con quest'altra

route

Autore: al - Ultimo Aggiornamento: 2002-10-24 13:47:12 - Data di creazione: 2002-10-24 13:47:12
Tipo Infobox: COMMANDS - Skill: 2- JUNIOR

Route è il comando Linux che viene utilizzato per manipolare le tabelle di routing. Permette di aggiungere ed eliminare route statiche e default gateway, oltre che semplicemente visualizzare la tabella di routing di un sistema.
Non è comune in altri Unix.

route add [-net|-host] indirizzo [gw gateway] [netmask netmask] [mss mss] [metric metric] [dev device]
route del indirizzo

Per aggiungere una route statica per un'intera rete si usa l'opzione add e si devinisce la rete con -net. Per esempio:
route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.0.0.254
Aggiunge una route statica per la rete 192.168.0.0/24 usando come gateway 10.0.0.254.

Per impostare il default gateway si può digitare qualcosa come:
route add -net 0.0.0.0 netmask 0.0.0.0 gw 10.0.0.1 oppure:
route add default gw 10.0.0.1


Per cancellare una route esistente basta indicare il nome della rete:
route del -net 192.168.0.0

Per visualizzare la tabella di route basta: route, se si vuole evitare il reverse lookup degli IP e velocizzare l'operazione scrivere: route -n

Per visualizzare la cache del sistema sulle route usate: route -C


Network scanning: strumenti e tecniche

Strumenti e tecniche di network e vulnerability scanning. Information gathering.

Conoscere come i propri sistemi appaiono in rete

Autore: al - Ultimo Aggiornamento: 2003-04-14 16:20:17 - Data di creazione: 2003-04-14 16:20:17
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Una delle prime operazioni da compiere all'inizio di un security assessment volto a verificare la vulnerabilità dei propri sistemi su Internet (tralasciando momentaneamente ogni considerazione sulle problematiche di sicurezza in senso lato, che comprendono aspetti non solo informatici ma anche logistici e umani) è uno scanning completo delle porte e delle informazioni che da Internet si possono rilevare.

Sapere come i propri sistemi si presentano in rete è infatti il primo fondamentale passo per procedere alla loro protezione dalla maggior parte delle possibili minacce esterne.
Per farlo ci si può mettere nei panni di un potenziale intrusore, che dei nostri sistemi non sa ancora nulla e che, in prima battuta, li può raggiungere solo via Internet.
Le informazioni e le operazioni che si possono fare sono:
- Network scanning di tutti gli indirizzi IP pubblici che ci sono assegnati da un IP arbitrario su Internet. Va fatto un controllo su tutti gli indirizzi, possibilmente non limitandosi ad un ping scan (potremmo avere un firewall perimetrale che ci filtra i pacchetti ICMP) ma provando tutti gli indirizzi delle nostre network pubbliche su tutte le porte TCP e UDP (l'operazione può essere particolarmente lunga, se si ha fretta limitarsi ad uno scan delle prime 1024 porte di ogni host). Per questo tipo di operazioni un software come Nmap è l'ideale, ma esistono valide alternative come Strobe o NetCat.
- DNS info gathering tramite query DNS sul proprio e su altri server DNS, cercare di ottenere il maggior numero di informazioni sulle macchine dei nostri domini, provare a fare un trasferimento di zona da un server remoto (non dovremmo renderlo possibile) e verificare se le informazioni esposte possono essere di natura delicata (nomi delle macchine troppo indicativi delle loro funzioni, dettagli aggiuntivi sugli host ecc). Per diagnosticare problematiche e raccogliere informazioni sul DNS possono essere usati programmi come nslookup o dig.
- Whois query e ricerca di info in rete per vedere quanto di noi si trova in rete. Partire da una query whois per uno dei nostri domini o blocchi di indirizzi, poi provare a cercare il proprio nome, così come appare nei campi whois, su Google e altri motori. Provare a cercare altre parole chiave che in qualche modo possono essere riconducibili agli amministratori dei propri sistemi, alla propria società o a qualsiasi altro aspetto in qualche modo riconducibile a noi.
Valutare se le informazioni trovate possono fornire spunti interessanti o notizie utili per chi ci vuole attaccare, prendere eventualmente provvedimenti (discorso vago, che richiede più ampia trattazione, in particolare per tutto quello che riguarda possibili attività di social engineering e come il proprio personale è educato al riguardo).
Verificare inoltre se le password che si utilizzano sono in qualche modo riconducibili alle informazioni che ci riguardano che trapelano in rete (interessi personali, abitudini, nomi di parenti, indirizzi ecc).
- Vulnerability scanning di tutta la nostra rete. E' un controllo più approfondito di un semplice port scanning, in quanto per ogni porta aperta si eseguono verifiche sulle versioni dei software che le gestiscono e sulle loro eventuali vulnerabilità. Tipicamente un software che esegue simili controlli (nel mondo opensource Nessus è il più comune e Satan/Saint sono piuttosto noti, anche se ormai obsoleti) esegue una serie di test sulla base di un vulnerability database in costante aggiornamento, per cui è opportuno eseguire un controllo sulla base di check aggiornati.

Queste operazioni possono fornirci i primi punti da cui partire per eventualmente provvedere a "tappare" i buchi più evidenti e più facilmente utilizzabili. A questo, inutile dirlo, dovrebbe seguire una analisi più approfondita e a vari livelli sulla sicurezza generale dei nostri sistemi e sui flussi di dati che li interessano.
E' inoltre buona norma rieseguire dei simili controllo ogni qualche mese, per verificare lo stato della situazione.

Information gathering in rete

Autore: al - Ultimo Aggiornamento: 2004-08-07 12:48:10 - Data di creazione: 2004-08-07 12:48:10
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Su Internet è possibile trovare varie ed inaspettate informazioni su persone, società e server, alcune delle quali possono fornire spunti utili ad un potenziale intrusore per definire le sue strategie di attacco e, soprattutto, per portare avanti sottili azioni di social engineering.

WHOIS QUERY
Ogni dominio registrato in rete deve essere associato ad una persona o società identificabili, che ne siano i proprietari e responsabili. Questo nome e altre informazioni anagrafiche di base (fondamentalmente i recapiti su Internet e sul mondo reale) vengono registrate su dei database whois che sono liberamente consultabili su appropriati server.
Esistono molti server whois in rete, spesso rispondono per i dati relativi ad un singolo Top Level Domain (TLD, come .it, .fr ecc) in alcuni casi (domini transnazionali come .com, .net .org ecc.) rispondono per più TLD.
Una query whois, da informazioni piuttosto articolate quali il nome della persone e della società che ha registrato il domini, il relativo indirizzo e numero di telefono (a meno che il registrante non abbia fornito dati falsi), i server DNS autoritari per il domini (quelli dove vengono configurati gli indirizzi IP dei server di quel dominio), la data di registrazione.
Oltre a informazioni relative ad un dominio, tramite whois è possibile ottenere dettagli su chi ha in uso un dato range di indirizzi IP pubblici. I fornitori di TLC solitamente aggiornano questi record con i dati dei loro clienti a cui hanno assegnato indirizzi IP fissi, per cui non è raro vedere i propri dati disponibili su un whois server  pubblico anche se non si è fatto nulla per metterli, se non firmare un contratto per una DSL con IP fisso.
Queste informazioni, seppur dovute, necessarie ed inevitabili, possono aiutare un intrusore nelle sue attività di social engineering per cui va quantomeno verificato cosa viene esposto pubblicamente e ci si dovrebbe assicurare che le informazioni e i recapiti utilizzati siano il più possibile generici.

GOOGLE (e ALTRI MOTORI)
Google è probabilmente il migliore motore di ricerca su Internet, i suoi spider costantemente sondano il web aggiungendo pagine e aggiornando il suo enorme database.
Alcune funzioni di ricerca permettono analisi piuttosto dettagliate e a volte sorprendenti sul contenuto di un sito: non è raro trovare su Google vecchie pagine di un sito indicizzate in passato che ormai non sono più linkate sul sito attuale, ma risultano ancora presenti sullo stesso server web e quindi accessibili da Internet.
Se queste pagine contengono form o parti dinamiche sfruttabili per un cracker, anche il sito apparentemente più sicuro e controllato potrebbe cadere, oltretutto a causa di funzionalità non più utilizzate.
Un buon modo per vedere su Google (ma ovviamente una simile ricerca andrebbe fatta anche su altre search engines) cosa del nostro sito è indicizzato è una query tipo:
site:www.esempio.it e
Questo ricercherà all'interno di www.esempio.it tutte le pagine che contengono la lettera "e" (quindi, presumibilmente, tutte le pagine in assoluto). Notare che si può usare "e" ma non "a", che Google esclude in quanto parola, inglese, troppo comune.
Google è inoltre estremamente efficace per cercare file di password o che rivelano informazioni potenzialmente sensibili  o che indicano la presenza di applicazioni web vulnerabily.
Una fonte interessante e completa di query è il "Googledorks!" sul sito http://johnny.ihackstuff.com/
Ulteriore fonte di informazioni potenzialmente utili è l'Internet Archive in cui è possibile visualizzare com'era un sito e parti di esso nel passato.

NEWSGROUPS ARCHIVES
Tutto quello che scriviamo su un newsgroup viene propagato su migliaia di news server sul globo ed è destinato a rimanere impresso negli archivi di Internet per molti anni, come parole scolpite nella pietra.
Siti come lo stesso news.google.com permettono di eseguire ricerche in tutti i post di molti newsgroup.
Un buon cracker sicuramente proverà ad utilizzare questo archivio per cercare informazioni sugli amministratori dei sistemi che vuole attacccare. Con una whois query ottiene dati quali il nome e l'indirizzo email del riferimento tecnico per il dominio sotto mira, con un po' di ricerche sugli archivi dei newsgroup e sugli stessi motori di ricerca può arrivare ad ottenere una quantità insospettabile di informazioni utili per le sue losche attività.
Fra queste informazioni ci possono essere richieste di chiarimenti o informazioni eseguite dal sysadmin sotto mira, dove eventualmente ha fornito dati interessanti e sfruttabili sulla sua struttura di rete o sui programmi e servizi che vuole utilizzare.
Controllando la signature usata da questo su un post pubblico il cracker può avere informazioni sul numero di telefono del sistemista, sui suoi hobby, sui suoi recapiti. Bisogna sempre ricordarsi che in termini di sicurezza informatica, chi si difende non conosce il suo avversario mentre chi attacca ha molti mezzi per raccogliere informazioni sul suo bersaglio.

Installare, configurare ed utilizzare Nessus

Autore: al - Ultimo Aggiornamento: 2003-05-05 19:09:01 - Data di creazione: 2003-05-05 19:09:01
Tipo Infobox: DESCRIPTION - Skill: 4- ADVANCED

Nessus è probabilmente il più completo ed evoluto strumento di vulnerability scanning disponibile nel mondo open source.
Presenta una struttura modulare, con dei plug-in che possono essere aggiornati per individuare vulnerabilità recenti, ha una logica client-server, in cui il server è l'engine che esegue lo scan vero e proprio e il client è l'interfaccia (disponibile in diversi linguaggi per diversi sistemi operativi) con cui si può configurare una sessione di scan (indirizzi target, tipi di check da eseguire ecc.) da far eseguire sul server.

INSTALLAZIONE
L'installazione di Nessus può essere fatta tramite sorgenti (necessari i seguenti tarball, nell'ordine: nessus-libraries-x.x.tar.gz, libnasl-x.x.tar.gz, nessus-core.x.x.tar.gz, nessus-plugins.x.x.tar.gz) o RPM/DEB.
Esiste anche la comodissima, semplicissima e rischiosa possibilità di eseguire una installazione direttamente via rete con lynx -source http://install.nessus.org | sh che provvede automaticamente a scaricare e compilare il tutto.
I prerequisiti di Nessus sono: disponibilità di GTK (in particolare il package gtk-devel che contiene per il programma gtk-config) per il client su Xwindows, disponibilità di NMAP per le operazioni di scanning, possibilmente presenza di OPENSSL per criptare le comunicazioni fra client e server.
A termine installazione ricordarsi di aggiungere /usr/local/bin e /usr/local/sbin al proprio PATH.

CREAZIONE DEGLI ACCOUNT UTENTE
Per poter eseguire uno scan tramite il server nessus, il client (il front-end disponibile all'utente) deve eseguire un login sulla base di un nome utente/password precedentemente creato.
Per aggiungere nuovi utenti sul server nessus si deve usare il comando nessus-adduser.
Vengono richiesti: login, password, tipo di autenticazione (normale o criptata), regole sugli IP che possono essere scannati dall'utente (lasciare vuoto per non impostare alcuna regola).

CONFIGURAZIONE DEL SERVER NESSUS
Il file di configurazione del demone nessus è di default /usr/local/etc/nessus/nessus.conf. Non sono necessarie particolari modifiche per far funzionare un Nessus compilato con le opzioni di default, in ogni caso fra i parametri configurabili, oltre a PATH vari, ci sono alcune impostazioni sul numero di test simultanei da eseguire, sul range di porte da scannare nonchè sui settaggi utilizzati per il canale criptato fra client e server.

AGGIORNAMENTO DEI PLUGIN
I check eseguiti da Nessus si basano su dei plugin, scrivibili in linguaggi diversi, che vengono regolarmente aggiornati sulla base delle scoperte di nuove vulnerabilità. E' disponibile una comoda utility per aggiornare automaticamente i plugin di nessus:
nessus-update-plugins -v visualizza e scarica gli ultimi aggiornamenti dei plugin di Nessus.

CREAZIONE DEI CERTIFICATI SSL
Prima di poter lanciare nessusd è consigliabile creare i certificati SSL necessari per criptare il traffico client-server.
Eseguire: nessus-mkcert e rispondere alle domande fatte.

ESECUZIONE DEL SERVER
Il server di Nessus può essere finalmente lanciato con nessusd -D, il programma si binda alla porta tcp 1241 ed è pronto per accettare richieste dal client.

ESECUZIONE DEL CLIENT
Lanciare il programma nessus che apre un tool grafico con cui interagire con il server nessus (che può essere sulla stessa macchina o sua una macchina remota).
Nella finestra che compare è innanzitutto necessario eseguire il login dalla finestra NESSUSD HOST (selezionare pure l'opzione di default su come gestire il certificato SSL).
Nella finestra PLUGINS selezionare quali security check eseguire. E' possibile selezionarli tutti tranne, o anche escludere quelli potenzialmente pericolosi, in grado di mandare in crash l'host selezionato.
Nella finestra PREFS si può fare un po' di tuning sulle tecniche di scanning da utilizzare, è possibile provare sistemi di evasione per non essere individuati da IDS vari o impostare brute force attacks basati su file di dizionari esterni.
Su SCAN OPTIONS si imposta il range di porte e altri parametri configurabili anche nel file di configurazione generale.
Nella finestra TARGET SELECTION si sceglie l'indirizzo IP o il nome dell'host da esaminare (se ne possono impostare più di uno separandoli con una virgola o si può definire una network tipo 10.0.0.0/24).
Per lanciare lo scan cliccare su START THE SCAN e aspettare il report sulle vulnerabilità note (da Nessus) presenti sul target selezionato.

Considerare che:
- Nessus non è stato pensato come tool per wannabe cracker
- Nonostante le tecniche di evasione utilizzate è probabile che un simile scan venga notato e registrato in qualche log sugli host target (l'IP registrato è quello del server, l'host su cui gira il demone Nessus)
- Alcune segnalazione di warning o alert si basano o su assunzioni relativamente paranoiche o su condizioni che di fatto  non esistono sul server interessato ("falsi positivi")
- Studiare i report di Nessus e le descrizioni sui buchi trovati è un buon metodo per iniziale a familiarizzare con il mondo variegato dei "Security Alert", che spesso oltre a descrivere il buco trovato, indicano le soluzioni su come correggerlo.
- E' bene abituarsi a lanciare regolarmente un Nessus con i plugin aggiornati sui propri server.

Installare ed usare NMAP

Autore: maxgrante - ( Revisione: al ) - Ultimo Aggiornamento: 2003-04-14 17:23:38 - Data di creazione: 2003-04-14 17:23:38
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Nmap è un port scanner avanzato e performante per sistemi Unix, solitamente installato di default su parecchie distribuzioni Linux. L'interfaccia presentata all'utente è di tipo testuale e richiede spesso i privilegi di root per poter utilizzare componenti critiche del Kernel (come i raw socket).
Il risultato che fornirà nmap sarà una lista di porte aperte, chiuse o filtrate presenti sull'host o sulla rete indicati.

Per testare se nmap è presente sul proprio Linux si può utilizzare rpm (rpm -qa | grep nmap) o comandi quali whereis o locate.
Nel caso fosse necessario installarlo si può procedere tramite rpm precompilati (in genere su http://www.rpmfind.net sono reperibili tutti gli rpm del caso, ad esempio nmap-3.00-1.i386.rpm per RedHat 8.0), o direttamente compilando i sorgenti.

INSTALLAZIONE DI NMAP TRAMITE COMPILAZIONE DEI SORGENTI
Per installare nmap dai sorgenti bisogna innanzitutto ottenere l'ultima release stabile di questi ultimi dal sito ufficiale.
Successivamente una volta scaricati i sorgenti si procede con il classico scompattamento del tarball (tar -zxvf namp...tar.gz) e la compilazione e installazione con i comandi in sequenza:
./configure
make
make install

Ricordarsi di aggiungere /usr/local/bin al proprio PATH

UTILIZZO DI NMAP
A dispetto della semplicità di installazione e configurazione (praticamente inesistente), nmap è un tool molto potente e ricco di opzioni per lo scanning di host o reti

La sintassi di base:
nmap [Tipo(i) di scan] [Opzioni] <host/rete> <host/rete> <host/rete> ...

Le principali opzioni:
-sT
E' il sistema di scanning più semplice in quanto utilizza la chiamata di sistema connect() del proprio sistema operativo. Ha il vantaggio di poter essere utilizzata anche senza privilegi di root ma permette una facile individuazione da parte dell'host di destinazione.

-sS TCP SYN SCAN
E' un sistema più avanzato di scanning che permette l'invio di un SYN per simulare il tentativo di connessione TCP, nel caso l'host risponda con un ACK significa che la porta è in ascolto e pertanto è possibile inviare un RTS per chiudere il tentativo di connessione appena tentato. Il vantaggio è che in assenza di IDS specifici, questi tentativi di connessione non vengono loggati, lo svantaggio è che bisogna avere privilegi di root per poter eseguire uno scan di questo tipo.

-sF -sX -sN
Scanning stealth avanzato. Questi tipi di scan utilizzano sistemi alternativi e a volte deduttivi per identificare le porte aperte limitando la possibilità di essere individuati.
La logica seguita da questi metodi di scan per passare inosservati sono i seguenti:
Le porte chiuse devono rispondere allo scanning con un RTS, mentre le porte aperte devono ignorare lo scan. L'inconveniente è che sistemi come Microsoft, Cisco, HP/UX e altri non supportano questi standard.

-sP
Ping scan. Assolve alla necessità di sapere quali host sono attivi in una rete, tramite un semplice ECHO REQUEST (ping) agli host specificati. E' utile per verificare quali host sono attivi su un segmento di rete specificato, ma può dare risultati incompleti se a monte degli indirizzi di destinazione c'è un firewall che filtra i pacchetti ICMP.

-sU UDP scans
Questa opzione permette di controllare tramite l'invio di un pacchetto UDP di 0 byte se una porta UDP è aperta, se la risposta a questo pacchetto sarà un ICMP che dice Network Unreachable la porta è chiusa, in caso contrario si pensa che sia aperta.

-O Fingerprinting
Esegue un fingerprinting per riconoscere, tramite sottigliezze e differenze nello stack di rete del sistema operativo dell'host remoto, quale OS e quale versione viene utilizzata. I risultati sono spesso corretti ma non infallibili.

-v Verbose mode
Questa è una opzione fondamentale per poter scoprire molteplici informazioni. Se si utilizza l'opzione -vv si aumenta ulteriormente la verbosità dell'output.

-o <logfilename>
Inserendo questa opzione avremo la possibilità di scegliere come argomento il nome di un file in cui NMAP andrà a scriverci il risultato della scansione (Il formato del file è di tipo HUMAN READABLE)

-m <logfilename>
Esegue la stessa cosa dell'opzione precedente tranne che per il fatto che l'output generato è di tipo MACHINE READABLE

-p <range porte>
Permette di inserire un range di porte da scannare (es. -p 25 scannerà esclusivamente la porta SMTP (25))

-F Fast scan
Scan veloce, permette di scansionare tutte le porte presenti nei services di NMAP (in pratica le well known ports) anzichè tutte le porte dalla 0 alla 65535.


Network sniffing: strumenti e tecniche

Teoria e pratica sulla subdola arte dello sniffing. Anti-sniffer tools. Arp spoofing e tecniche di prevenzione.

Sniffing di pacchetti in rete

Autore: al - Ultimo Aggiornamento: 2003-05-07 12:03:48 - Data di creazione: 2003-05-07 12:03:48
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

L'attività di monitorare i pacchetti di rete che arrivano al proprio computer si chiama sniffing.
Ogni sistema su una rete IP scambia informazioni con altri sistemi tramite singoli pacchetti che hanno un IP sorgente e un IP destinazione. Tipicamente un computer analizza e processa solo i pacchetti che arrivano al suo dispositivo di rete (una scheda ethernet, un modem ecc.) che hanno come IP di destinazione il proprio o che sono pacchetti di broadcast, indirizzati cioè ad ogni indirizzo IP attivo nello stesso network IP.

L'attività di sniffing il più delle volte è necessaria per monitorare e diagnosticare problematiche di rete ma può essere impropriamente utilizzata per intercettare informazioni sensibili di terzi, come login e password di accesso ad un determinato servizio.
Si possono sniffare pacchetti su ogni interfaccia di rete, ma tipicamente viene fatto su una scheda ethernet, per la quale possono esistere due tipi di ambienti tipici:
- Rete shareata, dove tutte le schede di rete dei computer nella rete locale ricevono TUTTI i pacchetti, anche quelli destinati ad altri indirizzi IP. In questo caso (rete ad anello con cavo coassiale oppure rete a stella con un hub centrale) le schede di rete dei PC normalmente selezionano solo i pacchetti destinati a loro e scartano tutti gli altri che attraversano il mezzo trasmissivo a cui sono collegati.
- Rete switchata, dove ogni PC riceve solo i pacchetti di broadcast o quelli destinati al proprio IP. Questa è tipicamente una rete a stella con uno switch al centro, che provvede autonomamente a forwardare ad ogni sua singola porta solo i pacchetti destinati all'IP del dispositivo collegato a quella porta, oltre ai broadcast, che vengono sempre propagati su tutte le porte.

Nel primo caso l'attività di sniffing permette di analizzare anche pacchetti destinati e originati da indirizzi terzi, ampliando notevolmente le possibilità di intercettare informazioni sensibili.
In una rete switchata, invece, quando si prova a sniffare i pacchetti che passano per l'interfaccia di rete, si possono solo incontrare pacchetti originati dal o destinati al computer locale, oltre ai soliti broadcast.
Esiste tuttavia una tecnica piuttosto evoluta (arp spoofing) tramite la quale è possibile sniffare pacchetti di terzi anche in una rete switchata.

Quando si vogliono sniffare pacchetti destinati a terzi, si deve impostare il "PROMISCUOUS MODE" sull'interfaccia di rete, in modo da farle processare tutti i pacchetti indifferentemente.

Esistono diversi strumenti di sniffing, alcuni sono esplicitamente realizzati per attività di hacking (Sniffit, Ettercap, Dsniff...) e evidenziano le login e le password che sono state intercettate, altri sono più orientati alla risoluzione di problematiche di rete (Ethereal, simile al Windows Network Monitor) e permettono l'analisi di tutti i pacchetti intercettati, altri hanno funzioni di monitoring e analisi a volte limitandosi a considerare solo le intestazioni dei pacchetti (tcpdump, snoop, iptraf, ntop).

Il motivo principale per cui si preferisce cercare di criptare ogni passaggio di login e password in rete (https, ssh, pop3s, sftp ecc.) è proprio per evitare che qualcuno, tramite sniffing, li possa intercettare e facilmente scoprire.

Tcpdump - Installazione ed uso

Autore: al - Ultimo Aggiornamento: 2003-01-30 16:56:40 - Data di creazione: 2003-01-30 16:56:40
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE

Tcpdump è uno strumento di sniffing particolarmente flessibile e diffuso nel mondo Linux. E' simile a snoop, più diffuso su Solaris, e permette di analizzare il tipo di pacchetti che passano per l'interfaccia di rete specificata.
Va sottolineato che tcpdump NON visualizza il contenuto dei pacchetti ma solo le loro intestazioni (protocollo, IP sorgente, destinazione, porte ecc.) per cui si presta bene alla diagnostica di problemi di networking ma non ad una attività di cracking.

INSTALLAZIONE
Per funzionare tcpdump richiede le librerie libpcap che possono essere scaricate dal sito ufficiale di tcpdump.
La procedura di installazione, sia per libpcap che tcpdump è quella standard (./configure ; make ; make install ). Per il corretto funzionamento su diversi Unix flavour sono necessari alcuni specifici adattamenti. Su Linux, per esempio, il kernel deve essere compilato con la funzione packet socket (CONFIG_PACKET=y) e tcpdump deve essere lanciato da root.

USO
Tcpdump prevede numerose e flessibili opzioni per definire quali pacchetti sniffare e come farlo.
Il suo output dipende dal protocollo e viene visualizzata una riga per ogni datalink frame intercettato.
Il man ufficiale è dettagliato e ben documentato, riportiamo qui alcune opzioni interessanti.
tcpdump - Senza opzioni tcpdump visualizza a schermo tutti i pacchetti che passano sull'interfaccia predefinita (di solito eth0)
tcpdump -i ppp0 -c 50 - Visualizza 50 pacchetti (-c 50) sull'interfaccia ppp0 (-i ppp0) e poi esce.
tcpdump -l | tee sniff.log - Mentre visualizza i pacchetti li mette in un buffer (-l) che viene scritto sul file sniff.log.
tcpdump -e -n - Visualizza gli indirizzi del data link (-e) e non prova a fare un DNS reverse lookup (-n) velocizzando l'output.
Le regole per identificare il tipo di pacchetto da visualizzare sono molto flessibili e adattabili a diverse necessità. Vediamo alcuni esempi
tcpdump port 80 - Visualizza solo i pacchetti che hanno come sorgente o destinazione la porta 80 (port 80).
tcpdump host 192.168.0.150 - Visualizza solo i pacchetti che hanno come IP sorgente o destinazione 192.168.0.150.
tcpdump host 10.0.0.150 and not port 22 - Visualizza solo i pacchetti relativi all'host 10.0.0.150 che non usino la porta ssh (and not port 22).
tcpdump net 10.0.0.0/24 and port 22 - Visualizza tutti i pacchetti per la rete 10.0.0.0/24 relativi al protocollo ssh (and port 22)

Ettercap - Sniffer per ambienti switchati

Autore: al - Ultimo Aggiornamento: 2003-01-30 16:16:17 - Data di creazione: 2003-01-30 16:16:17
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE

L'impossibilità di analizzare traffico con sorgente e destinazione diversi da quelli locali è una tipica limitazione degli sniffer normali quando vengono utilizzati in ambienti switchati, dove, cioè, lo switch di rete provvede ad inoltrare su ogni singola porta solo i pacchetti per gli host direttamente connessi alla porta stessa, oltre ai broadcast che vengono propagati a tutte le porte (o quantomeno a tutte le porte della stessa VLAN).

Ettercap, sviluppato da due programmatori italiani, è uno sniffer evoluto che permette di sniffare tutto il traffico anche in reti in cui è presente uno switch, con una attività di arp cache poisoning (vengono mandate arp reply finte, che associano il mac address della macchina su cui gira ettercap agli IP sorgente e destinatario, rispettivamente al destinatario e al sorgente), tramite la quale si frappone fra macchine ignare e la macchina bersaglio (che può essere un server o il default gateway di una rete).
Ettercap inoltre offre una serie di feature che fanno la gioia di ogni hacker:
- SSH 1 e HTTPS password sniffing;
- Password collection per una moltidutide di protocolli;
- OS fingerprinting per il riconoscimento dei sistemi operativi sugli Host trovati in rete;
- Possibilità di killare una connessione o inserire caratteri estranei;
- Supporto di plugin vari che a loro volta presentano features quali DNS spoofing, PPTP sniffing,

INSTALLAZIONE
./configure
make
make install
make plug-ins
make plug-ins_install

Il binario ettercap è copiato di default in /usr/local/sbin

USO
All'avvio di ettercap esegue un rapido scan degli host presenti nella rete locale (viene fatto un aarp request per ogni IP della rete e non un semplice ping a tutti gli IP o al broadcast) e ne presenta una lista a video.
Su questa lista è possibile selezionare gli IP sorgenti e destinatari da monitorare e si possono visualizzare le molteplici potenti opzioni con il tasto h.
Esistono diverse modalità di sniffing: IP based (s), MAC based (m) e ARP poisoning based (a), quella più devastante, in grado di sniffare in ambienti switchati.
Sempre dalla finestra principale, in cui si visualizzano tutti gli IP in rete è possibile identificare i sistemi operativi utilizzati ((f)), fare puro Arp poisoning senza sniffare (j), creare pacchetti custom (x), eseguire uno dei tanti (potentissimi) plugin distribuiti con il tarball ufficiale (p), fare uno scanning passivo, basandosi solamente sugli host per cui c'è traffico (o) controllare se ci sono in rete altri arp cache poisoners (c, notare che sulle macchine bersaglio è possibile accorgersi che qualcosa non va con il semplice comando arp e cercando se esistono diversi IP in rete con lo stesso MAC address).
Tutte queste opzioni a loro volta aprono una successiva finestra che può presentare dei comandi specifici. Utilizzare sempre h per un HELP e q per tornare alla finestra precedente.

tcpdump

Autore: neo - Ultimo Aggiornamento: 2003-04-04 22:44:28 - Data di creazione: 2003-04-04 22:44:28
Tipo Infobox: COMMANDS - Skill: 3- INTERMEDIATE

Tcpdump è un ottimo sniffer che permette di monitorare il traffico di rete con filtri flessibili per limitare l'output a video secondo varie regole di matching di pacchetti.

tcpdump [ options ] [ expression ]
-a Tenta di risolvere  network e broadcast address
-c [count] Esegue l'exit dopo aver raccolto tot pacc
-F [file] Specifica di utilizzare un file in input per le expression
-i Specifica l'interfaccia da cui sniffare
-n Non risolve gli indirizzi ip
-nn Non risolve ne gli ip ne il numero delle porte
-p Non abilita il promiscuous  mode sull'interfacce da cui tcpdump e' in ascolto
-v,-vv,-vvvAbilita il verbose mode
-x Printa ogni paccheto sniffato

Le expression servono per limitare il matching dei pacchetti
proto Specifica il protocollo [tcp,udp,ether etc...]
dst host [host] Specifica l'host di destinazione dei pacchetti
dst net Specifica la network di destinazione dei pacchetti
dst port Specifica la porta di destinazione dei pacchetti
src host [host] Specifica l'host sorgente dei pacchetti
src netSpecifica la network sorgente dei pacchetti
src port Specifica la porta sorgente dei pacchetti
`!' o `not' Simbolo di negazione, ovvero inverte il matching
`&&' or `and' Simbolo di concatenazione, visualizza il pacchetto che fa il match di tutte le regole concatenate
`||' or `or Simbolo di alternanza, visualizza il paccheto o con questa opzione o con quest'altra

Usare tcpdump su una macchina remota

Autore: neo - ( Revisione: al ) - Ultimo Aggiornamento: 2002-10-16 18:51:58 - Data di creazione: 2002-10-16 18:51:58
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE

Quando lanciate il comando tcpdump, su una macchina remota con una sola interfaccia oppure dovete sniffare il traffico dalla stessa interfaccia da cui avete aperto la connessione, dovrete utilizzare dei filtri per evitare di sniffare il vostro stesso traffico telnet o ssh e ricadere in vorticosi loop che rendono l'opera di analisi dei pacchetti improba.

Se mi collego ad un host remoto con SSH, dovro' sniffare tutto tranne i pacchetti con src e dst port 22
[root@morpheus pub]# tcpdump -i eth0  ! port 22
Kernel filter, protocol ALL, datagram packet socket
tcpdump: listening on eth0
[ Traffico sniffato ]

Per Interrompere Ctrl-c

Se devo sniffare ANCHE pacchetti SSH, ma non quelli generati dalla mia connessione posso scrivere (ipotizzando che il mio IP sorgente sia 10.0.0.10):
tcpdump -n -i eth0  ! host 10.0.0.10
(Notare il -n per evitare che venga fatto un DNS reverse lookup dell'IP 10.0.0.10, rendendo inefficace il filtro)

Arp poisoning detection con Arpwatch

Autore: al - Ultimo Aggiornamento: 2003-06-05 22:18:41 - Data di creazione: 2003-06-05 22:18:41
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE

Arpwatch è un ottimo strumento per monitorare il traffico arp in una rete locale.
L'installazione tramite rpm è estremamente semplice e subito funzionale, basta lanciare il demone arpwatch (viene creato lo script di gestione /etc/rc.d/init.d/arpwatch) per tenere sotto controllo le modifiche dei pacchetti arp nel segmento di rete a cui si è collegati.

L'ideale è installare Arpwatch su un server di monitoring, che rimane sempre acceso, e che intercetta tutti i broadcast arp che arrivano all'interfaccia di rete principale.
Ogni aggiunta di nuovo host o modifica del mac address di un host già aggiunto (sintomo o del cambio della scheda di rete di un computer o del cambio dell'host associato ad un IP o, e questo è l'aspetto più importante, di attività di arp poisoning, tipiche di sniffer per ambienti switchati come ettercap) viene notificato via mail (di default a root) e su syslog.
Alla prima esecuzione è normale ricevere varie mail per tutti gli host in rete, successivamente verranno notificate solo le variazioni e su queste, se non sono previste, è sempre bene indagare.
Nelle notifiche vengono segnalati l'indirizzo IP coinvolto e il vecchio e il nuovo MAC address. Se si ricevono mail che contengono nel titolo le parole FLIP FLOP o Chenge ethernet address è sicuramente il caso di indagare: segnalano una alternanza fra il precedente MAC address associato ad un indirizzo e l'ultimo noto o la modifica del Mac address associato ad un dato IP e possono essere la prova di attività di arp poisoning in rete (o di diversi PC che si alternano in rete con lo stesso IP).

Nella directory /var/arpwatch l'rpm di arpwatch scrive vari file e script tra cui il file dove si registrano le coppie mac:ip (arp.dat) e un database con l'elenco dei vendor a cui sono stati associati i principali prefissi arp (ethercodes.dat, utile anche per altri scopi, ogniqualvolta si cerca di individuare di quale produttore è un dispositivo con un dato mac address).


Linux Firewalling


Linux firewalling: Introduzione a Iptables

Overview, gestione, utilizzo di iptables su Linux per packet filtering

Overview di Netfilter e Iptables

Autore: neo - ( Revisione: al ) - Ultimo Aggiornamento: 2005-05-14 23:11:57 - Data di creazione: 2003-06-04 16:47:04
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Netfilter è il framework con cui vengono gestite tutte le operazioni di firewalling, natting e manipolazione di pacchetti nel kernel Linux.
Netfilter viene gestito con il comando iptables con cui si determinano e configurano tutte le regole con cui gestire il traffico di rete.

Breve storia dei firewall Linux
Il codice di firewalling di Linux ha subito diverse modifiche nella storia del kernel.
Nella versione 2.0.x viene usato il sistema ipfwadm che viene sostituito nelle versione 2.2.x dalle ipchains che introducono il concetto di catene di regole (access-list) a cui un pacchetto può essere indirizzato.
Dalla versione 2.4 in poi il kernel si basa sull'infrastruttura netfilter/iptables che permette con semplicità  estrema di configurare un firewall di fare packet filtering (stateless, statefull), diversi tipi di NAT (Network Address Translation) e packet mangling (modifica di alcuni flag dei pacchetti trattati).
Il progetto NETFILTER/IPTABLES nasce da Paul "Rusty" Russell e dal Core Team (i quali tutt'ora continuano il lavoro di sviluppo), nel lontano 1999.

Componenti
Il framework netfilter/iptables si può identificare in diversi componenti:
1- la parte riguardante il kernel, ovvero tutto il codice che lavora in kernel space e che con diversi moduli introduce funzionalità base e avanzate.
In quasi tutte le distribuzioni netfilter è installato, in alcune specifiche sulla sicurezza possono essere anche installati moduli aggiuntivi sperimentali.
2- L'interfaccia utente, ovvero sostanzialmente il comando iptables che permette di impostare regole e gestire il firewall.
Solitamente fornita con un pacchetto chiamato... iptables.

NetFilter e il firewalling su Linux

Il codice di firewalling nel kernel Linux ha una sua storia:
Nel kernel 2.0 ( 1996 ) si usava ipfwadm
Nel kernel 2.2 ( 1999 ) si sono usate le ipchains
Dal kernel 2.4 ( 2001 ) sono state introdotte le iptables
Tutt'ora utilizzate nel ramo 2.6 ( 2002 )

Il framework netfilter/iptables gestisce tutte le attività di firewalling su Linux:
- Netfilter comprende i moduli del kernel
- iptables è il comando con cui si gestisce netfilter

Feature principali:
- Packet filtering stateless e stateful
- Supporto IPv4 e IPv6
- Ogni tipo di natting (NAT/NAPT)
- Infrastruttura flessibile ed estendibile
- Numerosi plug-in e moduli aggiuntivi per funzionalità aggiuntive

Sito ufficiale: http://www.netfilter.org

Logica di Iptables: tabelle, catene, regole, target

Iptables lavora su 3 tabelle (tables) di default:
filter - Regola il firewalling: quali pacchetti accettare, quali bloccare
nat - Regola le attività di natting
mangle - Interviene sulla alterazione dei pacchetti.

Ogni tabella ha delle catene (chains) predefinite (INPUT, OUTPUT, FORWARD ... ) a cui possono essere aggiunte catene custom.
Ogni catena è composta da un elenco di regole (rules) che identificano pacchetti di rete secono criteri diversi (es: -p tcp --dport 80 -d 10.0.0.45)
Ogni regola termina con una indicazione (target) su cosa fare dei pacchetti identificati dalla regola stessa (es: -j ACCEPT,  -j DROP ...)

Script per testare regole iptables da remoto

Autore: lorenzopuntin - ( Revisione: al ) - Ultimo Aggiornamento: 2003-06-13 17:23:48 - Data di creazione: 2003-06-13 17:23:48
Tipo Infobox: SCRIPTS - Skill: 3- INTERMEDIATE

Lo script sotto indicato rappresenta un semplice modo per testare, senza rischiare di rimanere "tagliati fuori" le iptables su un firewall Linux remoto.
La tecnica è molto semplice, prima di mettere in produzione effettiva la modifica delle regole del firewall si fa un prova temporanea delle nuove regole per poi ristabilire quelle originarie.
Partendo dal principio che le regole in produzione sono giuste (quantomeno per quanto riguarda l'accesso al firewall) se le regole nuove comportano un mal funzionamento alle connessioni in atto (solitamente si viene tagliati fuori) le vecchie, che vengono richiamate a fine script, dovrebbero risistemare la situazione.

Lo script riportato prevede la presenza del file /etc/firewall/wall (ridefinibile con una variabile iniziale) che contiene le regole in produzione attualmente utilizzate.
Lo script semplicemente esegue l'argomento se viene passato (un analogo script con le nuove regole) o esegue /etc/firewall/wall.new (che dovrebbe essere la copia modificata di wall con le regole di
produzione), imposta il nuovo firewalling "aspetta" 20 secondi visualizzando una barra di progressione (utile per capire se si viene "tagliati fuori" o la connessione al firewall remoto rimane attiva) e poi riesegue le vecchie regole, permettendo, in caso di errori nelle nuove regole, di rientrare sul sistema.
I 20 secondi (ovviamente modificabili) sono anche utili per testare le nuove funzionalità del firewall, a prescindere dal fatto che riguardino la possibilità di accesso remoto alla macchina.

Quando le verifiche sono state "approvate" si rinomina il file wall.new in wall e lo si esegue in modo da renderle definitive.
Per reimpostare le regole al reboot ovviamente da qualche parte (tipo in /etc/rc.d/local.rc) si deve garantire l'esecuzione di /etc/firewall/wall.

#! /bin/bash
# Script di test delle regole di un firewall

# Path dello script che attiva il firewall (in produzione
PROD=/etc/firewall/wall

# Lo script modificato con le nuove regole può essere /etc/firewall/wall.new o il nome di file passato come argomento a questo script
if [ "$1" = "" ]
then
  PROVA=/etc/firewall/wall.new
else
  PROVA=./$1
fi

echo ""
# Provo le nuove regole di firewall
$PROVA

echo ""
echo "|    |    |    |    |"
i=0
while [ $i -le 20 ]
do
  echo -n "="
  sleep 1
  let i=$i+1
done
echo ""
echo ""

# Riattivo le regole precedenti
$PROD
echo ""

Firewall con la tabella filter

E' quella implicita e predefinita (-t filter)
Riguarda le attività di filtraggio del traffico.
Ha 3 catene di default:
INPUT - Riguarda tutti i pacchetti destinati al sistema. In entrata da ogni interfaccia.
OUTPUT - Riguarda i pacchetti che sono originati dal sistema e destinati ad uscire.
FORWARD - Riguarda i pacchetti che attraversano il sistema, con IP sorgente e destinazione esterni.

Esempio per permettere accesso alla porta 80 locale:
iptables -t filter -I INPUT -p tcp --dport 80 -j ACCEPT
Analoga a: iptables -I INPUT -p tcp --dport 80 -j ACCEPT

Esempio per permettere ad un pacchetto con IP sorgente 10.0.0.4 di raggiungere il server 192.168.0.1 attraversando il firewall:
iptables -I FORWARD -s 10.0.0.4 -d 192.168.0.1 -j ACCEPT

Gestione e salvataggio regole

Le regole di iptables vengono immediatamente attivate nel momento in cui si inserisce il comando.
Lo stato del firewall rimane fino a quando non si esegue un riavvio.
Il comando iptables-save stampa su stdout la configurazione corrente del firewall
Con iptables-restore si può ripristinare una configurazione salvata con iptables-save

Durante l'avvio le impostazioni di iptables possono essere ripristinate con:

- Uno script shell che esegue in successione tutti i comandi iptables necessari.
Ha il vantaggio di permettere commenti fra le regole e poter usare variabili, cicli e impostare regole sulla base di parametri variabili.
Spesso lo si richiama da /etc/rc.d/rc.local ma sarebbe meglio applicarlo appena attivate le interfacce di rete

- Uno script di init.d che tramite iptables-restore ripristina una configurazione precedentemente salvata. E' la soluzione usata da molte distribuzioni, dove il file di configurazione del firewall non è altro che l'output di un comando come: iptables-save > /etc/sysconfig/iptables. Ha il vantaggio di applicare lunghi elenchi di regole in modo molto più rapido.

Logica di Iptables

Autore: al - ( Revisione: maxgrante ) - Ultimo Aggiornamento: 2005-05-15 13:32:22 - Data di creazione: 2004-06-04 10:38:41
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

E' essenziale capire e familiarizzare con la logica di iptables prima di cimentarsi nella stesura delle policy di un firewall, altrimenti si rischia di non ottenere i risultati voluti o comprometterne la funzionalità.

Logica di tabelle, catene, regole.
Di default iptables lavora su 3 tabelle (tables) (filter, nat, mangle) che prevedono diverse catene (chains) (INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING...) all'interno delle quali esistono elenchi di regole (rules).
Ogni regola identifica pacchetti di rete secondo diversi criteri sulla base di variegati match (tcp, udp, state, pkttype e molti altri, alcuni sperimentali) con le relative opzioni e termina con un target che determina cosa fare del pacchetto matchato (ACCEPT, DROP, REJECT, SNAT, DNAT, LOG...).

Tabella di filter
Quando si usa il comando iptables questa è la tabella di default, implicita.
Prevede 3 catene di default che di fatto corrispondono alle possibili destinazioni del pacchetto rispetto alla macchina che funziona da firewall:
INPUT Catena in cui passano tutti i pacchetti in entrata dalle interfacce di rete del sistema. Si usa comunemente per permettere o negare l'accesso da IP remoti a porte locali.
OUTPUT: Considera tutti i pacchetti che sono originati ed escono dal proprio sistema. Si usa per controllare il traffico in uscita, sia per le risposte a pacchetti permessi in INPUT che per nuove connessioni in uscita.
FORWARD: Riguarda i pacchetti che devono "attraversare" il firewall, avendo IP sorgente e destinazione diversi da quello della macchina su cui gira iptables.
Si usa tipicamente su router o firewall di rete.

Tabella di nat
Questa tabella riguarda alcune alterazioni che si possono fare su un pacchetto, in particolare  la variazione degli IP e delle porte sorgenti o di destinazione . Viene richiamata con l'opzione -t nat e prevede le seguenti catene di default:
PREROUTING - Catena in cui vengono processati i pacchetti in ingresso, prima che il sistema prenda le decisioni di routing. Si usa tipicamente per fare destination natting usando il target DNAT.
POSTROUTING - Catena in cui passano i pacchetti dopo che sono stati routati sulla interfaccia di destinazione. Si usa per modificare l'IP e/o la porta sorgente di un pacchetto, tipicamente usato su default gateway di una rete con funzioni di Port Address Translation (su Linux definito Masquerading). Prevede i target SNAT e MASQUERADE.
OUTPUT - Catena utilizzata per modificare l'IP sorgente di un pacchetto uscito dal sistema stesso.

Tabella di mangle
Si può utilizzare per modificare vari parametri negli header di un pacchetto. Viene richiamata con -t mangle e prevede le catene di default PREROTING, INPUT, FORWARD, OUTPOUT, POSTROUTING. L'uso più comune è per alterare il TOS di un pacchetto IP. Non ci si ritroverà ad usarla spesso.

Il comando iptables
Iptables è sia il nome dell'infrastruttura a catene con cui si definiscono le policy di firewalling di un sistema basato su netfilter che il comando, utilizzabile da shell, con cui si configura e gestisce il tutto.
La sua sintassi è piuttosto variegata e prevede opzioni e impostazioni anche sulla base dei moduli aggiuntivi supportati e permette di: azzerare le catene esistenti, aggiungere regole, rimuovere regole, impostare le policy di default, creare nuove catene custom, azzerare i contatori ecc.
Comodi comandi ausiliari sono iptables-save e iptables-restore che si usano rispettivamente per salvare e ripristinare le configurazioni del firewall.
Le impostazioni sono immediatamente applicate sul sistema fino al momento in cui non si riavvia, per ripristinarle dopo un reboot, è necessario salvare su un file.
Le distribuzioni Linux possono avere file diversi di configurazione e diversi script di avvio, con cui le iptables sono gestite come un servizio, ma la sintassi del comando iptables resta comunque comune.
  
Attraversamento delle catene
La sequenza con cui vengono processate le varie catene dal Kernel ha questa logica, nel caso si faccia forwarding:
RETE A - MANGLE PREROUTING - NAT PREROUTING - ROUTING - FILTER FORWARD - ROUTING - RETE B
Oppure, per pacchetti in entrata o in uscita:
RETE A - MANGLE PREROUTING - NAT PREROUTING - ROUTING - FILTER INPUT - LOCAL PROCESS - MANGLE OUTPUT - NAT OUTPUT - FILTER OUTPUT - ROUTING - RETE B

I pacchetti attraversano le catene che sono destinati a percorrere, secondo l'ordine delle regole impostate. Se un pacchetto matcha le condizioni definite in una regola, allora segue le indicazioni specificate nel target (ACCEPT, DROP, DNAT) e , in molti casi, interrompe l'attraversamento. Se non matcha nessuna regola di una catena, segue la policy di default impostata per quella catena.
Per questo motivo è fondamentale l'ordine con cui sono inserite le regole in una catena.

iptables

Autore: neo - ( Revisione: al ) - Ultimo Aggiornamento: 2005-05-23 14:29:18 - Data di creazione: 2002-10-05 19:16:53
Tipo Infobox: COMMANDS - Skill: 3- INTERMEDIATE

Iptables è il comando utilizzato per settare, modificare e cancellare rule riguardanti il packet filtering del kernel linux.
Di seguito verranno riportati le principali opzioni e le sintassi più utilizzate:

Aggiunge una regola alla fine della catena scelta oppure la modifica o cancella:
iptables -[ADC] chain rule-specification [options]

Sostituisce regola o la inserisce all'inizio della catena
iptables -[RI] chain rulenum rule-specification [options]

Visualizza, svuota o azzera i contatori della catena selezionata:
iptables -[LFZ] [chain] [options]

Crea o aggiunge una nuova catena
iptables -[NX] chain

Setta la policy di default della catena
iptables -P chain target [options]

COMANDI
-A, --append Aggiunge una regola in fondo alla catena
-D, --delete Cancella una regola
-R, --replace Esegue il replace di una regola
-I, --insert Inserisce la regola all'inizio della catena o alla posizione indicata.
-L, --list Visulizza l'elenco delle regole inserite
-F, --flush Svuota le catene predefinite
-Z, --zero Azzera i contatori di ogni catena
-N, --new-chain Crea una nuova catena custom
-X, --delete-chain Cancella una catena (creata dall'utente)
-P, --policy Setta la policy di default per una catena

PARAMETRI
-p ,--protocol [protocol] Specifica  su quale protocollo deve matchare la regola
-s, --source  address[/mask], -src Specifica l'IP sorgente.
-d, --destination  address[/mask], -dst Specifica l'IP destinazione
-j, --jump Specifica il target a con cui gestire il pacchetto matchato: può essere una catena custom o un target esistente (drop,accept etc..)
-i, --interface Specifica da quale interfaccia è in entrata un pacchetto. Opzione valida solo per INPUT,  FORWARD e PREROUTING.
-o, --out-interface Specifica l'interfaccia d'uscita di un pacchetti. Opzione valida per FORWARD, OUTPUT e POSTROUTING.

TARGET
DROP I pacchetti che "matchano" la regola  vengono droppati.
ACCEPT I paccheti che "matchano"  la regola vengono fatti passare.
RETURN Il pacchetto smette di attraversare la catena e passa a quella successiva o segue il comportamente di default
QUEUE Se il kernel lo supporta il pacchetto passa a livello user-space dove può essere manipolato da programmi vari.
REJECT Il pacchetto viene rifiutato con un messaggio di notifica al mittente (es: icmp destination unreachable)
LOG Il pacchetto viene loggato via syslog.
MARK Il pacchetto viene marcato per essere gestito da programmi in user space.
MASQUERADE L'IP del pacchetto viene mascherato.
MIRROR Viene rimandato al mittente un pacchetto speculare a quello ricevuto
REDIRECT Il pacchetto viene redirezionato ad una porta locale

ALTRE OPZIONI
-v --verbose Abilita il verbose mode
-n Abilita la visualizzazione numerica, senza DNS reverse lookup
--linenumbers Quando viene eseguito il list delle regole viene aggiunto un numero ad ogni regola che corrisponde la posizione della regola nella sua catena.
! Inverte il significato dell'opzione che lo segue

/etc/sysctl.conf

Autore: neo - ( Revisione: al ) - Ultimo Aggiornamento: 2004-04-01 12:13:42 - Data di creazione: 2004-04-01 12:13:42
Tipo Infobox: PATH - Skill: 3- INTERMEDIATE

File di configurazione contenente le opzioni del kernel modificabili in run-time.
Di seguito verra' riportato un esempio di questo file con alcune opzioni abilitate di default da RedHat.
E' fondamentale abilitare net.ipv4.ip_forward (forwarding dei pacchetti IP) se il proprio Linux deve fare da firewall/router.

Di fatto vengono modificati i parametri contenuti nel /proc filesystem.
Abilitando (1) ,disabilitando (0), o il Tuning di alcuni parametri del kernel:
Precisamente si possono modificare i valori del kernel in run-time per i seguenti campi
- Virtual memory
- File System
- Network

Ecco il cat del file in configurazione RedHat Standard:
[neo@dido neo]$ cat /etc/sysctl.conf
# Disables packet forwarding
net.ipv4.ip_forward = 0
# Enables source route verification
net.ipv4.conf.default.rp_filter = 1
# Disables the magic-sysrq key
kernel.sysrq = 0


A causa di un bug di alcuni router, inoltre, se l'ECN (Explicit Congestation Notification) è abilitato, ciò che sta dietro a tali router NON sarà raggiungibile.
Il tutto si risolve disabilitando l'ECN nel kernel, intervenendo in /etc/sysctl.conf con una riga tipo:
net.ipv4.tcp_ecn= 0

iptables - One command to rule them all

Il comando iptables viene usato per ogni attività di gestione e configurazione.

Inserimento regole:
iptables -A CATENA ... - Aggiunge una regola alla fine della catena indicata
iptables -I CATENA [#] ... - Inserisce alla riga # (default 1) una regola nella catena indicata
iptables -N CATENA - Crea una nuova catena custom
iptables -P CATENA TARGET - Imposta il target di default per la catena indicata

Rimozione regole e azzeramenti:
iptables -F [catena] - Ripulisce tutte le catene (o quella indicata)
iptables -X [catena] - Ripulisce tutte le catene custom (o quella indicata)
iptables -Z [catena] - Azzera i contatori sulle catene
iptables -D catena # - Cancella la regola numero # dalla catena indicata

Interrogazione:
iptables -L - Elenca le regole esistenti
iptables -L -n -v - Elenca, senza risolvere gli host, in modo verboso le regole esistenti

Criteri standard di match

Le possibilità di matching di pacchetti secondo diversi criteri sono molte e possono essere abbinate nella stessa regola.
Il carattere ! si usa come negazione (NOT logico):
Criteri di match standard:
-p [!] proto - Protocollo IP. Secondo IP number o nome (es: tcp, udp, gre, ah...)
-s [!] address[/mask] - Indirizzo IP sorgente (o network con maschera di sottorete)
-d [!] address[/mask] - Indirizzo IP destinazione (o network)
-i [!] interface[+] - Interfaccia di rete di entrata ([+] wildcard)
-o [!] interface[+] - Interfaccia di rete di uscita ([+] wildcard)
-f - Frammento di pacchetto

Estensioni per principali protocolli
TCP (-p tcp)
--sport port[:port] - La porta o il range di porte TCP sorgenti (Per un range da 1 a 1024: 1:1024
--dport port[:port] - La porta o il range di porte TCP di destinazione
--tcp-flags flag - I flag TCP del pacchetto attivi (SYN, ACK, FIN, RST, URG, PSH)  
--syn - Pacchetti con solo SYN attivo (nuove connessioni)
--tcp-option option - Match per specifiche opzioni della intestazione TCP
Esempio per droppare tutti i pacchetti TCP in entrata su porte privilegiate:
iptables -I INPUT -p tcp --syn --dport 0:1024 -j DROP

UDP (-p udp)
--sport port[:port] - La porta o il range di porte UDP sorgenti (Per un range da 1 a 1024: 1:1024
--dport port[:port] - La porta o il range di porte UDP di destinazione
Esempio per permettere pacchetti UDP per traceroute:
iptables -I INPUT -p udp --sport 32769:65535 --dport 33434:33523 -j ACCEPT

ICMP (-p icmp)
--icmp-type type - Match sul tipo di pacchetto ICMP in formato numerico o completo (iptables -p icmp --help per un elenco dei tipi ICMP)
Esempio per permettere pacchetti UDP per traceroute:
iptables -I INPUT -p udp --sport 32769:65535 --dport 33434:33523 -j ACCEPT

sysctl

Autore: neo - Ultimo Aggiornamento: 2002-10-03 18:07:14 - Data di creazione: 2002-10-03 18:07:14
Tipo Infobox: COMMANDS - Skill: 4- ADVANCED

Comando su Linux che permette di configurare in run-time e visualizzare alcuni parametri del kernel.
Particolarmente utile per il tuning del sistema, in particolare:
- Tuning dei Parametri della Network
- Tuning dei Parametri della memoria virtuale
- Tuning dei Parametri del filesystem

Per verificare le opzioni:
sysctl [-n] [-e] variable ...
sysctl [-A]

Per modificare le opzioni:
sysctl [-n] [-e] -w variable=values

Per rileggere il file di condfigurazione:
sysctl [-n] [-e] -p  [file di configurazione]

-A Printa in stdout tutti i valori attualmente disponibili
-n Disabilita il print in stdout del nome della variabile
-e Ignora eventuali errori nel nome della variabile
-w Opzione per modificare il settaggio di sysctl
-p Carica le opzioni di sysctl da un file. Default /etc/sysctl.conf

Target e jump

Ogni regola termina con la definizione di un TARGET che indica cosa viene fatto del pacchetto.
Molti dei target principali (ACCEPT, DROP, REJECT...) determinano l'interruzione della catena: il pacchetto matchato segue le indicazioni del Target e non vengono considerate le catene successive.
Come target si può anche impostare una catena custom nella quale "saltare" (jump -j) per procedere nell'attraversamento delle regole.

Target principali
-j ACCEPT - Il pachetto matchato viene accettato e procede verso la sua destinazione. Si usa per definire il traffico permesso.
-j DROP - Il pacchetto viene rifiutato e scartato, senza alcuna notifica al mittente. Si usa, in alternativa a REJECT, per bloccare traffico.
-j REJECT - Il pacchetto viene rifiutato. Al mittente viene mandato un pacchetto (configurabile) di notifica  tipo ICMP port-unreachable (--reject-with icmp-port-unreachable)
-t LOG - Il pacchetto viene loggato via syslog e procede l'attraversamento della catena. Opzioni: (--log-level, --log-prefix, --log-tcp-sequence, --log-tcp-options,     --log-ip-options)
-j DNAT - Viene modificato l'IP di destinazione del pacchetto. Target disponibile solo in nat / PREROUTING e nat / OUTPUT. L'opzione --to-destination IP:porta definisce il nuovo IP di destinazione. Si usa tipicamente su network firewall che nattano server di una DMZ
-j SNAT - Viene modificato l'IP sorgente. Solo in nat / POSTROUTING. Prevede l'opzione --to-source IP:porta. Si usa per permettere l'accesso a  Internet da una rete locale con IP privati.
-j MASQUERADE - Simile a SNAT, si applica quando i pacchetti escono da interfacce con IP dinamico (dialup, adsl, dhcp...). Si usa solo in nat / POSTROUTING e prevede l'opzione --to-ports porte.
-j REDIRECT - Redirige il pacchetto ad una porta locale. Usabile solo in nat / PREROUTING e nat / OUTPUT è previsto per fare un transparent proxy (con proxy server in esecuzione sulla macchina con iptables)
-j RETURN - Interrompe l'attraversamento della catena. Se questa è una secondaria, il pacchetto torna ad attraversare la catena madre da punto in cui aveva fatto il salto nella secondaria. Se il RETURN è in una delle catene di default, il pacchetto interrompe l'attraversamento e segue la policy di default.
-j TOS - Usabile solo nella tabella mangle, permette di cambiare il TOS (Type Of Service) di un pacchetto con l'opzione --set-tos. Per un elenco dei parametri disponibili: iptables -j TOS -h
-j MIRROR - Curioso e sperimentale, questo target invia un pacchetto speculare al mittente. In pratica è come se facesse da specchio per tutti i pacchetti ricevuti. Da usare con cautela, per evitare attacchi DOS indiretti.

Tool di configurazione di Iptables

Sono disponibili diversi strumenti che rendono più semplice la gestione e la configurazione di Iptables. A volte questi sono installati e integrati di default su una distribuzione, a volte vanno installati autonomamente.

Shorewall - http://www.shorewall.net/ - Potente strumento di configurazione, che sulla base di propri file di configurazione permette la creazione di regole iptables complesse. Meno semplice di altri strumenti si rivela più adeguato per scenari evoluti.

FwBuilder - http://www.fwbuilder.org/ - Ottimo tool grafico di configurazione con supporto di firewall diversi (iptables, pix, ipfilter, ipf..). Ha un aspetto e una logica che ricorda quello di Checkpoint e permette anche configurazioni complesse.

Firestarter - http://www.fs-security.com/ - Semplice e comodo tool grafico di configurazione, gestione e monitoraggio del traffico. Non adeguato ad usi evoluti, è l'ideale come personal firewall o per utenti non esperti.

FireHol - http://firehol.sourceforge.net/ - Similmente a Shorewall prevede propri file di configurazione, con una logica semplificata, con cui costruisce catene iptables complesse.

KMyFirewall - http://kmyfirewall.sourceforge.net/ - Tool per KDE che permette una configurazione relativamente semplice ma senza rinunciare al dettaglio e alla "consapevolezza" sulle regole implementate.

Lokkit - E' il tool di default con cui viene gestita la configurazione su RedHat (disponibile anche per altre distro) . Molto semplice permette una configurazione essenziale, ma non ha le funzioni di monitoring e gestione di un Firestarter.

WebMin - http://www.webmin.org/Webmin ha un modulo per la gestione diretta di iptables (e uno anche per gestire Shorewall). Richiede comunque una buona comprensione della logica di iptables, ma presenta in modo comodo le opzioni disponibili.

Tuning dei parametri del kernel

Tramite l'interfaccia system control è possibile settare, in tempo reale, numerosi parametri che influenzano il tuning del networking.

Esistono diversi modi per intervenire su sysctl:
1- Usare normali comandi come cat e echo per visualizzare e modificare parametri all'interno di /proc/sys. Es:
echo "1" > /proc/sys/net/ipv4/ip_forward
cat /proc/sys/net/ipv4/ip_forward

2- Usare il comando sysctl per visualizzare o settare (con opzione -w) i parametri:
sysctl -w net.ipv4.ip_forward="1"
sysctl net.ipv4.ip_forward

3- Usare il file di configurazione /etc/sysctl.conf che all'avvio viene caricato automaticamente e contiene righe come:
net.ipv4.ip_forward = 1

Iptables sulle distribuzioni Linux

La gestione di iptables cambia su diverse distribuzioni Linux.
Non è indispenabile usare la logica di una specifica distribuzione: si possono applicare le regole di iptables con metodi propri, disattivando quelli di default.

RedHat - Fedora (e derivate)
Il firewalling è gestito con il servizio iptables, gestibile tramite l'init script /etc/init.d/iptables. La configurazione delle regole è, in formato iptables-save, in /etc/sysconfig/iptables.

SuSE
Yast2 permette di configurare un firewall con una discreta varietà di possibilità. Il file di configurazione è in un formato proprio, orientato alla funzione e senza riferimenti diretti alle regole iptables da applicare: /etc/sysconfig/SuSEfirewall2.

Mandriva (Mandrake)
Dal Mandrake Control Center il tool DrakDirewall permette una comoda configurazione.

Debian
Debian non fornisce una soluzione di default per gestire iptables. Mette a disposizione diversi strumenti che facilitano la creazione e la gestione delle regole.
Questi programmi sono disponibili e a volte previsti di default anche su altre distribuzioni (Firestarter, Fwbuilder, Shorewall, Guarddog, Knetfilter, Lokkit...)

Gentoo
E' fornito uno script di gestione del firewall /etc/init.d/firewall che contiene comandi iptables da applicare in funzione del file di configurazione (custom) /etc/conf.d/firewall. Comode funzionalità di accounting con il comando accounting-report.

Distribuzioni Firewall dedicate

Esistono varie distribuzioni esplicitamente dedicate per un firewall.
Possono essere LiveCD o installate sul sistema e generalmente prevedono:
- Kernel con iptables e a volta patch sperimentali
- Interfaccia grafica di gestione (generalmente via web)
- Server DHCP per assegnare IP alla rete interna
- Software per VPN varie (IPSec, PPTP)
- Software di Intrusion detection e monitoring della sicurezza
- Proxy filtering e eventuali filtri sulla posta

Le più significative sono:
Astaro Security Linux - http://www.astaro.com/
Distribuzione commerciale con comoda interfaccia web e notevoli funzionalità: firewall, VPN, antivirus, antispam, content filtering, antispyware, intrusion detection.

SmoothWall - http://smoothwall.org/
Storica distribuzione per firewall con la versione Express (free) e versioni commerciali. Supporto VPN, antivirus, antispam, content filtering, antispyware, intrusion detection.

Clark Connect - http://www.clarkconnect.com/
Esplicitamente dedicata per firewall, lan gateway prevede supporto VPN, antivirus, antispam, content filtering, antispyware, intrusion detection oltre alla gestione di normali servizi di rete.

IpCop - http://www.ipcop.org/
Funzionale e completa, con bella interfaccia web e gestione traffic shaping e VPN.

Devil Linux - http://www.devil-linux.org
Può essere caricata direttamente da CD o USB. Ha un kernel hardened con GRSecurity e una interfaccia testuale per la gestione del sistema.

Monowall - http://www.m0n0.ch/
Si cita per riferimento, anche se non è basata su Linux ma su FreeBSD. Ha una comoda interfaccia, supporto DHCPd, IPSEC, PPTP, SNMP. Notare che usa ipfilter e non iptables.

Connection tracking con Iptables

Una delle più potenti e benvenute feature di iptables è la gestione del traffico con la consapevolezza dei flussi e delle connessioni dei protocolli usati.
Il modulo ip_conntrack di Netfilter si preoccupa di gestire le connessioni e fornire gli strumenti per poterle controllare.
In /proc/net/ip_conntrack il kernel mantiene e aggiorna in tempo reale lo stato delle connessioni gestite (il numero massimo è configurabile modificando /proc/sys/net/ipv4/ip_conntrack_max.

La gestione del traffico sulla base delle connessioni è fatta richiamando il modulo di match state che permette di dividere il traffico secondo diversi stati:
NEW - Il primo pacchetto relativo ad una nuova connessione (syn TCP o nuovo pacchetto UPD)
ESTABLISHED - Pacchetti relativi a connessioni già stabilite, in cui si è avuto almeno un pacchetto da entrambi i peer
RELATED - Pacchetti in qualche modo correlati a connessioni esistenti ed established. Ticipi esempi il traffico di dati FTP o il trasferimetno DCC in IRC.
INVALID - Pacchetti che non rientrano in alcuno dei suddetti stati, di solito vengono droppati.

Il match state risulta particolarmente comodo per gestire il "traffico di ritorno" per connessioni accettate.
Ad esempio, per permettere su un host, tutto il traffico in uscita e, in entrata, solo il traffico correlato a quanto uscito bastano regole tipo:
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
itables -I OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT


Per gestire lo stato di connessione di alcuni protocolli particolari, esistono dei moduli speciali adibili sia alla gestione del connection tracking, sia al natting:
ip_conntrack_ftp - ip_nat_ftp : Conntrack e nat per FTP
ip_conntrack_h323 - ip_nat_h323 : Conntrack e nat per H323
ip_conntrack_irc - ip_nat_irc : Conntrack e nat per IRC
ip_conntrack_rtsp - ip_nat_rtsp : Conntrack e nat per IRC
ip_conntrack_tftp - ip_nat_tftp : Conntrack e nat per TFTP
ip_conntrack_rpc_tcp - ip_conntrack_rpc_udp : Conntrack per RPC


iptables - Linux natting e packet mangling

Utilizzo di iptables per natting, masquerading e mangling di pacchetti.

Alterazione di pacchetti con la tabella mangle

La tabella mangle (-t mangle) permette la modifica di vari header IP o TCP di un pacchetto.
Viene tipicamente usata per alterare il TOS e prevede le catene di default: PREROTING, INPUT, FORWARD, OUTPOUT, POSTROUTING.
Ha usi rari e sporadici come il tentativo di ottimizzare la velocità del traffico in uscita impostando il TOS o, più in voga, il DSCP di un pacchetto.

Esempio di modifica TOS per ridurre la latenza di pacchetti DNS:
iptables -t mangle -A OUTPUT -p udp --dport 53 -j TOS --set-tos Minimize-Delay

Esempio di impostazione del massimo throughput per protocolli di trasferimento file:
iptables -t mangle -A FORWARD -p tcp -m multiport --dport 21,20,43,88,109,110,143,873 -j TOS --set-tos Maximize-Throughput

Network address translation con la tabella nat

La tabella nat (-t nat) si usa per modificare IP e porte sorgenti e destinazione.
Ha 3 catene di default:
PREROUTING - Viene attraversata prima che il sistema decida come fare routing. Si usa per fare DESTINATION NATTING (target DNAT)
POSTROUTING - Viene usata dopo che il sistema ha deciso su che interfaccia fa uscire un pacchetto. Si usa per SOURCE NATTING (target SNAT).
OUTPUT - Si applica a pacchetti in uscita dal sistema stesso per eventuali modifica dell'IP sorgente.

Esempio per nattare una rete completa con un unico IP pubblico (PAT) su interfaccia dialup:
iptables -t nat -I POSTROUTING -s 10.0.0.0/24 -o ppp0 -j MASQUERADE

Analogo esempio preferibile su interfacce con ip fisso (es: 80.80.14.14):
iptables -t nat -I POSTROUTING -s 10.0.0.0/24 -j SNAT --to-source 80.80.14.14

Esempio per nattare un host con IP privato su IP pubblico :
iptables -t nat -I PREROUTING -d 213.198.151.5 -j DNAT --to-dest 10.10.10.19

Logica di attraversamento di iptables

Il kernel gestisce ogni pacchetto secondo logiche e seguenze ben precise, che determinano il modo con cui vanno processate, e configurate, le iptables.

Pacchetti destinati al sistema locale
1 - Un pacchetto entra da una interfaccia (es: eth0)
2 - Attraversa la tabella/catena mangle / PREROUTING (set TOS ecc)
3 - Attraversa la tabella/catena nat / PREROUTING (DNAT)
4 - Viene fatta la decisione di routing sulla base dell'IP destinazione attuale.
5 - Attraversa la tabella/catena mangle / INPUT
6 - Attraversa la tabella/catena filter / INPUT
7 - Viene processato da una applicazione locale (in userland)

Pacchetti in uscita dal sistema locale
1 - Il pacchetto viene processato/generato da una applicazione locale
2 - Il kernel decide dove routare, sulla base dell'IP destinazione.
3 - Attraversa la tabella/catena mangle / OUTPUT
4 - Attraversa la tabella/catena nat / OUTPUT
5 - Attraversa la tabella/catena filter / OUTPUT
6 - Attraversa la tabella/catena mangle / POSTROUTING
7 - Attraversa la tabella/catena nat / POSTROUTING (SNAT)
8 - Esce dall'interfaccia per raggiungere la sua destinazione (es: eth1)

Pacchetti che attraversano il firewall
1 - Un pacchetto entra da una interfaccia (es: eth0)
2 - Attraversa la tabella/catena mangle / PREROUTING
3 - Attraversa la tabella/catena nat / PREROUTING
4 - Viene routato verso l'IP di destinazione (in questo caso remoto).
5 - Attraversa la tabella/catena mangle / FORWARD
6 - Attraversa la tabella/catena filter / FORWARD
7 - Attraversa la tabella/catena mangle / POSTROUTING
8 - Attraversa la tabella/catena nat / POSTROUTING
9 - Esce dall'interfaccia per raggiungere la sua destinazione (es: eth1)

Linux Network Address Translation

Autore: neo - Ultimo Aggiornamento: 2004-06-04 10:47:19 - Data di creazione: 2004-06-04 10:47:19
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE

NAT ovvero Network Address Tranlation permette di manipolare un pacchetto IP modificando l'indirizzo IP sorgente o di destinazione.
Ovviamente il dispositivo che esegue il NAT quando riceve il pacchetto di ritorno esegue l'operazione inversa, sulla base di una tabella di natting che si tiene in memoria.

Il Nat viene utilizzato in varie occasioni, dove si ha la necessità ad esempio di redirezionare il traffico su un unico IP, oppure forwardare il traffico con una certa porta di destinazione ad un'altro host oppure su un'altra porta.
Su Linux si usa definire il natting con due modalità specifiche:
SNAT: Source NAT, cioè l'alterazione dell'IP sorgente del primo pacchetto che apre la connessione. Avviene sempre dopo che il pacchetto ha subito il routing (post-routing).
Un esempio di SNAT è il masquerading, con cui tutti gli IP sorgenti di una rete locale vengono convertiti in un unico IP sorgente (del dispositivo che fa masquerading) con cui i pacchetti vengono mandati in rete.
DNAT: Destination NAT, cioè l'alterazione dell'IP di destinazione del primo pacchetto.
A differenza del SNAT il DNAT  avviene sempre prima che il pacchetto subisca il routing (pre-routing).
Una forma di DNAT è il port-forwarding e trasparent proxy.
Per quanto riguarda iptables, le catene (chain) da considerare per i vari tipi di NAT sono:
PREROUTING (DNAT, per i pacchetti in arrivo).
Esiste inoltre un "caso speciale"  chiamato redirection. E' un DNAT effettuato esclusivamente sull'interfaccia di ingresso del pacchetto. Ovvero si può eseguire un redirect di tuti i pacchetti provenienti su eth0 con destination port 80 e redirezionarli sempre su eth0 ma sulla porta 12345.
OUTPUT (DNAT, per i pacchetti generati della macchina locale)
POSTROUTING (SNAT, per i pacchetti in uscita)

Esempi di NAT:
Port forwarding
iptables -A PREROUTING -t nat -p tcp -d 10.0.0.150 --dport 8080  -j DNAT --to 172.16.1.128:80
Ovvero tutti i pacchetti che hanno destinazione 10.0.0.150 sulla porta 8080vengono riderizionati al'ip 172.16.1.128 alla porta 80.
Source Natting
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 10.0.0.1
Tutti i pacchetti che escono dall'interfaccia eth0, subiscono una variazione dell'ip sorgente in 10.0.0.1
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 10.0.0.1-10.0.0.254
Come sopra, con la differenza che l'ip sorgente può essere alterato sia in 10.0.0.1 o 10.0.0.154
Masquerading
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Tutto ciò che passa in uscita dal proprio modem viene mascherato con l'ip pubblico assegnato dal proprio ISP.
Destination Natting
iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 -j DNAT --to 10.0.0.1:8080
Tutti i pacchetti TCP, arrivati dall'interfaccia eth1 con destinazione porta 80 vengono "dirottati" all'ip 10.0.0.1 alla porta 8080.

Masquerading e destination natting con Linux - Esempio

Autore: al - Ultimo Aggiornamento: 2005-05-22 20:39:41 - Data di creazione: 2004-10-20 11:28:23
Tipo Infobox: DESCRIPTION - Skill: 4- ADVANCED

Segue un esempio di script che esegue il masquerading di una rete locale e il destination natting di un server PPTP interno a dei limitati IP pubblici.
Può essere modificato e adattato ai propri scopi.

#!/bin/sh
#
# masquerading.sh - Version 20040531 - Coresis
#
#### DEBUGGING ###
set -x

### FLUSHING CHAIN ### Azzera e pulisce ogni regola esistente
/sbin/iptables -F
/sbin/iptables -F -t nat
/sbin/iptables -X
/sbin/iptables -Z

### DEFAULT CHAIN ### Imposta le policy di default
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT DROP
/sbin/iptables -t nat -P POSTROUTING DROP
/sbin/iptables -t nat -P PREROUTING DROP

### SETTING IPFORWARDING ### Abilita il forwarding di pacchetti non locali - FONDAMENTALE
/bin/echo "1" > /proc/sys/net/ipv4/ip_forward

### DISABLE RESPOND TO BROADCAST ### Non risponde ai ping inviati al browadcast della subnet
/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

### ENABLE BAD ERROR MESSAGE PROTECTION ### Ignora finti messaggi di errore ICMP
/bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

### DISABLE ICMP REDIRECT ACCEPTANCE ### Non accetta pacchetti ICMP di route redirection
/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects

### SETTING ANTISPOOFING PROTECTION ###
/bin/echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter

### DON'T RESPOND TO BROADCAST PINGS ###
/bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martians

### Qui vengono definite alcune variabili che successivamente sono usate nelle regole - MODIFICARE SECONDO I PROPRI PARAMETRI
# External Public Interface
EXTIF="eth1"
# Internal Private Interface
INTIF="eth0"
# Host Public IP (su eth1)
EGO="211.121.111.111"
# Internal LAN IP (su eth0)
LANIN="10.0.0.0/24"
# Trusted public network (da cui si permettono collegamenti SSH)
TRUSTED="13.18.151.0/24"
# IP/rete di un utente esterno abilitato a connetterci al server VPN interno
USER="112.56.10.32/28"
# IP Interno del server VPN
VPNSERVER="10.0.0.77"
# RFC IPs Classi di indirizzi dedicate a utilizzi privati o particolari e non routate su Internet
LOOPBACK="127.0.0.0/8"
CLASS_A="10.0.0.0/8"
CLASS_B="172.16.0.0/12"
CLASS_C="192.168.0.0/16"
CLASS_D_MULTICAST="224.0.0.0/4"
CLASS_E_RESERVED_NET="240.0.0.0/5"

# ANTISPOOF Adesso iniziano le regole vere e proprie. Le prime sono generiche regole anti-spoof per IP noti dall'interfaccia pubblica.
/sbin/iptables -A INPUT -i $EXTIF -s $EGO -j DROP
/sbin/iptables -A INPUT -i $EXTIF -s $CLASS_A -j DROP
/sbin/iptables -A INPUT -i $EXTIF -s $CLASS_B -j DROP
/sbin/iptables -A INPUT -i $EXTIF -s $CLASS_C -j DROP
/sbin/iptables -A INPUT -i $EXTIF -s $CLASS_D_MULTICAST -j DROP
/sbin/iptables -A INPUT -i $EXTIF -s $CLASS_E_RESERVED_NET -j DROP
/sbin/iptables -A INPUT -i $EXTIF -d $LOOPBACK -j DROP

# LOOP RULE Permettiamo il traffico di loopback
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT

# LAN IN ACCESS Regole che permettono l'accesso al firewall Linux dagli IP della rete Interna - Potrebbero essere più ristrette e limitarsi all'IP dell'amministratore
/sbin/iptables -A INPUT -i $INTIF -s $LANIN -j ACCEPT
/sbin/iptables -A OUTPUT -o $INTIF -d $LANIN -j ACCEPT

# LAN IN OUT Seguono le regole che gestiscono il masquerading della rete interna
/sbin/iptables -A FORWARD -s $LANIN -d 0/0 -j ACCEPT Forwarda tutti i pacchetti dalla rete interna a qualsiasi destinazione
/sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -d $LANIN -j ACCEPT Permette il forwarding di tutti i pacchetti correlati a comunicazioni esistenti
/sbin/iptables -t nat -A POSTROUTING -o $EXTIF -s $LANIN -j MASQUERADE Maschera gli IP sorgenti Interni con l'IP dell'interfaccia pubblica

# GENERAL Regole generali per permettere all'host locale di collegarsi a IP remoti e ricevere i pacchetti di risposta (Nota: si riferiscono alle attività che vengono fatte direttamente dalla macchina Linux locale e non dagli host che la usano come firewall)
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

# SSH Regole per permettere l'accesso al server SSH locale da un IP esterno fidato precedentemente indicato
/sbin/iptables -A INPUT -s $TRUSTED -p TCP --dport 22 -j ACCEPT

# VPN NATTING Esegue un DNAT di un server VPN che usa pptp (TCP porta 1723) e GRE (IP type 47) e permette l'accesso al server solo da un IP sorgente definito
/sbin/iptables -A FORWARD -s $USER  -p TCP --dport 1723 -j ACCEPT
/sbin/iptables -t nat -A PREROUTING -d $EGO -p tcp --dport 1723 -j DNAT --to-dest $VPNSERVER:1723
/sbin/iptables -t nat -A PREROUTING -d $EGO -p 47 -i eth1 -j DNAT --to-dest $VPNSERVER

# LOGGING Log di tutti i pacchetti, esclusi i broadcast, prima di essere droppati dalla regole di default. I logging viene fatto con livello debug per isolarlo da altri log di sistema. Per cui è necessario scrivere in /etc/syslog.conf una riga tipo:
kern.debug          /var/log/iptables.log

/sbin/iptables -A INPUT -m pkttype --pkt-type ! broadcast -j LOG --log-level=DEBUG --log-prefix="[INPUT DROP] : "
/sbin/iptables -A OUTPUT -m pkttype --pkt-type ! broadcast -j LOG --log-level=DEBUG --log-prefix="[OUTPUT DROP] : "


Esempi di configurazione di Iptables

Esempi di configurazioni di un firewall Linux con iptables

Scenario comune: Personal Firewall

Un Personal Firewall, se non ha servizi da esporre, può avere una configurazione essenziale: permette ogni pacchetto in uscita e accetta in entrata solo i pacchetti di ritorno:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT


Configurazioni più elaborata possono prevedere logging dei pacchetti droppati:
iptables -A INPUT -m pkttype --pkt-type ! broadcast -j LOG --log-prefix "INPUT DROP: "
iptables -A FORWARD -m pkttype --pkt-type ! broadcast -j LOG --log-prefix "FORWARD DROP: "

Controllo, se match owner è supportato, degli utenti autorizzati a far traffico in rete:
iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -m owner --uid-owner 501 -j ACCEPT

Script per la configurazione di un firewall a 3 interfacce

Autore: al - Ultimo Aggiornamento: 2007-03-28 12:18:33 - Data di creazione: 2007-03-28 12:11:14
Tipo Infobox: SCRIPTS - Skill: 4- ADVANCED

Viene proposto uno script, customizzabile, utilizzabile in un firewall Linux con 3 interfacce: esterna, DMZ e interna. Contiene degli esempi per gestire VPN IpSec e PPTP sia fra il server stesso su gira lo script e un peer remoto, sia fra client della rete interna e un server esterno.
Vanno cambiati i parametri relativi agli indirizzi usati e commentate o scommentate delle regole secondo proprie esigenze.

#!/bin/bash

PATH=$PATH:/sbin:/usr/sbin:/bin:/usr/bin

## SCRIPT DI CONFIGURAZIONE IPTABLES PER FIREWALL A 3 INTERFACCE:
##
## EXTERNAL - Tipicamente con IP pubblici, con accesso IPSEC e PPTP
## DMZ - Per server pubblici, nattati, esposti alla rete pubblica
## INTERNAL - Permette l'accesso Internet ai client della rete interna
##
## INSTRUZIONI PER L'USO
## Lo script è diviso in varie parti:
## - Definizione di Variabili generali (modifica necessaria)
## - Impostazione parametri del kernel (modifica facoltativa)
## - Impostazione regole generali (modifica facoltativa)
## - Impostazione regole per specifiche funzioni (DMZ, VPN, LAN NAT ecc.)
##   (Attivare/Disattivare e impostare parametri secondo proprie necessità)
##
## Versione 0.2 - [email protected]
## Revisione 20070328

############################################################
## DEFINIZIONE DI VARIABILI GENERALI
## Modificare i parametri sulla base delle proprie impostazioni
## Nota: Per maggiore leggibilità sono definite e vanno adattate
## altre variabili nella sezione in cui sono utilizzate
############################################################

## Impostazione indirizzo IP primario delle interfacce:
## esterna (ext), dmz (dmz), interna (int)
extip="151.151.151.151"
dmzip="172.16.0.1"
intip="192.168.0.1"

## Associazione interfacce alle reti:
## esterna (ext), dmz (dmz), interna (int)
extint="eth0"
dmzint="eth2"
intint="eth1"

## Indirizzi delle reti:
## esterna (ext), dmz (dmz), interna (int)
extnet="151.151.151.0/24"
dmznet="172.16.0.0/16"
intnet="192.168.0.0/24"




############################################################
## IMPOSTAZIONE PARAMETRI E CARICAMENTO MODULI DEL KERNEL
## Possono essere impostati anche su /etc/sysctl.conf
############################################################

## Abilita IP forwarding (fondamentale)
echo "1" > /proc/sys/net/ipv4/ip_forward

## Non risponde a ping su broadcast
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

## Abitilita protezione da messaggi di errore
echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

## Non accetta icmp redirect
echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects

## Abilita protezione (parziale) antispoof
echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter

## Logga pacchetti strani o impossibili
echo "1" > /proc/sys/net/ipv4/conf/all/log_martians

## Pre-carica i moduli del kernel che servono
modprobe ip_tables
modprobe iptable_nat
modprobe ip_nat_ftp
modprobe ip_conntrack_ftp
modprobe ipt_MASQUERADE




############################################################
## IMPOSTAZIONE REGOLE IPTABLES GENERALI
## Questa parte, in linea di massima, non necessita customizzazioni
## In questo script si segue questa logica:
## - Drop di default di ogni pacchetto
## - AGGIUNTA di regole sul traffico accettato
## - Log finale dei pacchetti prima che siano droppati
##
## Per ottimizzare le prestazioni può servire modificare l'ordine
## delle regole, inserendo per prime quelle più utilizzate.
## Si suggerisce, nel caso, di riordinare interi blocchi di configurazione
## (regole per dmz, nat, ipsec ecc.) facendo sempre attenzione all'ordine
## con cui sono aggiunte le regole per evitare disfunzioni
## Nota: Lo script è stato testato solo con l'ordine qui impostato.
############################################################

## Azzeramento di ogni regola e counter esistenti
iptables -t filter -F
iptables -t filter -X
iptables -t filter -Z
iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -Z
iptables -t nat -F
iptables -t nat -X
iptables -t nat -Z

## Impostazione policy di default
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT
iptables -t mangle -P OUTPUT ACCEPT
iptables -t mangle -P INPUT ACCEPT
iptables -t mangle -P FORWARD ACCEPT
iptables -t mangle -P POSTROUTING ACCEPT
iptables -t mangle -P PREROUTING ACCEPT

## Abilitazione traffico di loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT




############################################################
## TRAFFICO IN ENTRATA E IN USCITA DAL FIREWALL
## Adattare secondo proprie preferenze
############################################################

## INDIRIZZO IP o RETE da cui è possibile accedere al firewall (ssh)
## Inserire un indirizzo di amministrazione
admin="100.0.0.254"


############################################################
## INPUT - Traffico permesso in ingresso verso il firewall

## Accesso dalla rete interna (su porta ssh e proxy)
iptables -A INPUT -s $intnet -i $intint -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -s $intnet -i $intint -p tcp --dport 3128 -j ACCEPT

## Accesso incondizionato da indirizzo di amministrazione
iptables -A INPUT -s $admin -j ACCEPT

## Viene permesso in entrata il traffico correlato a connessioni già esistenti
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

## Abilitazione pacchetti ICMP (es: ping) da rete interna e dmz
iptables -A INPUT -p icmp -i $dmzint -j ACCEPT
iptables -A INPUT -p icmp -i $intint -j ACCEPT


############################################################
## OUTPUT - Traffico permesso in uscita dall'host del firewall
## Vengono proposte 2 alternative (commentare una o l'altra):
## A) Traffico in uscita ristretto (potrebbe impedire alcune attività di sistema)
## B) Traffico in uscita dal firewall libero (viene solo fatto un sanity check)

## A) Il firewall può pingare e uscire via ssh, stmp, dns:
# iptables -A OUTPUT -p icmp -j ACCEPT
# iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
# iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
# iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT
# iptables -A OUTPUT -p tcp --dport 22227 -j ACCEPT
# iptables -A OUTPUT -p tcp --dport 21 -j ACCEPT
# iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

## Dal firewall si può navigare sul web (necessario per proxy)
# iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
# iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT


## B) I pacchetti in uscita dal firewall all'esterno non hanno filtri
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT




############################################################
## REGOLE PER VPN IPSEC LAN 2 LAN
## Necessarie per permettere il collegamento ad un peer ipsec remoto
## e gestire il traffico fra le due reti
## Modificare i parametri secondo proprie necessità
############################################################

## Definizione degli indirizzi IP (pubblici) dei due peer IPSEC
## Server locale, questo (local) - Peer IpSec remoto (remote)
remote="212.212.212.212"
local="151.151.151.151"

## Rete locale e remota da mettere in comunicazione via ipsec
## (Coincidono con "leftsubnet" e "rightsubnet" di OpenSwan)
locallan="192.168.1.0/24"
remotelan="192.168.0.0/24"


############################################################
## Regole per ogni peer di una VPN IPSEC LAN 2 LAN

iptables -A OUTPUT -d $remote -p udp --dport 500 -j ACCEPT
iptables -A OUTPUT -d $remote -p ah -j ACCEPT
iptables -A OUTPUT -d $remote -p esp -j ACCEPT

iptables -A INPUT -s $remote -p udp --sport 500 -j ACCEPT
iptables -A INPUT -s $remote -p ah -j ACCEPT
iptables -A INPUT -s $remote -p esp -j ACCEPT

## Regole per IPSEC LAN 2 LAN con NAT-TRAVERSAL
## AGGIUNGERE le seguenti regole se è previsto l'uso di NAT-T
iptables -A OUTPUT -d $remote -p udp --dport 4500 -j ACCEPT
iptables -A INPUT -s $remote -p udp --dport 4500 -j ACCEPT

## Regola per permettere al server locale di contattare macchine della rete remota
iptables -A OUTPUT -d $remotelan -j ACCEPT


############################################################
## Regole per permettere ad un CLIENT VPN IPSEC INTERNO
## di collegarsi ad un server IPsec esterno
## Scommentare e usare se necessario

$ipsecserver = "21.21.21.21"
# iptables -A FORWARD -s $intnet -i $intint -p udp -d $ipsecserver -j ACCEPT
# iptables -A FORWARD -s $intnet -i $intint -p ah -d $ipsecserver -j ACCEPT
# iptables -A FORWARD -s $intnet -i $intint -p esp -d $ipsecserver -j ACCEPT


############################################################
## Definizione del traffico permesso fra le due reti
## Qui non vengono impostate alcune limitazioni:
## le due reti non hanno filtri tra loro.
## Restringere queste impostazioni secondo proprie necessità, nell'impostare
## gli indirizzi degli HOST delle LAN, usare il loro IP interno

iptables -A FORWARD -s $locallan -d $remotelan -j ACCEPT
iptables -A FORWARD -s $remotelan -d $locallan -j ACCEPT




############################################################
## REGOLE PER VPN PPTP
## Impostazioni per:
## - Permettere accesso PPTP da Internet a server locale
## - Permettere accesso PPTP da host locale a un pptp server esterno
## - Permettere accesso PPTP da host locale a qualsiasi pptp server
## - Permettere a client della rete interna di accedere ad un pptp server esterno
## - Permettere a client della rete interna di accedere a qualsiasi pptp server
## NOTA: Scommentare le regole che interessano
############################################################

## Indirizzo IP di un server PPTP esterno
pptpserver="85.85.85.85"


############################################################
## Regole per permettere accesso PPTP da Internet a server locale
iptables -A INPUT -p tcp --dport 1723 -j ACCEPT
iptables -A INPUT -p gre -j ACCEPT
iptables -A OUTPUT -p gre -j ACCEPT

## Ciclo per regole da applicare alle interfacce pptp create con il tunnel
## Da adattare se si prevede di avere più di 10 tunnel contemporaneamente.
for i in 0 1 2 3 4 5 6 7 8 9 ; do
    iptables -A FORWARD -i ppp$i -j ACCEPT
    iptables -A FORWARD -i $intint -o ppp$i -j ACCEPT
    iptables -A OUTPUT -o ppp$i -j ACCEPT
    iptables -A INPUT -i ppp$i -p icmp -j ACCEPT
done


############################################################
## Regole per permettere accesso PPTP da host locale a un pptpserver esterno
iptables -A OUTPUT -p tcp --dport 1723 -d $pptpserver -j ACCEPT
iptables -A OUTPUT -p gre -d $pptpserver -j ACCEPT


############################################################
## Regole per permettere accesso PPTP da host locale a qualsiasi server
# iptables -A OUTPUT -p tcp --dport 1723 -j ACCEPT
# iptables -A OUTPUT -p gre -j ACCEPT


############################################################
## Regole per permettere a client della LAN di accedere ad un pptpserver esterno
# iptables -A FORWARD -s $intnet -i $intint -p tcp --dport 1723 -d $pptpserver -j ACCEPT
# iptables -A FORWARD -s $intnet -i $intint -p gre -d $pptpserver -j ACCEPT


############################################################
## Regole per permettere a client della LAN di accedere a qualsiasi server pptp
# iptables -A FORWARD -s $intnet -i $intint -p tcp --dport 1723 -j ACCEPT
# iptables -A FORWARD -s $intnet -i $intint -p gre -j ACCEPT




############################################################
## LOCAL LAN NATTING (MASQUERADING)
## Impostazioni che permettono il natting (masquerading) della rete interna (LAN)
## e determinano quale traffico è concesso dalla rete interna verso Internet
## Adattare secondo proprie necessità
############################################################

## Indirizzo IP assegnato ai client quando escono su Internet
## Deve stare sull'interfaccia esterna e può essere lo stesso $extip
## precedentemente definito
## Se si usa un indirizzo diverso ricordarsi di abilitarlo come alias
## sull'interfaccia esterna (si può fare direttamente in questo script:
ifconfig eth0:1 151.151.151.152 netmask 255.255.255.0 broadcast 151.151.151.255

#extiplan=$extip
extiplan="151.151.151.152"

## Vengono proposte due alternative:
## A) Natting della rete locale con esclusione degli indirizzi della LAN remota
## B) Normale natting di tutta la rete locale
## Utilizzare A se il firewall è anche peer di una VPN ipsec lan-to-lan
## Nota: Se si usa l'opzione A, assicurarsi che questo blocco di regole sia
## successivo a quello relativo alla VPN IPsec

## A) LAN natting in caso di utilizzo VPN IPsec lan 2 lan:
# iptables -t nat -A POSTROUTING -s $intnet -d ! $remotelan -j SNAT --to-source $extiplan

## B) LAN natting normale
iptables -t nat -A POSTROUTING -o $extint -s $intnet -j SNAT --to-source $extiplan


############################################################
## Definizione del traffico Internet permesso ai client della rete Interna
## Vengono proposte due alternative:
## A) Libero accesso ad Internet a tutti i client della rete Interna
## B) Accesso limitato ai client della rete interna

## A) Libero accesso ad Internet a tutti i client della rete Interna
# iptables -A FORWARD -s $intnet -i $intint -j ACCEPT

## B) Accesso limitato ai client della rete interna
## Qui solo traffico di posta, dns e ssh (di default lo script prevede l'uso
## di un proxy locale per la navigazione dei client)
iptables -A FORWARD -s $intnet -i $intint -p tcp --dport 21 -j ACCEPT
iptables -A FORWARD -s $intnet -i $intint -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -s $intnet -i $intint -p tcp --dport 25 -j ACCEPT
iptables -A FORWARD -s $intnet -i $intint -p tcp --dport 110 -j ACCEPT
iptables -A FORWARD -s $intnet -i $intint -p tcp --dport 143 -j ACCEPT
iptables -A FORWARD -s $intnet -i $intint -p tcp --dport 995 -j ACCEPT
iptables -A FORWARD -s $intnet -i $intint -p tcp --dport 993 -j ACCEPT
iptables -A FORWARD -s $intnet -i $intint -p udp --dport 53 -j ACCEPT
iptables -A FORWARD -s $intnet -i $intint -p tcp --dport 80  -j ACCEPT
iptables -A FORWARD -s $intnet -i $intint -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -s $intnet -i $intint -p tcp --dport 3389 -j ACCEPT
iptables -A FORWARD -s $intnet -i $intint -p udp --dport 3389 -j ACCEPT



############################################################
## Viene accettato il traffico di ritorno a connessioni già stabilite
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT




############################################################
## DMZ
## Impostazioni che nattano i server presenti in DMZ e li rendono accessibili
## ad Internet sulle porte dei servizi di produzione
## Adattare e ampliare secondo proprie necessità
############################################################


############################################################
## Regole generali per permettere ai server in DMZ di accedere a servizi pubblici
## Sono proposti 2 approcci alternativi:
## A) Nessun filtro in uscita dalla DMZ
## B) Traffico in uscita limitato (può filtrare traffico necessario,customizzare)

## A) Nessun filtro in uscita dalla DMZ
# iptables -A FORWARD -i $dmzint -o ! $intint -j ACCEPT

## B) Traffico in uscita limitato (customizzare)
##
## iptables -A FORWARD -s $dmznet -i $dmzint  -j DROP

iptables -A FORWARD -i $dmzint -o ! $intint -p tcp --dport 25 -j ACCEPT
iptables -A FORWARD -i $dmzint -o ! $intint -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD -i $dmzint -o ! $intint -p udp --dport 53 -j ACCEPT
iptables -A FORWARD -i $dmzint -o ! $intint -p tcp --dport 25 -j ACCEPT
iptables -A FORWARD -i $dmzint -o ! $intint -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A FORWARD -i $dmzint -o ! $intint -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A FORWARD -i $dmzint -o ! $intint -p icmp --icmp-type echo-request -j ACCEPT



############################################################
## Accesso totale da indirizzo di amministrazione anche a server in DMZ
# iptables -A FORWARD -s $admin -j ACCEPT


##########################################################################
## Regole sul traffico da LAN a DMZ (accesso completo, restringere secondo necessità)
iptables -A FORWARD -s $intnet -i $intint -d $dmznet -o $dmzint -j ACCEPT


############################################################
## Natting di un server web, con accesso http pubblico e ftp da IP
## del webmaster.
## Vengono proposte due alternative:
## A) Natting 1 a 1, dove un IP pubblico corrisponde ad un IP interno
## B) Natting 1 a molti, dove a seconda della porta si redireziona su un diverso host interno

## IP pubblico del webserver (su rete esterna):
#extipwebserver="172.16.0.30"

## Impostazione IP aliasing su interfaccia pubblica
#ifconfig eth0:2 10.0.1.4 netmask 255.255.255.0 broadcast 10.0.0.255

## IP privato del webserver (su dmz)
#webserver="172.16.0.30"

## IP da cui può accedere un webmaster via ftp
#webmaster="10.0.0.150"

## A) NATTING 1-1 (Viene usato l'IP esterno definito in: $extipwebserver)
#iptables -t nat -A PREROUTING -d $extipwebserver -j DNAT --to-destination $webserver
#iptables -t nat -A POSTROUTING -s $webserver -j SNAT --to-source $extipwebserver

## B) NATTING 1-* (Viene usato l'IP esterno del firewall)
#iptables -t nat -A PREROUTING -d $extip -p tcp --dport 80 -j DNAT --to-destination $webserver:80

## Regole di firewalling per permettere l'accesso da Internet ai servizi in DMZ
#iptables -A FORWARD -d $webserver -p tcp --dport 80 -j ACCEPT
#iptables -A FORWARD -d $webserver -s $webmaster -p tcp --dport 21 -j ACCEPT


############################################################
## Natting di un terminal server.
## Sono definite le stesse logiche del webserver di cui sopra
## In forma compatta. Come sempre le opzioni A) o B) sono ALTERNATIVE fra loro

## IP Pubblico terminal server (solo per opzione A)
# extipterminalserver="10.0.0.3"
# ifconfig eth0:3 10.0.0.3 netmask 255.255.255.0 broadcast 10.0.0.255


## IP privato (in DMZ) del terminal server
ifconfig $dmzint  172.16.0.178 netmask 255.255.0.0
terminalserver="172.16.0.3"

## A) Natting 1-1
# iptables -t nat -A PREROUTING -d $extipterminalserver -j DNAT --to-destination $terminalserver
# iptables -t nat -A POSTROUTING -s $terminalserver -j SNAT --to-source $extipterminalserver

## A) Natting 1-*
iptables -t nat -A PREROUTING -d $extip -p tcp --dport 3389 -j DNAT --to-destination $terminalserver:3389

## Traffico concesso da Internet a porta 3389 Terminal Server
iptables -A FORWARD -d $terminalserver -p tcp --dport 3389 -j ACCEPT


############################################################
## Source natting degli IP della DMZ su IP esterno
## Lasciare alla fine del blocco relativo alla DMZ
iptables -t nat -A POSTROUTING -s $dmznet -j SNAT --to-source $extip



############################################################
## LOGGING dei pacchetti droppati
## Regole da inserire alla fine, appena prima del DROP di default
## Notare che non vengono loggati eventuali pacchetti droppati precedentemente
## Vegnono loggati solo pacchetti unicast (no broadcast/multicast) con prefisso
############################################################

iptables -A INPUT -m pkttype --pkt-type unicast -j LOG --log-prefix "INPUT DROP: "
iptables -A OUTPUT -m pkttype --pkt-type unicast -j LOG --log-prefix "OUTPUT DROP: "
iptables -A FORWARD -m pkttype --pkt-type unicast -j LOG --log-prefix "FORWARD DROP: "

Scenario comune: LAN Gateway

Un firewall che agisce come gateway per una rete locale (es: 10.0.0.0/24), che natta su un unico IP pubblico tutti gli IP interni, richiede:
iptables -A FORWARD -s 10.0.0.0/255.255.255.0 -i eth0 -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.0.0.0/255.255.255.0 -j MASQUERADE


IMPORTANTE: Abilitare l'IP forwarding a livello del kernel:
sysctl -w net.ipv4.ip_forward = 1

Il controllo su quali host della rete interna possono accedere a Internet può essere molto più fine, agendo a livello di porte concesse:
iptables -A FORWARD -s 10.0.0.0/255.255.255.0 -p tcp --dport 80 -i eth0 -j ACCEPT
A livello di MAC address degli host abilitati:
iptables -A FORWARD -m mac  --mac-source 00:50:8B:4D:55:BB -i eth0 -j ACCEPT
Introducendo un limite sul traffico che un host può avere:
iptables -A FORWARD -s 10.0.0.120 iptables -m connrate --connrate :36000 -j ACCEPT

Scenario comune: Transparent Proxy

Un transparent proxy è un normale proxy server che viene usato senza la necessità di configurazione di alcun parametro sul client.
Viene gestito, su Linux, operando su due livelli:
- Iptables per redirezionare il traffico dei client
- Squid (o analogo proxy server) per gestire questa funzionalità.

Configurazione Iptables
E' necessario redirezionare destinato ad host esterni verso la porta su cui ascolta il proxy.
Per esempio, se si vuole redirezionare il traffico web per un proxy locale in ascolto sulla porta 8080, sul gateway inserire:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
Se il proxy fosse su un altra macchina (LAN: 10.0.0.0/24 . Proxy: 10.0.0.15, Iptables FW: 10.0.0.1) si devono impostare regole tipo:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -s ! 10.0.0.15 -j DNAT --to-destination 10.0.0.15:8080
iptables -t nat -A POSTROUTING -i eth0 -s 10.0.0.0/24 -d 10.0.0.15 -j SNAT --to-source 10.0.0.1
iptables -A FORWARD -s 10.0.0.0/24 -d 10.0.0.15 -i eth0 -o eth0 -p tcp --dport 8080 -j ACCEPT
iptables -A FORWARD -s 10.0.0.15 -i eth0 -o eth1 -j ACCEPT


Configurazione Squid
Se si usa Squid assicurarsi che siano impostati in squid.conf:
http_port 8080
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

Scenario comune: Server firewall

Se applicate su un host che eroga un servizio pubblico, è bene bloccare tutto di default e abilitare il traffico in uscita:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

Il traffico permesso in entrata, ad esempio per un server web:
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Eventuale traffico di servizio da IP limitati (ftp, ssh):
iptables -A INPUT -p tcp --dport 22 -s 213.25.10.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 21 -s 143.20.12.7 -j ACCEPT


Stessi risultati si possono avere per configurazioni più "paranoiche" che limitano il traffico in uscita (attivandolo solo per risposte a richieste su porte aperte):
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 443 -j ACCEPT

Scenario comune: DMZ Firewall

Un firewall di rete classico permette di filtrare il traffico esterno prima che raggiuna dei server in una DMZ. Ha almeno 2 interfacce (una esterna, esposta ad Internet, una sulla DMZ, che costituisce il default gateway dei server pubblici).

Può agire in 2 modi principali:
- Routing fra rete esterna e DMZ con IP pubblic
- Natting fra rete esterna e DMZ con IP privati nattati dal firewall
In entrambi i casi l'IP forwarding va attivato.

Su un routing firewall con DROP di default, per quanto riguarda il controllo del traffico in transito bastano regole come:
iptables -A FORWARD -d 217.56.217.2 -i eth0 -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD -d 217.56.217.2 -i eth0 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -m tcp -p tcp -s 217.56.217.0/255.255.255.240 -i eth1 -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT


Se viene introdotto il natting dei server pubblici su host con IP privato (10.0.0.x):
iptables -A FORWARD -d 10.0.0.2 -i eth0 -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD -d 10.0.0.2 -i eth0 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -m tcp -p tcp -s 10.0.0.0/255.255.255.0 -i eth1 -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -d 217.56.217.2 -j DNAT --to-destination 10.0.0.2
iptables -t nat -A POSTROUTING -s 10.0.0.0/255.255.255.0 -j SNAT


Notare che per ogni IP di cui il firewall fa destination natting è necessario che il sistema risponda ad arp request, per cui deve avere tutti gli IP nattati configurati come alias sulla sua interfaccia esterna.


Iptables Avanzato

Funzionalità avanzate di iptables.

Catene Custom

E' possibile creare proprie catene con un set di regole autonomo.
La nuova regola può quindi diventare il target di qualsiasi altra regola.

Esempio (tipico) per catena custom che droppa, dopo aver loggato, i pacchetti
iptables -N LOGDROP
iptables -A LOGDROP -j LOG
iptables -A LOGDROP -j DROP


Per usarla:
iptables -A INPUT -p tcp --dport 22 -s ! 10.0.0.1 -j LOGDROP

Catene custom possono rendere più modulare e gestibile la configurazione di iptables.
Posso rivelarsi particolarmente utili in firewall complessi o particolarmente elaborati.
Su sistemi con logiche essenziali sono meno comode.

Moduli sperimentali di iptables

Lo sviluppo di moduli su iptables è costante e ai moduli stabili, integrati nelle distribuzioni comuni, si aggiungono moduli sperimentali di matching, target alternativi o patch per il connection tracking di protocolli particolari.
Lo script Patch'O'Matic permette di applicare facilmente le patch sperimentali sui sorgenti del proprio kernel.

Extra MATCH
condition - Match sulla base della presenza di file nel proc filesystem
connlimit - Permette di limitare il numero di connessioni per host
comment - Permette di aggiungere un commento alla regola
geoip - Controllo degli IP secondo la nazione di provenienza
nth - Controllo sulla base di logiche di alternanza configurabili
psd - Post Scan Detector
quota - Controllo delle quote di traffico
random - Gestione di regole sulla base di logiche random
string - Controllo a livello di payload: in pratica layer 7 filtering
time - Controllo sulla base dell'ora o del giorno

Extra TARGET
ACCOUNT - Per fare accounting (ad alta velocità) dei pacchetti matchati  
NETMAP - Utilizzabile per nattare 1:1 intere reti
ROUTE - Utile per modificare il routing di determinati pacchetti
TARPIT - Introduce una tarpit, una sorta di buco nero in cui le connessioni tendono a rimanere appese

Scenari di Load Balancing

Esistono molti metodi per fare load balancing: alcuni sono semplici e grossolani, altri usano software dedicati per monitoring e failure management.

DNS round robin
E' uno dei metodi più semplici. Il bilanciamento viene fatto assegnando diversi indirizzi allo stesso hostname. Non gestisce guasti e, anche con script di monitoraggio/aggiornamento DNS e TTL bassi non risulta essere una soluzione ideale.

Round robin tramite iptables
Esistono diversi metodi: prevedono la gestione del reindirizzamento (tipicamente tramite PREROUTING) dei pacchetti in entrata sull'IP del firewall / balancer verso diversi server reali.
Per gestire l'alternanza si può usare:
- match nth, con alternanza round robin
- match random, con alternanza random
Per gestire il controllo dei server e togliere dal pool server guasti si può abbinare il match condition per una verifica su file che possono essere gestiti da script di monitoraggio.

Linux Virtual Server
Una soluzione strutturata, più complessa ma più affidabile perchè può essere affiancata da tool di monitoring e gestione.
Richiede: Patch LVS nel kernel (ormai ufficiale) e strumenti di controllo e gestione dei servizi
Il Load Balancer può a sua volta essere ridondato con Keepalived, Ultra Monkey, Piranha, Heartbeat ecc.
LVS inoltre include progetti figli interessanti (e sperimentali):
TCPHA - Supporto di strutture con triangolazione del traffico (Internet->Directory->RealServer->Internet) senza gestire i pacchetti di ritorno dai server tramite il Balancer
KTCPVS (Kernel TCP Virtual Server) implementa load balancing a livello applicativo.

Iptables Patch'O'Matic

Autore: al - Ultimo Aggiornamento: 2005-06-01 10:21:27 - Data di creazione: 2004-10-30 01:30:26
Tipo Infobox: DESCRIPTION - Skill: 5- SENIOR

Il team di sviluppatori di Netfilter e i loro collaboratori hanno realizzato numerose patch che allargano in modo considerevole le funzionalità del codice base, normalmente incluso nel kernel.
Molte di queste non sono incluse nel codice ufficiale del kernel in quanto considerate sperimentali, non completamente stabili o non necessarie, alcune lo saranno in futuro o sono incluse nel ramo 2.6 ma non nel 2.4, alcune sono incluse nei kernel forniti da specifiche distribuzioni.
Esiste comunque la possibilità di inserirle in un proprio kernel custom utilizzando Patch'O'Matic (POM), un comodo strumento realizzato dagli autori di Netfilter.

INTRODUZIONE
Per applicare le patch aggiuntive sul codice del proprio kernel sono necessari:
- I sorgenti del kernel (normalmente scompattati nella directory /usr/src/linux o /usr/src/kernel-versione o simili) su cui verranno applicate le patch
- I sorgenti di iptables, scaricabili dal sito ufficiale http://www.netfilter.org/ che vanno ricompilati per supportare le nuove opzioni introdotte
- I sorgenti di patch'o'matic, anch'essi scaricabili dal sito ufficiale. Notare che dai primi di Gennaio 2005 il team di Netfilter ha smesso di rilasciare release ufficiali di patch'o'matic, per cui è interessato a queste patch si deve basare sulle release "current" rilasciate regolarmente.

Le patch (sono numerose e variegate) sono divise in diversi gruppi:
submitted - Patch proposte e sottoposte per l'inclusione nel kernel ufficiale
pending - Patch che sono in attesa di essere proposte per essere incluse nel kernel ufficiale
base - Patch di base, comunque sperimentali e non testate in modo approfondito  
extra - Tutte le patch disponibili, numerose, variegate e sperimentali
obsolete - Codice obsoleto o deprecato.
Notare che esistono patch in conflitto fra loro, che non vanno compilate sullo stesso kernel. Generalmente i conflitti, le dipendenze e le incompatibilità sono indicate per ogni patch.

INSTALLAZIONE
Si scaricano e scompattano i sorgenti. Non essendoci più release ufficiali di POM, in questo esempio si è ricorso all'ultimo snapshot, con tutti i rischi del caso nell'usare software in testing.
wget http://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/patch-o-matic-ng-20050413.tar.bz2
tar -jxvf patch-o-matic-ng-20050413.tar.bz2
cd patch-o-matic-ng-20050413

A questo punto si può procedere con la procedura standard di POM:
export KERNEL_DIR=/usr/src/kerneldir Indicare la directory dove si trovano i sorgenti del kernel da patchare
export IPTABLES_DIR=/usr/src/iptablesdir Dove sono stati scompattati i sorgenti di iptables
./runme pending

Alternativamente eseguire ./runme base o ./runme extra per includere i diversi gruppi.
Per ogni patch viene data una breve spiegazione e chiesto se si vuole inserirla nel kernel.
Una volta completata questa operazione sarà possibile procedere alla compilazione del kernel secondo le solite procedure. Nel menu di configurazione del kernel tutte le patch aggiuntive sono include nella voce NetFilter Configuration del menu Networking options.
Oltre ai moduli del kernel, patch'O'matic permette di patchare il mondo userland del comando iptables, in modo da gestire le nuove funzionalità.

PATCH (+) INTERESSANTI
Vediamo alcune delle patch più interessanti che POM mette a disposizione, queste riguardano soprattutto nuovi criteri di matching dei pacchetti e nuovi target:

match: comment
Questa patch, già inclusa nel kernel ufficiale 2.6, permette di aggiungere un commento ad una regola, introducento il modulo di match comment con l'unica opzione --comment.
Esempio: -A INPUT -s 213.215.144.242 -m comment --comment "Host Webmaster"
Voce nel kernel .config: CONFIG_IP_NF_MATCH_COMMENT
Nome modulo: ipt_comment

target: NETMAP
Ancora sperimentale, presente nel repository base, introduce il target NETMAP che permette di nattare 1 a 1 tutti gli host di intere reti senza specificare i singoli IP. Comodo per firewall che nattano tutti i propri server in una DMZ con IP privati o per fare double natting per far comunicare reti con gli IP privati sovrapposti.
Esempio: iptables -t nat -A PREROUTING -d 213.215.144.128/25 -j NETMAP --to 10.0.0.128/25
Si può usare anche per source natting: iptables -t nat -A POSTROUTING -s 213.215.144.128/25 -j NETMAP --to 10.0.0.128/25
Voce nel kernel .config: CONFIG_IP_NF_TARGET_NETMAP
Nome modulo: ipt_NETMAP

match: connlimit
Patch sperimentale che imposta un numero massimo di connessioni tcp da un singolo arbitrario host IP o da una intera rete. Introduce il match connlimit con le opzioni --connlimit-above (determina il numero massimo di connessioni) e --connlimit-mask (imposta il limite allargandolo ad una intera rete, definendola tramite i subnet bit, ad esempio 24. Di default si limita al singolo host: 32)
Esempi:
Per limitare l'accesso SSH a due sole connessioni per IP sorgente:
-I INPUT -p tcp --dport 22 --syn -m connlimit --connlimit-above 2 -j DROP
Per impostare massimo 16 connessioni per rete di 256 indirizzi ad un server web dietro il firewall Linux:
-A FORWARD -d 213.215.144.242 -p tcp -m tcp --dport 80 --syn -m connlimit --connlimit-above 16 --connlimit-mask 32 -j DROP
Per impostare a 250 il numero massimo di connessioni contemporanee che possono essere fatte ad un server SMTP:
-A FORWARD -d 213.215.144.242 -p tcp -m tcp --dport 25 --syn -m connlimit --connlimit-above 250 --connlimit-mask 0 -j DROP
Voce nel kernel .config: CONFIG_IP_NF_MATCH_CONNLIMIT
Nome modulo: ipt_connlimit

match: iprange
Comoda patch che permette di fare il match su un range di IP sorgenti o destinazione. Introduce il modulo di match iprange con le opzioni: --src-range (range di IP sorgenti, es: 10.0.0.0-10.0.255.255) e --dst-range.
Esempio: iptables -A FORWARD -m iprange --dst-range 10.0.0.0-10.0.255.255 -j ACCEPT
Voce nel kernel .config: CONFIG_IP_NF_MATCH_IPRANGE
Nome modulo: ipt_iprange

match: nth
Curiosa e versatile patch che permette di fare un match ogni n pacchetti sulla base di opzioni varie, mettendo a disposizione di default 16 "contatori" indipendenti. Introduce il match nth con le opzioni:
--every Imposta ogni quanti pacchetti eseguire il match
--counter Definisce il contatore da utilizzare (di default 0)
--start Definisce a quale pacchetto iniziare a contare (di default 0)
--packet Definisce quale pacchetto all'interno del contatore matchare. Se viene definito va inserira una regola per ogni --packet da 0 a N-1
Esempio senza l'uso di --packet per loggare un pacchetto ogni 10, in entrata: iptables -I INPUT -m nth --every 10 -j LOG
Esempio per un semplice ma efficace load balancer dove tutti i pacchetti alla porta 80 dell'IP pubblico vengono forwardati in modalità round robin a 3 diversi server web nattati (viene usato il contatore 1):
iptables -t nat -A PREROUTING -d 213.215.144.242 -p tcp --dport 80 -m nth --counter 1 --every 3 --packet 0 -j DNAT --to-dest 10.0.0.10:80
iptables -t nat -A PREROUTING -d 213.215.144.242 -p tcp --dport 80 -m nth --counter 1 --every 3 --packet 1 -j DNAT --to-dest 10.0.0.11:80
iptables -t nat -A PREROUTING -d 213.215.144.242 -p tcp --dport 80 -m nth --counter 1 --every 3 --packet 2 -j DNAT --to-dest 10.0.0.12:80

Voce nel kernel .config: CONFIG_IP_NF_MATCH_NTH
Nome modulo: ipt_nth

match: psd
E' possibile identificare dei Port Scan tramite il match psd con le seguenti opzioni:
--psd-weight-threshold Peso degli ultimi pacchetti TCP/UDP a porte di destinazione diverse proveniente dallo stesso host.
--psd-delay-threshold Ritardo, in centesimi di secondi, per considerare pacchetti a porte diverse come dovuti ad un port scan
--psd-lo-ports-weight Peso dei pacchetti destinate a porte privilegiate (<=1024).
--psd-hi-ports-weight Peso dei pacchetti destinati a porte non privilegiate.
Un esempio essenziale per aggiungere un log, che può essere verboso, di tutti gli scan (Consigliabile aggiungerlo alla fine della catena di INPUT, con un default DROP finale):
iptables -A INPUT -m psd -j LOG --log-prefix "PORTSCAN: "
Voce nel kernel .config: CONFIG_IP_NF_MATCH_PSD
Nome modulo: ipt_psd

match: quota
Implementa il match quota con cui si definisce un contatore relativo al traffico di rete che si vuole permettere (o comunque matchare). Unica opzione: --quota (numero di byte massimi).
Esempio: iptables -A FORWARD -m quota --quota 1024000 -d 10.0.0.5 -j ACCEPT
Voce nel kernel .config: CONFIG_IP_NF_MATCH_QUOTA
Nome modulo: ipt_quota

match: random
Un curioso match random che introduce la possibiltà  di definire regole con possibilità di match random in base all'opzione: --average che indica la percentuale media di match (di default il 50%)
Esempio: iptables -A INPUT -m random --average 10 -d 10.0.0.5 -j LOG
Voce nel kernel .config: CONFIG_IP_NF_MATCH_RANDOM
Nome modulo: ipt_random

match: time
Permete di creare regole sulla base dell'ora, della data o del giorno della settimana. Introduce il match time con le seguenti opzioni:
--timestart value - Match se l'ora locale è successiva a quella indicata (HH:MM, default 00:00).
--timestop  value - Match se l'ora è prima di quella indicata (default 23:59).
--days - Giorno della settimana (formato: Mon,Tue,Wed,Thu,Fri,Sat,Sun ; default tutti i giorni)
--datestart - Match se la data è successiva a quella indicatata (Formato: YYYY[:MM[:DD[:hh[:mm[:ss]]]]])
--datestop - Match se la data locale è prima di quella indicata (Formato YYYY[:MM[:DD[:hh[:mm[:ss]]]]])
Esempio per permettere l'accesso solo in orari lavorativi:
iptables -A INPUT -m time --timestart 8:00 --timestop 18:00 --days Mon,Tue,Wed,Thu,Fri -j ACCEPT
Esempio per permettere l'accesso solo fino al 31 Dicembre 2005:
iptables -A INPUT -m time --datestop 2005:12:31:23:59 -j ACCEPT
Voce nel kernel .config: CONFIG_IP_NF_MATCH_TIME
Nome modulo: ipt_time

match: condition
Fornisce un meccanismo di matching che può rivelarsi estremamente flessibile per modificare le regole di firewalling secondo il contenuto di un file.
In pratica permette di verificare se un file qualsiasi nella directory /proc/net/ipt_condition/ ha valore 0 o 1.
Esempio per aprire la porta 80 se il file  /proc/net/ipt_condition/openweb ha contenuto "1":
iptables -A INPUT -m condition --condition openweb -p tcp --dport 80 -j ACCEPT
Voce nel kernel .config: CONFIG_IP_NF_MATCH_CONDITION
Nome modulo: ipt_condition

match: geoip
Rivoluzionario modulo per eseguire filtering sulla base della nazione da cui proviene un IP. Si appoggia ad un database GeoIP, ha bisogno dei file /var/geoip/geoipdb.bin e /var/geoip/geoipdb.idx su quali eseguire il check sulle nazioni a cui sono associati i vari IP.
I database si possono creare con l'utility csv2bin o scaricare da http://people.netfilter.org/peejix/geoip/database/.
Voce nel kernel .config: CONFIG_IP_NF_MATCH_GEOIP
Nome modulo: ipt_geoip

match: string
Permette il match di una stringa nel contenuto di un pacchetto. Di fatto, seppur non è questo l'utilizzo migliore perchè non prevede la conoscenza della logica del protocollo, permette filtering a livello applicativo.
Esempio classico per loggare CodeRed e affini (notare che non esclude falsi positivi): iptables -I INPUT -p tcp -s 0.0.0.0/0 -m string --string "cmd.exe" -j LOG
Voce nel kernel .config: CONFIG_IP_NF_MATCH_STRING
Nome modulo: ipt_string

High Availability Firewall

Ogni soluzione di High Availability esistente su linux per un cluster applicativo si può applicare ad un firewall, che lavora a livello di kernel
Gli scenari sono comuni:
- Cluster Attivo-Passivo (con programmi come Heartbeat) o Attivo-Attivo
- Non si sono grossi problemi di filesystem, i dati coinvolti sono pochi e poco variabili: si possono usare sistemi gemelli con meccanismi di sincronizzazione della configurazione del firewall (brbd, rsync, ssh)
- Oltre a cluster, si possono usare soluzioni di load balancing
- Al momento non è supportato uno stateful failover: le connessioni esistenti, in uno switch attivo-passivo, vengono interrotte.

Soluzioni possibili (Alcune)
- Heartbeat + rsync|ssh scripts (Cluster HA con sincronizzazione dei file gestita tramite script e fatta via rsync o ssh con chiavi autorizzate)
- Heartbeat + DRBD (Cluster HA con file system sincronizzato tramite network mirroring con DRBD)
- Linux Virtual Server (LVS) Sistema di Load Balancing basato su Linux Virtual Server
- LVS + Ultramonkey - Sistema LVS con HA su Director gestito con Ultramonkey
- LVS + Keepalived - Sistema LVS con Keepalived per monitoring e gestione failvover
- LVS + Piranha - Sistema LVS con HA su Director gestito con Ultramonkey
- LVS + Heartbeat - Sistema LVS con Heartbeat e sistemi di storage sharing

Links
Linux Virtual Server - http://www.linuxvirtualserver.org/
Keepalived - http://www.keepalived.org/
Heartbeat - http://www.linux-ha.org/

Configurazione Kernel Linux per il firewalling

Autore: neo - ( Revisione: al ) - Ultimo Aggiornamento: 2002-10-04 01:20:15 - Data di creazione: 2002-10-04 01:20:15
Tipo Infobox: DESCRIPTION - Skill: 5- SENIOR

Per far si che il nostro linux funga da firewall, dovremo compilare il kernel abilitando il netfiltering e alcune sue features a seconda dello scopo e del tipo di traffico che dovra' filtrare.
Come la maggior parte delle features del kernel linux si ha la possibilita' di selezionarle come moduli oppure compilarli all'interno del kernel se si preferisce un kernel monolitico.

Di seguito vengono messe in evidenza le piu' importanti opzioni da considerare nella fase di configurazione del kernel per attivare e gestire il packet filtering:

CONFIG_PACKET
Permette a varie applicazione ed utility di lavorare direttamente sui device di rete
CONFIG_NETFILTER
DA ABILITARE!! Di fatto e' l'opzione base che vi permettera' anche di accedere al menu delle singole opzioni di iptables
CONFIG_IP_NF_CONNTRACK
Modulo che permette il tracking delle connessioni, utilizzato per il NAT e masquerading
CONFIG_IP_NF_FTP
Modulo che permette il tracking delle connessioni FTP, utile se volete fare firewall perimetrale o di contenimento che devono gestire anche traffico ftp. Bene o male FTP si utilizza ovunque, direi DA ABILITARE.

CONFIG_IP_NF_IPTABLES
DA ABILITARE!! Opzione che permette qualsiasi tipo di filtering, NAT e masquerading. Praticamento e' il core delle iptables
CONFIG_IP_NF_MATCH_LIMIT
Opzione non obbligatoria, ma permette di fare filtering sulle connessioni, stabilendo che un certo numero di pacchetti in un certo limite di tempo devono matchare alcune regole. Utile per difendersi da attacchi DoS
CONFIG_IP_NF_MATCH_MAC
Opzione che permette l'utilizzo del MAC address per il matching delle regole. Comodo se si hanno poche macchine da gestire, ma sarete pesantemente dipendenti dall'hardware che utilizzerete
CONFIG_IP_NF_MATCH_MARK
Abilita la possibilita' di fare il matching tramite il MARK dei pacchetti.
CONFIG_IP_NF_MATCH_MULTIPORT
Permette di filtrare le connessioni specificando un range di sorce port e destination port. DA ABILITARE
CONFIG_IP_NF_MATCH_TOS
Permette il filetring tramite TOS (Type of Service). ONLY FOR EXPERT
CONFIG_IP_NF_MATCH_TCPMSS
Abilita' la possibilita del matching del MSS field. ONLY FOR EXPERT
CONFIG_IP_NF_MATCH_STATE
Permette il stateful matching delle connessioni. DA ABILITARE !!
CONFIG_IP_NF_MATCH_UNCLEAN
Opzione che permette di filtrare il traffico TCP,UDP,ICMP che sono considerati invalidi. DA ABILITARE, ma ricordarsi che non funziona del tutto corettamente in tutti i casi
CONFIG_IP_NF_MATCH_OWNER
Ci permette di filtrare le socket, abilitando un'utente specifico per aprire un certo tipo di socket. E' ANCORA IN FASE DI SVILUPPO
CONFIG_IP_NF_FILTER
Modulo base per il packet filetering. DA AGGIUNGERE!!
CONFIG_IP_NF_TARGET_REJECT
Modulo che permette di specificare che i messagi di ICMP error di essere inviati alla sorgente
CONFIG_IP_NF_TARGET_MIRROR
Abilita il bounced back (rimbalzati indietro) dei pacchetti al sender. ES. se si decide di mettere un MIRROR target sulle porte di destinazione di HTTP (80), tutte le richieste verranno replicate al sender e poi seguite dai pacchetti contenenti le informazioni per visualizzare la pagina
CONFIG_IP_NF_NAT
Modulo che abilita il NAT, Port forwarding e masquerading. DA ABILIATRE se si vuole translare gli ip sorgente o di destinazione
CONFIG_IP_NF_TARGET_MASQUERADE
Modulo che permette di aggiungere il TARGET per il masquerading. DA ABILITARE, se si vuole fare masquerading.
CONFIG_IP_NF_TARGET_REDIRECT
Opzione che permette che vi permette di far funzionare il vostro firewall come se fosse un transparent proxy
CONFIG_IP_NF_TARGET_LOG
Permette la possibilita' di loggare i packetti. DA ABILITARE, anche se quello che si logga dipende dalle vostre regole. Se decidete di abilitare questa opzione e di loggare in syslog, utilizzate tools per avere un report del entry registrate nel log sia per rendere la lettura dei log piu' comprensibile sia per la possibilita' di mantenere una history
CONFIG_IP_NF_TARGET_TCPMSS
Questa opzione viene utilizzata per ovviare a vari problemi con host o ISP che bloccano i pacchetti che richiedono l'ICMP Fragmentation.
CONFIG_IP_NF_COMPAT_IPCHAINS
Abilita la compatibilita' con le vecchie IPCHAINS. DA ABILIATRE solo in caso di bisogno
CONFIG_IP_NF_COMPAT_IPFWADM
Abilita la compatibilita' con le vecchie IPCHAINS. DA ABILIATRE solo in caso di bisogno

Esistono altri parametri configurabili in run-time ovvero dopo che il kernel e' stato caricato e il sistema è in funzione.
Si hanno piu' possibilita' per modificare questi parametri, quello piu' corretto e' quello di modificare i vari parametri editando /etc/sysctl.conf oppure usare il comando sysctl o scrivendo direttamente i valori voluti nel proc filesystem.
Questa operazione viene normalmente eseguita tramite script lanciati al boot della macchina.

Segue un elenco delle principali opzioni modificabili in modalita' run-time per quanto riguarda il network, ovviamente nel dubbio è meglio lasciare i valori di default, salvo quelli strettamente necessari per un firewall (ip_forward).
I valori che si possono assumere sono di tipo:
- BOOLEAN = 0 (disabilita) e 1(abilita)
- INTEGER = N , dove N e' un mumero intero Es 64
- N INTEGERS = X Y Z , N indica il numero dei valori(interi) da inserire, e X Y Z i valori che acquisisce la variabile

Tutte le variabili fanno riferimento a /proc/sys/net/ipv4/*:
ip_forward BOOLEAN - Permette il forwarding dei pacchetti fra le interfacce. DA ABILITARE.
ipfrag_high_thresh INTEGER - La massima memoria utilizzata per riassemblare i pacchetti IP frammentati. Quando questo valore verra' raggiunto, i pacchetti in surplus verranno scartati finche' non si raggiungera' di nuovo il valore settato in ip_frag_low_thresh
ipfrag_time INTEGER - Indica il tempo max in secondi per mantenere in memoria un "IP fragment"
tcp_syn_retries INTEGER - Indica il numero di volte che un SYN deve essere ritrasmesso per i tentativi di una connessione TCP attiva (non puo' essere piu' grande di 255)
tcp_synack_retries INTEGER - Indica il numero delle volte che un SYNACK deve essere ritrasmesso per i tentavi di connessioni TCP passive (non puo' essere piu' grande di 255)
tcp_keepalive_time INTEGER - Indica quanto spesso verra' inviato il messaggio TCP di keepalive. Default 2hdsfsfds
tcp_keepalive_probes INTEGER -  Indica quanti pacchetti Keepalive probes verranno inviati, finche' la connessione verra' considerata definitivamente broken
tcp_keepalive_interval INTEGER - Indica quanto frequentemente i pacchetti di probe sono inviati. Moltiplicando per tcp_keepalive_probes si ottiene il tempo per il KILL di una connessione che non risponde ai pacchetti di probes.
tcp_retries1 INTEGER - Indica il numero di tentativi/richieste prima che venga segnalato al network layer che sulla connessione c'e' qualcosa che non va.
tcp_retries2 INTEGER - Indica il numero di tentativi/richieste prima di killare una sessione TCP attiva
tcp_orphan_retries INTEGER - Indica il numero dei tentativi/richieste prima che una connessione TCP venga killata
tcp_fin_timeout INTEGER - Indica il tempo per cui mantenere una socket nello status di FIN-WAIT-2
tcp_max_tw_buckets INTEGER - Indica il numero massimo di socket simultanee in timewait che mantiene il sistema
tcp_max_orphans INTEGER - Numero massimo di socket TCP che possono rimanere non collegati a file handle aperti dal sistema.
tcp_abort_on_overflow BOOLEAN - Permette il reset di una connessione se un servizio in listening e' troppo lento per rispondere.
tcp_sysncookies BOOLEAN - Opzione valida solo se il kernel e' stato compilato con il supporto dei SYNCOOKIES, previene possibili "syn flood attack"
tcp_timestamps BOOLEAN - Abilita o disabilita il timestamp
tcp_ecn BOOLEAN - Abilita o disabilta  la notificazione di una possibile congestione della network
ip_local_port_range 2 INTEGERS - Desinisce il range delle porte locali, utilizzate  dal  protocollo TCP e UDP. Il primo numero indica la porta piu' bassa ed il secondo indica la porta piu' alta. Il valore di default dipende dal quantitativo di ram disponibile sul sistema
ip_dynaddr BOOLEAN  - Se settato non a zero abilita il supporto per il dynamic addresses
icmp_echo_ignore_all BOOLEAN - Ignora i Ping (ICMP ECHO Request)
icmp_echo_ignore_broadcasts BOOLEAN -  Se settati entrambi il sistema ignora gli ICMP ECHO solo verso indirizzi di broadcast/multicast
log_martians BOOLEAN - Logga i pacchetti con indirizzi impossibili.
accept_redirects BOOLEAN - Accetta o meno gli ICMP redirect
forwarding BOOLEAN -  Abilita il forwarding per una specifica interfaccia
proxy_arp BOOLEAN - Abilita il proxy arp.
secure_redirects BOOLEAN - Accetta ICMP redirect message solo dai gw configurati.
La modifica di alcuni parametri potrebbe pregiudicare il buon funzionamento del sistema, ma può essere necessaria per il fine tuning di sistemi sotto particolari carichi di rete.
Per maggiori informazioni e indicazioni utili sui parametri raccomandabili fare riferimento direttamente al file Documentation/networking/ip-sysctl.txt nel tarball del kernel.

Strumenti di analisi e monitoring

Analizzare i dati di traffico di iptables può essere utile.
In particolare è comodo verificare tutti i pacchetti droppati dal firewall.
I target LOG e ULOG permettono il logging dei pacchetti.

LOG genera una riga di testo via syslog per ogni pacchetto matchato. Strumenti che possono analizzare questi log sono:
Iptables Log Analyzer http://www.gege.org/iptables/
Usa uno script Perl per processare i log e scriverli su MySQL. L'output è una pagina php con dati in tempo reale.
LogRep http://logrep.sourceforge.net/
E' un versatile analizzatore di log di diverso tipo, include il supporto di iptables.
LogWatch http://www.logwatch.org/
E' un diffuso analizzatore di log generici. Invia mail con l'analisi e il riassunto dei log. Intepreta anche l'output di iptables.
ULOG tramite ulogd permette una gestione più comoda dei log su database. Fra i tool che usano ulogd:
Webfwlog Firewall Log Analyzer http://webfwlog.sourceforge.net
Fornisce pagine php spartane ma complete e configurabili.
Ulog-php http://www.inl.fr/article.php3?id_article=7
Pagina php essenziale ma completa che interroga log salvati su MySQL da ulodg.

Per informazioni sugli strumenti, i metodi e le alternative per la gestione e l'analisi dei log: http://www.loganalysis.org/

Logging dei pacchetti

E' possibile loggare i pacchetti tramite il target LOG (log tramite syslog con facility kern) o ULOG (log tramite programmi in userspace).
Entrambi i target, a differenza di molti altri, NON interrompono il preseguimento di una catena.
Per pianificare le logiche di logging è opportuno:
- Decidere cosa si vuole loggare (di solito i pacchetti droppati)
- Definire come sono impostare le regole sul firewall
- Applicare le regole di log al posto giusto.

Se si vuole loggare solo i pacchetti droppati inserire una regola di LOG appena prima di ogni analoga regola di DROP.
Se si ha un DROP di default e si prevedono solo regole di ACCEPT, mettere la regola di LOG alla fine di una catena.

Nel target LOG è possibile definire:
- il livello di criticità per syslog (--log-level level);
- un prefisso, fino a 32 caratteri, per distinguere una riga di log (--log-prefix prefix);
- i dettagli da includere (--log-tcp-sequence , --log-tcp-options , --log-ip-options)

Nel target ULOG è possibile definire:
- il gruppo netlink (1-32) a cui il kernel manda in multicast i pacchetti (--ulog-nlgroup nlgroup). Default = 1.
- un prefisso, fino a 32 caratteri, per distinguere una riga di log (--ulog-prefix prefix);
- numeri di byte da copiare in userspace (Default = 0, tutti i byte del pacchetto) (--ulog-cprange size)
- numero di pacchetti da mettere in code nel kernel prima di inviarli al netlink. Default = 1 (--ulog-qthreshold size)

Criteri avanzati di match

Oltre alla possibilità di matchare pacchetti sulla base di logiche comuni, esistono delle estensioni particolarmente potenti e versatili.
Vanno richiamate con -m match e possono avere delle opzioni specifiche per il modulo di match utilizzato.
ADDRESS TYPE (-m addrtype) - Match sul tipo di pacchetto sulla base del suo indirizzo (es: UNSPEC, UNICAST, MULTICAST, BROADCAST, ANYCAST, LOCAL, BLACKHOLE... )
Es: iptables -I INPUT -m addrtype --src-type UNSPEC --dst-type UNICAST -j LOG
CONNECTION RATE (-m connrate) - Match sulla velocità di connessione in byte/secondo.
Es: iptables -I FORWARD -m connrate --connrate :36000 -d 213.215.151.8 -j ACCEPT
LIMIT (-m limit) - Impostazione di limiti sulla base di pacchetti /secondo /minuto /ora /giorno.
Es: iptables -I FORWARD -p tcp --syn -m limit --limit 10/second --limit-burst 20/second -d 213.215.151.8 -j ACCEPT
MAC ADDRESS (-m mac) - Match sul mac address di un frame ethernet.
Es: iptables -I INPUT -m mac --mac-source 00:50:8B:4D:55:BB -j ACCEPT
MULTIPORT (-m multiport) - Permette di definire più porte (sorgente o destinazaione).
Es: iptables -I INPUT -p tcp -m multiport --destination-port 25,80,110,143,443,993,995 -j ACCEPT
OWNER (-m owner) - Match di un pacchetto in uscita secondo onwer, pid o nome del processo che lo ha generato.
Es: iptables -I OUTPUT -m onwer --uid-owner 501 -j ACCEPT
PACKET TYPE (-m pkttype) - Match sul tipo di pacchetto a livello di datalink (UNICAST, MULTICAST, BROADCAST)
Es: iptables -I INPUT -m pkttype --pkt-type UNICAST -j LOG

Logging con Iptables

Autore: al - ( Revisione: al ) - Ultimo Aggiornamento: 2005-05-14 22:11:24 - Data di creazione: 2003-02-24 17:00:18
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE

Iptables mette a disposizione la possibilità di loggare pacchetti per debugging e analisi del traffico.
Di fatto il log generato da iptables può essere utile sia per verificare le funzionalità delle regole inserite sia per essere analizzato da tool per creare statistiche e report.

Il logging viene abilitato tramite target LOG che lavora in kernel space e usa syslog per scrivere i log o con ULOG per trasmettere a programmi in user space le informazioni di log.
E' buon senso loggare solo i pacchetti che vengono bloccati, in modo da avere informazioni utili per troubleshooting (in fase di configurazione e test del firewall) e sicurezza (per capire i volumi e la qualità del traffico non desiderato).

A differenza di molti altri, i target LOG e ULOG non interrompono l'attraversamento di una catena: i pacchetti che matchano una regola di (U)LOG vengono loggati e continuano ad essere processati venendo gestiti da netfilter secondo le regole successive.

In un firewall, che di default blocca tutto, la regola di logging dovrebbe essere l'ultima prima del DROP di default.

Il target LOG
Il target LOG (-j LOG) permette di definire diverse opzioni:
--log-level # - Livello di logging, secondo le logiche di syslog, utile, insieme alla configurazione di syslog.conf, per loggare i dati sui pacchetti su file separato.
--log-prefix stringa - Una stringa, lunga fino a 29 caratteri, che viene messa come prefisso alla riga di log, per renderlo più leggibile e associarlo ad un dato tipo di traffico
--log-tcp-sequence - Logga il TCP sequence naumber. Dato sensibile, se accessibile ad altri utenti locali.
--log-tcp-options - Logga le opzioni presenti nell'intestazione TCP
--log-ip-options - Logga le opzioni presenti nell'intestazione IP (come il precedente può essere utile per strumenti di analisi dei log, altrimenti, se le informazioni aggiuntive non si reputano interessanti, è meglio disattivare)
--log-uid - Logga lo UserID del processo che ha generato il pacchetto (in OUTPUT).

Il target ULOG
Meno diffuso e usato rispetto a LOG, ULOG fornisce maggiore flessibilità ed estende notevolmente il campo di applicazioni possibili.
Redireziona infatti in multicast il pacchetto che ha matchato la regola su una netlink socket a cui possono legarsi uno o più processi in userspace ricevendo i pacchetti senza che un loro eventuale malfunzionamento interrompa la gestione del traffico da parte di netfilter.
I programmi che ricevono i pacchetti li possono quindi trattare per molteplici scopi:
- Logging su database o in formati diversi da quello standard via syslog del target LOG
- Ispezioni dei pacchetti per matching su tipologie di traffico articolate, come le regole di un IDS quale SNORT
- Attivazione di meccanismi di Intrusion Prevention, interrompendo flussi di traffico indesiderati o pericolosi
Le applicazioni possono essere molte e modulari e possono essere sviluppate come componenti esterne al kernel.
Una di queste è ULogD che funziona come un servizio e utilizza diversi plugin per gestire i dati in vario modo, tra cui la possibilità di loggare su database MySQL o PostgreSQL
--ulog-nlgroup nlgroup - Definisce il gruppo netlink (1-32) a cui è indirizzato il pacchetto. Di default è 1
--ulog-prefix prefix - Come su LOG, imposta una stringa come prefisso alla riga di log (max 32 caratteri)
--ulog-cprange # - Numero di byte da copiare in user space. Di default è 0 e l'intero pacchetto viene inviato
--ulog-qthreshold # - Numero di pacchetti che il kernel deve avere in coda prima di inviarli al netlink. Default è 1

Esempi
Per loggare i pacchetti sulle catene di filter FORWARD, INPUT e OUTPUT aggiungendo in ogni riga di log adeguato prefisso.
iptables -A FORWARD -j LOG --log-prefix="FORWARD: "
iptables -A INPUT -j LOG --log-prefix="INPUT:"
iptables -A OUTPUT -j LOG --log-prefix="OUTPUT:"


Per loggare tutti i pacchetti UDP in INPUT con porta sorgente diversa da 137,138 e 139, inserendo come prefisso INPUT UDP:
iptables -A INPUT -p UDP --source-port ! 137:139 -j LOG --log-prefix="INPUT UDP:"

Per loggare tramite ULOG:
iptables -A INPUT -j ULOG --log-prefix="INPUT:"
In esecuzione sul sistema deve  esserci us servizio come ulogd in grado di intercettare il multicast su netlink.

Un buona regola di log da appendere alla fine di una catena con policy di default DROP, può essere la seguente. Logga solo pacchetti di tipo unicast (comodo per evitare log di drop di multicast o broadcast inoffensivi) e con livello 7 di severity su sysylog (debug):
iptables -A INPUT -m pkttype --pkt-type unicast -j LOG --log-prefix "INPUT: " --log-level 7

Esempio di output di LOG su syslog
Feb 19 11:01:12 GIOVE kernel: FORWARD=eth1 OUT=eth0 SRC=192.168.0.98 DST=213.198.151.2 LEN=66 TOS=0x00 PREC=0x00 TTL=127 ID=165 PROTO=UDP SPT=1047 DPT=53 LEN=46

Raccomandazioni per il network tuning del Kernel

Vediamo alcune impostazioni per il kernel che possono rivelarsi interessanti per un firewall.
Possono ovviamente essere applicate via /etc/sysctl.conf e editando direttamente i file in /proc/sys/net

sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1 - Disabilita echo request su ping a brodcast (anti smurf abuse)
sysctl -w net.ipv4.conf/all/accept_redirects=0 - Impedisce la modifica del routing tramite ICMP redirection.
sysctl -w net.ipv4.conf/all/send_redirects=0
sysctl -w net.ipv4.conf.all.accept_source_route=0 - Disabilita source-routing
sysctl -w net.ipv4.conf.all.forwarding=0
sysctl -w net.ipv4.conf.all.mc_forwarding=0
sysctl -w net.ipv4.conf.all.rp_filter=1 - Forza verifiche di congruità sul traffico in ingresso e uscita
sysctl -w net.ipv4.conf.all.log_martians=1 - Logga e droppa pacchetti "marziani" che non si sa dove routare
sysctl -w net.ipv4.tcp_syncookies=1 - Abilita i syn-cookie, allocando risorse (TCP buffer) solo dopo aver ricevuto un ACK di un SYN/ACK (Utile per Syn Flood)
sysctl -w net.ipv4.tcp_max_syn_backlog=1280 - Aumenta la dimensione della coda delle socket allocate per SYN ricevuti
sysctl -w net.ipv4.tcp_keepalive_time = 1800 - Imposta a 1800 secondi (30 minuti) il tempo di keepalive per una connessione TCP. Al termine di questo tempo una connessione non chiusa ma inattiva, viene chiusa (default 7200)

Design di reti sicure - Scenari e discussioni

Una network disegnato secondo buoni principi di sicurezza dovrebbe:
- Avere firewall che limitano al massimo le porte esposte a Internet
- Avere firewall configurati per bloccare tutto, di default
- Differenziare in diversi network server pubblici, backend, e eventuale LAN interna.
- Separare fisicamente (switch diversi o VLAN) reti IP diverse
- Non avere assolutamente hsot con porte pubbliche a cavallo di due reti
- Limitare al massimo e non lasciare porte pubbliche sui firewall a cavallo di due reti
- Avere sistemi di monitoraggio e IDS isolati e non raggiungibili da Internet
- Avere sistemi di analisi dei pacchetti isolati
- Prevedere Intrusion Prevention Systems packet based e non policy based
- Aprire in modo selettivo e temporalmente limitato le porte di accesso a VPN

Privacy Policy