Web Version
Print Version
Esercitazioni (Risposte)
Esempi di configurazioni

Workshop: Approccio pratico alla sicurezza di un server Linux in rete

Seminario sulle problematiche di sicurezza pratiche di un server Linux in rete: le minacce, le porte aperte, le informazioni esposte, i metodi di aggiornamento del sistema, l'hardening di un server dopo una installazione standard. Quello che serve ad un amministratore di sistemi Linux per mettere in rete un server ragionevolmente protetto. Le slide sono accompagnate dalla dettagliata documentazione tecnica di OpenSkills sulle procedure e le tecniche effettive per affrontare gli argomenti discussi nel seminario.

Scheda Corso

ProgrammaGiorni0TargetAmministratori di sistemi LinuxPrerequisitiConoscenza base di Internet e computerObiettivoMateriali

Programma

Linux, Internet, i pericoli, le difese

Obiettivo:
- Capire le problematiche di sicurezza di un server in rete
- Tenere aggiornato il proprio sistema Linux
- Eseguire l'hardening di un server Linux dopo l'installazione

Introduzione alla sicurezza

Introduzione alle problematiche di sicurezza su Internet

Network scanning: strumenti e tecniche

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

Aggiornamento di un sistema Linux

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

Linux post-installation check-list

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

Attacchi e intrusioni

Metodi di intrusione, Intrusion Detection, attività di attacco, rootkits.

Link e documentazione sulla security

Libri, risorse, siti sulla sicurezza



Linux, Internet, i pericoli, le difese


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.


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.


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


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.


Attacchi e intrusioni

Metodi di intrusione, Intrusion Detection, attività di attacco, rootkits.

Intrusion Detection Systems (IDS) su Linux

Autore: al - Ultimo Aggiornamento: 2003-03-05 18:02:19 - Data di creazione: 2003-03-05 18:02:19
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Le attività e i campi di applicazione di un Intrusion Detection System sono vari, al punto che spesso vengono gestiti da diversi software, che nel loro insieme provvedono ad accorgersi dei tentativi di attacco o scansione di un sistema, prevedere meccanismi di notifica (Email, log, Sms) e reazione secondo eventi anche proattivi in grado di bloccare sul nascere le comunicazioni con IP da cui arrivano pacchetti ostili.
L'evoluzione naturale di un IDS relativo ad un singolo host è il Network Intrusion Detection System (NIDS) che monitora il traffico di una intera rete.

I meccanismi di individuazione di attività sospette sono diversi, ma generalmente si concentrano su:
- Verifica dei log di sistema o di specifici programmi per individuare attività anomale;
- Controllo dell'integrità dei file locali, modifiche sospette possono essere sintono di una avvenuta irruzione;
- Monitoring dei pacchetti destinati all'host, sia per reagire a pattern di attacco noti che per accorgersi di un port scan da remoto, generalmente prologo di un tentativo di intrusione.

Il mondo OpenSource offre una moltitudine di strumenti utili per questi scopi, si va da piccoli programmi per specifiche attività a sistemi più complessi di qualità evolute.
Per essere veramente efficace, l'implementazione di sistemi di Intrusion Detection oltre a richiedere un sostanzioso intervento sistemistico per la configurazione e la customizzazione del software usato, deve essere tale da permettere una rapida analisi: troppi log e mail di notifica sono alla lunga controproducenti e inutili se a questo non segue un controllo effettivo.
Segue un breve elenco di alcuni dei programmi più noti per le attività di Intrusion Detection.

LOG ANALYZERS
Sono programmi che monitorano le entry nei file di log di sistema e possono essere configurati per eseguire date operazioni in presenza di determinate righe di log.
E' bene che agiscano in tempo reale, dal momento che dopo una intrusione una delle prime occupazioni di un hacker è quella di cancellare le tracce eventualmente lasciate sui log vari.
In questa categoria possono rientrare:
Swatch http://swatch.sourceforge.net/ - Può monitorare in tempo reale ogni tipo di file. E' in Perl e richiede alcuni moduli generalmente non installati di default e scaricabili da CPAN, nei file di configurazione si settano le regole di pattern matching dei log e i comportanti da adottare.
Logsurfer - http://www.cert.dfn.de/eng/logsurf/ - Ha caratteristiche simili a Swatch ma presenta alcuni miglioramenti, tra cui la possibilità di correlare gli output di diversi log e, al contempo, propone un file di configurazione più complesso (è consigliabile ispirarsi agli esempio di conf esistenti).
LogWatch - http://www.logwatch.org/ - Installato di default su alcune distribuzioni Linux come RedHat monitora diversi tipi di log, secondo impostazioni configurabili e genera i relativi alert e report.
Logcheck - Prodotto da Psionic, recentemente acquisita da Cisco. Non ha più un home page ufficiale.

A prescindere dal meccanismo di controllo dei log utilizzato, alcuni accorgimenti rendono l'operazione più efficace:
- Loggare, se possibile, su una macchina remota, in modo tale da impedire la manipolazioni dei log dopo un'intrusione;
- Nel definire le regole di log checking seguire una policy di logging di tutto tranne dei messaggi noti: definire delle regole di esclusione di righe di log lecite; definire regole per l'inclusione di speciali e noti eventi sospetti; includere tutto il resto (righe di log ignote o non previste).
- NON eseguire i programmi di log check come utente root, eventuali stringhe maligne nei log potrebbero generare risultati incontrollabili;
- Allo stesso modo, non visualizzare i log da un terminale potenzialmente sensibile ad un "TERMINAL EMULATOR ATTACK" tramite caratteri escape che vengono mal utilizzati o interpretati da certi terminali (Per dettagli: http://www.digitaldefense.net/labs/papers/Termulation.txt)

FILE INTEGRITY CHECKERS
Una volta fatta con successo un'intrusione, oltre a guardarsi intorno e cercare di capire dove si trova, un hacker che vuole mantenere l'accesso e la possibilità di rientrare nel sistema provvede ad cancellare le proprie tracce dai log, ad installare trojan e programmi che aprano nuovi accessi remoti, controllino le attività degli amministratori (packet sniffers, key loggers...) servano per attacchi successivi, lanciati dall'host già violato. Queste attività sono facilitate e in parte automatizzate da rootkit dedicati ma, in ogni caso, lasciano tracce sul sistema: nuovi file copiati, log e binari modificati, cancellazioni ecc.
Gli strumenti di Integrity Check aiutano ad individuare simili manipolazioni e generalmente registrano cambiamenti nella data di creazione o modifica di un file, alterazioni dei permessi, degli attributi o dello contenuto di file di configurazione, binari di comandi più o meno comuni, testi di log ecc.
Tripwire - http://www.tripwire.org - E' uno dei primi, più evoluti e utilizzati sistemi di Integrity Check.  Oltre alla versione OpenSource ne esistono complementi proprietari che facilitano l'integrazione e la centralizzazione dei dati da diversi sistemi remoti, rendendo più agevole il monitoraggio di molti host.
Aide - http://www.cs.tut.fi/~rammer/aide.html - Si presenta come l'alternativa completamente Free a Tripwire, ha una logica simile e prevede controlli della stessa natura tramite una varietà di algoritmi di checksum.
Integrit - http://integrit.sourceforge.net/ - Altra promettente e performante alternativa a Tripwire che si presta ad essere integrata in un sistema di monitoring che utilizza diversi strumenti.
Chkrootkit - http://www.chkrootkit.org - E' una serie di script dedicati alla individuazione di rootkit noti. Oltre a controllare lo stato di alcuni binari esegue controlli di altra natura (verifica sul proc filesystem ecc.), ma non va considerato come una soluzione generica.

Una caratteristica comune di questi e altri Integrity Checkers è quella di creare una snapshop preliminare dello stato dei file di un host "pulito", adattare la configurazione per il proprio specifico sistema, eliminare controlli che producono eccessivi false-positive (troppi warning tendono ad essere ignorati) e schedulare periodicamente un check dello stato attuale del sistema rispetto allo snapshot iniziale.
In tutti i casi ci sono alcune precedure di base che è giusto seguire per migliorare la sicurezza e l'affidabilità di simili strumenti:
- Copiare i database di snapshot su un sistema remoto o comunque un mezzo non scrivibile dall'host a cui si riferiscono;
- Considerare che un checksum non è infallibile ed esistono metodi per mantenere lo stesso checksum in un file modificato (quantomeno per md5, l'algoritmo più utilizzato in questi casi);
- Controllare effettivamente i log generati e rifinire gradualmente la configurazione per evitare segnalazioni errate, falsi positivi, per file che vengono modificati a causa di normali attività sul sistema.  

PORT SCANS DETECTORS
Preludio ad ogni tentativo di intrusione è quasi sempre un network scanning remoto, con cui l'attaccante cerca di individuare le porte aperte sui sistemi bersaglio. Nonostante le tecniche di port scanning siano piuttosto evolute (nmap, per esempio, permette almeno 6 diversi tipi di scanning, più o meno "stealth") esistono sistemi per individuarle e, quindi, sapere prima ancora di subire l'attacco, quali IP remoti stanno raccogliendo informazioni sui propri sistemi.
Sebbene ogni cracker accorto cercherà di non eseguire alcuna operazione di probing o hacking, direttamente dal proprio IP, sapere da quali indirizzi può provenire una minaccia è sempre utile.
I programmi più noti per individuare un port scanning sono:
ScanLogD - http://www.openwall.com/scanlogd/ Viene eseguito come un demone, costantemente in monitoraggio di collegamenti a porte TCP locali. Utilizza dei metodi per evitare disservizi o problemi nel gestire tentativi di DOS e discriminare dei veri e propri scan da attività più innocue.
PortSentry - Anch'esso progetto della Psionic di cui non esiste più un Home ufficiale, prevede meccanismi di detection anche di stealth scan, con la possibilità di bloccare tutti gli accessi dagli indirizzi che eseguono scan o azioni ostili.

In genere un semplice port scan detector ha funzioni limitate e può essere sostituito con migliore efficacia da un NIDS in grado di individuare, oltre a normali port scan una varietà di attività di rete sospette.

NIDS, IDS, HIDS
Il mondo OpenSource offre una discreta varietà di NIDS, HIDS (Host Intrusion Detection Systems) e IDS che, però, generalmente difettano nelle interfacce di reporting e gestione, oltre che nella facilità di installazione, per le quali molte alternative commerciali offrono soluzioni più evolute.
Snort - http://www.snort.org - E' il progetto NIDS più noto nella comunità OpenSource. Seppur di non banale gestione e con un sistema di reporting piuttosto grezzo, viene utilizzato come base da molti altri prodotti che ne estendono le funzionalità migliorando la gestione e i meccanismi di reporting. Le policy di packet matching sono costantemente aggiornate sulla base di nuove vulnerabilità.
Tamandua - http://tamandua.axur.org/ - E' un progetto relativamente poco conosciuto ma interessante, è possibile convertire le regole scritte per Snort sul database di Tamandua e sono previste tutte le features tipiche di un NIDS.
Prelude - http://www.prelude-ids.org/ - E' un interessante ibrido fra un NIDS e un HIDS, che presenta sia sensori per il traffico di rete che sensori per il singolo host. Vanta prestazioni superiori a SNORT e una buona modularità.

Un buon NIDS è un ottimo strumento per avere un'idea della variegata fauna di pacchetti che arrivano ad una rete pubblica e, se ben configurato, può indubbiamente troncare sul nascere molti tentativi di intrusione.
Alcune raccomandazioni di massima valgono per ogni NIDS:
- Selezionare con cura le regole di packet matching, cercando di evitare falsi positivi troppo verbosi o relativi a rischi molto relativi (il logging di ogni PING ai nostri sistemi è assolutamente inutile).
- Tenere ragionevolmente aggiornate le regole di matching, appoggiandosi ai database online.
- Tenere in un luogo particolarmente protetto la macchina centrale, se esistono diverse sonde nella rete, o comunque quella in cui i dati vengono raccolti ed elabotati.
- Controllare con costanza le segnalazioni di warning e minacce, avendo la pazienza di rifinire le proprie configurazioni per evidenziare solo gli eventi più significativi.
- Non esagerare a implementare, o quantomeno verificare con regolarità, meccanismi proattivi che bloccano ogni comunicazione con IP da cui arrivano pacchetti molesti. Questi IP possono venire spoofati e un soggetto ostile può creare una sorta di auto DOS attack, facendo bloccare al nostro IDS comunicazioni con normali e validi indirizzi IP.

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.

Effetti e sintomi di una intrusione

Autore: al - Ultimo Aggiornamento: 2004-01-28 08:02:52 - Data di creazione: 2004-01-28 08:02:52
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Gli strumenti di Intrusion Detection disponibili sul mercato automatizzano controlli e operazioni che possono essere saltuariamente eseguite a mano o tramite strumenti inizialmente pensati per altri scopi.

I mezzi e i modi con cui ci si può accorgere della avventua intrusione in un sistema possono essere vari:
Picchi di banda, di solito in uscita, non spiegabili. Tramite strumenti come MRTG è possibile visualizzare velocemente il traffico generato da un host nel corso del tempo (giorni, settimane, mesi, anni). Questi grafici possono evidenziare con un colpo d'occhio, eventuali attività di rete anomale, in quanto a quantità. Sta poi all'ammnistratore approfondirne i motivi, che possono essere assolutamente legittimi.
Rapida occupazione di spazio su disco, che può essere dovuto ad un DOS attack che mira a saturare i log di sistema o all'uso di una macchina violata come repository per warez (software copiato, materiale pornografico... ) di varia natura. In questo caso parallelamente all'ocupazione di spazio su disco, è plausibile un aumento dell'occupazione di banda.
Defacing di un sito, è il modo più rapido e definitivo per individuare un'intrusione (e farsi individuare). I motivi per cui qualcuno possa cercare di modificare l'home page di un sito sono vari (rappresaglia ideologica o politica, semplice esibizionismo, scherno...), gli effetti sono spesso deleteri per l'immagine di chi gestisce il sito ma dal punto di vista tecnico questo risparmia agli amministratori il rischio di avere per ulteriore tempo una macchina violata su cui un intrusore può fare quello che vuole.
Comportamenti anomali del sistema, di varia natura. Possono essere malfunzionamenti o "cose strane" e inusuale che accadono sul sistema o su alcuni suoi processi. Possono avere svariate cause: malfunzionamenti hardware (problemi di disco, memoria, processore, bus ecc), software (bug, implementazioni errate) o anche essere dovuti ad una intrusione (binari modificati, trojan, modifiche al sistema).
Blocco di un processo o del sistema. Può capitare che per motivi non chiari il sistema vada in crash o un singolo processo che magari gestisce un servizio pubblico muoia. Quando accade di solito si riavvia la macchina o il processo e si ritorna a fare altro. Quando accade, in realtà, è il caso di provare ad analizzare i motivi del problema. Anche in questo caso possono essere dovuti al malfunzioanmente dell'hardware, ad un bug di un programma o anche essere conseguenza di un attacco che può anche essere andato a buon fine.
Modifica o cancellazione di log. Se ci si accorge di un simile evento (tipicamente tramite programmi di Integrity Check, ma anche con casuali osservazioni manuali o utilizzo di comandi come last o lastlog) dovrebbero subito scattare un po' di allarmi nella nostra mente e le relative verifiche. Un log è fatto per incrementare costantemente di dimensioni, senza subire modifiche nei suoi contenuti precedenti.
Notifica di amministratori di sistemi remoti che rileva attività ostile da parte dei nostri IP. In questo caso l'intrusore potrebbe utilizzare i nostri sistemi per sferrare attacchi o scan su altri sistemi in rete. Gli IP che risultano ostili sono i nostri (con le potenziali complicazioni legali del caso) per cui è necessario intervenire e verificare in fretta.
Il proprio IP è segnalato su DShield. Un ottimo strumento per verificare se un proprio IP risulta fra quelli da cui sono sferrati attacchi in rete è il sito DSHIELD, è una sorta di Distributed Intrusion Detection System, in cui sono raccolti i log degli IDS di chi contribuisce al progetto e vengono segnalati gli indirizzi IP da cui arrivano la maggior parte degli attacchi.
Esiste una comoda pagina in cui si può inserire un indirizzo IP e visualizzarne varie informazioni tra cui se è stato origine di attività ostile: http://www.dshield.org/ipinfo.php  
Nuovi utenti sul sistema, che non ci sono familiari, sono sicuramente un sintomo che dovrebbe sollevare più di un sospetto. I nomi degli utenti possono essere sfacciati (r00t, 0wn3d, dud3) o più camuffati (bins, lpr) ma se hanno a disposizione una shell che non dovrebbero avere e, soprattutto, se non si conosce il motivo della loro presenza, bisogna subito allertarsi e verificare. Non è detto che un cracker abbia bisogno di crearsi un nuovo utente per tornare sul sistema, ma se succede è evidente dimostrazione di una avvenuta intrusione.
Interfacce di rete promiscue indicano nella maggior parte dei casi che qualcuno sta provando a sniffare il traffico di rete e, per individuare anche i pacchetti non direttamente indirizzati alla macchina locale, mettono l'interfaccia di rete in "promiscuous mode". Analogamente una doppia entry nella arp cache con lo stesso IP che risulta appartenere a 2 diversi Mac Address, è sintono di una probabile attività non lecita di arp spoofing.

Password cracking

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

Per password cracking si intendono tutte quelle operazioni che permettono di reperire una password da una fonte di informazione come ad esempio un file criptato. Questi tipi di attacchi possono essere effettuati in numerevoli modalità sia da remoto, ad esempio con un Brutal force attack (un attacco che mira ad accedere al sistema tramite tentativi di login a ripetizione finchè non si trova un utente e una password validi) oppure in locale, tramite appositi tools come Crack che analizzano file come /etc/passwd.

Nei vecchi sistemi Unix queste stringhe criptate venivano salvate e verificate tramite il file /etc/passwd, durante il processo di login: username e relativa password venivano confrontati con le entry di questo file tramite la funzione chiamata crypt(), se questa funzione riproduceva una password criptata identica a quella inserita nel file l'utente poteva accedere.
L'inconveniente era che il file /etc/passwd doveva essere leggibili da ogni utente del sistema e quindi le password ivi criptate potevano essere viste da chiunque rendendo vulnerabile il sistema ad un password attack.
Per ovviare a questo problema ci si è appoggiati ad un secondo file leggibile solo da root, /etc/shadow (nella maggior parte degli *nix) il quale contiene le password criptate, ovviamente sempre affiancato a un /etc/passwd (sempre leggibile da chiunque) senza le password criptate.
Ormai tale configurazione è quella adottata da tutte le distribuzioni GNU Linux dove sono a disposizione (in configurazione standard) due algoritmi di criptazione one-way DES e MD5, i due algoritmi sono in grado di generare una stringa criptata da una password ma non viceversa e rendono "difficile" effettuare un cracking della password in poco tempo.
Inoltre occorre sottolineare che il cracking delle password non viene effettuato solo per eseguire un login su una shell ma in tutti quei casi in cui occorre inserire usename e password per accedere ad un servizio, dunque occorre prestare attenzione non solo alle password di sistema ma anche a quelle dei servizi correlati (per esempio gli accessi via web ad un'area protetta).
Al riguardo va fatta attenzione a dove viene mantenuto l'eventuale file delle password, da quali utenti è leggibile, se esistono password di default (che vanno ovviamente cambiate) o accessi anonimi.

Esistono innumerevoli tools come Crack o John the ripper che semplificano le operazioni di password cracking, questi stessi strumenti possono essere utilizzati dallo stesso system administrator per verificare la robustezza degli account sul proprio sistema.

(Bad) Hackers' Tools: rootkits

Autore: al - Ultimo Aggiornamento: 2003-05-07 12:41:31 - Data di creazione: 2003-05-07 12:41:31
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE

Un rootkit è una collezione di tool che permette ad un cracker di cancellare le proprie tracce e assicurarsi la possibilità di rientrare sul sistema bucato, senza dover riutilizzare il buco di sicurezza con cui originariamente ha preso possesso della macchina.

I rootkit non servono per violare un sistema, vengono utilizzati solo quando è stato già compromesso e nella gran parte dei casi possono essere installati solo dall'utente root.
Generalmente un rootkit comprende:
- Un network sniffer, per registrare login e password utilizzate sulla o dalla macchina violata, in modo da estendere il raggio d'azione dell'intrusore e la qualità e quantità di informazioni in suo possesso;
- Un keystroke logger, che registra quanto digitato dall'utente direttamente in console;
- Dei log wipers, script che cancellano automaticamente le tracce dell'intrusione dai log di sistema;
- Versioni modificate (trojans) di comandi di sistema comunemente utilizzati che possono rivelare l'esistenza del rootkit: ls, netstat, ifconfig, ps, killall, find, top.
- Una backdoor che accetta connessioni remote sia appoggiandosi ad una porta locale (nascosta dal netstat modificato) che modificando le versioni sul sistema di server telnet, ssh o analoghi.

Esistono diversi tipi di rootkit con diverse peculiarità, in genere, quelli per Linux, si possono inquadrare in due grandi famiglie:
- Quelli che lavorano in user space, sostituendo comandi ed eseguendo processi estranei;
- Quelli che lavorano in kernel space, presentandosi come moduli del kernel stesso. Una evoluzione di questi ultimi sono i rootkit che scrivono direttamente in memoria tramite /dev/kmem e funzionano anche su kernel non modulari.

I primi sono generalmente più semplici da trovare: per un system administrator basta verificare se l'output di un ps (che in presenza di un rootkit è stato sicuramente trojanato) mostra meno processi, con relativo PID, di quanti vengono visualizzati nel /proc file system (dove esiste una directory con nome del PID per ogni processo in esecuzione sul sistema). Utilizzando inoltre versioni "sicure" di comandi tipo ps, find, ls, netstat (che si è certi essere integre e non modificate, perchè, per esempio, compilate staticamente ed eseguite da un file system che può essere montato solo in read mode (per esempio un CDROM)) la presenza di simili rootkit verrebbe smascherata senza particolari problemi.
I secondi sono invece molto più subdoli e complessi. Lavorando direttamente come moduli del kernel intercettano le chiamate di sistema di qualsiasi processo e modificano il risultato secondo quanto definito dall'intrusore. In questo modo possono nascondere anche directory nel /proc filesystem e modificare l'output di comandi integri.
In questi casi può essere utile uno strumento come chkrootkit per trovare l'esistenza di un rootkit nel sistema.

Per poter risiedere in memoria anche dopo un riavvio, l'esecuzione del servizio del rootkit che permette l'accesso remoto deve essere lanciata da qualche script o comando di avvio.
Una volta in memoria, tipicamente, il processo maligno non viene visualizzato tramite l'uso di comandi tipo ps e top, la cartella dove fisicamente risiede viene nascosta a comandi come ls, find e cat e le porte su cui ascolta non vengono visualizzate con netstat.

Come prevenire / intercettare l'installazione di un rootkit

Autore: al - Ultimo Aggiornamento: 2003-05-07 12:43:00 - Data di creazione: 2003-05-07 12:43:00
Tipo Infobox: TIPS - Skill: 3- INTERMEDIATE

Fra i metodi per difendersi dall'installazione sul proprio sistema di un rootkit ci sono:
- Innanzitutto impedire che un utente possa bucare il proprio sistema utilizzando security bug noti sui servizi in produzione, quindi mantenere il proprio sistema protetto e aggiornato;
- Utilizzare tool come TRIPWIRE che eseguono un check costante dell'integrità dei file di sistema;
- Utilizzare, su macchine in produzione, un kernel monolitico non modulare, che renderebbe impossibile l'installazione di un rootkit basato su un modulo del kernel (non basta con rootkit dell'ultima generazione che si basano su /dev/kmem);
- Utilizzare strumenti come LIDS che limitano permessi e accesso alle risorse del sistema a livello di singoli processi (se ben configurato LIDS appare come la soluzione estrema e più efficace);
- Usare un demone come RKDET, che si accorge quando un interfaccia di rete entra in promiscous mode e invia mail, disattiva il networking o esegue altre operazioni di conseguenza;
- Garantirsi l'integrità dei log: stampandoli direttamente su carta o inviandoli ad un syslog server remoto (protetto);
- Avere un sistema che non può montare in write mode le directory /sbin, /usr/sbin, /bin e /usr/bin, impedendo che i comandi ivi contenuti possano essere modificati. Contestualmente è necessario verificare che la $PATH della shell non venga modificata.

Individuare l'installazione di un rootkit

Autore: al - Ultimo Aggiornamento: 2002-08-16 18:04:15 - Data di creazione: 2002-08-16 18:04:15
Tipo Infobox: TIPS - Skill: 4- ADVANCED

Una volta installato, un buon rootkit è, per natura, difficile da individuare proprio perchè tende a nascondere le tracce della propria esistenza.
Esistono tuttavia diversi metodi per individuarne la presenza che possono essere più o meno efficaci a seconda della natura del root kit:
- Il primo, più semplice, e piuttosto efficace è l'utilizzo di CHKROOTKIT, che è in grado di individuare sul sistema un numero sempre maggiore di rootkit.
- Verificare se il numero dei processi e i relativi PID che si visualizzano con ps è diverso da quello che si vede in /proc. Questa procedura, relativamente veloce, non funziona con rootkit basati su un modulo del kernel.
- Verificare con un port scanning da una macchina esterna, se sul sistema indagato sono aperte porte che non dovrebbero essere aperte e non vengono visualizzate con un netstat locale. Questo sistema non funziona con rootkit che modificano demoni esistenti come telnetd o sshd e tramite loro (e quindi tramite le rispettive porte) permettono accessi remoti non autorizzati.
- Indagare sempre quando un server si riavvia o si blocca senza apparente motivo o un servizio cade o comunque si riscontrano anomalie nel suo funzionamento: possono essere tutti indici di DOS attack o tentativi di intrusione o tentativi di installazione di un rootkit.
- Eseguire comandi come ls, ps, find da una fonte sicura (CDROM, NFS in read mode ecc.) e verificare se il loro output da risultati diversi dai rispettivi comandi di sistema. Questo metodo non funziona con rootkit kernel based.
- Verificare in /dev se esistono nomi di device sospetti, in particolare device pty senza numeri successivi (es: /dev/ptyr).
- Verificare negli script di startup del sistema se vengono lanciati comandi non noti: ogni rootkit deve garantirsi l'esecuzione in memoria al riavvio.
- Monitorare la banda utilizzata da ogni singolo server (MRTG è lo strumento ideale) e indagare quando si notano picchi di traffico anomali: non di fado una macchina compromessa viene utilizzata come repository di warez.
- Verificare su www.incidents.org se il proprio IP risulta nel database degli attackers: se lo è o siamo hacker maldestri o qualcuno sta usando la nostra macchina per lanciare attacchi altrove.


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.

Privacy Policy