Installazione di Linux e introduzione alla sicurezzaPianificazione dell'installazione di un sistema Linux sicuro usando procedure di installazione e aggiornamento dei pacchetti via rete. Check-list post installazione. Obiettivo: |
Installazione di Linux via reteKickstart, Jumpstart e sistemi di installazione centralizzata via rete. Introduzione alla sicurezzaIntroduzione alle problematiche di sicurezza su Internet Linux post-installation check-listOperazioni da compiere su un sistema Linux dopo averlo installato dal CDROM. Security fixes e patches. Aggiornamento di un sistema LinuxI metodi e le tecniche per l'upgrade manuale e automatico di un sistema Linux Link e documentazione sulla securityLibri, risorse, siti sulla sicurezza |
Network securityLinux, la sicurezza e le reti. Obiettivo: |
Linux InternetworkingOverview del networking su Linux Network scanning: strumenti e tecnicheStrumenti e tecniche di network e vulnerability scanning. Information gathering. Network sniffing: strumenti e tecnicheTeoria e pratica sulla subdola arte dello sniffing. Anti-sniffer tools. Arp spoofing e tecniche di prevenzione. |
La sicurezza di un sistema LinuxPanoramica sulle problematiche e le configurazioni che riguardano la sicurezza di un sistema Linux: Obiettivo: |
Linux e la sicurezza fisicaProblematiche di sicurezza su server fisicamente non protetti La logica della sicurezza sui sistemi Unix / LinuxUtenti e root, permessi, attributi, limiti: le proprietà di sicurezza dei sistemi Unix. Passwords e password crackingScelta di password sicure e metodi di password cracking. Il superdemone Inetd (e Xinetd)Configurazione di inetd e tcp wrappers. Configurazione di xinetd. Overview sulla sicurezza dei serviziIndicazioni operative e rasegna delle problematiche di sicurezza dei principali applicativi laso server. |
Attacchi, intrusioni, IDS e system recoveryTecniche e metodi di intrusion detection. IDS e NIDS. Overview sugli attacchi DOS. Obiettivo: |
Intrusion detection e analisi dei logOverview sugli strumenti di intrusion detection e analisi del sistema Attacchi DOSOverview su Denial Of Service attacks e sui DDOS RootkitsAnalisi della logica dei rootkit e dei metodi per individuarli - chkrootkit |
Linux Virtual Private NetworksRassegna delle soluzioni in ambiente Linux per l'implementazione di VPN: Obiettivo: |
Linux VPNLe soluzioni VPN disponibili su Linux. Teoria e implementazione. SSHIl protocollo, i server, i client. OpenSSH |
Installazione di Linux via rete |
Kickstart, Jumpstart e sistemi di installazione centralizzata via rete. |
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-05-06 16:54:37
Sebbene praticamente ogni distribuzione Linux venga distribuita tramite CDROM è possibile pianificare una installazione via rete, risparmiando tempo e automatizzando le operazioni.
Fondamentalmente esistono 4 diversi metodi di installazione, con livelli di automazione crescente:
1- Normale Installazione via CD
E' la procedura standard, si fa il boot da un CD e si procede alla configurazione del sistema rispondendo alle varie domande fatte dal tool di installazione. I pacchetti installati vengono prelevati direttamente dai CD forniti.
2- Normale installazione con scaricamento dei pacchetti via rete
E' una procedura leggermente più comoda, si presenta come una normale installazione ma si fa in modo di scaricare tutti i pacchetti via rete (locale, di solito) da un proprio repository creato appositamente. Di fatto questo rende più rapida l'installazione e non costringe, una volta fatte le configurazioni iniziali, a presiedere il sistema per cambiare il CD.
Su sistemi tipo RedHat va digitato al prompt di boot del CDROM linux askmethod
per poter avere, successivamente, la richiesta su quale fonte di installazione scegliere.
Su Debian esiste il CD Network Install con il minimo necessario per installare un sistema che al primo riavvio procede allo scaricamento via rete di tutti il software che si sceglie.
E' inoltre possibile, ma ormai meno comodo, fare il boot da un floppy e scaricare il resto via rete (il kernel caricato dal floppy deve avere i driver per la propria scheda di rete).
Anche Gentoo prevede un minimal CD che permette il setup iniziale per poi gestire il resto dell'installazione via rete.
3- Installazione via kickstart o analoghi
Ha un livello di automazione maggiore, perchè permette di definire al boot un file da cui prendere tutti i settaggi che normalmente vengono configurati a mano. In questo modo gran parte dell'installazione avviene automaticamente e senza necessità di presidio, anche se il boot iniziale va fatto dal CD ufficiale.
RedHat e derivati usano KickStart, su Debian è disponibile FAI (Fully Automatic Installation), Suse ha il suo AutoYaST
4- Installazione tramite PXE
E' la forma più automatica, ma prevedere la configurazione di una adeguata infrastruttura. E' possibile solo per le schede di rete che permettono il boot via rete (supportando la funzionalità PXE, Pre Execution Environment) che, oltre a poter essere usata per thin client senza hard disk locale, si può usare per automatizzare completamente una installazione, senza nemmeno la necessità di inserire il CDROM.
LINK: Debian Network install from a minimal CD - http://www.debian.org/CD/netinst/
LINK: Debian Booting from floppy disks and installing using the network - http://www.debian.org/distrib/floppyinst
LINK: FAI (Fully Automatic Installation) for Debian GNU/Linux - http://www.informatik.uni-koeln.de/fai/
LINK: Suse AutoYaST - http://yast.suse.com/autoinstall/
GOOGLE: redhat kickstart - http://www.google.com/search?q=redhat+kickstart&btnG=Search&hl=en&lr=
GOOGLE: linux pxe installation - http://www.google.com/search?q=linux+pxe+installation&sourceid=opera&num=0&ie=utf-8&oe=utf-8
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2005-05-06 16:21:59
Kickstart è un sistema che permette di automatizzare e standardizzare il processo di installazione di Linux e risulta particolarmente utile quando si ha a che fare con un parco macchine particolarmente esteso. E' disponibile nelle distribuzioni di RedHat (Fedora e Enterprise Linux) e nelle derivate.
Permette di installare Linux sia tramite i media tradizionali (cd-rom) sia via network (http,ftp,nfs).
Il vantaggio nell'utilizzo di kickstart deriva dalla possibilità di:
- Rendere più facili e veloci i processi di installazione.
- Customizzare e rendere omogenee le installazioni.
- Automatizzare le attività di post-installazione.
- Installare sistemi con pacchetti RPM già aggiornati.
Risulta dunque essere la scelta ideale se si vuole avere un parco macchine uniforme o si deve prevedere un considerevole numero di nuove installazioni.
Tutto quello che si deve avere a disposizione è:
- Un server kickstart (Servizio Web, NFS, FTP o SMB che rende disponibili via rete gli rpm necessari all'installazione)
- Un dischetto o un cdrom per il primo boot della macchina
- Il file di configurazione (default ks.cfg
) contenente tutte le opzioni per l'installazione ed eventuali script pre/post-installazione. Questo file può risiedere direttamente sul kickstart server (ce ne possono essere diversi con configurazioni per sistemi di diversa natura).
LINK: Kickstart Ufficial Docs per RH 7.3 - http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/custom-guide/ch-kickstart2.html
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2005-05-06 16:09:42
Creato un file di configurazione .ks e messo a disposizione sul kickstart server o su un floppy, è possibile avviare l'installazione tramite kickstart.
L'operazione comune per qualunque media che verrà utilizzato per l'installazione è l'avvio del sistema con il boot dai device tradizionali come cd-rom o dischetto.
Al prompt di boot, specificando alcuni parametri è possibile indicare al sistema quale media dovrà utilizzare ma soprattutto dove risiede il file di configurazione per iniziare l'installazione.
Ammettiamo di avere un dischetto contenente sia l'immagine sia il file di configurazione, il comando al boot sarà:
boot: linux ks=floppy
oppure se il file di configurazione si chiama in modo diverso da quello di default (ks.cfg) è possibile specificarlo nel seguente modo:
boot: linux ks=hd:fd0/pippo.cfg
Nel caso in cui il file risieda nel cd-rom lanciare il seguente comando:
boot: linux ks=cdrom:/[path]
Comando di avvio in caso il file di configurazione risieda su un web o NFS server:
boot: linux ks=nfs:[server]:/[path]
boot: linux ks=http://[server]/[path]
In entrambi i casi sarà un dhcp server ad assegnare un indirizzo di rete.
Gli esempi sopra illustrati sono gli esempi delle modalità più utilizzate ma è possibile caricare il file di configurazione sia da un file system locale oppure tramite il dhcp server il quale assegnerà un ip e tutti i parametri necessari per raggiungere il file di configurazione.
Nel caso in cui il sistema preveda più interfacce di rete è possibile specificare tramite la seguente opzione quale interfaccia abilitare per l'installazione.
ksdevice=[device]
Esempio:
boot: linux ks=http://192.168.0.10/distro/servermail.ks ksdevice=eth2
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2005-05-06 16:01:41
Creare il file di kickstart con i parametri da impostare via rete è semplice e può seguire due strade, fra loro non alternative:
- Fare una normale installazione su un sistema "master" e poi creare comodi cloni con le stesse impostazioni
- Creare da zero un file di configurazione con gli strumenti forniti dal sistema
Clonare una installazione
Ad ogni installazione di RedHat Linux, viene creato in modo automatico il file di configurazione per kickstart in /root/anaconda-ks.cfg
con i parametri e i settaggi relativi alla installazione appena conclusa.
Editandolo a seconda delle proprie esigenze ci si ritrova con un file di configurazione kickstart utilizzabile su macchine clone (che avranno stesse impostazioni e possibilmente hardware simile).
Creazione di un file di configurazione di kickstart
RedHat rende disponibile un front-end grafico avviabile dal menu di gnome o kde (KickStart Configurator) oppure tramite shell lanciando il comando /usr/sbin/system-config-kickstart
. Questo strumento permette di definire tutti i parametri relativi ad una installazione di Fedora/RedHat, con una interfaccia che ha gli stessi elementi di Anaconda (l'installer di RedHat), e quindi rende particolarmente semplice la creazione di uno o più file di kickstart da usare per scenari diversi.
LINK: Kickstart Oprions - http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/custom-guide/s1-kickstart2-options.html
Introduzione alla sicurezza |
Introduzione alle problematiche di sicurezza su Internet |
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-05-02 11:59:32
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.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-05-02 12:08:46
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.
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-05-02 12:25:44
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.
LINK: The on-line hacker Jargon File - http://www.antionline.com/jargon/
Linux post-installation check-list |
Operazioni da compiere su un sistema Linux dopo averlo installato dal CDROM. Security fixes e patches. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-14 17:53:20
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.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-05-06 12:10:29
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.
LINK: Rpm man Pages - http://man.openskills.info/rpm/
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-05-06 12:56:21
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
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-05-06 13:13:05
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
Se è installato sar, fornisce numerose statistiche sull'utilizzo delle risorse
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
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-13 22:54:54
Riassumiamo qui una serie di configurazioni e ottimizzazioni post-installazione che possono aumentare il livello di sicurezza del sistema.
Non ci addentriamo nei particolari, ci si limita a dare indicazioni operative, lasciando a chi legge gli approfondimenti del caso.
Alcune indicazioni sono necessarie solo per server fisicamente posizionati in luoghi non sicuri ed in qualche modo accessibili da estranei (PHYSICAL), altre sono particolarmente pignole e dedicate a chi ha particolarmente a cuore la sicurezza del sistema o è particolarmente paranoico (PARANOID), altre ancora in qualche modo possono compromettere le funzionalità di parti del sistema per cui vanno adottate e testate adeguatamente (DISFUNCTION?), alcune sono particolarmente raccomandate (RECCOMENDED).
Queste impostazioni si riferiscono ad una distribuzione RedHat 7.2 standard. Su altre distribuzioni le posizioni dei file possono essere diverse e le indicazioni date vanno adattate.
In ogni caso queste indicazioni NON bastano a rendere un server sicuro, ma vanno affiancate ad altre precauzioni (aggiornamento costante di programmi e kernel - esposizione solo dei servizi strettamente necessari - utilizzo di IPTABLES adeguate - controllo della sicurezza dei servizi pubblici - installazione di un IDS e di un file integrity checker - log check regolare - BACKUP!).
Settare una password sul BIOS - PHYSICAL - RECCOMENDED
Necessario per impedire che si possa modificare il device di boot, impedendo la possibilità di fare password recovery o accesso non protetto ai dati bootando da floppy o CDROM estranei. Considerare che la password del BIOS è resettabile switchando un jumper sulla scheda madre. Il vero paranoico impedisce anche l'apertura del case se la macchina si trova in luoghi fisicamente non sicuri.
Strong password policy - RECCOMENDED
Le password di fatto sono il baluardo principale per permettere l'accesso al sistema. Se sono semplici, triviali, recuperabili da un dizionario o brevi sono password deboli.
E' possibile forzare il numero minimo di caratteri composti da una password editando /etc/login.defs
e forzando a 8 il numero minimo di caratteri della password con PASS_MIN_LEN 8
.
Altra opzione interessante presente nello stesso file è PASS_MAX_DAYS 99999
dove 99999 è la durata della password. Ha senso inserire un PASS_MAX_DAYS 180
per forzare il cambio della password ogni 180 giorni. Attenzione: Queste modifiche vanno fatte PRIMA di aggiungere utenti alla macchina. PASS_MAX_DAYS 99999 e altri parametri sono comunque modificabili successivamente in /etc/shadow
.
Cript a lot - RECCOMENDED
E' fondamentale per un server pubblico che si gestisce via Internet rimuovere l'accesso telnet e sostituirlo con SSH, che cripta i dati trasmessi (e quindi login e password per l'accesso). SSH comunque non è esente da difetti, la versione 1 del protocollo ha potenziali buchi e in passato ci sono state serie vulnerabilities su alcuni software SSH. Si raccomanda di usare una versione recente di OpenSSH con supporto di SSH2, chiave di almeno 1024 bit e con accesso root diabilitato.
Permission restriction - PARANOID - DISFUNCTION?
In molte distribuzioni, spesso, alcuni file hanno di default permessi in lettura per tutti gli utenti anche quando non è necessario.
Non è una brutta idea restringere questi permessi, lasciando che sia root Colui Che Può:
chmod 600 /etc/inetd.conf
Se presente inetd.conf. Ovviamente è pure necessario editarlo per rimuovere tutti i servizi inutili.
chmod 600 /etc/xinetd.conf
Se presente Xinetd invece di inetd. Stesse raccomandazioni.
chmod 700 /etc/xinetd.d
La directory dove Xinetd ha il file di configurazione per i singoli servizi.
chmod -R 700 /etc/&rc.d/init.d/*
La directory dove sono presenti gli script di avvio. Perchè un normale utente dovrebbe vederlI?
Restrizione /etc/aliases - PARANOID - DISFUNCTION?
/etc/aliases
gestisce gli alias di posta, spesso di default si forwardando a root la posta di altri utenti. E' opportuno commentare alcuni alias, inseriti di default, per evitare potenziali exploit tramite il loro utilizzo (in particolare l'alias decode). Segue una lista delle righe di /etc/aliases che si possono commentare o rimuovere. Dopo la modifica del file va eseguito il comando newaliases per rendarla effettiva:
# uucp: root
# operator: root
# games: root
# ingres: root
# system: root
# toor: root
# manager: root
# dumper: root
# decode: root
Boot loader password - PHYSICAL - RECCOMENDED
Impedire l'accesso alle opzioni del bootloader è fondamentale in un server fisicamente non custodito.
Se si usa lilo aggiungere a /etc/lilo.conf
la riga password= e assicurarsi che lilo.conf sia leggibile solo da root.
Se si usa grub aggiungere a /etc/grub.conf
la riga password e assicurarsi che grub.conf sia leggibile solo da root o, meglio, usare l'opzione password --md5
Disabilitare CTRL-ALT-CANC - PHYSICAL - RECCOMENDED
Sicuramente non ci piace l'idea che chiunque possa riavviare il nostro server con un comodo CTRL+ALT+CANC
, per renderlo impossibile commentare in /etc/inittab la riga: ca::ctrlaltdel:/sbin/shutdown -t3 -r now
Stampare i log! - PARANOID
La prima cosa che fa un intrusore una volta preso possesso del sistema e coprire le proprie tracce, modificando e cancellando i log che ne possano rilevare l'entrata.
Questo è evitabile se si ha molta carta da sprecare: è possibile configurare syslog per stampare (su stampante a feed continuo) i log che si vogliono. E' semplice, basta aggiungere una riga come quella che segue ed avere una stampante funzionante su /dev/lp0
authpriv.* /dev/lp0
Usare un syslog server
Leggermente meno sicuro e definitivo del metodo precedente è quello di loggare i propri log su un syslog server remoto, opportunamente blindato, che risulti, per quanto possibile, inattaccabile per l'intrusore. Sul syslog locale aggiungere/modifcare:
authpriv.* @nomesyslogserver
Sul syslog server configurare /etc/rc.d/init.d/syslog
per lanciare syslogd con l'opzione di accettare messaggi dalla rete, aggiungendo -r
alle opzioni di startup.
In RedHat 7.2 modificare la riga: SYSLOGD_OPTIONS="-m 0" con SYSLOGD_OPTIONS="-r -m 0"
Buona scelta è anche usare alternative più sicure (paranoiche?) a syslogd.
Limitare la history della shell
E' possibile limitare la history predefinita della bash per ridurre i rischi che un hacker, leggendola, possa vederci delle password digitate per sbaglio.
Caso tipico è l'utente che prova a diventare superuser e scrive la password al momento sbagliato, passandola come comando shell (che probabilmente non verrà trovato) invece che come input alla richiesta della password. Tale leggerezza resta immortalata nella history della sua shell.
Editare /etc/profile
per ridurre la dimensione della history. Modificare HISTSIZE=1000 in HISTSIZE=25
(o il valore che si preferisce).
Non urlare la proria identità - RECCOMENDED
Nonostante esistano tool come queso in grado di rivelare il sistema operativo installato su una macchina, è sempre buona norma fornire il minor numero possibile di informazioni sul sistema ed i suoi servizi. Questo non basta per fermare un bravo hacker, ma può essere abbastanza per fuorviare lo scan di uno script kiddie.
Per quanto riguarda i singoli servizi (web, dns, ssh, smtp ecc) riferirsi alle relative documentazioni per trovare il modo di nascondere versione e nome del programma utilizzato. Per quanto riguarda il sistema si può evitare di mostrare a console o via telnet/ssh un verboso banner introduttivo con nome distribuzione e versione del kernel.
Su RedHat7.2 editare rispettivamente /etc/issue
e /etc/issue.net
per mascherare versioni di kernel e distribuzione.
Su RedHat più vecchi uno sciagurato script di avvio (/etc/rc.d/rc.local) riscriveva ogni volta questi file con le informazioni originarie. In questo caso è necessario commentare le righe dello script che riscrivono /etc/issue e /etc/issue.net.
Rimuovere RPM, GCC e altri comandi utili - DISFUNCTION?
Se si vuole rendere la vita difficile ad un intrusore, e anche complicarsi un po' la propria, considerare la possibilità di spostare il comando RPM in una directory non standard (meglio cambiandogli anche il nome per evitare che un find lo trovi) o metterlo direttamente in un luogo inaccessibile (floppy estraibile).
Analogamente si può pensare di rimuovere dal sistema tutti i tool necessari per compilare del codice come gcc, make e le relative libraries (utili all'hacker che vuole crearsi delle backdoor) e i comandi che si possono usare per prendere un file dalle rete (lynx, ftp, irc, ncftp, wget, scp, rcp ...) e che si possono impropriamente essere utilizzare per caricare sulla macchina programmi estranei.
Queste precauzioni, seppur efficaci in un contesto di sicurezza estrema, rendono molto meno comoda e pratica la vita dell'amministratore.
Restringere le opzioni di mount del file-system - DISFUNCTION?
Il file /etc/fstab contiene le informazioni su quali dispotivi possono essere montati sulla macchina e può definire delle opzioni che introducono limitazioni sul file-system montato.
Per esempio un /etc/fstab con queste righe:
/dev/hda2 /tmp ext2 defaults 1 2
/dev/hdc1 /home ext2 defaults 1 1
può essere modificato con opzioni che restringono, sui file system montati, la possibilità di eseguire binari (noexec), di onorare i bit setUID e setGID su file che li hanno (nosuid), di interpretare caratteri o dispositivi a blocchi speciali (nodev):
/dev/hda2 /tmp ext2 nosuid,nodev,noexec 1 2
/dev/hdc1 /home ext2 nosuid,nodev 1 1
Limitare gli utenti che possono fare SU - RECCOMENDED
Qualsiasi utente con una shell sul sistema con il comando su, può diventare root (sapendo la password). Si può stroncare alla radice questa velleità editando il file /etc/pam.d/su
e scommentando la riga:
auth required /lib/security/pam_wheel.so use_uid
.
Una volta fatto, solo gli utenti appartenti al gruppo wheel (è un gruppo speciale, non si possono usare altri gruppi arbitrari per questa operazione) possono fare su, per cui editare /etc/group ed aggiungere al gruppo wheel gli utenti abilitati ad eseguire su.
Aggiornamento di un sistema Linux |
I metodi e le tecniche per l'upgrade manuale e automatico di un sistema Linux |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2006-03-23 11:52:41
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.
(F)AQ: configurare yum -
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-05-05 23:08:20
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ù.
LINK: RHN HomePage - http://rhn.redhat.com/
LINK: RHN Satellite - http://www.redhat.com/support/techsupport/production/RHN_satellite_defs.html
LINK: RHN proxy - http://www.redhat.com/support/techsupport/production/RHN_proxy_defs.html
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-04-19 18:45:02
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
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-04-26 16:49:38
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
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2005-05-06 11:53:22
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%]
Tipo Infobox: COMMANDS - Skill Level: 4- ADVANCED - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-03-14 22:34:23
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
Tipo Infobox: COMMANDS - Skill Level: 4- ADVANCED - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-03-14 22:30:25
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.
Link e documentazione sulla security |
Libri, risorse, siti sulla sicurezza |
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2003-04-14 16:00:00
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.
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-04-14 15:57:28
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.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-05-08 13:32:23
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.
Linux Internetworking |
Overview del networking su Linux |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-09-29 10:47:14
Tipicamente la configurazione di un host in rete prevede pochi dati fondamentali: Indirizzo IP, subnet mask, default gateway e DNS server.
Esistono molteplici metodi per configurare il servizio di rete in Linux, molto di quanto viene qui riportato si applica a tutti gli Unix:
- editare i singoli file di configurazione del networking (ristartare il servizio per applicare le modifiche);
- usare comandi shell come ifconfig
, route
- utilizzare strumenti di configurazione con interfaccia a finestra come netconfig, linuxconf, webmin e altri facilmente individuabili su desktop KDE o GNOME.
File di configurazione:
/etc/sysconfig/network
Contiene le principali configurazioni per il Networking: hostname, domainname, default gateway (tipico di RedHat).
/etc/sysconfig/network-script/ifcfg-XXX
Directory contenente i file di configurazione delle singole interfacce (tipico di RedHat).
/etc/hosts
Contiene il mapping statico fra indirizzi e hostname ed alias. Segue un esempio.
/etc/services
Contiene il mapping tra i numeri di porta e i nomi dei servizi.
E' un file che solitamente non si modifica, salvo l'aggiunta di porte e protocolli custom.
/etc/host.conf
Specifica l'ordine secondo il quale il sistema effettuerà la ricerca di informazioni per risolvere gli indirizzi. Usato dalla resolver library in sistemi con libc versione 5.
order hosts,bind ; specifica di usare prima /etc/hosts e poi il DNS per risolvere gli IP.
/etc/nsswitch.conf
Stessa funzione di host.conf nei sistemi con libc versione 6 (glibc). In pratica è sempe meglio avere entrambi i file correttamente configurati.
/etc/resolv.conf
File di configurazione del client DNS ovvero contiene gli indirizzi del server DNS e un possibile dominio dell'host e l'ordine di ricerca
Comandi comuni
Tipicamente su Linux e su Unix i comandi che bastano per configurare la rete (con privilegi da root (sono:
ifconfig [interface] [options] | address
Permette di configurare le interfacce di rete dell'host. Es: ifconfig eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255 up
. NOTA: Non esiste nessun controllo sulla corrispondenza fra netmask e broadcast.
route [ opzioni ] [comando] [parametri]
Permette di manipolare la tabella di routing del kernel. Es: route add -net 0.0.0.0/0 gw 192.168.0.1
/etc/init.d/network
Script di avvio/stop del networking. Es: Per riavviare il subsystem rete dopo una riconfigurazione basta scrivere /etc/init.d/network restart
.
ip [ opzioni ] oggetto { comando }
Comando estremamente potente e flessibile disponibile a chi ha installato i tool iproute2
E' possibile associare più indirizzi ip appartenenti alla stessa rete su un'unica interfaccia, ovvero è possibile associare più Alias a interfacce di rete.
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: fargo 'fargo' - Ultimo Aggiornamento: 2002-10-16 19:36:13
Ifconfig serve essenzialmente a configurare l'indirizzo ip di un'interfaccia di rete, tipicamente una ethernet.
Un computer può avere più di un indirizzo IP. Ad ogni interface può corrispondere uno o più indirizzi IP.
per esempio potremmo avere un computer con due ethernet interface e avremmo quindi una eth0 e una eth1 (quindi due indirizzi), ma potremmo avere anche degli alias, quindi eth0:1, eth0:2 e così via.
Con ifconfig si possono configurare altri aspetti di un'interface, anche se molti parametri saranno difficilmente cambiati. Per esempio si possono cambiare e MTU e metrica, abilitare o disabilitare il multicast e la modalità promiscqua (di solito attivata automaticamente da programmi di sniffing). Sulla manuale (man ifconfig) si possono trovare queste opzioni, che consiglio di leggere.
Sicuramente i comandi dati sono sufficienti ad una configurazione standard.
Vediamo una panoramica dei principali comandi per utilizzare ifconfig:
ifconfig [interface] options | address
ifconfig -a
mostra la configurazione IP di tutte le interface. Su molti sistemi è sufficiente digitare ifconfig, senza l'opzione -a. Un esempio dell'output di ifconfig può essere questo (i commenti spiegano le varie righe):
eth0 Link encap:Ethernet HWaddr 00:50:8B:B0:15:7F
indica il tipo di hardware e il suo indirizzo fisico (MAC address)
inet addr:192.168.0.1 Bcast:192.168.1.255 Mask:255.255.255.0
indica indirizzo IP, indirizzo di broadcast e maschera della rete.
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Indica lo stato (UP) e le opzioni attive (accetta broadcast e multicast) l'MTU e la Metrica.
RX packets:2590603 errors:0 dropped:0 overruns:0 frame:0
TX packets:2713120 errors:0 dropped:0 overruns:1 carrier:0
collisions:0 txqueuelen:100
RX bytes:987732693 (941.9 Mb) TX bytes:1198865677 (1143.3 Mb)
Mostra le statistiche in ricezione (RX) e trasmissione (TX)
Interrupt:12 Base address:0x6100
Mostra l'indirizzo hardware della scheda
ifconfig interface
mostra la configurazione della interface specificata. Per esempio ifconfig eth0.
ifconfig interface ip netmask broadcast up/down
attiva disattiva una determinata interface. Con questo comando possiamo facilmente configuare e attivare una interface. Questo si applica sia come indirizzo primario che come alias, consentendoci di creare più alias alla stessa interfaccia.
Vediamo qualche esempio:
ifconfig eth0 192.168.0.1 up
assegna l'indirizzo IP 192.168.0.1 e attiva l'interface (di default viene assegnata la classe C in questo caso, che sarebbe stata una classe A se avessimo usato 10.0.0.1)
ifconfig eth0:1 192.168.0.1 up
assegna l'indirizzo IP 192.168.0.1 alla eth0:1 e attiva l'interface. Eseguendo questo comando di fatto assegniamo un'altro indirizzo IP alla interface.
ifconfig eth0 192.168.0.1 netmask 255.255.255.128 broadcast 192.168.0.127 up
assegna l'indirizzo IP 192.168.0.1 e attiva l'interface, creando una mask 192.168.0.0/25 (In questo modo la Classe C è divisa in due subnet di 126 indirizzi) e assegnando come indirizzo di broadcast 192.168.0.127.
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-24 13:47:12
Route è il comando Linux che viene utilizzato per manipolare le tabelle di routing. Permette di aggiungere ed eliminare route statiche e default gateway, oltre che semplicemente visualizzare la tabella di routing di un sistema.
Non è comune in altri Unix.
route add [-net|-host] indirizzo [gw gateway] [netmask netmask] [mss mss] [metric metric] [dev device]
route del indirizzo
Per aggiungere una route statica per un'intera rete si usa l'opzione add e si devinisce la rete con -net. Per esempio:
route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.0.0.254
Aggiunge una route statica per la rete 192.168.0.0/24 usando come gateway 10.0.0.254.
Per impostare il default gateway si può digitare qualcosa come:
route add -net 0.0.0.0 netmask 0.0.0.0 gw 10.0.0.1
oppure:
route add default gw 10.0.0.1
Per cancellare una route esistente basta indicare il nome della rete:
route del -net 192.168.0.0
Per visualizzare la tabella di route basta: route
, se si vuole evitare il reverse lookup degli IP e velocizzare l'operazione scrivere: route -n
Per visualizzare la cache del sistema sulle route usate: route -C
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-16 23:13:18
Diagnosticare problemi di rete è attività che difficilmente si spiega a parole.
Per essere in grado di affrontare problematiche di rete complesse (ma anche quelle relativamente triviali) sono necessari diversi skill, non tutti tramandabili facilmente:
1 - Solide basi teoriche e conoscenza dello stack TCP/IP.
Inutile fingere, si deve poter diagnosticare in fretta un problema di DNS rispetto a quello dovuto ad un cavo scollegato, un problema di routing rispetto ad un problema dovuto a troppi errori su una interfaccia.
Per farlo, a prescindere dai sistemi usati, è sempre necessario avere in mente network layers e protocolli.
2 - Esperienza.
Come sempre, i trucchi migliori sono quelli che si acquisiscono sul campo e la familiarità con ambienti e dispositivi specifici ci rende più efficaci e rapidi nelle scelte e nelle implementazioni.
3 - Conoscenza degli strumenti a disposizione.
Qui possiamo dare qualche indicazione utile, valida per quasi tutti gli Unix e anche sistemi Windows:
- ping, traceroute, telnet sono utili per diagnosticare problemi di raggiungibilità di sistemi remoti
- ifconfig, route servono per identificare la configurazione di rete corrente ed evidenziare routing particolari o problemi di errori a livello di interfaccia fisica.
- arp e le arp cache sono sempre da considerare quando si cambia IP di una macchina o la macchina associata ad un IP
- netstat è uno strumento flessibile per identificare connessioni di rete attive e errori e statistiche di traffico su IP, TCP, UDP e ICMP.
- tcpdump, snoop e altri sniffer sono fondamentali quando si devono analizzare nel dettagli dei flussi di pacchetti in rete
- nslookup e dig sono fondamentali per diagnosticare problemi di DNS.
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2004-05-23 16:10:35
Netstat è un comando polifunzionale che ti permettere di verificare le connessioni, le route e statistiche del proprio sistema. Un comando che ogni sys adm deve conoscere alla perfezione, utile per diagnostica e controllo del sistema.
netstat [information-type] [options]
netstat {--help|-h}
Richiama l'help
Per selezionare il tipo di informazioni da visualizzare, bisogna mettere come primo argomento una delle seguenti opzioni. Se non si specifica nulla il comando visualizzera' la lista delle socket aperte, opzione di default.
Information Type
--route , -r
Visualizza le route impostate sul sistema
--groups , -g
Visualizza informazioni riguardanti i multicast group membership (ipv4 e ipv6)
--interface=iface , -i
Visualizza le statistiche di tutte le interfacce o della singola interfaccia specificata
--masquerade , -M
Verifica le connessioni che hanno subito masquerading
--statistics , -s
Visuallizza un sommario di statistiche
Options
--verbose , -v
Abilita il verbose mode.
--numeric , -n
Non risolve gli Ip e il numero delle porte, risparmiando i tempi per query DNS.
--protocol=family , -A
Opzione per specificare l'address family quando si vuole visualizzare le connessioni.
-c, --continuous
Esegue il comando ogni secondo (o ogni intervallo di secondi specificato).
-p, --program
Mostra il PID, ed il nome del programma proprietario della socket. Utile per capire, per esempio, quale programma utilizza una specifica porta TCP.
-l, --listening
Mostra solo le conessioni in LISTENING
-a, --all
Mostra tutte le connessioni (LISTENING e non), se abbinato al flag -i visualizza le informazioni per tutte le interfacce
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-10-12 20:02:55
Comando che ti permette di visualizzare e manipolare le voci di arp nella cache del sistema.
Come la maggior parte dei comandi relativi alla network ottiene informazioni dal proc file-system (/proc/net/arp)
Visualizzazione del contenuto di tutta la cache, oppure specificando l'host solo l'arp del suddetto host
arp [opzioni] -a [hostname]
Cancellazzione dell'arp di uno specifico host
arp [opzioni] -d hostname
Creazione manuale di uno specifico arp di un host
arp [opzioni] -s hostname hw_addr [opzioni]
Options
-v, --verbose
Abilita il verbose mode
-n, --numeric
Non esegue il DNS lookup degli indirizzi ip
-H type, --hw-type type, -t type
Specifica quale classe di arp deve visualizzare,cancellare inserire. ( ARCnet (arcnet) , PROnet (pronet) , AX.25 (ax25) and NET/ROM (netrom). Default=ether)
-i If, --device If
Specifica l'interfaccia
-e
Visualizza il risultato in linux standard
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-04-04 22:44:28
Tcpdump è un ottimo sniffer che permette di monitorare il traffico di rete con filtri flessibili per limitare l'output a video secondo varie regole di matching di pacchetti.
tcpdump [ options ] [ expression ]
-a
Tenta di risolvere network e broadcast address
-c [count]
Esegue l'exit dopo aver raccolto tot pacc
-F [file]
Specifica di utilizzare un file in input per le expression
-i
Specifica l'interfaccia da cui sniffare
-n
Non risolve gli indirizzi ip
-nn
Non risolve ne gli ip ne il numero delle porte
-p
Non abilita il promiscuous mode sull'interfacce da cui tcpdump e' in ascolto
-v,-vv,-vvv
Abilita il verbose mode
-x
Printa ogni paccheto sniffato
Le expression servono per limitare il matching dei pacchetti
proto
Specifica il protocollo [tcp,udp,ether etc...]
dst host [host]
Specifica l'host di destinazione dei pacchetti
dst net
Specifica la network di destinazione dei pacchetti
dst port
Specifica la porta di destinazione dei pacchetti
src host [host]
Specifica l'host sorgente dei pacchetti
src net
Specifica la network sorgente dei pacchetti
src port
Specifica la porta sorgente dei pacchetti
`!' o `not'
Simbolo di negazione, ovvero inverte il matching
`&&' or `and'
Simbolo di concatenazione, visualizza il pacchetto che fa il match di tutte le regole concatenate
`||' or `or
Simbolo di alternanza, visualizza il paccheto o con questa opzione o con quest'altra
Network scanning: strumenti e tecniche |
Strumenti e tecniche di network e vulnerability scanning. Information gathering. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-04-14 16:20:17
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.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-08-07 12:48:10
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.
LINK: Universal Whois: Query whois su tutti i TLD - http://www.uwhois.com/
LINK: Link su Intelligence Resources generiche - http://www.fas.org/irp/
LINK: Internet Archive - Wayback Machine - http://www.archive.org/
LINK: Linux Exposed: Google Tricks and hacks - http://www.linuxexposed.com/modules.php?op=modload&name=News&file=article&sid=517&mode=thread&order=0
LINK: Googledorks! - Hacking query su Google - http://johnny.ihackstuff.com/
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2003-04-14 17:23:38
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.
LINK: Nmap homepage - http://www.insecure.org/nmap/
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-05-05 19:09:01
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.
SOURCE: Nessus Home Page - http://www.nessus.org
Network sniffing: strumenti e tecniche |
Teoria e pratica sulla subdola arte dello sniffing. Anti-sniffer tools. Arp spoofing e tecniche di prevenzione. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-05-07 12:03:48
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.
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-01-30 16:56:40
Tcpdump è uno strumento di sniffing particolarmente flessibile e diffuso nel mondo Linux. E' simile a snoop, più diffuso su Solaris, e permette di analizzare il tipo di pacchetti che passano per l'interfaccia di rete specificata.
Va sottolineato che tcpdump NON visualizza il contenuto dei pacchetti ma solo le loro intestazioni (protocollo, IP sorgente, destinazione, porte ecc.) per cui si presta bene alla diagnostica di problemi di networking ma non ad una attività di cracking.
INSTALLAZIONE
Per funzionare tcpdump richiede le librerie libpcap che possono essere scaricate dal sito ufficiale di tcpdump.
La procedura di installazione, sia per libpcap che tcpdump è quella standard (./configure ; make ; make install
). Per il corretto funzionamento su diversi Unix flavour sono necessari alcuni specifici adattamenti. Su Linux, per esempio, il kernel deve essere compilato con la funzione packet socket (CONFIG_PACKET=y
) e tcpdump deve essere lanciato da root.
USO
Tcpdump prevede numerose e flessibili opzioni per definire quali pacchetti sniffare e come farlo.
Il suo output dipende dal protocollo e viene visualizzata una riga per ogni datalink frame intercettato.
Il man ufficiale è dettagliato e ben documentato, riportiamo qui alcune opzioni interessanti.
tcpdump
- Senza opzioni tcpdump visualizza a schermo tutti i pacchetti che passano sull'interfaccia predefinita (di solito eth0)
tcpdump -i ppp0 -c 50
- Visualizza 50 pacchetti (-c 50) sull'interfaccia ppp0 (-i ppp0) e poi esce.
tcpdump -l | tee sniff.log
- Mentre visualizza i pacchetti li mette in un buffer (-l) che viene scritto sul file sniff.log.
tcpdump -e -n
- Visualizza gli indirizzi del data link (-e) e non prova a fare un DNS reverse lookup (-n) velocizzando l'output.
Le regole per identificare il tipo di pacchetto da visualizzare sono molto flessibili e adattabili a diverse necessità. Vediamo alcuni esempi
tcpdump port 80
- Visualizza solo i pacchetti che hanno come sorgente o destinazione la porta 80 (port 80).
tcpdump host 192.168.0.150
- Visualizza solo i pacchetti che hanno come IP sorgente o destinazione 192.168.0.150.
tcpdump host 10.0.0.150 and not port 22
- Visualizza solo i pacchetti relativi all'host 10.0.0.150 che non usino la porta ssh (and not port 22).
tcpdump net 10.0.0.0/24 and port 22
- Visualizza tutti i pacchetti per la rete 10.0.0.0/24 relativi al protocollo ssh (and port 22)
LINK: TCPDUMP Home Page - http://www.tcpdump.org
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-04-04 22:44:28
Tcpdump è un ottimo sniffer che permette di monitorare il traffico di rete con filtri flessibili per limitare l'output a video secondo varie regole di matching di pacchetti.
tcpdump [ options ] [ expression ]
-a
Tenta di risolvere network e broadcast address
-c [count]
Esegue l'exit dopo aver raccolto tot pacc
-F [file]
Specifica di utilizzare un file in input per le expression
-i
Specifica l'interfaccia da cui sniffare
-n
Non risolve gli indirizzi ip
-nn
Non risolve ne gli ip ne il numero delle porte
-p
Non abilita il promiscuous mode sull'interfacce da cui tcpdump e' in ascolto
-v,-vv,-vvv
Abilita il verbose mode
-x
Printa ogni paccheto sniffato
Le expression servono per limitare il matching dei pacchetti
proto
Specifica il protocollo [tcp,udp,ether etc...]
dst host [host]
Specifica l'host di destinazione dei pacchetti
dst net
Specifica la network di destinazione dei pacchetti
dst port
Specifica la porta di destinazione dei pacchetti
src host [host]
Specifica l'host sorgente dei pacchetti
src net
Specifica la network sorgente dei pacchetti
src port
Specifica la porta sorgente dei pacchetti
`!' o `not'
Simbolo di negazione, ovvero inverte il matching
`&&' or `and'
Simbolo di concatenazione, visualizza il pacchetto che fa il match di tutte le regole concatenate
`||' or `or
Simbolo di alternanza, visualizza il paccheto o con questa opzione o con quest'altra
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-10-16 18:51:58
Quando lanciate il comando tcpdump, su una macchina remota con una sola interfaccia oppure dovete sniffare il traffico dalla stessa interfaccia da cui avete aperto la connessione, dovrete utilizzare dei filtri per evitare di sniffare il vostro stesso traffico telnet o ssh e ricadere in vorticosi loop che rendono l'opera di analisi dei pacchetti improba.
Se mi collego ad un host remoto con SSH, dovro' sniffare tutto tranne i pacchetti con src e dst port 22
[root@morpheus pub]# tcpdump -i eth0 ! port 22
Kernel filter, protocol ALL, datagram packet socket
tcpdump: listening on eth0
[ Traffico sniffato ]
Per Interrompere Ctrl-c
Se devo sniffare ANCHE pacchetti SSH, ma non quelli generati dalla mia connessione posso scrivere (ipotizzando che il mio IP sorgente sia 10.0.0.10):
tcpdump -n -i eth0 ! host 10.0.0.10
(Notare il -n per evitare che venga fatto un DNS reverse lookup dell'IP 10.0.0.10, rendendo inefficace il filtro)
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-01-30 16:16:17
L'impossibilità di analizzare traffico con sorgente e destinazione diversi da quelli locali è una tipica limitazione degli sniffer normali quando vengono utilizzati in ambienti switchati, dove, cioè, lo switch di rete provvede ad inoltrare su ogni singola porta solo i pacchetti per gli host direttamente connessi alla porta stessa, oltre ai broadcast che vengono propagati a tutte le porte (o quantomeno a tutte le porte della stessa VLAN).
Ettercap, sviluppato da due programmatori italiani, è uno sniffer evoluto che permette di sniffare tutto il traffico anche in reti in cui è presente uno switch, con una attività di arp cache poisoning (vengono mandate arp reply finte, che associano il mac address della macchina su cui gira ettercap agli IP sorgente e destinatario, rispettivamente al destinatario e al sorgente), tramite la quale si frappone fra macchine ignare e la macchina bersaglio (che può essere un server o il default gateway di una rete).
Ettercap inoltre offre una serie di feature che fanno la gioia di ogni hacker:
- SSH 1 e HTTPS password sniffing;
- Password collection per una moltidutide di protocolli;
- OS fingerprinting per il riconoscimento dei sistemi operativi sugli Host trovati in rete;
- Possibilità di killare una connessione o inserire caratteri estranei;
- Supporto di plugin vari che a loro volta presentano features quali DNS spoofing, PPTP sniffing,
INSTALLAZIONE
./configure
make
make install
make plug-ins
make plug-ins_install
Il binario ettercap
è copiato di default in /usr/local/sbin
USO
All'avvio di ettercap esegue un rapido scan degli host presenti nella rete locale (viene fatto un aarp request per ogni IP della rete e non un semplice ping a tutti gli IP o al broadcast) e ne presenta una lista a video.
Su questa lista è possibile selezionare gli IP sorgenti e destinatari da monitorare e si possono visualizzare le molteplici potenti opzioni con il tasto h.
Esistono diverse modalità di sniffing: IP based (s), MAC based (m) e ARP poisoning based (a), quella più devastante, in grado di sniffare in ambienti switchati.
Sempre dalla finestra principale, in cui si visualizzano tutti gli IP in rete è possibile identificare i sistemi operativi utilizzati ((f)), fare puro Arp poisoning senza sniffare (j), creare pacchetti custom (x), eseguire uno dei tanti (potentissimi) plugin distribuiti con il tarball ufficiale (p), fare uno scanning passivo, basandosi solamente sugli host per cui c'è traffico (o) controllare se ci sono in rete altri arp cache poisoners (c, notare che sulle macchine bersaglio è possibile accorgersi che qualcosa non va con il semplice comando arp
e cercando se esistono diversi IP in rete con lo stesso MAC address).
Tutte queste opzioni a loro volta aprono una successiva finestra che può presentare dei comandi specifici. Utilizzare sempre h per un HELP e q per tornare alla finestra precedente.
LINK: Ettercap Home Page - http://ettercap.sourceforge.net/
LINK: CCO: VLAN Security White Paper - http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml
LINK: ARP Vulnerabilities: The Complete Documentation - http://www.l0t3k.org/security/docs/arp/
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-06-05 22:18:41
Arpwatch è un ottimo strumento per monitorare il traffico arp in una rete locale.
L'installazione tramite rpm è estremamente semplice e subito funzionale, basta lanciare il demone arpwatch (viene creato lo script di gestione /etc/rc.d/init.d/arpwatch
) per tenere sotto controllo le modifiche dei pacchetti arp nel segmento di rete a cui si è collegati.
L'ideale è installare Arpwatch su un server di monitoring, che rimane sempre acceso, e che intercetta tutti i broadcast arp che arrivano all'interfaccia di rete principale.
Ogni aggiunta di nuovo host o modifica del mac address di un host già aggiunto (sintomo o del cambio della scheda di rete di un computer o del cambio dell'host associato ad un IP o, e questo è l'aspetto più importante, di attività di arp poisoning, tipiche di sniffer per ambienti switchati come ettercap) viene notificato via mail (di default a root) e su syslog.
Alla prima esecuzione è normale ricevere varie mail per tutti gli host in rete, successivamente verranno notificate solo le variazioni e su queste, se non sono previste, è sempre bene indagare.
Nelle notifiche vengono segnalati l'indirizzo IP coinvolto e il vecchio e il nuovo MAC address. Se si ricevono mail che contengono nel titolo le parole FLIP FLOP o Chenge ethernet address è sicuramente il caso di indagare: segnalano una alternanza fra il precedente MAC address associato ad un indirizzo e l'ultimo noto o la modifica del Mac address associato ad un dato IP e possono essere la prova di attività di arp poisoning in rete (o di diversi PC che si alternano in rete con lo stesso IP).
Nella directory /var/arpwatch
l'rpm di arpwatch scrive vari file e script tra cui il file dove si registrano le coppie mac:ip (arp.dat
) e un database con l'elenco dei vendor a cui sono stati associati i principali prefissi arp (ethercodes.dat
, utile anche per altri scopi, ogniqualvolta si cerca di individuare di quale produttore è un dispositivo con un dato mac address).
Linux e la sicurezza fisica |
Problematiche di sicurezza su server fisicamente non protetti |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-04-07 14:01:32
Un aspetto che spesso viene sottovalutato o totalmente ignorato è la sicurezza fisica dei vari sistemi, l'accesso non autorizzato a dati sensibili può avvenire anche da locale, il classico esempio è quello della propria workstation contenente informazioni personali come numeri di carte di credito o numeri di conto correnti accessibile senza nessuna protezione di sorta come le password di sistema.
Di fatto l'accesso in locale dei propri sistemi deve essere permesso ai soli addetti ai lavori, ma dobbiamo considerare anche l'ipotesi di un "attacco" effettuato dall'interno.
Il termine sicurezza si deve estendere anche ad altre problematiche come ad esempio l'uso di un locale adeguato, con accesso controllato, per ospitare più host o la stesura di policy per il disaster recovery.
In linea di massima possiamo tracciare tre gruppi di check list per migliorare la sicurezza fisica dei propri sistemi.
Sicurezza Fisica del luogo
Ovvero tutto ciò che bisognerebbe fare per rendere più sicuro l'ambiente che ospita i sistemi.
- Accesso limitato e controllato alla sala macchina.
Sarebbe appropriato limitare e controllare tutti gli accessi ai vari locali e avvalendosi di sistemi di sicurezza elettronici come controllo. Ad esempio badge o scanner biometrici.
- Adeguare l'ambiente all'uso.
Adottare sistemi di:
Climatizzazione per mantenere l'ambiente ad un temperatura adeguata.
Anti-incendio a gas, approriati per i locali contenenti apparati elettronici ed elettrici.
Gruppi elettrogeni per l'erogazione continua di elettricità anche in caso di down della linea principale.
- Disaster recovery
Sarebbe opportuno stendere policy ed installare sistemi per il disaster recovery, effettuare il backup e spostarli dal luogo dei sistemi in produzione.
Sicurezza fisica del singolo host
I punti fondamentali per aumentare la sicurezza fisica del singolo host:
- Accesso limitato alla singola macchina
E' opportuno limitare la possibilità di accedere direttamente all'host, è bene togliere video e tastiere e impedire ove è possibile l'uso dei cdrom e dei floppy drive.
Nella maggior parte dei casi si hanno i sistemi messi in appositi armadi con serratura (rack) che limitano sia l'accesso al singolo host sia la possibilità di accedere a cavi di alimentazione o di rete. L'accesso dei sistemi dovrebbe avvenire tramite network o, in subordine, via console.
- Password sul BIOS
I comuni BIOS mettono a disposizione vari livelli di protezione basati sull'autenticazione utente tramite password. E' possibile usufruire di questa protezione sia in caso di reboot della macchina o per il solo cambiamento delle impostazioni del BIOS, la soluzione consigliata è la seconda perchè in caso di reboot volontario non verrà richiesto l'inserimento della password che dovrà essere inserita da locale.
- Boot Loader
Ulteriore possibilità di protezione al boot è la password del proprio boot loader.
In caso di un server è bene che al boot non venga richiesta nessuna password a meno che non venga modificata la procedura standard di boot, come ad esempio l'aggiunta di parametri all'avvio del kernel, questo per evitare la presenza fisica di un operatore ad ogni reboot. Analogamente va richiesta una password nei caso si cerchi di passare opzioni di boot diverse da quelle di default.
Tenere presente che queste password sono facilmente superabili nel caso in cui il sistema venga riavviato effettuando un boot da cd-rom o da floppy.
- Disattivare il reboot via ctrl-alt-del
Commentando la seguente linea in /etc/inittab
è possibile eliminare la possibilità di riavvio tramite tastiera con la sequenza ctrl-alt-del
# Trap CTRL-ALT-DELETE
#ca::ctrlaltdel:/sbin/shutdown -t3 -r now
Attenzione: il tasto di reset sul case, continua a funzionare!
Cosa deve fare l'utente di un sistema
Le azioni comuni di un operatore per aumentare la sicurezza fisica del suon sistema.
- Lock della propria postazione
Ogni qual volta ci si allontana dall'host è necessario chiudere tutte le shell aperte e in caso di X attivo lanciare lo screensaver impostato con la password, in modo tale che chi non conosce la password non possa accedere al sistema.
- Info cartacee ed elettroniche
Evitare assolutamente di scrivere password o qualsiasi altra informazione considerata strategica o sensibile al contesto in cui si opera come ad esempio password scritte sotto le tastiere o sui video oppure attaccare post-it con informazioni rilevanti come numeri di conto corrente o qualsiasi altra informazione che potrebbe rivelarsi utile per introdursi nei propri sistemi informatici.
Nel caso in cui si debba annotare tali informazioni utilizzare filesystem cryptati in caso di supporti informatici o archiviare in posti "sicuri" (cassaforti, armadi con serratura) i documenti cartacei.
LINK: InfoCare, risorse, prodotti e servizi per la sicurezza fisica di server, supporti e documenti - http://www.infocare.it
LINK: Testie indicazioni su sicurezza fisica e IT - http://www.sicurezzafisica.it
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-23 16:03:44
Il processo di boot di una macchina Linux su sistemi x86 Intel compatibili comporta diverse fasi.
Conoscerle e saperle interpretare è fondamentale per il troubleshooting di problemi di avvio.
Il boot di un sistema Linux su un sistema x386 (su altri si possono essere differenze nelle prime fasi) prevede i seguenti stadi:
1- All'accensione il BIOS su ROM non volatile definisce l'ordine dei device da utilizzare per effettuare il boot.
2- Il BOOT SECTOR del primo device di boot contiene il codice (o i riferimenti su dove trovarlo) del loader che esegue il bootstrap del sistema operativo. Nel caso di Linux il più diffuso loader è LILO, una recente alternativa evoluta è GRUB.
3- Il loader lancia il caricamento del kernel di Linux, che si copia in memoria ed esegue i controlli e il riconoscimento dell'hardware presente.
4- A fine caricamento il kernel esegue il processo init, padre di tutti i processi, che gestisce il caricamento di tutti gli altri programmi da eseguire per completare il boot.
IL BIOS SU ROM
Ogni sistema Intel ha sulla motherboard un BIOS su ROM con cui gestire l'hardware del sistema.
All'avvio di un computer non c'è nulla in RAM e nessun programma predefinito da caricare.
Le istruzioni su come procedere sono nella memoria non volatile del BIOS, in cui, fra le impostazioni definibili dall'utente, c'e' la sequenza dei dispositivi da usare per il boot.
Nei BIOS più recenti è possibile bootare da floppy, cdrom, hard disk (potendo scegliere se dare precedenza a HD IDE o SCSI) e altri dispositivi quali Zip o scheda di rete.
Il BIOS cerca, nell'ordine configurato, il boot sector sui diversi dispositivi di boot previsti.
Gli hard disk hanno un boot sector per ogni partizione e un unico Master Boot Record (MBR) che è il primo boot sector dell'intero hard disk. Se si esegue il boot da un hard disk, è il codice contenuto nel MBR che viene eseguito.
IL LINUX LOADER
Esistono diversi loader che eseguono il bootstrap del sistema operativo per Linux:
Su sistemi Intel Based: LILO, GRUB, LOADLIN, SYSLINUX, BOOTLIN;
su sistemi Alpha: MILO;
su sistemi Sparc: SILO.
Tutti di fatto eseguono la stessa funzione, alcuni (loadlin e syslinux) sono programmi DOS che eseguono il kernel caricandolo da una partizione DOS, altri sono adattamenti di LILO che riguardano sistemi non basati su processori Intel.
Nella pagina LILO, GRUB e Master Boot Record vengono analizzati nel dettaglio:
LILO - Il più conosciuto e diffuso
GRUB - Un loader più recente e versatile di LILO in rapida diffusione.
IL KERNEL
Il kernel, invocato dal loader, viene caricato in memoria ed inizializza i vari device driver, visualizzando vari messaggi utili per capire e conoscere il proprio sistema.
I dettagli sull'avvio del kernel, il riconoscimento e l'inizializzazione dell'hardware sono riportati nel TOPIC dedicato.
INIT E I SUOI FIGLI
L'ultima operazione eseguita dal kernel alla fine del suo caricamento è il lancio del processo init, il padre di tutti i processi.
Da questo momento tutto il codice eseguito lavora in user space (in kernel space lavorano solo il kernel e i suoi moduli).
L'init, tramite il suo file di configurazione /etc/inittab, provvede a lanciare tutti i programmi che completano il processo di caricamento.
LINK: A Guided Tour of a Linux Boot - http://ourworld.compuserve.com/homepages/KanjiFlash/BPTour.htm
HOWTO: The Linux Bootdisk HOWTO - http://ldp.openskills.info/HOWTO/Bootdisk-HOWTO/index.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-31 09:00:37
LILO è il Linux loader più diffuso, permette il boot sia di Linux che di altri sistemi operativi.
Generalmente l'installazione di Linux provvede a creare ed installare LILO sulla macchina (se si è scelto di installare il loader direttamente sull'hard disk e non su floppy) ma in caso di kernel upgrade o aggiunta di un nuovo sistema operativo sulla macchina è necessario modificare le sue impostazioni.
Tutte queste impostazioni sono definite nel file /etc/lilo.conf
che contiene una parte globale e una o più parti relative alle diverse immagini del kernel o sistemi operativi che si vogliono poter caricare.
Il comando /sbin/lilo
installa sul MBR o sul settore di boot di una partizione il LILO secondo le indicazioni date in /etc/lilo.conf.
Ogni volta che viene modificato /etc/lilo.conf è necessario eseguire il comando lilo per installare il nuovo LILO sul settore di boot (notare la differenza, comunemente adottata, fra il comando lilo, tutto in minuscolo, e il Linux Loader vero e proprio LILO, in maiuscolo).
Al momento del boot LILO inoltre presenta la possibilità di dare comandi vari e di scegliere quale sistema operativo o quale versione del kernel caricare, a seconda delle confgiurazioni impostate in /etc/lilo.conf.
ATTENZIONE: Operare maldestramente con LILO e il MBR può impedire il boot del sistema operativo, si suggerisce sempre di avere un dischetto di ripristino disponibile da utilizzare in caso di danni o problemi con l'MBR.
LINK: The LILO Mini HOWTO - http://www.linuxdoc.org/HOWTO/mini/LILO.html
HOWTO: LILO mini-HOWTO - http://ldp.openskills.info/HOWTO/LILO.html
HOWTO: Win95 + WinNT + Linux multiboot using LILO mini-HOWTO - http://ldp.openskills.info/HOWTO/Multiboot-with-LILO.html
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-09-02 22:48:03
LILO dispone di un command prompt che permette di eseguire operazioni più evolute della scelta del sistema operativo da caricare.
La possibilità di digitare i seguenti comandi può essere, per sicurezza, soggetta all'introduzione di una password.
TAB
Visualizza l'elenco delle label disponibili, cioè dei sistemi operativi e delle versioni del kernel selezionabili al boot.
linux rescue
Carica l'immagine con label linux in modalità single user mode (init 1) per interventi di amministrazione straordinaria sul sistema.
linux single
Come rescue, con la differenza che viene tentato il boot da disco.
root=/dev/...
Come nel file lilo.conf, definisce il dispositivo di boot permettendo di bootare, per esempio dal CDROM senza modificare il BIOS.
vga=80x25
Definisce la modalità video della console: colonne x righe.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-23 16:04:40
GRUB è un boot loader multipiattaforma estremamente flessibile e potente.
Ha una propria CLI in cui inserire a mano i parametri di boot o può presentare un'interfaccia a menu configurabile tramite il file /etc/grub.conf
.
Per installare grub sul settore di avvio basta dare il comando:
grub-install /dev/hda
(o altro nome di device di boot valido).
A differenza di LILO non c'è bisogno di ridare il comando ogni volta che si cambia la configurazione.
Per la sintassi di /etc/grub.conf
si rimanda alla relativa sezione: si consideri che avendo le stesse funzioni di Lilo, la sua logica è affine a /etc/lilo.conf
.
Solitamente all'avvio Grub si presenta con un menu da cui è possibile scegliere quale sistema operativo caricare, ma è possibile entrare in modalità comandi, simile ad una shell, in si possono eseguire svariate operazioni: dalla scelta del path del kernel, al boot via rete.
SOURCE: Grub Manual - http://www.gnu.org/manual/grub/
HOWTO: Multiboot with GRUB Mini-HOWTO - http://ldp.openskills.info/HOWTO/Multiboot-with-GRUB.html
HOWTO: Linux+Win9x+Grub HOWTO - http://ldp.openskills.info/HOWTO/Linux+Win9x+Grub-HOWTO/index.html
Tipo Infobox: PATH - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2005-01-21 10:25:18
Il file /boot/grub/grub.conf
(spesso referenziato con il symlink /etc/grub.conf
) è il file di configurazione del boot loader GRUB.
La sua logica è simile a quella del classico lilo.conf, ma la sintassi è leggermente diversa e le opzioni più numerose.
Di fatto permette di predefinire gli stessi comandi che possono essere inseriti a mano quando Grub viene avviato, rendendo ovviamente più rapida ed automatica la fase di boot.
Il file presenta una struttura di questo tipo (esempio da un RedHat standard dual boot Win-Linux):
boot=/dev/hda
Device dal quale bootare
default=0
Label (sezione) selezionata di default (0 è la prima visualizzata, in questo caso Red Hat Linux)
timeout=10
Tempo, in secondi, dopo il quale se non si effettua alcuna azione grub boota la label di default
splashimage=(hd0,2)/boot/grub/splash.xpm.gz
Path della immagine di sfondo mostrata da grub al boot
password --md5 $1$6ðòüZßXÈ$bXTLL8IbDhnwmjyaNNcPG.
Password (criptata) per poter modificare i parametri di avvio al boot
title Red Hat Linux (2.4.9-31)
Titolo della prima label, può essere un testo arbrario
root (hd0,2)
Disco (0, 1, 2...) (e partizione, dove 0 è la prima partizione e le altre a seguire) dove si trova la root directory ( / ). Notare che Grub ha una propria naming conventon sugli hard disk diversa da quella tipica di Linux: hd0 può corrispondere sia a /dev/hda che a /dev/sda.
kernel /boot/vmlinuz-2.4.9-31 ro root=/dev/hda3
Path dell'immagine del kernel. Qui possono essere definite eventuali opzioni da passare al kernel (es: vga=ext)
initrd /boot/initrd-2.4.9-31.img
Path dell'immagine da mettere in un RamDisk nelle prime fase del boot (necessario se il supporto di driver fondamentali per il caricamento del kernel (device SCSI, filesystem di / e /boot) è gestito tramite moduli).
title Win2K
Titolo della seconda label
rootnoverify (hd0,0)
Disco (e partizione) su cui procedere per il boot di un sistema operativo non supportato (lascia al settore di boot della partizione indicata l'onere del bootstrap dell'OS)
chainloader +1
Passa il compito di bootare ad un altro boot loader (in questo caso quello di Windows)
A differenza di Lilo, con Grub quanto scritto in questo file di configurazione è immediatamente attivo e non va eseguito alcun comando per rendere definitive le modifiche (con Lilo va eseguito il comando lilo
ogni volta che si modifica lilo.conf
(riscrive il MBR)).
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-01-28 10:48:05
E' possibile tramite semplici operazioni effettuare un password recovery di un sistema linux.
Tutto quello che si deve avere a disposizione è un cd-rom o un dischetto bootabile con un kernel linux ed un editor di testo come vi.
La prima operazione è quella di riavviare il sistema inserendo il cd o dischetto contenente un'immagine di un kernel funzionante.Il primo cd della propria distribuzione è piu' che sufficiente. Ovviamente sul BIOS vanno impostati il floppy disk o il CDROM come device di boot primari.
Una volta che il sistema ha completato il boot da cd-rom o da dischetto abilitare il caricamento del kernel in modalità rescue:
boot: linux rescue
Verrà caricato un sistema Linux in INIT 1 in cui viene presentato il prompt di una shell senza la necessità di inserire login o password.
Quando si avrà una shell disponibile montare la partizione di root.
Ammettiamo che sia hda3 e che si scelga un mount point arbitrario come /mnt/cdrom:
[bash-2.0.3]$ mount -t ext3 /dev/hda3 /mnt/cdrom
Nel caso in cui si utilizza il primo CD della distribuzione RedHat in modo del tutto automatico il sistema salvato sul proprio hard-disk verrà montato in /mnt/sysimage/ e si verrà avvisati dal seguente messaggio:
The rescue environment will now attempt to find your Red Hat
Linux installation and mount it under the directory
/mnt/sysimage. You can then make any changes required to your
system. If you want to proceed with this step choose
'Continue'. You can also choose to mount your filesystem
read-only instead of read-write by choosing 'Read-only'.
If for some reason this process fails you can choose 'Skip'
and this step will be skipped and you will go directly to a
command shell.
Ora si ha completo accesso ai file presenti nella partizione montata, senza limitazioni su permessi e owner, per cui basta disabilitare la vecchia, non più nota, password, cancellando la entry opportuna nel file /etc/shadow.
Ammettiamo di effettuare il password recovery per l'utente root:
sh-2.05a# vi /mnt/cdrom/etc/shadow
root:$1$Uowq9pDe$.76a1DuKc9rxSSk.P25xP.:12017:0:99999:7:::
[....]
Cancellare il campo relativo alla password, come nell'esempio
root::12017:0:99999:7:::
Salvare il file e riavviare il sistema. (Ricordarsi di togliere il cd-rom o il dischetto utilizzato per il boot)
In questo caso al momento del login, se si inserirà come username root non verrà chiesta nessuna password e l'utente verra autenticato come root.
Ricordarsi di settare una nuova password per root.
Come si può notare se si ha accesso fisico ad un PC con Linux installato è facile poter cambiare la password di root ed avere completo controllo del sistema. Per proteggere fisicamente una macchina da simili modifiche di deve quindi:
- Mettere una password su BIOS per evitare che qualcuno possa alterare l'ordine dei device di boot e impostare l'hard disk dove è installato Linux come device primario.
- Mettere una password su LILO o su GRUB, in modo da evitare che si possa eseguire un boot in init 1 con un comando tipo linux single
.
- Impedire (da veri paranoici) la possibilità di aprire il case del PC evitando che possa essere spostato il jumper sulla motherboard che resetta le impostazioni del BIOS.
LINK: RedHat Ufficial Docs - http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/custom-guide/s1-rescuemode-boot.html
La logica della sicurezza sui sistemi Unix / Linux |
Utenti e root, permessi, attributi, limiti: le proprietà di sicurezza dei sistemi Unix. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-09-20 10:27:33
Unix è un sistema operativo multiuser che, oltre all'utente root, con privilegi di amministrazione, prevede utenti di sistema (usati per eseguire processi e demoni) e utenti umani che utilizzano e accedono in vario modo alla macchina.
La gestione (aggiunta, modifica, cambio password, cancellazione) degli utenti del sistema è tipicamente compito di root, che ha a disposizione su diversi sistemi Unix variegati programmi grafici o comandi testuali per queste operazioni.
I comandi più comuni e standard per gestire gli utenti sono:
useradd [opzioni] nomeutente
Aggiunge un utente al sistema. Prevede varie opzioni per definire impostazioni specifiche.
userdel [opzioni] nomeutente
Elimina un'utente. Su molti Unix questo comando non cancella la home directory dell'utente.
groupadd [opzioni] nomegruppo
Aggiunge un gruppo.
passwd [nomeutente]
Modifica la password. Tutti gli utenti, tranne root, possono cambiare solo la propria password.
Il file con l'elenco di tutti gli utenti è, su tutti i sistemi Linux, /etc/passwd
, qui ci sono informazioni sulla login dell'utente, la shell utilizzata, la posizione della sua home directory, dove l'utente può liberamente scrivere dati e documenti.
In tutti i Linux moderni, la password, criptata viene scritta nel file /etc/shadow
dove vengono mantenute altre informazioni relative alla gestione della stessa.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-28 22:43:34
Storicamente su Unix il file /etc/passwd
contiene l'elenco di tutti gli utenti e la loro password in forma criptata.
Per la stessa natura di Unix tutti gli utenti devono poter aver accesso in lettura a questo file, per cui l'esporre le password di tutti, seppur criptate, risultava rischioso per la sicurezza del sistema.
Su tutti i Linux e gli Unix non troppo vecchi, la gestione della password è stata migliorata sia in termini di sicurezza che di versatilità affiancando al normale /etc/passwd
la gestione del file /etc/shadow
che introduce nuove funzionalità:
- Questo file è leggibile solo da root mentre viene lasciato l'accesso il lettura a /etc/passwd per tutti gli utenti;
- Le password in /etc/shadow sono criptate con algoritmi più complessi e robusti;
- E' possibile gestire il tempo di scadenza, la durata minima e massima e i tempi di notifica della password.
Notare che:
- se la password è scritta in /etc/shadow, in /etc/passwd c'è solo una x al posto della password criptata.
- se in /etc/passwd il campo password è un * , la password è nulla e l'utente non può accedere al sistema.
Tipo Infobox: PATH - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2003-11-28 23:04:51
Il file /etc/passwd
è il database degli utenti su ogni sistema Unix. Ad ogni user è dedicata una riga che definisce quali sono i suoi principali attributi. Sui sistemi Unix meno recenti in questo file viene scritta anche la password (criptata), su quelli più recenti viene scritta, generalmente, in /etc/shadow
, che ha maggiori restrizioni in termini di sicurezza.
Le righe di /etc/passwd si presentano nella seguente forma:
Username:Password:UserID:GroupID:Info:HomeDirectory:Shell
Username:
Nome dell'user, la login con cui può accedere al sistema;
Password:
Campo riservato alla password dell'utente. Può essere scritta direttamente in forma criptata o esserci semplicemente una x
(la password c'è ma è scritta altrove, di solito in /etc/shadow
). Se c'è un *
(asterisco) significa che l'utente o non ha una password o la password non è valida (in questo caso non gli è permesso di login);
UserID:
ID dell'user;
GroupID:
ID del gruppo di appartenenza;
Info:
Contiene informazioni sull'utente non necessarie al sistema (nome esteso, numero di telefono, mail ecc...);
HomeDirectory:
Indica la directory della home dell'utente;
Shell:
Indica la shell di default per quell'utente.
Un esempio:
[diego@vagante diego]$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
[...]
diego:x:501:503::/home/diego:/bin/bash
Tipo Infobox: PATH - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2003-11-28 23:07:52
Il file /etc/shadow
è il database delle password sui Unix più evoluti. In esso sono elencate per ogni utente la password (criptata) e vari parametri ad essa connessi (ultima modifica, durata massima e minima, ecc...). Ad esso fanno riferimento diversi files, fra cui /etc/passwd e tutti i comandi per la gestione degli utenti (useradd, userdel, usermod).
Le righe in /etc/shadow si presentano nella seguente forma:
Username:password:lastchange:min:max:warn:inactive:expire:
Username:
Il nome dell'utente a cui fa riferimento la password;
Password:
Password criptata (13 caratteri). Puo assumere anche altri valori quali *
(asterisco) che sta ad indicare che l'utente è disabilitato e !!
(o nessun carattere) che significa che l'utente non ha password (cosa molto pericolosa in termini di sicurezza);
lastchange:
Numero di giorni compresi fra il 1 gennaio 1970 e l'ultima modifica della password;
min:
Minimo numero di giorni dall'ultima data di modifica prima di poter nuovamente cambiare la password;
max:
Durata massima della password (sempre in giorni);
warn:
Numero di giorni di preavviso all'utente prima di invalidare la password;
inactive:
Numero di giorni di inattività possibili per quell'utente.
expire:
Data dopo la quale quel login non può più essere usato.
Un esempio da un RedHat Linux standard evidenzia che di default non sono previste scadenze per la password e vari altri parametri:
[diego@vagante diego]$ cat /etc/passwd
:root:$1$ÐQEXe5ÀJ$Jffvxi5UaGHpaMckCsKH0:11628:0:99999:7:::
:daemon:*:11628:0:99999:7:::
[...]
:xfs:!!:11628:0:99999:7:::
Tipo Infobox: PATH - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2003-11-28 23:09:49
Il file /etc/group
contiene l'elenco dei gruppi di utenti presenti nel sistema. Ad ogni gruppo è associata una riga nella quale si trova l'IDgroup e l'elenco degli utenti che ne fanno parte.
Alcuni Unix creano un nuovo gruppo per ogni nuovo utente, altri hanno il gruppo "users" in cui vengono automaticamente inseriti tutti gli utenti aggiunti al sistema.
Di fatto i gruppi servono per gestire con maggiore flessibilità l'accesso ai file e di conseguenza l'uso delle risorse.
Le righe di /etc/group si presentano nella seguente forma:
GroupName:Password:GroupID:User1,User2,...,UserN
GroupName:
Indica il nome del gruppo;
Password:
Indica la password del gruppo. Solitamente non viene data una password al gruppo ma solo ai singoli utenti;
GroupID:
Indica l'ID associato a quel gruppo;
User1,User2,...,UserN:
E' l'elenco degli users appartenenti a quel gruppo. I nomi dei singoli users devono essere sparati da una virgola.
Un esempio:
[diego@vagante diego]$ cat /etc/group
root:x:0:root
bin:x:1:root,bin,daemon
[...]
wheel:x:10:root,macno
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-21 19:45:02
Formatta e visualizza informazioni relative all'ultimo login di tutti gli utenti del sistema.
Ottiene le proprie informazioni dal file /var/log/lastlog.
lastlog [-u login] [-t giorni]
-u login
Visualizza l'ultimo login solo dell'utente specificato
-t giorni
Visualizza i last login effettuati negli ultimi giorni indicati (es: -t 2)
SOURCE: Man Pages - http://man.openskills.info/lastlog
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-08-13 19:21:57
Visualizza l'elenco degli ultimi accessi al sistema, elencando nome utente, data, console utilizzata, IP e durata della sessione. Ottiene queste le informazioni da /var/log/wtmp.
Una versione leggermente diversa è lastb
che visualizza le login di accesso al sistema fallite (ha bisogno del file /var/log/btmp, se esiste).
last [-R] [-righe] [-adx] [ -f file ] [nome_utente] [tty]
-righe, -n righe
Specifica quante righe mostrare (es: -n 10)
-f file
Specifica un file alternativo a /var/log/wmtp dove trovare le informazioni relative ai login.
nome_utente
Visualizza solo le informazioni di login dell'utente specificato.
tty
Visualizza solo le informazioni di login del terminale specificato (es: pts/0 )
SOURCE: Man Pages - http://man.openskills.info/last
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-06-17 13:46:18
Alcuni sysadm particolarmente sensibili a problematiche di sicurezza e controllo ritengono che non si dovrebbe mai amministrare la macchina come utente root, ma utilizzare esclusivamente un utente normale e, quando è necessario, "diventare" root per eseguire funzioni da superuser.
Con il comando su
si può impersonificare (sapendo la password) qualsiasi utente (di default, se non viene specificato "su nomeutente", questo comando si utilizza per diventare root).
Se si è già loggati come root è possibile impersonificare qualsiasi utente senza dover digitare la password.
E' raccomandabile non permettere l'accesso remoto, via telnet, ssh o analoghi, direttamente all'utente root.
Il comando sudo
permette di accordare a semplici utenti la possibilità di eseguire comandi che solo root potrebbe lanciare. Le policy su chi può fare cosa sono definite nel suo file di configurazione /etc/sudoers
.
Quando si usa sudo viene richiesta la password dell'utente stesso (non quella di root), sempre se l'utente è autorizzato ad eseguire il comando richiesto.
Con sudo -s
di fatto viene aperta una shell di root, dalla quale è poi possibile operare con i diritti del superuser.
Su alcuni sistemi, la password di root può essere disattivata e ogni attività da superuser viene fatta tramite sudo.
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-05-05 15:27:41
Sudo (superuser do) è un utility che permette di eseguire comandi con i permessi di un altro utente, tipicamente utilizzato per eseguire comandi che solamente root potrebbe lanciare.
sudo è un ottima soluzione per gestire e controllare gli accessi e le azioni degli utenti, sia perchè permette di eseguire comandi che tipicamente un utente normale non potrebbe sia perchè offre la possibilità di loggare nei minimi dettagli qualsiasi azione.
Inoltre se si aggiunge il vantaggio di non dover utilizzare l'account di root per le normali operazioni di amministrazione come ad esempio riavvio di un servizio, assicura un certo vantaggio in ambito sicurezza oltre che limitare in modo ulteriore la conoscenza della password di root.
Le principali feature di questa utility sono:
- Limitare o permettere la possibilità di eseguire un certo comando ad un gruppo o ad un singolo utente
- Logging, per ogni comando eseguito.
- Ticketing system, ovvero è possibile configurare sudo in modo tale che ogni volta che viene invocato, l'utente possa inserire una sola volta la password anche in caso di una sequenza di comandi. Ovviamente dopo un certo timeout configurabile verrà richiesta nuovamente la password.
- La struttura del file di configurazione permette una configurazione centralizzata, un file di configurazione valido per più host.
Installazione
Il download dei sorgenti è possibile dall'home page ufficiale: http://www.sudo.ws/dist/, mentre per il download dei rpm è possibile appoggiarsi a http://www.rpmfind.net
[root@SATURNO root]# wget http://www.sudo.ws/dist/sudo-1.6.7p3.tar.gz
--14:53:03-- http://www.sudo.ws/dist/sudo-1.6.7p3.tar.gz
=> `sudo-1.6.7p3.tar.gz'
[...]
[root@SATURNO root]# tar zxvf sudo-1.6.7p3.tar.gz
sudo-1.6.7p3/
sudo-1.6.7p3/alloc.c
sudo-1.6.7p3/alloca.c
sudo-1.6.7p3/check.c
sudo-1.6.7p3/def_data.c
sudo-1.6.7p3/defaults.c
[...]
Nel caso in cui si vogliano utilizzare le impostazioni di default occorre semplicemente lanciare lo script configure seguito da make e make install, per personalizzare l'installazione occorre specificare le singole opzioni con lo script configure, ecco alcuni esempi di interessanti opzioni:
--disable-root-sudo
Non permette a root di eseguire sudo
--disable-path-info
Printa a video 'command not allowed' al posto di 'command not found'
--without-passwd
Disabilita l'utenticazione tramite passwd o shadow
--with-insults
Insulta l'utente che sbaglia la password
Esempio di compilazione:
Lancio dello script configure per la creazione del Makefile
[root@SATURNO sudo-1.6.7p3]# ./configure --prefix=/usr --with-pam --with-insults --with-all-insults
[...]
checking for log file location... /var/log/sudo.log
checking for timestamp file location... /var/run/sudo
configure: creating ./config.status
config.status: creating Makefile
config.status: creating sudo.man
config.status: creating visudo.man
config.status: creating sudoers.man
config.status: creating config.h
config.status: creating pathnames.h
configure: You will need to customize sample.pam and install it as /etc/pam.d/sudo
Creazione del file di configurazione per PAM, il file di esempio all'interno dei sorgenti (sample.pam) è utilizzabile solo in due due casi, quello attivo di default (non commentato) permette di autenticare l'utente tramite /etc/passwd , il secondo non attivo (commentato) prevede l'uso di un Master domain controller per l'autenticazione utente
[root@SATURNO sudo-1.6.7p3]# cp sample.pam /etc/pam.d/sudo
[root@SATURNO sudo-1.6.7p3]# cat /etc/pam.d/sudo
#%PAM-1.0
[...]
#auth required /lib/security/pam_smb_auth.so
auth required /lib/security/pam_pwdb.so shadow nullok
Compilazione e installazione
[root@SATURNO sudo-1.6.7p3]# make
gcc -c -I. -I. -O2 -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 check.c
gcc -c -I. -I. -O2 -D_PATH_SUDOERS=\"/etc/sudoers\" -D_PATH_SUDOERS_TMP=\"/etc/sudoers.tmp\" -DSUDOERS_UID=0 -DSUDOERS_GID=0 -DSUDOERS_MODE=0440 env.c
[...]
[root@SATURNO sudo-1.6.7p3]# make install
/bin/sh ./mkinstalldirs /usr/bin \
/usr/sbin /etc \
/usr/man/man8 /usr/man/man5
mkdir /usr/man
[...]
Configurazione
Il file di configurazione di sudo è /etc/sudoers modificabile tramite l'utility visudo, che risulta essere un editor con gli stessi comandi di vi con il plus del check della sintassi del file.
La sintassi del file di configurazione prevede due parti:
- aliases (opzioni e variabili di base):
Creazione di gruppi di utenti
User_Alias ADMINS = neo, led
User_Alias OPERATORS = pippo, nobody
Creazione di gruppi di comandi
Cmnd_Alias SHUTDOWN = /usr/sbin/shutdown, /usr/bin/halt, /usr/bin/reboot
Creazione di gruppi di host
Host_Alias SERVERS = ns, www, mail
Host_Alias WORKSTATION = saturno, dido, trinity
- user specifications (opzioni e variabili specifici dell'utente, chi ,cosa e come può eseguire):
L'utente root può eseguire qualunque comando, in qualunque host come se fosse qualunque utente
root ALL = (ALL) ALL
Tutti gli utenti appartenenti al gruppo ADMINS possono lanciare qualsiasi comando senza inserire una password
ADMINS ALL = NOPASSWD: ALL
Tutti gli utenti appartenenti al gruppo OPERATOR possono lanciare i comandi relativi al gruppo SHUTDOWN
OPERATORS WORKSTAION = SHUTDOWN
Ulteriori esempi si possono trovare all'interno dei sorgenti sample.sudoers o al seguente indirizzo: http://www.courtesan.com/sudo/man/sudoers.html#examples.
LINK: Home page sudo - http://www.courtesan.com/sudo/sudo.html
SOURCE: sito - http://www.courtesan.com/sudo/sudo.html
LINK: Storia di SUDO - http://www.courtesan.com/sudo/history.html
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-08-13 18:38:55
Permette di aprire una shell avendo i permessi di un altro utente. Se non viene specificato l'utente, viene usato il superuser (root) di default. Se l'operazione comporta un aumento dei propri poteri viene richiesta la password dell'utente specificato.
Presente anche in Unix, in alcuni casi con la sola opzione -
.
su [opzioni] [-] [-c comando] [nome_utente] [argomenti_shell]
-, -l, --login
Invoca la shell eseguendo tutti i relativi script di startup e ricreando l'environment dell'utente (se non specificato viene mantenuto l'environment dell'utente che l'ha eseguito)
-c comando
Esegue il comando specificato in una nuova shell e termina immediatamente.
SOURCE: Man Pages - http://man.openskills.info/su
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-05-05 21:05:20
Utility che permette di eseguire un comando come se fosse un altro utente.
Tipicamente utilizzato per lanciare comandi come root da utenti "normali".
sudo [opzioni] commando
Opzioni comunemente utilizzate:
-l
Visualizza i comandi permessi e negati dell'utente corrente
-b
Esegue il comando in background
-s
Esegue la shell dell'utente specificato, se non si specifica nessun utente viene richiamata una shell con i permessi di root
-p prompt
Visualizza il "prompt" specificato e sovrascrive quello di default
-a auth_type
Specifica il tipo di autenticazione utente utilizzato da sudo
-u username|#uid
Specifica con quale utente dovrà essere lanciato il comando, se l'opzione è omessa sudo interpreterà il comando come se dovesse lanciare il comando da utente root
Esempi:
Lancio di un singolo comando
[neo@dido neo]$ sudo /etc/rc.d/init.d/cups restart
Password:
Stopping cups: [ OK ]
Starting cups: [ OK ]
Richiamare la shell di root
[neo@dido neo]$ sudo -s
Password:
[root@dido neo]#
Visualizzazione dei comandi che si possono lanciare tramite sudo:
[neo@dido neo]$ sudo -l
User neo may run the following commands on this host:
(ALL) ALL
Tipo Infobox: COMMANDS - Skill Level: 4- ADVANCED - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-04-07 22:54:58
Utility per l'editing del file di configurazione di sudo: /etc/sudoers
.
Di fatto è un editor come vi con la possibilità di eseguire controlli sulla sintassi del file sudoers.
visudo [ -c ] [ -f sudoers ] [ -q ] [ -s ] [ -V ]
-c
Abilita solo il check del file di configurazione
-f sudoers
Specifica il file di configurazione
-q
Abilita il quiet mode, nemmeno gli errori di sintassi vengono segnalati
-s
Abilita lo strict check
Check della sintassi del file di configurazione:
[root@SATURNO sudo-1.6.7p3]# visudo -c
/etc/sudoers file parsed OK
Tipo Infobox: BOFH - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-06-25 00:35:28
Visualizza tutte le impostazioni correnti sui limiti di utilizzo delle risorse del sistema considentiti agli utenti. Fra i parametri su cui si possono settare limiti ci sono: dimensione del file di coredump (core), dimensione della memoria utilizzabile, numero dei processi che possono essere eseguiti dal'utente ecc.
Alcune di queste limitazioni e altre, tra cui il numero massimo di login contempomporanee per utente, si possono solitamente configurare in /etc/security/limits.conf
.
[al@socrate al]$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 4095
virtual memory (kbytes, -v) unlimited
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-11-28 23:16:22
File di configurazione, sui Linux basati sulla distribuzione RedHat che contiene tutte le opzioni di default sugli utenti del sistema.
[neo@dido skel]$ cat /etc/login.defs
# *REQUIRED*
# Directory where mailboxes reside, _or_ name of file, relative to the
# home directory. If you _do_ define both, MAIL_DIR takes precedence.
# QMAIL_DIR is for Qmail
#
#QMAIL_DIR Maildir
MAIL_DIR /var/spool/mail
#MAIL_FILE .mail
# Password aging controls:
#
# PASS_MAX_DAYS Maximum number of days a password may be used.
# PASS_MIN_DAYS Minimum number of days allowed between password changes.
# PASS_MIN_LEN Minimum acceptable password length.
# PASS_WARN_AGE Number of days warning given before a password expires.
#
PASS_MAX_DAYS 99999
PASS_MIN_DAYS 0
PASS_MIN_LEN 5
PASS_WARN_AGE 7
#
# Min/max values for automatic uid selection in useradd
#
UID_MIN 500
UID_MAX 60000
#
# Min/max values for automatic gid selection in groupadd
#
GID_MIN 500
GID_MAX 60000
# If defined, this command is run when removing a user.
# It should remove any at/cron/print jobs etc. owned by
# the user to be removed (passed as the first argument).
#
#USERDEL_CMD /usr/sbin/userdel_local
#
# If useradd should create home directories for users by default
# On RH systems, we do. This option is ORed with the -m flag on
# useradd command line.
#
CREATE_HOME yes
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-08-21 22:09:07
Tutti i sistemi Unix hanno una gestione standard dei permessi sui file, che rispecchia la natura di sistema operativo multiutente.
I permessi possono essere di lettura, scrittura e esecuzione e vengono differenziati sulla base della natura dell'utente rispetto al file o directory:
- utente proprietario owner del file
- gruppo proprietario owner group del file
- gli altri utenti others, che sono l'owner e non appartegono all'owner group.
Il permesso di esecuzione è necessario per poter accedere a delle directory e, ovviamente, permette l'esecuzione di file (script shell, perl, php, cgi; programmi binari compilati).
Per visualizzare i permessi di un file basta usare il comando ls -l
che per ogni file da un output simile a:
-rwxr-xr-- 1 mark admins 77266 Dec 13 17:18 /bin/command.sh
La prima colonna, composta da 10 caratteri, descrive i permessi sul file /bin/command.sh.
Il primo carattere (nell'esempio: -) identifica il tipo di file (directory, pipe, block o char device, symlink...);
I successivi 3 caratteri identificano i permessi in lettura/scrittura/esecuzione dell'owner di /bin/command.sh (in questo caso l'owner mark ha tutti i permessi sul file: rwx );
I successivi 3 identificano i permessi del gruppo owner di /bin/command.sh (in questo caso il gruppo admins ha permesso di lettura ed esecuzione sul file: r-x );
I successivi 3 identificano i permessi di tutti gli altri utenti del sistema (in questo caso hanno solo il permesso di lettura: r-- ).
Le successive colonne nell'output di ls -l indicano l'owner, il gruppo, la dimensione in byte, la data di ultima modifica e il nome del file.
Per modificare i permessi dei file si usa il comando chmod che usa una duplice sintassi per indicare i permessi:
read - lettura: Flag r in symbolic mode; Valore 4 in octal mode
write - scrittuta: Flag w in symbolic mode; Valore 2 in octal mode
execute - esecuzione: Flag x in symbolic mode; Valore 1 in octal mode
LINK: About.com : Unix file security - http://unix.about.com/library/weekly/aa090400a.htm
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-23 15:47:52
Modifica il proprietario di uno più file. Può essere fatto solo da root o dal proprietario corrente del file.
E' un comando comune in tutti gli Unix.
chown [opzioni] nuovo_proprietario file
chown [opzioni] nuovo_proprietario:nuovo_gruppo file
-c
(--changes) Visualizza informazioni sui file che vengono modificati
-R
(--recursive) Applica le modifiche alla directory indicata e a tutte le sue sottodirectory
--reference=file_origine
Applica al file specificato nella riga di comando lo stesso proprietario che ha file_origine
-f
(--silent) Non stampa messaggi di errore sui file che non possono essere modificati
-v
(--verbose) Visualizza dettagliate informazioni su ogni file che chown tenta di modificare.
Esempi
chown al /var/tmp/alien
Imposta al come propietario del file /var/tmp/alien
chown beppe:beppe /home/file
Imposta owner beppe e group owner beppe al file /home/file
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-28 22:22:34
Modifica gli attributo di accesso su uno o più file. Solo il proprietario del file, o l'utente root, può modificarne gli attributi. E' un comando comune in tutti gli Unix.
chmod [opzioni] modo file
-c
(--changes) Visualizza informazioni sui file che vengono modificati
-R
(--recursive) Applica le modifiche alla directory indicata e a tutte le sue sottodirectory
--reference=file_origine
Applica al file specificato nella riga di comando gli stessi permessi che ha file_origine
-f
(--silent) Non stampa messaggi di errore sui file che non possono essere modificati
Esistono due diversi modi per definire i permessi su un file:
SYMBOLIC MODE
I permessi vengono definiti nella forma: chi-opcode-permesso.
CHI può essere:
u USER - Utente proprietario del file
g GROUP - Gruppo proprietario del file
o OTHER - Altri utenti
a ALL - Tutti gli utenti del sistema (default)
OPCODE può essere:
+ Aggiunge un permesso
- Rimuove un permesso
= Assegna un permesso (e rimuove tutti quelli non specificati)
PERMESSO può essere:
r READ - Lettura sul file
w WRITE - Scrittura sul file
x EXECUTE - Esecuzione del file (o apertura della directory)
s SET USER ID - Il file (comando) viene eseguito con i permessi dell'owner sul file system, anche quando viene eseguito da altri utenti. Questo attributo è a volte necessario in alcuni comandi lanciati da utenti normali che hanno accesso sul sistema con i permessi di root (es: traceroute).
t STICKY BIT - Normalmente un utente può cancellare tutti i file contenuti in una directory su cui ha permesso di scrittua, anche se non ha permessi di scrittura sul file stesso. Con lo Sticky bit impostato, ciò non è possibile: l'utente può cancellare il relativo file solo se ha permessi di scrittura sul file stesso
u Lascia i permessi correnti dell'utente owner
g Lascia i permessi correnti del gruppo owner
o Lascia i permessi correnti per gli altri utenti
OCTAL MODE
E' un metodo alternativo che permette di definire i permessi con un numero ottale composta da tre cifre:
la prima indica i permessi per l'utente owner, la seconda per il gruppo, la terza per gli altri.
I permessi vengono calcolati sommando i seguenti valori ottali:
4 - Lettura
2 - Scrittura
1 - Esecuzione.
In questo modo il permesso di lettura+scrittura+esecuzione si indica con il numero 7 (4+2+1), il permesso di lettura, esecuzione con 5 (4+1) e così via.
E' inoltre possibile indicare una quarta cifra (da far precedere alle 3 usuali) per permettere l'assegnamento dei seguenti permessi spciali:
4 - Imposta lo UserId per l'esecuzione
2 - Imposta il GroupID
1 - Imposta lo sticky bit.
Esempi
Per impostare i permessi totali all'owner, e solo in lettura a tutti gli altri si hanno le seguenti possibilità:
chmod 744 /home/file
chmod u=rwx,go=r /home/file
Per impostare permessi di sola lettura per l'owner e il group e nessun permesso per gli altri:
chmod 440 /home/file
chmod ug=r,o-rwx /home/file
Per impostare totali permessi per tutti gli utenti su un file:
chmod 777 /home/file
chmod ugo=rwx /home/file
Per impostare lo sticky bit su un file e permessi totali solo per l'owner e di sola lettura per il group:
chmod 1740 /home/file
chmod u=srwx,g=r,o-rwx
LINK: Set-User-ID Permission for Executable Files - http://heather.cs.ucdavis.edu/~matloff/UnixAndC/CLanguage/SetUserID.html
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: ivan 'kaharoth' molella - Ultimo Aggiornamento: 2002-12-18 19:24:02
chattr imposta gli attributi di un file su un file system linux di tipo ext2/ext3.
Andando a lavorare su particolari attributi peculiari di questi file system chattr non è un comando unix standard.
chattr [-RV] [-v versione ] [+/-= attrib] file ...
-R
Ricorsivo
-V
Stampa gli attributi modificati
-v versione
Imposta la versione di un file.
Attributi
a
il file può essere aperto solo in append mode.
c
il file è compresso/decompresso dal kernel su disco
d
Non verrà eseguito il backup su di esso dall' utility dump.
i
Il file non può essere modificato in alcun modo.
s
Il file è cancellato e i suoi blocchi sono azzerati e scritti su disco.
S
I cambiamenti sono scritti in modo sincrono su disco
u
Il file è cancellato e il suo contenuto è salvato per un eventuale ripristino.
NB: gli attributi 'c' ed 'u' non sono attualmente implementati.
Tipo Infobox: BOFH - Skill Level: 4- ADVANCED - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-12-18 19:49:14
Cerca all'interno di tutto il file system i file o le directory che hanno impostato il bit setuserid o setgroupid, che permettono l'esecuzione di comandi con privilegi di root anche da parte di utenti normali e rappresentano un potenziale problema di sicurezza.
La quantità di simili file su un normale sistema Unix è notevole. Segue un esempio su una RedHat 8.0 con installazione di default.
[root@51 al]# find / \( -perm -04000 -o -perm -02000 \) -ls
289237 4 drwxr-sr-x 2 root ftp 4096 Jun 23 15:50 /var/ftp/pub
320100 40 -rwsr-xr-x 1 root root 37688 Aug 29 23:20 /usr/bin/chage
320102 36 -rwsr-xr-x 1 root root 35000 Aug 29 23:20 /usr/bin/gpasswd
320431 12 -r-xr-sr-x 1 root tty 10224 Jul 19 04:14 /usr/bin/wall
320527 20 -rws--x--x 1 root root 16835 Aug 30 22:00 /usr/bin/chfn
320528 16 -rws--x--x 1 root root 15664 Aug 30 22:00 /usr/bin/chsh
320546 8 -rws--x--x 1 root root 6999 Aug 30 22:00 /usr/bin/newgrp
320557 20 -rwxr-sr-x 1 root tty 18605 Aug 30 22:00 /usr/bin/write
320568 40 -rwsr-xr-x 1 root root 37140 Jul 25 04:45 /usr/bin/at
321011 16 -r-s--x--x 1 root root 15368 May 28 2002 /usr/bin/passwd
321016 20 -rwxr-sr-x 1 root mail 17477 Jun 24 01:09 /usr/bin/lockfile
321081 20 -rwsr-xr-x 1 root root 19131 Jun 24 02:05 /usr/bin/rcp
321083 16 -rwsr-xr-x 1 root root 15376 Jun 24 02:05 /usr/bin/rlogin
321084 12 -rwsr-xr-x 1 root root 10689 Jun 24 02:05 /usr/bin/rsh
321099 32 -rwxr-sr-x 1 root slocate 31661 Jun 24 02:22 /usr/bin/slocate
321103 88 ---s--x--x 1 root root 84984 Jun 28 01:57 /usr/bin/sudo
321122 36 -rwsr-xr-x 1 root root 34662 Jul 20 00:51 /usr/bin/crontab
321795 12 -rwsr-xr-x 1 root root 8345 Sep 5 15:19 /usr/bin/desktop-create-kmenu
321803 20 -rwsr-xr-x 1 root root 17743 Sep 5 14:06 /usr/bin/kcheckpass
321814 64 -rwxr-sr-x 1 root root 60955 Sep 5 14:33 /usr/bin/kdesud
244475 8 -rws--x--x 1 vcsa root 7491 Aug 23 21:32 /usr/lib/mc/bin/cons.saver
64012 8 -rwsr-xr-x 1 root root 5100 Sep 6 00:58 /usr/libexec/pt_chown
144607 164 -rws--x--x 1 root root 162476 Aug 14 06:08 /usr/libexec/openssh/ssh-keysign
96111 36 -rwsr-xr-x 1 root root 33071 Jun 23 20:14 /usr/sbin/ping6
96115 16 -rwsr-xr-x 1 root root 13718 Jun 23 20:14 /usr/sbin/traceroute6
96515 16 -rwxr-sr-x 1 root utmp 15570 Jun 24 03:00 /usr/sbin/utempter
96526 16 -rwsr-xr-x 1 root root 15502 Sep 4 19:23 /usr/sbin/usernetctl
96544 32 -rws--x--x 1 root root 29676 Sep 4 22:32 /usr/sbin/userhelper
96755 12 -rwsr-xr-x 1 root root 10205 Jul 1 19:27 /usr/sbin/userisdnctl
97243 16 -rwxr-sr-x 1 root utmp 13414 Aug 30 00:54 /usr/sbin/gnome-pty-helper
96932 16 -rwxr-sr-x 1 root lock 12325 Jun 23 22:26 /usr/sbin/lockdev
97254 744 -rwxr-sr-x 1 root smmsp 754801 Aug 29 21:38 /usr/sbin/sendmail.sendmail
97397 32 -rwsr-xr-x 1 root root 32076 Jun 24 02:41 /usr/sbin/traceroute
100260 20 -r-s--x--- 1 root apache 20469 Sep 4 23:23 /usr/sbin/suexec
100385 100 -rwxr-sr-x 1 root postdrop 95744 Jul 24 13:20 /usr/sbin/postdrop
100391 88 -rwxr-sr-x 1 root postdrop 84885 Jul 24 13:20 /usr/sbin/postqueue
98934 1844 -rws--x--x 1 root root 1884018 Sep 6 05:29 /usr/X11R6/bin/XFree86
160313 36 -rwsr-xr-x 1 root root 35302 Jun 23 20:14 /bin/ping
160390 88 -rwsr-xr-x 1 root root 81996 Aug 30 22:00 /bin/mount
160391 40 -rwsr-xr-x 1 root root 40700 Aug 30 22:00 /bin/umount
160416 20 -rwsr-xr-x 1 root root 19132 Aug 29 22:56 /bin/su
176244 8 -r-s--x--x 1 root root 7132 Aug 2 17:08 /sbin/pam_timestamp_check
176245 124 -r-sr-xr-x 1 root root 119592 Aug 2 17:08 /sbin/pwdb_chkpwd
176246 20 -r-sr-xr-x 1 root root 17180 Aug 2 17:08 /sbin/unix_chkpwd
176279 16 -rwxr-sr-x 1 root root 12578 Sep 4 19:23 /sbin/netreport
Passwords e password cracking |
Scelta di password sicure e metodi di password cracking. |
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-02-28 15:55:04
L'obiettivo ultimo di un hacker è quello di riuscire ad avere i privilegi di root (Administrator) sul sistema attaccato per averne pieno controllo, ciò può avvenire o tramite l'exploit di programmi e servizi vulnerabili o a causa di errori di amministrazione come la configurazione sbagliata di un servizio o l'impostazione di policy errate per la gestione degli utenti e delle relative password.
Una via, relativamente semplice, per compromettere un sistema è quella di accederci come utente "normale" e poi tramite l'utilizzo di bachi di package installati elevarsi a root o administrator.
Ovviamente, come è pure intuibile, questa semplicità relativa dipende dalle policy utilizzate per definire gli username e le password.
E' essenziale creare una policy ed educare gli utenti di un sistema ad utilizzare password difficilmente reperibili seguendo semplici regole:
- Utilizzare le shadow password ove è possibile, quindi basarsi su algoritmi di criptazione difficilmente decriptabili (MD5 + DES). Uno dei vantaggi di avere le password criptate su un file come /etc/shadow
anzichè il solito /etc/passwd
è che a differenza del secondo, leggibile da ogni utente Unix, il primo è accessibile soltanto da root.
- Utilizzare password complesse non riconducibili all'utente (nomi, date, preferenze etc..) o a semplici parole contenute in un dizionario, ma parole complesse almeno di 6 caratteri alcuni dei quali dovranno essere numeri e caratteri speciali come ().?!#
Cercare di trovare un proprio "algoritmo" mentale che ci permetta di ricordarci una password apparentemente complessa senza doverla scrivere da qualche parte.
- Verificare tramite utility di password cracking l'esistenza di password nel sistema facilmente deducibili. Queste stesse utility possono essere utilizzate da un intrusore, in possesso del file con le password criptate, per eseguire un brute force attack sulle password, cercando di individuare quelle più semplici cn strumenti automatici.
- Settare una policy di scadenza delle password. Le password potenzialmente eterne non dovrebbero esistere, anche perchè si tende a lasciarle tali. E' sempre meglio impostare una scadenza (anche non brevissima, come 6 mesi o 1 anno) a tutte le password anche se questo può rendere più scomoda la vita degli amministratori e mettere a dura prova la memoria degli utenti. In casi estremi si può pensare di implementare un sistema di one-time password, dove ad ogni accesso viene automaticamente cambiata la password.
- Non lasciare traccia delle password, sia in formato cartaceo (post-it attaccati al video o sotto la tastiera) o in formato elettronico (Fogli excel oppure semplici file di testo). Se le password sono complesse si può comunque pensare di averle scritte in un qualche file o documento, che però devono essere particolarmente protetti (sotto chiave, criptati, ecc.)
Ovviamente la possibilità di cracking delle password non si riduce a zero anche seguendo queste poche regole, che oltretutto pur semplici sono spesso ignorate, ma di sicuro rendono difficoltosi tutti quegli attacchi al proprio sistema che mirano al cracking di una password.
A questo proposito si cerchi anche di limitare la possibilità di accesso ad una macchina (via telnet, ssh, remote desktop...) da qualsiasi parte su Internet. La maggior parte delle problematiche di password guessing e escalation dei privilegi da utente normale a root si hanno su sistemi in cui l'utente ha la possibilità di usare una shell (unix) o il sistema stesso (Windows).
In altri casi (accesso ftp o http ad aree riservate) la compromissione delle password difficilmente porta alla compromissione del sistema, anche se può dare diritti importanti all'intruso (possibilità di modificare le pagine di un sito o di accedere ad informazioni riservate).
LINK: Articolo da linuxsecurity.com - http://www.linuxsecurity.org/tips/tip-6.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-04-17 23:04:51
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.
LINK: Crack Home Page - http://www.crypticide.org/users/alecm/
LINK: John The Ripper Password Cracker - http://www.openwall.com/john/
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-05-05 16:40:53
DES è un algoritmo per la criptazione dati sviluppato da IBM (adottato in seguito dal governo degli Stati Uniti nel gennaio 1977) basato su un altro cipher sviluppato e patentato sempre da IBM denominato lucifer (128bit-key contro i "soli" 64 bit di DES, dei quali solo 56 realmente utilizzabili rimanenti 8 vengono utilizzati per le operazioni di calcolo degli errori).
Attualmente, modificato in alcune sue parti, grazie all'intervento della NSA (National Security Agency) viene utilizzato anche per criptare le password degli utenti di sistema nel mondo Unix.
Fino a pochi anni fà era ritenuto un metodo poco sicuro, ma grazie a queste modifiche non si hanno ancora prove di violazione nella struttura di DES oltre quella effettuata nel luglio del 1998 da parte dell'EFF (Electronic Frontier Foundation) tramite un super computer dotato di schede particolari che hanno permesso di violare il sistema DES 64bit in soli 3 giorni generando tutte le chiavi possibili (2 ^56)
La criptazione tramite il cipher DES (56 bit-key) avviene attraverso 19 step differenti per trasformare i dati in chiaro in dati criptati. Nel primo step i dati in chiaro vengono suddivisi in blocchi di 64bit e per ogni blocco viene eseguita una trasposizione di una chiave, nell'ultimo avviene esattamente l'opposto e nel penultimo avviene uno scambio dei 32 bit di estrema sinistra con quelli di destra. Questi passaggi vengono ripetuti per i rimanenti 16 step.
Il seguente metodo di criptazione è stato sviluppato per permettere la decriptazione tramite la stessa chiave utilizzata per criptare, durante le decriptazione vengono eseguiti gli stessi step ma in senso contrario.
LINK: Articolo relativo al cracking di DES - http://www.nwfusion.com/news/1999/0120cracked.html
LINK: Descrizione dell'algoritmo DES - http://www.provincia.venezia.it/mfosc/studenti/crittografia/critto/des.htm
LINK: EFF Home Page - http://www.eff.org/
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-02-28 16:50:15
MD5 (message digest 5) è un algoritmo hash 128 bit (Indipendentemente dall'input e dalla sua lunghezza restituisce un output lungo 128bit) sviluppato da Ron Rivest nei primi anni '90, non essendo considerata una tecnologia utilizzata per la criptazione non è soggetta a nessun tipo di restrinzioni in stati come gli USA ove vi sono leggi che limitano e controllano l'uso di sistemi di criptazione dati.
Attualmente è implementato in numerosi linguaggi di programmazione come C, Java e PHP.
Tutti quei programmi che hanno incorporato questo algoritmo per lo più vengono utilizzati per monitorare i file di un sistema per individuare possibili corruzioni o modifiche del file stesso. Esempi di questi programmi sono Tripwire (http://www.tripwire.org/) e SGI_FAM (http://oss.sgi.com/projects/fam/).
L'uso di MD5 nei sistemi linux e Unix per l'autenticazione utente aggiunge due enormi vantaggi in ambito sicurezza delle password:
- Lunghezza infinita della password (Altrimenti limitata a 8 caratteri)
- Spazio maggiore per la chiave (Altrimenti limitata a 13 caratteri)
Esempio:
Password in formato DES: pluto:/ftypF.PVqn5
Password in formato MD5: pluto:$aprl$CaVFD/..$GIrdfKK7x04Nw1iEsYYpl
LINK: RFC Algoritmo md5 - http://www.ietf.org/rfc/rfc1321.txt?number=1321
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-02-28 16:44:15
Calcola il message digest del file specificato secondo l'argoritmo MD5.
Dal momento che anche piccole variazioni in un file danno un message digest completamente diverso, questo comando è tipicamente usato per verificare se un file salvato sul proprio filesystem è stato modificato o per confrontare se un file scaricato da Internet (tipicamente un tar.gz di sorgenti) ha un digest che coincide con quello "ufficiale" comunicato dai responsabili e che quindi è integro e uguale all'originale.
Calcolo del MD5
md5sum [opzioni] [file]
Opzioni comuni
--binary,-b
Abilita la lettura del file in binario.
--text,-t
Abilita la lettura del file in text mode
Esempio di un check MD5 di un file scaricato da Internet. L'output ottenuto (la stringa di lettere e numeri senza apparente senso) va verificato con quello (eventualmente) indicato su sito da cui è stato fatto il download
[al@giraffa DOWNLOADS]$ md5sum task-1.60.tar.gz
e8542e0cd96ea9d6d32913ac9652cd15 task-1.60.tar.gz
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-02-28 16:51:54
E' un metodo utilizzato per l'autenticazione utente di alcuni sistemi che permette di utilizzare password sempre diverse per effettuare il login. La password una volta utilizzata per effettuare il login scade e non potrà più essere utilizzata, questo esclude la possibilità di utilizzo di password intercettate tramite sniffer o altri metodi.
Esistono molteplici modi di implementazione:
SecureID:
L'autenticazione avviene tramite lo scambio di un codice di un username tra il sistema e l'utente. Tale codice ha una validità relativamente breve, pochi secondi e viene trasmesso da un sistema centralizzato su una scheda SecureID in possesso all'utente.
Lo svantaggio risiede nei elevati costi di implementazione.
S/key:
Una delle soluzioni più utilizzate, viene implementato lato server un metodo di generazione automatica di password tramite formule matematiche. Tramite una chiave confronta la password memorizzata con quella fornita dall'utente (ovviamente sempre diversa), se il matching risulta positivo sostituisce la password memorizzata con quella fornita dall'utente.
OPIE:
Di fatto è una libreria (implementa MD5) che comprende anche un FTP server e l'utility su modificata per supportare le OTP.
LINK: RFC OTP - http://www.ietf.org/html.charters/otp-charter.html
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-04-04 18:59:57
John The Ripper è buon strumento per testare la robustezza delle password di un sistema. Il suo utilizzo non è complesso e può aiutare ad individuare, fra le proprie password, quelle troppo semplici.
Download del package John the ripper
[root@GIOVE root]# wget http://www.openwall.com/john/john-1.6.tar.gz
[...]
Scompattazione dei sorgenti e compilazione
[root@GIOVE root]# tar zxvf john-1.6.tar.gz
[...]
[root@GIOVE root]# cd john-1.6/src/
[root@GIOVE src]# make
Visualizza l'elenco di piattaforme per il quale è possibile compilarlo. Scegliere quella su cui si sta lavorando.
[root@GIOVE src]# make linux-x86-any-elf
[...]
Nella sottodirectory run
si trova sia il file di configurazione (john.ini
) che il file contenente le parole che verranno utilizzate per il cracking delle password (password.lst
) oltre al binario john
. Il file password.lst
d'esempio può essere sostituito con ben più corposi file con elenchi di parole comuni presi da dizionari, in varie lingue. Considerare che John The Ripper non verifica semplicemente se una password coincide con una parola in password.lst, ma effettua una moltitudine di variazioni sul tema (cambio di lettere con numeri, cambio del case ecc) secondo quanto specificato in john.ini.
A questo punto si è pronti per un test delle password, dal momento che John The Ripper lavora su file con formato uguale a /etc/passwd, è necessario, su sistemi che supportano le shadow, lanciare preventivamente il comando unshadow per creare un unico file che incorpora il secret di /etc/shadow in un unico file simile a passwd:
[root@GIOVE run]./unshadow /etc/passwd /etc/shadow > passwd.test
Verifica le password tramite john (l'operazione può durare parecchio tempo)
[root@GIOVE run]# ./john passwd.test
Loaded 1 password (FreeBSD MD5 [32/32])
root (root)
guesses: 1 time: 0:00:00:00 100% (1) c/s: 1.00 trying: root
In questo caso John the Ripper è riuscito a trovare la password di root che era semplicemente "root".
Da notare che se si rilancia di nuovo il comando ./john passwd.test non si avrà più l'output precedente poichè il cracking della password di root è già stato effettuato:
[root@GIOVE run]# ./john passwd.test
Loaded 0 passwords, exiting...
Nel caso si vogliano rivedere le password già crackate occore lanciare il seguente comando:
[root@GIOVE run]# ./john -show passwd.test
root:root:0:0:root:/root:/bin/bash
1 password cracked, 0 left
Nella directory doc si troveranno tutte le info indispensabili per far funzionare l'utility oppure è possibile richiamare un semplice help lanciando John senza opzioni:
[root@GIOVE run]# ./john
[...]
LINK: John the Ripper password cracker - http://www.openwall.com/john/
LINK: Password Files per brute force attacks da ElcomSoft - http://www.elcomsoft.com/order.html#wcd
LINK: Distributed John (DJohn) - http://www.l0t3k.net/tools/Password/djohn-0.9.8.tgz
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2003-04-24 22:40:11
Crack, giunto attualmente alla versione 5.0a, è un software di password cracking sviluppato originariamente per UNIX da Alec D.E. Muffet, utilizzabile dopo opportune configurazioni anche in ambiente Linux
Analogamente a John The Ripper, Crack permette di indiviudare le password più facilmente violabili su un sistema. Questo software può utilizzare sia le librerie dell'algoritmo di crittografia DES sia quelle dell'MD5.
RECUPERO SORGENTI, CONFIGURAZIONE ED INSTALLAZIONE
E' possibile scaricare Crack liberamente dal server FTP indicato sul sito dell'autore:
[root@Enigma homer]# wget ftp.cerias.purdue.edu/pub/tools/unix/pwdutils/crack/crack5.0.tar.gz
--19:43:46-- http://ftp.cerias.purdue.edu/pub/tools/unix/pwdutils/crack/crack5.0.tar.gz
=> `crack5.0.tar.gz'
Resolving ftp.cerias.purdue.edu... fatto.
Connecting to ftp.cerias.purdue.edu[128.10.252.10]:80... connected.
HTTP richiesta inviata, aspetto la risposta... 200 OK
Lunghezza: 2,964,507 [application/x-tar]
100%[================================================================================>]2,964,507 4.39K/s ETA 00:00
19:54:47 (4.39 KB/s) - `crack5.0.tar.gz' salvato [2964507/2964507]
Successivamente dovranno essere scompattati i sorgenti:
[homer@Enigma homer]# tar xzvf crack5.0.tar.gz
Viene creata la directory c50A e le relative sottodirectory
c50a/
c50a/conf/
c50a/conf/dictrun.conf
c50a/conf/rules.weird
c50a/conf/rules.suffix
...
c50a/extra/Crack7
c50a/extra/b64encode
...
c50a/manual.html
c50a/manual.txt
[root@Enigma homer]#
E' ora necessario spostarsi all'interno della directory appena creata:
[homer@Enigma homer]# cd c50a
[root@Enigma c50a]# ls
conf Crack dict doc extra LICENCE Makefile manual.html manual.txt Reporter scripts src
I file e le directory creati dopo la scompattazione, tra i quali un manuale sia in formato testo che in html
Se il proprio sistema utilizza MD5 come in questo caso (Red Hat 7.3) è necessario eseguire alcune operazioni sui sorgenti come spiegato in manual.html:
[root@Enigma c50a]# mv src/libdes src/libdes,orig
[root@Enigma c50a]# cd src/util
[root@Enigma util]# cp -f elcid.c,bsd elcid.c
[root@Enigma util]# cd ../..
E' necessario inoltre modificare alcune linee in Crack in quanto si utilizza gcc e non cc sotto UNIX. Le direttive di compilazione devono apparire come segue:
# vanilla unix cc
#CC=cc
#CFLAGS="-g -O $C5FLAGS"
#LIBS=-lcrypt # uncomment only if necessary to use stdlib crypt(), eg: NetBSD MD5
# gcc 2.7.2
CC=gcc
CFLAGS="-g -O2 -Wall $C5FLAGS"
LIBS=-lcrypt # uncomment only if necessary to use stdlib crypt(), eg: NetBSD MD5
Una volta configurati i file è possibile lanciare la compilazione dei sorgenti:
[homer@Enigma c50a]# ./Crack -makeonly
Crack 5.0a: The Password Cracker.
..
all made in util
make[1]: Leaving directory `/home/homer/c50a/src/util'
Crack: makeonly done
Si passa quindi alla creazione dei dizionari:
[homer@Enigma c50a]# ./Crack -makedict
Crack 5.0a: The Password Cracker.
(c) Alec Muffett, 1991, 1992, 1993, 1994, 1995, 1996
..
Crack: Created new dictionaries...
Crack: makedict done
E' quindi necessario creare il file da dare in pasto a Crack. Se si utilizzano le shadow password è necessario fare un merge del file con i nomi degli utenti /etc/passwd
con quello contenente le password in forma crittografata /etc/shadow
.
[root@Enigma c50a]# cp /etc/passwd passwd.txt
Copia del file con il nome degli utenti nella directory locale
[root@Enigma c50a]# ./scripts/shadmrg.sv > passwd.txt
Tramite un'utilty a corredo di Crack, shadmrg.sv, è possibile generare un file "violabile"
UTILIZZO
A questo punto è possibile eseguire Crack. La sua sintassi è Crack [opzioni] [-fmt formato] [file...]
[root@Enigma c50a]# ./Crack passwd.txt
Crack 5.0a: The Password Cracker.
(c) Alec Muffett, 1991, 1992, 1993, 1994, 1995, 1996
..
Crack: launching: cracker -kill run/KEnigma.2354
Done
[root@Enigma c50a]#
Una volta lanciata l'esecuzione di Crack, si ritorna al prompt di sistema perchè il software lavora in background. E' possibile tenere sotto controllo il lavoro del programma visualizzando un file utilzzato dallo stesso nella sottodirectory run di nome Knomehost.N, in questo caso KEnigma.2354. Utilizzando TOP è possibile notare che il programma assorbe valori intorno al 98% di CPU
VISUALIZZARE I RISULTATI
L'utility Reporter ci permette di visualizzare le password deboli scovate:
[root@Enigma c50a]# ./Reporter
---- passwords cracked as of sab apr 12 22:17:15 CEST 2003 ----
Guessed root [alabama] root [passwd.txt /bin/bash]
Una password decismente semplice come alabama sul sistema di prova (Pentium III 600 Mhz 126Mb Ram) è stata trovata in pochi minuti
FERMARE LA SESSIONE
Per fermare il il programma in modo pulito è possibile usare uno script sempre a corredo del software:
[root@Enigma c50a]# ./scripts/plaster
RECUPERARE LA SESSIONE IN CASO DI CRASH
In caso il processo dovesse interrompersi per un crash di sistema è possibile riprenderne l'esecuzione creando il file temporaneo da cui ripartire tramite con mv /run/Dnomehost.N /run/nome-file-temporaneo
e poi utilizzare Crack -recover -fmt spf run/nome-file-temporaneo
[root@Enigma run]# mv DEnigma.21087 sessione-interrotta
[root@Enigma c50a]# ./Crack -recover -fmt spf run/sessione-interrotta
Crack 5.0a: The Password Cracker.
(c) Alec Muffett, 1991, 1992, 1993, 1994, 1995, 1996
System: Linux Enigma 2.4.18-3 #1 Thu Apr 18 07:37:53 EDT 2002 i686 unknown
Home: /home/homer/c50a
Invoked: ./Crack -recover -fmt spf run/sessione-interrotta
Option: -recover enabled
Stamp: linux-2-unknown
...
[root@Enigma c50a]#
CRACKING DISTRIBUITO
Il processo di cracking può essere distribuito su più macchine utilizzando il file di configurazione conf/network.conf
. Per utilizzare questa modalità è necessario che Perl sia installato sulla macchina master. Una volta settato il file di configurazione è possibile lanciare l'esecuzione con:
[root@Enigma c50a]# ./Crack -network [opzioni] nomefile
Per la completa lista delle opzioni sia di crack che delle utility è possibile consultare il file manual.html.
LINK: Home Page di Crack - http://www.users.dircon.co.uk/~crypto/index.html
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-02-28 16:32:34
Comando per verificarte l'integrità di un file di password.
Di fatto viene utilizzzato per verificare che tutte le entry nel file /etc/passwd e /etc/shadow siano inserite nel modo corretto e che non ci siano dati non validi (per esempio shell inesistenti).
[root@dido root]# pwck
user adm: directory /var/adm does not exist
user news: directory /var/spool/news does not exist
user uucp: directory /var/spool/uucp does not exist
user gopher: directory /var/gopher does not exist
user ftp: directory /var/ftp does not exist
user sshd: program /etc/nologin does not exist
pwck: no changes
Il superdemone Inetd (e Xinetd) |
Configurazione di inetd e tcp wrappers. Configurazione di xinetd. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-17 12:33:51
Inetd è un demone (servizio) che ascolta sulle porte specificate nel suo file di configurazione e fa avviare il relativo servizio nel momento in cui viene fatta una richiesta.
Viene chiamato superdemone proprio per questa sua funzione di controllo di altri demoni.
Il vantaggio di usarlo è di ottimizzare le risorse del sistema, avviando il programma che gestisce un determinato servizio solo quando ci sono effettive richieste.
Sebbene possa essere usato per gestire quasi tutti i servizi è consigliabile farlo solo per quelli a basso e occasionale traffico.
/etc/inetd.conf
E' solitamente il suo file di configurazione
/etc/services
E' un file che assegna un nome di servizio alla relativa porta. Viene usato anche da altri programmi.
Spesso inetd si trova abbinato ai tcp wrappers che permettono di introdurre delle access list che regolano quali IP possono accedere a determinati servizi.
Spesso un'installazione standard di Unix lascia il file inetd.conf
con molte porte inutilmente aperte: è consigliabile commentare le relative righe per evitare che inet ascolti su porte non utilizzate e potenzialmente soggette ad intrusioni.
Ogni volta che viene cambiato il suo file di configurazione, va riavviato il servizio.
Inetd è comune su tutti gli Unix, ma su Linux più recenti si utilizza Xinetd, che è una versione più evoluta che introduce nuove funzionalità.
LINK: The inetd super server - http://www.tldp.org/LDP/nag/node125.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-17 12:58:23
I tcp wrapper (tcpd), sviluppati dall'olandese Wietse Venema, sono un layer software che permette il controllo e il filtro degli accessi a servizi del sistema, tipicamente gestiti con inetd.
In pratica da una logica:
1- client (che esegue una connessione)
2- inetd (che risponde alla connessione e lancia il relativo server)
3- server (che processa la connessione al suo servizio)
si passa ad una configurazione:
1- client 2- inetd 3- tcpd 4- server
in cui i tcpwrappers possono limitare l'accesso al servizio secondo criteri configurabili ed hanno funzionalità anti-spoofing e anti tcp sequence guessing.
La configurazione dei tcp wrappers si fa essenzialmente in due file:
/etc/hosts.allow
Permette di specificare quali servizi permettere e da quali indirizzi IP
/etc/hosts.deny
Permette di specificare come limitare l'accesso a specifici servizi
In alcuni sistemi con Xinetd (es: RedHat) la configurazione dei wrappers viene direttamente inglobata nella configurazione dei singoli servizi.
Tipo Infobox: PATH - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-23 16:13:13
E' il file di configurazione del superdemone Inetd.
Qui si configurano quali servizi e relative porte vengono resi disponibili sul sistema.
Ogni riga di /etc/inetd.conf corrisponde ad un servizio che viene gestito da inetd.
Se è commentata con un # il servizio non viene avviato e inetd non mette la relativa porta in listening.
Il formato di ogni riga è:
service type protocol wait user server argument
Un esempio di una riga tipica è:
ftp stream tcp nowait root /usr/sbin/in.ftpd -l
Se si vogliono utilizzare i tcpwrapper per limitare l'accesso al servizio la riga sopra diventa:
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l
Vediamo nei dettagli le varie voci:
service E' il nome del servizio a cui si riferisce la riga di inetd.conf. La porta a cui è associato viene ottenuta dal file /etc/services
. Di default inetd.conf prevede vari servizi. Alcuni sono attivati, altri commentati. Tipicamente gli unici che si dovrebbero lasciare attivati (se serve) sono ftp e telnet o ssh (se si decide di non far partire il server ssh autnonomamente).
type Specifica il tipo di socket usata per il protocollo indicato. Può essere: stream, dgram, sunrpc_tcp, sunrpc_udp.
protocol Indica il tipo di protocollo: tcp o udp. Si basa sul file /etc/protocols
wait Indica se aspettare o no che il server invocato rilasci la socket prima di rimettersi in listening sulla relativa porta
user L'utente con cui viene lanciato il server. Inetd di suo viene eseguito come root.
server Il path completo del programma da eseguire per gestire la connessione per il servizio specificato
argument Gli argomenti da passare al comando di server lanciato.
LINK: Configuring inetd.conf securely - http://www.uwsg.iu.edu/security/inetd.html
LINK: inetd.conf file format dor TCP/IP - http://www.unet.univie.ac.at/aix/files/aixfiles/inetd.conf.htm
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-17 13:19:31
Di default inetd permette fino a 40 connessioni al minuto su una specifica porta (è una misura anti attacchi DOS).
Questo può essere un limite per server particolarmente affollati.
Tipicamente un server pop3 con parecchie connessioni può superare questo limite e venire temporaneamente disattivato, lasciando un esplicativo messaggio di errore nei log.
Per impostare, per esempio a 100, il numero massimo di connessioni al minuto inserire una simile riga in inetd.conf:
pop-3 stream tcp nowait.100 root /usr/sbin/tcpd ipop3d
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-17 13:09:46
Nelle versioni di Linux più recenti Inetd viene sostituito da un superdemone più versatile e sicuro: Xinetd.
A differenza del precedessore, xinetd:
- Limita o regola l'accesso a determinati servizi sia con un sistema proprio sia inglobando nella sua configurazione i TcpWrappers
- Offre un sistema di logging indipendente da syslog
- Permette di limitare l'accesso ai servizi in determinate ore della giornata
- Supporta il protocollo Ipv6
- Utilizza vari meccanismi che mitigano l'impatto di un attacco DOS.
La configurazione del demone e dei servizi può essere suddivisa in più file (non compatibili con /etc/inetd.conf).
Su RedHat si deve operare su:
/etc/xinetd.conf
File principale di configurazione del demone
/etc/xinetd.d/*
Directory che contiene i singoli file dei servizi offerti da xinetd
SOURCE: Xinetd Home Page - http://www.xinetd.org/
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-18 13:48:33
E' il file di configurazione del superdemon Xinetd. Ha una sintassi leggermente più complicata e flessibile del suo analogo /etc/inet.conf e può prevedere degli "include" che ne facilitano la gestione.
In particolari su distribuzioni Linux come RedHat si usa inserire per ogni servizio un omonimo file di configurazione nella directory /etc/xinetd.d/
Vediamo un esempio di xinetd.conf leggermente modificato (in versione security paranoia) rispetto a quello standard.
[root@95 al]# cat /etc/xinetd.conf
Si definiscono fra parentesi graffe le proprietà comuni a tutti i servizi (defaults)
defaults
{
Numero di istanze del server evocato. Di default sono infinite
instances = 60
Specifica di usare SYSLOG con facility authpriv per il logging. Può anche essere FILE /path/nomelog
log_type = SYSLOG authpriv
Cosa viene loggato di ogni connessione. Può essere uno o più delle seguenti voci: HOST remoto, PID del server, DURATION della sessione, EXIT status del server, USERID dell'utente remoto (tramite identd - sconsigliato)
log_on_success = HOST PID
Cosa viene loggato di ogni connessione non riuscita (per access list o problemi nel lancio del server): HOST remoto, ATTEMPT registrato, USERID dell'utente remoto (identd), RECORD di ogni dato utile
log_on_failure = HOST RECORD
Limita il numero massimo di connessioni contemporanee per server: il primo numero è il numero di connessioni al secondo, superato il quale il servizio viene temporaneamente disabilitato per il numero di secondo indicato con la seconda cifra. Su server molto
cps = 25 30
Il numero massimo di connessioni da un singolo IP ad un determinato servizio
per_source = 5
}
Specifica la directory che contiente ulteriori file di configurazione (in genere 1 per ogni servizio)
includedir /etc/xinetd.d
Prendiamo un file di esempio di configurazione di un singolo servizio:
cat /etc/xinetd.d/wu-ftp
Definisce il servizio, associa la relativa prota tramite il file /etc/services
service ftp
{
Indica se disattivarlo o farlo funzionare, in questo caso il servizio è attivo
disable = no
Come viene gestito il flusso di dati sulla socket: stream Servizio basato su stream di dati, dgram Servizio basati su datagrammi, raw Servizio che richiede accesso diretto all'IP, seqpacket Sercizio che richiede una trasmissione di datagrammi affidabile
socket_type = stream
Indica se il server lanciato è single-threaded (wait=yes: Xinetd non accetta più connessioni fino a quando il server lanciato muore) o multi-threaded (wait=no: Xinetd continua ad accettare connessioni per il servizio ed invocare nuove istanze del server)
wait = no
L'utente con cui viene lanciato il server
user = root
Il path completo del comando per lanciare il server
server = /usr/sbin/in.ftpd
Gli argomenti eventualmente passati al comando lanciato
server_args = -l -a
Il += indica di aggiungere le impostazioni qui indicate a quelle impostate di default
log_on_success += DURATION
Il livello di priorità del server lanciato
nice = 10
Limita l'accesso al servizio solo dagli IP o reti indicati (Alcune notazioni valide: 10.0.0.0/24, 10.0.0.1, 0.0.0.0 (tutti gli IP)
only_from = 192.168.0.0/24
Esclude l'accesso dagli IP o reti indicati. Insieme a only_from gestire le access list di xinetd
no_access = 192.168.4.0/24
Definisce il range di ore del giorno in cui servizio è attivo. Formato hh.mm-hh.mm (hh da 0 a 23, mm da 0 a 59)
access_times = 0:0-6:30
}
Tipo Infobox: BOFH - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-18 12:59:23
Visualizza rapidamente quali servizi sono attivati e quali disattivati nella configurazione di xinetd.
Le righe dove si trova un disable = no
indicano che il rispettivo servizio è attivato.
grep disable /etc/xinetd.d/*
/etc/xinetd.d/chargen: disable = yes
/etc/xinetd.d/chargen-udp: disable = yes
/etc/xinetd.d/daytime: disable = yes
/etc/xinetd.d/daytime-udp: disable = yes
/etc/xinetd.d/echo: disable = yes
/etc/xinetd.d/echo-udp: disable = yes
/etc/xinetd.d/finger: disable = yes
/etc/xinetd.d/ntalk: disable = yes
/etc/xinetd.d/rexec: disable = yes
/etc/xinetd.d/rlogin: disable = yes
/etc/xinetd.d/rsh: disable = yes
/etc/xinetd.d/rsync: disable = no
/etc/xinetd.d/servers: disable = yes
/etc/xinetd.d/services: disable = yes
/etc/xinetd.d/talk: disable = yes
/etc/xinetd.d/telnet: disable = yes
/etc/xinetd.d/time: disable = yes
/etc/xinetd.d/time-udp: disable = yes
/etc/xinetd.d/wu-ftpd: disable = no
Overview sulla sicurezza dei servizi |
Indicazioni operative e rasegna delle problematiche di sicurezza dei principali applicativi laso server. |
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2006-11-09 10:58:07
Analizziamo le direttive che possono essere usate nella configurazione di Apache per regolare i cordoni della sicurezza e rendere più tranquilla l'esistenza di un sysadmin.
Come sempre, più si stringe una configurazione per aumentare la sicurezza di un sistema, più si limitano le sue funzionalità e flessibilità, per cui ogni indicazione va correlata alle proprie esigenze.
Cataloghiamo le note riportate secondo vari criteri, alcuni casi ne possono prevedere più di una contemporaneamente, in certe situazioni, le indicazioni che vengono qui date DEVONO essere disattese per garantire il servizio previsto:
DEFAULT
Indica settaggi presenti nella configurazione di default di Apache, distribuita con i sorgenti.
WEBMASTER
Indica configurazioni che si prestano ad aumentare la sicurezza su server su cui diversi utenti non trusted possono uploadare pagine (clienti di un ISP, freepages di utenti privati ecc.)
NAVIGATORI
Si riferisce a configurazioni che impediscono a normali navigatori il potenziale uso improprio dei servizi del web
RISERVATEZZA
Si riferisce a settaggi che aumentano la riservatezza dei dati presenti sul server Web
DENIAL OF SERVICE
Indica procedure che possono aiutare a difendersi da Denial Of Service Attacks.
Impedire il controllo degli accessi per directory - WEBMASTER
- DEFAULT
Tramite l'uso dei file .htaccess
è possibile definire direttive di configurazione specifiche in ogni singola directory, direttamente da parte di chi ci uploada file.
Su un server su cui possono uploadare documenti anche webmaster non noti, è opportuno limitare il più possibile questa funzionalità con una radicale disabilitazione dell'uso degli .htaccess su ogni directory:
<Directory />
AllowOverride None
</Directory>
E' poi possibile "aprire" per directory e funzionalità selezionate, la possibilità di fare l'override della conf generale tramite i file .htaccess locali.
Le diverse opzioni di AllowOverride
controllano quali direttive possono essere definite nei file .htaccess: All, AuthConfig, FileInfo, Indexes, Limit, Options, None
.
Impedire la lettura via Web a file .htaccess - NAVIGATORI
- DEFAULT
- RISERVATEZZA
Nella configurazione di Apache di default è presente un provvidenziale:
<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</Files>
che impedisce la lettura via Web di file che iniziano con .ht
e di conseguenza evita che un utente via Web possa leggere le informazioni delicate che possono essere presenti nei file .htaccess.
Ovviamente se si decide di cambiare il nome del file che controlla gli accessi sulle singole directory (direttiva di default: AccessFileName .htaccess
) si dovrà adattare anche questa configurazione.
Impedire la lettura via Web a file di configurazione - NAVIGATORI
- RISERVATEZZA
Analogamente al caso precedente può essere utile impedire l'accesso diretto a file che possono contenere parametri di configurazione (che finiscono con inc o conf):
<FilesMatch \.(inc|conf)>
Order Allow,Deny
Deny from all
</FilesMatch>
Disattivare l'uso di .cgi e .shtml al di fuori di directory predefinite - WEBMASTER
- DEFAULT
Tramite la direttiva AddHandler si può dire al server web di trattare file con determinate estensioni con un apposito handler (per esempio un modulo per gestire pagine dinamiche). Di default sulla conf di Apache sono disattivati gli handler per script .cgi e .shtml:
#AddHandler cgi-script .cgi
#AddType text/html .shtml
#AddHandler server-parsed .shtml
per cui se si vogliono usare dei Server Side Includes o degli script CGI al di fuori della directory predefinita con la direttiva ScriptAlias /cgi-bin/ "@@ServerRoot@@/cgi-bin/"
, queste righe vanno scommentate.
Disabilitare l'accesso pubblico a server-info e server-status - NAVIGATORI
- DEFAULT
- RISERVATEZZA
Apache prevede due location speciali che possono essere utilizzate per visualizzare informazioni utili al sysadmin sullo stato del server web e la sua configurazione. Di default questo sono disabilitate, ma possono essere abilitate limitando gli IP da cui possono essere visualizzate. In genere è consigliabile non renderle visibili pubblicamente (in particolare server-info, che di fatto espone la configurazione completa di Apache).
#<Location /server-status>
# SetHandler server-status
# Order deny,allow
# Deny from all
# Allow from .your-domain.com
#</Location>
#<Location /server-info>
# SetHandler server-info
# Order deny,allow
# Deny from all
# Allow from .your-domain.com
#</Location>
Se si vogliono visualizzare server-status e server-info, scommentare queste righe e specificare i domini o gli IP da cui è permesso visualizzarli.
Disabilitare il file listing in directory senza index.html (o analoghi nomi di file predefiniti) - NAVIGATORI
- RISERVATEZZA
Con la direttiva DirectoryIndex
si definiscono quali file Apache automaticamente cerca, e visualizza, quando il client richiede un URI che contiene solo il nome di una directory, senza specificare il nome della pagina web. Se il client accede ad una directory che non contiene uno di questi index predefiniti, Apache visualizza direttamente tutti i file contenuti nella directory stessa, esponendo infomazioni potenzialmente riservate.
Se si vuole disabilitare il listing di tutti i file presenti in una directory, quando non è presente il file di indice, si usa la direttiva Options -Indexes
. Es:
<Location />
Options -Indexes
</Location />
Per disabilitare il directory listing si può anche direttamente rimuovere il caricamento (o la compilazione) del modulo mod_autoindex, se invece si vuole abilitarlo, ma al contempo escludere dal listing dei file potenzialmente sensibili si può usare una direttiva come:
IndexIgnore .??* *.bak *.swp *# HEADER* README* RCS
Limitare le richieste del client - NAVIGATORI
- DENIAL OF SERVICE
Di default Apache permette al client di eseguire richieste particolarmente esose che possono essere impropriamente utilizzate per un Denial Of Service attack. Esistono alcune direttive che limitano alcune caratteristiche delle richieste che il client può eseguire:
LimitRequestBody 10240
Limita a meno di 10 Kb le dimensioni del body di una richiesta HTTP (PUT o POST). Di default questo valore è 0 (infinito). Si può specificare un valore in byte diverso, avendo cura di non interferire con il normale funzionamento di un sito.
LimitRequestFields 30
Imposta a 30 il numero massimo di header HTTP che il client può inserire nella sua richiesta. Il valore di default è 100, in genere è difficile avere richieste che abbiamo più di 20-30 header.
LimitRequestFieldSize 500
Imposta a 500 byte la dimensione massima di ogni singolo header HTTP in una richiesta. Il valore di default è 8190.
LimitRequestLine 500
Imposta a 500 byte le dimensioni della richiesta HTTP (metodo, URL e protocollo), limitando di fatto le dimensioni dell'URL stesso che un client può chiedere (attenzione a dimensionarlo secondo i nomi e i parametri passati negli URL del proprio sito). Valore di default 8190.
Disabilitare l'uso di symlink - WEBMASTER
Di default Apache se trova in una directory di un suo sito Web un link simbolico all'infuori della directory stessa, prova a seguirlo e fornire il file linkato.
Questo comportamento può essere usato per far vedere via web dati che non dovrebbero essere visibili (immaginare un webmaster che digita il seguente comando nella sua home: ln -s /etc/passwd passwd.html
.
Per impedirlo si deve definire, nella conf generale o in un specifico contenitore:
Options -FollowSymLinks
.
Esiste anche la possibilità di configurare Apache per seguire solo i symlink a file posseduti dall'utente, permettendo il symlinking all'interno del proprio sito web (e appesantendo non poco il server, per la quantità di controlli aggiuntivi che deve fare per ogni file servito):
Options -FollowSymLinks +SymLinksIfOwnerMatch
.
LINK: Securing Apache: Step-by-Step - http://www.securityfocus.com/infocus/1694
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-11-15 13:07:57
I veri grattacapi in termini di protezione di un server web arrivano quando si deve gestire un sito dinamico, in cui, tramite cgi, php, perl, ssi o altri metodi le pagine vengono generate on-the-fly e il server non solo deve leggere i file presenti sulla document root ma attingere a dati su un database ed eseguire operazioni sul sistema.
In simili casi le insidie sono enormemente maggiori, perchè non dipendono semplicemente dalla versione del web server installata o dalla sua configurazione, ma di fatto riguardano ogni singolo script che viene eseguito per gestire e generare le pagine.
Fondamentali, in questo senso, sono i permessi con cui vengono eseguiti script o programmi: questi vengono solitamente ereditati da Apache stesso per cui è importante che il server web giri come utente comune (deve comunque essere lanciato come root, per bindarsi alla porta 80, ma tutti i processi figli che gestiscono le connessioni con i client, sono eseguiti con privilegi comuni).
A volte è necessario eseguire alcuni script come root, in questo caso è necessario abilitare funzionalità di suexec, che vanno sempre ponderate con attenzioni.
A prescindere dai singoli linguaggi utilizzati per generare pagine dinamiche, esistono alcune regole di fondo, legate alla stessa logica di un sistema operativo, che vanno considerate nell'analisi e nella realizzazione del codice:
Verifica dell'input di POST o GET
Qualsiasi dato che l'utente può postare su una pagina web va attentamente valutato e ponderato: le possibilità di abusare della funzionalità di uno script sono enormi, considerando la logica di Unix e la modalità con cui vengono gestiti gli input.
Immaginiamo di avere un form dove viene richiesto un indirizzo Email, questo viene passato tramite un nostro script CGI ad un comando shell come mail $indirizzo_inserito
.
Se qualcuno inserisce come email qualcosa come [email protected] < /etc/passwd
il comando eseguito sul sistema diventa mail [email protected] < /etc/passwd
con le conseguenze che si possono immaginare.
Considerare anche le variazioni sul tema, nel caso nell'input venga inserito un ; seguito da un comando maligno, o un > o delle parentesi tonde () ecc.
In pratica si deve sempre porre la massima attenzione a qualsiasi "punto di entrata" di dati dall'esterno: di fatto a qualsiasi form che passa dati ad uno script CGI, o qualsiasi pagina dinamica che accetta parametri tramite l'URL passato in GET.
Controllo dell'input sul server (non lasciare la sicurezza sul lato client)
Le possibilità di abuso che si aprono nel momento in cui si utilizzano pagine dinamiche sono innumerevoli, le soluzioni varie, ma in genere la logica è sempre la stessa: controllare e filtrare ogni input accettabile e farlo sul server e non lasciarlo al client.
Eveitare per esempio di controllare l'input direttamente nella pagina HTML tramite javascript o analoghi.
In questo modo si lascia al lato client il controllo e la sicurezza dei dati: un utente ostile può sempre salvare la pagina html in locale, modificare il javascript che esegue il controllo dell'input, ed eseguire il POST dalla pagina modificata, senza i filtri previsti: l'unico modo per evitare una simile operazione sarebbe verificare il referrer da cui arrivano i dati postati, se la pagina è quella del nostro sito allora si accetta l'input, altrimenti si blocca, ma anche in questo caso l'header REFERRER può essere manipolato, per cui di fatto, è sempre meglio operare ogni controllo e filtro dell'input direttamente sul server.
Evitare l'output di codice HTML inseribile dall'utente
Si consideri un forum dove chiunque può scrivere messaggi. Se non vengono fatti specifici controlli e filtrati tutti i tag html tranne eventualmente quelli che possono essere ritenuti innocui, un utente ostile può postare del codice HTML con effetti imprevedibili e comunque molto ampi e variegati (Basta richiamare uno script remoto con <img src=http://www.sitoremoto.com/bruttecose.cgi>
per eseguire codice ostile sul browser dell'utente che visita il forum)
Passaggio di dati e parametri sensibili via URL o hidden fields
A volte per gestire pagine dinamiche si devono passare dati e parametri da una pagina all'altra. I metodi per farlo possono essere via POST, tramite i contenuti di un form o via GET, tramite coppie di attributi/valori passati nell'URL.
Se i parametri sono sensibili e potenzialmente riservati o sfruttabili per usi impropri si deve prestare attenzione a come vengono gestiti: usare HIDDEN field in un form, per esempio, dal punto di vista della sicurezza è inutile, visto che il sorgente della pagina HTML è facilmente visualizzabile.
Si può pensare di criptare i dati, se si devono a tutti costi "passare", oppure di trovare soluzioni tali da rendere inutile il passaggio di simili dati, perchè associati alla singola sessione di navigazione (per esempio tramite cookie).
LINK: Fingerprinting Port 80 Attacks - http://www.cgisecurity.com/papers/fingerprint-port80.txt
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2002-10-24 10:07:26
Per l'analisi delle configurazioni principali di php.ini prendiamo in esame il php.ini-dist che presenta un tipo di configurazione meno esasperata e più user friendly nonchè oggettivamente più utile per la programmazione.
Cominciamo con il dire che php.ini gestisce tutte le configurazioni possibili (eccezion fatta per le modalità di installazione e compilazione).
I settaggi che metterò negli esempi sono quelli di default
La logica è davvero molto semplice, in pratica corrisponde a questo esempio:
settaggio = value
Permette l'utilizzo dei tag abbreviati
short_open_tags = On
Permette l'utilizzo di tag ASP
asp_tags = Off
Il numero di cifre significative nei numeri a virgola mobile
precision = 12
Forza la compatibilità con l'anno 2000 (crea problemi con non-compliant browser)
y2k_compliance = Off
Abilitazione del buffering dell'output. Settando "On" questa configurazione permetterete a PHP di inviare la pagina al browser solo al termine dell'esecuzione di tutti gli script e tutte le varie funzioni di echo o print venrranno immagazzinate nel buffer. Questo ha il vantaggio di permettere l'invio di header lines anche dopo l'invio del body. Inoltre nel caso che nella maggioranza delle pagine ci sia commistione di html tradizionale e html generato da php attraverso echo() o print().
Oppure qualora si senta l'esigenza di comprimere l'output per velocizzare lo scaricamento delle pagine (attivando nel php.ini sia il buffering che la compressione). Lo svantaggio principale è di rallentare l'esecuzione del codice PHP nel caso che lo script non sfruttati appieno queste opportunità.
Nel caso che il server fornisca hosting a diversi clienti è preferibile lasciare queste opzioni disabilitate e lasciare la libertà ai programmatori di sfruttare il buffering con le funzioni ob_start etc...
output_buffering = Off
Puoi redirezionare l'output degli scripts verso una funzione. Ad esempio impostando output_handler a ob_gzhandler, l'output verrà trasparentemente compresso per i browser che supportano gzip o browser che scompattano il codice.
output_handler =
Rende trasparente la compressione tramite le librerie gzip. Le impostazioni valide sono 'Off' 'On' o specificando il buffer size da utilizzare per la compressione (default = 4 Kbyte)
Importante: se si imposta questa configurazione ad 'On' output_handler DEVE essere settata 'On'
zlib.output_compressed = Off
Implicit flush è una opzion che deve essere settata Off, al massimo deve essere utilizzata solamente in fase di debugging in quanto ha gravi conseguenze sulle performance
implicit_flush = Off
Impostando "on" si forza a passare per reference gli argomenti quando viene chiamata la funzione. Questo metodo è deprecato (anche se di default è settato On) e viene consigliato di sistemare gli script per funzionare anche se questa configurazione è settata ad "on" in quanto in futuro verrà cancellata.
allow_call_time_pass_reference = On
Safe mode effettua un rigido controllo sugli utenti che "girano" nello spazio web in cui vengono eseguiti script php.
Normalmente tutti gli script ereditano i permessi di Apache (che con certe configurazioni del server possono rivelarsi troppo ampi), invece dal momento in cui viene attivato safe_mode, gli script agiranno strettamente con i permessi dell'utente che li ha uplodati (cioè, in uno spazio in hosting, l'utente ftp), quindi, ad esempio, non potranno andare a leggere un file creato con php nello spazio WEb di un altro utente (revisionato da Fabio Heller)
safe_mode = Off
Di default safe mode quando viene aperto un file fa un UID compare. Se vuoi "rilassare" il tuo script ad un GID compare bisogna impostare la seguente impostazione ad "On"
safe_mode_gid = Off
Quando il safe mode è impostato su "On" il controllo UID/GID è bypassato quando viene incluso un file da quella directory e dalle sue sottodirectory
safe_mode_include_dir =
Se si imposta "On" dice a PHP di dichiararsi presente sul server
expose_php = On
Limiti risorse:
Tempo massimo di esecuzione di uno script PHP
max_execution_time = 30
Massima quantità di memoria che uno script PHP può occupare per la sua esecuzione
memory_limit = 8M
Gestione degli errori (per maggiori dettagli in php.ini vengono spiegati i vari livelli di visualizzazione degli errori)
Questa configurazione mostra tutti gli errori eccetto le notifiche
error_reporting = E_ALL & E_NOTICE
Visualizzazione errori come parte dell'output della pagina. Questa opzione deve essere impostata "On" SOLO per siti in sviluppo, per server in produzione è vivamente consigliato di spegnere questa configurazione e di utilizzare il logging interno di PHP (più avanti spiegato) perchè potrebbe visualizzare informazioni critiche come il path dei file
display_errors = On
Anche quando display_errors = On, gli errori occorsi durante la sequenza di startup di PHP non vengono visualizzati. E' fortemente raccomandato per server in produzione di disattivare questa funzionalità
display_startup_errors = Off
Logging degli errori in un file di log. Il team di php.net avvisa di attivare questa opzione per server in produzione
log_errors = Off
Memorizza l'ultimo errore/warning in $php_errormsg (boolean)
track_errors = Off
Disabilita l'inclusione di tag HTML negli errori
html_errors = Off
Log errors in uno specifico file (valido se log_errors = On)
error_log = filename
IMPORTANTE! la configurazione di questo parametro è molto importante perchè definisce la compatibilità con vecchie versioni di PHP in qui era impostata di default ad "On" mentre ora per motivi di sicurezza è consigliato settare ad "Off" Regiter Globals.
In breve questa funzione permette di non dover richiedere una variabile passata in un URL come GET o come POST ma di averla già disponibile.
Se register_globals = On nel caso di un url del tipo: http://www.dominio.com/pippo.php?ID=56 se nella pagina successiva printo $ID il PHP visualizzerà 56, nel caso di register globals = Off la variabile sarà disponibile solamente in $_GET["ID"] o con le vecchie variabile in $HTTP_GET_VARS["ID"] e non come $ID
register_globals = On
Questa direttiva dice a PHP di dichiarare le variabili argv&argc (quelle contanenti le informazioni GET). Se non si usano queste variabili si può spegnere questa configurazione per ottenere maggiori performance.
register_argv = On
Massima dimensione di un POST di dati che PHP accetti
post_max_size = 8M
Questa direttiva è deprecata e php.net consiglia di utilizzare l'altra variabile di ordinamento dei GET POST COOKIE spiegata precedentemente
gpc_order = "GPC"
Importante: Magic quotes
Magic quotes per variabili in ingresso GET/POST/COOKIE: Vuol dire che a tutte le variabili in incoming come GPC vengono aggiunti gli slashes. Es. ' = \' " = \"
magic_quotes_gpc = On
Magic quotes per dati runtime (Es. dati da SQL, da exec etc...)
magic_quotes_runtime = Off
Utilizza magic quotes stile sybase (escape per ' con '' anzichè \')
magic_quotes_sybase = Off
Directory dove risiedono le estensioni
extension_dir = ./
Configurazione per enablare o meno le dl() function che non funzionano correttamente su multithread server, IIS e Zeus e vengono automaticamente disabilitate in questi server
enable_dl = On
File Uploads
Impostare il permesso di HTTP upload di files
file_uploads = On
Directory dei file temporanei in fase di upload (se commentate questa configurazione verrà utilizzata quella di default del S.O.)
upload_tmp_dir
Massima dimensione di un file accettata da PHP
upload_max_filesize = 2M
File Opening
Configurazione per concedere la possibilità del trattamento con fopen di URL file
allow_url_fopen = On
Dinamic extension
Windows extensions (se commentata non viene caricata) un esempio:
extension = php_cpdf.dll
Module settings
Configurazione per attivazione dei syslog (disabilitare questa opzione permette un incremento delle performance di PHP)
define_syslog_variables = Off
Funzioni email per windows
Impostazione SMTP server
SMTP = localhost
Invio email da:
sendmail_from = [email protected]
Funzioni email per unix
Path di sendmail
;sendmail_path = (commentata di default)
Configurazioni database
SQL
sql.safe_mode
ODBC
Permette o previene connessioni persistenti
odbc.allow_persistent = ON
Controlla che la connessione persistente sia valida prima di utilizzarla
odbc.check_persistent = On
Massimo numero di connessioni persistenti (-1 equivale ad infinite)
odbc.links = -1
MYSQL
Per eventuali configurazioni del tipo mysql.allow_persistent = On valgono le spiegazioni date per ODBC e così per i database supportati. (tratterò esclusivamente i casi specifici di ogni DB).
Porta di default di mySQL. Se lasciata blank viene utilizzata la porta di default 3306
mysql.default_port =
Nome socket per connessioni locali a mySQL. Se vuota viene utilizzata quella di default
mysql.default_socket = On
Default host per mysql_connect() (non applicabile in safe mode)
mysql.default_host
Default user per mysql_connect() (non applicabile in safe mode)
mysql.default_user =
Default password per mysql_connect() (non applicabile in safe mode). E' assolutamente sconsigliabile utilizzare una password di default!!
mysql.default_password =
POSTGRESQL
Individua connessioni persistenti broken con pg_connect(). Necessita di un piccolo overhead
pgsql.auto_reset_persistent = Off
SYBASE
Error severity minimo visualizzato
sybase.min_error_severity = 10
Si forza la compatibilità con versioni vecchie di PHP (3.0) in caso di settaggio ad On forza PHP a assegnare tipi di risultati del tipo di quelli di sybase.
Questa compatibilità non rimarrà a lungo
sybase.compatibility_mode = Off
SYBASE-CT
Massimo numero di connessioni (persistenti e non) accettate da sybase (-1 senza limiti)
sybct.max_links = -1
N.b.Non mi dilungherò ulteriormente sui database in quanto indicativamente per tutti i database le configurazioni sono simili, ci sono altri casi eccezionali comunque descritti ampiamente in PHP.INI
SESSIONI
Handler utilizzato per lo store ed il retrieve dei dati
session.save_handler = files
Path dove vengono immagazzinati i files delle sessioni
session.save_handler = /tmp
Se usare i cookies
session.use_cookies = 1
Nome della sessione (usato come cookie name)
session.name = PHPSESSID
Inizializzazione sessioni alla richiesta di startup
session.auto_start = 0
Tempo di vita del cookie (se 0 finchè il browser non viene restartato)
session.cookie_lifetime = 0
Path per il quale il cookie è valido
session.cookie_path = /
Handler utilizzato per la serializzazione dei dati (lo standard è PHP)
session.serialize_handler = php
Percentuale di possibilità che la "Garbage Collection" venga iniziata quando la sessione viene inizializzata
session.gc_probability = 1
Importante: Numero di secondi dopo il quale la sessione viene considerata scaduta (importante in caso di carrelli della spesa)
session.gc_maxlifetime = 1440
Controlla l'HTTP referer per la validazione di stored URL che contengono l'ids
session.referer_check =
Quanti bytes vengono letti dal file
session.entropy_lenght = 0
Specifica dove creare il session ID
session.entropy_file =
Setta il no cache
session.cache_limiter = nocache
Tempo di espirazione del documeto in N minuti
session.cache_expire = 180
E' molto rischioso abilitare il trans sid perchè permette di accedere ad una sessione tramite vecchi bookmarks o url stored e perchè l'utente può inviare l'URL contenente la sessione via mail, irc etc...
sessione.use_trans_sid = 0
E con questa ultima spiegazione ho terminato di trattare le configurazioni principali di php.ini
Esempio di configurazione per un sito in produzione (da prendere con le molle e da customizzare in base alle proprie esigenze) PHP.INI
LINK: Le funzioni di controllo dell'output - http://freephp.html.it/articoli/view_articolo.asp?id=65
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-03-06 15:51:12
La funzione dei server DNS è fondamentale per il funzionamento di Internet e spesso una mancanza di servizio da parte di server DNS si tramuta in un blocco, di fatto, di qualiasi altra attività in rete.
Le problematiche di sicurezza che riguardano il protocollo DNS e il relativo servizio sono di varia natura:
- Riservatezza e sensibilità delle informazioni.
Tramite il DNS si possono fornire varie informazioni su una macchina, oltre al semplice nome. La qualità e la quantità delle informazioni esposte dipende di fatto da come si configurano le proprie zone (i domini per cui si è autoritari) e quante informazioni vengono date sui singoli host.
In linea di massima è consigliabile dare alle macchine nomi di fantasia (es: giove.dominio.com) che non siano strettamente collegate alla loro funzione e associarli con un CNAME al nome di un servizio (es: www.dominio.com o upload.dominio.com).
A prescindere dalla quantità di informazioni configurate per un dominio sul suo server DNS autoritativo, è anche opportuno limitare il zone transfer della zona solo ai server DNS secondari o a IP fidati.
- Vulnerabilità del servizio DNS.
Come per altri protocolli anche i software che vengono usualmente utilizzati per gestire il DNS possono avere buchi ed essere suscettibili di attacchi. In particolare BIND ha una security history relativamente tormentata per cui è importante averne sempre una versione aggiornata per i servizi pubblici.
L'intrusione su un server DNS, oltre alle problematiche tipiche di ogni intrusione, è particolarmente critica, perchè sul server violato è possibile modificare facilmente le configurazione del DNS dando via libera ad una vasta varietà di problematiche per tutti i servizi dei domini per cui il server DNS è autoritario.
- Funzionamento del servizio
Attacchi DOS a server DNS o guasti su linee o sistemi, compresi i ROOT-SERVERS, possono mettere a repentaglio la risoluzione dei nomi su diverse scale.
E' prassi comune, anche perchè semplice da implementare, prevedere almeno un server DNS secondario per ogni server primario. I server secondari devono risiedere su reti diverse e possibilmente in zone geografiche differenti.
Generalmente il DNS non è un servizio che impegna troppo un sistema per cui può essere tranquillamente implementato su macchine che forniscono altri servizi primari.
- DNS poisoning e attacchi sul protocollo
La comunicazione fra client-server e server-server DNS, a meno che non venga usato DNSSEC, non viene validata, autenticata o criptata e può essere soggetta ad una varietà di attacchi con diverse caratteristiche.
Il loro punto in comune è quello di fornire risposte DNS arbitrariamente errate e quindi potenzialmente foriere di ogni tipo di attacco a legittime richieste di client ignari.
Di fatto il modo migliore per proteggersi dalla intrinseca "buona fede" delle risposte del protocollo DNS sarebbe quella di usare DNSSEC, ma la sua diffusione è ancora troppo lenta e parziale per essere veramente utile.
WEB SERVICE: DNS Report - http://www.dnsreport.com/
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-10-03 08:58:46
Le precauzioni di massima per evitare abusi comuni su un server DNS non sono molte e soprattutto non comportano particolari complicazioni per cui vale la pena implementarle appena possibile.
Elenchiamo alcune configurazioni e accorgimenti raccomandabili quando si configura BIND.
NEGARE LO ZONE TRANSFER
Il trasferimento di zona avviene esclusivamente fra due server DNS (può farlo anche un client, ma solo per raccogliere informazioni non necessarie) quando viene aggiornata una zona sul master e trasferita agli slave.
Si può configurare BIND per limitare gli zone transfer solo ai server autorizzati. In /etc/named.conf
ci dovrebbero essere righe come:
options {
directory "/var/named";
allow-transfer {
192.168.0.0 / 24 ; Si permette uno zone transfer a tutta la rete 192.168.0.0/24
172.16.1.6 ; Si permette uno zone transfer all'host 172.16.1.6
};
};
In caso di richieste di zone transfer non autorizzate, sul file di log, generalmente /var/log/messages
si trovano entry del tipo:
Mar 4 11:48:31 ns named[2762]: client 193.0.0.63#46935: zone transfer 'openskills.info/IN' denied
Mar 4 11:48:54 ns named[2762]: client 193.0.0.63#47815: zone transfer 'openskill.info/IN' denied.
Fondamentalmente su un server DNS slave non è necessario permettere lo zone transfer ad alcun IP, su un server DNS master è necessario permetterlo a tutti gli indirizzi dei server slave.
LIMITARE LE POSSIBILITA' DI QUERY
Quando si imposta un server DNS come resolver su un client, ogni richiesta fatta dal client al server viene completamente processata dal server stesso, se il server non ha la risposta nella sua cache o fra le zone di cui è autoritativo, il server DNS richiede per conto del client, le informazioni ai server DNS autoritativi. Questa operazione si definisce Query Ricorsiva e viene generalmente permessa sui server DNS che forniscono il loro servizio come resolver ad un dato range di client.
Se il proprio server DNS funge solo da resolver e non è autoritativo per alcun dominio (quindi non deve ricevere query da altri server DNS) è può configurare Bind per limitare query solo da dati IP:
acl "trusted" {
213.198.151.0/24; 10.0.0.0/8; Definisce una acl, chiamata "trusted"
};
options {
directory "/var/named";
allow-query { "trusted"; }; Permette le query solo agli IP indicati nella acl "trsuted"
};
Se invece il proprio server è autoritativo per alcune zone ma non viene utilizzato come resolver è opportuno disabilitare la possibilità di fare query-ricorsive e si deve lasciare aperta la possibilità di eseguire query da ogni parte di Internet, almeno per i domini di cui è autoritativo:
options {
recursion no; Diabilita la possibilità di fare query ricorsive
};
SEPARARE DNS RESOLVER DA DNS DELEGATED
Se un server DNS ha la delega per un dominio, deve poter rispondere a query DNS di tutti i client su Internet per le zone di cui è autoritario. Se viene utilizzato come resolver da un dato numero di client (i PC di una rete locale, gli utenti di un provider, ecc) deve poter eseguire query ricorsive per conto di tutti i suoi client.
Queste sono due funzionalità separate che in linea di massima sarebbe opportuno implementare su 2 macchine separate:
- Un server delegato, che permette query da tutta Internet, non permette query ricorsive e permette zone transfer solo ai suoi slave.
- Un server resolver, che permette l'accesso solo da un range di IP definito, permette query ricorsive e nega ogni zone transfer.
Molti tipi di attacchi di DNS poisoning, infatti, si basano sulla funzionalità di recursive query, che quindi andrebbe limitata per quanto possibile.
Se, come spesso accade, il proprio server DNS deve essere sia autoritativo per alcuni propri domini che fare da resolver per i propri client, è possibile configurarlo per cercare di espletare entrambe le funzioni limitando i rischi di sicurezza:
acl "trusted" {
213.198.151.0/24; 10.0.0.0/8; Definisce una acl, chiamata "trusted"
};
acl "slave" {
192.253.253.9; 193.205.245.8;
};
options {
directory "/var/named";
allow-query { "trusted"; }; Di default permette query solo dagli IP trasted
};
zone "openskills.info" {
type master;
file "openskills.info";
allow-query { any; }; Per il dominio openskills.info, di cui è autoritario, accetta query da tutti
allow-transfer { "slave"; }; Permette zon transfer per il dominio openskills.info solo agli IP indicati nell'acl "slave"
};
zone "151.198.213.in-addr.arpa" {
type master;
file "213.198.141";
allow-query { any; };
allow-transfer { "slave"; };
};
NASCONDERE LA VERSIONE DI BIND
Tramite il comando dig è possibile scoprire la versione di Bind che gira sul server interrogato:
dig version.bind chaos txt
- Visualizza la versione di Bind sul server DNS correntemente utilizzato:
; <<>> DiG 9.2.1 <<>> version.bind chaos txt
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41822
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;version.bind. CH TXT
;; ANSWER SECTION:
version.bind. 0 CH TXT "9.2.1" Sul server gira Bind 9.2.1
dig @ns.dominio.it version.bind chaos txt
- Visualizza la versione di Bind sul server DNS ns.dominio.it.
Notare che se sul server non gira Bind, l'ANSWER SECTION risulta vuota.
Per nascondere la versione di Bind che si sta utilizzando basta scrivere nel file di configurazione:
options {
version "Ignota";
};
SOURCE: Estratto dal libro: "DNS and BIND". Capitolo 11. Sicurezza. - http://www.oreilly.com/catalog/dns4/chapter/ch11.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-05-23 21:01:25
Quasi tutti sono d'accordo sul fatto che lo SPAM (invio su larga scala di mail non richieste) sia un distrubo, per non dire una piaga, di cui si può volentieri fare a meno e da cui ci si deve difendere.
Tecnicamente è possibile inviare spam utilizzando un qualsiasi server SMTP in rete, che per intrinseca natura permette il RELAY, cioè la possibilità di essere utilizzato per inviare posta, ai suoi client.
I problemi da affrontare, per gli amministratori di un server di posta sono di molteplice natura:
1- Impedire che il proprio server sia utilizzato per inviare spam in rete;
2- Limitare e filtrare il più possibile le mail di spam destinate agli utenti locali;
3- Evitare che il proprio server sia inserito in Black List contenenti indirizzi di server usati per spam di
1- Tipicamente un server di posta viene configurato per permettere il relay sono a client di indirizzi IP o domini specifici o a quelli che si autenticano in qualche modo.
Il problema quindi può venire da qualsiasi utente che è autorizzato ad usare il server e ne abusa consapevolmente, perchè lui è lo spammer, o senza saperlo, perchè vittima di qualcuno o qualcosa che abusa del suo computer.
Questo vale anche e soprattutto per server in rete, anche con tutt'altre funzioni, nel momento in cui vengono violati da un cracker che si mette ad utilizzarli per spammare ferocemente.
A questo proposito buona pratica è:
- Verificare che il proprio server di posta non abbia relay aperti a indirizzi che non siano autorizzati, controllati e considerati fidati (tramite siti web o servizi in rete dedicati, o verifiche da indirizzi arbitrari). Evitare di fare controlli basati su nomi di dominio (manipolabili) e farli solo sulla base degli indirizzi IP sorgenti.
- Limitare sul server il numero massimo di mail che un client può inviare in un dato lasso di tempo. Facendo attenzione a casi in cui l'invio di grandi quantità di messaggi è legittimo (mailing list, newsletter ecc).
- Monitorare le attività di invio di mail, possibilmente con statistiche visuali, che possano velocemente mostrare se ci sono comportamenti anomali ed eccessivi volumi di messaggi.
- Impedire, ovviamente, che qualcuno violi uno dei propri server e lo utilizzi abusivamente per spammare.
2- Le attività volte a limitare l'arrivo di eccessivo spam sulle caselle di posta locali sono altrettanto necessarie.
I metodi di difesa sono vari, il più comodo e diffuso è quello di appoggiarsi ad una o più RBL, black list, mantenute da organizzazioni o società, che contengono elenchi di indirizzi che sono stati utilizzati per l'invio di spam in passato o che si basano su principi diversi (relay aperti, indirizzi IP assegnati a dialup, socks proxy aperti...).
In questo senso considerare che:
- Ci sono diversi metodi per eseguire un controllo su queste liste di indirizzi. Quello più comune è di appoggiarsi ad un server dns che comunica al server di posta se un indirizzo è nella sua black list (DNSBL).
- Non esagerare nell'implementare troppi DNSBL sullo stesso server di posta, soprattutto se questi gestisce grossi volumi: comportano ciascuno una query DNS esterna per ogni messaggio in arrivo.
- Fare attenzione alle Black List che si utilizzano, alcune sono troppo restrittive e limitano la possibilità di ricevere posta da troppi server smtp legittimi: nessuno vuole lo spam, ma molti non sono disposti a perdere mail potenzialmente importanti per difendersene.
- Su server di posta eseguire un controllo sul reverse degli IP da cui arrivano i messaggi. E' una misura che può essere pericolosa (creando falsi negativi e respingendo mail validi da server con DNS misconfigurato) e tuttosommato facilmente bypassabile da chi invece vuole veramente fare spam, per cui va valutata con estrema prudenza.
- Tenere sotto controllo cosa viene regolarmente rifiutato, farsi un'idea dei flussi di posta, sia per capire quanto possano essere efficaci i filtri implementati sia per cercare di verificare se generano falsi negativi.
- Per valutare quali RBL possono fare al proprio caso, verificare le statistiche che si trovano in rete.
Una piuttosto interessante è quella di OpenRBL, che da un'idea di quali RBL sono più aggressive: http://openrbl.org/stats.htm
3- Le stesse black list che si utilizzano per bloccare l'arrivo di posta indesiderata si possono rivelare un'arma a doppio taglio nel momento in cui un PROPRIO server di posta si ritrova su di esse.
Questo può capitare per vari motivi ma di fatto è un problema perchè impedisce al server di offrire un servizio completo ai suoi client, avendo altri server in rete, che utilizzano le black list in cui si è incappati, che rifiutano di accettare la posta, anche legittima, dei propri utenti.
Generalmente tutte le black list permettono di rimuovere un indirizzo, dopo che è dimostrato che non ha più relay aperti e non può essere utilizzato di nuovo per inviare spam. Il problema è che le black list sono molte e che non sempre sono rapide nell'aggiornare i propri database.
Si consiglia di verificare regolarmente gli indirizzi dei propri server di posta su siti che permettono ricerche multiple su diverse liste. Fra questi segnaliamo OpenRBL e DRBcheck
LINK: drbcheck: dr. Jørgen Mash's DNS database list checker - http://www.moensted.dk/spam/
Intrusion detection e analisi dei log |
Overview sugli strumenti di intrusion detection e analisi del sistema |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-03-05 18:02:19
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.
LINK: Completa rassegna di software e soluzioni IDS - http://www.networkintrusion.co.uk/ids.htm
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-01-28 08:02:52
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.
(F)AQ: Come ci si accorge di un intrusione? -
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-01-21 14:10:18
Logwatch è uno degli strumenti di log monitoring più interessanti fra quelli disponibili nel panorama opensource:
- E' modulare, permettendo customizzazione, adattamente ed estensioni;
- Si installa facilmente e su alcune distribuioni è operativo ed efficace senza alcuna necessità di configurazione post-installazione
La sua modalità di funzionamento non è in real-time: quando viene eseguito processa i log e invia una mail di report (di default a root), per cui si presta ad essere crontabbato, con tutte le limitazioni, in termini di sicurezza, del caso: se un intrusore fa in tempo a modificare i log e cancellare le sue tracce, LogWatch non si accorge di nulla. Si accorge però di tentativi di Intrusione, di attività sul sistema (anche legittime, di cui comunque è bene avere traccia) e di eventi anomali.
INSTALLAZIONE
Logwatch è composto fondamentalmente da script Perl e file di configurazione, non richiede ricompilazioni o adattamenti particolari a seconda della piattaforma, se non la configurazione sulla posizione e i nomi dei file di log.
Se si installa tramite RPM, LogWatch è immediatamente operativo e non richiede ulteriori interventi di configurazione. Installa i seguenti file:
[root@socrate /]# rpm -ql logwatch
/etc/cron.daily/00-logwatch E' un link simbolico a /etc/log.d/scripts/logwatch.pl, che di fatto è il programma vero e proprio, che quindi viene eseguito ogni giorno (comando logwatch senza particolari argomenti)
/etc/log.d La directory che contiene tutto "il mondo logwatch"
/etc/log.d/conf Directory che contiene i file di configurazione
/etc/log.d/conf/logfiles Directory che contiene le configurazioni per i singoli tipi di log
/etc/log.d/conf/logfiles/cron.conf [...]
/etc/log.d/conf/logwatch.conf File di configurazione generale, imposta tutti i parametri standard che vengono usati quando il comando logwatch viene lanciato senza argomenti
/etc/log.d/conf/services Directory che contiene le configurazioni per i tipi di servizi
/etc/log.d/conf/services/automount.conf [...]
/etc/log.d/logwatch Link al programma logwatch: /etc/log.d/scripts/logwatch.pl
/etc/log.d/logwatch.conf Link al file di configurazione: /etc/log.d/conf/logwatch.conf
/etc/log.d/scripts Directroy che contiene tutti i script Perl di logwatch e i suoi moduli
/etc/log.d/scripts/logfiles directory che contiene script per la gestione di file di log specifici
/etc/log.d/scripts/logfiles/samba [...]
/etc/log.d/scripts/logwatch.pl Il programma logwatch vero e proprio. Il fatto che esista il link /usr/sbin/logwatch fa in modo che possa essere evocato semplicemente scrivendo "logwatch"
/etc/log.d/scripts/services Directory con i filtri modulari per il parsing di specifici servizi
/etc/log.d/scripts/services/automount [...]
/etc/log.d/scripts/shared Directory che contiene i filtri comuni per tutti i servizi e tipi di log
/etc/log.d/scripts/shared/applystddate [...]
/usr/sbin/logwatch Link al programma logwatch: /etc/log.d/scripts/logwatch.pl
/usr/share/doc/logwatch-2.6 Directory con la Documentazione ufficiale
/usr/share/doc/logwatch-2.6/CHANGES [...]
/usr/share/man/man8/logwatch.8.gz Pagine del man di logwatch
Se si ha a disposizione il tar.gz di logwatch, l'installazione è ugualmente semplice:
- Scompattare il tarball;
- Copiare tutto il contenuto della directory creata in /etc/log.d
(Se si cambia la directory di default, si deve cambiare la variabile $BaseDir all'inizio di logwatch.pl;
- Editare, se si vuole il file di configurazione generale logwatch.conf;
- Crontabbare, secondo la frequenza che si desidera, l'esecuzione di logwatch.pl (senza particolari argomenti).
CONFIGURAZIONE
Il file di configurazione generale /etc/log.d/logwatch.conf
è piuttosto chiaro e prevede alcune opzioni interessanti, che possono essere sovrascritte dalla riga di comando. Seguono le impostazioni di default, che vanno bene in molti casi:
LogDir = /var/log Directory di default dove risiedono i log
MailTo = root A chi vengono inviate le mail di logwatch, può essere un utente locale o un normale indirizzo email
Print = No Se settato a Yes, l'output di logwatch viene visualizzato a schermo invece di essere inviato via mail
# Save = /tmp/logwatch Se impostato, l'output viene salvato sul file indicato invece di essere inviato via mail
# Archives = Yes Specifica se cercare anche nei file di log archiviati (anche gzippati) come /var/log/messages.1 o /var/log/messages.1.gz
Range = yesterday Indica su quale periodo fare l'analisi dei log: "All" analizza tutti i log (in questo caso si consiglia di impostare "Archives = Yes", "Yesterday" si riferisce ai log del giorno prima (utile quando si crontabba un esecuzione notturna), "Today" si riferisce alle righe di log relative al giorno corrente.
Detail = Low Livello di dettaglio dei report. Può essere "Low", "Med", "High"
Service = All Definisce per quali servizi verificare i log. Può essere "All" o uno o più servizi, da scrivere su più righe, come "pam_pwdb" e "ftpd-messages"
# LogFile = messages Specifica un singolo file di log da analizzare. Se "Service = All" vengono comunque analizzati tutti i log
UTILIZZO
La modalità di utilizzo tipica è l'esecuzione in crontab del semplice comando logwatch
(su varie distribuzioni è un link simbolico /etc/log.d/scripts/logwatch.pl
) che si basa sulle impostazioni generali nel file di configurazioni. Per test o controlli straordinari si possono comunque passare alcuni argomenti alla command line:
logwatch --print --detail High --archives --range All
Stampa a video (--print) invece che inviare via mail, con il massimo dettaglio (--detail High), includendo anche i log archiviati (--archives) tutti i messaggi di ogni data (--range All)
logwatch --save logwatch.txt --range Today
Salva sul file logwatch.txt (--save logwatch.txt) l'output relativo alla giornata corrente (--range Today), usando per gli altri paramentri le impostazioni definite nel file di configurazione.
LINK: LogWatch Home Page - http://www.logwatch.org/
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2004-01-21 14:11:23
Snort è uno dei numerosi strumenti di rilevazione del traffico di rete per individuare e segnalare intrusioni.
Snort è stato progettato per funzionare in 3 modi differenti:
-Sniffer intercetta i pacchetti che viaggiano nella rete e li visualizza in console.
-Packet Logger salva su disco locale i pacchetti
-Network Intrusion Detection analizza il traffico di rete attraverso delle regole customizzabili ed esegue operazioni configurabili in caso di corrispondenza.
INSTALLAZIONE DI SNORT
L'installazione base di SNORT prevede come unico requisito di sistema la presenza delle libpcap (librerie per la cattura di pacchetti).
[root@GIOVE snort-1.9.0]# ./configure
loading cache ./config.cache
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
........
[root@GIOVE snort-1.9.0]# make
cd . && /root/snort/snort-1.9.0/missing autoheader
.....
[root@GIOVE snort-1.9.0]# make install
Making install in src
make[1]: Entering directory `/root/snort/snort-1.9.0/src'
.......
Snort è ora installato sul sistema in /usr/local/bin/snort
.
[root@GIOVE snort]# snort -?
Initializing Output Plugins!
-*> Snort! <*-
Version 1.9.0 (Build 209)
By Martin Roesch ([email protected], www.snort.org)
USAGE: snort [-options] <filter options>
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2003-03-04 11:47:56
SNORT può essere utilizzato come un normale packet sniffer per visualizzare il traffico di rete.
snort [-opzioni] < filtri >
Come ogni sniffer è possibile creare filtri in modo da monitorare solo certi tipi di pacchetti o interfacce.
Con snort -v
(verbose mode) si visualizzano gli header dei pacchetti, con snort -dev
si visualizzano sia i dati che gli header dei pacchetti.
[root@GIOVE root]# snort -v
Initializing Output Plugins!
Log directory = /var/log/snort
Initializing Network Interface eth0
--== Initializing Snort ==--
Decoding Ethernet on interface eth0
--== Initialization Complete ==--
-*> Snort! <*-
Version 1.9.0 (Build 209)
By Martin Roesch ([email protected], www.snort.org)
03/04-11:47:04.995500 10.0.5.16:22 -> 10.0.5.95:33227
TCP TTL:64 TOS:0x10 ID:26313 IpLen:20 DgmLen:132 DF
***AP*** Seq: 0x14F186E3 Ack: 0x13A910FF Win: 0x25B0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 51224596 4732590
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/04-11:47:04.995841 10.0.5.16:22 -> 10.0.5.95:33227
TCP TTL:64 TOS:0x10 ID:26314 IpLen:20 DgmLen:132 DF
***AP*** Seq: 0x14F18733 Ack: 0x13A910FF Win: 0x25B0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 51224596 4732590
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2003-03-07 17:03:43
Attraverso le opzioni del comando snort è possibile salvare su disco i pacchetti catturati da snort per poterli analizzare in un tempo successivo.
snort -dv -l /var/log/snort
dove /var/log/snort è una directory. Al suo interno verranno create diverse sottodirectory, con nomi corrispondenti agli indirizzi IP trovati nei pacchetti analizzati.
Nel caso su operi su reti ad alta velocità con l'opzione -b si imposta un logging più veloce (formato di tcpdump):
snort -dv -l /var/log/snort -b
con l'opzione -h (home network) si definisce la network di cui loggare i pacchetti:
snort -dev -l /var/log/snort -h 192.168.0.0/24
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2003-03-04 11:58:23
Un NIDS (Network Intrusion Detection Systems) è un sistema di monitoring di traffico di rete, volto ad individuare pattern di pacchetti potenzialmente ostili in risposta ai quali possono essere eseguite determinate azioni (notifica via mail, chiusura di una connessione, logging su un database ecc.).
Snort presenta vari modi per essere configurato come NIDS.
Innanzitutto prevede 3 tipi principali di regole:
-ALERT invia messaggi ad ogni infrazione;
-PASS non considera il pacchetto;
-LOG visualizza/scrive le informazioni del pacchetto;
Lo standard di Snort è stampare a video i messaggi di alert ma è possibile utilizzare altre modalita':
-full, visualizza l'intero messaggio
-fast, logging rapido dei messagggi
-unsock, invio dei messaggi ad un socket unix
-syslog, scrittura dei messaggi nel syslog di sistema
-smb messages, invio di messaggi di alert ad altri host tramite samba
-none, non invia nessun messaggio
Per le opzioni full,fast,unsock e none è necessario anteporre il comando -A
mentre con -s
i messaggi di alert vengono inviati al syslog. Per abilitare a Snort l'invio di messaggi tramite il samba client, una sorta di Winpopup, è necessario aggiungere l'opzione "--enable-smbalerts
" in fase di installazione di Snort.
snort -c snort.conf -l /var/log/snort -h 192.168.0.0/24
salva i log nella dir /var/log/snort prendendo in considerazione la rete 192.168.0.0/24
snort -c snort.conf -b -h 192.168.0.0/24 -M HOSTS
salva i dati in modalità tcpdump (meno informazioni ma più veloce), invia gli alert alle workstation windows
snort -c /etc/snort.conf -l /var/log/snort -h 10.1.0.0/24 -aIe -D
mostra i pacchetti ARP, aggiunge il nome interfaccia al log, mostra il layer secondario del pacchetto e con -D agisce come demone senza occupare una shell
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2004-01-21 18:31:44
Tripwire è un tipo di Intrusion Detection System, il suo lavoro è quello di verificare lo stato di determinati file rispetto ad uno stato di partenza (baseline). Una modifica non prevista di questo stato può essere indice della compromissione del sistema e della manipolazione non autorizzata di comandi, log o file di configurazione.
Esistono due versioni di Tripwire, una commerciale ed una Open Source.
Come punto di partenza Tripwire crea un database con all'interno una "fotografia" dei file del sistema in uno stato che iniziale che viene considerato sicuro. D'ora in poi Tripwire sarà in grado di controllare se ci sono state modifiche (nel contenuto, nella data di modifica, nei permessi, negli attributi...) o cancellazioni dei file presi in considerazione informando l'amministratore di sistema attraverso un rapporto.
Se le modifiche sono legittime, perchè dovute a normale attività del sistema, l'amministratore può aggiornare la baseline del database di Tripwire inglobando il nuovo status, altrimenti se le modifiche non vengono ritenute valide l'amministratore può immediatamente verificare quali componenti sono stati alterati.
Tripwire permette inoltre di criptare i suoi file di configurazione rendedoli modificabili solo attraverso l'inserimento di password creata in fase di installazione.
Sono richieste due password:
- la site password, di carattere generale, utilizzata per il file di configurazione e policies; può essere utlizzata per altre macchine esportando il file site.key
- la local password per il file database e i report
INSTALLAZIONE
Installazione di Tripwire tramite rpm:
[root@giove root]# rpm -ivh tripwire-2.3.1-14.i386.rpm
Preparing... ########################################### [100%]
1:tripwire ########################################### [100%]
Directory create:
/var/lib/tripwire ---> directory in cui verranno memorizzati i rapporti e il database di sistema
/etc/tripwire ---> si trovano i file di configurazione e le key di codifica
Post-Install
Per completare l'installazione è necessario eseguire lo script twinstall.sh
(nella dir /etc/tripwire/) il quale crea le password dei file di configurazione e produce le key di codifica
[root@giove tripwire]# ./twinstall.sh
----------------------------------------------
The Tripwire site and local passphrases are used to
sign a variety of files, such as the configuration,
policy, and database files.
Passphrases should be at least 8 characters in length
and contain both letters and numbers.
See the Tripwire manual for more information.
----------------------------------------------
Creating key files...
(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)
# Richiede l'inserimento della site password
Enter the site keyfile passphrase:
......
# Richiede l'inserimento della local password
Enter the local keyfile passphrase:
Verify the local keyfile passphrase:
FILE di CONFIGURAZIONE
I file di configurazione sono:
tw.cfg
(criptato) vengono memorizzati i dati riguardanti la locazione dei file di configurazione e i paramentri per l'invio di email (twcfg.txt file di esempio non criptato).
tw.pol
(criptato) file in cui viene specificata la modalità di funzionamento di Tripwire e le policy di controllo. Sono elencati i file da monitorare e il livello di "criticità" a loro assegnato (twpol.txt è un esempio non criptato).
INIZIALIZZAZIONE del SISTEMA
I file di configurazione e dati di Tripwire sono per sicurezza criptati, la loro modifica è possibile attraverso comandi che creano un file di testo relativo al file da modificare.
- Modifica del file tw.cfg:
[root@GIOVE tripwire]# twadmin --print-cfgfile > conf.txt
Per validare le modifiche effettuate sul file è necessario creare il nuovo file di configurazione specificando la "site key":
[root@GIOVE tripwire]# twadmin --create-cfgfile --site-keyfile /etc/tripwire/site.key conf.txt
Please enter your site passphrase:
Wrote configuration file: /etc/tripwire/tw.cfg
Le modifiche al file di configurazione sono ora attive.
- Creare il file tw.pol (file delle policies):
Prima di modificare le policy di tripwire bisogna creare il file da editare utlizzando il file tw.pol standard:
[root@GIOVE tripwire]# twadmin --print-polfile tw.pol > polfile.txt
Ora è possibile editare il file polfile.txt secondo le proprie necessità. Per rigeneraere il tw.pol definitivo si usa il comando:
[root@GIOVE tripwire]# tripwire --create-polfile polfile.txt
- Creare il database di sistema
Nel database di sistema verranno introdotti tutte le voci riguardanti i file da controllare secondo il file di configurazione tw.pol
[root@GIOVE tripwire]# tripwire --init
Please enter your local passphrase:
Incorrect local passphrase. # Ops!
Please enter your local passphrase:
Parsing policy file: /etc/tripwire/tw.pol
Generating the database...
*** Processing Unix File System ***
Performing integrity check...
Nel caso alcuni file specificati in tw.pol non esistono il comando visualiza messaggi di errori
### Warning: File system error.
### Filename: /var/lock/subsys/portmap
### No such file or directory
### Continuing...
### Warning: File system error.
### Filename: /var/lock/subsys/httpd
### No such file or directory
.....
# la locazione del file database è definita nel file di configurazione tw.cfg
Wrote database file: /var/lib/tripwire/GIOVE.twd
The database was successfully generated.
Tripwire è ora configurato, inizializzato e pronto per essere eseguito ed eventualmente schedulato per eseguire dei report sulle modifiche dei file del sistema:
[root@GIOVE tripwire]# tripwire --check
Tipo Infobox: PATH - Skill Level: 4- ADVANCED - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2003-03-10 22:48:13
tw.pol è il file delle regole di Tripwire criptato.
Con il seguente comando si crea una copia del file in formato testo:
[root@GIOVE tripwire]# twadmin -m p > twpol.txt
Una volta modificato twpol.txt ad hoc ecco i comandi per implementare le modifiche:
- nel caso in cui si voglia ricreare il file (opzione che necessita la rinizializzazione del database):
[root@GIOVE tripwire]# twadmin -m P twpol.txt
Please enter your site passphrase:
Wrote policy file: /etc/tripwire/tw.pol
- nel caso in cui si voglia aggiornare il file:
[root@GIOVE tripwire]# tripwire -m p twpol.txt
Parsing policy file: /etc/tripwire/twpol.txt
Please enter your local passphrase:
Please enter your site passphrase:
======== Policy Update: Processing section Unix File System.
======== Step 1: Gathering information for the new policy.
[...]
======== Step 2: Updating the database with new objects.
======== Step 3: Pruning unneeded objects from the database.
Wrote policy file: /etc/tripwire/tw.pol
Wrote database file: /var/lib/tripwire/GIOVE.twd
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2004-01-21 14:27:46
tw.cfg è il file di configurazione criptato di Tripwire.
twadmin -m f > twcfg.txt
è il comando per creare una copia del file in formato testo. Dopo la sua modifica è possibile ricreare il file tw.cfg
con twadmin -m F -S /etc/tripwire/site.key twcfg.txt
[root@GIOVE tripwire]# cat twcfg.txt
# Dichiarazione della locazione degli eseguibili e dei file di configurazione
ROOT = /usr/sbin
POLFILE = /etc/tripwire/tw.pol
DBFILE = /var/lib/tripwire/$(HOSTNAME).twd
REPORTFILE = /var/lib/tripwire/report/$(HOSTNAME)-$(DATE).twr
SITEKEYFILE = /etc/tripwire/site.key
LOCALKEYFILE = /etc/tripwire/$(HOSTNAME)-local.key
# Percorso dell'editor utilizzato per interagire con tripwire
EDITOR = /bin/vi
# Se vera lascerà la password in memoria il minor tempo possibile
LATEPROMPTING = false
# Impostazione per evitare il ripetersi di entry all'interno del report
LOOSEDIRECTORYCHECKING = false
# Non invia mail nel caso non siano state trovate violazioni nel check
MAILNOVIOLATIONS = true
# Livello di dettagli nell'email; max 4
EMAILREPORTLEVEL = 4
# Livello di dettagli nel file report; max 4
REPORTLEVEL = 4
# Metodo di invio mail: connessione a un SMTP remoto o SENDMAIL locale
MAILMETHOD = SMTP
# Opzioni in caso si scelga SMTP come metodo
SMTPHOST = mail.dominio.it
SMTPPORT = 25
# Caso metodo SENDMAIL: comando da eseguire per inviare email
#MAILPROGRAM = /usr/sbin/sendmail -oi -t
# Inserisce nel syslog tutti i messaggi di tripwire
SYSLOGREPORTING = false
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2003-03-04 12:14:24
Tripwire-check è lo script inserito, durante l'installazione tramite RPM su distribuzioni Linux basate su RedHat, nel cron per effettuare ogni giorno un controllo Tripwire del sistema.
#!/bin/sh
HOST_NAME=`uname -n`
if [ ! -e /var/lib/tripwire/${HOST_NAME}.twd ] ; then
echo "**** Error: Tripwire database for ${HOST_NAME} not found. ****"
echo "**** Run "/etc/tripwire/twinstall.sh" and/or "tripwire --init". ****"
else
#verifica del file di configurazione ed esecuzione del check con invio del report via email tramite l'opzione --email-tripwire
test -f /etc/tripwire/tw.cfg && /usr/sbin/tripwire --check --email-report
fi
L'indirizzo e-mail del destinatario deve essere specificato nel file tw.pol
che contiene anche tutte le regole per il controllo dei file locali.
Attacchi DOS |
Overview su Denial Of Service attacks e sui DDOS |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2003-03-05 22:00:27
Con un attacco DOS (Denial Of Service) si cerca di "negare un servizio" mettendo il sistema vittima nell'impossibilità di erogare regolarmente il suo servizio.
Questo genere di attacchi non comporta la compromissione di un sistema, i suoi effetti si esauriscono nel momento in cui viene interrotto e, in vari casi, è tale da risultare quasi impossibile da evitare.
La natura di un simile attacco è a suo modo "violenta" e brutale e spesso non richiede particolari conoscenze e può essere esguito tramite strumenti e script reperibili in rete.
Un evoluzione di un attacco DOS è un DDOS (Distributed Denial Of Service), in cui gli IP da cui viene sferrato sono molteplici e permettono una amplificazione degli effetti.
Ha fatto notizia, nel Febbraio 2000, una serie di DDOS su siti particolarmente noti (Yahoo, Ebay, CNN...)
che un singolo individuo è riuscito a rendere inutilizzabili per alcune ore utilizzando centinaia di host di origine, a loro volta precedentemente violati.
La diffusione di questi attacchi deriva anche dal fatto che è molto più facile rendere una rete o un sistema impraticabile piuttosto che ottenerne l'accesso e, vista anche la diffusione di comodi tool per farlo, questo ha scatenato le velleità di molti aspiranti hacker che vedono in un DOS un modo veloce per ottenere effetti di cui vantarsi.
La definizione DOS attack si riferisce all'effetto finale che si intende raggiungere, il rendere impraticabile un servizio in rete, ma i modi con cui può essere ottenuto questo scopo sono vari:
ESAURIMENTO DELLA LARGHEZZA DI BANDA
E' uno dei metodi più comuni, consiste nel saturare le linee che garantiscono la connettività dei sistemi bersaglio, in modo da rallentare enormemente il flusso di pacchetti legittimi.
Se l'aggressore può avere a disposizione sui sistemi da cui intende sfoderare il suo attacco una largehzza di banda superiore a quella del suo bersaglio, un simile attacco è facilmente realizzabile, volendo anche con un ping flood che per ogni ECHO REQUEST si aspetta un ECHO REPLY (salvo filtri di qualche firewall).
Più comune è il caso in cui l'attaccante ha a disposizione meno banda del bersaglio, in questo caso è comunque possibile cercare di saturarla utilizzando degli amplificatori.
Un tipico attacco di questo tipo era lo smurf in cui veniva inviato un pacchetto spoofato (con IP sorgente modificato in modo tale da corrispondere al bersaglio dell'attacco invece che all'host attaccante) direttamente all'indirizzo di broadcast di reti particolarmente affollate di host: per ogni pacchetto originario venivano reinviati al presunto mittente molti pacchetti di risposta.
Al giorno d'oggi un attacco smurf è molto improbabile, visto che sono state introdotte adeguate controdifese sulla maggior parte dei dispositivi in rete.
ESAURIMENTO DELLE RISORSE DI UN SISTEMA
Questi tipi di attacchi si differenziano da quelli basati sull'esaurimento della banda in quanto si punta a sovraccaricare il sistema della vittima, sottoponendo a sforzi insostenibili varie componenti quali CPU, memoria, spazio su disco ecc.
Questo effetto può essere ottenuto in vari modi, tutti fondamentalmente basati sul principio di generare il maggior carico possibile su un sistema remoto con il minimo delle risorse. Un SYN flood (inizio di una sessione TCP, con l'invio di un SYN, che non viene mai conclusa in quanto non si risponde al SYN ACK di risposta del bersaglio) può esaurire le socket disponibili di un sistema, una enorme quantità di GET ad una o più pagine Web dinamiche particolarmente pesanti da computare può riempire memoria e CPU di un sistema e contribuire ad allargare a dismisura i file di log (con rischio di esaurimento dello spazio su disco), altri mezzi possono esistere per rendere indisponibili altri servizi.
Anche un mail bombing a suo modo è una forma di DoS attack, sia al server di posta che riceve le mail, che al destinatario finale, che può vedersi esaurire la sua quota.
DIFETTI DI PROGRAMMAZIONE
Difetti di programmazione possono impedire ad un sistema di gestire una situazione eccezionale. Il mondo del software è pieno di bug che possono avere ripercussioni in termini di sicurezza e dare a luogo a vulnerabilità di varia natura. Alcune di questo possono essere tali da saturare la CPU time o causare il crash del sistema o del programma che eroga un servizio.
Tutti gli exploit in grado di sfruttare simili vulnerabilità di fatto costituiscono un attacco di tipo DoS.
ATTACCHI A ROUTING E DNS
Un attacco DoS basato sul routing consiste nella manipolazione da parte dell'aggressore delle tabelle di routing in modo da impedire il normale indirizzamento di pacchetti ai sistemi legittimi.
Alternativamente si può cercare di impedire ai server DNS autoritari per un dato dominio di svolgere correttamente la loro funzione e quindi di impedire la risoluzione degli indirizzi IP.
In entrambi i casi l'attacco non si concentra direttamente sul vero bersaglio (un sito web, per esempio) ma sui sistemi collaterali che sono indispensabili per renderlo accessibile: i router che ne gestiscono la connettività e i server DNS che ne conoscono l'indirizzo IP.
LINK: CERT Advisory CA-1998-01 Smurf IP Denial-of-Service Attacks - http://www.cert.org/advisories/CA-1998-01.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Davide 'Davide' Cattaneo - Ultimo Aggiornamento: 2003-03-07 16:31:54
Smurf è uno dei DOS attack che si basano sull'amplificazioni della banda più noti.
Anche se è un tipo di attacco diffuso da anni e se i suoi effetti sono facilmente individuabili sia per l'impotente vittima che per chi gestisce i network utilizzati per l'amplificazione, esistono tuttora varie reti che permettono di utilizzare questi tipi di attacco.
Smurf si basa su una tecnica di amplificazione dovuta alla natura del protocollo IP che può essere facilmente ovviata con una corretta configurazione dei dispositivi di rete.
L'amplificazione si ottiene inviando un pacchetto ICMP ECHO ad un indirizzo di broadcast di una rete, tramite il comando Ping.
Colui che vuole sferrare l'attacco innanzitutto si preoccuperà di spoofare il proprio indirizzo IP inserendo nel campo sorgente dei pacchetti IP l'indirizzo IP della vittima da lui selezionata. Prossimo passo sarà quello di scegliere una rete che faccia poi da amplificatore per l'attacco e cominciare a spedire quanti più pacchetti possibili verso
l'indirizzo di broadcast della rete prescelta.
Il router della rete selezionata, all'arrivo dei pacchetti inviati li inoltrerà verso tutti gli indirizzi IP facenti parte della sua sottorete.
Ogni computer che riceve il pacchetto ICMP risponde con un altro pacchetto ICMP diretto verso l'IP mittente che,
come abbiamo visto precedentemente, l'attaccante ha modificato con l'IP della vittima. Questo vale per tutti i computer presenti nella sottorete che a loro volta invieranno un pacchetto ICMP alla vittima occupandone la relativa banda Internet.
Si noti che il danno recato dai pacchetti ICMP sarà più elevato tanto quanti computer sono presenti nella rete.
Mettiamo di inviare un solo pacchetto ICMP a una rete contenente 100 sistemi configurati in modo da rispondere, l'aggressore riesce in pratica a moltiplicare il suo attacco DoS di ben 100 volte.
CONTROMISURE
Per evitare di essere utilizzati da terzi come amplificatore per il loro smurf, sarebbe bene disattivare sul proprio router esterno la funzione di risposta delle richieste ICMP mandate all'indirizzo di broadcast della rete dall'aggressore.
Il comando tipicamente utilizzato con router Cisco è il seguente: no ip directed-broadcast
e va applicato a livello di interfaccia. Nelle versioni recenti dell IOS questo comando è attivo di default.
E' inoltre possibile disabilitare questa funzione direttamente via software, dato che alcuni sistemi operativi quali Solaris, Linux, FreeBSD, AIX 4.x prevedono la possibilità di evitare queste richieste.
Linux:
Per impedire a un sistema Linux di rispondere alle richieste broadcast di ECHO, è possibile attivare il firewall a livello di kernel utilizzando iptables.
Unix:
Per impedire agli host di rispondere all'attacco Fraggle (una variante di Smurf che invece di usare un ECHO ICMP utilizza un ECHO sulla porta 7 UDP), disattivare echo e chargen in /etc/inetd/conf inserendo un # prima del nome dei servizi.
Durante l'attacco:
Abbiamo visto la grave minaccia rappresentata dalla possibilità di essere oggetto di un attacco smurf.
Come già detto prima sarebbe bene limitare il traffico ICMP e UDP in ingresso sui router esterni ai soli sistemi interni della rete che realmente necessitano questo servizio, e possibilmente solo per tipi ICMP prestabiliti.
E' possibile limitare la banda da destinarsi al servizio di ICMP a valori acettabili attivando la funzione di CAR (Committed Access Rate) disponibile nelle versioni di Cisco IOS 1.1CC, 11.1CE e 12.0, restringendo tale banda a valori acettabili.
Se prevenire non è più possibile la migliore via di uscita è cercare di collaborare con il proprio ISP e con la società proprietaria della rete di amplificazione, ricordandosi comunque che per quanto risalire all'aggressore sia possibile non è affatto semplice.
Si inizia quindi con l'individuazione dell'interfaccia che ha ricevuto il pacchetto contraffatto e si risale in tal modo al router precedente, percorrendo al contrario gli hop del pacchetto inviato dall'aggressore fino a giungere alla rete originaria. Una simile procedura risulta nella maggior parte dei casi molto complicata in quanto richiede l'intervento di network administrator di diversi Autonomous Systems, eventualmente displocati su nazioni diverse.
Questo genere di attacco è destinato ad essere sempre meno diffuso anche grazie al contributo di alcuni progetti che nei loro siti web inseriscono gli IP delle reti che ancora permettono uno Smurf (e generalmente gengono notificati di questa misconfigurazione). Ovviamente questi siti possono essere utilizzati da un malintenzionato per trovare reti che ancora possono essere da lui utilizzati per simili attacchi.
Altra utile contromisura, che non evita che la propria rete possa essere vittima di un DOS attack, ma impedisce agli utenti della rete stessa di portare a termine molti attacchi basati sullo spoofing degli IP sorgenti, è quella di implementare filtri in uscita dalle proprie linee, che impediscano l'invio in rete di pacchetti spoofati che abbiamo un IP sorgente diverso da quelli presenti nella propria rete.
LINK: Netscan.org: Una lista di network Smurf amplifiers - http://www.netscan.org/
LINK: Smurf Amplifier Registry (SAR) - http://www.powertech.no/smurf/
Rootkits |
Analisi della logica dei rootkit e dei metodi per individuarli - chkrootkit |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-05-07 12:41:31
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.
SOURCE: Understanding Rootkits - O'Reilly Net - http://linux.oreillynet.com/pub/a/linux/2001/12/14/rootkit.html
LINK: An Overview of Unix Rootkits (PDF) - http://www.idefense.com/idpapers/Rootkits.pdf
LINK: Kernel Rootkits Explained - http://www.ebcvg.com/articles.php?id=124
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-05-07 12:43:00
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.
(F)AQ: Come si previene l'installazione di un rootkit? -
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-08-16 18:04:15
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.
Tipo Infobox: STDOUT - Skill Level: 4- ADVANCED - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-08-20 19:45:29
Breve analisi del rootkit SuckIT
Su un sistema Linux RedHat 7.3 è stato installato il rootkit SuckIT, uno dei più evoluti in quanto agisce direttamente su /dev/kmem e non ha bisogno di un kernel modulare, cancella le proprie tracce dal /proc file system e modifica /sbin/init con una versione trojan.
Di default si installa nella directory /usr/share/locale/sk/.sk12/ che ovviamente non è visibile all'amministratore del sistema violato.
Un lsof, come tutti gli altri comandi di visualizzazione di file e processi, normalmente non ne rileva l'esistenza, ma nella shell remota dell'intrusore il processo è normalmente visibile:
[root@95 .sk12]# lsof | grep sk
(dalla shell del rootkit)
sk 5878 root cwd DIR 3,6 4096 2 /
sk 5878 root rtd DIR 3,6 4096 2 /
sk 5878 root txt REG 3,6 29220 211267 /usr/share/locale/sk/.sk12/sk
sk 5878 root 0u CHR 1,3 33485 /dev/null
sk 5878 root 1u CHR 1,3 33485 /dev/null
sk 5878 root 2u CHR 1,3 33485 /dev/null
sk 5878 root 3u CHR 1,2 33250 /dev/kmem
sk 5878 root 4u raw 2791354 00000000:0006->00000000:0000 st=07
sk 5878 root 5u IPv4 2960357 TCP 95.intranet:32954->95.intranet:32947 (ESTABLISHED)
sk 5878 root 6u CHR 2,0 33702 /dev/ptyp0
[root@95 .sk12]# ps -adef
(evidenziati i processi normalmente nascosti)
root 5040 1 0 11:25 ? 00:00:00 ./sk
root 5878 5040 0 11:32 ? 00:00:00 ./sk
root 5879 5878 0 11:32 ttyp0 00:00:00 sh -i
Fortunatamente l'ultima versione al momento disponibile di chkrootkit si accorge che qualcosa sul sistema è anomalo:
[root@95 chkrootkit-pre-0.36]# ./chkrootkit
ROOTDIR is `/'
Checking `amd'... not found
Checking `basename'... not infected
Checking `biff'... not found
Checking `chfn'... not infected
Checking `chsh'... not infected
Checking `cron'... not infected
Checking `date'... not infected
Checking `du'... not infected
Checking `dirname'... not infected
Checking `echo'... not infected
Checking `egrep'... not infected
Checking `env'... not infected
Checking `find'... not infected
Checking `fingerd'... not found
Checking `gpm'... not infected
Checking `grep'... not infected
Checking `hdparm'... not infected
Checking `su'... not infected
Checking `ifconfig'... not infected
Checking `inetd'... not tested
Checking `inetdconf'... not found
Checking `identd'... not infected
Checking `killall'... not infected
Checking `ldsopreload'... not infected
Checking `login'... not infected
Checking `ls'... not infected
Checking `lsof'... not infected
Checking `mail'... not infected
Checking `mingetty'... not infected
Checking `netstat'... not infected
Checking `named'... not found
Checking `passwd'... not infected
Checking `pidof'... not infected
Checking `pop2'... not found
Checking `pop3'... not found
Checking `ps'... not infected
Checking `pstree'... not infected
Checking `rpcinfo'... not infected
Checking `rlogind'... not found
Checking `rshd'... not found
Checking `slogin'... not infected
Checking `sendmail'... not infected
Checking `sshd'... not infected
Checking `syslogd'... not infected
Checking `tar'... not infected
Checking `tcpd'... not infected
Checking `top'... not infected
Checking `telnetd'... not infected
Checking `timed'... not found
Checking `traceroute'... not infected
Checking `w'... not infected
Checking `write'... not infected
Checking `aliens'... no suspect files
Searching for sniffer's logs, it may take a while... nothing found
Searching for HiDrootkit's default dir... nothing found
Searching for t0rn's default files and dirs... nothing found
Searching for t0rn's v8 defaults... nothing found
Searching for Lion Worm default files and dirs... nothing found
Searching for RSHA's default files and dir... nothing found
Searching for RH-Sharpe's default files... nothing found
Searching for Ambient's rootkit (ark) default files and dirs... nothing found
Searching for suspicious files and dirs, it may take a while...
/usr/lib/perl5/5.6.1/i386-linux/.packlist
Searching for LPD Worm files and dirs... nothing found
Searching for Ramen Worm files and dirs... nothing found
Searching for Maniac files and dirs... nothing found
Searching for RK17 files and dirs... nothing found
Searching for Ducoci rootkit... nothing found
Searching for Adore Worm... nothing found
Searching for ShitC Worm... nothing found
Searching for Omega Worm... nothing found
Searching for Sadmind/IIS Worm... nothing found
Searching for MonKit... nothing found
Searching for Showtee... nothing found
Searching for OpticKit... nothing found
Searching for T.R.K... nothing found
Searching for Mithra... nothing found
Searching for anomalies in shell history files... nothing found
Checking `asp'... not infected
Checking `bindshell'... not infected
Checking `lkm'... You have 3 process hidden for readdir command
You have 3 process hidden for ps command
Warning: Possible LKM Trojan installed
Checking `rexedcs'... not found
Checking `sniffer'...
eth0 is not promisc
Checking `wted'... nothing deleted
Checking `z2'...
nothing deleted
In particolare è lo script che controlla ad uno ad uno tutti i possibili PID (da 1 a 65535) che si accorge che alcune righe di ps e alcune directory (che sono comunque accessibili, se si conosce il nome, ma non vengono visualizzate) in /proc/ vengono nascoste:
[root@95 chkrootkit-pre-0.36]# ./chkproc -v
PID 5040: not in readdir output
PID 5040: not in ps output
PID 5878: not in readdir output
PID 5878: not in ps output
PID 5879: not in readdir output
PID 5879: not in ps output
You have 3 process hidden for readdir command
You have 3 process hidden for ps command
A questo punto anche da una shell normale è possibile visualizzare il contenuto delle rispettive directory in proc, anche se un ls non le visualizza:
cat /proc/5040/cmdline
./sk
Dalla shell dell'intrusore si visualizza sia /sbin/init sia /sbin/initsk12 (questo è l'init originario, che viene rinominato, sostituito con una versione modificata, e nascosto (come tutti i file che finiscono con sk12 (suffisso configurabile in fase di compilazione del rootkit)
-rwxr-xr-x 1 root root 26920 Jul 5 11:16 init
-rwxr-xr-x 1 root root 37617 Apr 19 18:35 initlog
-rwxr-xr-x 1 root root 26920 Jul 5 11:16 initsk12
Un controllo sull'integrità dei file modificati ci rende evidente che il rootkit non altera il checksum md5, rendendo difficle, per tool come Tripwire, l'individuazione dello stesso.
[root@95 chkrootkit-pre-0.36]# md5sum /sbin/init
a44b4fe49763349af054000b8565618a /sbin/init
[root@95 chkrootkit-pre-0.36]# md5sum /sbin/initsk12
a44b4fe49763349af054000b8565618a /sbin/initsk12
SOURCE: L'articolo su Phrack che introduce SuckIT - http://phrack.org/show.php?p=58&a=7
Tipo Infobox: BOFH - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-08-19 16:35:53
Visualizza in tutto il file system i file modificati negli ultimi 4 giorni (sostituire con il numero di giorni passati da quando si ritiene essere stata fatta l'instrusione). Può essere utile per individuare tracce lasciate dall'intrusore non coperte. Quando viene modificato un comando come ps, tipicamente la data di modifica viene lasciata inalterata, tuttavia altre tracce di attività illegittima (compilazione del rootkit, modifica di file dove non si è corretta la data ecc.) possono essere rivelate.
Tipo Infobox: BOFH - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-08-19 16:36:28
Visualizza per tutti i file installati tramite RPM se sono stati in qualche modo modificati rispetto all'RPM originale. E' E' un comodo metodo per determinare se qualcosa di strano è successo a dei file sul proprio sistema utilizzando le funzionalità di integrity checksum di RPM.
Un output piuttosto verboso su effettive modifiche è normale, ma se si riferisce a file che non dovrebbero essere stati modificati dovrebbe suonare un campanello d'allarme.
Linux VPN |
Le soluzioni VPN disponibili su Linux. Teoria e implementazione. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-02-25 00:44:07
Una VPN (Virtual Private Network) è un collegamento fra due reti private attraverso la rete pubblica. Una VPN sfrutta i meccanismi di trasporto di Internet per effettuare connessioni fra delle reti remote e scambiare dati fra queste in modo trasparente, come se fossero collegate da un linea diretta.
Il traffico che passa per le VPN viene criptato per garantire la riservatezza dei dati, dal momento che attaversa Internet per delle rotte non note a priori e non controllabili.
Gli host che gestiscono le VPN devono avere un IP pubblico per stabilire un link con il relativo peer e devono entrambi implementare lo stesso protocollo per gestire la VPN.
Una VPN, oltre a collegare due reti remote tramite i loro gateway, può collegare un singolo host client a un server VPN su Internet e tramite quello accedere alla rete privata che gli sta dietro.
L'importanza e la diffusione delle VPN è cresciuta con la crescita di Internet: rispetto a linee dedicate dirette, permettono la connessione fra sedi remote di un'azienda o qualsiasi entità in modo decisamente più economico e amministrabile, pur presentando gli inconvenienti inevitabili dovuti all'uso di Internet: maggiori problemi di sicurezza, meno garanzie di affidabilità e velocità minima.
I PROTOCOLLI USATI PER LE VPN
Qualsiasi metodo per criptare del traffico di rete fra due host remoti può essere usato per creare una VPN, anche protocolli generalmente utilizzati per altri scopi con SSH o SSL.
I protocolli comunemente usati per una VPN sono comunque dedicati a questo scopo e, in diversi modi ottengono risultati analoghi: la creazione di un tunnel criptato entro il quale veicolare i pacchetti di due reti distanti.
IPSEC
E' lo standard più diffuso, generalmente non semplice da configurare ma supportato da molti vendor e sistemi operativi.
Cisco lo supporta sia sui Firewall Pix che nello IOS dei suoi router, per cui esistono versioni dedicate, con supporto hardware per velocizzare la criptazione dei dati.
Microsoft lo supporta nativamente su Windows 2000 e XP e, tramite un client dedicato, su Windows 98/ME/NT.
Per Linux, FreeBSD e altri Unix esistono soluzioni diverse, tra quelle opensource FreeS/Wan è la più nota. Sun supporta IPSec da Solaris 8 in poi.
Checkpoint Firewall-1, SonicWall, Raptor, Shiva, Lucent e molti altri prodotti e produttori lo supportano in soluzioni software o in network appliance dedicate.
PPTP
Protocollo sviluppato da Microsoft e supportato, oltre che su Windows, anche da altri fornitori e prodotti software.
Su Linux e altri Unix ne esiste una versione opensource chiamata PoPTop e altre implementazioni meno diffuse.
E' un adattamento del PPP che permette di stabilire collegamenti punto-punto tramite Internet, risulta meno sicuro di IPsec ma generalmente più semplice, almeno su Windows, da configurare e utilizzare.
Utilizza la porta 1723 TCP per il canale di controllo e il protocollo GRE (IP type 47) per incapsulare i dati.
L2TP
Standard che si basa sul protocollo L2F di Cisco e crea connessioni punto-punto incapsulando PPP (layer2) e quindi permettendo il trasporto anche di protocolli diversi da IP.
I pacchetti incapsulati vengono trasportati tramite UDP per cui può essere nattato facilmente.
Rispetto a IPSec è carente nella criptazione del payload ma ha un overhead minore.
Protocolli proprietari
Molti vendor oltre a supportare i protocolli più diffusi implementano nelle loro soluzioni VPN dei protocolli proprietari che possono rendere più semplice la configurazione di un tunnel fra dispositivi dello stesso produttore ma, ovviamente, difettano in interoperabilità con implementazioni di terzi.
Su Linux è diffuso il protocollo CIPE seppur con scarse possibilità di interoperabilità con dispositivi di terzi e VPND che usa un protocollo custom, oltre a soluzioni particolari come l'uso di ppp incapsulato su SSH.
HOWTO: VPN HOWTO - http://ldp.openskills.info/HOWTO/VPN-HOWTO/index.html
(F)AQ: volevo sapere la risposta che avete dato a jordan23 -
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-09-22 05:12:12
FreeS/WAN è una delle implementazioni IPsec per Linux più diffuse. Può essere utilizzato per gestire decine di tunnel sulla stessa macchina in grado di comunicare tramite IPsec anche con dispositivi di terzi.
INTRODUZIONE E FEATURES
FreeS/WAN è composto da 3 parti principali:
Klips E' un modulo per il kernel, che va compilato sul kernel corrente (ed è in genere piuttosto sensibile alle variazioni di versione, per cui è bene utilizzarne la versione compatibile con il proprio kernel). Gestisce AH e ESP modificando di conseguenza i pacchetti IP gestiti dal kernel.
pluto E' un demone che gestisce il protocollo IKE per la negoziazione dei tunnel.
User tool vari, che generalmente possono essere invocati dal comando ipsec
, con cui di fatto si eseguono tutte le operazioni di gestione delle VPN.
Tramite FreeS/WAN si possono configurare tunnel net-to-net, ai cui estremi si trovano dei gateway delle due reti remote da connettere, oppure si può avere un singoli VPN gateway a cui si collegano client remoti anche con IP variabili (configurazioni roadwarrior, tipicamente utilizzabili su portatili o dial-up stations).
L'interoperabilità con altri software e device IPsec (da Cisco a Microsoft, da Checkpoint a Solaris) è buona, soprattutto se si usano le patch per il supporto di certificati x.509.
Una versione parallela a quella ufficiale che si base su di essa e aggiunge tutte le patch più interessanti (supporto NAT, x.509, algoritmi di criptazione alternativi a 3DES ecc) è Super FreeS/WAN.
Una caratteristica interessante, proposta dagli autori di FreeS/WAN come estensione dello standard IPsec (che loro vorrebbero ratificata in future RFC) è l'Opportunistic Encryption (OE) che, basandosi sul DNS per lo scambio delle chiavi pubbliche, rende l'implementazione di nuovi tunnel molto più rapida e snella.
Al momento è possibile utilizzare questa feature solo fra due VPN gateway basati su FreeS/WAN.
Molte soluzioni VPN (network appliance e distribuzioni standard dedicate) basate su Linux utilizzano FreeS/WAN, spesso con interfacce grafiche che ne semplificano l'installazione e la configurazione.
Fino alla versione 1.99 l'unico protocollo di criptazione supportato è 3DES. DES non viene supportato per la scarsa sicurezza, il supporto AES è previsto nelle future versioni ufficiali o disponibile nelle patch di Super FreeS/WAN. Gli autori, non a torto, non ritengono necessario implementare altri protocolli che complicherebbero il progetto.
INSTALLAZIONE
L'installazione direttamente dai sorgenti richiede un patching del kernel per includere i moduli forniti da FreeS/WAN. Non è ovviamente pratica che può essere felicemente portata a termine da un utente poco esperto ma, per chi è abituato a ricompilarsi il kernel, non presenta particolari difficoltà.
Dal sito ufficiale sono scaricabili anche dei comodi rpm (al momento per RedHat 7 e 8) che rendono l'installazione molto più semplice: basta un rpm -i di freeswan-module.*.rpm e freeswan.*.rpm.
Notare che per usare questi RPM si devono usare i kernel modulari standard di RedHat: se si usa un proprio kernel ricompilato autonomamente è il caso di considerare l'installazione da sorgenti.
Prima di procedere alla configurazione ai due estremi del tunnel è bene assicurarsi che ci sia connettività IP fra i due per evitare troppe perdite di tempo di fase di troubleshooting del setup.
A livello di firewalling, un tunnel IPsec ha bisogno di poter far comunicare i due gateway sulla porta UDP 500, in entrambi i sensi, per il protocollo IKE, inoltre si deve permettere il passaggio di pacchetti IP type 50 per il protocollo ESP, che quindi non usa TCP o UDP per il trasporto, e i pacchetti IP type 51 per il protocollo AH (che, comunque, non viene abilitato di default da FreeS/WAN).
Si trovano in rete inoltre, gli RPM per RedHat che già comprendono le patch per il supporto di certificati x509, fondamentali per l'interoperabilità con le soluzioni IPsec di vari produttori.
CONFIGURAZIONE
FreeS/WAN di default si aspetta il suo file di configurazione in /etc/ipsec.conf
e un eventuale /etc/ipsec.secrets
con le chiavi RSA o elementi per l'autenticazione fra host. Altri file come certificati e revocation lists devono stare nella directory /etc/ipsec.d/
.
Nel file di configurazione, che prevede un discreto numero di direttive, si intende generalmente il lato sinistro (left) come quello locale e quello destro (Right) come quello Remoto ma questa è solo una convenzione in quanto i termini possono essere scambiati.
Il file di configurazione prevede diverse sezioni, all'interno delle quali si definiscono direttive con formato parametro=valore (una per riga, precedute da almeno uno spazio, anche in presenza di # per i comment, senza righe vuote all'interno della stessa sezione).
Le impostazioni generalmente da fornire per ogni tunnel sono:
- Gli host ID dei server VPN e il modo con cui si autenticano (hostid
).
- L'IP pubblico del server locale (left
)
- L'IP del suo default gateway pubblico (leftnexthop
)
- La rete locale a cui il server è collegato (che dovrà essere messa in comunicazione con la rete remota (leftsubnet
).
- L'IP pubblico del server remoto (right
, può essere un %any
per indicare un IP arbitrario)
- L'IP del suo default gateway pubblico (rightnexthop
può essere un generico %defaultroute
)
- La rete locale a cui il server remoto è collegato (che dovrà essere messa in comunicazione con la rete locale (rightsubnet
).
- Il metodo di autenticazione utilizzato (authby
).
GESTIONE
Tramite il comando ipsec
si possono gestire tutte le userland utility fornite con FreeS/WAN.
Con ipsec --help
è possibile vedere tutti i comandi eseguibili, per o quali esistono ottime man pages con prefisso ipsec_ (es: man ipsec_whack
).
Qui si elencano alcune opzioni particolarmente utili:
ipsec verify
Verifica se il sistema può gestire un tunnel IPsec. Utile per capire in fretta se ci sono problemi di base che precludono il funzionamento.
ipsec setup --start
Avvia il servizio IPsec (carica il kernek module Klips e lnacia Pluto per gestire IKE). Coincide, in installazioni basate su RPM a /etc/rc.d/init.d/ipsec start
.
ipsec setup --stop
Stoppa il servizio IPsec, droppando tutti i tunnel eventualmente attivi.
ipsec whack --status
Mostra lo stato corrente del sistema IPsec
ipsec auto --listall
Elenca tutte le chiavi PSK, RSA o i certificati x509 che possono essere accettati (leggendo i contenuti da /etc/ipsec.secrets
ipsec newhostkey --output /etc/ipsec.secrets --hostname io.openskills.info
Genera una nuova chiave RSA per l'host io.openskills.info e la aggiunge al file ipsec.secrets
ipsec barf
Visualizza a video una grande quantità di informazioni utili per il debugging e il troubleshooting in caso di problemi.
LINK: Home Page ufficiale FreeS/WAN - http://www.freeswan.org/
LINK: Home Page di Super FreeS/WAN con patch aggiuntive - http://www.freeswan.ca/
Tipo Infobox: STDOUT - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-03-25 21:10:13
L'installazione di FreeS/WAN è intrinsecamente complicata, dal momento che richiede la compilazione di un modulo altamente sensibile alle differenze di versione del Kernel.
Dal sito ufficiale, comunque, si possono scaricare degli RPM precompilati per RedHat, per i quali l'unica attenzione da seguire è il rispetto della versione del proprio kernel.
[root@GIOVE root]# ftp ftp.xs4all.nl
Connected to ftp.xs4all.nl (194.109.6.26).
[...]
ftp> cd pub/crypto/freeswan/binaries/RedHat-RPMs
ftp> ls
Notare che esistono diverse directory per ogni Kernel version ufficiale di RedHat
227 Entering Passive Mode (194,109,6,26,8,21).
150 Opening ASCII mode data connection for file list
drwxr-xr-x 2 freeswan user 4096 Nov 4 22:31 2.4.18-10
drwxr-xr-x 2 freeswan user 4096 Nov 4 22:31 2.4.18-14
drwxr-xr-x 2 freeswan user 4096 Nov 4 22:31 2.4.18-17.7.x
drwxr-xr-x 2 freeswan user 4096 Nov 4 22:31 2.4.18-17.8.0
drwxr-xr-x 2 freeswan user 4096 Nov 18 10:06 2.4.18-18.7.x
drwxr-xr-x 2 freeswan user 4096 Nov 18 10:06 2.4.18-18.8.0
drwxr-xr-x 2 freeswan user 4096 Dec 23 10:13 2.4.18-19.7.x
drwxr-xr-x 2 freeswan user 4096 Jan 4 06:57 2.4.18-19.8.0
drwxr-xr-x 2 freeswan user 4096 Feb 13 15:50 2.4.18-24.7.x
drwxr-xr-x 2 freeswan user 4096 Feb 13 15:50 2.4.18-24.8.0
drwxr-xr-x 2 freeswan user 4096 Nov 4 22:31 2.4.18-3
drwxr-xr-x 2 freeswan user 4096 Nov 4 22:31 2.4.7-10
drwxr-xr-x 2 freeswan user 4096 Nov 4 22:31 2.4.9-34
-rw-r--r-- 1 freeswan user 285 Oct 16 00:25 README
lrwxrwxrwx 1 freeswan user 26 Nov 4 22:44 freeswan-rpmsign.asc -> .
./../freeswan-rpmsign.asc
ftp> cd 2.4.18-14
[...]
ftp> get freeswan-1.99_2.4.18_14-0.i386.rpm
[...]
ftp> get freeswan-module-1.99_2.4.18_14-0.i386.rpm
[...]
[root@GIOVE root]# rpm -i freeswan-module-1.99_2.4.18_14-0.i386.rpm
warning: freeswan-module-1.99_2.4.18_14-0.i386.rpm: V3 RSA/MD5 signature: NOKEY, key ID 5a7e4731
do not forget to install the userland utilities
[root@GIOVE root]# rpm -i freeswan-1.99_2.4.18_14-0.i386.rpm
warning: freeswan-1.99_2.4.18_14-0.i386.rpm: V3 RSA/MD5 signature: NOKEY, key ID 5a7e4731
invoke "service ipsec start" or reboot to begin
[root@GIOVE root]# service ipsec start
ipsec_setup: Starting FreeS/WAN IPsec 1.99...
ipsec_setup: insmod: ipsec: no module by that name found
ipsec_setup: insmod failed, but found matching template module 53cb1f7e.
ipsec_setup: Copying /lib/modules/2.4.18-14/kernel/net/ipsec/53cb1f7e to /lib/modules/2.4.18-14/kernel/net/ipsec/i psec.o.
ipsec_setup: /sbin/insmod /lib/modules/2.4.18-14/kernel/net/ipsec/ipsec.o
ipsec_setup: Using /lib/modules/2.4.18-14/kernel/net/ipsec/ipsec.o
ipsec_setup: Symbol version prefix ''
ipsec_setup: WARNING: eth0 has route filtering turned on, KLIPS may not work
ipsec_setup: (/proc/sys/net/ipv4/conf/eth0/rp_filter = `1', should be 0)
Tipo Infobox: DESCRIPTION - Skill Level: 5- SENIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-02-27 15:55:24
Super FreeS/WAN è una versione di FreeS/WAN con incluse alcune delle patch non ufficiali più richieste quali supporto certificati x509, transversal NAT per gestire tunnel anche attraverso connessioni nattate, algoritmi di criptazione aggiuntivi oltre al 3DES di default, notifica e cancellazione delle SA.
Di fatto, pur presentando alcune feature sperimentali, è la soluzione necessaria per creare tunnel con device di terzi tramite certificati x 509 o per situazioni particolari in cui uno dei due estremi del tunnel viene a sua volta nattato da un firewall.
Come per la versione ufficiale di FreeS/WAN, anche questa versione "con gli steroidi" può essere comodamente installata tramite gli RPM (compatibili RedHat 7 e 8) forniti sul sito.
Per chi è pratico di compilazioni di kernel, comunque, il patching è una procedura piuttosto semplice.
cd /usr/src/
wget http://download.freeswan.ca/super-freeswan/super-freeswan-1.99.5.1.tar.gz
tar -zxvf super-freeswan-1.99.5.1.tar.gz
cd super-freeswan-1.99.5.1/
Si scarica, si scompatta, si entra nella directory creata, in cui sono presenti varie sottodirectory e file tra cui:
doc/
Directory con abbondante documentazione (che si trova anche online)
klips/ pluto/
Directory con i sorgenti per i moduli kernel e le userland utilities
rpm-in
File di specs per costruire un RPM
make menugo
Con questo comando si apre il familiare menu di configurazione del kernel con già aggiunti, sotto la voce Networking options, i moduli aggiuntivi relativi a FreeS/WAN e con le altre opzioni del kernel precedentmente impostate in una compilazione precedente (è buona cosa operare sulle configurazioni di un kernel già testato, di cui si è certi che funzioni la parte di networking per normali operazioni in rete). Ovviamente, a prescindere da dove si trova la directory super-freeswan-1.99.5.1 da cui si lancia make menugo
(il giusto posto sarebbe /usr/src/super-freeswan-1.99.5.1/
) ci si aspetta di avere i sorgenti del kernel che si vuole patchare in /usr/src/linux
). I moduli preimpostati di FreeS/WAN vanno generalmente bene, a questi si possono aggiungere alcuni algoritmi di criptazione opzionali, che vengono caricati come sotto-moduli (notare che 3DES è incluso di default come algoritmo principale e può essere incluso anche come modulo aggiuntivo).
Dopo la scelta dei moduli si può uscire, salvando la configurazione, e automaticamente viene lanciata la ricompilazione del kernel e dei moduli, tanto che alla fine basterà copiare l'immagine del kernel ottenuta (/usr/src/linux/arch/i386/boot/bzImage
) e configurare il LILO o GRUB del caso.
Il Makefile fornito è piuttosto completo e oltre a fornire l'opzione tutto-fare make menugo
presenta altre opzioni parziali come make menumod
per ricompilare solo i moduli IPsec aggiuntivi.
Terminata la compilazione del nuovo kernel e dei suoi moduli, installato il kernel e aggiornato il file di configurazione del boot loader, è possibile riavviare la macchina e iniziare a lanciarsi nel criptico mondo di IPsec.
I dettagli sulla configurazione sono spiegati altrove, ma è utile sarebe le posizioni dei file che contano:
/etc/ipsec.conf
E' il file di configurazione. Ne viene creato uno di esempio che deve ovviamente essere modificato.
/etc/ipsec.secrets
Contiene le chiavi e le eventuali password per gestire le autenticazioni fra gli estremi del tunnel
/etc/ipsec.d/
E' una directory in cui si trovano certificati e chiavi
/usr/local/sbin/ipsec
E' il comando ipsec (uno script shell) con cui si può gestire praticamente ogni aspetto di FreeS/WAN
/usr/local/lib/ipsec
Contiene i vari sotto-comandi di ipsec, che possono essere anche eseguiti direttamente (meglio evitare, dal momento che il comando ipsec imposta anche un environment adeguato, prima di eseguire i sottocomandi)
man ipsec
e man ipsec_sottocomando
Fornisce ottima e puntuale documentazione
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2003-02-26 18:58:13
Vpnd è una alternativa relativamente semplice e piuttosto funzionale per realizzare VPN interamente basate su Linux (e altri Unix). I dati tra le due reti remote vengono criptati, dai gateway dove gira il demone VPND con l'algoritmo Blowfish, dopo uno scambio manuale preventivo di chiavi.
Necessita delle libreirie zlip e del supporto SLIP sul kernel per funzionare.
INSTALLAZIONE
Prima di installare verificare che il kernel supporti l'interfaccia SLIP (Serial Line Internet Protocol), che viene utilizzata da vpnd per effettuare la connessione tramite linea seriale (modem) o IP.
Decompressi i sorgenti lanciare i soliti configure/make:
root@urano:/usr/src/vpnd#./configure
root@urano:/usr/src/vpnd# make
gcc -DCOMPRESS -DLINUX -DLINUX2 -Wall -O3 -fno-inline -DCRYPTOX86 -DMD5_HMAC_FAST -DSHA1_HMAC_FAST -DRMD160_HMAC_FAST -c -o vpnd.o vpnd.c
.....
CONFIGURAZIONE
Il file di configurazione di Vpnd è di default /etc/vpnd.conf
, nel caso si usi il modem per effettuare la VPN è necessario configurare anche il file di inizializzazione della connessione vpnd.chat.
In aggiunta anche un file contente la "key" di codifica dei dati, che può essere vpnd.key nel caso si abbia scelto il formato base (con il comando ./vpnd -m
), vpnd.lcl.key o vpnd.rmt.key
nel caso del formato esteso (cioè una key sul server e una key sul client remoto con il comando ./vpnd -x dir/key/
).
In entrambi i casi la key di codifica deve essere copiata nella macchina client attraverso, ovviamente una modalità sicura (es: scp) prima di poter stabilire il tunnel.
Effettuare la stessa procedura di installazione per la macchina Linux all'altro capo della VPN.
GESTIONE
Si può lanciare il demone con il comando vpnd
oppure aggiungendo le seguenti opzioni:
vpnd -f /dir/vpnd.conf
utilizza un file di configurazione con path diverso dallo standard(/etc/vpnd.conf)
vpnd -n
forza vpnd a non diventare un demone
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2003-02-26 19:06:19
Di seguito il file di configurazione vpnd.conf lato server.
Il file lato client si differenzia solo per la dichiarazione "mode client" e IP.
# File di Configurazione Lato SERVER
mode server
#
# IP e porta del client remoto
client 123.123.123.17 3001
#
# IP e porta del server
server 234.234.0.2 2001
#
# IP dell'interfaccia SLIP locale utilizzata da Vpnd
local 192.168.10.100
#
# IP dell'interfaccia SLIP remota utilizzata da Vpnd
remote 192.168.10.200
#
# Intervallo di tempo tra un ping di controllo e l'altro
keepalive 10
#
# Numero massimo di tentativi del ping
noanswer 3
#
# Il percorso della key di codifica
keyfile samples/key
#
# Il pid file del demone vpnd
pidfile /var/run/vpnd.pid
#
# Ogni quanti secondi viene cambiata la chiave di crittazione
keyttl 120
#
# Settaggio del random device
randomdev /dev/urandom
#
# MTU (maximum-transfer-unit) se settato deve essere identico nella configurazione client
mtu 1500
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-10-10 19:08:04
PopTop è l'implementazione pptp opensource più diffusa ed utilizzata per permettere ad un sistema Unix, tipicamente Linux, di fare da server PPTP per client che supportano questo protocollo per VPN (implementato nativamente su Windows).
Per funzionare poptop si appoggia al pppd comunemente disponibile nelle varie distribuzioni Linux e richiede una configurazione relativamente semplice, ma se si deve interoperare con client Windows E supportare i suoi metodi di default di autenticazione (MSCHAP v2) e criptazione (MPPE) è necessario avere il supporto del modulo mppe nel kernel, con qualche complicazione in più per il setup iniziale.
INSTALLAZIONE
Dal sito ufficiale è facilmente raggiungibile l'area download che si appoggia a sourceforge.
Si presentano diversi tipi di file (tar.gz dei sorgenti o pacchetti precompilati per alcune delle prinicpali distribuzioni):
- mppe module builder serve per avere il supporto mppe e qundi avere piena interoperabilità con client Windows. Vengono utilizzati due componenti: il comodissimo dkms che permette di ricompilare on.the-fly moduli aggiuntivi del kernel quando questo viene aggiornato (evitando il rischio che il modulo mppe diventi inutilizzabile al primo aggiornamento del kernel) e il vero e proprio modulo mppe, kernel_ppp_mppe, pacchettizzato in modo da essere usato con dkms.
- ppp che contiene anche il server pppd in una versione sufficientemente aggiornata o patchata per supportare mppe (quella di default presente nella propria distribuzione potrebbe non farlo).
- pptpd il server PopTop vero e proprio.
Per l'installazione si suggerisce l'uso dei pacchetti rpm precompilati e di generarsi i propri rpm partendo dagli rpm dei sorgenti (Installare il src.rpm e ricostruire il pacchetto RPM per la propria macchina con rpmbuild -ba /usr/src/redhat/SPEC/pptpd.spec
).
SU Debian pptpd è disponibile direttmanete (apt-get install pptpd
).
Se si vuole procedere compilando i sorgenti leggere la documentazione sul sito ufficiale.
CONFIGURAZIONE
I file di configurazione essenziali sono 3 /etc/pptpd.conf, /etc/ppp/options.pptpd e /etc/ppp/chap-secrets:
/etc/pptpd.conf
contiene informazioni su quali IP assegnare ai client che si collegano e qualche parametro che generalmente non si modifica.
DI fatto il suo contentuo potrebbe limitarsi a qualcosa tipo:
option /etc/ppp/options.pptpd Esplicita la posizione del file che contiene i parametri ppp da usare per le connessioni pptp
.
localip 10.0.0.60 L'IP sulla rete interna del server PPTP
remoteip 10.0.0.110-119 Il range di IP che si vuole assegnare ai client PPTP che si collegano sulla rete interna
Può inoltre servire impostare:
bcrelay eth0
Abilita il broadcast dai client alla rete interna (qui su interfaccia eth0), necessario per queli protocolli che si basano su broadcast per funzionare correttamente (può essere utile per sfogliare reti Windows)
/etc/ppp/options.pptpd
contiene i parametri ppp da utilizzare ed è quello dove è più importante prestare attenzione ad alcuni dettagli che determinano quali metodi di autenticazione e protocolli di criptazione utilizzare.
In particolare per definire se usare il protocollo mppe e il metodo di autenticazione esistono due diverse sintassi a seconda della versione del pppd installata a disposizione (notare che questo di fatto è un file di configurazione del ppp e di come negoziare la connessione ppp fra server e client).
La sintassi vecchia, che vale per il fork mppe compatibile di ppp 2.4.1, prevede parametri come:
-chap Rifiuta autenticazione CHAP
-mschap Rifiuta autenticazione MSCHAP
+chapms-v2 Forza l'uso di autenticazione basata su MSCHAP v2
mppe-128 Imposta supporto mppe con cifratura a 128 bit
mppe-stateless Abilita mppe in modalità stateless
(Questi sono quelli che forzano MSCHAP2 e mppe e sono compatibili con le impostazioni standard delle VPN Windows).
La sintassi nuova, valida per ppp 2.4.2 e successivi prevede, sempre per i parametri di default per client Windows:
refuse-pap Rifiuta autenticazione PAP (plaintext)
refuse-chap Rifiuta autenticazione CHAP
refuse-mschap Rifiuta autenticazione MSCHAP
require-mschap-v2 Forza l'uso di autenticazione basata su MSCHAP v2
require-mppe Imposta supporto mppecon cifratura a 128 bit
nomppe-stateful Abilita mppe in modalità stateless
Altri parametri generalmente usati, comuni a tutte le versioni, sono:
lock Crea un file di lock per il server pppd. Nel dubbio, lasciarlo.
debug Abilita il debug della connessione, di solito si trovano i log in /var/log/messages
name nome_server Imposta il nome del server pptd. Deve coincidere con quanto scritto in /etc/ppp/chap-secrets
mtu 1500 Imposta l'MTU dei pacchetti
auth Richiede l'autenticazione del client. Necessario su un server ppp
proxyarp Imposta sul server una arp entry con l'IP assegnato al client, necessario per rendere quest'ultimo visibile agli altri host nella lan del server.
nobsdcomp Disabilita compressione BSD
ms-wins 10.0.0.150 Imposta l'IP del server WINS da assegnare ai client
ms-dns 10.0.0.150 Imposta l'IP del server DNS da assegnare ai client
Le login e le password utilizzabili per i collegamenti vanno scritte in /etc/ppp/chap-secrets
la cui sintassi è semplice, preve una riga per utente, con i seguenti dati separati da un tab: nome utente, nome del server (specificato con l'opzione "name" in /etc/ppp/options.pptpd), password (in chiaro!) e eventuale IP da cui il client può collegarsi (usare * per non imporre restrizioni). Ad esempio:
pippo nome_server pippo_password *
Se si è compilato pptp con il supporto smbauth, è possibile autenticare gli utenti via samba, con una configurazione tipo
* nome_server &/etc/samba/smbpasswd *
E' inoltre possibile autenticare gli utenti usando un server radius, per dettagli consultare la documentazione sul sito ufficiale.
FIREWALLING E NETWORKING
Ogni client connesso crea una nuova interfaccia sul server, chiamata ppp0
per il primo, ppp1
per il secondo e via dicendo.
A livello di firewalling si devono quindi considerare diversi aspetti:
- deve essere abilitato il traffico, nella catena di FORWARD, fra la rete interna del firewall e queste interfacce pppX. Ovviamente si possono configurare le limitazioni che servono (accesso solo a determinati host interni ecc.).
- L'interfaccia esterna del vpn server deve permettere l'accesso, dall'IP del client, alla porta tcp 1723 (per l'autenticazione) e il protocollo di trasporto GRE (ip type 47) per il tunnel.
- L'ip forwarding deve essere abilitato sul kernel.
Un esempio essenziale di configurazione delle iptables su un VPN server dove eth0 è l'interfaccia interna e l'eth1 è quella esterna può essere (qui vengono previsti solo due collegamenti ppp contemporanei):
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -p tcp --dport 1723 -i eth1 -j ACCEPT
-A INPUT -p gre -i eth1 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -i ppp0 -j ACCEPT
-A FORWARD -i ppp1 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
COMMIT
In genere, per qualsiasi VPN server che per natura deve essere accessbile da arbitrari IP esterni e avere una interfaccia su una rete interna, non è il massimo avere le porte su cui si negozia il tunnel sempre accessibili. Al riguardo valutare soluzioni di port knocking che aprano la possibilità di accedere solo a determinate condizioni.
LINK: PoPTop Home Page - http://www.poptop.org/
SSH |
Il protocollo, i server, i client. OpenSSH |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-10-03 17:28:37
La suite di Openssh nasce dal gruppo (ma non solo) che sviluppa OpenBSD, ha come scopo la sostituzione di tutti quei comandi intrinsecamente pericolosi come telnet, rcp poiche' il traffico passa in chiaro (comprese le nostre preziosissime password) con comandi e tools che implementano protocolli criptati considerati sicuri come SSH protocol
versione 1.3, 1.5 e 2.0.
Lo sviluppo della suite e' gestita da due team, uno che si focalizza sullo sviluppo del codice in ambiente OpenBSD ed un secondo che si preoccupa del porting della suite su altri OS.
Anche se lo sforzo e' notevole (Updates,patchs non mancano di certo ed escono con una certa frequenza) molto spesso affiorano problemi di sicurezza non indiferrenti (Addirittura Troyan nei sorgenti) che richiedono un immediato patching. La suite di Openssh include:
ssh
Per la sostituzione di telnet e rlogin
scp
Per la sostituzione di rcp
sftp
Per la sostituzione di ftp
sshd
Il comando per lanciare un server ssh.
Inoltre sono fornite utility per la gestione delle chiavi pubbliche e private. (ssh-add ssh-keygen
...).
Di sicuro la sua portabilita', facilita' di installazione e l'innumerevoli features lo rendono il mezzo piu' utilizzato al mondo per aprire conessione in quelle reti non considerate trusted.
Ecco alcune features:
Open Source Project Il codice sorgente e' disponibile a tutti, con tutti i vantaggi del caso.
Free Licensing La suite openssh non ha una licenza ristrettiva e puo' essere utilizzata anche per scopi commerciali.
Strong Encryption Openssh utilizza algoritmi come 3DES e Blowfish per una miglior e sicura compressione dati.
X11 Forwarding (encrypt X Window System traffic) Permette la compressione del traffico di un remoto X windows, quindi possiamo esportare sul nostro display senza preoccuparci di una possibile intercettazione della nostra password
Port Forwarding (encrypted channels for legacy protocols) Ci permette di forwardare le connessioni TCP/IP standard su una macchina remota attraverso canali sicuri ovvero criptati. Ad esempio il POP si potrebbe rendere sicuro in questo modo.
Strong Authentication (Public Key, One-Time Password e Kerberos Authentication) Molteplici tipi di autentificazione robusti.
LINK: Sito ufficiale - http://www.openssh.org
HOWTO: VPN PPP-SSH Mini-HOWTO - http://ldp.openskills.info/HOWTO/ppp-ssh/index.html
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-09-21 11:47:01
Avendo disposizione i sorgenti possiamo modificarli a nostro piacimento, cosi abbiamo la possibilita' di nascondere, modificare la versione per rendere difficoltoso lo scouting delle informazioni.
Inoltre e' bene modificare alcuni parametri del demone.
Nella directory dei sorgenti vi e' un file chiamato version.h
, il quale definisce semplicemente la versione del package.
$ cat version.h
#define SSH_VERSION "OpenSSH_3.4p1"
Modificate il valore OpenSSH_3.4p1 in quello che volete, salvate il file e compilate come meglio credete.
Potete verificare il vostro operato facendo un semplice telnet sulla porta 22:
$ telnet 0 22
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
SSH-2.0-CORE 1.0
in questo caso la versione e' CORE 1.0 (ovviamente dopo aver modificato i sorgenti)
Nel vostro /var/log/messages
se incontrate entry simili a queste significa che avete subito uno scan sulla porta 22 per identificare la versione del package di Openssh:
Sep 10 21:02:52 morpheus sshd[10190]: Did not receive identification string from 10.0.0.100
Esistono tools che fanno un probe sulla porta 22 per identificare che versione di openssh si ha installato sul proprio server
Inoltre e' bene "correggere" alcuni valori di default del demone sshd, in sshd_config
modificare:
Limitare al solo protocollo 2, intrinsecamente piu' sicuro
Protocol 2
Limitare il listening solo sulle interfacce da cui effettivamente devono avvenire le connessioni
ListenAddress 10.0.0.1
Aumentare il serverKeyBits almeno a 1024, valido solo per il protocollo 1
ServerKeyBits 1024
Aumentare il livello di logging
LogLevel INFO
Non permettere il login come root e con password empty
PermitRootLogin no
PermitEmptyPasswords no
Inoltre e' bene filtrare le connessioni da ip considerati trusted o tramite iptables oppure tramite tcpwrappers se il package e' stato compilato per il supporto di questa feature.
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-10-01 19:29:09
Server della suite di Openssh.
Puo' essere configurato per girare sia come server standalone, sia come servizio gestito da inetd o xinetd con tutti i vantaggi del caso. (Es: tcpwrappers)
Qualunque sia la sua modalita' di avvio, la configurazione del demone e' gestita tramite il file sshd_config il quale racchiude tutte le opzioni che possono essere passate anche in linea di comando.
Di seguito vengono riportate le opzioni piu' utilizzate:
sshd [-dtiq] [-b bits] [-f config_file] [-h host_key_file] [-p port]
-d
Abilita il debug mode, il server invia i messaggi in stdout e non permette al server di girare in background, e' possibile aumentare la verbosita' aggiungendo altre "d" fino ad un max di 3.
-t
Test mode, verifica il file di configurazione ela validita' delle chiavi senza far partire il servizio.
-i
Flag specifico per identificare, che il servizio parte da inetd.
-q
Abilita il quit mode, solo alcuni messaggi vengono loggati
-b
Specifica il numero di bits della key server per il protocollo 1
-f config_file
Specifica il file di configurazione. Default /etc/ssh/sshd_config
-p
Specifica la porta, dove il server rimarra' in Listenig. Default 22
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-09-21 09:48:01
Directory (rpm standard) ove risiedono i file di configurazione e i file contenenti le chiavi private e pubbliche della suite openssh.
Altrimenti, se la suite e' stata compilata da sorgenti senza passargli nessun parametro, il path standard e' /usr/local/etc.
Vale per qualsiasi sistema *Unix
Esempio di un ls -l della directory /etc/ssh:
-rw-r--r-- 1 root root 1110 Feb 25 2002 ssh_config
-rw------- 1 root root 1773 Jul 4 17:47 sshd_config
-rw------- 1 root root 668 Nov 2 2001 ssh_host_dsa_key
-rw-r--r-- 1 root root 590 Nov 2 2001 ssh_host_dsa_key.pub
-rw------- 1 root root 515 Nov 2 2001 ssh_host_key
-rw-r--r-- 1 root root 319 Nov 2 2001 ssh_host_key.pub
-rw------- 1 root root 883 Nov 2 2001 ssh_host_rsa_key
-rw-r--r-- 1 root root 210 Nov 2 2001 ssh_host_rsa_key.pub
ssh_config e' il file di configurazione del client ssh il quale contiene le opzioni utilizzate di default con il comando ssh.
# Host *
# ForwardAgent no
# ForwardX11 no
# RhostsAuthentication no
# RhostsRSAAuthentication yes
# RSAAuthentication yes
# PasswordAuthentication yes
# FallBackToRsh no
# UseRsh no
# BatchMode no
# CheckHostIP yes
# StrictHostKeyChecking yes
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_dsa
# IdentityFile ~/.ssh/id_rsa
# Port 22
# Protocol 2,1
# Cipher blowfish
# EscapeChar ~
sshd_config e' il file di configurazione del demone sshd:
Porta tcp da bindare
Port 22
I protocolli con cui negoziare la connessione
Protocol 1,2
Su quale ip rimanere in ascolto
#ListenAddress 0.0.0.0
Elenco dei file contenenti le varie chiavi
HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
Indica il numero di bit per la chiave lato server per il protocollo 1
ServerKeyBits 1024
Tempo in secondi per chiudere la connessione quando un utente non si e' ancora loggato
LoginGraceTime 600
Il tempo in secondi per la rigenerazione della chiave lato server, protocollo 1
KeyRegenerationInterval 3600
Permette o meno il login come root
PermitRootLogin yes
#
# Don't read ~/.rhosts and ~/.shosts files
Specifica l'utilizzo o meno dei file .rhosts e .shosts quando si utilizza
IgnoreRhosts yes
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
ignora o meno il contenuto del file $HOME/.ssh/known_hosts per RhostsRSAAuthentication e HostbasedAuthentication.
#IgnoreUserKnownHosts yes
Abilita o meno il check dei permessi della home dell'utente e del suo contenuto prima di abilitare l'utente al login
StrictModes yes
Abilita o meno i il forwarding dei pacchetti di X
X11Forwarding no
Specifica il primo numero del display disponibile
X11DisplayOffset 10
Visualizza al login il contenuto di /etc/motd
PrintMotd yes
Visualizza alcune informazioni sull'ultimo login effettuato sulla macchina
PrintLastLog no
Mantiene attiva la connessione (lato server)
KeepAlive yes
Opzioni per il Logging
SyslogFacility AUTHPRV
LogLevel DEBUG
#obsoletes QuietMode and FascistLogging
Abilita o meno RhostsAuthentication
RhostsAuthentication no
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
Abilita o meno RhostsRSAAuthentication
RhostsRSAAuthentication no
# similar for protocol version 2
Abilita o meno HostbasedAuthentication
HostbasedAuthentication yes
Abilita o meno SAAuthentication
RSAAuthentication yes
# To disable tunneled clear text passwords, change to no here!
Abilita o meno PasswordAuthentication
PasswordAuthentication yes
Permette di l'utilizzo o meno le password empty
PermitEmptyPasswords no
# Uncomment to disable s/key passwords
#ChallengeResponseAuthentication no
# Uncomment to enable PAM keyboard-interactive authentication
# Warning: enabling this may bypass the setting of 'PasswordAuthentication'
#PAMAuthenticationViaKbdInt yes
# To change Kerberos options
Opzioni per kerberos
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no
# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes
Verifica la presenza di mail nella mailbox dell'utente che si e' loggato
#CheckMail yes
Utilizzo o meno del login in alcune situazioni particolari
#UseLogin no
Specifica il numero delle connessioni non autentificate da droppare
#MaxStartups 10:30:60
Visualizza il contenuto del file
#Banner /etc/issue.net
Verifica o meno del reverse del'ip da cui provenie la connessione
#ReverseMappingCheck yes
Configurazioni per i subsystem esterni
#Subsystem sftp /usr/libexec/openssh/sftp-server
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-10-03 18:04:53
Directory contenente le chiavi pubbliche e private e file di configurazione del singolo utente
Ecco il classico contenuto della directory
[neo@dido neo]$ ls -l .ssh/
total 28
-rw-r--r-- 1 neo neo 456 Jun 4 15:30 configure
-rw------- 1 neo neo 736 Jul 4 15:02 identity
-rw------- 1 neo neo 736 Jul 4 15:02 identity.pub
-rw------- 1 neo neo 736 Jul 4 15:02 id_dsa
-rw-r--r-- 1 neo neo 598 Jul 4 15:02 id_dsa.pub
-rw------- 1 neo neo 736 Jul 4 15:02 id_rsa
-rw-r--r-- 1 neo neo 598 Jul 4 15:02 id_rsa.pub
-rw-r--r-- 1 neo neo 15463 Sep 13 12:14 known_hosts
-rw-r--r-- 1 neo neo 3931 Jun 24 12:25 known_hosts2
In particolare avremo:
identity / identity.pub File contenenti le chiavi private e pubbliche di tipo rsa per il protocollo 1
configure File di configurazione del client ssh del singolo utente. La struttura del file e' uguale a quello generale che di default e' .../ssh/ssh_configure
id_dsa / id_rsa File contenente le chiavi private dell'utente per il protocollo 2
id_dsa.pub / id_rsa.pub File contenente le chiavi pubbliche dell'utente per il protocollo 2
know_host / know_host2 File che ha la funzone di db per i vari host key dei server a cui ci si collega. rispettivamente per il protocollo 1 e 2
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-09-21 09:41:58
Client per il login o lancio di comandi da remoto attravero la suite di ssh.
ssh [-l login_name] [hostname | user@hostname] [command]
ssh [-afgknqstvxACNPTX1246] [-c cipher_spec] [-e escape_char] [-i identity_file] [-l login_name] [-m mac_spec] [-o option] [-p port] [-L port:host:hostport] [-R port:host:hostport] [hostname | user@hostname] [command]
-l
Specifica il nome dell'utente con cui aprire la connessione sull'host remoto.
user@hostname
Come sopra
-f
Manda in background ssh prima di lanciare il comando
-i [identity_file]
Specifica il file contenente la chiave privata (rsa e dsa)
-v
Abilita il verbose mode.
-x
Disabilita x11 forwarding
-X
Abilita x11forwarding
-C
Richiede la compressione dati
-1
Forza l'uso del protocollo 1
-2
Forza l'uso del protocollo 2
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-09-21 09:39:59
Secure copy, permette di copiare file, directory da host remoti utilizzando il protocollo ssh.
Utile anche per backup o restore veloci, valida alternativa a ftp soprattutto se si considera la criptazione del traffico.
comando [opzioni] [argomenti]
scp [-pqrvC46] [-S program] [-P port] [-c cipher] [-i identity_file] [-o option] [[user@]host1:]file1 [...] [[user@]host2:]file2
-p
Preserva alcune opzioni sul file, come access time, modification time etc..
-r
Recursive mode
-v
Verbose mode
-P
Specifica la porta a cui connettersi sull'host remoto
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Francesco 'nadal' Dal Molin - Ultimo Aggiornamento: 2003-10-09 21:26:32
L'uso delle chiavi con SSH permette di eseguire un login senza dover digitare la password con questi due vantaggi:
1- Sicurezza: si fa a meno di usare le password che possono essere indovinate o rubate.
2- Si possono effetture collegamenti in "batch" e quindi scrivere script che prevedono un collegamento ssh.
1. Generazione sul client delle chiavi pubblica e privata:
[utente_cli@client]$ ssh-keygen -t rsa
(è possibile evitare di digitare la passphrase)
2. Invio della chiave pubblica al server
[utente_cli@client]$ scp ~/.ssh/id_rsa.pub utente_ser@server:
3. Sul server inserire il contenuto di id_rsa.pub appena trasferito in /home/utente_ser/.ssh/authorized_keys2
:
[utente_ser@server]$ cat id_rsa.pub >> .ssh/authorized_keys2
(Questo comando va eseguito sul server)
Da ora in poi se ci si connette al server partendo dalla shell dell'utente che ha trasmesso la chiave non verrà chiesta la password e funziona l'opzione "-o BatchMode=yes" (necessaria se usiamo il comando in uno script)
NOTA: Se la password viene ancore richiesta, provare a controllare sul server in /etc/ssh/sshd_config l'opzione "StrictModes": inserire
StrictModes no
e far ripartire il servizio sshd.
L'opzione a "yes" (default su molte distro) dice al server sshd di non accettare la connessione con la chiave pubblica se la home dell'utente e il file authorized_key hanno permessi diversi da 700 (per la dir) e 640 (per il file). Spesso però sui server le home degli utenti di un certo gruppo sono leggibili dagli utenti appartenenti al gruppo.
(F)AQ: La chiave crittografica di ssh non funziona -
HOWTO: Gestione chiavi con ssh -
(F)AQ: La password viene ancora richiesta: Fai chmod 600 di .ssh/authorized_keys2 -
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Francesco 'nadal' Dal Molin - Ultimo Aggiornamento: 2003-10-09 21:07:02
A volte si ha la necessità di collegarsi ad un server che sta dietro un firewall e quindi non è raggiungibile.
Col comando qui sotto è possibile creare un tunnel dal server (dietro il firewall) al client attraverso cui far passare in senso contrario la connessione al servizio che ci occorre, in questo caso 'telnet'.
Sul server lanciare il comando per creare il tunnel fino al nostro client:
$ ssh -f -N -R 2333:localhost:23 [email protected]
2333 porta usata sul client
23 porta del servizio sul server (telnet)
guest è un utente presente sul client
80.100.100.100 indirizzo IP (su internet) del client
Il server si collega con il client usando ssh e gli dice di redirigere le richieste alla porta 2333 sul client alla porta 23 del server.
Se va tutto bene verrà chiesta la password per accedere sul client come utente guest (a meno che ci sia autenticazione con chiave criptata).
Ora sul client è possibile collegarsi via telnet al server:
$telnet localhost 2333
Il comando è utile se il tunnel viene mantenuto attivo e quindi è possibile sfruttarlo, quindi attenzione ai tempi di Timeout di ssh (V. configurazione SSH).
SOURCE: Articolo su Inter.Net -
Fonte: OpenSkills.info | Rilasciato sotto licenza Creative Commons Attribuzione - Non commerciale - Condividi allo stesso modo. |