Linux - Introduzione e InstallazioneIl variegato mondo Linux. Obiettivo: |
Storia di un pinguino e altri animali liberiStoria di Unix e Linux. Il modello OpenSource. GPL e licenze aperte. Statistiche sulla diffusione. Kernel, dialetti e distribuzioniIl kernel. I dialetti Unix. Le distribuzioni Linux. Partizionamento di un sistema LinuxLa struttura del filesystem. Fdisk e diskdruid. Policy di partizionamento. Installare LinuxRaccolta informazioni. Scelta dell'hardware. Definizione degli obiettivi. Opzioni di installazione. |
Primi passi su un sistema LinuxLe procedure di login e logout. Obiettivo: |
Login sul sistema, utenti normali e rootProcedure di login e logout. Root e altri utenti. Acceso remoto via telnet. Introduzione alla interfaccia testuale: la shellDefinizione di shell. Panoramica delle shell più diffuse. Introduzione alla bash. Introduzione all'interfaccia grafica: X Window SystemIntroduzione all'uso e alla comprensione delle interfacce grafiche a finestre di Linux Istruzioni e documentazione su LinuxLe risorse online [siti e mailing list , Libri e riviste] - Man, info, /usr/docs Linux SoftwareRisorse e informazione su dove trovare software per Linux |
File e FilesystemLa gestione dei file e delle directory. La gestione dei filesystem. Visualizzare file. Obiettivo: |
Gestire file, directory e linksCapire, muoversi e modificare file e directory: /, .., . , cd, ls, cp, mv, rm, rmdir, mkdir. Uso di link e symlink. Leggere e visualizzare fileComandi per visualizzare e leggere file: cat, less, more, tail, info, strings. Gestione dei file systemI principi e i comandi per gestire un file system: mount, df, du, fsck, mkfs. Attributi e permessiLa gestione di attributi e permessi sui file: chmod, chown, chgrp. Ricerca, confronto e filtriRicerca nel file system: find, locate. Confronto e verifica di file: diff, md5sum. Filtri di output: grep, wc, sed, awk. |
Processi e uso evoluto della shellUtilizzo più evoluto della shell. Regular expressions. Introduzione allo shell scripting. I processi e i job. Obiettivo: |
Ambiente shell e scriptingL'ambiente shell e lo scripting: variabili d'ambiente, cicli, strutture base. I processiDefinizione e gestione dei processi. Segnali e job. Debugging dei processiStrumenti e indicazioni su come eseguire il debugging delle applicazioni: strace, lsof, ldd. |
Il processo di bootIl dettagli sul processo di boot: dal BIOS all'avvio dei servizi. Obiettivo: |
Il processo di bootDescrizione del processo di boot su sistemi Intel: ROM BIOS - LINUX LOADER - KERNEL LOADING - INIT Linux loaders: LILO, GrubInstallazione e configurazione di LILO, GRUB e altri Linux loader Init e runlevelsInit, i runlevel e la gestione dei servizi da avviare al boot. |
Amministrazione del sistemaLe attività comuni di un sistemista: gestione degli utenti, installazione di programmi, schedulazione, backup, gestione e analisi dei log. Obiettivo: |
Gestione degli utentiI file che gestiscono gli utenti: /etc/passwd, /etc/group, /etc/shadow. I comandi per gestire gli utenti: adduser, passwd, userdel. Installare programmi su Unix e LinuxUtilizzo di RPM per installare, aggiornare, rimuovere pacchetti .rpm. Utilizzo di tar.gz Backup e compressione di fileTecniche di backup. L'uso di tar, gunzip, e altri comandi di compressione. Schedulazione dei processiUtilizzo di crontab e at. Configurazione e alternative a crontab. Gestione e analisi dei logAnalisi, monitoring, rotazione e gestione dei log di sistema. Configurazione di syslogd. |
InternetworkingConfigurazione, gestione e controllo del networking. Introduzione al firewalling. Gestione dei servizi Internet. Obiettivo: |
Networking - ConfigurazioneConfigurare i parametri di rete e il DNS: ifconfig, route, resolv.conf Networking - DiagnosiI comandi e le tecniche per diagnosticare la rete: netstat, arp, tcpdump. Networking - Tool comuniI comandi comuni per utilizzare la rete: finger, ftp, nslookup, dig, lynx, wget. Il superdemone Inetd (e Xinetd)Configurazione di inetd e tcp wrappers. Configurazione di xinetd. |
Assegnazione di IP e nomi in una LANIN questo capitolo si valutano le possibilità di usare Linux come server DHCP e come DNS resolver per una rete interna Obiettivo: |
DHCP serverProtocollo, installazione, configurazione ed uso di un server DHCP (ISC) Installazione e gestione di BINDInstallazione di BIND tramite RPM e sorgenti, file installati e posizioni. Gestione del servizio. Configurazione di BINDConfigurazione di BIND - In particolare la versione 9.x |
Gestione e hardening del sistemaSi presentano i principali strumenti grafici di gestione di un sistema e viene dettagliata una completa procedure di system hardening post-installlazione. Obiettivo: |
Aggiornamento di un sistema LinuxI metodi e le tecniche per l'upgrade manuale e automatico di un sistema Linux Tool grafici per l'amministrazione del sistemaLe alternative grafiche alla command line per la gestione e configurazione di sistemi Linux / Unix. Webmin e altri tool grafici. Esempi di configurazione di IptablesEsempi di configurazioni di un firewall Linux con iptables Linux post-installation check-listOperazioni da compiere su un sistema Linux dopo averlo installato dal CDROM. Security fixes e patches. |
Usare SambaAnalisi della configurazione di Samba, gestione del servizio, reperimento documentazione. Utilizzo si Samba in ambienti misti. Obiettivo: |
File sharing in una rete localeVisione d'insieme sul file sharing in LAN e le alternative possibili Il protocollo CIFS/SMBCommon Internet File System / Server Message Block Installazione e gestione di SambaInstallazione di Samba tramite RPM e sorgenti, file installati e posizioni - Gestione del servizio Documentazione e tool di configurazione di SambaManuali, libri, documentazione online, risorse e tool grafici di configurazione su Samba Configurazione di SambaFile di configurazione e settaggio dei parametri base e avanzati. SMB troubleshootingUtilizzo dei log, del debug e di altri strumenti di diagnosi. Stampa e condivisione stampantiLa stampa su Linux e la condivisione delle stampanti in rete. Reti miste Windows - LinuxCasi e situazioni comuni con rete miste Windows-Linux - WINS - PDC. Samba securityBreve rassegna della security history, problematiche attuali |
Mail server in una rete localeLe problematiche e gli utilizzi di un server di posta interno. Obiettivo: |
Il protocollo SMTPSimple Mail Transfer Protocol: sintassi base Installazione e gestione di SendmailInstallazione di Sendmail tramite RPM e sorgenti, file installati e posizioni. Gestione del servizio Configurazione di SendmailFile di configurazione e settaggio dei parametri di Sendmail PostfixInstallazione, configurazione, gestione Soluzioni AntivirusRassegna delle soluzioni antivirus server based Meccanismi Anti-SpamVerifica relay e implementazione di sistemi anti-spam FetchmailOverview e approfondimenti su fetchmail |
Apache Web ServerIntroduzione ai server web e al protocollo http. Obiettivo: |
Il Web e i server WebDefinizione del Web, visione d'insieme sui server disponibili, statistiche. I protocolli HTTP e HTTPSHyperText Transfer Protocol: sintassi, headers, URI e methods. Introduzione a HTTPS. Installare e compilare APACHEInstallazione e upgrade di Apache tramite package e sorgenti. Principi di configurazione di ApachePrima analisi di httpd.conf, settaggio dei parametri base. Tool grafici per la configurazione. Gestione del servizio httpdAvvio, chiusura, verifica del servizio, opzioni di invocazione. Manuali, libri, risorse online su ApacheDocumentazione e risorse su Apache. Monitoring di ApacheServer-status, server-info, uso di netstat, top, vmstat, ldd, lsof, strace. Environment variables. Analisi e gestione dei log httpdConfigurazione, analisi e gestione dei log di un server Web. Software di analisi dei log. Elementi base della configurazione di ApacheLe direttive per la gestione della configurazione: IfModule, IfDefine, Include, Options e Overrides. Default index e directory listingsGestione della visualizzazione di directory. Definizione index predefiniti. Configurazione di VirtualHostConfigurazione di Virtual Hosts named based e ip based. Apache performance tuningSuggerimenti e informazioni per migliorare le performance di Apache. Design di una infrastruttura WebDesign della rete, dei server, dei servizi. |
Condivisione dell'accesso ad InternetConoscere e implementare le soluzioni di accesso condiviso ad Internet con Linux Obiettivo: |
Linux firewalling: Introduzione a IptablesOverview, gestione, utilizzo di iptables su Linux per packet filtering iptables - Linux natting e packet manglingUtilizzo di iptables per natting, masquerading e mangling di pacchetti. SQUID Proxy serverInstallazione e configurazione del proxy server Squid Traffic monitoringTools per il monitoraggio del traffico IP |
Principi di sicurezza su LinuxVisione d'insieme e approfondimenti sul mondo della sicurezza Linux: Le problematiche, i riferimenti, la documentazione, le minacce, gli strumenti di difesa, i software OpenSource più comuni. Obiettivo: |
Link e documentazione sulla securityLibri, risorse, siti sulla sicurezza Introduzione alla sicurezzaIntroduzione alle problematiche di sicurezza su Internet Network sniffing: strumenti e tecnicheTeoria e pratica sulla subdola arte dello sniffing. Anti-sniffer tools. Arp spoofing e tecniche di prevenzione. Network scanning: strumenti e tecnicheStrumenti e tecniche di network e vulnerability scanning. Information gathering. Passwords e password crackingScelta di password sicure e metodi di password cracking. Linux e la sicurezza fisicaProblematiche di sicurezza su server fisicamente non protetti 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 VPNLe soluzioni VPN disponibili su Linux. Teoria e implementazione. Disaster recoveryBackup e disaster recovery |
Linux, da alcuni chiamato GNU/Linux, è un sistema operativo dalle caratteristiche uniche:
- si può liberamente utilizzare, senza pagare licenze d'uso,
- si può liberamente adattare alle proprie esigenze e, sapendo come, modificare,
- è realizzato da un numero imprecisato di persone, società, enti distribuiti su tutto il pianeta,
- è un colossale progetto condiviso di sviluppo software.
- funziona bene, sia su server che su computer desktop.
Linux è composto da un kernel, il cui sviluppo è coordinato da Linus Torvalds, da vari tool e programmi del progetto GNU e da altri software rilasciati con licenze Open Source e in vario modo "impacchettati" dai produttori delle varie distribuzioni.
Approfondimenti in: Kernel, dialetti e distribuzioni
La sua storia è legata a quella del software libero ed è popolata da protagonisti i cui nomi, nell'ambiente, sono piuttosto noti.
Per ragguagli consultare: Storia di un pinguino e altri animali liberi
L'installazione di Linux è ormai una pratica semplice grazie al lavoro svolto dalle varie, diverse, distribuzioni, con cui Linux si può presentare.
Procedure e riferimenti in: Installare Linux
Le uniche, minime, complicazioni si possono avere quando si deve installare Linux su un sistema in cui si vuole mantenere Windows.
In questo caso è necessario avere delle partizioni libere su cui operare e il processo di ripartizionamento del sistema può, per i neofiti, comportare preoccupazioni e problemi.
Per approfondimenti: Partizionamento di un sistema Linux
Storia di un pinguino e altri animali liberi |
Storia di Unix e Linux. Il modello OpenSource. GPL e licenze aperte. Statistiche sulla diffusione. |
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-21 19:32:37
La storia di Linux è la storia del più colossale progetto di sviluppo condiviso di software di tutti i tempi.
Sotto la direzione di Linux Torwalds quello che inizialmente doveva essere un programma sviluppato ad uso personale è diventato il più noto risultato di un modello di sviluppo basato sulla disinteressata collaborazione di migliaia di sviluppatori tramite Internet.
E' una storia relativamente breve, perchè in campo informatico tutto accade velocemente e perchè la collaborazione creativa di tante persone, se ben coordinate, ha un potenziale enorme.
Luglio 1991 - Agli occhi della Rete, tutto inizia in un'estate finlandese, Linus Benedict Torvalds, ancora un giovane studente dell'Università di Helsinki, si informa su Usenet:
"Hello netlanders, Due to a project I'm working on (in minix), I'm interested in the posix standard definition. Could somebody please point me to a (preferably) machine-readable format of the latest posix rules? Ftp-sites would be nice." Torvalds giustificherà poi la folle impresa con queste parole: "I couldn't afford some of the commercial OSes and I didn't want to run DOS or Windows -- I don't even know, did Windows really exist then?".
5 Ottobre 1991 - Nello stesso anno viene rilasciata la versione 0.02. Il post su usenet che ne annuncia la presenza è diventato un classico.
Gennaio 1992 - Viene rilasciata la versione 0.12. Risulta relativamente stabile e supporta vario hardware.
Da questa versione in poi la crescita di Linux inizia a diventare progressiva e dirompente, sia come numero di coder che supportano lo sviluppo, sia come utilizzatori."Earlier kernel releases were very much only for hackers: 0.12 actually worked quite well"
Aprile 1992 - Rilasciate la versione 0.95 e 0.96. Il salto è diretto dalla 0.12. Nascono le prime distribuzioni: la MCC Linux e la SLS.
1994 -Viene rilasciata la prima versione definitiva 1.0. Nascono RedHat, Debian, SUSE tutt'ora fra le distribuzioni più diffuse. Linux, che resta Copyrighted by Linux Torvalds, diventa ufficialmente un software aperto, abbracciando in pieno la General Public License (GPL) del movimento Free Software di Stallman.
Grazie all'aumento esponenziale dell'interesse da parte della comunità mondiale nascono i primi LUGs (Linux User Groups), ormai diffusi anche in Italia.
1995 - Compaiono sul mercato nuove distribuzioni commerciali come Caldera Linux. Kernel 1.2 out in Marzo. Dal kernel 1.3 in sviluppo si passerà direttamente al 2.0
1996 - Rilasciata la versione 2.0. Compaiono le prime versioni tradotte in più lingue.
Linux ha bisogno di una mascotte: nasce TUX, il pinguino più famoso del mondo.
1997 - Da qui in poi la storia di Linux diventa sempre più Linus indipendent, che nel 1997 lascia la Finlandia per raggiungere Santa Clara, Silicon Valley, dove lo aspetta, nella misteriosa start-up Transmeta, un ruolo che ai più non è chiaro.
Per anni, prima di annunciare al pubblico di produrre microprocessori a basso consumo e quotarsi al NASDAQ, Transmeta rimane un segreto impenetrabile intorno al quale si accumulano rumours e misteri:
- E' la società dove lavora Linus Torvalds (che continua a sviluppare Linux e non si capisce per cosa venga pagato)
- Fra i soci finanziatori figura Paul Allen (Microsoft co-founder)
- Assume programmatori e tecnici di altissimo livello
- Sfoggia per anni una home page che è un capolavoro di anti-marketing.
1999 - Dopo lunga attesa il kernel 2.2 vede la luce, un passo avanti notevole. Nel pieno del boom della new economy si quotano al Nasdaq con successo società che basano il loro business interamente su Linux come RedHat, Va Linux e Caldera (che, paradossalmente, dopo alcuni anni, movimenti societari e il cambio di nome in Sco Group, diventerà uno dei peggiori nemici del pinguino).
2001 - Agli inizi dell'anno, dopo varie pre-version, su kernel.org appare l'immagine da 19.788.626 byte del 2.4.0 La prima release di un altro stable thread, con un maggiore e più ampio supporto di hardware di livello enterprise.
2002 - Linux è una reale alternativa al mondo Microsoft e Unix, si ritrova milioni di utenti, migliaia di sviluppatori e un mercato in espansione.
E' presente in sistemi integrati, è usato per il controllo di dispositivi robotizzati e ha volato a bordo dello Shuttle, praticamente gira su oggetti elettronici di tutti i tipi, dai palmari alle workstation Alpha, risultando l'OS in assoluto il sistema operativo più soggetto a porting.
Nessuno ormai si sogna di considerarlo un progetto sperimentale che non possa essere usato in applicazioni mission-critical, IBM "lo monta sui suoi server" (e lo pubblicizza pure), Microsoft lo considera il principale nemico da combattere (e non lesina risorse nel farlo), Oracle ci fa girare sopra il suo DB.
2003 - Le guerre si combattono per il petrolio e, più sotterraneamente, per il controllo dei computer. Il 2003 sarà ricordato anche per l'anno di SCO e dei suoi attacchi a Linux e al mondo OpenSource, consequenziali ad una azione legale intrapresa contro IBM.
Le modalità degli attacchi, la loro natura, il modo con cui si cerca creare FUD intorno a Linux (Fear Uncertainty and Doubt) sono sintomo di interessi che vanno oltre la protezione di presunte proprietà intellettuali per parti di codice che vengono nominate ma non mostrate sembrano delinearsi come un banco di prova decisivo per la definitiva affermazione di Linux anche sul lato desktop e per un cambio paradigmatico su come viene valorizzato e diffuso il software.
Tecnologicamente la strada è chiara e le carte sono vincenti: Linux e tutto il software OpenSource sono decisamente all'altezza sia sui sistemi di fascia alta che sui desktop, oltre ad essere presente nel cuore invisibile di innumerevoli device elettronici.
2004 - Sgonfiato, anche se non concluso, il caso SCO, nuove minacce si profilano all'orizzonte di un pinguino che continua a diffondersi e conquistare nuovi territori: in particolare leggi draconiane sui brevetti, che permettono di brevettare indiscriminatamente algoritmi, soluzioni e idee informatiche triviali e ambiamente diffuse, o soluzioni tecniche tali da rendere impossibile o soggetta a una fee arbitraria l'interoperabilità fra sistemi operativi.
Intanto il kernel 2.6 si diffonde e viene usato nelle principali distribuzioni, sempre più user friendly e pronte per il desktop. E' una guerra, più o meno dichiarata, i cui i nemici spesso mostrano una faccia sorridente e colpiscono su campi e livelli che non hanno nulla a che vedere con l'innovazione e l'eccellenza tecnica.
(F)AQ: Come è nato Linux? -
LINK: Linux Kernel History (beginnings) - http://ftp.cdut.edu.cn/pub2/linux/kernel/history/Master.html
SOURCE: "Rivoluzionario per caso" di Linus Torvalds e David Diamond. -
GOOGLE: linux history -
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-03-27 22:41:32
Nel 1985 Richard Stallman, ex ricercatore del MIT, fondò la Free Software Foundation (FSF), finanziata prevalentemente da donazioni, alla cui base c'era il progetto GNU, che ambiva alla realizzazione di un sistema operativo free, libero di essere usato, studiato, modificato, distribuito.
Il software free, rilasciato con la GNU General Public Licence (GPL), in questo contesto, implica:
- Ridistribuzione Libera del software e del codice
- Il Codice Sorgente è disponibile per lettura, modifiche, analisi, controllo
- Chiunque può prendere del software libero e modificarlo come vuole, ma deve mantenere per il suo prodotto derivato la licenza GPL
- Il Copyright del software appartiene all'autore. Chi ne fa modifiche deve segnalare la fonte.
- Libero, free, non significa necessariamente gratis. Chiunque può vendere software free o servizi correlati al prezzo che vuole.
Linux è il più famoso progetto GNU, di fatto è composto dal kernel di Torvalds e da molte altre utility e programmi di base, ispirate agli equivalenti Unix.
Spesso associato al concetto di free software è quello di OpenSource le differenze sono apparentemente sottili ma ben precise. L'Open Source è stato definito e si è diffuso in tempi successivi per definire software rilasciato con modelli di licenza che permettono l'accesso e la modifica del codice sorgente.
Si basa su logiche pragmatiche, mentre il Free Software (così come descritto nella GPL) ha radici più etiche e filosofiche, anche se non escludono la commercializzazione e la vendita.
Per l'OSI (Open Source Initiative) si dovrebbe rilasciare il codice del proprio software perchè è una scelta sostenibile e valida, che ne aiuta la diffusione e il miglioramento, per la FSF il codice dovrebbe essere aperto per rispettare la libertà degli autori e degli utenti. Non esiste inoltre una licenza di riferimento dell'OSI, come può essere la GPL per la FSF, ma un elenco di licenze considerate compatibili per essere definite OpenSource.
Fra i fondatori dell'OSI figura Eric Raymond noto fra l'altro per aver scritto il libro/manifesto "The Cathedral and the bazaar" il cui percorso editoriale è emblematico su cosa può essere un modello di business basato sull'open source: il libro è liberamente disponibile, nella sua interezza, in rete e chiunque può leggerlo ma l'autore ha venduto i diritti di pubblicazione su carta alla O'Reilly (che ne vende parecchie copie).
LINK: Definizione di Free software - http://www.gnu.org/philosophy/free-sw.it.html
LINK: Definizione di Open Source - http://opensource.org/docs/osd-italian.html
LINK: Sito Ufficiale della Free Software Foundation - http://www.fsf.org/
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Luca 'pillolinux' Bove - Ultimo Aggiornamento: 2004-05-21 19:33:35
Uno degli aspetti più confusionari del fenomeno open source é la proliferazione di differenti licenze che regolano la proprietà intellettuale e la distribuzione del software. In questo articolo presenteremo una piccola guida sulla terminologia utilizzata nelle licenze che accompagnano i vari software free. In particolare illustreremo i seguenti termini:
->Software Proprietario
->Shareware
->Freeware
->Free Software
->Public Domain Software
->GNU General Public License (GPL)
->GNU Lesser General Public License (LGPL)
->Open Source
->Community Source
Software Proprietario
E' il modello di licenza più tradizionale per il software commerciale: nessuna persona ha il permesso di esaminare il codice sorgente per il prodotto. L'unica eccezione è un cliente disposto a pagare un cifra, spesso esorbitante, come "tassa" per avere a disposizione il codice sorgente. Ma anche se comprate il codice sorgente per tale prodotto, non potrete pubblicarlo o sarete fuorilegge poiché la licenza per il codice sorgente proprietario non può essere ceduta. E inoltre i vostri diritti di modificare il codice sorgente per meglio adattarlo alle vostre esigenze sono ristretti.
Shareware
Con la licenza Shareware, il modello tradizionale è (leggermente) rovesciato. Vale la filosofia "prima prova, poi paga". Il software è distribuito gratuitamente, e ve lo potete passare l'un l'altro. Gli utenti dei prodotti shareware sono poi legalmente tenuti a pagare un compenso allo sviluppatore per la registrazione; questo compenso alcune volte è libero altre volte è predeterminato. Una variante di questa licenza, chiamata "crippleware" (si potrebbe tradurre software "storpiato"), fa in modo che il software non abbia tutte le funzionalità abilitate sino a quando non viene pagato il compenso per la registrazione. Un'altra tipica variante è la shareware a scadenza: il programma funziona solo per un determinato periodo di tempo, la durata viene estesa solo se viene pagato il compenso.
Il codice sorgente non è tipicamente incluso con i programmi.
Free software
Il free software (software libero) è il software in cui si ha pieno accesso al codice sorgente. Esiste una vera e propria organizzazione politica che ne difende i diritti: il Movimento per il Free Software (http://www.fsf.org). Sotto il modello di licenza "free software" è un vostro sacrosanto diritto usare il software, modificarlo e ridistribuirlo con ogni mezzo a disposizione. Ma è anche possibile far pagare dei soldi per la distribuzione.
Comunque, dietro a questi diritti ci sono dei doveri: tutte le modifiche devono essere accessibili a tutti e nessuno può restringere i diritti di distribuzione libera.
La maggior parte dei sostenitori del free software, crede che l'informazione, e specialmente il codice sorgente, debba essere libera. Nei paesi di lingua inglese la parola "free" racchiude i termini di libero e di gratis, e si usa dire che il free software va inteso come "libero discorso" ("Free Speech") e non come "birra gratis" ("Free Beer"). I seguaci del Free Software difendono la frase principale della copyleft che recita: "coloro che ridistribuiscono il software, con o senza modifiche, devono lasciare intatta la libertà di effettuare ulteriori copie e modifiche" ("anyone who redistributes the software, with or without changes, must pass along the freedom to further copy and change it").
Software di Pubblico Dominio
Il software di pubblico dominio è sia software gratis (freeware) che free software, ma meno restrittivo. Esso può essere usato, modificato o ridistribuito con ogni mezzo. Però voi siete liberi di fare cambiamenti al software e rendere tali modifiche proprietarie. Potete anche scegliere di far pagare il codice o i suoi derivati senza fornire alcun accesso al codice sorgente. In ogni modo, chiunque può fare uso (e abuso) di software di pubblico dominio, senza consultare alcun uomo di legge.
GNU General Public License (GPL)
Dal 1984, lo scopo del progetto GNU è stato di sviluppare un ambiente UNIX completo che comprenda la licenza dei free software.
Sebbene una parte del codice utilizzato nel progetto GNU ricada nell'ambito del pubblico dominio, la grande maggioranza ha licenza GPL. GPL è una specifica implementazione del copyleft, gioco di parole che indica il contrario di copyright:
right=destra left=sinistra ma anche right=diritto left=permesso, quindi copia permessa.
Il software copyleft deve essere libero, deve includere il codice sorgente e deve essere modificabile e ridistribuibile senza limitazioni. La GPL proibisce i brevetti proprietari relativi alla modifica del software, proibisce le royalties e richiede che gli stessi termini di libera distribuzione siano allegati quando si ridistribuisce il software o anche derivazioni di esso. Per questo motivo la licenza è anche conosciuta come "licenza virus". Questa licenza non è ristretta solo ai progetti GNU, chiunque può creare del software e rilasciarlo con questa licenza.
Ad esempio il popolare compilatore GNU e gli strumenti associati hanno licenza GPL. Questo significa che tutti coloro che effettuano dei miglioramenti al compilatore GNU devono poi dare il nuovo codice alla comunità. E' importante comunque notare che questo non significa che il software costruito con il compilatore debba essere free.
Quindi e' legale utilizzare uno strumento free software per produrre software proprietario.
GNU Lesser General Public License (LGPL)
La LGPL è usata come licenza per il free software in modo che quest'ultimo possa essere incorporato sia nel software free sia in quello proprietario. Si puo' dire che sia il fratellastro più debole della GPL.
Le regole sono sostanzialmente le stesse, tranne una: è eliminato l'obbligo che le proprie estensioni al software siano aperte. In questo modo i componenti LGPL rimangono sempre free software, ma possono essere inclusi in un pacchetto software proprietario.
La GPL è stata progettata per scoraggiare la creazione di software proprietario e incoraggiare il free software. Se volete costruire il vostro codice intorno a una libreria o pacchetto GPL, sarete poi costretti a dare il codice sorgente delle vostre modifiche. Questo non è un problema con un pacchetto LGPL, come la libreria GNU C, che può essere legalmente inclusa in un software proprietario.
Questa licenza viene in genere utilizzata per le librerie, che sono sfruttate nella produzione di software.
Ricapitolando il software GPL non può essere incluso in software proprietario, mentre quello LGPL si. In entrambi i casi si possano comunque utilizzare (ma con la GPL non includere) in prodotti proprietari.
Open Source
Questo termine ha creato molta confusione. Sebbene abbiamo iniziato l'articolo con questa parola, non c'é alcuna chiara definizione per "software open source" e nessuna licenza standard. Diverse società usano il termine "open source" in modi completamente diversi. L'idea è simile a quella del free software (si può generalmente usare, modificare e ridistribuire il software), ma c'é poca enfasi sui diritti del software di essere libero. Questo perché le grandi società mostrano grandi riserve quando si tratta di perdere il controllo del loro software. C'é anche una definizione di Open Source che si può trovare a http://www.opensource.org (la traduzione italiana si trova in http://www.apogeonline.com/openpress/op_definition.html ). Nonostante la proliferazione di diverse licenze che rientrano nella cerchia dell'Open Source (una lista completa si può trovare in http://www.opensource.org/licenses ), in genere esse si avvicinano più alla licenza LGPL piuttosto che alla GPL. In altre parole se utilizziamo del software Open Source, lo possiamo in genere includere in codice proprietario.
Riguardo questa classe di licenza c'é stato un ampio dibattito tra i sostenitori del puro Free Software e quelli del più generico Open Source. In questo momento sembra prevalere quest'ultimo.
SOURCE: PILLOLINUX: Piccola guida alle licenze - http://www.freeonline.it/articolo_linux_dtml?id_articolo=32
LINK: Linux Information Sheet - http://ldp.openskills.info/HOWTO/INFO-SHEET.html
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2006-03-24 10:01:21
Non essendoci dati di vendita centralizzati è difficile valutare la diffusione di Linux.
Informazioni e indicazioni utili ma incomplete vengono date da Linux Counter, dove viene fatto un censimento (su base volontaria) sul numero di utenti Linux: nel Marzo 2006 risultano 138056 utenti registrati e 153627 macchine registrate.
Questa stima è ovviamente per difetto (la registrazione viene fatta sul sito stesso e molti che usano Linux nemmeno sanno della sua esistenza).
Il gestore di questo sito (ovviamente un Linux enthusiast) stima intorno a 29 milioni il numero effettivo di utenti Linux, sulla base di statistiche, proiezioni e analisi varie.
Altro indicatore interessante è Netcraft, che, pur senza fare riferimento a singoli OS, da indicazioni utili sui server Web utilizzati in rete. Qui domina Apache (che può girare sia su Unix vari che su Windows) con 51.810.676 siti web pari al 69,01% dei server web totali analizzati.
Ricerche varie fatte in passato sulla diffusione di Linux nel mondo danno risultati diversi:
- IDC ha stimato 1.300.000 server Linux consegnati nel 1999 e ha previsto uno share del 4% su totale dei computer sul desktop nel 2004.
- Dataquest ben più prudenzialmente stima in 543.778 il numero di server Linux consegnati nel 2001.
A titolo di curiosità Google, nel Maggio 2004 conta circa 115.000.000 pagine contenenti la parola Linux (erano nel 50.500.000 Gennaio 2002 e 64.300.000 nel Settembre 2003). Per confronto la parola Windows appare in 121.000.000 pagine (erano 65.900.000 a Settembre 2003).
Sempre nel Maggio 2004 esistevano 629 Linux User Groups (LUG).
Comunque si vogliano considerare questi numeri il dato certo è:
- La crescita nella diffusione di Linux è innegabile;
- Il suo utilizzo in ambiti aziendale, corporate e accademico sempre maggiore;
- La conoscenza delle sue potenzialità è sempre più precisa e consapevole.
SOURCE: Linux Counter - Reports - http://counter.li.org/reports/
(F)AQ: Quanto è diffuso Linux? -
LINK: Statistiche web server usati su Netcraft - http://news.netcraft.com/archives/web_server_survey.html
LINK: Linux Statistics - http://www.linux-stats.org/
Tipo Infobox: ETCETERA - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-09-20 08:47:36
Linux non è l'unico sistema operativo Open source ma è sicuramente il più conosciuto.
Ne esistono molti altri in circolazione tra cui i dialetti *BSD (FreeBSD, OpenBSD, NetBSD) e GNU/Hurd, che costituisce il secondo sistema operativo "ufficiale" della FSF.
Lo stesso kernel di Mac Os X, Darwin, è open source (è basato su FreeBSD e Mach 3.0) ed esistono versioni open di sistemi del passato (ma non troppo) come Open BeOS o OpenVMS.
LINK: DMOZ: Sistemi operativi OpenSource - http://dmoz.org/Computers/Software/Operating_Systems/Open_Source/
Tipo Infobox: FUN - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-08-22 15:00:54
Il padre di tutti gli informatici con aspirazioni da giullare è sicuramente lui, Simon Travaglia, il grandioso Bastard Operator From Hell che scrive dalla Nuova Zelanda. Fin dal 1992 allieta i monitor di ogni tecnico, sistemista, operatore, smanettone con la BOFH saga.
Da quei tempi non ha più smesso.
Sempre bastardo, sempre lui.
L'emblema e il riscatto per una generazione di nerd, vittime di ogni relazione sociale ed eroi della tastiera.
Sull'home page ufficiale, ovviamente orribile, seguendo comodi link rossi su sfondo blu è possibile leggersi l'intera saga.
SOURCE: The Bastard Operator from Hell Official Archive - http://bofh.ntk.net/Bastard.html
LINK: Il primo POST su usenet di BOFH - http://groups.google.com/[email protected]
Kernel, dialetti e distribuzioni |
Il kernel. I dialetti Unix. Le distribuzioni Linux. |
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-03-23 18:20:13
Linux si presenta in multiformi e numerose distribuzioni, dai nomi a volte curiosi: Debian, Ubuntu, Mandrake, Fedora, Slackware che ormai sono noti e conosciuti da molti per quello che permettono di fare facilmente: installare un sistema Linux completo di software OpenSource in grado di placare la dieta informatica di ogni tipo di utente o sistemista.
Si consideri che il "Linux di Linus Torvalds" non è un sistema operativo completo come comunemente percepito, ma il semplice kernel, il cuore del sistema, che, a basso livello, si occupa della gestione diretta delle risorse hardware (CPU,memoria, dischi, interfacce, schede audio/video...).
Al kernel ogni distribuzione aggiunge tutto il software necessario per avere un sistema completo di programmi applicativi, utility e software lato server per gestire diversi servizi Internet.
Il panorama del software open source comunemente fornito in ogni distro prevede una grande varietà di programmi realizzati da persone, società ed organizzazioni diverse che riescono a interagire grazie a standard e librerie condivise.
Anche per questo molti preferiscono chiamarlo GNU/Linux poiché tutte le utility di base, dal gcc (compilatore di riferimento) alle utility tipiche del mondo Unix fanno parte del progetto GNU, ideato da Richard Stallman.
Le distribuzioni differiscono per:
- Numero e versioni dei programmi installabili;
- Versione del kernel utilizzata e modalità di pre-installazione (il kernel solitamente non viene compilato durante una normale installazione);
- Procedura di installazione (interfaccia utente e possibilità di definire opzioni e scegliere quale software installare);
- Organizzazione di file di configurazione, programmi, log nel file system;
- Configurazioni predefinite del software installato.
PRINCIPALI DISTRIBUZIONI
Red Hat
Red Hat è la più popolare distribuzione Linux e si adatta bene ad usi diversi (desktop, server, laptop) pur avendo una storia di sicurezza non certo esemplare. Pioniera nell'includere un meccanismo di update User Friendly e l'aggiornamento automatico tramite il RedHat Network. Ha introdotto il sistema di gestione di pacchetti software con estensione .RPM che facilita installazione e aggiornamento del software.
Fornisce due linee principali di prodotto:
Fedora, distribuzione completamente libera, aggiornata spesso e sviluppata in collaborazione con la community, con tempi di vita relativamente brevi.
Red Hat Enterprise Edition, versione commerciale, con supporto online per assistenza e aggiornamenti a pagamento, con tempi di vita lunghi e costo, non trascurabile, per singola licenza (in base alla possibilità di collegarsi al RedHat Network).
Debian
Distribuzione completamente sviluppata da una comunità che consta di migliaia di persone in tutto il mondo incarnando appieno lo spirito del Free Software. Fornisce un proprio sistema di pacchettizzazione simile all'RPM (pacchetti .DEB). Viene considerata per puristi ed esperti e risulta generalmente meno user-friendly e più stabile delle altre.
Ha tempi di vita decisamente superiori a quelli di altre distribuzioni free (spesso soggette ad aggiornamenti e cambi di versione frequenti) e per questo ben si presta per sistemi server dove la durata di vita del sistema è prioritaria rispetto alla necessità di software recente.
S.U.S.E.
Distribuzione nata in Germania, solida e ben accessoriata, RPM compatibile e user-friendly. Utilizza un software di gestione e configurazione (YAST) completo e piuttosto semplice, che può facilitare l'uso ad utenti non esperti.
Acquistata nel 2004 da Novell, Suse si propone come il più agguerrito concorrente commerciale di RedHat.
Viene fornita in diverse versioni:
Suse Linux Personal e Professional per il desktop (la versione Personal è liberamente scaricabile)
SuSE Linux Enterprise Server per ambienti enterprise, con costi di licenza superiori e supporto più duraturo.
Mandrake
In crescente diffusione, usa pacchetti simili a RPM (MDK) che sono aggiornati molto rapidamente. E' molto user friendly e probabilmente è una delle più adeguata per sistemi desktop. Prevede anche versioni server esplicitamente rivolte al mercato enterprise.
Slackware
Slackware è una delle prime distribuzioni, a differenza delle altre, è fortemente basata sulla attività di una singola persona, supportata comunque da una fedele comunità. Si distingue dalle altre per non usare package tipo RPM o DEB. E' essenziale nella sua logica e questo può essere gradito ai puristi e gli esperti ma risulta ostica per i principianti.
Gentoo
E' una distro relativamente recente ma a suo modo rivoluzionaria per il mondo Linux. E' fatta per essere compilata direttamente sul PC di installazione in ogni sua parte. Si basa su un sistema simile ai ports BSD basati su semplici file di testo con tutti i riferimenti su un programma/pacchetto in termini di nome, descrizione, caratteristiche, dipendenze e url per scaricare i sorgenti e procedure di compilazione.
E' decisamente per esperti, ma permette tuning e personalizzazioni notevoli.
Linspire
E' una delle distribuzioni più "commerciali", espressamente dedicata ad utenti non esperti che sono abituati a Windows. Incorpora e integra Wine e altri strumenti per rendere il sistema il più possibile simile a Windows, prevede un sistema di abbonamento online (Click'n'Run) tramite il quale si possono facilmente installare nuovi programmi. Non include nemmeno il compilatore gcc. Precedentemente chiamata Lindows ha dovuto cambiare nome in seguito a screzi legali con Microsoft.
ALTRE DISTRIBUZIONI
Il numero delle distribuzioni Linux supera le 300 unità, sviluppate in più di 50 nazioni diverse molte sono sfrozi collaborativi a livello mondiale), gli utilizzi sono svariati: molte sono "general purpose", alcune sono specifiche per il desktop, altre per il firewall, varie sono adatte per systemi embedded o incluse in network appliance di varia natura... Esistono inoltre distribuzioni specializzate per piattaforme non basate su processori Intel: PowerPC, sparc, alpha, motorola 68000, i390 e disribuzioni "Live" che possono essere utilizzate caricandole direttamente da un CDROM, senza installarle su Hard Disk.
Questo apparente caos e frammentazione, in realtà non devono fuorviare: le distribuzioni principali sono poche e da queste derivano gran parte delle altre, i punti in comune, inoltre, sono parecchi (kernel, software GNU, logica Unix, gerarchia del file system...) e un sistemista esperto non ha difficoltà a gestire una o l'altra.
LINK: Distro Watch - Il paradiso delle distribuzioni - http://www.distrowatch.com
LINK: Linux for Scratch - Come costruire il proprio sistema Linux da zero - http://www.linuxfromscratch.org/
LINK: Panoramica sulle distribuzioni disponibili - http://www.linuxhq.com/dist.html
HOWTO: English-language GNU/Linux distributions on CD-ROM - http://ldp.openskills.info/HOWTO/CD-Distributions-EN-HOWTO/index.html
LINK: Linux ISO torrents - http://www.linuxisotorrent.com/
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-03-23 20:06:05
Il kernel è il codice che gestisce le risorse presenti in un computer e le rende disponibili alle applicazioni con cui l'utente comunemente interagisce. In un sistema operativo, inteso in senso esteso, come può esserlo Windows completo di programmi accessori (Explorer, Internet Explorer, notepad e via dicendo), il kernel costituisce solo lo strato più profondo, quello che si occupa del "lavoro sporco" di interagire direttamente con l'hardware.
Il kernel si occupa principalmente di gestire:
- le comunicazioni con le memorie di massa (hard disk, floppy cdrom, dispositivi usb rimuovibili... ),
- i file system, cioè il modo con cui sono organizzate le informazioni sulle memorie di massa (fat, fat32, ntfs, ext3, reiserfs...),
- la memoria RAM, l'accesso dei singoli programmi alla stessa e il paging della memoria su hard disk,
- l'utilizzo della CPU e la condivisione della stessa fra i vari programmi,
- l'interfacciamento e la comunicazione con hardware vario (schede di rete, porte seriali, USB, parallele, schede audio, schede video ecc.
Le versioni del kernel Linux sono identificate con numeri a tre cifre separate da un punto (ed: 2.1.45) con una convenzione ben precisa.
Per esempio il kernel 2.4.15 ha:
2- Il major number, la serie principale. I kernel della serie 1.x sono ormai piuttosto vecchi e poco usati, quelli della serie 0.x sono ancora più vecchi e ormai rarità da collezionista (si fa per dire, dal sito ufficiale del kernel Linux sono ancora scaricabili.
4- Il minor number, il numero di versione principale. Se è pari il kernel viene considerato stable e pronto per sistemi in produzione, se è dispari lo si considera in development e da usare con cautela o per sperimentazione. Le release stable sono sempre figlie delle devel precedenti. Ad esempio il kernel attualmente considerato stabile, il 2.6, deriva dal 2.5 che era la versione in sviluppo mentre la 2.4 era quella considerata stabile. Solitamente nei kernel stable si tende a fare maintenance ed a implementare solo le feature strettamente necessarie, lasciando a quello in development lo sviluppo di nuove funzionalità.
15- E' la revisione (patch) corrente. Questo è un numero progressivo che parte da 0. Da una revisione alla successiva possono passare da pochi giorni a varie settimane.
Esistono inoltre varie patch temporanee, anche non di Torvalds stesso (comuni sono le -ac patch, di Alan Cox) che rappresentano stadi intermedi prima della release di una revisione definitiva.
Ha senso utilizzarle subito solo in caso di utilizzo di kernel con gravi problemi di sicurezza o stabilità (sul proprio sistema) che vengono risolte con le relative patch parziali.
Il kernel in development è attualmente composto da sorgenti realizzati da centinaia di programmatori e assemblati da Linus Torvalds che rilascia personalmente le nuove versioni.
Navigare e leggere il codice sorgente del kernel
Poter avere accesso completo al codice sorgente del proprio sistema operativo può essere per molti totalmente irrilevante ma per alcuni è una fonte inesauribile di studio, approfondimento e supporto allo sviluppo.
Esistono in rete progetti che favoriscono la possibilità di lettura ed analisi dei sorgenti di Linux, fra questi Cross-Referencing Linux.
E' un sito che permette il browsing all'interno del codice del kernel. E' particolarmente affascinante ed utile perchè, tramite una moltitudine di link, permette di correlare funzioni, variabili e strutture risultando piuttosto interessante, anche per il semplice curioso senza particolari cognizioni di programmazione in C.
Le discussioni sul kernel
Gli sviluppatori che affiancano Torvalds sono molti e tipicamente discutono e comunicano in una mailing list dedicata e piuttosto affollata: la linux-kernel mailing-list (è fortemente sconsigliato iscriversi, a meno che si sia direttamente coinvolti nello sviluppo del kernel.
Esistono in rete siti che riassumono le attività in corso sul kernel e le presentano in forme più accessibili a chi non è un kernel hacker:
Kernel Trap è un blog completo e aggiornato sugli sviluppi del kernel.
Kernel Traffic è una mailing list che riassume le principali discussioni su linux-kernel.
Kernel Newbies è un sito indicato per chi il kernel lo deve usare, compilare e imparare. Di fatto è il punto di partenza ideale per un sistemista Linux che vuole approfondire le sue conoscenze sul kernel.
LINK: Kernel Newbies - http://kernelnewbies.org/
LINK: The linux-kernel mailing list FAQ - http://www.tux.org/lkml/
LINK: Kernel traffic - http://www.kernel-traffic.org/
LINK: Cross Referencing Linux - http://lxr.linux.no/
LINK: Kernel Trap - http://kerneltrap.org/
LINK: Kernel.Org - Official Linux Kernel Site - http://www.kernel.org
Tipo Infobox: DISTRO - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-10-15 17:17:09
Questa è un sommario elenco dei prezzi delle varie distribuzioni Linux, così come esposti sui siti ufficiali.
Va vista come lista indicativa dell'offerta commerciale su Linux basata sui prezzi di listino online, ovviamente non comprende costi indiretti potenzialmente legati all'uso di Linux (assistenza, formazione, hardware ecc) e si riferisce alle versioni commerciali delle varie distribuzioni, dove generlamente viene fornito supporto e assistenza di livello enterprise.
Dove specificato "ISO Online" si indica che le relative ISO sono scaricabili da Internet (un buon sito è www.linuxiso.org ) e liberamente distribuibili.
Aggiornamento: 15 Ottobre 2004
Prezzi e condizioni possono essere riportati in modo inesatto o incompleto, si rimanda ai siti ufficiali per informazioni dirette.
REDHAT
http://www.redhat.com/apps/commerce/ - RedHat Store
Per i suoi prodotti commerciali RedHat offre diverse "edition" che fondamentalmente si differenziano per il livello di supporto, e diverse versioni per WorkStation o Server.
Esistono poi delle soluzioni per il desktop e per sistemi di managemnt e assistenza.
Red Hat Enterprise Linux WS (WorkStation) - Basic Edition: $179 - Standard Edition: $299
Red Hat Enterprise Linux ES (Enterprise Server) - Basic Edition: $349 - Standard Edition: $799
Red Hat Enterprise Linux AS (Advanced Server) - Standard Edition: $1499 - Premium Edition: $2499
RedHat Desktop - Proxy Starter Pack: $2500 (10 Licenze RedHat Desktop + Red Hat Network Proxy Server (include Red Hat Enterprise Linux AS, Premium Edition)
RedHat Desktop - Extension Pack: $3500 (50 Licenze RedHat Desktop aggiuntive)
SUSE
http://store.suse.com - SUSE Store
SUSE Linux 9.1 Professional: $89.95
SUSE Linux 9.1 Professional Update: $59.95
SUSE Linux 9.1 Personal: $29.95 - ISO Online
SUSE Linux Enterprise Server 9 - 2CPU: $389 - 16 CPU: $939
MANDRAKE
http://store.mandrakesoft.com/ - Mandrake Store
Su Mandrake Store esistono vari bundle che alla distribuzione base aggiungono hardware e gadget di varia natura. Vediamo i costi delle versioni essenziali, su CD o DVD e dell'inscrizione al Mandrake Club, da cui è possibile scaricare tutte le versioni desktop di Mandrake.
Mandrakeclub membership Silver 120,00 € / anno (Accesso alla PowerPack Edition e altri bonus)
Mandrakelinux 10.1 Community DVD: 54,00 € ISO Online
Mandrakelinux 10.0 PowerPack: 79,90 € (8 CD, versione completa di programmi accessori)
Mandrakelinux 10.0 Discovery: 44,90 € (2+1 CD, versione entry level)
MandrakeSecurity Multi-Network Firewall: 499,90 € (Firewall Enterprise)
Corporate Server 2.1 - Standard support: 749,90 € (Enterprise Server, esistono costi aggiuntivi per diversi livelli di supporto)
MandrakeClustering Pentium (1-16 CPU): 1.990,90 € (Versione per cluster enterprise)
LINSPIRE
Linspire fornisce il servizio online Click And Run (CNR) per rendere semplice l'aggiornamento e l'installazione di nuovi programmi. Questo servizio viene erogano tramite un abbonamento che può essere mensile o annuo e permette l'accesso anche ad ulteriori software commerciali per Linux (ai relativi costi).
Linspire 4.5: $59.95
Abbonamento CNR Warehouse: $49.95 / anno - (Servizio online di aggiornamento e gestione software)
SLACKWARE GENTOO DEBIAN e molti altri
Non esistono versioni commerciali di queste distribuzioni, è comunque possibile comprarne i CD dai siti ufficiali o da terzi, pagandone i materiali, il tempo e i costi di distribuzione in puro GPL style, in ogni caso questi contengono esattamente le stesse versioni scaricabili da Internet o reperibili in varie riviste del settore.
Tipo Infobox: TIPS - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2006-03-24 12:43:11
Scegliere la distribuzione giusta fra le centinaia disponibili è impresa ardua, come lo è ottenere una risposta precisa da un "esperto di Linux".
Inevitabilmente, da bravo informatico, risponderebbe "dipende".
In genere, la migliore distribuzione da usare è quella che meglio si conosce e se si devono gestire diverse macchine è opportuno averle tutte con la stessa distribuzione e possibilmente versione, per facilità e rapidità di aggiornamente e manutenzione.
Qualunque sia la distro adottata è spesso consigliabile installarne l'ultima versione disponibile (contiene pacchetti e kernel più recenti) lasciando possibilmente passare almeno un mese dalla sua release per permettere il fixing dei bug e dei buchi di sicurezza più evidenti.
Fondamentale è comunque seguirne sul relativo sito le segnalazioni di aggiornamenti ("errata" o "patch"), possibilmente attivando sistemi di autoaggiornamento dei pacchetti.
Considerare che dopo l'installazione di una qualsiasi distribuzione, se si sta lavorando su un server che deve andare in produzione, sono auspicabili, consigliati e necessari una serie di interventi di post installazione:
- Aggiornamento di tutti i pacchetti per i quali esistono degli errata (nuove versioni che aggiornano bug o buchi di quelle rilasciata con il CDROM originale);
- Rimozione di tutti i servizi Internet non utilizzati;
- Eventuale aggiornamento del kernel;
- Configurazione dei servizi di produzione che si intende utilizzare;
- Implemementazione di script o configurazioni custom.
Nella scelta della distribuzione vanno valutati i seguenti aspetti e date risposte alle seguenti domande:
- In che contesto viene utilizzata?
Su un server, su un laptop, un dekstop... A seconda delle funzionalità richieste può essere adeguata una distribuzione piuttosto che un'altra.
Ci sono distribuzioni come Ubuntu, Mepis, Linspire, Xandros che sono particolarmente orientate al desktop e si differenziano per facilità di utilizzo o presenza di programmi per Internet e il multimedia in grado di soddisfare le tipiche esigenze di un poweruser.
Per un firewall esistono distribuzioni dedicate che possono risultare particolarmente comode e semplici da configurare.
Per un server è opportuno cercare distribuzioni con tempi di vita lunghi e in grado di riconoscere e supportare il proprio hardware.
- Che tempo di vita mi aspetto da questa installazione?
Un computer desktop può essere reinstallato in tempi relativamente brevi, quantomeno per rincorrere le nuove versioni di vari programmi comuni, un server può richiedere tempi di vita molto maggiori e questo influenza la scelta.
Un vizio comune a molte distribuzione sono i tempi di release estremamente rapidi, tali da rendere apparentemente obsoleta una versione dopo pochi mesi dal suo rilascio.
Questo vale in modo evidente con Fedora (una release indicativamente ogni 6 mesi, fine del supporto ufficiale di RedHat dopo 2 release) ma anche, in misura minore, per le versioni Personal/Professional di Mandriva, Suse e altre fra le distribuzioni principali.
Questa costante rincorsa è dovuta al tumultuoso e rapido sviluppo di software opensource e al fatto che difficilmente all'interno della stessa versione di una distribuzione viene fatto un "major upgrade" dei programmi forniti (per garantire la piena compatibilità e il funzionamento delle procedure di aggiornamento automatico del software (per bug e vulnerabilità di sicurezza)).
Fra le distribuzioni liberamente accessibili, Debian e in misura minore Slackware si distinguono per tempi di vita decisamente superiori. Debian, in particolare, ha un ramo "stable" particolarmente conservativo che ha tempi di vita molto lunghi a scapito di una certa obsolescenza del software fornito.
Se la necessità è di avere un sistema Linux per poche ore o alcuni giorni (per dimostrazioni, corsi, prove, test, ecc) le Live CD come Knoppix sono particolarmente indicate, in quanto non richiedono nemmeno l'installazione su hard disk.
- Quanto sono disposto a spendere per la licenza del mio Linux?
Le versioni commerciali delle distribuzioni Linux hanno tempi di vita e supporto generalmente maggiori e sono adatte ad ambienti in cui è prioritario avere garanzia di supporto duraturo rispetto ai costi di licenza.
RedHat, Suse/Novell, Mandriva forniscono tutte versioni "enterprise" a pagamento delle proprie distribuzione con tempi di supporto di vari anni e durata di vita del software molto superiori alle versioni liberamente distribuite dagli stessi produttori.
Nella analisi dei costi, ovviamente, vanno anche considerati il training del personale, la consulenza di esterni, i tempi di disservizio eventualmente dovuti a guasti o problemi, ecc.
- La distribuzione che voglio usare supporta l'hardware che ho a disposizione?
Per quanto il supporto hardware su Linux sia piuttosto avanzato esistono casi in cui va opportunamente verificato. In particolare non tutte le distribuzioni sono in grado di riconoscere immediatamente i device di un laptop (winmodem, scheda wireless connettori infrarossi ecc.) e, per sistemi di fascia medio/alta con controller scsi è schede di retei in gigabit è opportuno verificarne il supporto nella hardware compatibility list del produttore della distribuzione.
Tipo Infobox: DISTRO - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-12-19 18:38:44
Esistono distribuzioni che si presentano come un "LIVE CD" che permette l'esecuzione sul proprio computer di un Linux completo, che viene caricato direttamente dal CD-ROM e non ha bisogno di essere installato su Hard Disk.
In questo caso l'hard disk può essere assente o venir utilizzato solo per creare file temporanei, ed eventuali dati dell'utente.
Simili Live CD, che ovviamente richiedono l'impostazione del CDROM come device di boot principale, possono essere utili per operazioni di disaster recovery e, soprattutto, per provare sulla propria macchina un Linux senza di fatto doverlo installare sull'Hard Disk.
Una interessante applicazione di un LiveCD è quella specificatamente dedicata all'utilizzo di una macchina Linux come firewall. In questi casi basta un Live CD, che viene caricato al boot, e un floppy da cui caricare le impostazioni e le configurazioni specifiche: al termine del caricamento si potrà avere un firewall basato su Linux particolarmente sicuro, in quanto non presenta la possibilità di scrivere file da alcuna parte e, fatte salve adeguate regole di packet filtering, risulta praticamente impermeabile a molti tipi di attacco.
Fra queste distribuzione una delle più complete, interessanti ed efficaci è Knoppix che condensa in un singolo CD, 2Gb di software compattato che può essere eseguito e scompattato on-the-fly, dopo un rapido boot (nell'ordine di 2 minuti, dal Bios ad un KDE completo) direttamente da CD, senza scrivere un byte su hard disk e con attime capacità di riconoscimento dell'hardware locale.
Consigliato a chi vuole provare Linux o deve farne dimostrazioni pubbliche.
LINK: DMOZ: Live CD Distributions - http://dmoz.org/Computers/Software/Operating_Systems/Linux/Distributions/Live_CD/
LINK: Live CD Italiana per Firewall / VPN Gateway - http://www.zeroshell.net/
Partizionamento di un sistema Linux |
La struttura del filesystem. Fdisk e diskdruid. Policy di partizionamento. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2009-02-23 02:17:06
Durante l'installazione di una distribuzione Linux viene richiesto come partizionare gli hard disk, definendo dimensioni e tipo di file system.
Non è necessario avere una partizione già predisposta prima i iniziare, la fase di definizione delle varie partizioni necessarie per Linux viene gestita dal tool di installazione, ma si deve avere dello spazio libero (hard disk libero, spazio non partizionato o una partizione esistente che si puà cancellare (e dividere nelle partizioni che servono a Linux))
Il minimo partizionamento richiesto prevede:
- una partizione generale ("/" , la root directory) in cui vengono copiati tutti i file.
- una partizione di swap (non contiente file e viene usata solo come Virtual Memory, quando si esaurisce la RAM)
E' comunque consigliabile, almeno su un server, utilizzare partizioni indipendenti per diverse directory.
La decisione su come suddividerle e quali dimensioni assegnargli dipende dalle specifiche necessità del sistema.
Considerare che un eccessivo partizionamento aumenta la possibilità di sfruttare male la capacità dell'hard disk e rischiare che alcune partizioni si riempano al 100%.
Queste sono alcune directory che ha senso tenere su partizioni indipendenti da quella dalla root ( / ).
- /boot (partizione di boot, dove risiedono kernel e file di boot. Con BIOS vecchi deve stare nei primi 1023 settori dell'hard disk. 100 Mb di spazio possono bastare)
- /var (partizione in cui vengono messi file che cambiano di dimensione, tipicamente i log. E' utile averla su partizione indipendente per evitare che un aumento dei log inattesi riempa tutto il filesystem. Farla almeno di 100 Mb)
- /home (dove risiedono i file di tutti gli utenti. Può essere piccola e praticamente inutilizzata (mail, dns server) o molto grossa e piena di documenti (web, file server). Dimensionarla a seconda dell'uso della macchina)
- /tmp dove risiedono file temporanei.
In fase di partizionamento, oltre a decidere come partizionare gli hard disk bisogna assegnare ad ogni partizione un mount point.
Per esempio se abbiamo un hard disk da 10 Gb come primary master e lo vogliamo dividere in 6 partizioni, potremo ottenere:
PARTIZIONE MOUNT POINT
/dev/hda1 /
/dev/hda2 /boot
/dev/hda3 /var
/dev/hda4 /home
/dev/hda5 /tmp
/dev/hda6 /SWAP
Notare che la partizione di SWAP non necessita di un mount point.
Per /dev/hda si intende l'hard disk Primary Master IDE. I numeri successivi indicano le partizioni all'interno dell'hard disk.
Gli hard disk IDE hanno i seguenti nomi:
Primary Master: /dev/hda
Primary Slave: /dev/hdb
Secondary Master: /dev/hdc
Secondary Slave: /dev/hdd
Le singole partizioni di un hard disk hanno nomi tipo:
- /dev/hda1 (prima partizione del primary master)
- /dev/hdc4 (quarta partizione del secondary master)
Considerare inoltre che si possono formattare le partizioni con un file system diverso.
Possiamo per esempio avere, nell'esempio sopra indicato, tutte le partizioni in ext3 (uno dei File System più usati su Linux) e la partizione /dev/hda4 ( dove viene montala la /home ) formattata in FAT 32 (File System di Windows 98, supportato anche da Linux).
Su una directory del filesystem Unix è possibile montare anche Network File System come SMB (Reti Windows) o NFS.
HOWTO: Linux Partition HOWTO - http://ldp.openskills.info/HOWTO/Partition/index.html
HOWTO: Linux Swap Space Mini-HOWTO - http://ldp.openskills.info/HOWTO/Swap-Space.html
Tipo Infobox: TIPS - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-12 21:01:20
Esistono vari programmi sia su Linux che su Windows per gestire le partizioni degli hard disk. Alcuni di questi si limitano a preparare le partizioni in modo da poterle formattare con il file system che verrà usato dal proprio sistema operativo, altri, dal compito più delicato ed evoluto, permettono di cambiare le dimensioni di partizioni esistenti (senza danneggiarne i dati), in modo da creare spazio per nuove partizioni.
Durante l'installazione di Linux viene richiesto come partizionare i(l) propri(o) hard disk, in modo da definire cosa formattare e dove installare il sistema operativo, se preservare le eventuali partizioni esistenti (contenenti altri OS) o ripulire completamente gli hard disk.
Va considerato che se non si intende cancellare nulla e se non esistono hard disk o partizioni liberi, l'installazione non può essere eseguita, a meno che non si scelga la strada (non sempre disponibile) di installare Linux su una partizione Windows esistente.
Linux - Gli strumenti più usati per gestire il partizionamento su Linux sono:
- Fdisk - Diffuso tool testuale, simile all'analogo su Windows, che offre opzioni avanzate per il partizionamento.
- Diskdruid - Tool grafico fornito da RedHat, semplice ed intuitivo, è una alternativa funzionale a fdisk se non si ha bisogno di funzionalità avanzate. E' accessibile solamente durante la fase di installazione di RedHat.
- Parted - Oltre alle normali operazione di creazione e visualizzazione della partition table, questo programma permette di modificare le dimensioni di partizioni esistenti, anche formattate con file system non nativi Linux. E' fondamentale per liberare spazio su un hard disk completamente partizionato.
Windows offre una vasta scelta di soluzioni commerciali e alcuni strumenti free:
- Partition Magic - E' il software, commerciale, di gestione di partizioni più conosciuto e probabilmente più evoluto. Permette di ridimensionare, senza cancellare dati, partizioni formattati con tutti i più diffusi file system.
Alternativamente, esistono analoghi prodotti commerciali come: 7tools Partition Manager, Paragon Hard Disk Manager (assai simile). Hanno il vantaggio di funzionare sotto Windows ma la loro versione demo, generalmente, NON permette la modifica delle partizioni.
- Fips - Software free che permette il ridimensionamento di partizioni esistenti. Ha funzionalità essenziali e spesso è fornito con le distribuzioni Linux per creare spazio per una installazione. Basato su DOS.
- Ranish Partition Manager - Alternativa valida a Fips. E' anch'esso OpenSource e basato su DOS, pur avendo un'interfaccia testuale a finestre.
LINK: Linux Partition Mini HOWTO - http://www.tldp.org/HOWTO/mini/Partition/
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-08-14 11:24:17
Tool testuale con la possibilità di operazioni avanzate per il partizionamento e la manipolazione della partition table degli hard disk.
Presenta un'interfaccia a menu con la quale è possibile creare, visualizzare, modificare le partizioni del device specificato.
fdisk [ -l ] [ -v ] [ -s partition] [ device ]
device
Specificando solo il nome di un device (es: /dev/hda ) entra nella modalità menu per modificare la partition table del device
-l
Mostra la partition table degli harddisk del sistema. Per ogni device indica le partizioni, la dimensione in blocchi, il filesystem e i cilindri utilizzati
SOURCE: Man Pages - http://man.openskills.info/fdisk
Tipo Infobox: ETCETERA - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-08-14 20:48:25
Su sistemi Windows lo swapping viene fatto su un file dedicato ("pagefile.sys"), presente nel normale file system mentre su Unix e Linux si dedica una partizione autonoma, che viene formattata indipendentemente.
Anche su Windows FDISK è il nome del più comune strumento per partizionare gli hard disk.
La versione per Windows è diversa e meno flessibile ma prevede le stesse funzioni di base.
LINK: Usare FDISK su Windows - http://support.microsoft.com/support/kb/articles/Q255/8/67.ASP
Installare Linux |
Raccolta informazioni. Scelta dell'hardware. Definizione degli obiettivi. Opzioni di installazione. |
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2006-03-23 12:01:19
L'installazione di Linux è ormai una operazione piuttosto semplice, visto il progresso evidente che molte distribuzioni hanno avuto negli ultimi anni in termini di facilità d'uso.
Nonostante questo esistono alcune informazioni fondamentali che vanno conosciute, in particolare per i casi in cui si intende installare Linux su un computer dove è già installato, e si vuole mantenere, Windows.
Sapere com'è il proprio sistema, come e dove si vuole installare Linux, nel caso sia presente già un altro sistema operativo, è fondamentale, per cui è bene assicurarsi, prima di procedere, di conoscere le informazioni di base riguardo a:
- Hardware a disposizione. Solitamente durante l'installazione il proprio hardware viene rilevato automaticamente, ma possono esserci rari casi in cui questo non accade. In genere se si usa un PC standard con una nuova distribuzione non ci sono problemi nel riconoscimento di componenti e periferiche.
- Sapere quali e quanti Hard Disk sono presenti sul sistema, come sono partizionati, quali sono cancellabili. Queste informazioni sono visualizzabili durante l'installazione, ma si deve essere certi di sapere dove sono i dati (per esempio, una installazione di Windows esistente) che non si vogliono cancellare.
- Configurazione di rete, se prevista (indirizzo IP, subnetmask, nome macchina, server DNS).
- Il tipo di attività che si intende fare con Linux (si userà come workstation o come server? si installa su un portatile? Si ha idea di quale software si vorrà usare?).
Gli scenari possibili sono vari, dipendono dalle singole situazioni e possono riassumersi in questi casi generali:
- Installazione su un computer esclusivamente dedicato a Linux (con o senza dati presenti sull'hard disk, che comunque si intende cancellare). Questo è il caso più semplice e se si ha a che fare con hardware non particolarmente esotico (normale PC, di marca, o assemblato, con processore Pentium o superiore) non dovrebbe creare alcun problema con una distribuzione recente.
- Installazione su un PC dove è già presente Windows e si ha a disposizione un hard disk libero o una partizione completamente libera all'interno dell'hard disk con Windows. Anche in questo caso l'installazione può procedere senza particolari problemi: durante le sue fasi verranno evidenziate le partizioni presenti sull'hard disk e sarà possibile decidere di utilizzare per Linux quelle libere, senza toccare quelle in cui si trova Windows.
- Installazione su un PC dove è presente Windows e non è disponbile un hard disk aggiuntivo, spazio non partizionato o una partizione sacrificabile. Questo purtroppo, oltre ad essere il caso più ostico, per un normale computer domestico, è anche il più comune. In queste situazioni si possono seguire diverse strade:
-- Provare Linux con un Live CD (come Knoppix) che permette di usare Linux senza installarlo sull'harddisk, eseguendo il boot direttamente dal CDROM. Non è una soluzione definitiva (un sismile approccio ha degli inevitabili limiti e minori performance) ma può essere un ottimo modo per iniziare a familiarizzare con Linux senza alcun bisogno di installarlo e in completa sicurezza.
-- Procurarsi un hard disk aggiuntivo (di 1 GB o più) e aggiungerlo al proprio PC (indicativamente come Secondary Master, lasciando Windows sul Primary Master) per poterlo usare liberamente con Linux.
-- Creare dello spazio sull'hard disk esistente: se si hanno partizioni quasi vuote, spostare i dati presenti, in altre partizioni Windows e "sacrificare" la partizione semi-vuota per l'installazione Linux; alternativamente considerare la possibilità di usare strumenti come Fips o Partition Magic per Windows o Parted per Linux (lanciato da un Live CD) per ridurre la dimensione delle partizioni esistenti e creare spazio per Linux.
Fare massima attenzione a simili procedure: se fatte in modo scorretto o interrotte (per esempio da un blackout) possono definitivamente compromettere i dati presenti sul proprio hard disk. Un backup preventivo dei propri file, seppur di solito non necessario, è generalmente consigliato.
-- Installazione su PC con hardware particolare o architetture non basate su processori tipo Intel o AMD (i386).
In questi casi la procedura di installazione può essere più complicata (per la richiesta di driver aggiuntivi per gestire l'accesso al disco) o non riconoscere alcuni dispositivi e schede (per esempio i modem interni).
Se si vuole installare Linux su Mac o sistemi con architettura non Intel-like, sono necessarie distribuzioni particolari e procedure a volte più complesse.
HOWTO: The Linux Installation HOWTO - http://ldp.openskills.info/HOWTO/Installation-HOWTO/index.html
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-09-20 11:13:35
Una scelta importantissima è quella della configurazione hardware, dal numero di interfacce di rete al numero di processori, dalla dimensione dei dischi fissi a quanta ram utilizzare.
Ormai Linux offre una vasta compatibilità con la maggior parte dell'hardware esistente, sia direttamente a livello di kernel ufficiale, sia con driver rilasciati direttamente dai produttori, inoltre, per il vero hacker, avendo a disposizione i sorgenti del kernel, c'è sempre la possibilità ultima di scriversi autonomamente i propri driver.
Segue un breve quadro sulla scelta dell'hardware, si rimanda ai link indicati per informazioni più dettagliate:
CPU
Le distribuzioni standard contengono un Linux predisposto per processori Intel Based a 32 bit. (dal 386 al Pentium 4 Intel, oltre a compatibili quali AMD Athlon, Cyrix, Transmeta ecc.) Se si vuole installare Linux su un Mac, una Sun o un Compaq Alpha si deve trovare una distribuzione per PowerPC, Sparc o Alpha.
La potenza del processore dipende ovviamente dalle applicazioni usate, un Pentium 2 o superiore basta per normali applicazioni server senza eccessivo carico. Esiste il supporto multiprocessore.
RAM
Come sempre, più ce n'è, meglio è. Se si usa Linux senza interfaccia grafica, le esigenze sono modeste: 64Mb bastano per un sistema base, ma sono ovviamente da aumentare per server che devono gestire volumi di traffico medio/alti o ospitare applicativi pesanti.
HARD DISK
La scelta fra un sistema (E)IDE o SCSI dipende essenzialmente dal budget a disposizione. In genere, prima di pensare ad un sistema SCSI è opportuno "carrozzare" la macchina con un buon processore e abbastanza memoria. Il supporto per schede SCSI è ottimo.
CDROM - FLOPPY
Un normale CD-ROM IDE o SCSI basta e avanza (di fatto, per un server, serve solo in fase di installazione). Il floppy può mancare se la motherboard supporta il boot direttamente dal CD (funzione comune in tutte le motherboard non vecchie). E' disponibile il supporto di CD-RW.
SCHEDA VIDEO
Per un server (su cui si avrà soltanto l'interfaccia a caratteri) basta una semplice VGA. Per un desktop con interfaccia visuale il minimo è una SVGA.
E' disponibile l'accelerazione 3D su schede che supportano OpenGL.
SCHEDA RETE
Si consiglia una scheda ethernet 10/100. Esistono driver per alcune schede gigabit, ma è opportuno verificarne l'esistenza per il proprio hardware.
Esiste anche il supporto per Token Ring, schede wireless e WAN cards.
ACCESSORI MULTIMEDIALI
Per un server non sono necessarie schede audio o accessori multimediali. I kernel dalla 2.4 in su, comunque supportano le Sound Blaster Live e Audigy, schede audio meno recenti e le periferiche USB. Esiste anche il supporto Firewire.
MODEM
I modem esterni (analogici o ISDN) su interfaccia seriale (meglio) o USB sono normalmente utilizzabili.
Possibili complicazioni esistono per modem interni (Winmodem), che in genere sono sconsigliabili e tipicamente si trovano su portatili.
LINK: Un sito completo sul Linux Hardware - http://www.linuxhardware.net/
LINK: Linux Hardware Database su ZDNET - http://lhd.zdnet.com/
HOWTO: The Linux 3Dfx HOWTO - http://ldp.openskills.info/HOWTO/3Dfx-HOWTO.html
HOWTO: Framebuffer HOWTO - http://ldp.openskills.info/HOWTO/Framebuffer-HOWTO.html
HOWTO: i810 with XFree86 4.x HOWTO - http://ldp.openskills.info/HOWTO/i810-HOWTO/index.html
HOWTO: Nvidia OpenGL Configuration mini-HOWTO - http://ldp.openskills.info/HOWTO/Nvidia-OpenGL-Configuration/index.html
HOWTO: ATI R200 + XFree86 4.x mini-HOWTO - http://ldp.openskills.info/HOWTO/XFree86-R200/index.html
HOWTO: Brief Introduction to Alpha Systems and Processors - http://ldp.openskills.info/HOWTO/Alpha-HOWTO.html
HOWTO: CPU Design HOW-TO - http://ldp.openskills.info/HOWTO/CPU-Design-HOWTO.html
HOWTO: The Elite's K7s5a mainboard HOWTO - http://ldp.openskills.info/HOWTO/K7s5a-HOWTO.html
HOWTO: Linux/MIPS HOWTO - http://ldp.openskills.info/HOWTO/MIPS-HOWTO.html
HOWTO: SPARC-HOWTO. - http://ldp.openskills.info/HOWTO/SPARC-HOWTO.html
HOWTO: CD-Writing HOWTO - http://ldp.openskills.info/HOWTO/CD-Writing-HOWTO.html
HOWTO: The Linux CD-ROM HOWTO - http://ldp.openskills.info/HOWTO/CDROM-HOWTO/index.html
HOWTO: Linux DVD HOWTO - http://ldp.openskills.info/HOWTO/DVD-HOWTO.html
HOWTO: Linux - Optical Disk HOWTO - http://ldp.openskills.info/HOWTO/Optical-Disk-HOWTO.html
HOWTO: The Linux keyboard and console HOWTO - http://ldp.openskills.info/HOWTO/Keyboard-and-Console-HOWTO.html
HOWTO: Remote Serial Console HOWTO - http://ldp.openskills.info/HOWTO/Remote-Serial-Console-HOWTO/index.html
HOWTO: Linux ATA RAID HOWTO - http://ldp.openskills.info/HOWTO/ATA-RAID-HOWTO/index.html
HOWTO: Linux DPT Hardware RAID mini-HOWTO - http://ldp.openskills.info/HOWTO/DPT-Hardware-RAID.html
HOWTO: Jaz-drive HOWTO - http://ldp.openskills.info/HOWTO/Jaz-Drive-HOWTO.html
HOWTO: The 3 Button Serial Mouse mini-HOWTO - http://ldp.openskills.info/HOWTO/3-Button-Mouse.html
HOWTO: Linux ACP Modem (Mwave) mini-HOWTO - http://ldp.openskills.info/HOWTO/ACP-Modem/index.html
HOWTO: Cable Modem Providers HOWTO - http://ldp.openskills.info/HOWTO/Cable-Modem/index.html
HOWTO: Modem-HOWTO - http://ldp.openskills.info/HOWTO/Modem-HOWTO.html
HOWTO: Linksys Blue Box Router HOWTO - http://ldp.openskills.info/HOWTO/Linksys-Blue-Box-Router-HOWTO/index.html
HOWTO: The Linux 2.4 SCSI subsystem HOWTO - http://ldp.openskills.info/HOWTO/SCSI-2.4-HOWTO/index.html
HOWTO: The Linux SCSI Generic (sg) HOWTO - http://ldp.openskills.info/HOWTO/SCSI-Generic-HOWTO/index.html
HOWTO: The Linux SCSI programming HOWTO - http://ldp.openskills.info/HOWTO/SCSI-Programming-HOWTO.html
HOWTO: The Linux MIDI-HOWTO - http://ldp.openskills.info/HOWTO/MIDI-HOWTO.html
HOWTO: Sound Blaster AWE 32/64 HOWTO - http://ldp.openskills.info/HOWTO/Soundblaster-AWE.html
HOWTO: Ftape-HOWTO - http://ldp.openskills.info/HOWTO/Ftape-HOWTO.html
HOWTO: Linux Touch Screen HOWTO - http://ldp.openskills.info/HOWTO/XFree86-Touch-Screen-HOWTO.html
HOWTO: The UPS Howto - http://ldp.openskills.info/HOWTO/UPS-HOWTO.html
HOWTO: Wireless Howto - http://ldp.openskills.info/HOWTO/Wireless-HOWTO.html
HOWTO: Linux Infrared HOWTO - http://ldp.openskills.info/HOWTO/Infrared-HOWTO/index.html
HOWTO: Linux PCI-HOWTO - http://ldp.openskills.info/HOWTO/PCI-HOWTO.html
HOWTO: Linux PCMCIA HOWTO - http://ldp.openskills.info/HOWTO/PCMCIA-HOWTO.html
HOWTO: Plug-and-Play-HOWTO - http://ldp.openskills.info/HOWTO/Plug-and-Play-HOWTO.html
HOWTO: Smart Card HOWTO - http://ldp.openskills.info/HOWTO/Smart-Card-HOWTO/index.html
HOWTO: VCR-HOWTO - Using your GNU/Linux computer as a VCR - http://ldp.openskills.info/HOWTO/VCR-HOWTO.html
Tipo Infobox: DISTRO - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-08-19 16:37:21
Molte distribuzioni hanno una propria pagina dedicata all'hardware supportato. Seguire i link per dettagli.
Considerare che il supporto hardware di Linux dipende dal kernel più che dalle singole distribuzioni.
Una distribuzione più recente ha maggiori probabilità di supportare una gamma maggiore di hardware, avendo, presumibilmente, un kernel più recente.
LINK: Red Hat - Linux Hardware Compatibility List - http://www.redhat.com/support/hardware/
LINK: Mandrake - Hardware Database - http://www.linux-mandrake.com/en/hardware.php3
LINK: Caldera - Compatible Hardware - http://www.caldera.com/support/hardware/
LINK: SUSE - Linux Component DataBase - CDB - http://hardwaredb.suse.de/index.php?LANG=en_UK
LINK: Yellow Dog Linux - Power PC hardware support - http://www.yellowdoglinux.com/support/hardware/
LINK: Mandrake - Hardware Database - http://www.linux-mandrake.com/en/hardware.php3
LINK: DMOZ - Categoria Linux Hardware Support - http://dmoz.org/Computers/Software/Operating_Systems/Linux/Hardware_Support/
LINK: Turbolinux - Hardware supported - http://www.turbolinux.com/hcl/
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-12 21:37:27
L'installazione di Linux si può eseguire seguendo metodi differenti: generalmente si usa il CD-ROM (ogni PC almeno dal 1998 in poi permette il boot diretto da CD) oppure via floppy ma sono possibili anche installazioni centralizzate via rete (via http, ftp, nfs, smb) particolarmente utili quando si devono gestire ed installare un gran numero di macchine.
Il primo e fondamentale punto da considerare è lo spazio su hard disk dove installare il sistema operativo.
E' necessario avere a disposizione un hard disk almeno parzialmente libero. Qualora fosse necessario liberare spazio su disco e creare una partizione, si può usare il programma Parted, gratuito per Linux e presente su un Live CD come Knoppix, o programmi per Windows come Partition Magic (commerciale) o Fips (gpl).
Solo quando si è sicuri di avere una partizione o un hard disk disponibile (i dati eventualmente presenti verrebbero cancellati), si può procedere con l'installazione vera e propria.
Sebbene ogni distribuzione utilizzi un proprio tool di setup, le procedure sono generalmente le stesse:
- Viene caricato da CD o floppy di boot un sistema Linux temporaneo, tramite il quale è possibile lanciare il tool di installazione ed eseguire tutte le operazioni previste.
- Viene partizionato lo spazio su disco disponibile secondo i criteri definiti dall'utente;
- Vengono formattate le partizioni create, con il filesystem scelto;
- Si selezionano i programmi da installare, scegliendoli individualmente o selezionando delle impostazioni di default a seconda del tipo di sistema che si sta creando: desktop, server, stazione di sviluppo, laptop ecc. Il sistema provvede automaticamente ad installare le dependencies (pacchetti non selezionati dall'utente ma necessari per poter far funzionare quelli scelti). Se il computer è per un uso personale (desktop) e lo spazio su Hard Disk non manca ( > 2Gb ) ci si può sbizzarrire ad installare un po' di tutto, per verificare la funzionalità di programmi diversi. I programmi scelti vengono copiati sulle partizioni appena formattate.
- Si sceglie se installare l'interfaccia a finestre X window o lasciare soltanto la shell (interfaccia testuale). Se la macchina che si sta installando è destinata a diventare un server si consiglia di rimuovere ogni programma legato a X window ed ogni applicazione ludica/multimediale.
- Si inseriscono parametri relativi alla configurazione di rete, password dell'utente root, eventuali utenti aggiuntivi, servizi da avviare al boot ecc.
- Si installa sul Master Boot Record (MBR) del computer un Linux Loader (LILO o GRUB sono i più comuni) che permette il boot di Linux al riavvio e di eventuali altri sistemi operativi presenti sul sistema.
- Si crea, facoltativamente, un floppy disk di ripristino che permette di caricare il sistema installato in caso di problemi con l'MBR o altri fasi del boot.
Alla fine dell'installazione si esegue un reboot e ci si ritrova, da subito (non sono necessari ulteriori riavvii) un sistema Linux completo, già provvisto di una moltitudine diprogrammi per tutti gli usi.
Il tempo totale di installazione può variare generalmente dai 20 ai 60 minuti.
SOURCE: The Linux Bootdisk HowTo - http://www.linuxdoc.org/HOWTO/Bootdisk-HOWTO/
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-09-20 11:44:54
In ambienti Unix e quindi anche su Linux esistono differenze fra i vari utenti, definite dai permessi e dall'acceso ai file e comandi che un'utente può lanciare.
Per convenzione i semplici utenti possono scrivere, leggere e modificare file solo all'interno del loro ambiente (home) e lanciare comandi che non influiscono sulla configurazione o il corretto funzionamento del sistema.
Per poter accedere completamente alle risorse del sistema bisogna accedere al sistema come superuser ovvero impersonificando l'utente root.
In fase di installazione di una macchina Linux si consiglia di scegliere una password di root piuttosto complicata (ma che si possa ricordare) e di creare immediatamente un normale utente con il quale eseguire le proprie funzioni più comuni.
In particolare si consiglia, per motivi di sicurezza, di non lanciare mai X window (l'interfaccia a finestre disponibile su Linux) come utente root su una macchina che ha accesso a reti esterne.
L'utente root è diverso dagli altri, in quanto ha pieno controllo del sistema.
Può infatti:
- Aggiungere, eliminare, modificare e cambiare la password degli altri utenti
- Installare e configurare tutti i servizi del sistema
- Accedere senza limitazioni (lettura e scrittura) a tutti i file presenti nel filesystem
- Gestire (avviare, terminare, modificare la priorità) tutti i processi
- Gestire l'hardware del computer
- Distruggere tutto con un solo comando (e tante altre brutte cose, il potere di root sul sistema è assoluto).
Inutile sottolineare che è molto importante che l'accesso a root sia limitato solo al proprietario o all'amministratore del sistema.
Tipo Infobox: DISTRO - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2006-08-23 00:56:40
Qualunque appassionato di informatica o anche semplice curioso dovrebbe essere interessato a provare Linux e iniziare a vedere direttamente come funziona.
Per i pigri, gli insicuri o coloro che non se la sentono di fare una normale installazione di Linux sul proprio PC, esistono e sono ormai consolidate varie distribuzioni "LIVE" che permettono il caricamento di Linux direttamente dal CDROM, senza la necessità di installare alcunchè sul proprio prezioso e fragile hard disk.
Queste distribuzioni che bootano direttamente un sistema Linux completo dal CDROM possono essere usate in varie occasioni:
- Dimostrazioni dal vivo, in tempi rapidi, senza le potenziali complicazioni di un'installazione su Hard Disk;
- System Recovery, con la possibilità di operare sul sistema locale senza averlo bootato;
- Network monitoring in situazioni straordinarie, con la possibilità di sniffare, diagnosticare, eseguire test;
- Prove e valutazioni rapide e innocue di un sistema Linux sul proprio PC, senza il rischio di far danni.
Citiamo alcune delle distribuzioni LIVE CD più significative, si raccomanda sempre di utilizzare le più recenti e di considerare che l'esecuzione di molteplici applicazioni richiede memoria che va paginata sull'hard disk, se non basta la RAM.
In genere è fondamentale che la distribuzione riconosca la propria scheda di rete o modem, nel momento in cui questo avviene la configurazione del networking diventa semplice (tramite DHCP o configurazione manuale).
Alcune schede sonore o periferiche particolari (winmodem, schede integrate su motherboard ecc.) possono non essere rinosciute.
KNOPPIX - Impressionante, efficace e comoda.
Il tedesco Klaus Knopper ha fatto un gioiello di immagine ISO, basata su Debian. Due Gigabyte di software compresso su un CD di quasi 700 Mb (o molto di più nella versione DVD), un boot rapido ed efficiente nel riconoscimento dell'hardware locale, la possibilità di eseguire moltissimi programmi da un ambiente grafico completo (KDE di default) ne fanno la distribuzione ideale sia per dimostrazioni e valutazioni che per system recovery e network analysys.
In caso di carenza di RAM crea dello SWAP space sull'hard disk e per chi si affeziona puo' essere installato su Hard Disk.
KNOPILS - Il Knoppix italiano
KnopILS (il cui nome vuole ricordare KNOPPIX e ILS) è una KNOPPIX modificata con queste caratteristiche particolari:
- i pacchetti .deb installati appartengono tutti al ramo free di Debian GNU/Linux (o consentono una classificazione equivalente nel caso di pacchetti non ufficiali)
- la schermata di boot è in italiano
- la schermata ``F2`` iniziale è in italiano
- la tastiera predefinita è quella italiana
- la lingua predefinita è l'italiano
- quando possibile, sono presenti pacchetti localizzati
- altre modifiche minori (grafica, bug fixing ecc...)
Morphix - Derivazione modulare di Knoppix
Live cd basato su debian sid e derivato da Knoppix, è possibile vedere più ambienti grafici (Gnome, KDE, XFCE) in base alla iso che si utilizza. Comoda ed aggiornata ha la possibilità di essere customizzata in modo modulare ed installata su Hard Disk in modo estremamamente semplice.
LINUX BOOTABLE BUSINESS CARD Un Linux su una Business Card CD
In poco più di 100 Mb di CD (basta un Mini CD) permette il boot da CD di un sistema Linux grafico con un tool di diagnostica utili e gli strumenti essenziali per un system recovery (fdisk, lilo...).
LINUXCARE BOOTABLE TOOLBOX Essenziale e pratica.
Distribuzione che deriva dalla precedente e ne mantiene le caratteristiche.
Preente un pratico menu di diagnosi e setup del sistema.
DEMO LINUX Una derivazione Live basata su Mandrake e ben fornita.
Gnome, KDE, StarOffice, Gimp, Netscape e molti altro software comune in Linux.
DYNE:BOLIC A network streaming server on CD.
Curioso Live CD, che carica un ambiente grafico basato su Enlightement e presenta i programmi essenziali per l'uso di Internet e una suite di strumenti, basata sul software MUSE e il network PublicVoice per imbastire uno streaming server velocemente e facilmente. Puo' essere usato come un rapido sistema per mettere online una Internet Radio da qualsiasi postazione.
BACK TRACK - Probabilmente il LIVE CD relativo alla sicurezza più completo ed efficace. Comprende moltissimi e non comuni programmi relativi alle diverse facce del variegato mondo della sicurezza. E' basata su Slax, una Live a sua volta basata su Slackware.
LINK: Home Page KNOPPIX Linux - http://www.knoppix.net/
LINK: LINUXCARE BOOTABLE TOOLBOX (Live CD) Home Page - http://lbt.linuxcare.com/
LINK: DYNEBOLIC LIVE CD Home Page - http://dynebolic.org/
LINK: DEMO-LINUX Home Page - http://www.demolinux.org/
LINK: Home Page Distro Morphix - http://www.morphix.org/
LINK: Home Page knopILS - http://knopils.linux.it/
Una volta installato Linux possiamo iniziare ad utilizzarlo, prendendo dimestichezza con le sue componenti fondamentali.
Alcuni aspetti dell'uso di un sistema operativo (SO) possono essere tanto comuni e conosciuti da apparire scontati. Lo sono, come sempre, solo per chi li conosce.
Accesso al sistema e utenti
Su ogni SO moderno è generalmente previsto che l'utente acceda al sistema tramite login e password. Possono inoltre coesistere diversi utenti, alcuni dei quali hanno poteri speciali di amministrazione (Administrator su Windows, root su Linux e Unix).
Su Linux è possibile accedere, via via interfaccia testuale che grafica, anche d un sistema remoto.
L'interfaccia testuale: la shell
Caratteristica alla base di ogni sistema Unix è la shell, un interprete dei comandi dell'utente con interfaccia a caratteri che di fatto, per la sua flessibilità, è alla base dell'intero sistema.
Esistono diversi tipi di shell, con sintassi e funzionamento leggermente diversi, su Linux è particolarmente diffusa la bash.
Avere dimestichezza con la propria shell è indispensabile per un amministratore di sistema.
L'interfaccia grafica: X Window System
Nel mondo Unix l'interfaccia grafica è gestita con X Window, un sistema client server dove il client è la normale applicazione che usa l'utente e il server si preoccupa di gestire l'output su Video. Linux ha 2 alternative principali per X: XFree86 e Xorg.
Esistono poi diversi Windows Manager, che gestiscono il sistema di finestre e menu, e pochi desktop manager (come Gnome, KDE, XFCE) che forniscono un ambiente desktop uniforme.
Documentazione
La migliore fonte di documentazione di un sistema Linux è il sistema stesso, sia da riga di comando che da ambiente grafico è possibile accedere a moltissime informazioni contestuali e complete. Abituarsi ad usarle e conoscere dove trovarle è fondamentale.
Software
Un sistema operativo senza software è come un cnalae televisivo senza programmi. La disponibilità di software per Linux è notevole e, per quanto normalmente gran parte di quello che serve è già disponibille con la proprio distribuzione, è sempre utile sapere dove trovarlo.
Login sul sistema, utenti normali e root |
Procedure di login e logout. Root e altri utenti. Acceso remoto via telnet. |
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-18 22:51:50
Linux, come ogni Unix, è un sistema operativo multiutente, dove differenti utenti possono avere, contemporaneamente, accesso al sistema avendo i propri dati, documenti e impostazioni completamente separati da quelli di altri utenti oltre ad avere la possibilità di accedere alla risorse del sistema simultaneamente ed eseguire i programmi disponibili.
L'accesso ad un sistema Unix può avvenire tramite un'interfaccia grafica a finestre, paragonabile a quella di Windows e basata sull'X Window System, o una interfaccia testuale, a riga di comando, tramite un programma che ha lo scopo di interpetare i comandi digitati dall'utente: la shell
Essendo un sistema operativo orientato alle reti, si può accedere a Linux, come ad altri dialetti Unix, sia direttamente tramite console (la tastiera direttamente collegata al computer) sia da una postazione remota, via rete.
L'accesso al sistema è subordinata all'inserimento, da parte dell'utente, di una login (nome utente) e della relativa password. Questa operazione di autenticazione dell'utente è detta login.
Il login può quindi essere eseguito in ambienti diversi, grafici o testuali da locale o da remoto ma ha sempre lo stesso scopo: permettere all'utnete di accedere ed interagire con il sistema dopo averne verificate le credenziali (login e password).
Il logout è esattamente l'opposto del login: se si è in modalità testuale si chiude la shell aperta con il precedente login, se si è in un ambiente grafico, si esce da questo. In entrambi i casi dopo il logout si ha la possibilità di ripetere una operazione di login, eventualmente con un nome utente diverso.
Per eseguire il login da remoto su un sistema Unix si utilizzano generalmente programmi con telnet (nome di un protocollo e del relativo comando, ampiamente usato, sopratutto in passato) o ssh (una alternativa a telnet con le stesse funzionalità ma la possibilità di criptare i dati in transito e quindi, di questi tempi, preferito al telnet).
LINK: The Login Process - http://ctdp.tripod.com/os/linux/howlinuxworks/linux_hllogin.html
HOWTO: What happens when you log in? - http://ldp.openskills.info/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/login.html
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-18 23:00:57
Eseguire lo spegnimento o il riavvio del proprio Linux da interfaccia grafica è intuitivo quanto su Windows: nel menu delle applicazioni, di solito, in basso a sinistra, esistono le adeguate icone.
Anche con Linux, come con Windows e tutti i sistemi operativi moderni, che fanno largo e costante uso dell'hard disk per scrivere file anche temporanei, è consigliabile evitare di spegnere brutalmente il computer direttamente con l'interruttore ed è meglio seguire la procedure di spegnimento "soft" prevista dal sistema.
I comandi per spegnere il sistema, operando in modalità testuale, sono vari, a volte sono semplici alias:
shutdown -h
(passa al runlevel 0, corrisponde ad un spegnimento del sistema).
halt
poweroff
init 0
Per riavviare il sistema si possono usare i seguenti comandi:
shutdown -r
(passa al runlevel 6, reboot)
reboot
init 6
In molte distribuzioni è attivata la combinazione di tasti CTRL+ALT+CANC, associata al comando "shutdown -t3 -r now
" (o analoghi) che esegue un reboot entro 3 secondi.
Per disabilitare la possibilità di fare un reboot da console (anche senza essere loggati sul sistema!) con i tre famigerati tasti, si deve editare il file /etc/inittab
.
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-06-17 12:52:22
Per usare telnet (da prompt DOS, shell UNIX e qualsiasi altra CLI (Command Line Interface) che presenti questo comando) basta scrivere: telnet seguito dall'indirizzo o dal nome dell'host da raggiungere.
Per esempio: telnet www.whitehouse.gov
Scrivendo semplicemente telnet senza specificare l'host remoto, si entra in modalità comandi, da cui è possibile aprire o chiudere connessioni o effettuare altre operazioni (digitare help per l'elenco dei comandi in ambiente telnet).
Per chiudere una sessione telnet basta digitare logout (sulla macchina remota).
Se per qualche motivo la connessione telnet risulta bloccata, è possibile premere CTRL + ] per entrare in modalità comandi e da li scrivere quit per chiudere la sessione telnet bloccata. Se si hanno più sessioni telnet in successione, scrivere send escape per passare dalla prima aperta all'ultima.
La porta a cui risponde un telnet server è la 23 (TCP) e viene data per sottointesa.
E' comunque possibile effettuare un telnet ad altre porte TCP e digitare direttamente dei comandi validi per il protocollo utilizzato dal server a cui ci si è connessi.
Per esempio, un sistema rapido, disponibile ovunque e piuttosto utile, per diagnosticare velocemente il funzionamento di un server web è scrivere:
telnet www.server.net 80
(o qualsiasi altro comando HTTP)
GET /
Premendo INVIO due volte si visualizza il codice html della pagina richiesta (l'home page, in questo caso) e ci si assicura che il server web sta rispondendo e non ci sono problemi di connettività a raggiungerlo.
LINK: Using and Understranding the Internet: TELNET - http://www.pbs.org/uti/guide/telnet.html
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: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-06-17 13:15:05
Accedere a Unix in modalità testuale direttamente da console (tramite una tastiera direttamente collegata al computer) o da remoto, via rete, è fondamentalmente la stessa cosa e permette di operare con la shell in modo analogo.
Di fatto è molto più comune accedere a dei server da remoto che tramite console, che a volte viene usato solo per interventi straordinari o guasti, quando la macchina non è interconnessa in rete.
Il metodo più comune, in passato, per accedere ad una macchina Unix era tramite telnet.
Telnet è un semplice programma di terminale oltre ad essere il nome del protocollo che viene utilizzato da questo programma.
Il suo uso primario è quello di aprire connessioni su macchine remote per permettere il login e quindi accedere alla shell come se fosse un'operazione eseguita in locale.
Con telnet i pacchetti contenenti login e password passano in chiaro nella rete, con i relativi rischi in termini di sicurezza informatica (esistono sniffer specifici per sessioni telnet, che evidenziano le password senza nemmeno la fatica di andare ad analizzare i singoli pacchetti telnet).
Un' alternativa valida e ormai molto diffusa per l'accesso ad host remoti via command-line è ssh, con il quale i dati trasferiti vengono criptati.
Il protocollo SSH (ora giunto alla versione 2, sensibilmente più affidabile e sicura della versione 1) su Linux è generalmente implementato con il pacchetto openssh, che ha sia una componente client che una server.
E' possibile usare un sistema remoto operando anche in modalità grafica. Il sistema X Window, alla base dell'interfaccia grafica di Linux, di fatto è basato su una architettura client-server che rende possibile l'esecuzione di un programma su un computer remoto e la sua visualizzazione sul proprio schermo (normalmente server e client X operano sulla stessa macchina).
Esistono inoltre tecnologie che permettono la gestione dell'ambiente grafico fra sistemi operativi diversi:
- rdesktop è un client Linux per accedere ad un Desktop Remoto Windows.
- Vnc è una tecnologia, disponibile su tutti i principali sistemi operativi, per visualizzare l'output di un sistema remoto.
- NX è un sistema di ottimizzazione di X Window che permette l'accesso a sistemi Linux anche da macchine Windows.
Introduzione alla interfaccia testuale: la shell |
Definizione di shell. Panoramica delle shell più diffuse. Introduzione alla bash. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2007-02-23 15:45:37
Molti termini informatici hanno, non a caso, significati che sono direttamente correlati a quelli delle rispettive parole d'uso comune.
Il "kernel" di un sistema operativo è il nucleo, la parte interna, il nocciolo, quello, in termini informatici, che si occupa di lavorare a basso livello e gestire l'hardware e le sue risorse, la "shell", al contrario, è il guscio, la conchiglia, la parte esterna, quella a contatto con il mondo esterno, l'utilizzatore di un computer.
La shell è quindi l'interfaccia (testuale) tramite la quale l'utente può operare ed interagire con il sistema.
La shell, tecnicamente, è un normale programma che interpreta ed esegue i comandi dell'utente (viene chiamata anche Command Interpreter) permettendogli di eseguire altri programmi che accedono alle risorse hardware della macchina tramite le chiamate di sistema offerte dal kernel.
Su un sistema Unix la shell è fondamentale per moltissime attività , che vanno oltre la semplice interattività con l'utente, avendo diverse modalità funzionali:
- USO INTERATTIVO, il sistema attende i comandi digitati dall'utente, che possono redirezionare input ed output, è quello che normalmente si utilizza dopo il login e a cui ci si riferisce quando si parla di usare una shell;
- CONFIGURAZIONE della propria sessione, con cui definire variabili e parametri che vengono utilizzati in ogni interazione dell'utente con la macchina, viene fatto negli script di inizializzazione;
- PROGRAMMAZIONE utilizzando comandi di sistema e funzionalità della shell è possibile realizzare piccoli programmi (script shell) in grado di automatizzare operazioni e reagire ad eventi.
Esistono diverse varietà di shell, hanno sostanzialmente la stessa funzione ma si differenziano per funzionalità e, in parte, sintassi dei loro comandi interni. Fra le shell più diffuse segnaliamo la Bourne Shell (sh
), la Korn Shell (ksh
), la C Shell (csh
) e la Bourne Again Shell (bash
), sviluppata dal progetto GNU, rilasciata con licenza GPL e particolarmente comune su sistemi Linux.
LINK: Shell Dorado - Info utili per shell programmers - http://oase-shareware.org/shell/
LINK: An introduction to Unix Shell - Scritta da Mr. Bourne in persona - http://www.ling.helsinki.fi/users/reriksso/unix/shell.html
LINK: Softpanorama University Shell Course - Shells Webliography - http://www.softpanorama.org/Scripting/shells.shtml
LINK: Elenco di provider che offrono account shell gratuiti - http://www.leftfoot.com/freeshells.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-12 22:07:26
In linea con la natura multiforme e variegata di Unix, esistono molteplici shell, ognuna delle quali presenta caratteristiche e peculiarità proprie.
sh - Bourne shell, è disponibile su qualsiasi ambiente UNIX, quindi è la più utilizzata per creare script shell compatibili e cross-platform.
csh - C shell, prende il nome dal linguaggio di programmazione, ovviamente le funzionalità di tale shell derivano in modo diretto dal C.
bash - Bourne Again Shell. Una delle ultime nate, offre le stesse capacità della C shell, con l'aggiunta di alcune funzionalità come l'history dei comandi e la TABcompletion. E' una componente del progetto GNU come, come molti altri programmi, vengono ormai usati su altri Unix, anche commerciali.
ksh - Korn shell. Largamente diffusa è compatibile con la sh sulla parte di scripting ed ha tutte le funzionalità di interazione della csh.
tcsh - E' un'evoluzione della csh, con cui mantiene piena compatibilità e introduce feature come command line editing e name completion.
rsh - Restricted Bourne shell (da non confondere con l'omonimo comando). Una shelle con funzionlità minime ed essenziali.
jsh - Bourne Shell con Job control.
dtksh - Desktop Korn Shell.
rksh - Restricted Korn Shell.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-23 15:35:52
Bash acronimo di Bourne Again Shell, è la shell di gran lunga più utilizzata in ambiente Linux. E' un componente chiave del progetto GNU e rimane disponibile su ogni Unix.
Alcune sue caratteristiche (presenti anche in altre shell):
- Possibilità di editare la command line
- TAB completion dei comandi
- Possibilità di definire alias
- History infinita dei comandi inseriti
- Funzionalità di scripting, funzioni condizionali e di ciclo.
- Possibilità di definire funzioni
- Possibilità di gestire array indicizzati di dimensioni infinite
- Gestione e controllo dei job
- Espressioni aritmetiche
- Caratteri jolly (metacaratteri) nella gestione dei nomi di file
L'uso e la pratica della bash sono l'unico vero modo per conoscerla e approfondirne le molteplici caratteristiche.
Sui sistemi Linux viene lanciata automaticamente dopo il login, alternativamente basta scrivere bash (trovandosi in un'altra shell) per eseguirla.
LINK: Bash Reference Manual - http://www.gnu.org/manual/bash/html_chapter/bashref_toc.html
LINK: Come modificare il Prompt della propria BASH - http://www.linux.org/docs/ldp/howto/Bash-Prompt-HOWTO/index.html
SOURCE: Bash Official Home Page - http://www.gnu.org/software/bash/bash.html
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-23 15:36:29
La bash presenta una serie di funzionalità molto pratiche che è fondamentale conoscere ed utilizzare regolarmente, in quanto rendono il suo utilizzo molto più comodo e rapido.
Tutte queste funzionalità di base vanno praticate direttamente più che lette o studiate.
Si invita il lettore quindi ad aprirsi una shell e provare "sul campo" quanto segue.
TAB
Il tasto TAB è fondamentale quando su usa la bash: permette l'autocompletamento di comandi o nomi di file e directory. Abituarsi a premerlo uno o due volte in rapida successione per completare automaticamente un comando che si sta digitando o visualizzare tutti i comandi possibili che iniziano con le lettere inserite prima di "TABbare".
Oltre a velocizzare l'inserimento di comandi permette di essere certi della loro sintassi o della correttezza di nomi di file e directory inseriti.
FRECCIA SU - FRECCIA GIU
Altri tasti da usare spesso. Premendoli è possibile spostarsi nella history dei comandi digitati precedentemente nella shell. E' comodissimo in molte occasione e permette di risparmiare tempo e di fare velocemente "prove e riprove" di comandi dati.
FRECCIA DESTRA - FRECCIA SINISTRA
Permettono di muoversi all'interno della riga di comando corrente per modificarla o inserire del testo. Utili, per esempio, quando si deve cambiare leggeremente una riga di comando inserita precedentemente (e richiamata con FRECCIA SU).
SHIFT + FRECCIA SU - SHIFT + FRECCIA GIU
Permette di visualizzare l'output della shell che ormai non è più visibile nella schermata corrente. In pratica si scrolla verticalmente, di una riga alla volta, il testo visualizzato nella sessione corrente.
SHIFT + PAGINA SU - SHIFT + PAGINA GIU
Ottiene lo stesso effetto più rapidamente, eseguendo lo scroll di intere pagine alla volta invece che di singole righe.
Tipo Infobox: BOFH - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2003-11-27 17:36:03
Funzionalità della bash che permette di ri-eseguire un comando precedentemente lanciato e presente nella history.
E' possibile specificare un numero, per indicare una entry nella history, o una stringa, che permette di eseguire l'ultimo comando dato che inizia con la stringa indicata.
Tecnicamente definito event designator !
, si occupa di recuperare una entry nella history di Bash in base alla stringa o al numero passati come "parametro":
root@Joker:/home/homer/python# ls -l hello*
-rw-r--r-- 1 homer users 48 Jun 9 14:30 hello.py
-rw-r--r-- 1 homer users 70 Jun 9 15:33 hello2.py
root@Joker:/home/homer/python# history
1 ls -l hello*
2 history
root@Joker:/home/homer/python# !1
ls -l hello*
-rw-r--r-- 1 homer users 48 Jun 9 14:30 hello.py
-rw-r--r-- 1 homer users 70 Jun 9 15:33 hello2.py
Viene indicato il numero 1 (UNO) e si esegue la entry numero Uno nella history
root@Joker:/home/homer/python# !l
ls -l hello*
-rw-r--r-- 1 homer users 48 Jun 9 14:30 hello.py
-rw-r--r-- 1 homer users 70 Jun 9 15:33 hello2.py
Viene indicata la lettera l (ELLE) e si esegue l'ultimo comando presente nella history che inizia con Elle
Tutto questo è piuttosto utile per recuperare comandi complessi inseriti in precedenza, evitando di riscriverli completamente.
Tipo Infobox: ETCETERA - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-08-21 22:42:09
La shell è presente in ogni Unix, ma anche su Windows si può ricostruire il propro mondo shell.
Il vecchio DOS e il più recente prompt dei comandi Windows, seppur simili come aspetto (command line interpreter testuale) e in parte come funzionalità non danno un'idea completa di cosa è possibile fare con una shell evoluta o quantomeno Bourne-like.
E' possibile sentirne l'ebbrezza con l'ottimo CYGWIN, che è molto di più di una shell, è un vero e proprio ambiente Unix, con tanto di compilatore, disponibile sotto Windows.
Può essere molto comodo per utilizzare comandi comuni e pratici tipici di un sistema Unix direttamente da una finestra Windows.
LINK: Home Page CYGWIN - http://sources.redhat.com/cygwin/
Introduzione all'interfaccia grafica: X Window System |
Introduzione all'uso e alla comprensione delle interfacce grafiche a finestre di Linux |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-06-15 21:58:46
E' possibile operare su un sistema Linux in due modi: tramite una shell, con interfaccia testuale a caratteri, particolarmente comoda su server, o tramite un più accessibile ambiente grafico, con un mondo di finestre e icone gestite via mouse.
Il sistema grafico di Linux viene comunemente chiamato X (X Window System) che nel tempo è diventato lo standard GUI (graphic user interface) di Unix e Linux.
A differenza di Microsoft Windows in cui l'interfaccia a finestre è parte integrante del kernel, in Unix è un normale processo e viene trattato come tale, con i vantaggi (maggiore stabilità del sistema nel momento in cui si dovesse bloccare) e gli svantaggi (prestazioni penalizzate) del caso.
L'ambiente grafico X è composto essenzialmente da questi componenti:
Server X
E' il processo che si occupa di gestire il display, ovvero si occupa di far interagire l'utente con la GUI. Esistono molteplici server X, ma su Linux sono diffusi Xorg e XFree86.
Alternative commerciali sono Accelerated-X e Metro-X.
Windows manager
Sono i software che si occupano di gestire le finestre e l'interazione con l'utente, ne esistono numerosi e possono essere alla base di sistemi desktop più complessi e completi. Fra i nomi più noti KDE (è un sistema Dekstop con un proprio Window Manager), Enlightenment, Sawfish, AfterStep, FVWM, Blackbox, Fluxbox, Metacity..
Desktop Manager
Insieme di programmi, che offrono una interfaccia unificata, coerente ed integrata. I Desktop Manager più conosciuti e utilizzati sono Gnome e KDE, dotati di tutto il software necessario per un ambiente desktop moderno, con XFCE terzo incomodo, sicuramente più "leggero".
Client X
Sono tutti i programmi eseguiti sotto X, con cui l'utente interagisce (ad esempio un browser, un word processor ecc.).
Il fatto di avere un'architettura client-server permette di utilizzare facilmente un server X locale (che mostra l'ambiente grafico sul nostro schermo) con un client in esecuzione su una macchina remota (potrebbe essere un server di applicazioni, particolarmente dotato in termini di hardware, dove di fatto vengono eseguiti i programmi che si usano).
Un'applicazione possimile di questa struttura prevede dei terminali con poche risorse hardware (thin client), a volte senza harddisk e giusto una scheda video e di rete, che caricano il sistema operativo via network, ospitano localmente un server X ed eseguono programmi (client X) su un server centrale.
Comunemente, quando si utilizza Linux sul proprio computer, il server e i client coesistono e vengono eseguiti sulla stessa macchina, ma prima di poter lanciare i client (i programmi, in ambiente grafico, che l'utente normalmente esegue), bisogna avere il server X funzionante.
HOWTO: X Window System Architecture Overview HOWTO - http://ldp.openskills.info/HOWTO/XWindow-Overview-HOWTO/index.html
HOWTO: Remote X Apps mini-HOWTO - http://openskills.info/LDP/HOWTO/Remote-X-Apps.html
HOWTO: XFree Local Multi-User HOWTO - http://openskills.info/LDP/HOWTO/XFree-Local-multi-user-HOWTO/index.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2005-06-15 21:49:17
L'interfaccia grafica su Linux può basarsi su diversi ambienti desktop (Desktop Environment o Desktop Manager), che mirano alla definizione di un interfaccia a finestre omogenea, coerente, semplice da usare ed integrata: Gnome e KDE sono i più conosciuti e generalmente usati nelle distribuzioni Linux, ma esistono alternative come XFCE e il vecchio CDE.
Gnome e KDE hanno le caratteristiche tipiche di un ambiente desktop evoluto: un file manager integrato e coerente, un layer di librerie tramite il quale è possible realizzare programmi con un look&feel comune, degli ambienti di sviluppo IDE che semplificano lo sviluppo di applicazioni native, canali omogenei di comunicazione fra programmi ecc.
Kde (K Desktop Environment)
Comprende, oltre ad un Windows Manager autonomo, un'intero ambiente desktop molto user friendly. Fornisce vari sistemi integrati per la gestione e configurazione del sistema oltre a vari programmi come una suite office completa (KOffice) e un IDE - Ambiente di sviluppo integrato (Kdevelop).
Si basa sulle librerie Qt ed utilizza un proprio metodo di comunicazione fra processi: DCOP.
Gnome (GNU Network Object Model Environment)
E' scritto e sviluppato dal Gnome Developer's project e fa parte del progetto GNU. A differenza di KDE Gnome è solo l'ambiente desktop per cui ha bisogno di un windows manager come FVWM (Fantastic Virtual Windows Manager). Anche Gnome offre dei propri sistemi integrati per la gestione della macchina. La sua architettura è completamente basata su CORBA.
Si basa sulle librerie GTK ed utilizza Corba per la comunicazione fra processi con l'implementazione OBRit.
Molte distribuzioni Linux prevedono la possibilità di installare ed utilizzare sia Gnome che KDE, è poi possibile modificarli e aggiornarli secondo le proprie necessità.
E' possibile lanciare programmi per KDE sotto Gnome e viceversa (sono tutti client X), l'interoperabilità reciproca migliora ma resta l'onere di caricare in memoria le librerie di base di entrambi e quindi appesantire sistemi non ben dimensionati.
XFCE
E' un ambiente desktop che sta crescendo molto perchè mantiene la caratteristica di essere leggero, e quindi permettere un agevole uso anche su hardware non potente.
LINK: Gnome Home Page - http://www.gnome.org/
LINK: KDE Home Page - http://www.kde.org/
LINK: Da DMOZ: Tutti i siti su KDE - http://dmoz.org/Computers/Software/Operating_Systems/Graphic_Subsystems/Desktop_Environments/KDE/
LINK: Da DMOZ: Tutti i siti su GNOME - http://dmoz.org/Computers/Software/Operating_Systems/Graphic_Subsystems/Desktop_Environments/GNOME/
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-06-17 18:29:52
XWindow è un sistema client server in cui il server si occupa della visualizzazione del display e il client è il singolo programma eseguito.
Normalmente client e server coesistono sulla stessa macchina e all'utente questa natura non appare in tutte le sue potenzialità.
E' possibile infatti eseguire programmi su macchine remote e visualizzarli sulla propria macchina.
Per farlo, in modo rapido, si possono seguire 2 vie:
Sistema normale
Consideriamo un sistema in cui la nostra macchina ha IP 10.0.0.90 e vogliamo visualizzare sul nostro schermo comandi sulla macchina 10.0.0.20.
Per farlo sulla macchina locale va impostato (con non pochi potenziali problemi di sicurezza), solitamente come root, su alcuni sistemi anche come utente normale:
xhost +
Apre a tutti gli IP la possibilità di collegarsi all'X server locale o
xhost + inet:10.0.0.90
Limita l'accesso solo all'IP 10.0.0.90
Mentre sulla macchina remota, basta collegarsi in telnet e impostare come Xserver il proprio IP:
export DISPLAY=10.0.0.20:0
A questo punto qualsiasi programma che richiede l'ambiente grafico lanciato dalla shell aperta in remoto viene visualizzato sullo schermo del PC locale.
Sistema criptato tramite SSH
Se è abilitata l'opzione X11forwarding sia sul client che sul server SSH, si possono lanciare programmi remoti e visualizzarli sul Xserver locale in modo molto più semplice e sicuro.
Per farlo basta collegarsi via SSH con l'opzione -X. Per esempio:
ssh -X 10.0.0.20
A questo punto qualsiasi programma grafico lanciato sulla macchina remota viene visualizzato automaticamente sul proprio schermo, senza bisogno di ulteriori configurazioni.
Se c'e' un firewall fra client X remoto e server X locale, ricordarsi di aprire la porta 6000 TCP, utilizzata dall'X Window System
HOWTO: Remote X Apps mini-HOWTO - http://ldp.openskills.info/HOWTO/Remote-X-Apps.html
Tipo Infobox: ETCETERA - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-18 23:20:54
Rdesktop è un RDP client per Unix: in pratica l'anello mancante per accedere a sistemi Windows remoti dal proprio Linux tramite la funzionalità di accesso remoto e condivisione desktop chiamata Terminal Services su Windows 2000 Server e Remote Desktop su WindowsXP.
Di fatto con una comoda riga di comando rdesktop permette di aprire una sessione su un Windows 2000 Server remoto o un WindowsXP e visualizzarne il contenuto in una finestra all'interno del proprio ambiente X Window.
Terminal Services funziona molto meglio di VNC (ha protocollo più ottimizzato che supporta meglio limiti di banda) e il client per Unix / Linux permette quello che promette: la gestione e l'uso di server Windows remoti dalla propria postazione Linux.
La sintassi è semplice e si rimanda alla documentazione ufficiale per maggiori informazioni.
Per esempio:
rdesktop -P 98% -k it -u al 10.0.0.100 &
apre una sessione sul server Windows 10.0.0.100, con nome utente al, con dimensioni della finestra al 98% del proprio schermo e usando il layout di tastiera italiana.
Dalla versione 1.3, minima raccomandata, è migliorata la compatibilità con tastiere internazionali (tra cui l'italiana) e la possibilità di fare un copia e incolla dalla macchina locale Linxu alla finestra del Windows remoto.
Download e installazione sono semplicissimi:
make
Nella directory scompattata, per compilare (senza particolari configurazioni).
./rdesktop nomeserver
Per collegarsi al server remoto.
./rdesktop ?
Per un elenco delle opzioni disponibili.
LINK: Sito ufficale rdesktop - http://www.rdesktop.org/
LINK: Grdesktop: Una GUI per rdesktop - http://www.nongnu.org/grdesktop/
LINK: Tsclient: GUI per rdesktop e altri tool - http://www.gnomepro.com/tsclient/
Istruzioni e documentazione su Linux |
Le risorse online [siti e mailing list , Libri e riviste] - Man, info, /usr/docs |
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-06-17 18:42:15
Il primo posto dove cercare documentazione su Linux è Linux stesso.
Tutte le distribuzioni danno la possibilità di installare manuali e documentazione di vario genere.
Nella maggior parte dei casi sono più che sufficienti per conoscere gran parte degli argomenti da sapere.
Ambiente Testuale
Di seguito vengono riportati alcuni comandi per richiamare manuali ed info di vario genere presenti in locale, sul sistema installato, da interfaccia testuale.
man
- E' la fonte più rapida e semplice per apprendere delle informazioni riguardanti comandi, file di configurazioni, funzioni di sistema e altro. Esempio: man ps
info
- Info è un lettore di ipertesti gnu. Molti programmi hanno la loro documentazione anche in questo formato. Esempio: info grub
whatis
- Cerca la keyword specificata all'interno del database whatis (contiene una breve descrizione di tutti i comandi nel sistema). Equivalente a man -f
apropos
- Come whatis, ma cerca stringhe e non parole complete, di conseguenza può dare risultati più verbosi. Equivalente a man -k
/usr/share/doc /usr/doc
- Le directory dove risiedono generalmente le documentazioni per programmi specifici in diversi formati (txt,html,pdf etc..).
Moltissimi programmi e comandi, inoltre, permettono di visualizzare alcune righe di HELP passando una specifica opzione. Generalmente si utilizzano queste opzioni: comando --help
; comando ?
; comando -h
Ambiente Grafico
L'help in linea nell'interfaccia a finestre e generalmente ben visibile fra le icone sul desktop o le voci dei menu nelle toolbar.
Il nome del collegamento può cambiare a seconda della distribuzione o dell'ambiente desktop, spesso, oltre alla documentazione ufficiale di Gnome o KDE, sono disponibili manuali e documentazione aggiuntiva.
In genere basta cercare un icona chiamata Help (spesso a forma di salvagente) e accedere da interfaccia grafica a tutta la documentazione sul sistema.
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-23 15:40:52
La rete pullula di siti di informazione, gruppi di discussione, mailing list, , forum, chat rooms sul mondo Linux.
E' nella natura stessa di questo sistema operativo lo scambio di informazioni e conoscenze.
Per chi sa sfruttarle valgono quanto il supporto tecnico (a pagamento) di un normale vendor.
Viene qui presentata una breve rassegna di alcuni siti significativi di documentazione su Linux.
Linux Documentation Project (LDP) - E' la collezione più vasta di documentazione su Linux.
Comprende FAQ, HOWTO, MiniHOWTO e i docs sui singoli programmi.
Linux Org - Un buon sito di partenza per reperire tutte le informazioni riguardanti a Linux
linux.html.it - Sezione Linux di HTML.it Docs e istruzioni in italiano.
comp.os.linux.* - E newsgroups linux.* Ottimo punto di partenza, oltre a vari web forum, per ottenere supporto interagire direttamente con altri utenti.
www.google.com - groups.google.com - Google - Sempre lui, probabilmente il migliore motore di ricerca in rete, oltretutto basato su cluster di migliaia di server Linux.
Se si incontra un problema o un errore di qualche tipo, provare a digitarlo così come è scritto: probabilmente si vedranno link a forum online, siti e luoghi dove il problema è stato già incontrato, discusso e risolto.
LINK: Linux Documentation Project - http://www.tldp.org
LINK: Linux.org - http://www.linux.org
LINK: Linux su HTML.it - http://linux.html.it
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2006-07-05 15:54:14
Libri su Linux o argomenti attinenti sono ormai moltissimi, sia in italiano che in inglese.
Si trovano libri generali (con tanto di distribuzione su CDROM allegata) di diverso livello di difficoltà e libri su specifici argomenti, a volte molto dettagliati.
Anche il numero di riviste su Linux, in italiano o inglese, è ragguardevole.
Spesso queste riviste contengono CDROM con le distribuzioni più recenti e sono un'ottimo sistema per testare ed installare nuove distribuzioni senza doverle scaricare dalla rete.
http://www.linuxjournal.com/ - Linux Journal - La prima e la più autorevole rivista su Linux. Disponibile anche in rete.
http://www.oltrelinux.com/ - Linux & C. - La prima rivista in italiano su Linux. Indipendente e ben fatta.
http://www.linuxfocus.org/Italiano/ - La versione italiana di LinuxFocus Magazine
http://www.linux-magazine.it/ - Sito ufficiale di Linux Magazine
http://www.linuxitaly.net/ - La versione italiana di Linux Journal, particolarmente rivolta al mondo business.
http://linux.cassino.edu/lgei/ - La versione italiana di Linux Gazette
http://www.linuxpro.it/ - Linux Pro Rivista su Linux e OpenSource di Future Media.
http://www.linuxpratico.com/ - Linux Pratico Rivista a fascicoli.
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-06-07 17:05:21
La quantità di siti in lingua italiana che trattano di OpenSource e Linux è notevole.
Viene qui presentata una rassegna di quelli più significativi.
Alcuni sono siti di news e commenti, spesso basati sulla piattaforma PHP Nuke, altri sono informativi e divulgativi, altri presentano innumerevoli risorse e informazioni tecniche interessanti.
In tutti non mancano passione e intraprendenza da parte degli autori.
ZIO BUDDHA - www.ziobudda.net - Italian Linux Portal
Uno dei primi e più conosciuti portali italiani su Linux: articoli, news, docs e info.
LINUX.HTML.IT - linux.html.it - Risorse per gli utenti Linux
Una sezione completa di docs, info, software e articoli di HTML.it
LINUX.KUHT.IT - linux.kuht.it - Portale a tutto campo su Linux
Articoli, news, documentazione, link, risorse su Linux. Ottimo.
LINUX VALLEY - www.linuxvalley.it - Portale su Linux
Informazioni, notizie, risorse, documentazioni e prodotti del mondo Linux.
WUP - www.wup.it - L'alternativa italiana a Slashdot
Fra i siti ispirati a Slashdot, WUP è uno dei primi, più completi e più seguiti: Informazioni e news sul mondo informatico che cambia.
FEELING LINUX - www.feelinglinux.com - Documentazione e approfondimenti.
Interessanti articoli sulla amministrazione e la programmazione Linux. Man Pages online.
PLUTO - www.pluto.linux.it - Il Pluto è un gruppo di persone che, unito dalla passione per il software libero, realizza progetti per favorirne lo sviluppo sul territorio italiano.
DIFF - www.diff.org - Il Vortal dei Sistemi Operativi Alternativi
Articoli, news e link su sistemi operativi e tecnologie informatiche alternative.
SPLATT - www.splatt.it - Articoli e notizie sul mondo PHP Nuke.
Un buon punto di riferimento sull'universo Nuke e sul software Splatt Forum.
FREEX.CH - www.freex.ch - News su Opensource e dintorni.
Sito Nuke con notizie, informazioni e articoli sull'opensource e il mondo IT.
ITALINUX - www.italinux.net - News su Linux.
Sito Nuke on informazioni e notizie su Linux.
LINUX TOOLS - www.linux.it/ospiti/linuxtools/ - La bussola italiana del mondo Linux.
Completo elenco ragionato di link sull'universo Linux.
LINUX A SCUOLA - www.linuxascuola.it - Info per scuole.
Informazioni sull'uso di Linux nelle scuole.
INFORMATICA E GNU/LINUX - vandali.org/DanieleMasini/infolinux.php - E-Book FDL.
Completo e interessante e-book su Hardware, Informatica e Linux.
Questo elenco è in costante aggiornamento.
Usa i commenti di questo INFOBOX per segnalare ulteriori siti.
Tipo Infobox: TIPS - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-18 23:09:21
Se non ci si accontenta di libri, siti e riviste e si vuole il contatto umano per approfondire la propria conoscenza su Linux, il LUG (Linux User Group) locale può essere l'ideale.
Un LUG è una associazione di persone che hanno Linux come hobby e interesse comune.
Nei LUG si organizzano incontri, corsi, party, install fest ecc, oltre a promuovere la diffusione e l'alfabetizzazione di Linux.
In Italia esistono parecchi LUG locali e la Italian Linux Society (ILS) che, fra le altre attività, ogni anno organizzano un Linux Day in cui si propone e presenta Linux a chi ancora non lo conosce.
LINK: Elenco LUG italiani - http://www.linux.it/LUG/
LINK: Elenco LUG nel mondo - http://www.linux.org/groups/
LINK: Italian Linux Society - http://www.linux.it
Linux Software |
Risorse e informazione su dove trovare software per Linux |
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-09-20 12:44:15
Pochi link al software per Linux. Quelli essenziali.
Il sito ufficiale del kernel Linux: http://www.kernel.org - Home Page ufficiale del kernel
Le distribuzioni più diffuse: http://www.linuxlinks.com/Distributions -
Tutte le distribuzioni Linux: http://www.distrowatch.com/ - Distrowatch
Carne fresca. Software abbondante: http://freshmeat.net/ - Freshmeat
Due mucche e tanto software. Ben catalogato: http://linux.tucows.com/ - Tucows Linux
Officina di sviluppo di codice opensource: http://www.sourceforge.org/ - Sourceforge
Computer/Software/OS/Linux . Su dmoz. http://dmoz.org/Computers/Software/Operating_Systems/Linux/ - Dmoz
RPM repository: http://rpmfind.net - Rpmfind
LINK: Il sito ufficiale del kernel - http://www.kernel.org
LINK: Le distribuzioni più diffuse - http://www.linuxlinks.com/Distributions
LINK: Freshmeat. - http://freshmeat.net/
LINK: DMOZ: Computer/Software/OS/Linux - http://dmoz.org/Computers/Software/Operating_Systems/Linux/
(F)AQ: Dove trovo link su Linux? -
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-10-15 15:57:05
Viene qui fatta una rassegna essenziale del software che viene maggiormente utilizzato per gestire servizi comuni su un server. Va vista come indicazione sui software mainstream, quelli più diffusi e sui quali più facilmente ci si può trovare ad operare.
Quasi tutti i prodotti sotto elencati sono Open Source e disponibili su Linux come su altre piattaforme. Windows Incluso.
File sharing
Samba Windows networking. Condivisione di file e stampanti, avanzata e performante compatibilità con NetBios.
NFS Server File sharing attraverso il protocollo NFS, richiede un kernel con tale supporto abilitato.
Web Server e Application Server
Apache Il server web utilizzato dal 60% dei siti Internet. Flessibile ed estendibile con moduli.
Tomcat Java Application Server del progetto Apache. Interessante ma poco performante.
PHP HTML embedded scripting language. L'alternativa OpenSource ad ASP di Microsoft. Molto diffuso.
Mod Perl Modulo PERL per Apache. Fondamentale per chi sviluppa in Perl.
Mail & News Server
Sendmail SMTP server, cresciuto con la Rete. Molto utilizzato, molto flessibile.
Postfix Alternativa SMTP a Sendmail. Facilmente configurabile. Con enfasi sulla sicurezza.
Qmail Altro SMTP server alternativo a Sendmail. Dal design recente e sicuro.
INN Server NEWS dell'ISC.
DNS & DHCPD
Bind Il server di DNS più utilizzato. Presente in tutte le distribuzioni.
Dhcpd Il server DHCP dell'Internet Software Consortium, incluso in tutte le distribuzioni disponibili sul mercato.
DB Server & LDAP
MySQL SQL server Open Source. Molto veloce, con qualche limitazione sulle funzioni più complesse.
PostgreSQL Alternativa a Mysql, prodotto Open Source.
Openldap L'implementazione Open Source di Ldap.
Oracle ormai ben supportato e certificabile su Linux.
Altri servizi: FTP, WEB CACHE...
Wu-ftpd, proftpd, vsftpd Diversi comuni FTP server.
Squid Proxy server. Web cache engine. La soluzione OpenSource più diffusa.
VNC Virtual Netwrok Computing. Per gestire macchine remote tramite interfaccia grafica.
Lotus Domino/Notes la versione per Linux viene sviluappta di pari passo con quella Windows.
LINK: Samba Home Page - http://www.samba.org
LINK: Apache Home Page - http://www.apache.org
LINK: Php Home Page - http://www.php.net
LINK: OpenLDAP Home Page - http://www.openldap.org
LINK: Sendmail Home Page - http://www.sendmail.org
LINK: MySQL Home Page - http://www.mysql.org
LINK: PostgreSQL Home Page - http://www.postgresql.org
LINK: ISC Bind Home Page - http://www.isc.org/products/BIND/
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-10-15 23:50:44
L'aspetto sicurezza è fondamentale su ogni sistema operativo utilizzato in rete.
In questa pagina è presente una rassegna indicativa di strumenti di security disponibili su Linux (e, come sempre, anche su altre piattaforme, in particolare Unix).
La gamma dei prodotti, gratuiti e commerciali, è molto più ampia ed in continua crescita.
Questa lista da una indicazione dei progetti più noti.
SNIFFER
Tcpdump Sniffer incluso nella maggior parte delle distribuzioni, comandi semplici con la possibilità di utilizzare filtri. Analizza le intestazioni dei pacchetti, non il payload.
Ethereal Packet sniffer, analyzer & decoder. Su interfaccia a finestre.
Ettercap Sniffer per ambienti switchati.
FIREWALL
Ipchains Le utility per gestire il firewalling sui kernel pre 2.4.
Iptables Evoluzione di ipchains, gestisce il modulo netfilter del kernel 2.4
Shorewall Tool per configurare e gestire in modo semplice le iptables
IDS
Snort Network intrusion detection system, che genera alert sulla base di un database di fingerprints in costante aggiornamento.
Tripwire Host Intrusion Detection System: monitora le modifiche sui file di sistema.
Ossim Open Source Security Information Management: raccoglie e organizza le informazioni di diversi software di montoraggio e IDS
Monitoring
Nagios Sistema di monitoring e alerting dei servizi attivi in una rete, con report via web
Mrtg Non direttamente attinenete la sicurezza. Crea grafici sulla base di MIB SNMP. Molto utilizzato per visualizzare l'occupazione di banda.
Ntop Strumento di analisi del traffico di rete con ottima interfaccia web/testuale. Sviluppato dall'italiano Luca Deri.
Criptazione e VPN
mod_ssl Modulo di Apache per implementare il protocollo https.
Openssh Implementazione opensource dei protocolli criptati ssh1e ssh2.
OpenSWAN Implementazione opensource per il supporto di VPN IPSEC.
PoPtop Implementazione OpenSource del protocollo di tunneling PPTP.
Cipe Software per VPN basate su un protocollo non standard.
Network Scanners
Nmap Port scanner veloce e flessibile.
Nessus Security scanner, basato su un ampio database di vulnerabilità in costante aggiornamento.
LINK: YoLinux: List of Linux Security and Hacker Software Tools - http://www.yolinux.com/TUTORIALS/LinuxSecurityTools.html
LINK: Linux Security Portal - http://www.linuxsecurity.com/
LINK: Incidents.org Mappa in tempo reali di attacchi in rete - http://www.incidents.org/
LINK: The table of equivalents / replacements / analogs of Windows software in Linux. - http://linuxshop.ru/linuxbegin/win-lin-soft-en/
Capire il file system di un sistema operativo è fondamentale per conoscerlo e gestirlo ad un livello più approfondito di quella che può essere la normale utilizzo del computer, lato desktop. Nel caso di Linux, inoltre, questo aspetto è particolarmente importante quando si opera con la shell, in modalità testuale.
La logica del file system (FS) Linux è fortemente legata a quella di ogni Unix.
Quanto viene qui esposto si applica, per gran parte, a qualsiasi Unix.
Avremo modo di tornare a divagare sulla bellezza intrinseca di un sistema Unix, sulla sua elementare complessità, l'apparente caos di file e directory che, una volta carpiti i pochi segreti fondamentali, si rivela in tutta la sua esplicita profondità, lasciando all'utente una visione estesa, complessiva, totale di cosa succede sul proprio computer e di come il sistema operativo si adatta, riconosce e gestisce l'hardware.
Prima vediamo argomenti più prosaici:
FILE, DIRECTORY E GERARCHIA FILE SYSTEM
E' fondamentale capire la logica del file system Linux, il concetto di directory root ( / ), un' idea degli utilizzi e la funzione delle altre directory.
Conoscere i comandi tipici di elenco (ls), gestione file (cp, rm, mv, mkdir, rmdir) e gestione link è altresì necessario, pur non essendo indispensabile conoscerne gli innumerevoli (spesso utili) parametri.
Per approfondimenti: Gestire file, directory e link
VISUALIZZARE FILE
Sono disponibili diversi comandi per vedere il contenuto di un file.
Alcuni sono usati molto spesso (cat, less, tail), altri si rivelano utili quando si deve investigarne la natura (file, strings).
I dettagli in Leggere e visualizzare file
FORMATTAZIONE E MOUNT DI NUOVI FILE SYSTEM
Qualsiasi tipo di file system, presente su qualsiasi supporto (hard disk secondario, floppy, cdrom, condivisione di rete...) può essere "montato" all'interno di una sottodirectory della root.
Il sistemista Linux deve avere dimestichezza con le operazioni di mount, formattazione e gestione di file system e device di storage.
Approfondimenti in Gestione dei file system
ATTRIBUTI E PERMESSI
Su Unix/Linux, come su Windows NT, 2000 e XP, ogni file è posseduto da un utente del sistema e da un gruppo di utenti e può avere diversi attributi per gestire i permessi di scrittura, lettura ed esecuzione.
La logica degli "owner" e dei permessi sui file e i comandi per gestirli (chown, chgrp, chmod) sono comuni ad ogni sistema Unix e devono essere ben padroneggiati da ogni amministratore di sistema.
Moltissime problematiche di natura sistemistica di fatto sono dovute a problemi di permessi sul file system da parte degli utenti di sistema con cui sono in esecuzione le varie applicazione, per cui è fondamentale comprendere la logica dei permessi e il modo con cui modificarli.
Per saperne di più: Attributi e permessi
CERCARE FILE
Un motivo di diffcoltà ricorrente per il sistemista non esperto è capire dove stanno i file di configurazione, i programmi, i log e orientarsi nel groviglio della struttura delle directory.
Esistono comandi che permettono di trovare file o informazioni (whatis, whereis, locate, apropos) e di eseguire ricerche complesse sul file system (find).
Sono inoltre estremamente utili dei comandi "filtro", che permettono di visualizzare solo quello che ci intreressa di una serie di righe di output. Alcuni sono usati spessissimo e vanno ben compresi (grep, sort), altri risultano utili in condizioni specifiche ed è bene sapere che esistono (cut, wc, tr) e altri ancora sono estremamente flessibili, potenti e complessi (sed, awk).
Dettagli in Ricerca, confronto e filtri
Gestire file, directory e links |
Capire, muoversi e modificare file e directory: /, .., . , cd, ls, cp, mv, rm, rmdir, mkdir. Uso di link e symlink. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-28 19:33:54
Il file system di un sistema Linux, come ogni Unix, ha una struttura gerarchica: tutti i suoi oggetti (file e directory) sono contenuti all'interno della root ( la directory principale, indicata semplicemente con "/
" (barra) ) e lo stesso carattere / viene usato per separare i nomi delle directory ( Ad esempio /usr/bin/
indica la directory bin
contenuta nella directory usr
contenuta nella root (/
).
La root contiente non soltanto TUTTE le altre directory di una partizione ma TUTTI i filesystem eventualmente montati sul sistema (partizioni e hard disk diversi, floppy, cdrom, condivisioni di rete ecc.).
Il principio è radicalmente diverso da quello presente nel mondo Windows, dove ogni device o risorsa ha un suo nome o lettera identificativa (A:, C:, D: ecc) al cui interno si trovano le directory del relativo filesystem.
Su molti Linux, ad esempio, i file contenuti in un floppy disk si trovano in una directory chiamata /mnt/floppy
e non in qualcosa chiamato A:
come su Windows. Il nome di questa directory, oltretutto, può cambiare ed essere decisa arbitrariamente dall'utente o da chi ha realizzato la distribuzione (ovviamente esistono metodi per sapere in quale directory viene montato qualsiasi dispositivo).
Esistono alcune notazioni standard Unix per indicare la directory corrente, la directory padre, la home directory ecc.
E' opportuno conoscere bene queste convenzioni in quanto sono comunemente utilizzate in attività sistemistiche:
/
Come sopra riferito, indica la root, la directory principale alla base di tutto il filesystem
/bin/
Indica la sottodirectory bin (una arbitraria), alla root
bin/
Indica la sottodirectory bin rispetto alla dir corrente. Notare che se il path inizia con una / indica un path assoluto, che inizia dalla root ( /, appunto). Se non inizia con / indica un path relativo alla directory in cui ci si trova.
.
Indica la directory corrente
..
Indica la directory madre di quella in cui ci si trova
../bin/
Indica la sottodirectory bin che si trova allo stesso livello della dir corrente.
~
La home directory dell'utente corrente (coincide di default con /home/login_utente
Un path assoluto, quindi, avrà un simile aspetto: /usr/local/bin
e sarà funzionante in qualsiasi directory in cui ci si trova.
Un path relativo ha aspetto simile a local/bin
e indica directory diverse a seconda della directory in cui ci si trova. In questo caso local/bin coincide con /usr/local/bin
solo se ci si trova in /usr/
Comandi comuni
I comandi di gestione dei file su Unix sono paragonabili agli equivalenti di altri sistemi operativi a riga di comando come DOS. Tutti questi comandi, come tradizione Unix, hanno varie opzioni che possono ampliare notevolmente le potenzialità del comando stesso.
ls
Visualizza il contenuto di una directory (equivale a dir su Dos e in alcuni Linux esiste anche un alia di ls che si chiama proprio dir
);
cd
Cambia la directory corrente. Corrisponde all'omonimo cd su DOS.
cp
Esegue la copia di uno o più file. Corrisponde al copy di DOS.
mv
Esegue lo spostamente o la rinomicanzione di un file. Corrisponde a move e rename su DOS.
rm
Cancella uno o più file (fare attenzione: su molti Unix e Linux non è previsto l'equivalente di un cestino: se un file viene cancellato risulta poi piuttosto complesso recuperarlo). Corrisponde al del di DOS.
mkdir
e rmdir
Rispettivamente vengono usati per creare e cancellare una directory vuota.
ln
Viene usato per create un link, hard o soft (con l'opzione ln -s
).
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-24 20:55:36
La struttura delle directory in un sistema Linux ha molte caratteristiche comuni a quella di altri sistemi Unix.
Sotto vengono riportare le directory principale e più comuni su Unix diversi, altre directory possono avere nomi o funzionalità diverse in Unix diversi (e anche in distribuzioni Linux diverse).
/
Radice (root). La directory principale che contiene tutte le altre.
/root
Home dell'utente root, da non confondere con la root ( / ), che è la directory principale e non una directory che si chiama /root
/boot
Contiene tutte le immagini del kernel e file indispensabili al bootstrap del sistema
/etc
Contiene i file di configurazione del sistema e dei programmi installati
/home
Contiene le home directory degli utenti normali (tutti tranne l'utente root)
/usr
Contiene binari, documentazione, librerie e sorgenti della maggior parte dei programmi (e i sorgenti del kernel)
/var
Contiene tutti file che hanno informazioni dinamiche, che tendono a modificarsi con il tempo: log, file di pid e lock dei processi in esecuzione, directory di spool (stampa, mail...) ecc.
/proc
File system virtuale, generato in tempo reale dal kernel. Contiene, come se fossero file e directory, dati dinamici sul sistema e sui processi
/dev
Contiene file speciali, che corrispondono a dispositivi hardware o a funzionalità particolari. Tramite di essi si può accedere al relativo device hardware.
/sbin
Contiene comandi e programmi riservati a root ( altri comandi sono in /usr/sbin/
)
/bin
Contiene comandi e programmi base per tutti gli utenti (altri comandi sono in /usr/bin/
)
SWAP
Non è una directory ma una partizione speciale, utilizzata come memoria virtuale.
SOURCE: Filesystems, Directories, and Devices NHF ver. 1.0 - http://www.linuxnewbie.org/nhf/Filesystems/Filesystems_Directories_and_Devices.html
(F)AQ: Quali sono le principali directory in Linux? -
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-24 23:04:40
I sistemi Unix fanno largo uso di link: dei file speciali che sono semplici collegamenti o alias di file esistenti.
Servono per identificare lo stesso file o directory con nomi diversi, avendo anche path diversi.
Su Unix esistono due tipi di link: Hard link e Symbolic link.
L'effetto che hanno è lo stesso, ma la loro natura è diversa e si adattano a diversi utilizzi.
L'utilità dei link è varia:
- Se si devono modificare diversi file uguali, in diverse directory, con l'uso di link la modifica fatta su un file diventa immediatamente effettiva anche sugli altri file (link) (Es: la struttura di /etc/rc.* ) .
- Se si devono poter gestire contemporaneamente diversi ambienti o programmi con diverse versioni, si può cambiare solo il puntamento del link usato per accedere a questi ambienti per poter switchare rapidamente da uno all'altro (es: /usr/src/linux )
- Se si devono gestire diverse alternative dello stesso comando, si può usare un link per referenziare il comando con un nome fisso e poi cambiare il puntamento per valutare in tempi brevi le diverse alternative (ex: Directory /etc/alternatives in RedHat Linux).
Hard Link
Sono di fatto una copia di una voce di directory, hanno nomi diversi ma puntano allo stesso inode e quindi condividono esattamente lo stesso dato (oltre agli stessi permessi, data di modifica, owner ecc.).
Dal momento che originale e link sono indistinguibili e condividono lo stesso inode, non si possono fare hard link fra file system diversi e, in genere su Unix, su directory (su Linux è possibile creare un hard link ad una directory tramite l'opzione speciale -d).
Pur essendo la gestione dei link comunque molto rapida da parte del kernel, gli hard link sono leggermente più "economici" in quanto risparmiano più spazio su disco (stesso i-node, stessi dati) e richiedono una lettura in meno sul file system (i symlink hanno i-node diverso e puntatore, che va letto, ad un altro file).
Symbolic Link o Symlink
Sono dei piccoli file che contengono un puntamento ad altri file o directory. Questi file hanno i-node autonomo e possono puntare a file di altri file system (sia locali, che di rete). Si possono facilmente visualizzare con un normale ls -l e se viene cancellato o spostato il file a cui puntano rimangono "stale": continuano ad esistere ma puntano a qualcosa che non esiste.
I symlink sono generalmente molto più utilizzati nell'amministrazione di sistemi Unix e corrispondono come concetto e come implementazione ai collegamenti (shortcut) del mondo Windows.
Un symlink appare come avente tutti i permessi aperti a tutti gli utenti, di fatto è trasparente rispetto a permessi e ownership e riflette quelli del file o directory a cui punta.
LINK: Interessante articolo: When Hard Links Won't Do the Job - http://www.itworld.com/nl/unix_sys_adm/06062001/pf_index.html
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-24 22:25:58
La logica del file system Unix è semplice, elegante e potente, alcune sue caratteristiche sono comuni al DOS, altre all'antico MULTICS, altre sono uniche.
Le directory, a livello di sistema, sono trattate come dei file che invece di contenere dei dati contengono altri file o directory; per il sistema sono tutti i-node, che hanno in due parti separati il loro descriptor (nome, attributi, permessi ecc) dal contenuto (il dato presente nel file, o, nel caso di una directory, l'elenco dei file che contiene).
I file possono avere qualsiasi carattere (escluso NUL) nel nome, anche caratteri speciali per la shell o spazi e CR (Carriage Return).
Le estensioni non hanno nessuno specifico significato: sono usate per comodità da alcuni comandi ma non sono indispensabili e, a livello del file system, nemmeno identificative del tipo di file.
Una tipica partizione Unix contiene un file system così organizzato:
- Blocco 0, non usato da Unix, a volte usato per il boot del sistema (è l'MBR se si trova sul device primario);
- Blocco 1 o superblock, contiene informazioni critiche sulla struttura del file system (numero di i-node, numero di blocchi del disco ecc);
- Elenco degli I-node, numerati da 1 a un numero finito, che contengono le informazioni sui singoli file presenti nel file system e sulla posizione dei rispettivi dati;
- Blocchi dei dati, con i dati effettivi contenuti nel file.
Gli i-node contengono informazioni quali: tipo di file, permessi, data di creazione, modifica, ultimo accesso, utente e gruppo proprietari, posizione e dimensione del file ecc.
Tramite l'uso di link è possibile fare in modo che lo stesso i-node sia condiviso di diversi oggetti nel filesystem.
Linux di default supporta il file-system ext2 che ha molte caratteristiche in comune con un tipico file system Unix System V. Il kernel di Linux comunque permette l'uso di molti altri file system come ext3, reiserFS, jfs (file system giornalistici, che tengono un log di tutte le operazioni di scrittura per permettere un recupero dei dati più agevole in caso di guasti), i file system di Windows (fat, fat32, ntfs) e quelli di molti altri sistemi operativi (BeOs, AmigaOs, Mac, ecc), oltre a file system di rete come NFS, SMB, Novell.
SOURCE: Libro: "I moderni sistemi operativi" di Andrew Tanenbaum -
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-24 23:57:24
Visualizza il contenuto di una directory. Corrisponde al "dir" di Windows.
Comando comune in tutti gli Unix, a volte con opzioni diverse.
Se non viene specificata alcuna directory, indica i file nella directory corrente.
ls [opzioni] [file]
-a
Visualizza tutti i file, anche quelli nascosti (che iniziano con un punto: .)
-l
(--format=long) Visualizza informazioni aggiuntive quali data di modifica, permessi, owner e group
-i
(--inode) Visualizza anche l'inode dei file
-f
Non esegue alcun ordinamento di file e li visualizza nell'ordine con cui sono stati memorizzati (di default ls fa un elenco in ordine alfabetico)
-t
(--sort=time) Ordina l'elenco dei file secondo la data di modifica
-u
(--time=access) Ordina l'elenco dei file secondo la data di ultimo accesso
-S
(--tsort=size) Ordina l'elenco dei file secondo la dimensione
-r
(--reverse) Ordina in senso inverso l'output dei file (da usare con -t, -u, -S ecc.)
-X
(----sort=extension) Ordina i file per estensione
-R
(--recursive) Elenca ricorsivamente tutte le sottodirectory e i file ivi contenuti, rispetto alla directory specificata (o corrente)
-I pattern
(--ignore pattern) Non visualizza i file che matchano il pattern specificato
Esempi
ls -lS /var/spool/mail
Esegue un listing esteso dei file contenuti in /var/spool/mail ordinandoli secondo dimensioni dal più grande al più piccolo.
ls -ltr /var/log
Elenca i file contenuti nella directory /var/log secondo data di modifica inversa: dal più vecchio al più recente.
ls -a ~
Elenca tutti i file (anche quelli nascosti, preceduti da un .) presenti nella propria home directory.
SOURCE: Man Pages - http://man.openskills.info/ls
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-23 15:43:07
E' il comando per cambiare la directory corrente, cioè, in pratica, per spostarsi in una directory diversa da quella in cui ci si trova (usare il comando pwd
er visualizzare la directory corrente).
E' presente in tutti gli Unix e non è un comando a se stante (non è possibile trovarne il file binario) in quanto incorporato nella shell (BUILT IN COMMAND).
cd [directory]
Si aspetta come argomento il nome di una directory in cui spostarsi, se non ne viene specificata alcuna, entra, di default, nella home directory dell'utente.
Esempi
cd /
Cambia la directory corrente nella root.
cd ../
Si sposta nella directory padre di quella in cui ci si trova.
cd bin
Si sposta nella sottodirectory bin rispetto alla directory corrente.
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-25 14:52:03
Copia file e directory. Comando flessibile che permette di copiare sia un file su una destinazione data, sia un numero arbitrario di file su una directory d'arrivo. Può essere utile anche come strumento di backup e in script.
E' comune in tutti gli Unix ma alcuni parametri possono variare.
cp [opzioni] sorgente destinazione
cp [opzioni] sorgenti... directory_destinazione
OPZIONI POSIX (Valide in tutti gli Unix)
-f
(--force) Forza la copia, rimuovendo i file di destinazione preesistenti, se esistenti.
-i
(--interactive) Chiede conferma prima di sovrascrivere i file di destinazione (il cp su linux è solitamente un alias di cp -i, per cui di default viene chiesta la conferma alla sovrascrittura)
-p
(--preserve) Preserva gli attributi dei file copiati (owner, group, permessi, data di ultima modifica e data di ultimo accesso).
-R
(--recursive) Copia le directory ricorsivamente (include file e sottodirectory) rispettando l'integrità di file speciali.
OPZIONI GNU (Tipiche di Linux e altri Unix che usano la versione GNU di cp)
-a
(--archive) Corrisponde a cp -dpR e conserva nella copia quanto possibile la struttura e gli attributi dei file originali. Da usare quando si intende fare il backup di directory e file.
-d
(--no-dereference) Copia link simbolici come link simbolici piuttosto che copiare i file da essi puntati, e conserva la relazione di hard link tra i file originali anche nelle copie.
-s
(--symbolic-link) Crea un link simbolico invece della copia vera e propria dei file o directory.
-u
(--update) Nel caso il file di destinazione esiste già, lo sovrascrive solo se ha data di modifica più vecchia.
-v
(--verbose) Stampa il nome di ogni file prima di copiarlo.
-b
(--backup) Crea copie di backup dei file che stanno per essere sovrascritti o rimossi.
-S SUFFISSO
Aggiunge il SUFFISSO specificato a tutti file di backup.
Esempi
cp -a /etc /backup/
Copia tutta la directory /etc e i suoi contenuti nella directory /backup. Mantiene i link simbolici e i permessi inalterati.
cp /etc/grub.conf /tmp/
Copia il file /etc/grub.conf nella directory /tmp. Se /etc/grub.conf è un symlink, in /tmp/ si ritrova una copia del file a cui il link punta e non un symlink.
SOURCE: Man Pages - http://man.openskills.info/cp
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-25 15:11:10
Cancella file o directory.
E' comune in tutti gli Unix ma alcuni parametri possono variare.
ATTENZIONE: IN UNIX NON ESISTE IL "CESTINO", QUANDO UN FILE VIENE CANCELLATO NON E' POSSIBILE RECUPERARLO FACILMENTE! (Ci sono comunque dei metodi per recuperare dei file cancellati, ma non sono semplicissimi).
Per poter cancellare un file è necessario avere permessi in scrittura sulla directory che lo contiene, ma NON E' NECESSARIO AVERLI SUL FILE stesso (se non si hanno permessi di scrittura sul file che si vuole cancellare, e che si trova in una directory dove si può scrivere, viene semplicemente richiesta una conferma prima della cancellazione).
Se si vuole cancellare un file in modo definitivo, rendendo impossibile un suo recupero, utilizzare il comando shred
.
rm [opzioni] file
-f
(--force) Forza la rimozione senza richiesta di conferma.
-i
(--interactive) Chiede conferma prima di cancellare i file
-R
(-r , --recursive) Se viene indicata una directory la cancella con tutto il suo contenuto (USARE CON CAUTELA)
ATTENZIONE a usare certe opzioni di rm, un comando come rm -rf /* se eseguito come root cancella brutalmente tutto il file system (in realtà ad un certo punto la cancellazione si blocca perchè vengono cancellati alcuni file vitali al funzionamento corrente del sistema, ma il risultato è comunque catastrofico e irreparabile).
Esempi
rm -rf /tmp
Cancella tutta la directory /tmp
rm -rf /tmp/*
Cancella tutti i file contenuti nella directory /tmp (la directroy rimane vuota)
SOURCE: Man Pages - http://man.openskills.info/rm
LINK: Deleted files recovery howto - http://e2undel.sourceforge.net/recovery-howto.html
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-25 15:05:33
Sposta o rinomina un file o una directory.
E' un comando comune a tutti gli Unix (con opzioni che possono variare). Notare che su Unix non esiste il corrispondente del comando "rename" di Windows. Il cambiamento di nome di un file viene fatto semplicemente "spostandolo" in un file con nome diverso.
mv [opzioni] sorgente destinazione
mv [opzioni] sorgenti... directory_destinazione
-f
(--force) Forza lo spostamento, sovrascrivendo i file di destinazione preesistenti, se esistono.
-i
(--interactive) Chiede conferma prima di sovrascrivere i file di destinazione (il mv su Linux è solitamente un alias di mv -i, per cui di default viene chiesta la conferma alla sovrascrittura)
-u
(--update) Nel caso il file di destinazione esiste già, lo sovrascrive solo se ha data di modifica più vecchia.
-v
(--verbose) Stampa il nome di ogni file prima di spostarlo.
-b
(--backup) Crea copie di backup dei file che stanno per essere sovrascritti o rimossi.
-S SUFFISSO
Aggiunge il SUFFISSO specificato a tutti file di backup.
Esempi
Il comportamento di mv varia a seconda della natura di sorgente e destinazione, seguono alcuni esempi generici, se risultano poco chiari fare pratica sul proprio sistema, è sempre il metodo migliore:
mv /directory/file /directory/file_nuovo
(Rinomina file in file_nuovo)
mv /directory/file /directory/file_esistente
(Sovrascrive file_esistente con file)
mv /directory/file /directory/subdirectory_esistente
(Sposta file all'interno di subdirectory_esistente)
mv /directory/subdirectory /directory/subdirectory_nuova
(Rinomina subdirectory)
mv /directory/subdirectory /subdirectory_nuova
(Sposta, e rinomina, subdirectory)
mv /directory/subdirectory /directory/subdirectory_esistente
(Sposta subdirectory all'interno di subdirectory_esistente)
SOURCE: Man Pages - http://man.openskills.info/mv
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-27 11:46:08
Rimuove directory (ma non il loro contenuto).
Comando comune a tutti gli Unix.
Non cancella directory non vuote, per il quale è necessario un comando tipo rm -R
rmdir [opzioni] directory
-p
(--parents) Rimuove la directory specificata e ogni directory genitore che dovesse essere rimasta vuota.
--verbose
Modalità verbosa: per ogni directory rimossa stampa un messaggio
Esempi
rmdir /tmp/nuova
Rimuove la sottodirectory "nuova" all'interno di /tmp (ma solo se nuova non contiene file.
SOURCE: Man Pages - http://man.openskills.info/rmdir
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-27 11:36:22
Crea una o più directory. E' necessario avere permessi di scrittura nella directory in cui si vogliono creare nuove sotto directory. Comune in tutti gli Unix.
mkdir [opzioni] directory
-m ###
(--mode ###) Specifica i permessi della directiry creata (di default sono 777).
-p
(--parent) Crea le directory padre intermedie, nel caso non esistano. (es: mkdir -p /usr/local/test/my/dire crea la directory dire e anche le directory my, test, local, usr nel caso non esistano)
Esempi
mkdir -p temp/test/prova/nuova
Crea tutte le directory e sottodirectory indicate (anche se non esistono) rispetto alla posizione corrente. Senza l'opzione -p la directory "nuova" si poteva creare se esistevano già tutte le precedenti.
mkdir /tmp/nuova
Crea la directory "nuova" all'interno di /tmp.
SOURCE: Man Pages - http://man.openskills.info/mkdir
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-24 23:51:21
Crea un link al file specificato. Il link è un alias, uno pseudonimo, un secondo nome con cui un file può essere richiamato, oltre che con il suo nome principale.
ln è un comando comune in tutti gli Unix, la differenza fra hard e soft link è presente in tutti gli Unix.
ln [opzioni] nome_file_puntato [nome_link]
ln [opzioni] nomi sorgente directory destinazione
Nel primo caso se nome_file_puntato è un file, viene riscritto, se non viene specificato, viene creato nella directory corrente un link con il nome_sorgente (senza path).
Nel secondo caso è possibile specificare più file sorgenti e una directory di destinazione in cui vengono creati altrettanti alias con lo stesso nome.
-s
(--symbolic) Crea un link simbolico e non un hard-link. Opzione molto utilizzata.
-b
(--backup) Esegue una copia di backup dei file di destinazione, prima di cancellarli (se esistono).
Esempi
ln -s /usr/sbin/sendmail.postfix /usr/sbin/sendmail
Crea un link simbolico chiamato /usr/sbin/sendmail che punta al file /usr/sbin/sendmail.postfix
ln -s /etc/passwd
Crea, nella directory corrente, un link simbolico chiamato passwd che punta al file /etc/passwd
ln /etc/passwd /etc/shadow /etc/group /backup/
Crea 3 hardlink chiamati passwd, shadow e group nella directory /backup/ che puntano ai rispettivi file nella directory etc.
SOURCE: Man Pages - http://man.openskills.info/ln
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2004-05-23 15:43:42
E' un comando che permette di visualizzare informazioni utili sui file come dimensione, permessi, inode, owner, data di ultimo accesso, di creazione e di modifica. In pratica tutto quello che è necessario conoscere di un file.
Ha opzioni, inoltre, che forniscono informazioni sul file system che contiene il file e che permettono di esportare i dati in modo sequenziale e poco user friendly ma comodo per essere gestiti all'interno di script.
stat [-l] [-f] [-v] [-t] file-name [file-name]...
-l
Flag da utilizzare per i links
-f
Visualizza le informazioni del file system che contiene il file
-t
Visualizza lo stdout in modo tale da essere processato da un secondo programma o comando
Esempi
stat /etc/rc.local
Fornisce informazioni, in formato "human readable" sul file /etc/rc.local (nel nostro caso un link simbolico)
stat -l /etc/rc.local
Fornisce informazioni sul file a cui punta il link simbolico /etc/rc.local
stat -t /etc/group
Fornisce informazioni su /etc/group dando solo l'elenco dei risultati senza specificarne la natura, utile per "passare" il risultato ad un altro comando all'interno di uno script.
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-27 11:50:38
Visualizza ricorsivamente l'elenco dei file e delle sottodirectory rispetto alla directory indicata (quella corrente, se non viene specificata).
L'output è ad albero e indica chiaramente la gerarchia delle directory.
tree [opzioni] [directory]
-a
Visualizza tutti i file, anche quelli nascosti.
-d
Visualizza solo le directory
-s
Visualizza anche le dimensioni di ogni file
-p
Visualizza anche i permessi di ogni file
-D
Visualizza anche la data di modifica di ogni file
-u
Visualizza anche l'owner di ogni file
Esempi
tree
Visualizza l'albero delle directory a partire dalla directory corrente.
tree -ap /etc
Visualizza l'albero delle directory all'interno di /etc includendo tutti i file nascosti ed evidenziando i permessi di ogni file
tree -ud /
Visualizza l'elenco di tutte le directiry (escludendo quindii file) e il rispettivo owner all'interno di tutto il filesystem
SOURCE: Man Pages - http://man.openskills.info/tree
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-27 11:28:06
Cambia il tempo di accesso e modifica di un file, di fatto fa quello che dice: "tocca un file senza modificarne i contenuti.
Se il file non esiste ne crea uno nuovo di dimensioni zero.
Comando comune a tutti gli Unix.
touch [opzioni] [data] files
data
La data è quella corrente se non specificata, altrimenti va inserita nel formato mmddhhmm[yy]
-a
Aggiorna solamente l'access time.
-m
Aggiorna solamente il modify time.
Esempi
touch /tmp/nuovo
Crea un file chiamato /tmp/nuovo di 0 byte e data di modifica e ultimo accesso attuale
touch /etc/group
Cambia la data di modifica e ultimo accesso a quella attuale.
SOURCE: Man Pages - http://man.openskills.info/touch
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-03-06 02:01:55
Midnight Commander è un file manager definito anche una Visual Shell per sistemi Unix, utile sui server dove spesso X non viene utilizzato. Ha una logica e un aspetto molto simile al vecchio Norton Commander per DOS.
E' possibile lanciare Midnight Commander in una shell tramite il comando mc
. Questo software una volta avviato presenta un pannello di controllo diviso in quattro parti. Due pannelli più grandi in cui vengono visualizzati i file contenuti nella directory in cui ci si trova al momento dell'esecuzione, la linea di comando, e dei menu richiamabili tramite tasti funzione F1-F10.
Il programma può essere utilizzato anche mediante i menu a tendina, e con l'ausilio del mouse, quest'ultimo non solo in locale ma anche in remoto tramite connessioni via telnet o ssh.
Tra le caratteristiche di questo file manager, la possibilita' di montare directory FTP, visualizzare file tar, DEB ed RPM con possibilita' di estrarne singoli file, ed infine eseguire l'undeleting di file su partizioni di tipo EXT2.
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-24 23:07:30
Può capitare di avere un sistema installato su più partizioni di un hard disk e ritrovarsi con un utilizzo non omogeneo dello spazio su disco libero.
In tempi rapidi, usando dei symlink, si possono mettere delle rapide "pezze" senza dover ridimensionare le partizioni o aggiungere hard disk.
Analizziamo questo esempio:
[root@socrate al]# df -k
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda5 1682664 1254556 342632 79% /
/dev/hda1 19487 6793 11688 37% /boot
none 258400 0 258400 0% /dev/shm
/dev/hda2 1512000 74880 1360312 6% /var
Ipotizziamo di dover copiare da un CDROM in /home/bigdata
di questo sistema una grande quantità di dati, più di quanto possa essere contenuto nella /
, che si trova nella stessa partizione ormai piena al 79%.
Una rapida soluzione può essere copiare i dati in un'altra partizione e mantenere lo stesso path in /home
con un link simbolico:
mkdir /var/bigdata
cp -r /mnt/cdrom/* /var/bigdata
ln -s /var/bigdata /home/bigdata
In questo modo esiste sempre la directory /home/bigdata e il fatto che in realtà sia un link simbolico a /var/bigdata è trasparente, per il sistema.
Questo è solo un esempio, non perfettamente calzante (la directory /var, contenendo log e file mutevoli, è destinata a riempirsi) che comunque da l'idea di come con un semplice link si possono spostare intere directory e distribuire meglio lo spazio disponibile su partizioni diverse.
Tipo Infobox: BOFH - Skill Level: 4- ADVANCED - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2004-05-23 15:45:02
Script in una riga che trasforma il nome di file nella directory corrente in caratteri minuscoli.
E' possibile invertire il risultato, cioe' trasformare tutto in maiuscolo, invertendo di posto
[:upper:]' '[:lower:]'
Tipo Infobox: BOFH - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-23 15:44:30
Trova in tutto il file system i file con l'inode specificato.
E' utile per identificare gli hard link ad un file.
Nell'esempio sotto si visualizza l'inode di un file che si è visto avere 3 nomi associati (il 3 nella terza colonna dell'output di ls -li) e si cerca in tutto il file sysyem tutti i file che hanno stesso inode.
[root@trinity root]# ls -li /usr/bin/zgrep
301759 -rwxr-xr-x 3 root root 1461 Aug 24 2001 /usr/bin/zgrep
[root@trinity root]# find / -inum 301759
/usr/bin/zfgrep
/usr/bin/zgrep
/usr/bin/zegrep
(F)AQ: Come si trovano gli hard link di un file? -
Tipo Infobox: ETCETERA - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-24 23:25:30
Molte comandi Unix eseguono funzioni comuni ad analoghi comandi su altri sistemi operativi. Per chi conosce bene un sistema operativo e vuole velocemente sapere gli equivalenti dei comandi su un nuovo OS, esistono in rete varie "Stele di Rosetta" o comunque tavole comparative.
Alcune di queste si riferiscono ai diversi dialetti Unix, che pur avendo radice comune, in certi comandi e naming convention differiscono fra loro.
Nei link associati a questo INFOBOX ci sono alcune di queste preziose risorse.
LINK: A Sysadmin's Unixersal Translator (ROSETTA STONE) - http://home.earthlink.net/~bhami/rosetta.html
LINK: Unix-DOS-Windows Rosetta Stone - http://iats.missouri.edu/servlets/knowledgebase/article/422
LINK: Unix / VMS Commands Comparison - http://www.albany.edu/academic_computing/documentation/local/unix_commands.html
Leggere e visualizzare file |
Comandi per visualizzare e leggere file: cat, less, more, tail, info, strings. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-27 17:49:06
Su Unix sono disponibili svariati comandi che permettono la visualizzazione del contenuto di file di testo o binari.
Fare pratica con i principali è fondamentale per la normale attività sistemistica.
Tutti questi comandi hanno svariate opzioni e possibilità di eseguire operazioni anche complesse.
In genere si suggerisce di fare pratica con le funzionalità di base ed eventualmente usare le opzioni più evolute o rare in script shell o casi particolari.
cat
Visualizza il contenuto di un file di testo
tac
Fa esattamente la stessa cosa di cat, ma al contrario, visualizzando per prime le utile righe di un testo.
less
Visualizza il contenuto di un file testo, pagina per pagina
more
Come less, ma con meno funzioni
tail
Visualizza l'ultima parte di un file di testo
head
Visualizza la prima parte di un file di testo
file
Analizza e mostra il tipo di un file
strings
Visualizza stringhe di testo all'interno di un file binario
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-27 12:53:00
Legge uno o più file e li scrive sullo standard output.
E' il comando Unix più comune per visualizzare un file ASCII senza interruzioni o particolari filtri.
cat [opzioni] [file]
-v
(--show-nonprinting) Visualizza caratteri di controlli e non stampabili (ad eccezione dei LINEFEED e TAB).
-T
(--show-tabs) Visualizza i caratteri TAB come ^I
-E
(--show-ends) Visualizza $ alla fine di ogni riga (dove c'è un LINEFEED)
-A
(--show-all) Corrisponde a -vET
-n
(--number) Numera tutte le righe in output, iniziando da 1.
Esempi
cat -A file.dos
Visualizza il contenuto di file.dos evidenziando la presenza di eventuali caratteri non stampabili (se il file è stato copiato o salvato da Windows avrà dei caratteri di fine riga, non necessari su Linux/Unix che possono creare problemi. Per rimuoverli usare il comando dos2unix
)
SOURCE: Man Pages - http://man.openskills.info/cat
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-27 17:50:07
Visualizza i file specificati una pagina alla volta.
E' comune in tutti gli Unix, ma in molti OS basati su utility GNU viene spesso sostituito o affiancato dall'analogo e più flessibile "less".
Con "SPAZIO" si scrolla l'output di una pagina, con "q" si torna alla shell.
more [opzioni] [file]
-r
Visualizza caratteri speciali e di controllo
+ #numero
Inizia a visualizzare dalla riga numero specificato
-num #numero
Imposta le dimensioni dello schermo a #numero righe
-p
Ripulisce ogni volta le pagine e non le scrolla. E' utile, con terminali che presentano problemi di visualizzazione, per rendere più leggibile l'output.
Una volta eseguito more si entra in modalità visualizzazione, in cui è possibile dare diversi comandi:
SPAZIO
Visualizza la schermata di testo successiva
INVIO
Visualizza la riga di testo successiva
q
Esce da more e torna alla shell
/pattern
Cerca il pattern indicato all'interno del testo
n
Cerca l'occorrenza successiva dell'ultimo pattern cercato
!comando
invoca la shell ed esegue il comando scritto
:n
Salta al file successivo (quando si visualizzano più file
:p
Salta al file precedente
SOURCE: Man Pages - http://man.openskills.info/more
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-23 15:45:57
Visualizza il contenuto di un file pagina per pagina, permettendo di scrollare al suo interno.
E' una versione più evoluta e recente di "more".
E' comune in tutti gli Unix che utilizzano utility GPL, Linux fra questi.
less [opzioni] [file]
-j #numero
Inizia a visualizzare dalla riga numero specificato
- #numero
Imposta il valore di default di linee scrollate (se non specificato è lo schermo intero)
-C
Ripulisce ogni volta le pagine e non le scrolla. E' utile, con terminali che presentano problemi di visualizzazione, per rendere più leggibile l'output.
-o file
Copia l'output sul file specificato nel caso in cui l'input provenga da una pipe.
-p pattern
All'apertura del file visualizza la prima occorrenza del pattern specificato.
Una volta eseguito less si entra in modalità visualizzazione, in cui è possibile dare diversi comandi:
SPAZIO
Visualizza la schermata di testo successiva (o avanza del numero di righe specificate con l'opzione - )
INVIO
Visualizza la riga di testo successiva
FRECCIA SU-GIU
Scrolla verso l'alto o verso il basso l'output
q
Esce da less e torna alla shell
/pattern
Cerca il pattern indicato all'interno del testo
n
Cerca l'occorrenza successiva dell'ultimo pattern cercato
!comando
invoca la shell ed esegue il comando scritto
:n
Salta al file successivo (quando si visualizzano più file)
:p
Salta al file precedente
SOURCE: Man Pages - http://man.openskills.info/less
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-27 18:01:14
Comando utile per capire la natura di un file che non si conosce. Identifica il tipo di file specificato sulla base di pattern definiti nel file di definizioni /etc/magic
(o /usr/share/magic
)
file [opzioni] file
-s
Controlla anche i file speciali a blocchi o a caratteri (tipicamente quelli in /dev )
-z
Scomprime e prova a verificare il formato di file compressi
Esempi
file /bin/vi
Mostra che tipo di file è /bin/vi
file -s /dev/hda1
Fornisce informazioni utili sulla partizione /dev/hda1
SOURCE: Man Pages - http://man.openskills.info/file
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-27 17:54:29
Visualizza le ultime righe (di default 10) di un file.
E' un comando Unix comune.
Con l'opzione -f visualizza il file continuamente, senza tornare alla shell: opzione molto utile per tenere sotto controllo dei log.
tail [opzioni] [file]
-f
Non esce alla fine del file ma continua a visualizzarlo mentre cresce. Premere CTRL+C per tornare alla shell
- #numero
Visualizza le ultime #numero righe del file specificato
Esempi
tail -f /var/log/maillog
Visualizza l'ultima parte del file /var/log/maillog, continuando a scorrere il testo mano a mano che nuove righe si aggiungono al log. Questa funzionalità è molto comoda per diagnosticare problemi vari visualizzando in tempo reale file di log o debug.
tail -10 codice.txt
Visualizza le ultime 10 righe del file codice.txt presente nella directory corrente.
SOURCE: Man Pages - http://man.openskills.info/tail
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-23 15:46:23
Visualizza le prime righe (di default 10) di un file.
E' un comando Unix comune.
head [opzioni] [file]
-#numero
Visualizza le prime #numero righe del file specificato
-c #numero
Stampa i primi #num byte
Esempi
head -5 /etc/group
Visualizza le prime cinque righe di /etc/group
head -c5 /etc/group
Visualizza i primi 5 caratteri di /etc/group
SOURCE: Man Pages - http://man.openskills.info/head
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-27 18:05:36
Visualizza i caratteri stampabili all'interno di un file binario.
Comando comune in Unix, è comodo per verificare la presenza di stringhe di testo all'interno di un file binario compilato (il cui output tipicamente è un insieme di caratteri senza senso).
Precisamente visualizza, per il file specificato, qualunque stringa lunga almeno 4 caratteri stampabili e seguita da un carattere non stampabile.
E' utile per avere un'idea dei messaggi di testo utilizzati in un dato programma.
strings [opzioni] file
-a
Scandisce l'intero file e non solo alcune parti
-n #numero
Imposta a #numero la lunghezza minima della stringhe da visualizzare (di default è 4)
Esempi
strings /usr/bin/passwd
Visualizza tutte le stringe di caratteri stampabili (e quindi di testo) all'interno del file binario /usr/bin/passwd.
SOURCE: Man Pages - http://man.openskills.info/strings
Tipo Infobox: BOFH - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-06-18 10:00:42
Visualizza il contenuto di un file con i caratteri solitamente non visualizzati (ad esempio ^M che rappresenta un Carriage Return (CR) di troppo).
Utile per individuare caratteri estranei in file di testo (tipicamente importati da DOS) che ne compromettono la funzionalità.
Per convertire file ascii da DOS a Unix e viceversa esistono le utility dos2unix
e unix2dos
.
Su un testo DOS l'"a capo" viene fatto con due caratteri ASCII: CR (carriage return) e LF (line feed).
Su un testo Unix è sufficiente LF. Su un testo Mac, si usa CR.
(F)AQ: Come visualizzo i caratteri speciali (LF, CR...) in un file? -
Gestione dei file system |
I principi e i comandi per gestire un file system: mount, df, du, fsck, mkfs. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-28 20:22:21
Per file system si intende l'astrazione (metodo e protocolli) con cui un sistema operativo organizza i file su un supporto fisico di memorizzazione ad accesso casuale (floppy, cdrom, memoria, hard disk...).
I sistemi operativi moderni tipicamente utilizzano un sistema gerarchico (diviso in directory e sottodirectory) e possono supportare nativamente uno o più diversi file system.
Linux grazie alla sua polivalenza permette di utilizzare quasi tutti i file system più diffusi, ma il suo file system "storico" è ext2.
Dal kernel 2.4.x è disponibile il supporto per un'evoluzione dell'ext2, l'ext3 che, oltre ad essere convertibile facilmente in ext2, ha il vantaggio di essere un journal file system (basato su un log di tutte le operazioni di scrittura su disco, che aumenta l'integrità e il controllo .
Prima di poter utilizzare un qualsiasi dispositivo con il proprio filesystem (es: CDROM, floppy, tape, condivisione di rete windows, directory nfs, partizione fat32 di un hard disk... ) questo deve essere formattato e montato in una subdirectory della root ( / ).
Una volta montato il filesystem risulta accessibile a programmi e utenti in modo trasparente e diventa parte integrante dell'albero delle directory sotto /.
Dopo l'uso il filesystem può essere smontato (operazione necessaria per espellere un CDROM o un floppy).
La directory su cui viene montato un filesystem può anche non essere vuota, ma nel momento in cui ci viene montato un file system, i dati ivi contenuti non sono più visibili fino a quando non si esegue l'umount.
La gestione di diversi file system all'interno dello stesso albero di directory (la root: /) permette l'astrazione dei device hardware da parte del sistema operativo: per i programmi e gli utenti che accedono a determinati file non è importante conoscere o sapere su che tipo di dispositivo risiedono e possono accedere e gestire tutti i file con gli stessi strumenti, a prescindere dall'hardware su cui sono registrati.
LINK: Introduction to Linux file system - http://www.linuxnewbie.org/nhf/intel/filesys/filesysintro.html
HOWTO: Filesystems HOWTO - http://ldp.openskills.info/HOWTO/Filesystems-HOWTO.html
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-09-09 16:06:59
In questo file vengono configurate le informazioni sui vari file system (da montare al boot o no) preimpostati sul sistema, vengono definiti i mount point, il tipo di file system ed altre informazioni.
Il suo formato prevede per ogni riga le seguenti informazioni:
1- Dispositivo da montare (es: /dev/hda1 o anche host:dir )
2- Mount point sul file system principale
3- File System Type da utilizzare (es: ext2, ext3, iso9660, nfs...)
4- Opzioni specifiche per il mount
5- Indica se il file system deve essere backuppato con il comando dump. Uno 0 indica NO.
6- Indica de deve essere fatto un file system check al boot. Uno 0 indica NESSUN CHECK.
Qui viene analizzato un tipico /etc/fstab su Linux.
Su SUN Solaris il file equivalente si chiama /etc/vfstab.
cat /etc/fstab
/dev/hda2 / ext2 defaults 1 1
/dev/hda1 /boot ext2 defaults 1 2
/dev/hdc1 /home ext2 defaults 1 2
/dev/fd0 /mnt/floppy auto noauto,owner 0 0
/dev/hda7 /usr ext2 defaults 1 2
/dev/hdc2 /var ext2 defaults 1 2
none /proc proc defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0
/dev/hda3 swap swap defaults 0 0
In questo esempio la root ( / ) è montata sulla seconda partizione dell'hard disk IDE primary master ( /deb/hda2 ) e al suo interno monta altre directory che sono fisicamente presneti in altre partizioni di hda o in un secondo hard disk, il secondary master ( /dev/hdc ).
In questo caso tutti i file system su tutte le partizioni sono ext2, ma ogni partizione potrebbe avere un proprio file system.
Notare inoltre la partizione di swap in /dev/hda3, il /proc file system virtuale (che non ha mount point) e il device pts, che è un'interfaccia virtuale per i pseudo terminali (pts).
Considerare l'entry per il floppy, identificato da /dev/fd0 e montato in /mnt/floppy. Tra le opzioni di mount c'è specificato un noauto che indica di non motnare automaticamente il floppy all'avvio. I due zero a fine riga, inoltre, segnalano al sistema di non controllarlo al boot e di non usarlo per backup con il comando dump.
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-28 21:41:14
Permette di inserire un file system presente in un dato device nella struttura di directory principale del sistema, a partire dalla directory indicata.
Questa operazione viene definita "montare" e di fatto rende visibile al sistema il contenuto di dispositivi quali CD-ROM, floppy ma anche hard disk o file system di rete.
Il comando mount senza opzioni visualizza l'elenco dei file system attualmente montati nel sistema.
Nel file di configurazione /etc/fstab sono elencati i parametri di mounting dei vari dispositivi del sistema predefiniti: per montare le voci presenti in questo file basta specificare come parametro di mount la directory o il device.
Nel file /etc/mtab vengono visualizzati i file system attualmente montati sul sistema.
mount [opzioni] [device] [directory]
-a
Esegue il mount di tutti i file system elencati in /etc/fstab
-o opzione
Specifica le opzioni con cui montare il file system. Sono varie, incidono su diversi aspetti e possono essere specifiche per determinati tipi di file system: async, auto, defaults, dev, exec, noauto, nodev, noexec, nosuid, nouser, remount, ro, rw, suid, sync, user, check, conv, debug, errors.
-r
Esegue il mount del file system in sola lettura
-w
Esegue il mount del file system in lettura/scrittura (opzione di default)
-t tipo_fs
Specifica il tipo di file system da montare. Valori possibili: minix, ext, ext2, ext3, xiafs, hpfs, msdos, umsdos, vfat, proc, nfs, iso9660, smbfs, ncpfs, affs, ufs, romfs, sysv, xenix, coherent, reiserfs, jfs...
Esempi
mount -t vfat /dev/fd0 /mnt/floppy
Monta un floppy formattato sotto Windows sulla directory /mnt/floppy
mount -t iso9660 /dev/hdc /mnt/cdrom
Mount un CD presente nel lettore IDE Secondary master sulla directory /mnt/cdrom
mount -t nfs 192.168.0.10:/home/rpm /mnt/remote
Monta sulla directory /mnt/remote la condivisione NFS /home/rpm del server 192.168.0.10 (il serviazio portmap deve essere attivo sul client)
SOURCE: Man Pages - http://man.openskills.info/mount
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-28 21:44:38
Smonta il file system specificato e lo rende inaccessibile al sistema.
E' il comando che esegue l'operazione opposta a mount.
Qualsiasi operazione in corso sul filesytem da smontare viene conclusa e la struttura del file system segnata come pulita (clean).
umount [opzioni] [device|directory]
-a
Smonta tutti i file system montati (visualizzati in /etc/mtab)
-n
Smonta tutti i file system montati SENZA memorizzare le modifche in /etc/mtab
-t tipo
Smonta tutti i file system del tipo specificato.
Esempi
umount /dev/fd0
Smonta il floppy (operazione necessaria prima di estrarre fisicamente il dischetto). Questo comando è analogo a umount /mnt/floppy
(se il floppy è montato sulla directory /mnt/floppy.
umount /mnt/cdrom
Smonta il CDROM (se è montato sulla directory /mnt/cdrom). Nello specifico per i CDROM può essere usato il comando eject
che smonta ed espelle il CD.
SOURCE: Man Pages - http://man.openskills.info/umount
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-08-13 17:59:03
Crea un filesystem (formatta) sulla partizione specificata. Corrisponde al format di Windows.
mkfs [-V ] [ -t tipo-fs ] [ opzioni-fs ] filesys [blocchi]
filesys
Può essere il nome di una partizione (es: /dev/hda1 ) o un mount point (es: /home )
-t tipo-fs
Indica quale filesystem creare. mkfs è di fatto il frontend generico che invoca la versione appropriata di mkfs (mkfs.fstype) a seconda del tipo di filesystem specificato dall'opzione -t
-c
Verifica il dispositivo cercando eventuali blocchi difettosi prima di creare il filesystem.
SOURCE: Man Pages - http://man.openskills.info/mkfs
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-28 20:53:30
L'utilizzo di un floppy disk su Unix e Linux è uguale a quello di altri dispositivi di memorizzazione.
Per usare un floppy disk vergine, bisogna prima formattarlo, con un file system specifico.
Per farlo con ext2, il file system nativo di Linux basta digitare da shell:
mkfs.ext2 /dev/fd0
Una volta formattato il floppy è pronto per essere montato:
mount -t ext2 /dev/fd0 /mnt/floppy
A questo punto il suo contenuto è visibile nella directory /mnt/floppy.
I file al suo interno possono essere accessibili come tutti gli altri file del sistema.
Chiaramente se il floppy è protetto fisicamente in scrittura, non sarà possibile scriverci o fare modifiche.
PRIMA di rimuovere fisicamente il floppy disk bisogna smontarlo, per essere sicuri che il sistema finisca di scrivere eventuali dati rimasti in memoria (Il sistema operativo, per motivi di performance non sempre esegue le operazioni di scrittura sul floppy nel momento in cui vengono richieste, a volte i dati da scrivere rimangono in memoria fino a quando non si forza un "flush" del file system, operazione automaticamente eseguita al momento dell'umount):
umount /dev/fd0
(F)AQ: Come si usano i floppy disk su Linux? -
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-01-06 11:35:01
Come convertire un filesystem ext2 in modo che supporti le caratteristiche di journaling del filesystem ext3.
Grazie all'utilty di sistema tune2fs è possibile settare diversi parametri di un filesystem Linux. Questo software permette anche di convertire il formato di un filesystem, passando da ext2 a ext3:
root@Joker:/# tune2fs -j /dev/hda1
L'opzione -j permette di creare il file di journal al filesystem presente in /dev/hda1
tune2fs 1.27 (8-Mar-2002)
Creating journal inode: done
This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
Una volta convertito sarà possibile notare il file .journal
nella directory in cui viene montato.
La conversione può essere eseguita anche con il filesystem da convertire in stato unmounted ma è fondamentale che il kernel utilizzato abbia abilitato il supporto per per ext3, altrimenti in seguito sarà impossibile accedervi.
Infine è possibile modificare la relativa entry in /etc/fstab
, cambiando il terzo campo da ext2 in ext3:
root@Joker:~# cat /etc/fstab
[...]
/dev/hda1 /scambio ext2 defaults 1 0
Prima della conversione il filesystem in /dev/hda1 veniva montanto come ext2 sulla directory /scambio
root@Joker:~# cat /etc/fstab
[...]
/dev/hda1 /scambio ext3 defaults 1 0
Dopo la conversione si fa in modo che venga montato in /scambio come ext3
SOURCE: Red Hat Linux 9 - Ed. Apogeo - ISBN 88-503-2113-9 -
Tipo Infobox: BOFH - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-08-21 16:42:38
Con questo semplice comando è possibile visualizzare il contenuto di un file .iso (l'immagine di un CDROM da masterizzare) montandolo come un loop device su una directory del proprio file system.
Il kernel deve avere il supporto per i loop device (CONFIG_BLK_DEV_LOOP=y
) e, ovviamente, per il filesystem iso9660 usato su CDROM di dati (CONFIG_ISO9660_FS=y
).
Anche se generalmente non necessario potrebbe servire specificare il filesytem type utilizzato (-t iso9960) e, volendo, abilitare il verbose mode (-vv). Nell'esempio che segue si è montato il file iso sulla directory /mnt/floppy, che ovviamente può essere diversa ed avere un nome più appropriato:
[root@giraffa al]# mount -t iso9660 -o loop -vv /home/al/DOWNLOADS/damnsmall-0.4.4.iso /mnt/floppy/
mount: going to use the loop device /dev/loop0
set_loop(/dev/loop0,/home/al/DOWNLOADS/damnsmall-0.4.4.iso,0): success
mount: setup loop device successfully
/home/al/DOWNLOADS/damnsmall-0.4.4.iso on /mnt/floppy type iso9660 (rw,loop=/dev/loop0)
[root@giraffa al]# mount
[...]
/home/al/DOWNLOADS/damnsmall-0.4.4.iso on /mnt/floppy type iso9660 (rw,loop=/dev/loop0)
Se si vuole creare un file .iso direttamente dal contenuto di un CDROM, oltre ad usare programmi vari per masterizzare, basta il semplice comando:
dd if=/dev/cdrom of=/path/to/file.iso bs=32k
(l'immagine iso sarà scritta nel path specificato dopo of=).
Alternativamente, in modo ancor più diretto e semplice:
cat /dev/cdrom > /path/to/file.iso
Se si vuole creare un file .iso contenente i file presenti in una data directory, si può usare il comando mkisofs:
mkisofs -RJ -o file.iso /directory/
(tutto il contenuto presente in /directory/ verrà inserito nel file.iso (con path relativo))
SOURCE: ISO, CDR, and CDRW in Linux - http://www.geocities.com/rlcomp_1999/cdrw.html
Tipo Infobox: ETCETERA - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-05-01 12:05:07
Explore2fs è un tool per Windows in grado di leggere partizioni partizioni disco di tipo ext2 ed ext3.
Questo software, attualmente alla versione 1.00 pre 6, scritto in in linguaggio Delphi da John Newbigin, viene rilasciato sotto licenza GPL. Si dimostra utile qualora si utilizzi un sistema dual boot Windows/Linux e si necessiti di accedere a partizion di tipo etx2 o ext3 da ambiente Microsoft.
Explore2fs funziona sotto Windows 95, Windows 98, Windows NT, Windows 2000 e Windows XP. Sebbene sia possibile usare il programma anche in scrittura, l'autore consiglia di utilizzarlo solamente in lettura, in quanto potrebbero essere presenti dei bug che potrebbero rendere illeggibile la partizione.
Il programma è composto da un solo eseguibile, che una volta avviato presenta un'interfaccia Explorer like, in stile Windows NT. Sulla sinistra vengono visualizzate le partizioni riconosciute, mentre sulla destra si può accedere ai file contenuti nelle varie directory.
LINK: Home Page Explore2fs - http://uranus.it.swin.edu.au/~jn/linux/explore2fs.htm
Attributi e permessi |
La gestione di attributi e permessi sui file: chmod, chown, chgrp. |
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: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-28 22:17:34
Tutti i programmi su un sistema Unix hanno i permessi di lettura e scrittura sul file system corrispondenti a quelli dell'utente di sistema, così come indicato in /etc/passwd
, con cui vengono eseguiti.
Può capitare, provando a installare e lanciare programmi diversi, che questi non riescano ad essere eseguiti o non funzionino correttamente.
Come sempre, in caso di problemi, un controllo dei log è la prima operazione da compiere.
Relativamente spesso la causa è proprio la mancanza di permessi per poter leggere o scrivere file (configurazione, log, dati, librerie condivise ecc.).
A volte il programma cerca determinati file in posizioni dove non si trovano (in questi casi un link può rapidamente, e in modo un po' "sporco" risolvere il problema), a volte non ha i permessi di lettura su file di configurazione o di dati, o sulle directory che li contengono, in altri casi può cercare di scrivere (tipicamente log e dati) su directory o file dove l'utente che ha lanciato il programma (può essere anche un utente di sistema, che lo esegue automaticamente al boot) non ha permessi di scrittura.
Un esempio ricorrente è la configurazione di Apache per gestire siti web, aggiornati via ftp da diverse persone.
In questo caso l'utente con cui gira Apache (di solito nobody o apache) deve poter avere permessi di lettura sui file che compongono il sito web (e di esecuzione sulle relative directory).
Contemporaneamente gli utenti che si collegano via ftp, devono poter scrivere sulle loro home directory, che sono anche le home dei relativi server web.
Spesso, su Linus e su altri Unix, le home directory degli utenti sono in /home e sono leggibili solo dai rispettivi owner:
ls -l /home/ | grep bacco
drwx------ 2 bacco bacco 18384 Aug 24 04:02 bacco
Se Apache fosse configurato per avere il dominio www.bacco.it con le proprie pagine in /home/bacco, non riuscirebbe a visualizzare il sito Web per mancanza di permessi.
Questi andrebbero allargati all'utente con cui viene eseguito da Apache:
chmod -R 750 /home/bacco
chgrp -R apache /home/bacco
Ottenendo un funzionale:
drwxr-x--- 2 bacco apache 18384 Aug 24 04:02 bacco
A volte, in preda a pigrizia o vittime dell'inconsapevolezza, si può avere la tentazione di allargare al massimo i permessi sui file che servono al programma che vogliamo far funzionare a tutti i costi:
chmod -R 777 /home/bacco
Ottiene un funzionale ma poco sicuro:
drwxrwxrwx 2 bacco bacco 18384 Aug 24 04:02 bacco
In questo modo Apache potrebbe tranquillamente visualizzare il sito di bacco, ma avrebbe anche permessi di scrittura non necessari, condivisi anche con tutti gli altri utenti del sistema, che avrebbero l'indebita possibilità di modificare le pagine di sito in /home/bacco.
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: 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:25:38
Cambia l'owner group di un file o directory. Comando comune in tutti gli Unix.
chgrp [opzioni] 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 gruppo 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
chgrp users /tmp/data
Imposta users come owner group del file /tmp/data
chgrp -R wheel /tmp/datadir
Imposta wheel come wonder group della directory /tmp/datadir e di tutti i file e le sottodirectory che contiene
LINK: Man Pages - http://man.openskills.info/chgrp
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.
Ricerca, confronto e filtri |
Ricerca nel file system: find, locate. Confronto e verifica di file: diff, md5sum. Filtri di output: grep, wc, sed, awk. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-24 11:33:10
Su Unix esistono molteplici comandi per la ricerca di file, all'interno dell'albero delle directory. Si basano su principi diversi e si adattano a diversi usi.
find - Ricerca file contenuti nella directory indicata in base a svariati criteri, come il nome, la data di modifica, la dimensione ecc. Utile per molti scopi.
locate - Ricerca file che matchano un pattern specificato tramite un database che permette ricerche veloci e viene aggiornato col comando updatedb.
whereis - Visualizza i path di binari, sorgenti e manuali per un comando
which - Mostra la posizione di comandi eseguibili all'interno del proprio ambiente PATH.
whatis - Cerca la parola completa specificata all'interno del database whatis, contenente brevi descrizioni dei comandi del sistema. Il database viene creato con il comando makewhatis
apropos - Come whatis, ma esegue ricerche anche di parole parziali.
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Max 'vm' Villa - Ultimo Aggiornamento: 2002-10-06 17:59:13
Comando estremamente utile per cercare particolari gruppi di file; funziona percorrendo l'albero delle directory a partire da ogni percorso indicato dall'argomento percorsi_di_file e rintraccia i file che soddisfano determinate condizioni. Il percorso di default è la directory corrente.
Comando comune a tutti gli Unix.
find [percorsi_di_file] [condizioni]
-print
Stampa file e directory per i quali sono verificate le condizioni imposte, mostrandone il percorso completo.
-name
[pattern] Trova i file i cui nomi contengono una corrispondenza con i pattern.
-iname
[pattern] Versione insensibile alle maiuscole-minuscole di -name.
-type
[x] Cerca file di vario tipo: b (file speciale di blocco), c (file speciale di caratteri), d (directory), p (fifo o pipe), l (link simbolico), s (socket), oppure f (file normale).
-follow
Segue i link simbolici e tiene traccia delle directory visitate (non usare con -type l)
-exec
[comando { } \;] Esegue il comando Unix, a partire dalla directory di partenza su ogni file per il quale find ha tracciato una corrispondenza. All'esecuzione del comando, l'argomento { } sostituisce il file corrente.
-size
[n(c)] Cerca i file contenenti n blocchi, o se c è specificato, lunghi n caratteri.
-mtime
[+n | -n | n] Trova tutti file che sono stati modificati più di n (+n), meno n (-n), o n giorni prima della data corrente. La modifica riguarda il cambiamento della data del file.
-atime
[+n | -n | n] Trova tutti i file per i quali l'ultimo accesso risale a più di n (+n), meno di n (-n), o esattamente n giorni prima della data corrente. E' importante notare che find modifica la data/ora.
-ctime
[+n | -n | n] Trova tutti i file modificati più di n (+n), meno di n (-n), o esattamente n giorni prima della data corrente.
-user
[utente] Cerca i file il cui proprietario è l'utente.
-ok
[comando { } \;] Come -exec, con la differenza che chiede all'utente la conferma (y) per eseguire il comando.
-path
[pattern] Cerca i file i cui nomi contengono una corrispondenza con il pattern.
-ipath
[pattern] Versione insensibile alle maiuscole-minuscole di -path.
-depth
Processa i file contenuti in ciascuna directory prima della directory stessa. Utile se i file risiedono in directory non scrivibili.
-xdev
Dice a find di non cambiare filesystem. Utile quando occore cercare qualcosa nel file system di root.
-cnewer
[file] Cerca i file cambiati dopo la loro ultima modifica.
-nouser
Cerca file per i quale lo userID non corrisponde ad alcun utente.
-noleaf
Toglie l'ottimazione che dice "una directory contine due sotto directory in meno, da indicare del conteggio dei link". Questa azione è necessaria quando si effetuano ricerche all'interno di filesystem che non seguono le convenzioni Unix.
-newer
[file] Cerca i file modificati più di recente; simile a -mtime.
-anewer
[file] Cerca file per i quali si è verificato un accesso dopo l'ultima modifica.
-cnewer
[file] Cerca file cambiati dopo l'ultima modifica.
-cmin
[+n | -n | n] Cerca file modificati più di n (+n), meno di n (-n), o esattamente n minuti prima dell'ora corrente.
-daystart
Calcola i tempi a partire dall'inizio del giorno corrente, non da 24 ore prima.
SOURCE: Man Pages - http://man.openskills.info/find
Tipo Infobox: BOFH - Skill Level: 4- ADVANCED - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-23 16:00:53
Cerca in tutto il file system file o directory che terminano con .log
L'opzione -name accetta REGEXP comuni e permette ricerche molto efficaci basate sui nomi dei file.
find / -name "*.log" -type f -print
/home/al/.rhopenoffice1.1/setup.log
/etc/logrotate.d/vsftpd.log
/usr/lib/rpm/rpm.log [...]
Tipo Infobox: BOFH - Skill Level: 3- INTERMEDIATE - Autore: Marco 'nxm' Naimoli - Ultimo Aggiornamento: 2003-12-08 23:00:41
Cerca la [stringa] (in modo case insensitive) all'interno di tutti i files presenti nella directory /var/log e in tutte le sue sottodirectory
find /var/log -type f -print | xargs grep -i [stringa]
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Max 'vm' Villa - Ultimo Aggiornamento: 2004-05-23 15:56:18
Trova un file all'interno di uno o più database di nomi di file e stampa le corrispondenze trovate.
Locate effettua la ricerca all'interno di un database che si aggiorna tramite il comando updatedb, che, tipicamente, viene schedulato per essere eseguito almeno una volta al giorno.
Un programma appena installato non può quindi essere trovato con locate fino a quando non viene eseguito updatedb e ricreato il relativo database.
locate [opzioni] [pattern]
-d
[percorso] (--database=percorso) Ricerca i database nel percorso specificato.
SOURCE: Man Pages - http://man.openskills.info/locate
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Max 'vm' Villa - Ultimo Aggiornamento: 2002-09-07 10:38:51
Elenca il percorso completo del comando eseguibile all'interno del proprio ambiente PATH.
Comando comune a tutti gli Unix.
which [opzioni] [comando]
-a
(--all) Stampa tutte le corrispondenze.
--skip-dot
Salta le directory che iniziano con un punto.
-i
(--read-alias) Legge gli alias dell'input standard e scrive le corrispondenze sull'output standard. Utile per usare un alias per which.
--skip alias
Utile per trovare file binari normali mentre si usa --read-alias
in un alias per which.
SOURCE: Man Pages - http://man.openskills.info/which
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Max 'vm' Villa - Ultimo Aggiornamento: 2002-09-07 10:36:15
Trova i file binari, i sorgenti e le pagine di manuale relative ad un determinato comando. I nomi forniti vengono prima ripuliti del percorso e di qualsiasi estensione (in formato .ext). whereis tenta poi di localizzare il programma desiderato nelle directory standard (p.es. /bin, /etc, /usr/bin, /usr/local/bin/, ecc.)
whereis [opzioni] [file]
-b
Ricerca solamente file binari.
-m
Ricerca solamente le sezioni del manuale.
-s
Ricerca solo i sorgenti.
-f
Evidenzia con un terminatore l'ultima directory dell'elenco e segnala l'inizio dei nomi di file; inoltre deve essere utilizzata con una delle opzioni -B, -M, -S.
-B
[directory] Modifica o limita il percorso nel quale whereis cerca i file binari.
-M
[directory] Modifica o limita il percorso nel quale whereis cerca le sezioni di manuale.
-S
[directory] Modifica o limita il percorso nel quale whereis cerca i file sorgente.
SOURCE: Man Pages - http://man.openskills.info/whereis
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Max 'vm' Villa - Ultimo Aggiornamento: 2004-05-23 15:51:01
Mostra la breve descrizione di un comando cercando la parola chiave all'interno di un set di file di database whatis. Il database in questione viene rigenerato utilizzando il comando /usr/lib/makewhatis.
Simile al comando apropos, fatta eccezione che ricerca soltanto parole complete.
Equivalente a man -f.
Comando comune a tutti gli Unix.
Esempio:
[root@localhost root]# whatis ifconfig
ifconfig (8) - configure a network interface
SOURCE: Man Pages - http://man.openskills.info/whatis
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Max 'vm' Villa - Ultimo Aggiornamento: 2004-05-23 15:54:58
Mostra una breve spiegazione di una serie di comandi che riguardano una determinata parola chiave.
Si comporta come whatis, eccetto per il fatto che ricerca una o più stringhe all'interno del set di file del database whatis (il suo argomento quindi non è il nome di un comando ma una parola generica).
Il database in questione viene rigenerato con il comando /usr/lib/makewhatis. Equivale a man -k.
Comando comune a tutti gli Unix.
Esempio:
[root@localhost root]# apropos routing
ip (8) - TCP/IP interface configuration and routing utility
NETLINK_ROUTE [rtnetlink] (7) - Linux IPv4 routing socket
netstat (8) - Print network connections, routing tables, interface statistics, masquerade connections, and multicast memberships
route (8) - show / manipulate the IP routing table
rtnetlink (7) - Linux IPv4 routing socket
SOURCE: Man Pages - http://man.openskills.info/apropos
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-23 15:48:37
Molti comandi Unix sono utilizzati come filtri per modificare il testo in input e presentarlo con l'output voluto. Vediamo alcuni dei filtri più comuni e, in genere, i comandi Unix utili per manipolare testi:
grep - Seleziona in file o nello standard input le righe di testo che contengono il pattern specificato. Es: Tutti le righe che contengono la scritta "bash".
sed - E' un flessibile e sofisticato strumento per modificare l'input secondo varie regole e match
sort - Ordina le righe del testo in input secondo criteri vari
tr - Converte o rimuove caratteri all'interno di un testo
cut - Ritaglia colonne o campi da un file, visualizzandone solo la parte selezionata
wc - Conta il numero di righe o di caratteri in un file
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2002-10-24 16:58:23
Il comando grep permette di ricercare una determinata parola o REGEXP pattern all'interno di un file e stampa a video tutte le righe che lo matchano. E' comune in tutti gli Unix.
grep [opzioni] pattern [file]
Il file su cui operare può essere passato direttamente allo standard input di grep. Per esempio cat /var/log/maillog | grep [email protected]
visualizza tutte le righe che contengono [email protected] all'interno del file maillog.
-i
Ignora la distinzione tra minuscolo e maiuscolo
-l
Stampa solamente i nomi dei file (una sola volta per file) che contengono righe soddisfatte dall'espressione
-n
Precede ogni riga soddisfatta dall'espressione con il suo numero di riga relativo all'interno del file
-v
Non vengono mostrate le righe che contengono le stringhe soddisfatte, ma le rimanenti.
-c
Stampa il numero di righe per le quali è stata rintracciata una corrispondenza.
-r
Legge ricorsivamente tutti i file sotto la directory indicata.
-A#
Stampa # righe di testo precedenti a quella per la quale è stata trovata la corrispondenza
-B#
Stampa # righe di testo successive a quella per la quale è stata trovata la corrispondenza
-C#
Stampa # righe di testo precedenti e successive a quella per la quale è stata trovata la corrispondenza
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2002-10-24 18:52:19
Il comando sort permette di ordinare le righe contenute in un file secondo criteri configurabili.
E' un comando comune in tutti gli Unix e viene tipicamente utilizzato come filtro.
sort [opzioni] [file]
-b
Ignora gli spazi e i caratteri di tabulazioni all'inizio e alla fine delle righe
-c
Verifica se i file sono già ordinati e, in tal caso non produce output
-f
Ignora la differenza fra caratteri minuscoli e maiuscoli
-i
Ignora i caratteri non stampabili
-n
Effettua un ordinamento numerico
-o file
Memorizza l'output nel file specificato
-r
Inverte l'ordinamento
-u
Le righe doppie vengono riportate in output una sola volta
-M
Tratta i primi tre caratteri come sigla di mese (Jan, Feb, etc...)
-t carattere
Utilizza il carattere indicato come delimitatore di campo (default è lo spazio)
+#
Esegue l'ordinamento sulla base del campo #+1
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2004-05-23 15:57:00
Questo comando stampa informazioni sul numero di caratteri, di parole e di righe dei file. Se l'argomento file non viene valorizzato, legge i dati dallo standard input. E' comune in tutti gli Unix.
wc [opzioni] [file]
-c, -bytes
Stampa solamente il conteggio dei caratteri
-l, --lines
Stampa solamente il conteggio delle righe
-w, --words
Stampa solamente il conteggio delle parole
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2002-10-24 18:23:58
Il comando cut è un filtro che di uno o più file in input visualizza solo le colonne, i caratteri o i campi selezionati.
E' possibile definire quale carattere viene considerato per separare campi diversi
Nell'elenco che segue considerare che list è una sequenza di interi in cui la virgola viene utilizzata per valori distinti e il trattino per intervalli di valori (es: 1,3 indica 1 e 3; 1-3 indica da 1 a 3)
cut [option] [file]
-c list
Stampa solo i caratteri nella posizione definita in list
-d carattere
Definisce quale carattere considerare per separare i campi in ogni riga. Va utilizzato insieme a -f
-f list
Visualizza i campi identificati da list
-s
Utilizzato con -f per sopprimere le righe che non contengono delimitatori
Alcuni esempi possono essere illuminanti. Prendiamo /etc/passwd.
Per visualizzare solo i nomi degli utenti e la shell impostata (campi 1 e 7, usando i : come delimitatore di campo):
[al@95 al]$ cat /etc/passwd | cut -d: -f 1,7
root:/bin/bash
bin:/sbin/nologin
[...]
mysql:/bin/bash
Per visualizzare solo i primi 5 caratteri di ogni riga:
[al@95 al]$ cat /etc/passwd | cut -c1-5
root:
bin:x
[...]
mysql
SOURCE: Guida Unix università di trieste - http://www.univ.trieste.it/~nircdc/doc/oldunix/DUsfs.10.7.4.html
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-23 15:49:25
AWK è un linguaggio di programmazione che esegue azioni definibili sulla base del matching di pattern definibili.
Il suo input (un file o lo standard output di un comando) viene processato una riga alla volta e se la riga soddisfa il pattern specificato, AWK esegue l'azione specificato, scrivendo su standard output il risultato di questa azione.
E' comune in tutti gli Unix, su Linux si trova l'implementazione GNU, chiamata con la solita fantasia gawk e, come spesso accade, con una serie di funzionalità aggiunte.
In questo contesto ci limiteremo a fare alcuni esempi che possono dare un'idea delle potenzialità di awk, della logica del suo funzionamento e della sua estrema utilità in molte attività di system administration.
Le regole che awk deve seguire possono essere scritte in un file o direttamente inserite fra apici negli argomenti del comando:
awk -f file_delle_regole file_di_testo_da_processare
è analogo a:
awk 'regole' file_di_testo_da_processare
ed etrambi sono analoghi a:
cat file_di_testo_da_processare | awk -f file_delle_regole
Le regole hanno di base un formato tipo:
pattern { azione }
dove pattern indica il matchind secondo criteri vari e l'azione quello che awk genera sullo standard output per ogni riga di testo nello standard input che soddisfa il pattern stabilito.
Vediamo alcuni esempi pratici, che possono chiarire molto meglio ed iniziare ad aprirci gli occhi sul versatile mondo di awk.
Visualizzo l'output di un normale comando (ma si possono immagina le variazioni sul tema):
ls -l
total 304
-rw-r--r-- 1 root root 11142 Aug 23 18:36 config.ini
drwxr-xr-x 2 shiva shiva 4096 Sep 3 22:25 docs/
-rw-r--r-- 1 root root 2807 Aug 23 16:49 installer.ini
-rw-r--r-- 1 root root 23264 Aug 23 16:49 license.txt
-rwxr-xr-x 1 root root 1449 Aug 23 16:49 netscape-installer*
-rwxr-xr-x 1 root root 249564 Aug 23 16:49 netscape-installer-bin*
-rw-r--r-- 1 root root 7995 Aug 23 16:49 README
Redireziono l'output del comando allo stdin di awk:
ls -l | awk '{print $1}'
total
-rw-r--r--
drwxr-xr-x
-rw-r--r--
-rw-r--r--
-rwxr-xr-x
-rwxr-xr-x
-rw-r--r--
Qui non viene specificata nessuna regola di matching e per tutte le righe di input awk stampa il primo campo ($1) Di default awk considera lo spazio come carattere di separazione fra i campi di una riga e non fa distinzione (ovviamente) fra righe con sintassi, significato e formato diversi (la prima rispetto a tutte le altre).
Per stampare il nono campo di ogni riga basta sostituire $1 con $9:
ls -l | awk '{print $9}'
config.ini
docs/
installer.ini
license.txt
netscape-installer*
netscape-installer-bin*
README
Se il nono campo non esiste, non viene stampato (della prima riga dell'ls -l originario non c'è più traccia).
Per stampare l'intera riga e non solo alcuni campi uso $0.
E se voglio iniziare a introdurre qualche regola di matching uso una simile sintassi:
ls -l | awk '$3 == "root" {print $0}'
-rw-r--r-- 1 root root 11142 Aug 23 18:36 config.ini
-rw-r--r-- 1 root root 2807 Aug 23 16:49 installer.ini
-rw-r--r-- 1 root root 23264 Aug 23 16:49 license.txt
-rwxr-xr-x 1 root root 1449 Aug 23 16:49 netscape-installer*
-rwxr-xr-x 1 root root 249564 Aug 23 16:49 netscape-installer-bin*
-rw-r--r-- 1 root root 7995 Aug 23 16:49 README
In questo caso il pattern matching è piuttosto semplice: eseguo l'azione fra parentesi graffe solo per le righe in cui il terzo campo coincide con la stringa "root".
L'output di awk può essere opportunamente editato e, ovviamente, redirezionato all'input di altri comandi:
ls -l | awk '$3 == "shiva" {print "rm -Rf " $9}' | sh
Qui, su stdout non compare nulla, ma come ci si può immaginare la directory docs/, con owner shiva, è stata rimossa. Notare che awk permette di stampare stringhe arbitrarie nelle sue azioni. Notare che lo spazio, all'interno dei doppi apici, dopo rm -Rf è necessario.
Questo è solo l'inizio, AWK è un vero e proprio linguaggio di programmazione interpretato, che presenta direttive BEGIN-END (vengono eseguite solo prima e dopo il processing dell'input), cicli IF-ELSE, variabili speciali, numerose variazioni e metodi per il matching di pattern (amggiore, minore, diverso, ecc), funzioni varie ecc.
E' molto utile per ripetere automaticamente operazioni simili secondo criteri predefinibili: di fatto esattamente quello che un sysadmin ama fare: automatizzare compiti noiosi ed evitare di digitare le quasi stesse cose per più di 3 volte di seguito.
SOURCE: Introduction to Unix: AWK - http://physinfo.ulb.ac.be/cit_courseware/unix/awk000.htm
LINK: DMOZ: Awk - http://dmoz.org/Computers/Programming/Languages/Awk/
LINK: AWK questo sconosciuto - http://www.pluto.linux.it/journal/pj9809/awk.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-08-27 05:00:03
Esistono diversi algoritmi che dato un input qualsiasi danno come output una stringa univoca di caratteri, di lunghezza fissa, a prescindere dalle dimensioni dell'input.
Questi algoritmi di "digesting", dal momento che anche minime differenze nell'input generano output totalmente diversi, possono essere utilizzati per verificare l'integrità di file (o messaggi di posta elettronica, o qualsiasi elemento binario o ascii).
Uno degli algoritmi più utilizzati è MD5, che crea un outout fisso (Hash) da un qualsiasi input.
Dall'output non è più possibile risalire all'input, e se lo stesso file da output diversi è stato sicuramente modificato.
IL comando per ottenere un hash MD5 da un file è md5sum e viene correntemente utilizzato per "firmare" programmi scaricabili da Internet e dare la certezza che sono versioni uguali a quelli ufficialmente rilasciate dal produttore.
SOURCE: md5, md5sum and related topics - http://hills.ccsf.org/%7Ejharri01/project.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-24 11:33:46
Su Unix esistono vari comandi per confrontare file fra loro e verificare se sono diversi:
diff - Permette di fare un confronto fra il contenuto di due file di testo. Visualizza con un formato proprio le differenze e viene ampiamente utilizzato per creare delle patch di sorgenti.
diff3 - Come diff ma eseguito su 3 file.
bdiff - Come diff, ma lavora su file che possono essere divisi in più parti e quindi avere dimensioni anche molto grandi.
cmp - Compara due file ed esce con exit status diversi a seconda del risultato.
comm - Visualizza le righe diverse e quelle uguali in due file specificati.
dircmp - Compara il contenuto di 2 directory
Come sempre è possibile utilizzare vari comandi Unix comuni in script per ottenere risultati simili di confronto di file, del loro contenuto e di directory
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: fulvio 'fulvio' montalbano - Ultimo Aggiornamento: 2004-05-23 15:51:48
Confronta le righe comuni ai file specificati e produce un output su tre colonne:
righe presenti solo nel primo file,
righe presenti solo nel secondo file,
righe comuni a entrambi i file.
comm è simile a diff nel fatto che entrambi i comandi confrontano due file. Però comm può essere utilizzato anche come uniq; infatti comm seleziona le righe duplicate o uniche tra i due file ordinati, mentre uniq seleziona le righe duplicate o uniche all'interno del medesimo file ordinato.
comm [opzioni] file1 file2
-
Legge lo standard input
-num
Sopprime la stampa della colonna num. E' possibile specificare più colonne, non separate da spazi
SOURCE: Man Pages - http://man.openskills.info/comm
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: fulvio 'fulvio' montalbano - Ultimo Aggiornamento: 2002-09-07 11:48:38
Confronta due file di testo. diff restituisce le righe differenti dei due file file1 e file2.
L'output consiste di righe di testo indicanti anche il contesto di ognuno dei due file, con il testo di file1 contrassegnato da un simbolo . Le righe di contesto sono precedute dal comando ed (a, c o d) che potrebbe essere utilizzato per convertire file1 in file2. Se uno dei due file viene indicato con -, viene letto lo standard input. Se uno dei due file è una directory, diff rintraccia il file della directory con lo stesso nome del file indicato dall'altro argomento (Es.: diff my_dir junk ha lo stesso significato di diff my_dir/junk junk). Se entrambi gli argomenti indicano directory, diff restituisce le righe che sono differenti di tutte le possibili coppie di file con lo stesso nome (Es.: oldir/program e newdir/program); inoltre diff indica tutti i nomi di file presenti solamente in una delle due directory, così come le sottodirectory comuni a entrambi. Vedere anche CMP.
diff [opzioni] [opzioni_directory] file1 file2
-a, --text
Tratta tutti i file cpme file di testo. Utile per verificare se file binari sono identici
-b, --ignore-space-change
Ignora le sequenze di caratteri blank ed end-of-line, trattando le prime come un unico carattere blank.
-B, --ignore-blank-lines
Ignora le righe vuote nei files
-d, --minimal
Per velocizzare i confronti ignora i segmenti contenenti numerosi differenze e invia in uotput solo i gruppi di differenze minime.
-H
Velocizza l'output per file di grosse dimensioni ricercando solo piccole differenze; lunghe porzioni contenenti molte differenze non vengono visualizzate
-i, -- ignore-case
Ignora la differenza tra caratteri minuscoli e maiuscoli durante il confronto. I caratteri minuscoli e maiuscoli sono considerati come identici
-N, --new-file
Tratta i file inesistenti come file vuoti.
-q, --brief
Indica solo se i file sono differenti senza mostrarne le differenze.
-r, --recursive
Confronta le sottodirectory ricorsivamente
-s, --report-identical-files
Indica se i file soono diversi
-S nomefile, --starting-file=nomefile
Per i confronti di directory, inizia con il file nomefile, saltando i file che lo precedono nell'ordine standard di elencazione
-T, --initial-tab
Inserisce caratteri tab iniziali alle righe di putput per allineare correttamente i tab
-X nomefile, --exclude-from=nomefile
Non confronta i file di una directory i cui nomi corrispondono ai pattern descritti nel file nomefile.
SOURCE: Man Pages - http://man.openskills.info/diff
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: fulvio 'fulvio' montalbano - Ultimo Aggiornamento: 2002-09-07 11:44:39
Confronta file1 e file2. Utilizza lo standard input se file1 vale - o è mancante. Vedere anche diff. I file possono essere di qualunque tipo. Skip1 e skip2 rappresentano degli offset opzionali nei file di corrispondenza dei quali deve partire il confronto.
cmp [opzioni] file1 file2 [skip1[skip2]]
-c, --print-chars
Stampa i byte differenti come caratteri
-i num, --ignore-initial=num
Ignora i primi num byte dell'input.
-l, --verbose
Stampa gli offset e i codici di tuttii byte differenti
-s, --quiet, --silent
Lavora in silenzio, senza stampare alcun messaggio, ma restituendo i seguenti codici:
0 I file sono identici
1 I file sono differenti
2 I file sono inaccessibili
Questa opzione è utile in script, per eseguire operazioni diverse se due file sono uguali o diversi.
SOURCE: Man Pages - http://man.openskills.info/cmp
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Marco 'nxm' Naimoli - Ultimo Aggiornamento: 2003-12-08 22:59:14
Applica un comando ad una lista di file ricevuta da standard input.
xargs [opzioni] [comando] [argomenti]
[comando]
un comando qualsiasi del sistema, script o binario eseguibile (default /bin/echo)
[argomenti]
argomenti del [comando]
-0
Interpreta lo standard input come una serie di filename separati dal "null character" (deve normalmente essere associata all'opzione "-print0" di find). Il suo utilizzo è richiesto quando i filename contengono spazi
-l num
vengono passati al [comando] blocchi di "num" linee alla volta al posto del massimo consentito dalla shell
-i[stringa]
ogniqualvolta appaia [stringa] in [argomenti] essa viene sostituita da una entry della lista in standard input (default "{}")
Tipo Infobox: BOFH - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2003-12-26 00:11:03
Permette di individuare quali servizi sono attivi al runlevel 3, quello tipicamente utilizzato su una macchina server.
Filtrando opportunamente l'output del comando chkconfig --list
è possibile visualizzare informazioni formattate relative al runlevel di interesse:
[root@vagante root]# chkconfig --list | grep '3:on' | sort | awk '{ print $1 $5 }'
apmd3:on
autofs3:on
crond3:on
cups3:on
gpm3:on
iptables3:on
isdn3:on
keytable3:on
kudzu3:on
netfs3:on
network3:on
nfslock3:on
portmap3:on
random3:on
sendmail3:on
sshd3:on
syslog3:on
xinetd3:on
L'opzione --list visualizza l'elenco di tutti i servizi di sistema, tramite grep vengono filtrati sono quelli attivi (on), tramite sort vengono ordinati alfabeticamente e tramite awk vengono stampati il primo campo, contentene il nome del servizio ed il quinto, contentente il valore relativo al runlevel 3
Con poche modifiche, in particolare al parametro di grep ed al print di awk è possibile adattare questa command line a stampare i valori relativi ad altri runlevel (se avessivo voluto visualizzare i dati relativi al runlevel 5 avremmo impostato il relativo valore nel grep ed il campo $7 come secondo parametro del print di awk).
La shell è l'interfaccia testuale Unix per definizione: l'interprete dei comandi, il compagno di tastiera, da decenni, di innumerevoli sistemisti Unix.
La shell non viene usata solo per ricevere comandi in modalità interattiva dall'utente ma anche per gestire script di varia complessità, di fatto è parte integrante del sistema operativo: tutto quello che succede dopo che viene caricato il kernel è un districato insieme di script shell, che richiamano programmi, impostano parametri, lanciano applicazioni e servizi e "costruiscono" durate il boot il sistema operativo come si presenta all'utente.
E' fondamentale comprendere:
- i principi di redirezionamento e pipe
- come fare uno script shell
- come usare variabili e cicli in uno script shell
- la logica degli script di inizializzazione della shell
- cosa è l'ambiente (environment) e le sue variabili
Per approfondimenti: Ambiente Shell e scripting
Sapere cosa è in esecuzione sul proprio sistema è un ottimo inizio per conoscerlo.
Un sistemista Linux bene o male riconosce ogni singolo processo in esecuzione sul suo sistema e di questo sa come gestirlo, quando viene eseguito e può sapere cosa sta facendo.
Conoscere la natura degli output di comandi come ps, top e vmstat equivale a capire esattamente cosa succede sul sistema, quali sono i colli di bottiglia quando è rallentato e diagnosticare eventuali problemi.
Analogamente è utile saper usare kill per gestire un processo.
Riferimenti su come visualizzare e gestire processi sono in I Processi
Informazioni sui metodi e gli strumenti per diagnosticare il funzionamento di un processo sono in Debugging dei processi
Ambiente shell e scripting |
L'ambiente shell e lo scripting: variabili d'ambiente, cicli, strutture base. |
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-28 00:04:51
Unix è un sistema operativo nato nei primi anni 70, grazie all'opera di monumenti dell'informatica quali Ken Thompson, Dennis Ritchie (l'inventore del C, per intenderci) e vari altri.
Uno dei motivi che rende Unix un sistema operativo attuale e perfettamente adattabile a sistemi che ai tempi non si concepivano neppure è la sua filosofia di base: KISS (Keep It Simple, Stupid).
E' il principio dei tanti piccoli mattoni, ognuno necessario per fare bene un compito specifico, messi insieme per fare compiti più complessi. Questo approccio facilita il troubleshooting, riduce i tempi di sviluppo, non dovendo "reinventare la ruota" ogni volta, , aumenta la possibilità di sviluppare un sistema in modo collaborativo distribuito e, evidentemente, permette una scalabilità e una adattabilità ineguagliate.
La shell è un interprete di comandi che funge sia da layer fra il kernel del sistema operativo e l'utente sia come linguaggio di programmazzione avanzato.
Un programma in shell è chiamato script e presenta un metodo facile e veloce per automatizzare operazioni ripetitive.
Conoscere lo shell scripting language e saperlo applicare per risolvere problemi di ordinaria e straordinaria amministrazione è una delle funzioni basilari del system administrator.
Saper scrivere uno script shell non è complicato, poichè la sintassi è semplice e la filosofia su cui bisogna basarsi nella realizzazione è la stessa dalla quale nasce unix: spezzare un progetto laborioso in tanti e semplici task.
Un bravo e produttivo sistemista Unix, quindi, è colui in grado di mettere insieme i mattoni che gli servono, creando script di "collante" che inglobano altri script con funzioni specifiche, magari pure scritti in linguaggi diversi.
E' colui che è pienamente consapevole che la macchina è al suo servizio e non viceversa, che ne può vedere e cambiare gli elementi con un semplice vi, che riesce a non ripetere due volte la stessa operazione, perchè la prima volta che l'ha fatto ha già creato uno script che lo fa per lui.
L'arte dell'automazione dei processi è strettamente legata alla conoscenza dalla bash (o della shell che si utilizza) e delle sue capacità di scripting.
I principi di massima per impratichirsi sono semplici:
- Avere obiettivi chiari, facendosi un percorso logico dei processi da effettuare;
- Guardare gli script esistenti scritti da altri, notare come vengono affrontati i problemi, come si usano le variabili e i cicli logici;
- Impratichirsi costantemente;
- Approfondire lo studio delle opzioni dei programmi che servono. Spesso risolvono molti problemi e aprono nuove prospettive sui risultati che si possono raggiungere.
Una distribuzione Linux o un sistema Unix è di fatto un insieme di script e comandi che vengono eseguiti al boot dopo il caricamento del kernel, ed è un'ottima fonte di apprendimento di tecniche di scripting e automazione.
HOWTO: BASH Programming - Introduction HOW-TO - http://ldp.openskills.info/HOWTO/Bash-Prog-Intro-HOWTO.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2003-11-27 23:54:29
La Shell è il programma di interfacciamento tra l'utente e il sistema operativo in grado di interpretare ed eseguire le richieste dell'utente.
La shell dispone di frasi proprie, di controllo di flusso, variabili, metacaratteri che combinati a comandi del sistema fa della shell un vero e proprio linguaggio di programmazione a comandi.
Quando ci si trova ad eseguire in modo ripetitivo comandi o sequenze di comandi abbastanza complesse è consigliabile scrivere tali comandi in un file ed esegulirlo ogni volta che occorre.
I file contenenti comandi shell si chiamano SCRIPT (procedure), per poter esser eseguiti questi file devono avere l'attributo di esecuzione (chmod +x
file).
La selezione di quale shell (bash, csh, ksh) eseguirà lo script è indicata nella prima riga del file:
- nel caso la prima riga contiene solo il carattere #
sarà eseguita la shell da cui è stato lanciato lo script;
- se contiene #!pathname viene utilizzata la shell indicata (es: #!/bin/ksh
)
- se non viene indicato nulla verrà interpretato da una Bourne Shell.
Per creare uno script shell quindi basta:
- Creare un nuovo file di testo con un editor come vi: vi prova
;
- Iniziare il file con una riga che identifica l'interpreta da usare: #!/bin/bash
- Scrivere nelle righe successive i comandi e le istruzioni che si intendono eseguire nello script
- Salvare il file e renderlo eseguibile: chmod 755 prova
- Eseguire il file: ./prova
.
NOTA: Se si edita un file su Windows o DOS fare attenzione ai caratteri speciali di fine riga che Windows introduce e che rendono impossibile l'esecuzione di uno script shell su Linux. Usare il comando dos2unix prova
per converire i caratteri ESC di fine riga Windows (LF,CR) nell'analogo Unix (CR).
HOWTO: Advanced Bash-Scripting Guide - http://ldp.openskills.info/LDP/abs/html/
HOWTO: Bash Prompt HOWTO - http://ldp.openskills.info/HOWTO/Bash-Prompt-HOWTO/index.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-23 16:01:22
Fin dalle prime (ma non le primissime) versioni di Unix è stata introdotta nella shell la possibilità di redirezionare l'output di programmi (i dati che generano) ad altri programmi e di compiere analoghe operazioni con l'input e i messaggi di errore.
Questa possibilità, essendo valida per tutti i programmi e applicabile a tutti i file e oggetti del file system, permette una flessibilità enorme ed è particolarmente utile in script shell.
La shell gestisce la comunicazione con ogni programma lanciato tramite 3 file descrittori:
- standard input (stdin - file descriptor 0)
E' il canale attraverso il quale il programma riceve i dati di ingresso, generalmente la tastiera.
- standard output (stdout - file descriptor 1)
E' il canale di uscita del risultato dell'elaborazione del programma, di solito il video.
- standard error (stderr - file descriptor 2)
E' dove il programma stampa eventuali errori durante l'esecuzione, di solito il video.
Molti comandi UNIX assumono che l'ingresso dei dati avvenga (o possa avvenire) da standard input e l'uscita avvenga su standard output. E' possibile concatenare più programmi fra loro e fare in modo che lo standard output di uno diventi lo standard input di un altro. Per farlo si utilizza il carattere | chiamato pipe.
E' inoltre possibile redirezionare stdin, stdout e stderr su un file tramite gli operatori di redirezionamento:
> redirige lo standard output di un comando su un file o dispositivo
>> redirige l'output di un comando su un file o dispositivo ma se il file esiste già i dati vengono aggiunti alla fine del file. Se il file non esiste viene creato
< redirige lo standard input da un file o dispositivo
2> redirige lo standard error di un comando su un file o dispositivo
| operatore pipe, concatena standard output e standard input di due programmi
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-27 23:53:41
La shell permette di definire mediante l'uso di variabili alcuni parametri che influenzano il comportamento dei programmi che vengono eseguiti.
Si usa distinguere fra Variabili d'ambiente, generalmente indicate in MAIUSCOLO, che vengono passate ad ogni programma eseguito dalla shell e quindi costituiscono di fatto la definizione di un una serie di parametri globali, e variabili locali, che vengono create ed utilizzate solo all'interno di un programma (che può essere anche uno script shell) e che generalmente si indicano in minuscolo.
Di solito basta esportare una variabile locale per farla diventare d'ambiente.
Si identifica una variabile con il simbolo $.
Le variabili d'ambiente più importanti sono:
HOME il valore di questa variabile è quella della home-directory dell'utente
PATH l'elenco delle directory dove la shell, dopo l'inserimento di un comando, cerca il programma da eseguire
DISPLAY definisce lo schermo sul quale un programma X-Window aprirà le proprie finestre
TERM definisce le sequenze di comandi che saranno usate per comandare il terminale che si sta usando.
Con il comando printenv
o env
vengono visualizzate le variabili d'ambiente della propria shell.
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-27 23:44:20
Tramite gli script di inizializzazione è possibile customizzare l'ambiente shell in cui si lavora, modificando e impostando i valori di variabili d'ambiente (valide per ogni processo gestito dall'utente) o di variabili locali (valide solo la shell corrente).
Le variabili d'ambiente più comuni sono:
LOGNAME
La login dell'utente. Viene impostata al login.
USER
L'utente corrente. Può essere diverso da LOGNAME se l'utente ha fatto un 'su'.
HOME
Il path dell'home directory dell'utente. Viene impostata al login.
SHELL
Il path della shell di default. Viene impostata al login.
PATH
I path di default in cui la shell cerca comandi da eseguire. Viene impostata al login.
MAIL
Il path della casella postale dell'utente. Viene impostata al login.
TERM
Il tipo di terminale corrente.
PWD
La directory di lavoro corrente.
PS1
Il prompt della shell (per Bourne e Korn shell)
prompt
Il prompt della shell (per la C shell)
EDITOR
Il text editor di default (usato nella shell e in comandi quali crontab -e)
DISPLAY
Dove viene visualizzato il Display di un X server
Per impostare o modificare una variabile d'ambiente ci sono diversi metodi a seconda della shell utilizzata:
Bourne, Bash e Korn Shell: VARIABILE=valore ; export VARIABILE
. Per esempio: PS1='$LOGNAME@$HOSTNAME ! $' ; export PS1
. Oppure, in forma ridotta: export VARIABILE=valore
C Shell: setenv variabile valore
. Per esempio: setenv prompt "\! 'uname -n' % "
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2003-11-28 00:00:09
Come ogni linguaggio di programmazione anche la shell ha delle strutture di controllo, la cui logica e sintassi è simile a quelle comuni in altri linguaggi come il C.
IF THEN ELIF ELSE
if
cmd1 - Se l'ultimo comando in cmd1 è terminato con successo
then
cmd2 - I comandi cmd2 vengono eseguiti
elif
cmd3 - Altrimenti se l'ultimo comando in cmd3 è terminato con successo
then
cmd4 - Vengono eseguiti i cmd4
else
cmd5 - Altrimenti, se ne cmd1 ne cmd3 sono soddisfatti, vengono eseguiti i cmd5
fi
FOR IN DO DONE
for
cmds - Cmds viene eseguito tante volte quanti sono
[in
a b c...] - i valori in a b c. Ad ogni ciclo il valore di vars cambia
do
- a seconda del corrispettivo valore a b c....
cmds
done
WHILE DO DONE
while
cmds1 - Esegue cmd1 e se i comandi terminano con valore logico vero
do
cmds2 - Esegue cmd2 fino a quando cmd1 termina con valore logico falso
done
UNTIL DO DONE
until
cmd1 - Esegue cmd1 e se i comandi terminano con valore logico falso
do
cmd2 - Esegue cmd2 fino a quando cmd1 termina con valore logico vero
done
CASE IN ESAC
case
vars in
- Viene effettuato un confronto tra vars
match1) list1 ;; - e le match1.. finchè non trova il
match2) list2 ;; - corrispettivo valore
match3) list3 ;;
...
esac
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-27 23:50:56
Una delle caratteristiche della filosofia di Unix è che l'impostazione del sistema non vuole prevedere tutte le necessità dell'utente, ma tenta di rendere semplice per ciascuno modificarsi l'ambiente a seconda delle proprie necessità.
Ogni shell prevede uno o più "file di configurazione" che viene processato ogni volta che viene invocata. Di fatto, gli script di inizializzazione di una shell, sono normali script che si eseguono all'avvio delle shell stessa.
Questi file di configurazione sono noti anche come "file init", "file rc"" (per "run control", controllo dell'esecuzione) o anche "file punto", perché il loro nome di solito inizia con ".".
La shell di default di Linux è la bash.
I file di configurazione della bash di default sono:
/etc/bashrc
: Contiene gli alias e le funzioni valide per l'intero sistema;
/etc/profile
: Contiene le variabili d'ambiente per l'intero sistema e i programmi di avvio;
$HOME/.bashrc
: Contiene gli alias e le funzioni dell'utente;
$HOME/.bash_profile
: Contiene le variabili d'ambiente e i programmi di avvio dell'utente;
$HOME/.inputrc
: Contiene definizioni di tasti e altre funzioni.
Per personalizzare il proprio ambiente bash è necessario modificare il file $HOME/.bashrc
.
E' possibile creare alias per comandi che vengono usati spesso (alias "alias"= "comando") o modificare il prompt utilizzando il linguaggio bash o eseguire determinati programmi all'avvio della shell ecc.
Oltre agli script eseguiti al login, la shell può eseguire uno script al momento del logout da parte dell'utente.
Per la bash, questo script, se esiste, è : $HOME/.bash_logout
LINK: HOW TO: Bash Prompt - http://www.linux.org/docs/ldp/howto/Bash-Prompt-HOWTO/index.html
Tipo Infobox: ETCETERA - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-09-12 13:21:41
I file di inizializzazione possono variare su Shell e sistemi operativi diversi.
Qui si analizzano quelli di tutte le shell disponibili su Solaris. In genere sono validi per tutti i dialetti Unix.
BOURNE SHELL
File di inizializzazione globali:/etc/profile
File eseguiti al login dell'utente: $HOME/.profile
File eseguiti all'apertura della shell dopo il login: --
PATH della shell: /bin/sh
KORN SHELL
File di inizializzazione globali:/etc/profile
File eseguiti al login dell'utente: $HOME/.profile
- $HOME/.kshrc
File eseguiti all'apertura della shell dopo il login: $HOME/.kshrc
PATH della shell: /bin/ksh
C SHELL
File di inizializzazione globali:/etc/.login
File eseguiti al login dell'utente: $HOME/.cshrc
File eseguiti all'apertura della shell dopo il login: --
PATH della shell: /bin/csh
Z SHELL
File di inizializzazione globali:/etc/zshenv
- /etc/zprofile
- /etc/zshrc
- /etc/zlogin
File eseguiti al login dell'utente: $HOME/.zshenv
- $HOME/.zprofile
- $HOME/.zlogin
File eseguiti all'apertura della shell dopo il login: $HOME/.zshrc
PATH della shell: /bin/zsh
BASH
File di inizializzazione globali:/etc/profile
File eseguiti al login dell'utente: $HOME/.bash_profile
- $HOME/.bash_login
- $HOME/.profile
File eseguiti all'apertura della shell dopo il login: $HOME/.bashrc
PATH della shell: /bin/bash
TC
File di inizializzazione globali:/etc/csh.cshrc
- /etc/csh.login
File eseguiti al login dell'utente: $HOME/.tcshrc
o $HOME/.cshrc
File eseguiti all'apertura della shell dopo il login: --
PATH della shell: /bin/tcsh
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2003-11-28 00:07:50
Il comando EXIT può essere utilizzato per terminare uno script Bash, ed in modo simile ad un linguaggio di programmazione può restituire un valore chiamato Exit Status.
EXIT
, permette di terminare arbitrariamente uno script. In particolare, ogni comando ritorna un Exit Status con valore 0 quando termina con successo e un valore diverso da 0 quando si verifica un errore.
Anche le funzioni all'interno di uno script o lo script stesso possono ritornare un Exit Status il quale è determinato dall'ultimo comando eseguito dalla funzione o dallo script.
E' possibile controllare lo stato di uscita dell'ultimo comando eseguito tramite la variabile $?
. Terminato uno script è possibile verificarne lo stato di uscita con echo $?
.
Per far ritornare un valore personalizzato da restituire alla Shell è possibile utilizzare EXIT nnn
, dove nnn è un numero compreso tra 0 e 255. Alcuni Exit Status hanno un valore riservato ed è quindi consigliato non utilizzarli per non confondersi in fase di troubleshooting:
- 1: Errore Generico
- 2: Errato utilizzo delle shell builtins
- 126: quando il comando non può essere eseguito
- 127: quando il comando non viene trovato
- 128: quando viene fornito un argomento errato a EXIT
- 128+n: quando il comando viene terminato da un segnale di interruzione. 128 +n sta a significare il valore 128 + il valore del segnale che lo ha interrotto.
- 130: quando lo script è terminato da Control-C
- 255: quando l'exit status è fuori dai limiti consentiti (0-255)
Se EXIT è chiamato senza parametri il suo valore è quello dell'ultimo comando eseguito.
SOURCE: Advanced Bash−Scripting Guide - Mendel Cooper -
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Davide 'Jediblack' - Ultimo Aggiornamento: 2004-05-23 15:37:21
Bash mette a disposizione due comandi interni molto interessanti: alias
e unalias
. Il primo dà la possibilità all'utente di rinominare un comando od uno script, mentre il secondo cancella un alias creato in questo modo.
Proviamo a digitare il comando alias
. Ciò che appare a schermo potrebbe assomigliare a quanto segue:
alias d='dir'
alias dir='/usr/bin/ls $LS_OPTIONS --format=vertical'
alias emacs='emacs-21.3-no-x11'
alias halt='su -c halt'
alias la='ls -la'
alias lh='ls -lh'
alias ll='ls -l'
alias ls='/usr/bin/ls $LS_OPTIONS'
alias mc='. /usr/share/mc/bin/mc-wrapper.sh'
alias reboot='su -c reboot'
alias v='vdir'
alias vdir='/usr/bin/ls $LS_OPTIONS --format=long'
Quello che viene mostrato è la lista degli alias attivi. Attenzione che questa lista potrebbe cambiare da utente ad utente e da distribuzione a distribuzione.
Vediamo come definire nostri alias. La sintassi del comando è particolarmente semplice ed assomiglia in tutto e per tutto alla definizione di variabili d'ambiente.
alias nomeAlias='comando + opzioni'
Tuttavia bisogna porre attenzione a due dettagli. Quando si digita un comando al prompt della Bash, quest'ultima come prima cosa scandisce la lista degli alias e, se trova una corrispondenza, la esegue. Significa che se ho intrapreso una decisione del tipo alias ls='clear'
, ogni volta che chiedo la lista delle directory mi ritrovo lo schermo pulito.
Un secondo dettaglio è che gli alias creati in questo modo vengono persi nel momento in cui eseguiamo il logout. Risulta quindi utile salvare gli alias che vengono usati più frequentemente nel file .profile nella propria home directory. In questo modo vengono ridefiniti tutte le volte che eseguiamo il login.
SOURCE: man page di Bash -
I processi |
Definizione e gestione dei processi. Segnali e job. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Massimiliano 'Max_Rispetto' Grassi - Ultimo Aggiornamento: 2002-10-31 08:59:17
Uno dei principali motivi del successo di Unix è senza dubbio dovuto alla sua capacità di multitasking. Per multitasking si intende la possibilità da parte del sistema operativo di far girare contemporaneamente più di una applicazione.
Ogni programma, ogni comando che si lancia, ogni servizio attivo sul sistema da origine a uno o più processi.
Ad ogni processo viene assegnato un numero che lo identifica univocamente, chiamato PID (Process IDentificator). Ogni processo, tranne init (a cui corrisponde il PID 1), è generato da un'altro processo di cui si definisce il PPID (Parent PID). Si parla quindi di processo padre (parent) e processo figlio (child).
Un processo consta di: codice eseguibile, posizione di esecuzione, dati che gestisce, file aperti, ambiente di esecuzione, credenziali.
Quando lo stesso programma è eseguito più volte nel sistema, anche da parte di utenti diversi, alcune parti dello stesso possono essere condivise (shared) in memoria: il codice in esecuzione e le eventuali librerie di sistema caricate, altre parti come i dati, i file aperti, il PID.
Un processo può generare una copia di se stesso (fork), cha ha PID diverso e PPID uguale al proprio PID.
La Schedulazione da parte del kernel
Nel kernel di un sistema operativo lo schedulatore (dispatcher) è responsabile della coordinazione dei processi in esecuzione per gestire i loro accessi alle risorse e assicurare che abbiano accesso alla CPU per un tempo relativo alla loro priorità assegnata, senza rischiare che alcuni processi intasino completamente il CPU time ed altri non riescano ad utilizzarla minimamente.
La schedulazione è un'operazione del kernel che definisce i seguenti stati di processo:
R - running, il processo è in esecuzione;
S - sleeping, il processo è in attesa (input dell'utente, conclusione di altri processi ecc..);
Z - zombie, il processo è morto ed aspetta che il parent chieda un codice d'uscita.
Ad ogni processo è associata una priorità, un valore che varia fra -20 e 19, che determina quanta CPU time rispetto agli altri il sistema gli deve dedicare.
La priorità pre-impostata di un task è 0 (-20 è considerata la priorità più alta). Solo l'amministratore puo resettare la priorità di un processo per portarla al di sotto di 0, ma i normali utenti possono variare la priorità per i valori positivi (usando il comando 'renice').
I nuovi processi ereditano la priorità dei loro padri.
JOB
La shell Unix è il tipico mezzo con cui vengono lanciati processi sul sistema (oltre ad essere essa stessa un normale processo), la shell assegna ad ogni processo lanciato da un utente un numero di job, e permette di mandare in foreground o background al sua esecuzione.
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Massimiliano 'Max_Rispetto' Grassi - Ultimo Aggiornamento: 2004-05-23 16:02:11
Comando che mostra un'istantanea dei processi correnti. Le opzioni sulla riga di comando possono opzionalmente essere precedute da un '-', ma non è necessario.
ps [- ] [lujsvmaxScewhrnu ] [txx ] [O [+ |- ]k1 [[+ |- ]k2 ...]] [pids ]
m
mostra informazioni sulla memoria (assieme con il flag p da il numero di pagine)
u
formato utente: da il nome dell'utente e l'ora d'inizio
f
le righe di comando sono mostrate in un albero
a
mostra anche i processi degli altri utenti
x
mostra i processi che non controllano un terminale
S
aggiunge il tempo di cpu dei figli e i page fault
r
solo processi running
pid
Elenca solo i processi specificati; sono separati da virgole. La lista deve essere data immediatamente dopo l'ultima opzione di una riga di comando con un unico argomento, senza introdurre spazi, p.es. ps -j1,4,5
--help
restituisce un messaggio d'aiuto che riassume l'uso e da un lista delle sort key supportate.
--version
mostra la versione
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Massimiliano 'Max_Rispetto' Grassi - Ultimo Aggiornamento: 2002-10-13 20:01:34
Ogni programma eseguito su un sistema è un processo, identificato con un suo PID. Quando un programma viene eseguito da una shell, assume anche un numero di job e può essere gestito all'interno della shell.
Le modalità fondamentali con cui si possono lanciare i job sono due: in foreground e in background.
Nella prima l'utente attende che l'esecuzione del suo processo termini prima di riottenere il prompt della shell.
Nella seconda invece il prompt viene restituito subito e il processo continua l'esecuzione. In questo modo l'utente può continuare a lavorare e quindi, volendo, potrebbe lanciare altri programmi in background.
Il segno & scritto alla fine del comando dice alla shell di eseguirlo in background e ridare subito il prompt.
Con CTRL-C si interrompe un processo.
Con CRTL-Z si mette in “pausa” un processo e si ritorna al prompt della shell.
La shell prevede una serie di comandi interni per gestire i job:
jobs: mostra i processi attivi in background lanciati da un certo utente. Il numero tra parentesi che viene restituito a video è il numero di, il “+” significa che è l’ultimo processo ad essere stato sospeso (fg senza parametri fa ripartire l’ultimo processo sospeso), l’altro numero è il PID.
bg: Esegue in background un processo precedentemente interrotto.
fg: Esegue un processo in primo piano.
Esistono inoltre vari comandi (file autonomi, non incorportati nella shell) utili per gestire i processi:
kill: Invia un segnale ad un processo attivo (normalmente utilizzato per fermare un processo).
nice [priority] [command]: E' un prefisso utilizzato per assegnare un certo livello di priorità al comando che si sta per eseguire. -20 vuol dire massima priorità, 19 è minima priorità.
nohup
ps: Visualizza un elenco dei processi in fase di esecuzione
pstree: Simile a ps ma mostra chiaramente le relazioni tra processi padre e processi figli.
top: Visualizza un elenco dei processi che sfruttano intensamente il processore e consumano molta memoria.
SOURCE: Clikkami.com - http://www.clikkami.com/ex-linux.html
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Massimiliano 'Max_Rispetto' Grassi - Ultimo Aggiornamento: 2002-09-21 10:54:43
Comando che riporta informazioni sui processi, sulla memoria, sulla paginazione, sui block IO, i trap e l'attività della CPU.
La prima volta mostra le medie dall'ultimo reboot. Le volte successive mostra informazioni su un periodo di campionamento di lunghezza "delay". I report sui processi e la memoria sono istantanei in entrambi i casi.
Questi report sono pensati per identificare i "colli di bottiglia" del sistema. Il vmstat di Linux non si conta come processo in esecuzione.
Tutti i blocchi di Linux attualmente sono da 1k, ad eccezione per i blocchi del CD-ROM che sono da 2k.
vmstat [-n] [delay [num]]
vmstat[-V]
-n
mostra l'header solo una volta invece che periodicamente.
delay
è il ritardo in secondi tra gli aggiornamenti. Se non è specificato alcun ritardo, è mostrato solo un report con i valori medi dal reboot.
num
è il numero degli aggiornamenti. Se non è specificato ed è definito il ritardo, allora num di default è infinito.
-V
mostra informazioni sulla versione
Esempio di output
procs | memory | swap | io | system | cpu | ||||||||||
r | b | w | swpd | free | buff | cache | si | so | bi | bo | in | cs | us | sy | id |
0 | 0 | 0 | 0 | 307240 | 69292 | 66456 | 0 | 0 | 0 | 1 | 101 | 5 | 0 | 0 | 100 |
Procs
Memory
Swap
IO
System
CPU
SOURCE: ILDP (Italian Linux Documentation Project) - http://ildp.pluto.linux.it/man/man8/vmstat.8.html
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Massimiliano 'Max_Rispetto' Grassi - Ultimo Aggiornamento: 2002-09-28 00:45:59
Comando che fornisce in tempo reale istantanee dell'attività del processore. Mostra una lista dei task del sistema che fanno un uso più intenso della CPU, e può mettere a disposizione un'interfaccia interattiva per manipolare i processi. Può ordinare i task in base all'uso della CPU, all'uso della memoria e al tempo d'esecuzione.
top [-] [d delay] [q] [c] [S] [s] [i]
d
Specifica l'intervallo tra gli aggiornamenti della schermata. Lo si può cambiare con il comando interattivo s.
q
Fa si che top si aggiorni senza nessun ritardo. Se il chiamante ha i privilegi del superuser, top gira alla più alta priorità possibile.
S
Specifica il cumulative mode, nel quale ogni processo è mostrato con il tempo di CPU che conprende anche quello speso dai figli che sono già terminati. È come il flag -S di ps
.
s
Dice a top di girare in secure mode. Disabilita i pericoli potenziali dei comandi interattivi (vedere sotto).
i
Avvia top ignorando qualsiasi processo idle o zombie. Si veda sotto il comando interattivo i.
c
Mostra la riga di comando invece del solo nome del comando.
Descrizione dei campi
top mostra una varietà di informazioni sullo stato del processore. Di default la schermata si aggiorna ogni 5 secondi, ma questo può essere cambiato con l'opzione d in riga di comando o con il comando interattivo s.
uptime
mostra da quanto tempo il sistema è "su", e i tre carichi medi del sistema. I carichi medi sono il numero medio di processi pronti per essere eseguiti durante gli ultimi 1, 5 e 15 minuti. Questa riga è come l'output di uptime
. La visualizzazione dell'uptime può essere disattivata (e riattivata) con il comando interattivo l.
processes
mostra il numero totale di processi in esecuzione quando è stato fatto l'ultimo aggiornamento. Questo è poi suddiviso nel numero di task che sono running, sleeping, stopped, o undead. La visulizzazione di processes e states può essere disattivata (e riattivata) con il comando interattivo t.
CPU states
mostra la percentuale del tempo di CPU speso in user mode, system mode, niced task, e idle. (I niced task sono solo quelli il cui valore nice è negativo). Il tempo speso in niced task sarà contato anche in system e user time, così il totale sarà più del 100%. La visualizzazione di processes e states può essere disattivata (e riattivata) con il comando interattivo t.
Mem
. Statistiche sull'uso della memoria, incluse la memoria complessiva disponibile, la memoria libera (free), la memoria condivisa (shrd), e la memoria usata per i buffer. La visualizzazione della memoria può essere disattivata (e riattivata) con il comando interattivo m.
Swap
. Statistiche sulla swap, incluse lo spazio di swap totale, lo spazio di swap disponibile, e lo spazio di swap usato. Questo e Mem sono in pratica l'output di free
.
PID
. Il process ID di ognuno dei task.
PPID
. Il parent process ID di ognuno dei task.
UID
. Lo user ID del proprietario del task.
USER
. Il nome utente del proprietario del task.
PRI
. La priorità del task.
NI
. Il valore nice del task. Valori negativi corrispondono a priorità più basse.
SIZE
. Sono qui mostrati la dimensione, in Kbyte, del codice del task più i dati più lo stack.
TSIZE
. La dimensione del codice del task. Da strani valori per i processi del kernel e non funziona per i processi ELF.
DSIZE
. Dimensione di Data + Stack. Non funziona per i processi ELF.
TRS
. Dimensione del text residente.
SWAP
. Dimensione della porzione del task swappata.
D
. Dimensione della pagine marcate dirty.
LIB
. Dimensione delle library page usate. Non funziona per i processi ELF.
RSS
. È qui mostrato l'ammontare, in Kbyte, delle memoria fisica usata del task.
SHARE
. L'ammontare della memoria condivisa usata del task.
STAT
. È qui mostrato lo stato del processo. Lo stato è S per sleeping, D per uninterruptible sleep, R per running, Z per zombie, oppure T per stopped o traced. Questi stati sono seguiti da < per un processo con un valore di nice negativo, da N per un processo con un valore di nice positivo, da W per un processo swappato (questo non funziona correttamente per i processi kernel).
WCHAN
. A seconda dalla disponibilità di /boot/psdatabase o della kernel link map /boot/System.map mostra l'indirizzo o il nome della funzione kernel sulla quale il task è in sleep.
TIME
. Il tempo di CPU totale usato dal task da quando è partito. Se è abilitato il cumulative mode, include anche il tempo di CPU usato dai suoi processi figlio che sono terminati. Il cumulative mode lo si può abilitare con l'opzione S in riga di comando oppure con il comando interattivo S. L'etichetta sulla riga di header sarà cambiata in CTIME.
%CPU
. La porzione del task del tempo di CPU dall'ultimo aggiornamento della schermata, espressa come percentuale del tempo di CPU totale.
%MEM
. La porzione del task della memoria fisica.
COMMAND
. La riga di comando del task; sarà troncata se è troppo lunga per essere mostrata in una riga. Sarà mostrata la riga di comando completa per i task in memoria, mentre sarà mostrata solo il nome del programma fra parentesi per i task swappati (per esempio, "(getty)").
Comandi interattivi
Mentre top è in esecuzione sono riconosciuti diversi comandi "single-key". Alcuni sono disabilitati se è stata data l'opzione s in riga di comando.
^L
- Cancella e riscrive la schermata.
h
o ?
- Mostra un schermata d'aiuto che da una breve sommario dei comandi, e lo stato dei secure e cumulative mode.
k
- Killa un processo. Sarà chiesto il PID del task, e il signal da inviare. Per un kill normale, inviare il signal 15. Per un kill sicuro, ma piuttosto brutale, inviare il signal 9. Il signal di default, come per kill
, è il 15, SIGTERM. Questo comando non è disponibile in secure mode.
i
- Ignora i processi idle e zombie.
n
o #
- Cambia il numero di processi da mostrare. Sarà chiesto di inserire un numero. Ciò ignora la determinazione automatica del numero di processi da mostrare, basata sulla misura delle dimensioni della finestra. Se è specificato 0 (impostato di default), allora top mostrerà tanti processi quanti ce ne stanno sullo schermata.
q
- Esce.
r
- Re-nice un processo. Sarà chiesto il PID del task, e il nuovo valore del nice. L'inserimento di un valore positivo fa si che il processo sia "niced" ad un valore negativo, e perda di priorità. Se top è eseguito da root, può essere immesso un valore negativo che assegna ad un processo una priorità più alta di quella normale. Questo comando non è disponibile in secure mode.
S
- Abilita il cumulative mode, l'equivalente di ps -S, cioè, i tempi di CPU comprenderanno anche i processi figlio defunct. Per alcuni programmi, come i compilatori, che lavorano con fork in molti task separati, il modo normale li fa apparire meno esigenti di quello che in realtà sono. Per gli altri, come le shell e init, questo comportamento è corretto. In ogni caso, si provi il cumulative mode per una visione alternativa dell'uso della CPU.
s
- Cambia l'intervallo tra gli aggiornamenti. Sarà chiesto di inserire l'intervallo temporale, in secondi, tra gli aggiornamenti. Valori frazionari sono riconosciuti fino ai microsecondi. L'inserimento di 0 causa un aggiornamento continuo. Si noti che valori bassi causano delle schermate praticamente illeggibili, e un grosso incremento del carico. Questo comando non è disponibile in secure mode.
f
o F
- Aggiunge o rimuove campi da mostrare nella schermata. Si veda sotto per ulteriori informazioni.
o
o O
- Cambia l'ordine dei campi visualizzati. Si veda sotto per ulteriori informazioni.
l
- Disabilita (riabilita) la visualizzazione delle informazioni sul carico medio e l'uptime.
m
- Disabilita (riabilita) la visualizzazione delle informazioni sulla memoria.
t
- Disabilita (riabilita) la visualizzazione delle informazioni sui processi e sullo stato della CPU.
c
- Disabilita (riabilita) la visualizzazione del nome del comando o dell'intera riga di comando.
M
- Ordina i task in base all'uso di memoria residente.
P
- Ordina i task in base all'uso della CPU (default).
T
- Ordina i task in base al tempo (o al tempo comulativo).
W
- Scrive la configurazione corrente sul file ~/.toprc. Questo è il modo raccomandato per scrivere il file di configurazione di top.
SOURCE: ILDP (Italian Linux Documentation Project) - http://ildp.pluto.linux.it/man/man1/top.1.html
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Massimiliano 'Max_Rispetto' Grassi - Ultimo Aggiornamento: 2002-09-28 00:41:40
Comando che visualizza la struttura ad albero dei processi sul sistema, e mostra anche quelli che hanno generato altri (ossia i processi "padre" e i processi "figli").
pstree [-a] [-c] [-h] [-l] [-n] [-p] [-u] [-G|-U] [pid|utente]
pstree [-V]
- a
Mostra gli argomenti della riga di comando
- h
Evidenzia il processo corrente e i suoi antenati
- n
Ordina i processi con lo stesso antenato in base al PID
- p
Mostra i PID. I PID sono mostrati in numeri decimali tra parentesi dopo ogni nome di processo. -p disabilita implicitamente la compattazione
- V
Mostra la versione
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Massimiliano 'Max_Rispetto' Grassi - Ultimo Aggiornamento: 2002-10-06 18:04:14
Comando per mandare un segnale ad un processo (non necessariamente di chiusura).
kill [ -s signal | -p ] [ -a ] pid ...
kill -l [ signal ]
pid ...
Specifica la lista di processi ai quali kill deve inviare il signal. Si può scegliere fra cinque opzioni:
n il processo con pid n viene killato (n maggiore di 0)
0 tutti i processi nel gruppo processi corrente vengono killati
-1 tutti i processi con pid maggiore di 1 vengono killati
-n tutti i processi nel gruppo processi n vengono killati (n maggiore di 0)
name tutti i processi che hanno nome name vengono killati
-s
Specifica il signal da inviare. Il signal può essere dato come il nome o il numero del signal
-l
Mostra una lista dei nomi dei signal
-p
Specifica che kill deve solo mostrare il pid dei processi nominati, e non deve mandare loro un signal
Tipo Infobox: BOFH - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2005-06-21 16:01:59
Visualizzare la stringa completa di startup di un processo non è sempre possibile.
Qualora la stringa che identifica come è stato lanciato sia troppo lunga per poterla vedere completamente con un normale comando ps
, è possibile utilizzare il file system virtuale /proc
, che mostra la command line che ha dato il via al processo nella variabile cmdline
.
[azitti@pegasus azitti]$ ps -adef | grep mysql
root 6912 1 0 Jan28 ? 00:00:00 /bin/sh ./bin/mysqld_safe --data
mysql 6936 6912 0 Jan28 ? 00:00:00 /usr/local/mysql/bin/mysqld --de
Essendo molto lunga la stringa di startup dei processi 6912 e 6936 non sono visualizzabili completamente
[azitti@pegasus azitti]$ cat /proc/6912/cmdline
/bin/sh./bin/mysqld_safe--datadir=/usr/local/mysql/data--pid-file=/usr/local/mysql/data/pegasus.pid
[azitti@pegasus azitti]$ cat /proc/6936/cmdline
/usr/local/mysql/bin/mysqld--defaults-extra-file=/usr/local/mysql/data/my.cnf
--basedir=/usr/local/mysql--datadir=/usr/local/mysql/data--user=mysql
--pid-file=/usr/local/mysql/data/pegasus.pid--skip-locking
Nel file sytem /proc è possibile trovare le directory relative ai processi attivi nel sistema
All'interno della directory /proc/$PID
(dove $PID è il PID di qualsiasi processo in esecuzione sul sistema) sono inoltre disponibili moltre altre informazioni di basso livello sul processo stesso come variabili d'ambiente, risorse occupate, link al file binario.
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alfonso 'Alian' Iannotta - Ultimo Aggiornamento: 2005-06-21 15:56:18
E' possibile fermare programmi in background che tentano di scrivere l'output su terminale.
Se eseguiamo un processo in background senza ridirezionare l'output, avremo che il testo scritto da tale processo verrà visualizzato sullo schermo senza controllo. Questo fastidioso effetto può essere eliminato tramite il seguente comando: stty tostop
.
Dopo aver dato questo comando tutti i processi in background che tentano di scrivere sul terminale saranno fermati ed eseguendo il comando jobs sulla shell apparirà il seguente messaggio:
[1] + Stopped (tty output) nomeJob
Volendo far ripartire il processo in background e vedere l'output dello stesso, è necessario portarlo in foreground tramite il comando fg
. E' possibile disabilitare questa funzione tramite il con: stty -tostop
.
Debugging dei processi |
Strumenti e indicazioni su come eseguire il debugging delle applicazioni: strace, lsof, ldd. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-07 16:37:07
L'opera di debugging di un processo non è generalmente argomento proponibile ad un sistemista non esperto, anche perchè spesso riguardano problemi sul lato applicativo che vanno affrontati direttamente dallo sviluppatore.
In ogni caso, nella vita di ogni sysadm capita sistematicamente che dei servizi non partano o dei programmi non facciano quello che dovrebbero fare (non inchiodarsi, innanzitutto), oppure, più subdolamente, abbiano comportamenti erratici o problemi di prestazioni o di sopportazione di alti carichi.
Senza volersi addentrare in problematiche di debugging avanzato, si possono elencare alcuni strumenti a disposizione del sistemista per diagnosticare simili problemi:
Log
I log sono sempre la prima cosa da guardare perchè di solito contengono abbastanza informazioni da farci capire dove intervenire. Eventualmente analizzare syslog.conf
o le istruzioni e le configurazioni del singolo programma per capire dove vengono loggati i suoi messaggi e poi leggere i messaggi di errore sui log che ci interessano.
Debug
Quasi sempre è possibile lanciare un programma con diversi livelli di debug: aumentando la verbosità del debug (di solito registrato sul file di log) si aumenta la possibilità di capire cosa non funziona. Tipicamente il livello di debug può essere impostato come opzione da command line o nel file di configurazione.
Comandi di diagnostica
Unix mette a disposizione vari comandi utili per capire cosa fa un processo e come si comporta il sistema. SU Linux si possono comunemente trovare i seguenti tool:
strace
Traccia le chiamate di sistema e i segnali del programma specificato mentre lo esegue. Ovviamente va utilizzato solo per fini diagnostici, rallentando particolarmente la velocità di esecuzione. Spesso non è nemmeno necessario capire l'output di strace (invero piuttosto verboso e per molti incomprensibile), basta cercare righe dove si parla di errori e vengono indicati path o funzioni specifiche. Spesso un programma non funziona perchè non trova certi file (librerie ecc) o non ha i permessi adeguati sugli stessi, un grep ENOENT
sullo stdout di strace può evidenziare tutte le volte in cui si è cercato un file senza trovarlo (spesso questo non è un problema, in quanto un processo può trovare un file dopo averlo cercato senza successo in varie directory (con relativo messaggio di errore "ENOENT (No such file or directory)".
ldd
Stampa l'elenco delle librerie condivise utilizzate dal comando specificato
lsof
Elenca gli open file del sistema. Un open file può essere: un normale file, una directory, un file speciale a blocchi o caratteri, una librerira, una socket Internet, una socket Unix domain... E' utile per vedere le risorse utilizzate da un programma (e, per esempio, capire dove sta loggando).
LINK: Strace HomePage - http://www.liacs.nl/%7Ewichert/strace/
LINK: Introduction to Reverse Engineering Software
Next
Introduction to Reverse Engineering Software - http://www.acm.uiuc.edu/sigmil/RevEng/
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Massimiliano 'Max_Rispetto' Grassi - Ultimo Aggiornamento: 2004-05-23 16:02:54
ldd (List Dynamic Dependencies) permette di determinare quali librerie condivise vengono utilizzate da un file eseguibile. All'output viene stampato l'elenco delle librerie necessarie al file e il loro percorso.
ldd [opzione] nome_file
-v
"verbose", opzione che stampa tutte le informazioni riguardanti le librerie utilizzate dal file.
Vediamo un esempio. Eseguendo il comando ldd /bin/ls
, verrà visualizzato l'elenco delle librerie che vengono utilizzate dal comando ls
.
libtermcap.so.2 => /lib/libtermcap.so.2 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x40022000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Questo vuol dire che il comando ls dipende dalla presenza di libtermcap.so.2 (libreria che descrive le capacità di un terminale) e da libc.so.6 (la libreria C).
Se un programma non dipende da alcuna libreria, ldd stamperà la stringa statically linked (ELF) oppure statically linked.
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Massimiliano 'Max_Rispetto' Grassi - Ultimo Aggiornamento: 2002-10-15 18:20:53
lsof (List Open Files) elenca gli "open file" del sistema, cioè normali file, file speciali a blocchi o caratteri, directory, librerie condivise, processi, socket, etc.
lsof [opzioni]
Eseguendo lsof
senza opzioni si genera l'elenco completo dei file aperti sul sistema, che generalmente è piuttosto lungo.
Le opzioni più interessanti sono:
-p [numero]
stampa gli open file in base al pid specificato
-i
stampa solo i processi Internet. Molto utile per esaminare le porte aperte che aspettano tentativi di connessione (e quindi anche potenziali intrusi).
lsof è un tool molto utile utilizzato in combinazione col comando grep
.
Ad esempio, eseguendo lsof | grep sshd
si visualizzano sia file aperti da sshd che la porta su cui sta "ascoltando" (LISTEN) o eventuali connessioni aperte.
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Massimiliano 'Max_Rispetto' Grassi - Ultimo Aggiornamento: 2002-10-16 17:52:52
strace è un tool molto utile per il debugging, eseguendo un "Signal Trace" ("Tracciamento dei Segnali", ndt). Il suo utilizzo permette di eseguire un programma tenendo sotto controllo tutti i segnali e le chiamate di sistema. In questo modo si possono ricercare eventuali errori e capire dove il programma non funziona. Strace è anche in grado di "attaccarsi" a un processo già in esecuzione e tracciarne i segnali.
strace [opzioni]
-o [file_output] [nome_comando]
esegue uno strace di un programma registrando l'output in un file, permettendo cosi una comoda analisi a posteriori
-p PID
collega strace ad un processo già in corso inserendo il PID
Vediamo un esempio. strace -o debug.txt netstat scrive su debug.txt l'output del tracing di netstat. Attenzione! Strace produce una grande quantità di output e rallenta notevolmente la macchina: la chiamata appena effettuata produce 235 righe di output in meno di 2 secondi, ma si può arrivare tranquillamente anche oltre 5000. Per questo è sempre utile stampare l'output in un file.
Spesso un programma non funziona perchè non trova certi file o librerie o non ha i permessi adeguati sugli stessi. Per rimediare basta fare | grep ENOENT: indica che non è riuscito a trovare un file o una directory.
LINK: Strace Homepage - http://www.liacs.nl/%7Ewichert/strace/
Il processo di boot di un sistema Linux ha 4 fasi fondamentali:
- Il BIOS (a livello hardware)
- Il Linux Loader (Lilo e Grub sono i più diffusi)
- Il caricamento del kernel
- L'avvio di Init, il padre di tutti i processi, da cui vegnono lanciati tutti i programmi secondo la logica degli script rc.
Questo è un altro tassello fondamentale per la conoscenza del sistema e la capacità di diagnosticare eventuali problemi.
Il quadro generale è esplicitato in Il processo di boot.
Informazione sui Linux loaders, i loro file di configurazione e come si usano sono in Linux loades: Lilo e grub.
I dettagli su Init e gli script che vengono eseguiti durante il boot del sistema sono in Init e runlevels
Il processo di boot |
Descrizione del processo di boot su sistemi Intel: ROM BIOS - LINUX LOADER - KERNEL LOADING - INIT |
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: 4- ADVANCED - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-12-06 21:02:25
Quando il kernel entra in azione e inizia a caricarsi procede con il riconoscimento e l'inizializzazione dell'hardware presente.
Durante il caricamento presenta a video una serie di informazioni, a volte fin troppo dettagliate, sull'hardware trovato.
Per vedere i messaggi del kernel basta digitare il comando dmesg
, che mostra esattamente quanto viene visualizzato dal kernel durante il boot (in tempi troppo rapidi per essere leggibili).
Segue l'esempio di un dmesg. Alcune parti variano a seconda dell'hardware presente sul sistema, altre sono sostanzialmente uguali su tutti i Linux. Quello che segue è il dmesg di un sistema piuttosto semplice, i kernel modulari di una distribuzione standard solitamente presentano ulteriori informazioni relative a driver per hardware o funzionalità qui non presenti.
Linux version 2.4.13 (root@llocalhost) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)) #5 Fri Nov 9 16:36:50 CET 2001
Questa prima riga mostra la versione del kernel (2.4.13) del compilatore interno (gcc), della versione del sistema operativo
Detected 200.457 MHz processor.
Ha rilevato la frequenza del processore a 200 MHz
Console: colour VGA+ 80x25
Inizializza la console e ne indica le proprietà (a colori, con 80 colonne per 25 righe)
Calibrating delay loop... 666.82 BogoMIPS
Test per verificare la velocità del processore. Più sono alti i BogusMIPS più è veloce la CPU:
Memory: 62272k/65536k available (1091k kernel code, 2880k reserved, 315k data, 212k init, 0k highmem)
Rilevazione della memoria fisica disponibile. Se il kernel non riesce ad individuare correttamente la memoria presente sul sistema, provare ad usare l'argomento mem al boot con LILO (es: mem=256M per dire al kernel che il sistema ha 256 Mb di memoria)
CPU: Intel Pentium II (Deschutes) stepping 01
Identificazione del processore
POSIX conformance testing by UNIFIX
PCI: PCI BIOS revision 2.10 entry at 0xfb5c0, last bus=0
Inizializzazione delle periferiche PCI
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Inizializzazione delle porte seriali
hda: IBM-DTTA-351010, ATA DISK drive
Identificazione dell'hard-disk
Partition check:
hda: hda1 hda2
Verifica dell'integrità delle partizioni da montare.
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
00:11.0: 3Com PCI 3c900 Cyclone 10Mbps Combo at 0x6400. Vers LK1.1.16
Inizializzazione del driver della scheda di rete e rilevazione del chip
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
Inizializzazione del TCP/IP ed elenco dei protocolli supportati dal kernel.
A fine caricamento il kernel lancia init, il padre di tutti i processi, che provvede al lancio dei servizi e dei programmi che devono girare sul sistema.
LINK: Linux Gazette: Dmesg Explained - http://www.linuxgazette.com/issue59/nazario.html
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-08 15:14:53
Visualizza i messaggi di avvio del kernel. Disponibile su Linux.
dmesg [opzioni]
Viene solitamente usato da solo, senza opzioni (che sono disponibili per operazioni poco usate).
SOURCE: Man Pages - http://man.openskills.info/dmesg
SOURCE: Man Pages - http://man.openskills.info/dmesg
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2003-08-13 12:41:26
Visualizza da quanto tempo il sistema è attivo.
Uptime visualizza una riga contenente l'ora corrente, da quanto tempo il sistema è up, quanti utenti sono loggati attualmente sul sistema, il carico medio di utilizzo del sistema nell' ultimo minuto, negli ultimi 5 e negli ultimi 15 minuti. Le informazioni visualizzate vengono ricavate da /var/run/utmp
, /proc
e /proc/loadavg
.
homer@Joker:~$ uptime
10:13:24 up 1:44, 3 users, load average: 0.06, 0.02, 0.00
Sono le ore 10.13, il sistema è up da 1 ora e 44 minuti, al momento ci sono 3 utenti loggati e il carico medio della cpu negli ultimi 1,5, e 15 minuti è stato rispettivamente 0.06, 0.02, 0.00
Linux loaders: LILO, Grub |
Installazione e configurazione di LILO, GRUB e altri Linux loader |
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: ETCETERA - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-31 09:01:39
Non è raro sentire di utenti che hanno provato, animati da ottime intenzioni e buona volontà, ad installare Linux sul proprio PC, con Windows già installato, e per qualche errore o svista o inesperienza in fase di installazione non riescono più a "vedere" e caricare il proprio Windows.
In questi casi, arrabbiature, delusione, disillusione e sconforto fanno diventare un potenziale nuovo utente di Linux in un suo acceso detrattore.
Le distribuzioni recenti ormai sono piuttosto efficaci nel riconoscere e preservare l'installazione Windows esistente e far pacificamente convivere i due sistemi operativi, al punto che è sempre consigliabile, se si vuole un sistema Dual Boot, installare prima Windows e poi Linux (i SO di Microsoft sono generalmente più invadenti, sotto questo aspetto, e non tollerano/prevedono facilmente coesistenze).
Di fatto, comunque, è possibile fare 2 tipi di danni sul Windows pre esistente quando si prova ad installare il pinguino:
- Cancellare completamente il vecchio Windows, distruggendone o sovrascrivendo la partizione in cui è installato (era il caso di prestare più attenzione i WARNING segnalati durante l'installazione di Linux)
- Sovrascrivere il Master Boot Record del proprio hard disk con LILO o GRUB o altri Linux Loader senza aver l'opzione di caricare Windows: in questo caso non viene propriamente cancellato Windows dal proprio hard disk, ma soltanto la possibilità di caricarlo al boot.
In questo caso il ripristino dello status quo è relativamente semplice:
Procurarsi un floppy di boot o di ripristino o un CDROM di Windows.
Se è un Windows 95, 98, Me, digitare dal DOS: fdisk /mbr
Se si è sulla console di ripristino di Windows 2000, scrivere: fixmbr
In entrambi i casi si sovrascrive e si azzera il MBR dove verosimilmente è stato installato un Linux Loader come LILO e si potrà ritrovare il proprio Windows.
L'effetto collaterale di questa operazione è che a questo punto non sarà più accessible il Linux appena installato: se si sono creati dei floppy di ripristino durante l'installazione di Linux potrà essere possibile caricare Linux con quelli ed eventualmente configurare /etc/lilo.conf (o analoghi file di configurazione del Linux Loader) in modo corretto. Altrimenti è generalmente possibile operare il ripristino bootando dal CDROM usato per l'installazione.
LINK: Creazione di Recovery Disk su Windows NT/2000/XP - http://www.xxcopy.com/xxcopy33.htm
LINK: Creazione di Recovery Disk su Windows 9x/Me - http://www.xxcopy.com/xxcopy32.htm
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: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2002-10-25 18:42:50
Grub ha una nomenclatura tutta sua per indicare i diversi devices e partizioni, e questo puo creare problemi, soprattutto se si edita per la prima volta il suo file di configurazione.
Differenze tra la nomenclatura standard di Unix e quella di Grub:
Primary Master IDE: hdaN (Unix) hd0,N (Grub)
Primary Slave IDE: hdbN (Unix) hd2,N (Grub)
Secondary Master IDE: hdcN (Unix) hd1,N (Grub)
Secondary Slave IDE: hddN (Unix) hd3,N (Grub)
dove N sta per il numero della partizione interessata.
Per quanto riguarda i dischi SCSI vale la stessa logica (sdaN di Unix equivale a sd0,N di Grub e cosi via).
Init e runlevels |
Init, i runlevel e la gestione dei servizi da avviare al boot. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-23 16:05:49
Init è il padre di tutti i processi, il suo ruolo principale consiste nel gestire il lancio di tutti i programmi necessari per rendere il sistema attivo creare i processi a partire dal suo file di configurazione: /etc/inittab.
Nell'inittab vengono definite le directory con gli script di avvio per i diversi runlevel (stati del sistema, in cui possono girare determinati programmi), il runlevel di default, altri script e comandi che vengono eseguiti al boot o in condizioni particolari.
Il primo script lanciato da inittab è (su RedHat Linux) /etc/rc.d/rc.sysinit: che esegue varie operazioni tra cui:
Impostazioni di alcuni path generali nella variabile $PATH; Configurazione dell'ambiente di rete;
Avvio swap per la memoria virtuale;
Impostazione del nome dell'host;
Check del filesystem root;
Check delle quote di spazio assegnate agli utenti, se previste;
Mount del filesystem root in modalità scrittura/lettura;
Preparazione del sistema per caricamento dei moduli;
Check delle dipendenze dei moduli;
Check di tutti i filesystem ed eventuali riparazioni;
Mount di tutti i filesystem;
Pulizia di file di supporto al boot e di processi non più attivi;
Umount dell'initrd;
Impostazione dell'orologio;
Attivazione dello swapping;
Inizializzazione delle porte seriali;
Caricamento Moduli;
Attivazione dei servizi del runlevel.
Durante la fase di file system check, se si trovano errori che non possono essere riparati automaticamente è possibile che il processo di boot si blocchi. In questo caso viene richiesta la password di root e si può da shell fare un file system check manuale. Verificare su quale partizione il kernel si è fermato e scrivere (si considera che la partizione sia /dev/hda5 e abbia ext2 come file system): fsck.ext2 /dev/hda5.
Rispondere SI a tutte le lugubri domande sulla correzione di file danneggiati.
Ogni sistema Unix gestisce con file e procedure diverse il processo di boot, ma tutti si basano su Init e il suo file di configurazione inittab
. Per cui basta analizzare questo file e capirne la logica per poter capire come viene caricato il sistema ed intervenire dove necessario in caso di problemi.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-05 12:15:20
Nel mondo Unix ci sono 2 principali approcci al processo di startup del sistema: quello usato da Unix System V e quello, meno complesso ma meno flessibile, usato dai BSD Unix.
Linux utilizza il primo metodo, che si basa su differenti runlevel, astrazioni software per indicare diversi stati della macchina in cui possono girare diversi programmi.
In genere su Linux sono utilizzati i seguenti livelli:
Runlevel 0 : /etc/rc.d/rc0.d
Questo runlevel avvia la sequenza di arresto del sistema (shutdown)
Runlevel 1: /etc/rc.d/rc1.d
Questo runlevel rappresenta la modalità singolo utente, nessun altro utente può collegarsi, il servizio di rete è disabilitato.
Runlevel 2: /etc/rc.d/rc2.d
Rappresenta lo stato multiutente, il servizio rete è attivo ma è disabilitato il file sharing.
Runlevel 3: /etc/rc.d/rc3.d
In genere è quello predefinito quando si opera in modalità testuale, tutti i servizi sono attivi.
Runlevel 4: /etc/rc.d/rc4.d
Inutilizzato. Può essere dedicato ad usi personali
Runlevel 5: /etc/rc.d/rc5.d
E' il runlevel predefinito quando si vuole avviare Linux in modalità grafica
Runlevel 6: /etc/rc.d/rc6.d
Il runlevel 6 è quello di reboot.
Lo script /etc/rc.d/rc
gestisce quali processi far partire a seconda del runlevel, andando ad analizzare le singole directory /etc/rc.d/rc#.d. In queste directory esistono una serie di symlink con nomi del tipo S12syslog o K65identd che puntano a degli script con nomi tipo /etc/rc.d/init.d/syslog o /etc/rc.d/init.d/identd.
/etc/rc.d/rc a seconda della directory corrispondente al runlevel da caricare fa partire tutti gli script che iniziano con S e fa chiudere tutti quelli che iniziano con K, eseguendoli nell'ordine indicato dal numero presente nei nomi dei file.
Gli script che di fatto permettono di gestire l'avvio o lo stop di un servizio sono quindi nella directory /etc/rc.d/init.d/
e possono essere utilizzati direttamente dall'utente per gestire i singoli processi.
Per esempio: /etc/rc.d/init.d/httpd start fa partire il server Web e /etc/rc.d/init.d/stop lo fa stoppare.
Se abbiamo il file (link a ../init/httpd ) /etc/rc.d/rc3.d/S85httpd, quindi, avremo un server web avviato quando la macchina è al run-level3 (runlevel di default per un server, che non ha bisogno di Xwindows).
Se vogliamo evitare che venga avviato un server web, bastera rinominare il file, sostituendo la K alla S:
mv /etc/rc.d/rc3.d/S85httpd /etc/rc.d/rc3.d/K85httpd
Nel fare queste operazioni va sempre considerato il numero dopo la prima lettera, che determina l'ordine di esecuzione degli script.
Questa è una logica comune a tutti gli Unix derivati da System V, possono cambiare i nomi dei runlevel, e in certi casi la funzione, ma non la logica di questra struttura di boot.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-05-08 14:22:08
La struttura di gestione dei processi e degli script da avviare al boot sulla base delle directory /etc/rc.* permette di stabilire cosa eseguire e cosa no con una logica ben precisa anche se non particolarmente semplice.
Su tutti gli Unix esistono tool, testuali o grafici, che permettono di gestire più facilmente quali servizi avviare al boot.
Per esempio, su distribuzioni RedHat, utilizzando il comando ntsysv è possibile accedere ad un tool grafico (su interfaccia testuale) dedicato.
I processi identificati da un asterisco (*) e dal nome del servizio indicano che il processo verrà attivato al boot, altrimenti i processi identificati solo dal nome del servizio e da una casella vuota indicano i processi che non verranno fatti partire.
Alternativamente si può usare il comando serviceconf su interfaccia grafica o il comando shell chkconfig.
In genere tutti gli strumenti "all purpose" di amministrazione della macchina prevedono una parte di gestione del boot. Su AIX si può usare smitty, su Suse Linux Yast, su Mandrake Linux Drake ecc.
Anche sotto XWindow sono disponibili svariati programmi per eseguire questa funzione.
A prescindere dallo strumento usato, è molto importante disattivare, nella fase di boot, l'avvio di tutti i processi e servizi non utilizzati, sia per evitare sprechi delle risorse del sistema che per ragioni di sicurezza.
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2004-05-23 16:06:35
/etc/inittab e' il file di configurazione di init, il primo processo che viene lanciato al boot, dopo il caricamento del kernel.
Esso contiene gli script che vengono lanciati per l'inizializzazione del sistema, configurazioni come il runlevel di default e alcune impostazioni come i comandi abbinati ad una sequenza di tasti oppure ai messaggi inviati dall'UPS.
Analizzare e comprendere la logica di questo file è molto utile per conoscere un sistema Unix con cui si ha poca familiarità: di fatto, analizzando i comandi e gli script che vengono eseguiti è possibile ricostruire tutto il processo di start-up del sistema.
Ogni entry del file segue la seguente sintassi:
id:runlevels:action:process
ID - Sequenza di 4 caratteri o meno che identifica in modo univoco la entry. Per quanto riguarda le entry relative alle getty, l'id deve corrispondere al suffisso della getty stessa. 1:2345:respawn:/sbin/mingetty tty1
RUNLEVELS - La lista dei run level per cui questa entry e' valida.
ACTIONS - La modalita' con cui viene eseguito il comando vero e proprio. Le action principali:
respawn: Ri-esegue il comando se termina. Tipicamente usato per i getty sulla console.
wait: Esegue lo script o il comando ed aspetta la sua conclusione prima di procedere.
once: Esegue il comando una sola volta quando il sistema entra nel runlevel configurato
boot: Esegue il process durante il boot ed ignora la entry relativa al runlevel
PROCESS - Il comando o script che effettivamente viene lanciato.
Vediamo un esempio tipico di una distribuzione RedHat Linux. Su altri sistemi Unix questo file può cambiare nella forma (ma non nella sintassi).
[neo@dido neo]$ cat /etc/inittab
# inittab This file describes how the INIT process should set up
# the system in a certain run-level.
#[...]
# Default runlevel. The runlevels used by RHS are:
# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)
Run level di default. Se è 5 il sistema parte in modalità grafica. Se è 3 in modalità testuale. Non usare 6 o 0 per evitare che il sistema non parte del tutto!
id:5:initdefault:
Lancio dello script /etc/rc.d/rc.sysinit, che imposta vari settaggi d'ambiente
# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit
Qui si gestisce effettivamente quali servizi e programmi lanciare ai diversi runlevel. La chiave è il programma rc che viene invocato con il numero di runlevel desiderato
l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6
Ad ogni boot viene eseguito il comando update
ud::once:/sbin/update
Comando abbinato alla sequenza di tasti CTRL-ALT-DELETE per riavviare il sistema con i 3 tasti magici. Da disattivare su macchine con la tastiera fisicamente accessibile in luoghi non controllati
# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
Comandi abbinati ai messaggi mandati dall'UPS
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"
Inizializzazione dei terminali. Basta aggiungere qui nuove righe (mingetty tty7, tty8 ...) per aumentare il numero di console usabili da tastiera
# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
Al runlevel 5 esegue il comando prefdm
x:5:respawn:/etc/X11/prefdm -nodaemon
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2003-12-08 23:03:25
Il comando service permette di gestire l'avvio, il riavvio o lo stop di un servizio senza dover digitare il percorso completo dello script relativo.
Nelle distribuzioni Linux Red Hat e derivate, è possibile utilizzare il comando service
per gestire manualmente i servizi di sistema. Per esempio, volendo controllare lo stato del servizio dhcp server è sufficiente utilizzare il comando service dhcpd start
anzichè /etc/r.cd/init.d/dhcpd start
.
Service non è altro che uno script shell che permette di gestire le classiche operazioni che si compiono in merito ad un servizio, tipicamente: avviarlo, fermarlo, riavviarlo e verificarne lo stato.
Alcuni esempi di utilizzo:
[root@Enigma root]# service mysqld start
Starting MySQL:8 [ OK ]
Start di MySql server
[root@Enigma root]# service mysqld restart
Stopping MySQL: [ OK ]
Starting MySQL: [ OK ]
MySql viene riavviato
[root@Enigma root]# service mysqld status
mysqld (pid 3580) is running...
In questo caso viene visualizzato lo stato del server con relativo Process Identifier
[root@Enigma root]# service mysqld stop
Stopping MySQL: [ OK ]
Il server viene fermato
Tramite le opzioni di service vi è la possibilità visualizzare lo stato, oppure eseguire il restart, anche di tutti i servizi contemporaneamente.
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-08 16:19:01
Durante l'installazione di Linux o altri Unix viene solitamente chiesto all'utente se si desidera, dopo il boot, avere un'interfaccia testuale (la shell) o visualizzare il login grafico su una finestra Xwindows.
In genere su un server ha sempre senso avere un'interfaccia solo testuale (init 3) e su una workstation di solito si lavora in modalità grafica (init5).
Per cambiare questa impostazione basta agire su /etc/inittab
La parola chiave initdefault
indica il runlevel di default:
Per avviare il sistema in modalità testuale: id:3:initdefault
Per avviare il sistema in modalità grafica: id:5:initdefault
NON inserire valori come 0 o 6 (halt, reboot)! Il sistema non riuscirebbe mai a partire correttamente.
(F)AQ: Come si fa a scegliere se far partire il proprio Linux in modalità testo o in modalità grafica? -
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2005-06-21 16:15:11
Visualizza il runlevel attuale in cui gira il sistema e quello precedente.
La sintassi:
runlevel [utmp]
Il comando runlevel
, ricava i dati dal file /var/run/utmp
e visualizza sullo standard output il runlevel corrente e quello precedente. Qualora non esista il file utmp, o non venga trovato il record relativo, viene visualizzato il messaggio unknown. Esempio:
root@Joker:~# runlevel
N 3
In questo caso, il runlevel corrente è il 3, mentre N sta a significare che non vi erano precedenti runlevel, ovvero che la macchina è stata avviata direttamente al terzo.
Tipo Infobox: TIPS - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-08 15:53:31
Perchè Unix, nato agli arbori degli anni settanta del secolo scorso è ancora un sistema operativo diffuso, utilizzato e vitale nelle sue varianti, Linux incluso?
Perchè Unix è in grado di radunare una folta schiera di utenti e amministratori fieri e fanatici della propria unixità?
Le spiegazioni sono tante, quasi tutte legate alla natura stessa del sistema operativo e a come è stato inizialmente sviluppato.
Uno dei motivi da non sottovalutare è che di fatto TUTTO su Unix è in ultima analisi riconducibile ad un file di testo ASCII che si può editare con un comune editor di testi.
Basta essere root ed avere un vi e il proprio Unix diventa un libro aperto che si può riscrivere:
- I sorgenti del kernel e del software sono liberamente accessibili e modificabili (questo vale per Unix opensource, come Linux, *BSD, Hurd ecc.)
- Il padre di tutti i processi si configura con inittab, un normale testo con una logica ben precisa.
- Gli script di startup sono generalmente comuni script shell, che richiamano altri script e costruiscono il boot del sistema.
Di fatto si può decidere di far fare al proprio sistema esattamente quello che si vuole.
Certo, per essere in grado di modificare il proprio Unix come si vuole lo si deve conoscere bene, ma una volta capita la logica molte operazioni sono quantomeno "controllabili" e diagnosticabili con relativa semplicità.
GESTIONE DEGLI UTENTI
La logica di gestione degli utenti su Linux, ancora una volta, è simile a quella di tutti gli Unix.
Sono sistemi operativi multi utente, dove per poter fare qualcosa (accedere al sistema) è necessario eseguire un login e fornire la relativa password.
Abbiamo già visto l'importanza dell'utente root, il dio assoluto di un sistema Unix, l'Administrator della situazione, colui che tutto può dalla / (root, intesa come directory madre) in poi.
Vediamo ora come gestire gli utenti del sistema, una attività sistemistica comune e necessaria.
Come sempre, diverse distribuzioni possono presentare diverse interfacce grafiche che permettono una configurazione degli utenti comoda e semplice.
Tutte si appoggiano a principi di fondo, comandi e file comuni, che è la parte che ci interessa evidenziare.
Approfondimenti: Gestione degli utenti
GESTIONE DEL SOFTWARE
Software diversi vengono gestiti (installati, interrogati, rimossi, aggiornati) su Linux basandosi su una logica a pacchetti, che possono contenere un programma, delle librerie, i sorgenti o, a volte, la documentazione completa di un applicativo.
Su Linux esistono diversi formati per la gestione dei pacchetti, i principali sono RPM (usati su redHat, Suse, Mandriva e derivate), DEB (usati su Debian e derivate come Knoppix, Mepis, Ubuntu) e TGZ (usati su Slackware e derivate).
Un file .rpm (o .deb o .tgz) è come se fosse il setup.exe di un programma Windows: contiene tutti i file, i dati e i programmi che vanno installati sul sistema.
Per gestire file .rpm si utilizza il comando rpm (da interfaccia testuale) o vari strumenti in ambiente grafico (tra cui il gestore dei pacchetti disponibile sotto Gnome e che viene usato anche in fase di installazione), che di fatto sono un semplice front-end del comando rpm.
Per gestire file .deb si utilizza dpkg.
Maggiori informazioni in - Installare programmi su Linux e Unix
Tutte le distribuzioni recenti utilizzano sistemi di aggiornamento online che possono essere usati anche per l'installazione di nuovi pacchetti.
Spesso forniscono un front-end grafico per rendere queste attività semplici e gestire automaticamente le dipendenze, quasi sempre il front-end grafico lavora su un sistema di gestione degli aggiornamenti e dell'integrità del database dei pacchetti disponibili.
Su Fedora su usa "yum", su Debian "apt", su Mandriva "urpmi", su RedHat si usa il comando up2date per collegarsi al servizio online RedHat Network.
Ulteriori informazioni in: Aggiornamento di un sistema Linux
BACKUP
Altra attività sistemistica tipica è il backup.
Non ci occuperemo estesamente di procedure di backup ma dobbiamo accennare ai comandi puù comuni in ambiente Unix per gestire e compattare file:
tar, gzip e anche bzip2 e zip.
Info: Backup e compressione di file
CRON E OPERAZIONI PIANIFICATE
Su ogni sistema Unix esiste la possibilità di eseguire automaticamente comandi ad intervalli di tempo specificati (è l'equivalente delle Operazioni Pianificate di Windows).
Questo meccanismo si chiama crontab.
Su molti Linux, destinati ad essere usati come desktop, al crontab viene affiancato anacrontab, che permette la schedulazione di processi previsti da crontab in un ora in cui il computer è spento.
Su un server, sempre acceso, anacrontab non è necessario.
Info su: Schedulazione dei processi
LOG DI SISTEMA
In ogni sistema Unix i log di molti programmi vengono gestiti da un processo specifico: syslog.
Ogni programma in esecuzione sul sistema può utilizzare syslog per tutte le attività di logging (alcuni programmi, come Apache o Samba, possono loggare con sistemi autonomi).
Per sapere dove vengono salvati i log, basta guardare e capire il file /etc/syslog.conf, presente praticamente in ogni sistema Unix.
Informazioni in Gestione e analisi dei log
Gestione degli utenti |
I file che gestiscono gli utenti: /etc/passwd, /etc/group, /etc/shadow. I comandi per gestire gli utenti: adduser, passwd, userdel. |
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: 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: 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: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: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-11-28 22:47:29
Crea un utente o modifica le proprietà di default per la creazione degli utenti.
Creazione di un nuovo Utente
adduser [opzioni] login-name
Modifica delle impostazioni d di un nuovo Utente
adduser -D [opzioni]
Opzioni per la creazione di un nuovo utente
-c [comment]
Commento all'interno di /etc/passwd
-d [home_dir]
Specifica la home dir del nuovo utente
-e expire-date
Indica la data di scadenza dell'account, formato della data YYYY-MM-DD
-f inactive_days
Indica il numero di giorni, che intercorrano fra la data di expire della password e la disabilitazione dell'account
-g group
Indica il primo gruppo di appartenenza. Per poter utilizzare questa opzione il gruppo deve gia' esistere
-G group
Indica gli altri gruppi di cui il nuovo utente fara' parte
-m
La home dir dell'utente verra' creata se non esiste
-p
Identifica la password cryptata
-s
Specifica la shell dell'utente
-u
Specifica l'UID dell'utente
Opzioni per la modifica delle opzioni di default
-b default_home
Setta il prefix per la creazione delle home di default
-e default_expire_date
Setta la data di expire dell' account
-f default_inactive
Indica il numero di giorni, che intercorrono fra la data di expire della password e la disabilitazione dell'account.
-g default_group
Identifica il gruppo iniziale di default
-s default_shell
Identifica la shell di default
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2004-05-23 16:07:36
Comando che permette di settare, modificare la password di un utente.
Root può modificare le password di ogni utente, mentri gli utenti normali possono modificare solo la propria.
passwd [-d] [-S] [username]
-d
Disabilita la password per l'utente
-S
Verifica lo status della password dell'utente.
Esempi
passwd
Cambia la password dell'utente corrente. La password va digitata due volte e, in certi sistemi, deve avere un numero minimo di caratteri.
passwd al
Cambia la password dell'utente al. Solo root può cambiare le password degli altri utenti.
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-11-28 22:48:18
Cancella un account e i relativi file
userdel [-r] login-name
-r
Oltre a cancellare l'account vengono cancellate anche la home directory (di default viene lasciata inalterata) e la posta.
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-11-28 22:54:53
Comando che permette di cambiare le impostazioni di un account creato precedentemente.
usermod [opzioni] login-name
-c comment
Modifica, aggiunge il commento
-d home_dir
Modifica la home_dir dell'utente
-e expire_date
Modifica l'expire_date, ovvero quando l'account verrà disabilitato
-f inactive_days
Modifica il numero di giorni che intercorrono fra la scadenza della password e la disabilitazione dell'account
-g initial_group
Modifica il gruppo primario
-G groups
Modifica i Gruppi secondari
-l login
Cambia il nome di login dell'utente
-p password
Modifica la password (criptata)
-s shells
Modifica la shell di default dell'utente
-u UID
Modifica l'UID
-L
Esegue il lock dell'account
-U
Operazione inversa del lock, ovvero riabilita l'account
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-11-28 22:50:31
Crea un nuovo gruppo
groupadd [-g gid [-o]] [-r] [-f] group
-g
Valore numerico del group ID
-r
Identifica la creazione di un gruppo di sistema ovvero con GID inferiore a 499
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-10-17 14:46:54
Comando che ti permette di modificare le caratteristiche di un gruppo, creato precedentemente.
groupmod [-g gid [-o]] [-n group_name ] group
-g
Identifica l'UID del gruppo
-o
Flag che assicura l'uso di un UID non univoco
-n group_name
Indica il nuovo nome del gruppo
Tipo Infobox: PATH - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-11-28 23:10:44
Directory contenente i file predefiniti che vengono copiati nella home di ogni nuovo utente quando viene creato con le impostazioni di default.
Ecco l'elenco dei file contenuti in /etc/skel di una redhat 7.2 con impostazioni di default.
Per la maggior parte si trattano di file riguardanti le impostazioni delle shells o configurazioni per-user di programmi installati.
neo@dido neo]$ ls -latr /etc/skel/
total 28
File contenenti le impostazioni della bash
-rw-r--r-- 1 root root 124 Jul 9 2001 .bashrc
-rw-r--r-- 1 root root 191 Jul 9 2001 .bash_profile
-rw-r--r-- 1 root root 24 Jul 9 2001 .bash_logout
File contenenti le impostazioni di emcas
-rw-r--r-- 1 root root 820 Jul 30 2001 .emacs
File contenenti le impostazioni dell'utility screen
-rw-r--r-- 1 root root 3511 Aug 3 2001 .screenrc
drwxr-xr-x 2 root root 4096 Jul 16 10:30 .
drwxr-xr-x 52 root root 4096 Oct 17 12:36 ..
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-11-28 22:35:24
Su Unix sono comuni diversi comandi e programmi per gestire gli utenti del sistema (es: useradd, usermod userdel).
Quelle che questi strumenti fanno automaticamente sono operazioni sul sistema che si possono fare manualmente.
Ovviamente si consiglia di usare tool dedicati come useradd
e groupadd
per queste attività.
Per aggiungere un utente al sistema si deve:
- Essere utente root, o avere analoghi privilegi.
- Editare /etc/passwd
aggiungendo una riga per il nuovo utente, facendo estrema cura al formato del file;
- [Non indispensabile] Editare /etc/group
aggiungendo un nuovo gruppo per il nuovo utente e/o aggiungendo il nuovo utente ad un gruppo di usenti generici;
- Se esiste il file /etc/shadow
editarlo aggiungendo una nuova riga per l'utente;
- Creare la home directory del nuovo utente: mkdir /home/nomeutente
;
- Ricreare l'ambiente base (script di inizializzazione shell o altri programmi) nella nuova home: cp /etc/skel/* /home/nomeutente/
;
- Modificare il proprietario della home: chown -R nomeutente:nomegruppo /home/nomeutente
;
- Modificare i permessi della home: chmod -700 /home/nomeutente
;
- Modificare la password dell'utente: passwd nomeutente
Questa è una procedura generalmente valida su ogni Linux e Unix, è utile conoscerla, ma resta più comodo e raccomandabile usare i comandi di gestione utente (testuali o grafici) del proprio Unix.
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: BOFH - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-06-13 12:53:47
Prima creazione di un utente con cambio password forzato.
Tra i compiti dell'amministratore di sistema vi è quello di gestire gli account utente. Solitamente, per ogni nuovo user, si crea un nuovo account con nome e password uguali, ricordando poi all'utente di modificare la propria password per non creare punti deboli nella sicurezza del sistema.
[root@Apollo13 root]# useradd morpheus ; echo "morpheus" | passwd --stdin morpheus; chage -d0 morpheus;
Changing password for user morpheus.
passwd: all authentication tokens updated successfully.
Questa command line permette di creare l'utente useradd [user]
, quindi ne setta la password uguale al nome echo "[user]" | passwd --stdin [user]
e successivamente forza il cambiamento della password al primo accesso con chage -d0 [user]
.
homer@Joker:/opt# ssh [email protected]
[email protected]'s password: *******
You are required to change your password immediately (root enforced)
Changing password for morpheus
(current) UNIX password: ********
New password: ********
Retype new password: *********
[morpheus@Apollo13 homer]$
Il sistema richiede il cambio password forzato al primo login
L'utilizzo di questo command line, è consigliato solo nel caso in cui l'accesso del nuovo utente al sistema avvenga immediatamente, pena un'alta vulenerabilita' delllo stesso data dall'uguaglianza di nome e password.
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-11-28 23:01:32
Utility che permette di amministrare la scadenza delle password dei vari utenti del sistema
Modalità di editing
chage [-m mindays] [-M maxdays] [-d lastday] [-I inactive] [-E expiredate] [-W warndays] user
Modalità di visualizzazione delle informazioni
chage -l [user]
-m
Indica i giorni minimi per poter cambiare password
-M
Indica il numero massimo di giorni di validità della password.
-d
Indica il numero del giorno in cui è stata cambiata la password
-I
Indica il numero di giorni di intermezzo fra la scadenza della password e la disabilitazione dell'account
-E
Indica la data di scadenza della password
-W
Indica il numero di giorni per i quali il sistema avvisa che la password sta scadendo
Installare programmi su Unix e Linux |
Utilizzo di RPM per installare, aggiornare, rimuovere pacchetti .rpm. Utilizzo di tar.gz |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-09-27 22:16:46
Per installare dei programmi su Linux esistono vari modi:
- compilare il sorgente, pratica che può essere complessa ma è utile in casi particolari;
- utilizzare pacchetti (packages) che contengono i programmi già compilati e pronti per l'uso, facilitando e standardizzando la gestione del software sul sistema.
I sistemi di package più comuni su Linux sono RPM e DEB.
I pacchetti .deb vengono usati nelle distribuzioni derivate da Debian, gli .rpm sono stati definiti da RedHat e risultano essere i più diffusi.
Slackware pacchettizza il suoi programmi con normali tar gzippati: .tgz.
Affrontiamo qui l'uso di RPM, Red Hat Package Manager, sottolineando che file .deb e, in parte, .tgz vengono gestiti con comandi diversi ma hanno una logica simile.
Un package costruito con RPM è un archivio di file e informazioni che può essere installato, rimosso, interrogato sul sistema.
RPM permette di installare programmi, già compilati, con una facilità e rapidità estrema sul proprio Linux (è paragonabile ad un unico setup.exe su Windows).
Si sottolinea che ogni distribuzione e anche ogni versione della stessa distribuzione richiede pacchetti dedicati, adatti per il proprio sistema: un RPM realizzato per RedHat 6.2, per esempio, difficilmente funzionerà su RedHat 7.2.
RPM gestisce automaticamente le "dependencies": se si prova ad installare un RPM che richiede librerie o programmi non presenti o non abbastanza aggiornati sul sistema, l'installazione fallisce e viene indicato quali file mancano.
Analogamente, se si prova a rimuovere un package che contiene file utilizzati da altri programmi, viene dato un messaggio di errore.
Gli RPM automaticamente distribuiscono i file di un pacchetto nelle directory giuste (logs in /var/log, file di configurazione in /etc/, binari in /usr/bin o /usr/sbin, script di startup in /etc/rc.d/init.d/ ecc.) e verificano la presenza di conflitti o installazioni più recenti.
La rimozione di un RPM non cancella mai nulla che non abbia installato. Se deve sostituire o cancellare un file di configurazione, per esempio, viene mantenuto il file esistente con il suffisso .rpmsave
.
Le opzioni più comuni per usare il comando rpm
per gestire file .rpm sono:
rpm -i [opzioni] pacchetto
Installa il pacchetto .rpm specificato.
rpm -U [opzioni] pacchetto
Aggiorna il pacchetto con una versione più recente.
rpm -e [opzioni] pacchetto
Disinstalla il pacchetto, rimuovendone i file dal sistema.
rpm -q [opzioni] [pacchetto]
Visualizza informazioni varie sul pacchetto (descrizione, file contenuti ecc.)
Le comuni distribuzioni Linux offrono svariati tool grafici per una semplice gestione dei pacchetti installati sul sistema. Di fatto questi programmi eseguono le stesse operazioni del comando rpm, ma sono più semplici ed immediate da usare.
La tendenza, sempre più diffusa, è quella di prevedere meccanismi di update automatizzato, per gestire il sempre alto numero di aggiornamenti (per sicurezza e bug fix) di programmi.
E' un principio analogo al Windows Update su sistemi Microsoft, ma si applica a tutti i programmi installati, e non solo al sistema operativo.
LINK: RPM Updaters - SIstemi di aggiornamento automatico - http://www.rpm.org/software/updaters/
LINK: RPM GUI. Programmi e strumenti grafici - http://www.rpm.org/software/gui/
LINK: RPMFIND - Database in cui cercare RPM per varie distribuzioni - http://rpmfind.net/
LINK: Freshrpm - Utile repository di RPM aggiornati - http://freshrpms.net/
LINK: Repository di interessanti pacchetti RPM per RedHat-Fedora - http://dag.wieers.com/packages/
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-30 15:33:39
Trovare l'rpm giusto per la propria distribuzione Linux può non essere semplice, come non lo è sempre capire quale rpm contiene il programma o il file che ci servono.
Esiste una convenzione standard per dare un nome ad un package RPM:
efax-0.8a-11.i386.rpm
corrisponde a nome-versione-release.arch.rpm
- nome è generalmente il nome del programma fornito col pacchetto,
- versione indica la versione del programma, secondo la convenzione usata da chi lo ha realizzato,
- release è la release del pacchetto, può anche indicare la distribuzione (es: mdk indica un RPM per Mandrake),
- arch è l'architettura hardware per la quale il pacchetto è stato previsto (i386: sistemi Intel 386 o superiori; i686: ottimizzato per sistemi Pentium 2 o superiori; sparc: Sun Sparc; src: sorgenti da compilare; ),
- rpm è l'estensione predefinita.
Se il nome di un pacchetto contiene il suffisso -devel, nel rpm ci sono librerie utilizzate dal programma indicato o da altri pacchetti che dipendono da questo.
A volte per installare un programma compiutamente sono necessari più pacchetti .rpm, spesso se un programma ha natura modulare, c'è un pacchetto diverso per ogni modulo.
LINK: Maximum RPM - Online book - http://www.rpm.org/max-rpm/
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2009-02-05 13:30:12
Distribuzioni basate su RPM (RedHat, Mandriva, Suse...) e su DEB (Debian, Ubuntu...) utilizzano comandi diversi per fare gestire i pacchetti.
Vediamo in breve come si fanno le stesse operazioni nei due mondi.
- Software e comandi
dpkg e rpm sono i comandi base per gestire (installare, rimuovere, interrogare) pacchetti di tipo .deb e .rpm (rispettivamente).
apt-get, yum (ma anche urpmi su Mandrake, o up2date su RedHat o Yast2 su Suse ecc.) sono sistemi per gestire automaticamente lo scaricamento di pacchetti da Internet, il loro aggiornamento, la gestione delle dipendenze.
Quindi:
dpkg sta a pacchetti .deb come rpm sta a pacchetti .rpm
apt-get sta a dpkg come yum sta a rpm:
- Elenco completo dei programmi installati sul sistema
rpm -qa (su sistema basati su RPM)
dpkg -l (su sistemi basati su DEB)
- Installare un pacchetto
yum install tcpdump ( o rpm -i tcpdump-ver.dist,arch.rpm )
apt-get install tcpdump ( o anche dpkg -i tcpdump-ver.arch.deb )
- Rimuovere un pacchetto
rpm -e tcpdump ( o anche yum remove tcpdump )
dpkg -r tcpdump ( o anche apt-get remove tcpdump )
- Visualizzare l'elenco dei file forniti da un pacchetto
rpm -ql tcpdump (o, se non ancora installato: rpm -qlp tcpdump.arch.rpm)
dpkg -L tcpdump (o, se non ancora installato: dpkg --contents tcpdump-version.arch.deb)
- Visualizzare informazioni su un pacchetto
dpkg -s tcpdump
rpm -qi tcpdump
- Trovare da quale pacchetto è stato installato un dato file
rpm -qf /path/nomefile (es: rpm -qf /etc/issue)
dpkg -S /path/nomefile (es: dpkg -S /etc/issue)
- Aggiornamento del sistema
yum update su sistemi Fedora/RedHat
apt-get upgrade su sistemi Debian e derivati
- Ricerca all'interno del database dei pacchetti
yum search squirrelmail
apt-cache search squirrelmail
Tipo Infobox: BOFH - Skill Level: 2- JUNIOR - Autore: Marco 'w00binda' Patti - Ultimo Aggiornamento: 2003-01-30 16:55:45
Visualizza l'elenco completo degli rpm installati.
Utile sopratutto se usato assieme al grep.
Nel caso volessi sapere se il pacchetto abiword è installato sul mio sistema, dovrei digitare al prompt:
[root@hell] rpm -qa | grep abiw
Tipo Infobox: DISTRO - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2003-04-08 15:51:16
Anche la distribuzione Linux Slackware utilizza software di Package Management, che sebbene più spartano rispetto a RPM di Red Hat o a Deb di Debian, permette di mantenere in ordine i pacchetti installati nel sistema
I packages di Slackware sono dei semplici tar compressi con gzip. Questa distribuzione mette a disposizione alcune utility per gestirne l'installazione, la rimozione, l'aggiornamento e di mantenere traccia delle operazioni tramite un database.
I principali tools forniti da Slackware per il management delle applicazioni sono quattro: pkgtool, installpkg, removepkg upgradepkg.
pkgtool
Pkgtool è un'utility di tipo menu-driven che permette di visualizzare, installare e rimuovere i packages. Attraverso questo tool è possibile visualizzare il contenuto di ogni package, disinstallarlo o scegliere da dove installarne uno nuovo. Tramite pkgtool non è però possibile effettuare l'aggiornamento, prerogativa disponibile solo per le utility di tipo command line che dispongono anche di un maggior numero di opzioni.
Passiamo agli strumenti a linea di comando.
installpkg
Installpkg gestisce l'installazione di nuovi packages nel sistema.
Sintassi:
root@Joker:/# [ROOT=<path>] installpkg [options] <nome package>...
Opzioni:
-m
: Esegue un makepkg
(Utility per creare i packages) nella directory corrente;
-warn
: Visualizza i cambiamenti nel sistema in caso di installazione del package. Usato sulle macchine di produzione per sapere cosa accadrà installando un software;
-r
: Installa ricorsivamente i packages contenuti nella directory corrente e nelle subdirectory. E' possibile utilizzare delle wildcards.
Settando la variabile ROOT è possibile utilizzare una directory a propria scelta, diversa da /
, per memorizzare i dati relativi all'installazione.
Al termine dell'installazione, se presente, nella subdirectory install/
del package verrà eseguito uno script di nome doinst.sh
che permette di rifinire l'installazione creando per esempio link simbolici.
Le informazioni del database dei packages installati, ovvero un file in plain text per ogni programma, si trovano in /var/log/packages
mentre gli eventuali script di post installazione si trovano in /var/log/scripts/<nomepackage>
.
removepkg
Removepkg si occupa di disinstallare i packages dal sistema.
Sintassi:
root@Joker:/# [ROOT=<path>] removepkg [options] <nome package>...
Opzioni:
-copy
: Il package non viene rimosso ma viene copiato in in una directory in /var/log/setup/tmp/preserved_packages
uguale all'originale;
-keep
: Tiene traccia dei file temporanei creati durante la disinstallazione. E' comodo per scopi di debugging;
-preserve
: Il package viene rimosso, ma copiato per sicurezza in un'altra directory, ovvero /var/log/setup/tmp/preserved_packages
;
-warn
: Visualizza quali problemi potrebbero esserci rimuovendo il package;
Settando la variabile ROOT è possibile utilizzare una directory a propria discrezione, diversa da /
, per memorizzare le informazioni relative alla disinstallazione.
Se presente, removepkg esegue lo script di postinstallazioine in modo da rimuovere, oltre ai file del package, anche eventuali link simbolici presenti.
Durante il processo di disinstallazione, vengono visualizzate le informazioni sullo stato dell'operazione. Una volta terminato li processo, le informazioni del packages e lo script di post installazione sono rispettivamente spostati in /var/log/removed_packages
e /var/log/removed_scripts
.
upgradepkg
Upgradepkg gestisce l'aggiornamento di un package Slackware già installato.
root@Joker:/# [ROOT=<path>] upgradepkg <package name>...
oppure:
root@Joker:/# [ROOT=<path>] upgradepkg [options] <vecchio nome package> <nuovo nome package>
Upgradepkg esegue nell'ordine, l'installazione del nuovo package e la disinstallazione del vecchio. Se il nome del package è cambiato da una versione all'altra è possibile usare la seconda versione del comando.
Al fine di evitare i problemi dovuti a qualche bug di upgradepkg come per esempio la sovrascrittura accidentale dei file di configurazione, è sempre consigliato fare un backup dei propri file di configurazione.
In tutte e tre le utility è possibile specificare più di un package utilizzando nel nome le wildcards.
SOURCE: Slackware Linux Essentials - The Official Guide To Slackware Linux - http://www.slackware.com/book/
Tipo Infobox: PATH - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-02-07 12:45:29
Con questa semplice riga è possibile visualizzare l'elenco dei pacchetti RPM installati sul sistema ordinandoli secondo le dimensioni.
Molto comodo per vedere quali pacchetti occupano più spazio.
Fonte: FedoraNews. Autore: Leonid Mamtchenkov
SOURCE: Fedora Tips da Fedoranews.org - http://fedoranews.org/krishnan/tips/tip002.shtml
Tipo Infobox: BOFH - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'ma01417' Brezzi - Ultimo Aggiornamento: 2004-05-23 16:08:23
Utilizzo della "command substitution" per conoscere di un eseguibile il pachetto che lo conteneva e la relativa versione.
rpm -qf `which tr`
voglio sapere il comando tr a quale pacchetto appartiene
coreutils-4.5.3-19.0.2
la risposta è coreutil alla versione 4.5.3
Tipo Infobox: DISTRO - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-01-21 14:01:46
Tramite l'utility rpm2tgz è possibile trasformare un pacchetto RPM nel formato gestito dal Package Management di Slackware
Uno dei formati più popolari tra i sistemi di packaging è RPM di Red Hat, ed è quindi probabile trovare spesso software in questo formato. A volte è possibile che il pacchetto ricercato sia disponibile solamente in questo formato. In questo caso è possibile trovare una soluzione (anche se non in tutti i casi), per l'installazione in una distribuzione Slackware, grazie all'utility rpm2tgz.
Il programma rpm2tgz crea un pacchetto con estensione .tgz partendo da un pacchetto RPM, la sua sintassi è: rpm2tgz <file.rpm>
Un esempio di utilizzo:
root@Joker:/test# ls
nmap-3.00-1.i386.rpm
Il file di partenza è un pacchetto di tipo RPM
root@Joker:/test# rpm2tgz nmap-3.00-1.i386.rpm
root@Joker:/test# ls
nmap-3.00-1.i386.rpm nmap-3.00-1.i386.tgz
Una volta lanciata l'esecuzione del programma si ottiene un pacchetto di tipo tgz gestibile dalle utility di Slackware come pkgtool, installpkg, removepkg o upgpackage
SOURCE: Slackware Linux Essentials - The Official Guide To Slackware Linux - http://www.slackware.com/book/
Backup e compressione di file |
Tecniche di backup. L'uso di tar, gunzip, e altri comandi di compressione. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2002-10-28 11:19:08
Per backup si intende un procedimento di salvataggio di files o directory (o addirittura interi filesystem) attraverso il quale e' possibile in caso di danni o altre svariate necessita' ripristinare le condizioni di funzionamento del sistema, da qui si capisce la sua fondamentale importanza.
In caso di mancato backup, la perdita di dati importanti puo essere una vera tragedia e un buon backup può fare la differenza fra un disastro e una scocciatura.
Ci sono svariate procedure e filosofie sul backup ma uno degli aspetti importanti e' che i dati salvatirisiedano in un luogo fisico differente rispetto a quello dei file originali (anche in un diverso supporto nella stessa macchina).
Per il backup di dati si possono utilizzare da floppy-disks (ne bastano 3 per backuppare /etc), fino ad interi raid di harddisks (arrivando cosi a dimensioni di svariati Terabyte). I supporti piu' comuni utilizzati sono floppydisks, Zipdisks, CDR, DVD, tapes e harddisks. La scelta del supporto dipende sia dalla quantita' di dati da backuppare
(a volte si preferisce salvare solo dati essenziali, a volte si opta per il backup di interi filesystem) sia dalla frequenza del backup (che comunque dipende dalla quantita', in quanto e' difficile che giornalmente si effettuino backup di 500Gb).
Generalmente le procedure di backup avvengono quando non ci sono users operanti sul sistema e quando il carico della rete e' basso, cosa che avviene spesso e volentieri la notte.
Fra le svariate utility per il backup nel mondo Unix troviamo Dump e Restore (con nomi diversi fra i vari
OS Unix-based, anche se di poco), comandi molto sofisticati con una semplice interfaccia ed opzioni essenziali che permettono di backuppare e restorare semplicemente (con la possibilita' di scieglierne il livello) interi devices e filesystems, anche da remoto.
Altro comando di rilievo e' cpio, non potente come dump ma con piu' features.
Tools importanti per il backup di filesystems sono AMANDA (performato dall'universita' del Maryland permette di settare un singolo master backup server in grado di backuppare piu hosts), BURT (altra utility, ottimizzata per il backup e restore da nastri) e CD backup Linux (performato per backup e restore automatici creando un CD-Rs bootabile mentre si lavora sul sistema).
Per il backup e' inoltre possibile utilizzare anche comandi di archiviazione (o compressione) come tar, gzip ecc...
Oltre alle opzioni elencate qui sopra vi sono anche un'infinita' di utility commerciali per backup e restore dei dati. Le case produttrici piu' importanti a livello commerciale di software per il backup sono VERITAS Software, FalconStor Software, BakBone Software, Arkeia.
HOWTO: Linux Complete Backup and Recovery HOWTO - http://ldp.openskills.info/HOWTO/Linux-Complete-Backup-and-Recovery-HOWTO/index.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2002-10-28 11:22:01
Rsync e' un comando (ed un protocollo) che permette la copia di file via rete, ottimizzando i tempi di backup e ripristino dei dati.
L'host da backuppare (su cui si devono leggere o scrivere file) deve avere in esecuzione rsync in modalita' server (rsync --daemon
), e deve essere presente il file /etc/rsyncd.conf
dove sono contenute le informazioni relative alla condivisione necessaria per il backup.
Sull'host remoto che deve leggere o scrivere file sulla macchina dove rsync gira come daemon, viene eseguito il comando rsync con una logica simile a quella di cp.
I parametri da settare in /etc/rsyncd.conf
sono:
- [nomecondivisione] e' il nome della condivisione rsync;
- path e' il path locale a cui fa riferimento la condivisione;
- read only e' un opzione che protegge i file dalla scrittura (se settata = yes);
- uid e gid sono l'utente ed il gruppo con cui rsync accede al filesystem;
- host allow rappresenta gli IP da cui e' possibile collegarsi via rsync;
- list e' un opzione che prevede di poter impedire di elencare le condivisioni disponibili sul server rsync (se settata = false);
La prima volta che si esegue un backup da un certo host vengono copiati tutti i files specificati nella condivisione, le altre volte solo quelli modificati dall'ultimo backup.
Per un utilizzo sicuro di rsync (le password non vengono richieste!), e' consigliabile:
- Selezionare accuratamente gli IP degli host che possono accedere al server rsync;
- Consentire esclusivamente ingressi in sola lettura;
- Non utilizzare root come uid e gid ( a meno che non sia necessario per esigenze di backup).
La sintassi del client rsync è:
rsync [opzioni] [host da backuppare]::nomecondivisione/files /[directory host locale]
opzione spesso utile e' -av
, che specifica di copiare i file mantenendo ownership, permessi e in modalita' "directory recursive".
LINK: Sito ufficiale di rsync - http://samba.anu.edu.au/rsync/
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-05-15 13:48:43
Il file di configurazione di rsync è simile ad un file .ini di un sistema Windows.
Le direttive di configurazione globali sono definite nella prima parte del file, mentre la seconda parte riguarda sezioni o moduli identificati da un nome racchiuso tra parentesi quadre. Il file può contentere linee vuote e commenti i quali devono iniziare con il carattere ; o con #.
Un esempio di rsyncd.conf
utilizzato per il backup, dove vengono configurati due moduli:
log file =
/var/log/rsyncd.log
definisce un file di log
motd file =
/etc/rsyncmotd
definisce un file per il MOTD (Message Of The Day)
[Apollo13]
tra parentesi quadre viene indicato il nome del modulo
path = /disco2/backup/Apollo13
percorso attraverso il quale vengono localizzati i file
comment = Backup Area Apollo13
commento visibile interrogando il server rsync
list = yes
permette di visualizzare il modulo tra la lista di quelli disponibili
read only = no
rende il modulo disponibile in scrittura, di default questo non è possibile
[Enigma]
path = /disco2/backup/Enigma
comment = Backup Area Enigma
list = yes
read only = no
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-03-06 02:09:20
Permette di visualizzare i moduli disponibili su un host in cui è in esecuzione rsync in modalità server.
Prima di trasferire da o verso un host dei dati, è necessario sapere quali sono i moduli messi a disposizione dal server rsync per l'operazione. Questo è possibile attraverso il comando:
[azitti@topolino azitti]$ rsync pluto.it::
ftp the whole ftp area
www the whole web site
ildp the ILDP web site
HOWTO-it Italian HOWTOs
In questo caso possiamo notare che il Pluto Linux Documentation Project pluto mette a disposizione quattro moduli da cui scaricare files: ftp, www, ildp e HOWTO-it
Se sul server si vuole evitare la possibilità da parte dei client di visualizzare la lista dei moduli disponibili (per sicurezza o riservatezza) va inserita, in /etc/rsyncd.conf
la voce:
list = false
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Andrea 'franz' Francesconi - Ultimo Aggiornamento: 2004-04-30 11:10:00
Rsync è un ottimo tool per la replica dei dati, con ssh (ovvero con supporto cifrato) lo è ancora di più =)
rsync -avzlrt --exclude 'nothisdir' -e "ssh -p 4321" [email protected]:/'`find /my/secret -name '*$VAR*'`' /localbackup
Opzioni utilizzate:
a: archive mode;
v: abilito la modalità verbose per l'operazione in corso;
z: abilito la compressione;
l: mantiene i link;
r: modalità ricorsiva;
t: preserva data e ora dei file;
e: rsync si appoggia su un ssh server in ascolto sulla porta (-p) 4321
Nel pc remoto eseguo un find nel percorso /my/secret per tutti i file contenenti nel nome la variabile $VAR, dopodichè copio localmente su /localbackup.
L'operazione può essere schedulata per comodi (e sicuri) backup notturi con l'integrazione di chiavi dsa con passphrase blank, definendo un livello di security a mio parere accettabile per la maggior parte delle realtà di impiego.
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2002-10-03 17:09:17
Comando che riduce la dimensione dei file usando un algoritmo che offre generalmente una migliore compressione rispetto ai convenzionali compressori basati su codifiche LZ77/LZ78 (gzip e zip).
La command-line e' volutamente simile (ma non identica) a quella di gzip.
Come gzip il file compresso mantiene il nome, data, permessi del file origine (che verra' eliminato), ed avrà l'estersione '.bz2'.
-c --stdout --to-stdout
Scrive l'uscita nello standard output; mantiene il file originale intatto.
-d --decompress
Decomprime
-z --compress
Comprime
-t --test
Verifica l'integrita' del file compresso senza decomprimerlo.
-f --force
Forza la compressione (o la decompressione), anche se il file corrisponde ad un file gia esistente (di default non lo fa)
-k --keep
Non elimina i file originali durante la compressione o la decompressione.
-v --verbose
Mostra il nome e la percentuale di riduzione di ogni file compresso o decompresso.
-1 (o --fast), -2, ... , -9 (o --best)
Setta la dimensione dei blocchi di memoria da utilizzare (100k,...,900k) durante la compressione.
A differenza di gzip utilizzando l'opzione -1 ( o --fast) l'aumento di velocita' di compressione non e' molto precepibile. di default e' settata l'opzione -9 (--best).
Questa opzione non ha effetto in fase di decompressione.
LINK: bzip2 official homepage - http://sources.redhat.com/bzip2
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2002-10-03 17:02:48
Programma di archiviazione progettato per immagazzinare ed estrarre file da un archivio conosciuto come un tarfile.
Un tarfile può essere fatto su un'unità a nastro magnetico o su un file normale.
tar [opzioni] file1, file2, ... , fileN
-A, --catenate, --concatenate
aggiunge i file ad un archivio
-c, --create
crea un nuovo archivio
--delete
elimina dall'archivio (da non usare sui nastri magnetici!)
-r, --append
aggiunge i file alla fine di un archivio
-t, --list
elenca il contenuto di un archivio
-u, --update
aggiunge solamente i file che sono pi recenti della copia nell'archivio
-x, --extract, --get
estrae i file da un archivio
-f, --file [NOME_HOST:]F
usa il file di archivo o dispostivo F (default /dev/rmt0)
-L, --tape-length N
cambia il nastro dopo aver scritto N*1024 byte
-p, --same-permissions, --preserve-permissions
estrae tutte le informazioni relative ai permessi
-v, --verbose
elenco minuzioso dei file elaborati
-z, --gzip, --ungzip
filtra l'archivio attraverso gzip
LINK: Sito ufficaile di tar - http://www.gnu.org/software/tar/tar.html
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2002-10-03 17:04:13
zip e' un utility di archivio e compressione di file per Unix, VMS, MSDOS, OS/2, Windows NT, Minix, Atari and Macintosh, Amiga and Acorn RISC OS.
E' analogo alla combinazione dei comandi Unix 'tar' e 'compress' ma utilizza algoritmi diversi.
Per la decompressione a differenza di altri comandi di archivio e compressione (tar, gzip e bzip2), e' possibile utilizzare esclusivamente il comando unzip, in quanto zip non prevede alcuna opzione che permetta di decomprimere un file.
-A
Crea un archivio eseguibile auto-decompattante.
-b path
Utilizza il path specificato per allocare i file zip temporanei. una volta terminato il processo copia il file.zip nella directory corrente eliminando i file zip temporanei.
-c
Aggiunge una riga di commento per ogni file.
-d
Rimuove i file origine una volta archiviati.
-f
Sovrascrive un file contenuto nell'arichivio se viene inserito lo stesso file con data di modifica piu recente.
-i files
Include solo i files specificati.
-j
Mantiene solo il nome dei files archiviati senza salvare il nome delle directory. Di default zip salva il path completo.
-m
Sposta i files nell'archivio specificato eliminando gli originali.
-e
Assegna una password all'archivio creato.
-o
Setta come data di modifica dell'archivio la data di modifica piu recente dei files archiviati.
-r
Ricorsivo, se si comprime una directory, con questa opzione si archivieranno anche tutte le sue sottodirectory.
-t mmddyyyy (o yyyy-mm-dd)
non operera su file modificati prima della data specificata.
-tt mmddyyyy (o yyyy-mm-dd)
non operera su file modificati dopo la data specificata.
-T
testa l'integrita' del nuovo zip file. se il test fallisce un eventuale vecchio zip file non viene eliminato e vengono mantenuti i file di origine.
-v
Verbose, fornisce maggiori dettagli.
-#
Regola il rapporto tra qualita' e velocita' (-1=veloce, -9=migliore).
Tipo Infobox: BOFH - Skill Level: 3- INTERMEDIATE - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2002-10-03 17:12:13
Con l'opzione -c, gzip scrive l'uscita nello standard output, lasciando il file originale intatto.
Percio' e' possibile concatenare piu file compressi con il comando gzip -c fileN >> gzfile.gz.
.
Quindi il comando gzip -cd gzfile.gz
equivale a cat file1 file2,..., fileN
.
Compressioni migliori si ottengono pero' con la riga cat file1,...,fileN | gzip > gzfile.gz
, che comprime cosi' tutti i membri assieme, anziche' con il comando il comando gzip -c file1,...,fileN > gzfile.gz
.
Se un file compresso e' formato da piu' membri, l'opzione --list fara' riferimento solo alla dimensione compressa, decompressa, rapporto di compressione ecc... dell'ultimo membro, nel caso interessi solo la dimensione decompressa per tutti i files membri si puo' usare gzip -cd file.gz | wc -c
.
Nel caso si voglia ricomprimere files concatenati per ottenere una migliore compressione si puo' eseguire gzip -cd old_gzfile.gz | gzip > new_gzfile.gz
.
Se si vuole pero' creare un archivio di piu' files compressi indipendenti bisogna utilizzare il tar, che con l'opzione -z filtra gli archivi con gzip, creando cosi' i .tar.gz.
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2008-08-25 09:48:13
Alcuni esempi di configurazione ed utilizzo di rsync, con uso di password su file esterni e pattern sui file da copiare
Configurazione server: /etc/rscynd.conf
log file = /var/log/rsyncd.log
# motd file = /etc/rsyncmotd
timeout = 300
max connections = 4
log format = "%o %h [%a] %m (%u) %f %l %b"
transfer logging = yes
secrets file = /etc/rsyncd.secrets
[bacco]
path = /
comment = Backup
list = no
read only = no
uid = root
auth users = ced
hosts allow = 172.16.1.9
Esempio di secret file: /etc/rsyncd.secrets (il path e' configurabile in modo arbitrario)
ced:password
Utilizzo lato client
rsync -avz --password-file=/etc/rsyncd.secrets.ced --delete --exclude-from=/etc/rsyncd.patterns [email protected]::bacco/var
/backup/
Copia in /backup la directory var remota, cancellando i file locali che non esistono piu' sul server, usando i pattern definiti nel file /etc/rsyncd.patterns e la password specificata (per l'utente ced) su /etc/rsyncd.secrests.ced
rsync -avz --password-file=/etc/rsyncd.secrets.ced [email protected]::bacco/var/tmp/bacco
Come sopra, senza esclusione di file e senza cancellazione dei file
locali non piu' presenti sul server.
Esempio di /etc/rsyncd.patterns (come invocato da comando rsync lato client)
(copia di file che finiscono con .log, .gif .jpg )
+ */
+ *.log
+ *.gif
+ *.jpg
- *
Esempio di /etc/rsyncd.secrets.ced (come invocato da comando rsync lato client)
password
LINK: Rsync Official Documentation - http://samba.anu.edu.au/rsync/documentation.html
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2002-10-03 17:07:36
Comando che riduce la dimensione dei file usando la codifica di Lempel-Ziv (lo stesso algoritmo di zip e PKZIP). Quando possibile, ogni file rimpiazzato da uno con l'estensione .gz, mantenendo le stesse proprietà, date d'accesso e di modifica. Se il nome del file compresso è troppo lungo per il file system, gzip lo tronchera'.
gzip [opzioni] file
-c --stdout --to-stdout
Scrive l'uscita nello standard output; mantiene il file originale intatto.
-d --decompress --uncompress
Decomprime.
-f --force
Forza la compressione o la decompressione anche se il file ha link multipli o corrisponde a un file che già esiste, o se i dati compressi sono letti da (o scritti in) un terminale.
-l --list
Per ogni file compresso, elenca dimensione del file compresso, dimensione del file decompresso, rapporto di compressione (0.0% se sconosciuto), nome del file decompresso.
-N --name
Quando comprime, salva sempre il nome di file e la time stamp originali; il comportamento di default. Quando decomprime, ripristina il nome di file e la time stamp se sono presenti.
-r --recursive
Attraversa ricorsivamente la struttura della directory.
-S .suf --suffix .suf
Usa il suffisso .suf invece di .gz. Può essere dato qualsiasi suffisso, ma suffissi diversi da .z e .gz dovrebbero essere evitati per evitare confusioni quando i file sono trasferiti su altri sistemi.
-t --test
Test. Verifica l'integrità del file compresso.
-v --verbose
Verbose. Mostra il nome e la percentuale di riduzione di ogni file compresso o decompresso.
-# --fast --best
Regola la velocità di compressione usando la cifra # specificata, dove -1 o --fast indicano il metodo di compressione più veloce (minore compressione) e -9 o --best indicano il metodo di compressione più lento (migliore compressione). Il livello di compressione di default è -6.
LINK: Official gzip homepage - http://www.gzip.org
Schedulazione dei processi |
Utilizzo di crontab e at. Configurazione e alternative a crontab. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Luca 'pillolinux' Bove - Ultimo Aggiornamento: 2002-10-09 16:21:05
Alcuni processi devono essere eseguiti a determinati orari, un determinato numero di volte. Esempi di questi possono essere i processi di backup che vengono lanciati ogni notte, oppure un analizzatore di log che deve girare ogni minuto.
Questi processi devono girare un certo numero di volte oppure in determinati giorni; il resto del tempo essi stanno fermi fino a quando un utente non interagisce con essi e li richiama (con gli appositi comandi). Qui è dove il CRON si rende utile. Vi permette di programmare (o "schedulare", come si dice in gergo) l'esecuzione di un lavoro in qualsiasi momento desideriate, ogni minuto, ogni ora, giornalmente, mensilmente.
E' un sollievo sapere che ci sono vari programmi che stanno girando senza alcun bisogno della vostra supervisione.
Le Basi
Cron può essere fatto partire da rc
o da rc.local
e ritorna immediatamente al prompt, sicchè non c'é bisogno di lanciarlo in background. Cron ricerca il file /etc/crontab
per le voci (le cosiddette "entry") di sistema e /var/spool/cron
per le voci relative agli utenti che si trovano nel file /etc/passwd
. Tutte le voci ritrovate sono caricate in memoria.
Tutto ciò viene ripetuto ogni minuto appena cron "si sveglia" ed esegue diversi compiti:
a) ricerca le voci ed esegue i programmi che sono stati schedulati.
b) determina se il modtime (vale a dire la data e l'ora dell'ultima modifica) nella directory di cron è cambiato c) se il modtime nella directory cron è cambiato, cron ricerca tutti i file e ricarica i programmi che sono stati modificati.
Poiché cron cerca le modifiche ogni minuto, non è necessario farlo ripartire quando sono stati effettuati dei cambiamenti (editati) nei file nella directory cron.
Utilizzare crontab
Il "cron daemon" legge il file "crontab"; ogni utente può avere la propria versione di questo file, orientata agli specifici compiti che si vogliono eseguire. I flag associati con le applicazioni crontab specificano quando aprire crontab per avere la lista o per rimuovere e modificare compiti.
La sintassi per il programma crontab è la seguente:
crontab [-u user] file
crontab [-u user] -l -e -r
Questi parametri indicano:
-u
questa opzione comunica al sistema il nome dell'utente che "possiede" il file. Se l'opzione -u è omessa, il sistema deduce per default che state usando il vostro crontab personale.
Il comando switch user (su) può confondere il crontab, così se siete nello switch "su" assicuratevi di utilizzare l'opzione -u.
-l
questa opzione dice a crontab di elencare i file nello standard output, in poche parole visualizza il file.
-e
questa opzione dice a crontab di editare il file. Cron usa l'editor definito dalla variabile EDITOR o da VISUAL. Se nessuna di queste variabili è definita, parte in automatico l'editor "vi". Quando si esce dall'editor, è immediamente piazzato nella locazione corretta e viene aggiornato il campo data/ora.
-r
questa opzione rimuove il file crontab specificato, se nessun file viene specificato, rimuove il file crontab dell'utente.
Voci in Crontab
Solo 2 tipi di voci sono permesse nel crontab: i settaggi ambientali (Crontab Environmental settings) e i settaggi di comando (Crontab Command settings)
a) Crontab Environmental settings
I settaggi ambientali utilizzano la seguente forma:
nome = valore
Cron conosce già le diverse variabili ambientali. Per esempio, SHELL è settato a /bin/bash
.
Altre variabili ambientali, come LOGNAME e HOME, sono associate al possessore del file. SHELL e HOME posso essere sovrascritte nello script, mentre non è possibile farlo con LOGNAME. Se MAILTO è definito (e non è settato a " "), tale variabile è inserita in una riga nel file crontab, e spedisce ogni messaggio generato all'utente specificato in questo campo.
La seguente riga mostra MAILTO settato ad uno specifico utente (luca): # spedisce tutti gli output all'utente *luca* (non importa chi è il proprietario di questo crontab)
MAILTO=luca
b) Crontab Command settings
I settaggi comandi usano un formato standard: ogni riga inizia con cinque campi ora/data. Se è il crontab di sistema, il campo successivo è lo username associato con la voce. Il campo seguente sarà il comando da eseguire. Il comando verrà eseguito solo quando la data e l'ora corrente coincideranno con tutti i valori dei campi time/date del crontab. Nel paragrafo succ. vi è un esempio.
I campi disponibili per la data e l'ora sono i seguenti:
Campi | Valori ammessi
----------------
minuti | 0-59
ore | 0-23
giorno | 1-31
mese | 1-12
giorno della settimana | 0-7 (0 & 7 indicano la domenica)
Questi campi possono anche contenere un asterisco (*) invece di un numero. Un asterisco indica che ogni possibile valore è ammesso.
Dettagli
La righe seguenti mostrano il /etc/crontab installato per default nella RedHat 6.2:
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
Avete notato come crontab chiama i quattro diversi eventi?
Il primo è associato ad eventi orari (eseguiti nel primo minuto di ogni ora)
Il secondo è associato ad eventi giornalieri (eseguiti alle ore 4:02 di ogni giorno)
Il terzo è associato ad eventi settimanali (eseguiti alle 4:22 di ogni domenica)
L'ultimo è associato ad eventi mensili (eseguiti alle 4:42 nel primo giorno di ogni mese).
Qualcosa da ricordare:
Il sistema non va indietro e raccoglie i lavori cron, esso li esegue solo se la data e l'ora sono uguali alla voce nel file. Ad esempio se il computer è spento quando dovrebbe essere eseguito il cron, quel programma non viene più eseguito.
Permessi e divieti di accesso al servizio crontab
Ci sono due file che abilitano la root (solo la root dovrebbe avere il permesso di editare o creare questi file) per autorizzare o vietare l'utilizzo dei servizi crontab agli utenti; essi sono: /etc/cron.allow -- Questo file in genere non esiste, lo dovete creare. Ogni voce che piazzerete in questo file coprirà quella inserita in /etc/cron.deny. Se il file /etc/cron.allow
esiste, solo gli utenti specificati dentro posso usufruire del servizio crontab.
/etc/cron.deny
-- Questo file esiste per default. In esso, ci metterete lo username delle persone a cui vietate l'utilizzo del servizio crontab.
SOURCE: PILLOLINUX: Introduzione al servizio di scheduling di Crontab - http://www.freeonline.it/articolo_linux_dtml?id_articolo=37
Tipo Infobox: PATH - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-10-24 15:39:32
File di configurazione generale del demone crond contenente le operazioni schedulate di default o manulamente dall'utente root.
La sintassi di crontab prevede una riga, con campi separati da uno spazio o un tab, per ogni comando da schedulare.
mm hh gg MM GG user comando
I primi 5 campi servono per definire quando eseguire il comando specificato nel settimo campo. Possono contenere valori separati da virgola o un asterisco che indica tutti i calori possibili:
1) mm Minuto in cui eseguire il comando. Valori da 00 a 59.
2) hh Ora in cui eseguire il comando. Valori da 0 a 23 (0 è mezzanotte, 12 mezzogiorno)
3) gg Giorno del mese in cui eseguire il comando. Valori da 1 a 31.
4) MM Mese dell'anno in cui eseguire il comando. Valori da 1 a 12.
5) GG Giorno della settimana in cui eseguire il comando. Valori da 0 a 6. (0 corrisponde alla Domenica, 1 al Lunedì.. )
6) Utente con cui viene eseguito il comando. Crond viene eseguito come root e può impersonificare qualsiasi utente. Questo campo può anche essere omesso (root di default).
7) Riga di comando da eseguire (con eventuali opzioni, argomenti ecc.)
Vediamo un esempio:
[neo@dido neo]$ cat /etc/crontab
Variabili che settano l'enviroment per il lancio di script o di comandi
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
Le entry riportate di seguito sono quelle di default di una RedHat ed esegue a seconda della scadenza gli script contenuti nelle varie directory
# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
Il file di crontab relativo al singolo utente in: /var/spool/cron/$user
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-01-09 18:12:08
Si occupa di mandare in esecuzione tutti gli script o i programmi contenuti in una directory.
Esegue tutti i programmi contenuti nella directory passata come parametro. Eventuali sottodirectory vengono ignorate. Gli script da eseguire devono contenere come prima linea il nome dell'interprete nel formato #!/bin/nome-interprete
altrimenti non verrano eseguiti.
run-parts [opzioni] directory
--test
: visualizza il nome degli script che dovrebbero essere eseguiti ma senza mandarli in esecuzione;
--verbose
: stampa sullo standard error il nome di ogni script/programma prima di eseguirlo;
--report
: simile a --verbose
ma con la differenza che stampa solamente il nome degli script che producono un output;
--umask=<umask>
: setta l'umask specificata prima di eseguire gli script/programmi; L'umask di default e' 022;
--arg=<argomenti>
: passa eventuali argomenti allo script; E' necessario utilizzare --arg
per ogni argomento passato;
--help
: visualizza l'help in linea ed esce;
--version
: visualizza la versione il copyright ed esce;
Il suo utilizzo tipico è all'interno del file di configurazione di crontab:
[root@pluto etc]# cat /etc/crontab
[...]
# run-parts
01 * * * * root nice -n 19 run-parts /etc/cron.hourly
In questo esempio vengono eseguiti in tutte le ore di ogni giorno (al minuto 01) tutti i programmi/script contenuti nela directory /etc/cron.hourly
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2003-11-21 16:01:27
Anacron è l'alternativa a cron da utilizzare per la schedulazione di processi su macchine non utilizzate come server e quindi non sempre in funzione.
Questo demone permette di eseguire processi schedulati nell'arco di tempo in cui la macchina non era in funzione e che quindi tramite cron non sarebbero stati eseguiti. Anacron utilizza il file /etc/anacrontab
per la schedulazione e la directory /var/spool/anacron
per tenere traccia dei compiti svolti.
Per ogni job-description line inserita in anacrontab, anacron controlla se il comando è stato eseguito nel periodo specificato ed in caso contrario lo esegue con il ritardo specificato. Una volta eseguito il comando, la sua data di esecuzione viene registrata in un file di time-stamps identificato dal nome univoco assegnato al processo nella directory /var/spool/anacron
. Una volta terminati i job da eseguire anacron termina.
Per default in caso di errore viene inviata una mail all'utente che ha avviato anacron, mentre gli altri messaggi vengono loggati da syslogd.
HOWTO: Linux Parallel Processing HOWTO - http://ldp.openskills.info/HOWTO/Parallel-Processing-HOWTO.html
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2003-07-13 19:04:24
E' l'eseguibile del demone anacron.
Anacron, viene tipicamente avviato tra gli script di boot del sistema. La sua sintassi è la seguente:
anacron [opzioni]
-f
: forza l'esecuzione di anacron ignorando i timestamps;
-s
: serializza l'esecuzione dei job. Non avvia l'esecuzione di un nuovo job finche' il precedente non e' stato terminato;
-n
: avvia l'esecuzione dei job senza tenere conto di quanto specificato in /etc/anacrontab
. Implica l'utilizzo dell'opzione -s
.
-d
: non esegue il demone in background, e visualizza i messaggi di stato sullo standard error:
-u
: aggiorna solamente i file di time-stamps senza eseguire jobs;
-q
: non visualizza messaggi sullo standard error quando l'esecuzione avviente con l'opzione -d
;
-t <nomefile>
: Utilizza il file di configurazione specificato anziche' quello di default;
-V
: stampa la versione ed esce;
-h
: visualizza la guida ed esce.
Tipo Infobox: PATH - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2003-07-13 19:05:26
E' il file di configurazione di anacron.
Questo file descrive il comportamento di anacron. Esso può contenere assegnamenti di variabili, linee vuote e linee di commento le quali iniziano con il carattere #.
Ogni entry nel file di configurazione contiene 4 parametri:
-1 periodo: ogni quanto tempo, in giorni, deve essere eseguito un comando;
-2 ritardo: il tempo di ritardo, in minuti, per l'avvio del comando (utile per non sovraccaricare il sistema con troppo processi attivi);
-3 nome-job: un nome univoco per identificare il comando;
-4 comando: il comando vero e proprio da eseguire;
Un esempio del contenuto di anacrontab:
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
Setting delle variabili per l'esecuzione dei job
1 65 cron.daily run-parts /etc/cron.daily
7 70 cron.weekly run-parts /etc/cron.weekly
30 75 cron.monthly run-parts /etc/cron.monthly
Schedulazione rispettivamente di processi giornalieri, settimanali e mensili
Gestione e analisi dei log |
Analisi, monitoring, rotazione e gestione dei log di sistema. Configurazione di syslogd. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-09-27 21:28:02
Molto spesso ci si ritrova a diagnosticare problemi, capire perchè una applicazione non parte o eseguire blandi compiti di reverse engineering sul funzionamento di parti del sistema.
La prima fonte da consultare per ogni operazione di troubleshooting sono i log, file di testo che tengono traccia di errori e particolari azioni eseguite dal sistema, come il cambiamento di una password, il login di un certo utente o il messaggio di errore di una applicazione.
I log del sistema vengono generalmente scritti in directory come /var/log
e var/adm
o dove definito nei file di configurazione dei singoli programmi.
In quasi tutti i sistemi Unix il demone syslogd si occupa della gestione dei log tramite il file di configurazione /etc/syslog.conf
.
Le recenti distribuzioni Linux utilizzano sysklogd, una versione evoluta di syslogd che gestisce anche il logging del kernel (tramite il demone klogd).
Sono inoltre disponibili versioni modificato o più sicure di syslog.
L'equivalente su Windows dei log Unix sono gli eventi.
Tipo Infobox: PATH - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-10-24 19:50:09
E' il file di configurazione principale del demone syslog. Di solito ha questo path in Unix vari ed è comodo consultarlo per verificare in fretta dove il sistema scrive i suoi log.
Il file si puo' suddividere in due campi, suddivisi da uno o piu' spazi bianchi o TAB:
SELECTOR: Diviso a sua volta in due parti separate da un punto: facility (identifica chi o cosa ha prodotto il messaggio) e priority(identifica il livello di priorita' del messaggio)
ACTION:Identifica il "logfile" dove vengono scritti i log corrispondenti. Oltre ad un normale file può essere un device coem la stampante o una console.
Analizziamo un esempio preso da una macchina RedHat Linux:
[neo@dido neo]$ cat /etc/syslog.conf
[...]
Nel file /var/log/messages vengono loggati tutti i messaggi di livello informativo, tranne quelli relativi alla posta (mail), all'accesso al sistema (authpriv) e al cron
*.info;mail.none;authpriv.none;cron.none /var/log/messages
[...]
Tutti i log, di qualsiasi priorità, che hanno a che fare con l'accesso al sistema, sono loggati in /var/log/secure
authpriv.* /var/log/secure
[...]
Tutti i log riguardanti la posta sono scritti in /var/log/maillog
mail.* /var/log/maillog
[...]
Tutti i log di comandi eseguiti in cron sono scritti in /var/log/cron
cron.* /var/log/cron
[...]
Tutti i log con priorità di emergenza vengono inviati ai terminali di ogni utnete collegato al sistema
*.emerg *
I log relativi al boot (a cui è associata, su questo sistema la facility local7) sono scritti in /var/log/boot.log
local7.* /var/log/boot.log
Alcune interessanti opzioni che si possono configurare su questo file sono del tipo:
Tutti i log del sistema vengono inviati al syslog server chiamato pippo (il nome deve essere risolvibile)
*.* @pippo
Tutti i movimenti di posta vengono scritti sulla console tty10
mail.* /dev/tty10
Tutti gli accessi al sistema sono stampati direttamente su una stampante locale
authpriv.* /dev/lp0
Tipo Infobox: DESCRIPTION - Skill Level: 5- SENIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2009-02-23 19:51:27
Brief report of the installation of rsyslog on Centos 5, with mysql support and PhpLogCon web interface.
This procedure has been tested on Centos 5 using the EPEL rpm repository.
Ensure all necessary packages are installed:
yum install rsyslog rsyslog-mysql
If you want local mysql server and web interface:
yum install mysql-server
yum install httpd php php-mysyql php-gd
If not running, start mysqld:
service mysqld status || service mysqld start
Create mysql database for rsyslog (file path changes on other distros/releases ):
mysql < /usr/share/doc/rsyslog-mysql-2.0.0/createDB.sql
Set mysql permissions (must be the same in /etc/rsyslog.conf and /path/top/phplogcon/config.php )
mysql> grant all on Syslog.* to syslog@localhost identified by 'mypass';
mysql> flush privileges ;
vi /etc/rsyslog.conf
# Log to Mysql Settings
$ModLoad ommysql
*.* :ommysql:localhost,Syslog,syslog,phplogcon
#Standard Redhat syslog settings
*.info;mail.none;authpriv.none;cron.none /var/log/messages
authpriv.* /var/log/secure
mail.* -/var/log/maillog
cron.* /var/log/cron
*.emerg *
uucp,news.crit /var/log/spooler
local7.* /var/log/boot.log
Try rsyslog (disable sysklogd):
service syslog stop
service rsyslog start
If you get messages like:
Feb 23 23:43:30 mon rsyslogd:could not load module '/usr/lib/rsyslog/ommysql', dlopen: /usr/lib/rsyslog/ommysql: cannot open shared object file: No such file or directory
fix fast with:
ln -s /usr/lib/rsyslog/ommysql.so /usr/lib/rsyslog/ommysql
Enable rsyslog service at boot time (and disable default syslog)
chkconfig syslog off
chkconfig rsyslog on
CENTRAL RSYSLOG
As with standard syslogd edit /etc/sysconfig/rsyslog
with option -r:
SYSLOGD_OPTIONS="-m 0 -r"
to enable the listening of syslog on the default 514 UDP port.
This is necessary for a centralized syslog server.
PHPLOGCON
Get latest package from http://www.phplogcon.org/
Unpack and move relevant files under Apache documents:
tar -zxvf phplogcon-2.5.24.tar.gz
cd phplogcon-2.5.24
mkdir /var/www/html/syslog
cp -a src/* /var/www/html/syslog
cd /var/www/html/syslog
To permit web configuration:
chmod 666 config.php
Browse to web interface: http://yourserver/syslog/ and follow on screen instructions.
Enable a Mysql source and use the authentication settings defined before.
Note that the logs table name is SystemEvents
To restore safe settings (do it after web configuration):
chmod 644 config.php
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-02-01 10:52:22
La gestione e l'analisi dei log è un'attività sistemistica che richiede le sue attenzioni.
Su macchine ad alto traffico, o sotto attacco DOS o con particolari problemi ricorrenti, le dimensioni dei log possono crescere a dismisura in pochissimo tempo, fino a saturare il file system.
Per questo motivo è sempre consigliabile montare la directory /var
, dove generalmente risiedono i log, in una partizione indipendente, che, anche se riempita, non blocca il funzionamento del sistema.
E' inoltre importante poterli gestire, ruotandoli ad intervalli fissi e compattando i log vecchi, preparandoli per un'archiviazione.
Su molte distribuzioni Linux è incluso Logrotate, un'applicazione che semplifica l'amministrazione dei log, permette di comprimere, rimuovere ed inviare il log via mail oltre a eseguire una rotazione di file con vari criteri.
Il file di configurazione è /etc/logrotate.conf
In sistemi che usano RPM , solitamente, le regole di gestione dei singoli log sono inserite nella directory /etc/logrotate.d/
.
Generalmente gli script che eseguono logrotate sono inseriti nel crontab e di default sono configurati per gestire i log standard di sistema.
Altra applicazione che viene spesso usata per gestire, in particolare, i log di Apache è Cronolog, che rende particolarmente semplice la segmentazione di log in file diversi generati secondo unità di tempo configurabili (es: un file diverso ogni giorno). E' particolarmente utile per gestire siti ad alto traffico, in cui le dimensioni dei log tendono a crescere in modo spropositato.
Viene tipicamente usato come un filtro che riceve un log dallo standard input e lo scrive in stdout su più diversi file, secondo le specifiche indicate in un template. La sintassi di base è /path/cronolog [opzioni] template
. Per esempio:
/usr/sbin/cronolog /web/logs/%Y/%m/%d/access.log
divide il log che riceve in stdout in tanto diversi log in diverse directory secondo il criterio /web/logs/anno/mese/giorno/access.log, con risultati tipo: /web/logs/2003/01/17/access.log.
Viene tipicamente usato in httpd.conf sfruttando la funzionalità di Apache di inviare i log ad un comando esterno:
TransferLog "|/usr/sbin/cronolog /web/logs/%Y/%m-%d-access.log"
ErrorLog "|/usr/sbin/cronolog /web/logs/%Y/%m-%d-errors.log"
Crea un file di log diverso ogni giorno e li mette in directory divise per anno.
Il vantaggio di simili programmi è quello di sollevare l'amministratore dalla noiosa e insidiosa pratica di gestione e archiviazione dei log, che se non automatizzata può portare a spiacevoli conseguenze quali file system riempiti al 100%, file di log enormi, perdita di dati e simili contrattempi.
LINK: Home page di cronolog - http://www.cronolog.org/
LINK: Cronolog Home Page - http://www.cronolog.org/
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2003-06-03 21:02:51
E' l'applicazione inclusa in diverse distribuzioni Linux per la gestione dei log di sistema.
Logrotate permette di comprimere, rimuovere ed inviare via mail i file di log. Ogni file può essere gestito in base criteri temporali (giornalmente, settimanalmente, o mensilmente) oppure alle proprie dimensioni. Tipicamente l'utilizzo di logrotate viene schedulato tramite il demone cron ed i file di log da esso gestiti non vengono modificati più di una volta al giorno salvo che il criterio sia basato sulla dimensione e logrotate avviato più volte al giorno oppure che sia utilizzata l'opzione -f
o --force
e quindi logrotate sia forzato a rielaborare i file di log.
Logrotate utilizza /var/lib/logrotate/status
per tenere traccia dei log elaborati e /etc/logrotate.conf
per quanto riguarda la configurazione. Alcuni packages installano informazioni relative alla rotazione dei log in /etc/logrotate.d/
.
La sintassi è la seguente:
logrotate [-dvf?] [-m command] [-s statefile] [--usage]
-d
: Abilita il debug mode. Questa azione implica anche l'utilizzo automatico dell'opzione -v
. In modalità di debug, non vengono apportati cambiamenti ai log o al file di stato;
-v
: Abilita il verbose mode ovvero visualizza informazioni durante la rotazione dei log;
-f
: Forza la rotazione dei log;
-?
: Visualizza una breve guida in linea;
-m <comando>
: Indica a logrotate quale comando utilizzare per inviare via mail i log. Di default viene utilizzato /sbin/mail -s
;
-s <state-file>
: Indica a logrotate di utilizzare un file di stato diverso da quello di default ovvero /var/lib/logrotate/status
;
--usage
: Visualizza le opzioni disponibili per l'applicazione.
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2003-06-03 20:55:34
E' il file principale riguardante la configurazione di logrotate.
Attraverso il file di configurazione di logrotate è possibile definire il comportamento dell'applicazione in due contesti: a livello globale (nella prima parte del file) e a livello locale dove le regole ridefinite prevalgono su quelle globali. Per ogni file di cui si vuole effettuare la rotazione è necessario indicarne il percorso, al quale seguono tra parentesi graffe le direttive di gestione.
Tra le direttive più utili:
- Criteri di rotazione
daily
: Rotazione su base giornaliera;
weekly
: Rotazione su base settimanale;
monthly
: Rotazione su base mensile;
size <dimensione>
: Rotazione in base alla dimensione;
notifempty
: Non esegue la rotazione se il file è vuoto;
- Compressione
compress
: Una volta archiviato il file di log, viene compresso tramite gzip;
compresscmd
: Indica il programma da utilizzare al posto di gzip;
- Gestione File
create <mode> <owner> <group>
: Immediatamente dopo la rotazione viene creato un nuovo file con il nome identico al precedente. E' possibile specificare, modalità di accesso, proprietario e gruppo;
copy
: Crea una copia del file di log e non modifica l'originale che non viene mai rimosso;
copytruncate
: Utilizzata nel caso in cui non sia possibile chiudere il file di log. Viene archiviata parte del file di log mentre ne viene eseguita una copia;
olddir <directory>
: I file di log vengono spostati nella directory indicata prima di eseguire la rotazione;
- Configurazione
include <file o directory>
: Legge il file oppure tutti i file della directory indicata ed applica le direttive incontrate all'interno di essi. E' possibile trovare include /etc/logrotate.d
in quanto alcuni packages installano le proprie istruzioni in questa directory;
- Operazioni Pre-log e Post-log
postrotate endscript
: Tramite questo blocco di direttive è possibile eseguire delle operazioni in seguito alla rotazione;
prerotate endscript
: Tramite questo blocco di direttive è possibile eseguire delle operazioni prima che avvenga la rotazione e solo se questa avrà luogo;
Un esempio del file di configurazione:
#
# Parametri Globali
#
compress Abilita la compressione, di default con gzip, dei log dopo la rotazione
weekly La rotazione di default è stabilita con criterio temporale settimanale ovvero ogni settimana viene creato un nuovo file di log
# Parametri Locali
/var/log/debug {
rotate 2 Indica che verranno mantenuti due file di log, in particolare uno per ogni settimana. La rotazione in questo caso è settimanale in quanto la direttiva di default non è stata ridefinita.
postrotate Blocco postrotate ovvero istruzioni eseguite in seguito alla rotazione di un log. Possono esistere solamente all'interno di direttive locali
/sbin/killall -HUP syslogd Ferma e riavvia il logging da parte di syslogd in modo che possa riprendere a lavorare sul nuovo file una volta effettuata la rotazione del vecchio file di log
endscript Termine blocco postrotate
}
/var/log/faillog {
monthly Il criterio temporale viene ridefinito localmente e passa da settimanale a mensile
rotate 2 Rotazione ogni 2 mesi
postrotate
/sbin/killall -HUP syslogd
endscript
}
/var/log/lastlog {
rotate 3 Rotazione ogni 3 settimane
postrotate
/sbin/killall -HUP syslogd
endscript
}
/var/log/maillog {
monthly
rotate 2 Rotazione ogni 2 mesi
postrotate
/sbin/killall -HUP syslogd
endscript
}
/var/log/syslog {
rotate 4 Rotazione ogni 4 settimane
postrotate
/sbin/killall -HUP syslogd
endscript
}
/var/log/messages {
rotate 2 Rotazione ogni 2 settimane
postrotate
/sbin/killall -HUP syslogd
endscript
}
/var/log/proftpd.log { Log ProFTPD Server
rotate 3 Rotazione ogni 3 settimane
postrotate
/sbin/killall -HUP syslogd
endscript
}
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-09-25 17:58:57
Per loggare su un syslog server Linux/Unix i log di un Cisco si deve intervenire sia sul router che sul server.
Su Cisco configurare lo IOS (conf term) per definire il syslog server (qui 10.0.0.20):
logging server 10.0.0.20
(opzionale, imposta il logging a livello 7: debug)
logging facility local2
logging trap 7
Sul syslog server Unix/Linux fare partire syslog con l'opzione di logging via rete (senza questo il syslogd non accetta messaggi via rete):
syslogd -r
e configurare /etc/syslog.conf per accettare i messaggi dal cisco (facility local2):
local2.* /var/log/cisco.log
La porta usata per il syslog via rete è la 514 UDP.
Considerare che syslog è un protocollo estremamente vulnerabile (accetta qualsiasi informazione, senza verificare contenuto o sorgente). E' opportuno limitare agli IP che servono (con packet filtering di vario tipo) l'accesso alla porta 514 di un syslog server.
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2002-10-28 12:50:19
Logwatch e' uno strumento che permette l'analisi e il monitoraggio dei log.
E' molto semplice, versatile e flessibile in quanto permette di impostare il servizio che si vuole monitorare, il livello di monitoraggio, filtri customizzabili per il matching di pattern, periodi di tempo specifici ecc...
Oltre a questo e' possibile settare una mail a cui inviera' il report o un file dentro il quale salvarli.
I file e le directory principali di logwatch sono generalmente:
/etc/log.d/conf/logwatch.conf
: file di configurazione di logwatch;
/etc/log.d/conf/services/
: directory che contiene i file di configurazione per i diversi servizi i cui log possono essere processati da logwatch;
/etc/log.d/conf/logfiles/
: directory che contiene i file di configurazione per i file contenenti i log di diversi servizi;
/etc/log.d/scripts/shared/
: directory che contiene i filtri comuni per i servizi o logfiles;
/etc/log.d/scripts/logfiles/
: directory che contiene i filtri specifici per logfiles particolari;
/etc/log.d/scripts/services/
: directory che contiene i filtri attuali per i vari servizi.
Logwatch viene tipicamente schedulato in crontab per eseguire dei controlli periodici sui log di sistema ed inviarne il report via mail.
LINK: LogWatch Home Page - http://www.logwatch.org/
Networking - Configurazione |
Configurare i parametri di rete e il DNS: ifconfig, route, resolv.conf |
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: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-07-10 23:23:01
Linux, a differenza di altri Unix come Solaris (dove ogni modello di scheda di rete ha un nome diverso in /dev) raggruppa i nomi delle interfacce di rete secondo il tipo (etherner, token ring, tunnel. ppp ecc.)
Su Linux, a prescindere dal modello, la prima scheda di rete ethernet ha sempre nome eth0
, le successive hanno nomi eth1
- eth2
ecc.
Interfacce tipo eth0:0
, eth0:1
sono interfacce logiche usate per ip virtuali attestati sulla stessa interfaccia fisiche.
Analogamente esistono nomi specifici per diversi protocolli di data link:
- token ring hanno nomi tipo tr0
, tr1:0
- ppp: ppp0
- il loopback (127.0.0.1, localhost) si rappresenta con lo
Anche delle VPN possono attestarsi su nomi di interfacce di rete come:
- Ipsec: ipsec0
- OpenVPN: tun0
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: PATH - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2005-07-23 21:27:46
File di configurazione per il settaggio dei server DNS che il nostro sistema deve utilizzare (più precisamente è il file che configura il comportamente delle librerie del resolver, utilizzate da tutti i programmi fare query DNS).
[neo@dido neo]$ cat /etc/resolv.conf
Entry che identifica il nome del dominio a cui appartiene la propria macchina
domain dominio.it
Elenca domini che vengono aggiunti a nomi di host per ricerche DNS. Può generare traffico inutile e ritardi.
search dominio2.it dominio.com
Indirizzo IP del DNS primario
nameserver xxx.xxx.xxx.xxx
Indirizzo IP di un eventuale DNS secondario
nameserver xxx.xxx.xxx.xxx
Imposta a 3 secondi il tempo di timeout per una query DNS. Default 5 (su RedHat Linux)
options timeout 3
Imposta a 3 il numero di tentativi andati in timeout prima di rinunciare. Default 5 (su RedHat Linux)
options attempts 3
Networking - Diagnosi |
I comandi e le tecniche per diagnosticare la rete: netstat, arp, tcpdump. |
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: STDOUT - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-12-04 23:02:37
Visualizzazione dei software che mantengono porte in listening, con relativo indirizzo IP.
root@enigma:/# netstat -nlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:2401 0.0.0.0:* LISTEN 640/inetd
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 773/mysqld
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 640/inetd
tcp 0 0 192.168.0.2:80 0.0.0.0:* LISTEN 783/httpd
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 640/inetd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 643/sshd
tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 722/cupsd
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 692/master
udp 0 0 0.0.0.0:631 0.0.0.0:* 722/cupsd
...
L'opzione -n visualizza gli indirizzi in formato numerico, -l filtra solamente le porte in stato listen mentre -p visualizza il PID ed il nome del programma che mantiene aperta una determinata porta
Tipo Infobox: STDOUT - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-10-12 20:08:02
Visualizzazione delle statistiche per quanto riguarda la network.
Utili per capire se il vostro server ha problemi, anomalie in ambito network o semplicemente per dedurre quanto traffico ha prodotto la vostra macchina.
[neo@dido neo]$ netstat -s
Statistiche relative ai pacchetti IP
Ip:
14743 total packets received
0 forwarded
0 incoming packets discarded
14385 incoming packets delivered
15907 requests sent out
Statistiche relative ai pacchetti ICMP
Icmp:
6 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
destination unreachable: 6
6 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 6
Statistiche relative ai pacchetti TCP
Tcp:
1039 active connections openings
0 passive connection openings
0 failed connection attempts
0 connection resets received
2 connections established
14419 segments received
15721 segments send out
145 segments retransmited
0 bad segments received.
25 resets sent
Statistiche relative ai pacchetti UDP
Udp:
169 packets received
2 packets to unknown port received.
0 packet receive errors
180 packets sent
TcpExt:
ArpFilter: 0
567 TCP sockets finished time wait in fast timer
7 packets rejects in established connections because of timestamp
269 delayed acks sent
Quick ack mode was activated 134 times
16 packets directly queued to recvmsg prequeue.
400 packets directly received from prequeue
6182 packets header predicted
16 packets header predicted and directly queued to user
TCPPureAcks: 1336
TCPHPAcks: 1195
TCPRenoRecovery: 0
TCPSackRecovery: 0
TCPSACKReneging: 0
TCPFACKReorder: 0
TCPSACKReorder: 0
TCPRenoReorder: 0
TCPTSReorder: 0
TCPFullUndo: 0
TCPPartialUndo: 0
TCPDSACKUndo: 0
TCPLossUndo: 0
TCPLoss: 0
TCPLostRetransmit: 0
TCPRenoFailures: 0
TCPSackFailures: 1
TCPLossFailures: 0
TCPFastRetrans: 0
TCPForwardRetrans: 0
TCPSlowStartRetrans: 0
TCPTimeouts: 69
TCPRenoRecoveryFail: 0
TCPSackRecoveryFail: 0
TCPSchedulerFailed: 0
TCPRcvCollapsed: 0
TCPDSACKOldSent: 158
TCPDSACKOfoSent: 29
TCPDSACKRecv: 0
TCPDSACKOfoRecv: 0
TCPAbortOnSyn: 0
TCPAbortOnData: 4
TCPAbortOnClose: 34
TCPAbortOnMemory: 0
TCPAbortOnTimeout: 8
TCPAbortOnLinger: 0
TCPAbortFailed: 0
TCPMemoryPressures: 0
Tipo Infobox: STDOUT - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-10-14 18:03:20
Visualizzazione delle route configurate sul sistema.
L'output e' identico al comando route -n , l'unica differenza dei due comandi e' il PATH; ovvero il comando route non e' all'interno dei path settati di default da RH linux per i normali utenti netstat invece si.
Output del comando netstat.
[neo@dido neo]$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.208.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0
Route per i pacchetti che hanno come destinazione la propria network
127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo
Route per i pacchetti che hanno come destinazione lo
0.0.0.0 192.168.208.254 0.0.0.0 UG 40 0 0 eth0
Route che identifica il default gw
Output del comando route. Da notare che si e' dovuto specificare il path assoluto del comando!
[neo@dido neo]$ route -n
bash: route: command not found
[neo@dido neo]$ /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.208.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Route per i pacchetti che hanno come destinazione la propria network
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
Route per i pacchetti che hanno come destinazione lo
0.0.0.0 192.168.208.254 0.0.0.0 UG 0 0 0 eth0
Route che identifica il default gw
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: 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: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-11-16 19:49:46
TTCP, test TCP è un tool Open Source originariamente scritto da Mike Muuss che permette di verificare le performance (Throughput) della propria network evitando di scrivere o leggere dati su disco dando dunque la possibilità di testare anche network basate su fibra.
Il test si basa sull'invio e ricezione di pacchetti UDP o TCP tramite due host oppure utilizzandolo come "network pipe" , quindi con un terzo host che ha la funzione di inviare e ricevere, è possibile verificare il Throughput di un segmento di network che originariamente per motivi di routing o strutturali non possono colloquiare fra di loro.
Installazione
L'installazione non richiede nessuna particolare attenzione, sia tramite rpm o compilazione dei sorgenti. Per i primi ci si può appoggiare ai vari repository come http://www.rpmfind.net per trovare il package più adatto per i sorgenti si possono trovare in rete in varti ftp server pubblici come
Installazione da RPM
[root@dido root]# wget ftp://216.254.0.38/linux/redhat/9/en/os/i386/RedHat/RPMS/ttcp-1.12-7.i386.rpm
--11:12:45-- ftp://216.254.0.38/linux/redhat/9/en/os/i386/RedHat/RPMS/ttcp-1.12-7.i386.rpm
=> `ttcp-1.12-7.i386.rpm'
Connecting to 216.254.0.38:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /linux/redhat/9/en/os/i386/RedHat/RPMS ... done.
==> PORT ... done. ==> RETR ttcp-1.12-7.i386.rpm ... done.
Length: 12,259 (unauthoritative)
100%[=================================================================================>] 12,259 33.72K/s ETA 00:00
11:12:47 (33.72 KB/s) - `ttcp-1.12-7.i386.rpm' saved [12259]
[root@dido root]# rpm -ihv /home/neo/fastweb/ttcp-1.12-7.i386.rpm
Preparing... ########################################### [100%]
1:ttcp ########################################### [100%]
[root@dido root]# rpm -qil ttcp
Name : ttcp Relocations: (not relocateable)
[...]
Binario
/usr/bin/ttcp
Manual e file README
/usr/share/doc/ttcp-1.12
/usr/share/doc/ttcp-1.12/README
/usr/share/man/man1/ttcp.1.gz
Installazione da sorgenti
[root@dido root]# wget http://www.netcordia.com/tools/tools/TTCP/ttcp.c
--11:22:11-- http://www.netcordia.com/tools/tools/TTCP/ttcp.c
=> `ttcp.c'
Resolving www.netcordia.com... done.
Connecting to www.netcordia.com[63.208.176.20]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 19,554 [text/plain]
100%[=================================================================================>] 19,554 60.81K/s ETA 00:00
11:22:12 (60.81 KB/s) - `ttcp.c' saved [19554/19554]
[root@dido root]# gcc -O3 -o ttcp ttcp.c
ttcp.c:539: warning: static declaration for `gettimeofday' follows non-static
Esempi di uso
Qualunque sia la funzione del test o l'invio dati tramite ttcp occorre attivarlo almeno su due host, sul primo in modalità "trasmitter" e il secondo in modalità "receiver".
Abilitazione del receiver tramite l'opzione -r, maggior verbosità con l'opzione -v e l'opzione -s per eviatre che i dati in stdin vengano printati sullo stdout.
La porta di ascolto di default è la 5001
[root@nefertiti root]# ttcp -r -v -s
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp
ttcp-r: socket
Abilitazione del trasmitter tramite l'opzione -t , specificando nella linea di comando l'host receiver o l'host che ha la funzione di network pipe e come era per il receiver anche qui l'opzione -s è dobbligo se si vuole effetuare un test.
[root@pippo root]# ttcp -t -v -s 192.168.1.2
Esempio Risulato
Per un considerare un test valido vengono richiesti almeno dieci secondi di trasferimento dati.
ttcp-r: accept from 192.168.1.5
ttcp-t: 16777216 bytes in 408.85 real seconds = 40.07 KB/sec +++
ttcp-t: 16777216 bytes in 0.00 CPU seconds = 1638400000.00 KB/cpu sec
ttcp-t: 2048 I/O calls, msec/call = 204.42, calls/sec = 5.01
ttcp-t: 0.0user 0.0sys 6:48real 0% 0i+0d 0maxrss 0+2pf 0+0csw
ttcp-t: buffer address 0x8050000
Esempio di utilizzo di ttcp come "network pipe"
[root@pippo root]# ttcp -rvs | ttcp -tvs 192.168.1.5
ttcp-r: socket
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp -> 192.168.1.5
ttcp-t: socket
ttcp-t: connect
In questo caso tutto il traffico ricevuto dall'host pippo sulla porta 5001 verrà dirottato sull'host 192.168.1.5
LINK: TTCP from CISCO - http://www.cisco.com/warp/public/471/ttcp.html
LINK: Repository di sorgenti di varie versioni - http://www.netcordia.com/tools/tools/TTCP/ttcp.html
LINK: Codice sorgente originale di Mike Muuss - http://sd.wareonearth.com/~phil/net/ttcp/ttcp.c
Networking - Tool comuni |
I comandi comuni per utilizzare la rete: finger, ftp, nslookup, dig, lynx, wget. |
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-16 18:05:20
Parlare di reti vuol dire anche parlare di protocolli e servizi di tutti i tipi, per vari scopi. Alcuni sono un retaggio del passato, di quel mondo accademico basato su Unix su cui Internet è cresciuta.
I comandi testuali per utilizzare, diagnosticare rete e servizi sono comuni a tutti gli Unix e, spesso a tutti i sistemi operativi, in quanto costituiscono spesso dei normali client per protocolli condivisi.
Le stesse funzioni e gli stessi protocolli sono comunemtne usati con analoghi strumenti e programmi grafici.
Gli strumenti più comuni, accessibili dalla shell di molti Unix sono:
telnet Permette un collegamento su una shell di un host remoto. E' comunissimo e molto diffuso. Richiede una login e un password che vengono trasmesse in chiaro sulla rete.
ssh Come telnet permette l'accesso remoto via shell ad un sistema, ma i dati trasmessi vegnono criptati per maggior sicurezza.
nslookup - dig Sono di fatto dei client DNS, permettono di interrogare server DNS e consentono precise operazioni di analisi e troubleshooting.
ftp E' un comune protocollo di trasferimento di file fra host remoti. E' anche il nome di base del client con cui si possono uploadare o downlodare file da server FTP remoti.
lynx - links Sono dei cleint HTTP testuali, cioè dei browser che visualizzano solo i testi dei siti web e non le immagini.
wget E' un comodo comandi, comuni in molti Linux ma disponibile anche su Unix, per scaricare file remoti tramite FTP o HTTP.
finger E' il client dell'omonimo protocollo, permette di elencare gli utenti collegati su un host remoto. Ormai è usato raramente.
traceroute Permette di visualizzare l'elenco degli nodi che esistono fra il nostro host e l'indirizzo specificato.
ping Permette di diagnosticare se è raggiungibile via retel'indirizzo specificato.
whois Esegue una query whois, utile anche per ottenere dati su chi ha registrato il dominio specificato.
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2004-05-23 16:11:34
Restituisce informazioni utili dei vari utenti del sistema (anche remoti).
Ormai, per questioni di riservatezza e sicurezza, il numero di server finger in rete è ridottissimo.
finger [-lmsp] [user] [user@host]
-m
Switch per identificare se il nome dell'utente corrisponde al login name oppure al real-name.
-s
Visualizza login name, real name, terminal name,write status, idle time, login time, e eventuali informazioni sull'ufficio e il numero di telefono.
-p
Utilizzato con l'opzione -l non visualizza alcune informazioni contenute nei seguenti file ``.plan'', ``.project'' e ``.pgpkey''
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-10-10 18:30:16
Un web browser testuale con comandi simili a lynx che supporta anche tabelle e frames.
Come tutti i web browser testuali risulta essere un prodotto veloce, leggero e funzionale, ma può presentare difficoltà di visualizzazione con siti con alto contenuto grafico o dinamico.
links -[OPTIONS] [filename|URL]
I comandi riportati sono quelli in aggiunta o diversi da lynx
F9 e F10
Richiama il menu.
^C
Exit
Left Arrow
Permette di fermare il download
\
Switch che permette la visualizzazione dei src della pagina html
^Z
Links passa in background. Per richiamarlo fg links.
LINK: Home page del progetto links - http://links.sourceforge.net/
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2004-05-23 16:12:32
Lynx è un web browser testuale molto popolare, veloce e comodo, ma non supporta i frame.
Le opzioni disponibili sono infinite, di seguito sono riportati i comandi piu comuni da utilizzare una volta che lynx è stato lanciato
lynx [options] [path or URL]
lynx --help
Per richiamare l'help
COMMANDS
Up arrows e Down Arrows
Permette lo scroll della pagina visualizzata
Return e right Arrows
Segue il ink selezionato nella pagina visualizzata, equivalente al click con il mouse sul link.
Left Arrows
Richiama la pagina precedentemente caricata.
H; ?
Richiama l'help.
K
Richiama la lista dei comandi con le relative key bindate.
d
Esegue il download.
g
Abilita la funzione goto, ovvero ti permette di cambiare url.
q
Chiude il browser.
o
Richiama una finistra con la possibilita' di cambiare le opzioni.
p
Esegue la stampa
^A
Richiama la home page
!
Richiama la shell senza chiudere il browser, e' possibile richiamarlo digitando in shell exit
LINK: Faq, Official Info - http://lynx.isc.org/release/lynx2-8-3/lynx_help/lynx_help_main.html
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-10-10 18:43:48
Utility GNU per downlodare files, sia tramite HTTP che FTP, con la possibilita' del resume, di logging e tante altre features.
Possiede due file di configurazioni che possono contenere le opzioni di default del comando:
-.wgetrc file di configurazione del singolo utente
- /usr/local/etc/wgetrc file di configurazione globale
Di seguito sono riportate le opzioni piu' interessanti:
wget [option]... [URL]...
BASIC OPTIONS
-b; --background
Esegue il processo in background
-e; --execute
Esegue il comando come se fosse all'interno del file di configurazione dell'utente .wgetrc
LOGGING E INPUT FILE OPTIONS
-o logfile;--output-file=logfile
Logga tutti i messaggi dello STERR in un file.
-a;--append-output=logfile
Come sopra, con la differenza che esegue un'append al file di log se tale file esiste gia'.
-d;--debug
Abilita il debug
-i;--input-file=file
Legge l'eleco degli indirizzi dal file specificato
-F;--force-html
Opzione per indicargli che il file in input e' un file html, e i vari url a cui si deve connettere sono quelli all'interno del tag del link (href="url")
DOWNLOAD OPTIONS
--bind-address
Specifica l'indirizzo a cui bindarsi sulla macchina locale
-c;--continue
Opzione per abilitare il resume di un download
--spider
Abilita lo spider mode, ovvero non scarica niente ma verifica che l'url esista
-Q;--quota
Specifica quanto scaricare, non funziona con un singolo file!
DIRECTORY OPTIONS
-nd;--no-directories
Non ricrea la struttura completa trovata sul server remoto, quindi tutti i file vengono scaricati nella directory corrente.
-x;--force-directories
Esattamente l'opposto dell'opzione -nd, ovvero foza la creazione della struttura ristrovata sul server remoto
HTTP OPTIONS
--http-user=user;--http-passwd=password
Specifica Utente e password per connettersi via http ad un server remoto
-C on/off; --cache=on/off
Abilita o meno la cache lato server
--cookies=on/off
Abilita o meno l'uso dei cookies
-U agent-string;--user-agent=agent string
Opzione che ti permette di modificare l'user-agent per identificarsi al web server
FTP OPTIONS
-g on/off;--glob=on/off
Abilita o meno l'uso delle wildcards. [ " * ", " ? " etc..]
--passive-ftp
Abilita il passive mode
RECURSIVE RETRIEVAL OPTIONS
-r;--recursive
Abilita il recursive mode
--delete-after
Cancella cio' che e' stato scaricato (ovviamente sulla macchina locale)
--convert-link
Opzione che permette di modificare in modo automatico i link all'interno di una pagina html per permettere la visualizzazioenda locale
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-10-10 18:45:34
Valida alternativa a nslookup per effettuare query sul dns.
Come nslookup ha due modi di utilizzo:
- Interactive mode, per effettuare una semplice query
- Batch mode, per effettuare una serie di query contenute in un file
dig [@server] domain [] [] [-]
@server
Specifica il server DNS a cui fare le query
query-type
Specifica che tipo di query effettuare
query-class
Seleziona la class della query
-f
-dig-options che specifica il file contenente le query da effettuare in modalita' batch mode.
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-10-10 18:42:13
Comando che permette di lanciare query dns per la risoluzione di ip o hostname.
Agisce in due modalita:
Interactive: Permette di effettuare piu' query e visualizza i singoli riultati. Viene abilitato in modo automatico quando il comando non e' seguito da argomenti oppure se il primo argomento e' un trattino (-) seguito dal secondo argomento che corrisponde all'host name o all'ip del name server.
non-interctive: Permette di effettuare una sola query e ovviamente visualizza il risultato della singola query. Abilitato ogni qualvolta che si specifica l'host-to-find.
Il DNS di default a cui si effettuano le query e' quello configurato in /etc/resolv.conf
nslookup [opzioni] [host-to-findi] [-server]
INTERACTIVE COMMAND
?
richiama l'help
host [server]
look up dell'host eseguendo una query al dns di default oppure al server specificato
server nomeserver
Modifica il dns di default per la sessione corrente
set keyword [value]
Comando che permette di cambiare i criteri di ricerca e visualizzazione delle informazioni che si vanno a richiedere al dns. Di seguito sono riportati alcune opzioni di questo comando.
all
Visualizza tutte le opzioni che sono selezionate di default
class=value
Modifica la query class
type
Modifica il tipo di informazioni da richiedere al dns.
CLASS
IN
Internet class
CHAOS
chaos class
HESIOD
MIT Athena Hesiod class
ANY
wildcard, cioe' tutte le classi
TYPE
A
L'indirizzo internet di un host
CNAME
canonical name di un alias
MX
mail exchanger
NS
Name server autoritativo della zona
PTR
l'host name se la query e' per un indirizzo internet altrimenti altre informazioni
SOA
Visualizza i dns autoritativi della zona
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2004-05-23 16:11:14
Ftp oltre ad essere un protocollo e' anche il comando (user-interface) per connettersi ad un server ftp.
Utilizzato per downloadare e uploadare files. Disponibile in tutti gli Unix e su Windows.
I comandi che si possono dare dal client sono quelli tipici del protocollo FTP e risultano disponibili su ogni client ftp.
ftp -pievd [host]
-p
Abilita il passive mode, utile se ci sono firewall fra il server ed il client
-i
Disabilita l'interctive prompting
-e
Disabilita il command editing e l'history
-v
Abilita il verbose mode
-d
Abilita il debugging
Comandi FTP
open nomehost
Si collega all'host specificato
user login
Si logga all'host a cui si è connessi con la login indicato
open nomehost
Si collega all'host specificato
dir
Visualizza file e directory.
get nomefile
Scarica il file specificato
put nomefile
Fa un upload sul server ftp del file locale specificato
cd nomedir
Cambia la directory corrente
ascii
Attiva la modalità di trasferimento file ascii
bin
Attiva la modalità di trasferimento file binari
pas
Attiva/disattiva la modalità passiva
!
Esegue il comando localmente. Es: !dir visualizza la directory corrente locale e non quella sul server FTP remoto.
Tipo Infobox: BOFH - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2006-09-20 21:59:26
Permette di scaricare un file dalla rete, eseguendo il processo in background (opzione -b) con possibilità di recupero in caso di interruzione (opzione -c) partendo dal file di log generato (opzione -o).
homer@Joker:~$ wget -c -b -o disc1-log ftp://ftp.edisontel.com/pub/Fedora_Mirror/1/i386/iso/yarrow-i386-disc1.iso
Continuing in background, pid 1340.
Utile nel caso sia necessario, abbandonare una shell remota di una macchina con un download in corso. Wget continuerà a scaricare i file anche dopo la disconnessione e in caso di interruzione imprevista il download potrà comunque essere ripreso.
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
DHCP server |
Protocollo, installazione, configurazione ed uso di un server DHCP (ISC) |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-06-04 10:28:00
Il protocollo DHCP Dynamic Host Configuration Protocol fornisce un meccanismo per assegnare dinamicamente gli indirizzi IP ed i parametri di configurazione ad un host tramite TCP/IP.
Questo protocollo definito dalle RFC 1533, 1534, 1541 e 1542 è un'estensione del protocollo BOOTP. L'utilizzo del DHCP su una rete con un significativo numero di macchine ne permette una migliore e più semplice gestione, riducendo i possibili conflitti di indirizzo.
Attraverso DHCP infatti, oltre ad assegnare ad ogni macchina automaticamente un diverso indirizzo di rete e la relativa subnet mask, è possibile assegnare anche altri parametri come per esempio: l'indirizzo di broadcast, il nome del nodo e del dominio, il gateway predefinito, l'indirizzo del server di stampa, l'indirizzo del DNS ecc.
Per utilizzare questo protocollo deve essere configurata una macchina, il DHCP Server, che si fa carico di distribuire gli indirizzi e gli altri parametri di configurazione ai client che ne fanno richiesta. Il range degli indirizzi distribuibili è chiamato Scope, ed ogni configurazione è valida solo per un determinato periodo di tempo, chiamato tempo di lease, scaduto il quale il client deve richiedere nuovamente la configurazione. In sostanza il client affitta il suo indirizzo di rete per un determinato periodo di tempo.
Il processo per la configurazione di un client tramite DHCP avviene in quattro fasi:
1. Il client invia sulla rete un messaggio in broadcast (in quanto non conosce l'indirizzo del server) chiamato DHCPDISCOVER. Questo messaggio proverrà quindi da 0.0.0.0 e come destinazione avrà 255.255.255.255. Il messaggio DHCPDISCOVER contiene anche l'indirizzo MAC (univoco) della macchina che fa la richiesta.
2. Il server DHCP che riceve la richiesta invia in risposta un messaggio chiamato DHCPOFFER contenente un indirizzo selezionato dallo SCOPE e l'indirizzo MAC del client che ne ha fatto richiesta per far sì che l'offerta giunga al client corretto.
3. Il client, invia ora un messaggio DHCPREQUEST in broadcast indicando che ha accettato l'indirizzo IP offerto.
4. Infine il server DHCP invia un messaggio DHCPACK (ACKnowledgment) che conferma al client l'assegnazione dell'indirizzo con il relativo tempo di lease ed invia anche i vari parametri opzionali.
Nel caso in cui il server è impossibilitato ad assegnare la configurazione richiesta dal client invia un messagggio di tipo DHCPNACK (Negative ACKnowledgment) il quale indica che è necessario ripetere tutti i passi per ottenere una nuova configurazione.
Esempio che è possibile trovare nei log di un DHCP server Linux:
Joker dhcpd: DHCPDISCOVER from 00:48:54:6e:b0:4d (Enigma) via eth0
La macchina Joker (DHCP Server) riceve la richiesta da Enigma (DHCP Client) con MAC Address 00:48:54:6e:b0:4d
Joker dhcpd: DHCPOFFER on 192.168.0.100 to 00:48:54:6e:b0:4d (Enigma) via eth0
Joker offre a Enigma, identificato tramite il MAC 00:48:54:6e:b0:4d, l'indirizzo 192.168.0.100
Joker dhcpd: DHCPREQUEST for 192.168.0.100 (192.168.0.2) from 00:48:54:6e:b0:4d (Enigma) via eth0
Enigma accetta e richiede l'indirizzo 192.168.0.100
Joker dhcpd: DHCPACK on 192.168.0.100 to 00:48:54:6e:b0:4d(Enigma) via eth0
Joker assegna ad Enigma l'indirizzo richiesto
Il rinnovo DHCP avviene in tre fasi:
1. Ogni volta che il client DHCP viene riavviato, se il tempo di lease non è scaduto, viene richiesta la conferma per la configurazione corrente tramite uno scambio di messaggi DHCPREQUEST e DHCPACK.
2. Quando è trascorso il 50% del tempo di lease il client DHCP invia messaggio al server DHCP per rinnovare la configurazione in uso. Se il server riceve il messaggio ed è disponibile al rinnovo invia un messaggio DHCPACK con i parametri, altrimenti il client utilizza i proprio valori fino alla scadenza del lease.
3. Quando è trascorso l'85% del tempo di lease il client DHCP invia in broadcast una richiesta DHCP per rinnovare la configurazione. Se il DHCP server che aveva precedentemente concesso la licenza riceve il messaggio, la rinnova, altrimenti viene inviato un DHCPNACK e quindi il client dovrà ripetere le quattro fasi iniziali.
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-06-04 10:30:27
L'assegnazione degli indirizzi e la configurazione dei client di rete in modo dinamico è offerta, su un sistema GNU Linux, dal server dhcpd sviluppato dall'ISC (Internet Software Consortium). Dhcpd utilizza due principali file di configurazione dhcpd.conf per la configurazione e dhcpd.leases coma database dei lease.
Il server dhcp, viene solitamente fatto partire tramite gli script di avvio del sistema, la sua sintassi è la seguente: dhcpd [opzioni] [interfacce]
Tra le opzioni principali abbiamo:
-p numero porta UDP
: permette cambiare la porta di listening, di default è la 67;
-cf file di configurazione
: permette di definire un file di configurazione alternativo a quello predefinito;
-lf file di lease
: permette di definire un file alternativo a quello predefinito contenente le informazioni relative agli indirizzi IP rilasciati;
-q
: non stampa i messaggi di copyright all'avvio del servizio;
-d
: utile per il debug, visualizza i messaggi del server sullo standard error anzichè essere come di default essere loggati da syslog.
-t
: testa solamente la correttezza sintattica del file di configurazione dhcpd.conf;
-T
: testa solamente la corretteza del file di database dhcpd.leases;
Di default dhcpd si mette in in ascolto su tutte le interfacce che supportano il multicast (ovvero dove è possibile trasmettere pacchetti all’indirizzo IP 255.255.255.255), altrimenti con la relativa opzione è possibile specificare al server su quali mettersi in ascolto ignorando le altre.
LINK: ISC Dynamic Host Configuration Protocol (DHCP) - http://www.isc.org/products/DHCP/
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-06-04 10:31:00
E' il database in cui vengono registrati gli indirizzi affittati da dhcpd ai client. Per ogni indirizzo rilasciato in lease viene accodata una voce a questo file. La sua posizione nel sistema può variare a seconda della distribuzione Linux.
E' un file ASCII, che non deve essere editato a mano e contenente tutte le informazioni necessarie al server riguardante il rilascio, il rinnovo e le scadenze dei lease. Dhcpd.leases deve esistere, anche se vuoto prima dell'avvio del demone dhcpd. E' possibile crearlo velocemente tramite il comando touch dhcpd.leases
.
Per evitare che il database di lease cresca eccessivamente, periodicamente, dhcpd.leases viene ricreato eliminando le voci scadute, mentre una copia di backup è salvata con il nome dhcpd.leases~
. In caso di crash del server prima che un file dhcpd.leases valido sia stato scritto su disco è possibile ripristinare il servizio rinominando dhcpd.leases~ in dhcpd.leases.
Il file di database presenta una forma strutturata, per ogni voce è presente l'indirizzo ip rilasciato e tra parantesi
graffe le relative dichiarazioni. Un esempio di voce aggiunta al file database è il seguente:
lease 192.168.0.80 { Ip rilasciato in affitto
starts 5 2003/04/11 18:37:21; Rilascio del lease (tempo GMT)
ends 1 2003/04/14 18:37:21; Scadenza del lease (tempo GMT)
binding state active;
next binding state free; Lo stato di binding attuale e lo stato successivo ovvero alla scadenza del lease
hardware ethernet 00:48:54:6f:2b:e6; Tipo (in questo caso ethernet) e MAC address dell'interfaccia che ha ricevuto l'indirizzo
uid "\001\000HTo+\346"; Identificativo del client
client-hostname "Apollo13"; Nome del client che ha ricevuto in affitto l'indirizzo
}
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2003-05-15 18:17:54
E' il file contenente la configurazione del server DHCP (ISC) che viene letto all'avvio del servizio. In caso si decida di apportare variazioni al funzionamento del server è necessario arrestare e riavviare dhcpd affinchè dhcpd.conf venga riletto.
Un esempio di configurazione:
#
# Configurazione parametri Globali
#
ddns-update-style ad-hoc; Opzione riguardante il metodo di aggiornamento dinamico del Domain Name System
option subnet-mask 255.255.255.0; Definizione della maschera di sottorete
option broadcast-address 192.168.0.255; Definizione indirizzo di broadcast per la rete
default-lease-time 259200; Il tempo di lease è quantificato in 3 giorni
max-lease-time 518400; Il tempo massimo per cui il client può utilizzare l'indirizzo affittato è quantificato in 6 giorni
option routers 192.168.0.1; Indicazione del router che fa da gateway verso Internet o altre reti
option domain-name-servers 212.216.112.112, 212.216.172.62; Specifica i server DNS per la risoluzione degli indirizzi
option domain-name "Zeta.net"; Definizione nome di dominio della rete
# Configurazione delle Subnet
subnet 192.168.0.0 netmask 255.255.255.0 { Definizine della subnet da configurare
range 192.168.0.3 192.168.0.50; Definizione di un primo intervallo di indirizzi da affittare
range 192.168.0.100 192.168.0.150; Definizione di un secondo intervallo di indirizzi da affittare
# Configurazione Gruppi Host
group {
option routers 192.168.0.2;
option subnet-mask 255.255.255.0;
option domain-name-servers 195.130.224.18;
Ridefinizione di alcuni parametri globali in modo
specifico per il gruppo di host elencati all'interno del blocco group
host plutone { Identificazione dell'host da configurare
option host-name "Plutone.Zeta.net"; Assegnamento del nome Host
hardware ethernet 00:A0:78:8E:9E:AA; Identificazione tramite Mac Address della scheda di rete
fixed-address 192.168.0.51; Assegnamento di un IP fisso
}
host saturno {
option host-name "Saturno.Zeta.net";
hardware ethernet 00:48:54:6E:B0:4D;
fixed-address 192.168.0.52;
}
}
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-06-04 10:29:33
La configurazione di un DHCP Server ISC avviene attraverso un file di configurazione strutturato in maniera particolare, la cui conoscenza è fondamentale per sfruttarne a pieno le caratteristiche.
La configurazione del server si basa sul file /etc/dhcpd.conf
, un file di testo, composto da istruzioni la cui sintassi è di tipo case insensitive e all'interno del quale è possibile lasciare linee vuote o inserire commenti i quali devono iniziare con il carattere #.
La struttura del file, ricorda dal punto di vista sintattico il linguaggio C, in quanto sono presenti blocchi di istruzioni, e istruzioni annidate, tra parantesi graffe. In particolare si possono individuare due categorie di istruzioni, i parametri (parameter statements) e le dichiarazioni (declaration). Mentre i parametri definiscono in che modo si deve comportare il server, le dichiarazioni vengono utilizzate per descrivere la topologia della rete.
La struttura del file è la seguente:
parametro valore;
parametro valore;
...
dichiarazione {
parametro valore;
...
sotto-dichiarazione {
parametro valore;
...
}
}
Le istruzioni in testa al file, al di fuori di ogni dichiarazione rappresentano i parametri globali. Essi sono validi in ogni sottorete utilizzata salvo una loro ridefinizione all'interno di successive direttive di dichiarazione. Le istruzioni all'interno di un blocco definito da parentesi graffe { } sono valide solamente per quel blocco in relazione all'oggetto (sottorete, host, gruppo di host ecc.) che definiscono.
Le direttive di dichiarazione sono:
subnet ip netmask sottorete {
: definisce la sottorete per la quale applicare i parametri definiti;
[parametro] valore;
}
shared-network nomerete {
: è utilizzata per il raggruppamento della configurazione di più sottoreti, in particolare quando si definiscono più sottoreti che condividono la medesima rete fisica;
[parametro] valore;
dichiarazione {
...
}
}
group {
: permette di definire un gruppo di host che hanno parametri di configurazione comune;
[parametro] valore;
}
La direttiva subnet riveste un particolare importanza perchè è la minima unità di informazione da inserire nel file dhcpd.conf. Senza la specificazione di almeno una subnet con un range di indirizzi validi non è possibile avviare il server.
Tra i parametri di configurazione più utilizzati abbiamo:
default-lease-time
secondi: definisce la durata della configurazione per l'interfaccia di rete;
max-lease-time
secondi: definisce il tempo massimo per la durata della configurazione per l'interfaccia di rete;
range indirizzo
ip iniziale indirizzo ip finale: definisce il pool di indirizzi utilizzabili da rilasciare ai client;
option subnet-mask
subnetmask: definisce la maschera di sottorete;
option broadcast-address
indirizzo di broadcast: definisce l'indirizzo di broadcast;
option routers
indirizzo ip del router: definisce l'indirizzo ip del gatway predefinito;
option domain-name-servers
indirizzo dns: definisce l'indirizzo ip del/dei server DNS;
option domain
nome dominio: definisce il nome di dominio della rete
Sotto la directory /usr/doc/
dell'applicazione è possibile trovare un esempio di dhcpd.conf.
Tipo Infobox: ETCETERA - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2005-06-21 16:40:33
Configurazione dinamica indirizzo di rete in ambiente Windows XP e possibili alternative.
Per fare in modo che all'avvio il sistema acquisisca tramite il protocollo DHCP l'indirizzo di rete, è necessario impostare il radio button "Ottieni automaticamente un indirizzo IP" nel tab Generale della scheda Protocollo Internet TCP/IP. Per fare questo è possibile cliccare con il tasto destro su Risorse di rete, scegliere Properietà, quindi Connessione alla rete locale (LAN) poi cliccare nuovamente con il tasto destro e scegliere ancora Proprieta'.
CONFIGURAZIONE ALTERNATIVA
E' possibile configurare Windows XP in modo da utilizzare un indirizzo IP a scelta dell'amministratore della macchina qualora il DHCP Server di rete non risulti disponibile. Anche in questo caso, è necessario aprire le proprietà di Protocollo Internet TCP/IP in cui è possibile trovare il tab Configurazione Alternativa il quale permette di impostare un indirizzo IP privato a propria scelta.
Le modifiche in oggetto devono essere effettuare con i privilegi di Administrator.
Installazione e gestione di BIND |
Installazione di BIND tramite RPM e sorgenti, file installati e posizioni. Gestione del servizio. |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-06-04 10:31:51
BIND, acronimo di Berkeley Internet Domain Name, è sviluppato e mantenuto dalla ISC, Internet Software Consortium (http://www.isc.org/products/BIND/).
BIND è un pacchetto software composto principalmente da:
- Un Domain Name Service server chiamato named.
- Una libreria per la risoluzione dei nomi.
- Alcune utility di configurazione e dei tool per la gestione del servizio (rndc, named-checkconf).
Attualmente la versione più recente è la 9.2.2 (marzo 2003).
Premesso che la maggioranza delle distribuzioni Linux permette l'installazione e l'aggiornamento del pacchetto attraverso sistemi binari (rpm per RedHat, Mandrake o Suse, deb per Debian) può essere utile all'amministratore di sistema, vuoi per abilitare qualche feature in fase di compilazione o perchè la versione presenta qualche baco, scaricare il pacchetto dei sorgenti.
Questo può essere fatto tramite l'immenso network di sourceforge/freshmeat.net o direttamente dal sito ufficiale.
Una volta scaricato e scompattato il pacchetto si può procedere alla compilazione con il classico:
./configure
make
Ci sono diverse variabili settabili al momento del lancio di configure, vediamo le principali:
--with-libtool
: per abilitare l'uso delle shared library.
--with-openssl
: per abilitare l'uso della crittografia per l'autenticazione sicura (DNSSEC), nel caso openssl fosse installata in un path diverso da quello standard, si può specificare con:
--with-openssl=/prefix
--enable-libbind
: per abilitare l'uso delle librerie libbind di BIND versione 8, visto che attualmente le librerie di BIND 9 sono ancora considerate in sviluppo, può essere interessante l'uso di quelle meno recenti ma più stabili.
--enable-threads
o --disable-threads
a seconda se la nostra macchina è multiprocessore o no, notare che configure dovrebbe verificare da solo questa variabile, è utile avere la possibilità di specificarla.
--prefix=/...
: di default named viene installato in /usr/local
con questa variabile si può specificare un'altra directory.
--sysconfdir
: permette di specificare un'altra directory dove installare il file di configurazione (named.conf) diversa da quella standard /etc
.
--localstatedir
permette di specificare una directory diversa dallo standard /var per run/named.pid
.
NOTA BENE: se si specifica la variabile --prefix
questa modifica anche i valori standard delle ultime due variabili descritte che diventeranno:
$PREFIX/etc/named.conf
e $PREFIX/var/run/named.pid
Di norma quindi se si specifica la variabile --prefix
va ricordato di specificare anche le altre due.
Ad ogni modo se si vuole avere un prospetto completo di tutte le opzioni del configure si usa:
./configure --help
Si procede ad installare il pacchetto con:
make install
SOURCE: Sito dell'Internet Software Consortium - http://www.isc.org/products/BIND/
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-06-04 10:32:44
Il pacchetto BIND dalla versione 9.x.x contiene l'utility rndc per la gestione e controllo del servizio. Rndc comunica con il named attraverso una connessione TCP inviando comandi autenticati tramite una signature digitale.
In caso si stesse utilizzando BIND 8.x.x il suo corrispettivo tool si chiama ndc e ha poche differenze con l'attuale rndc.
Se si desidera utilizzare rndc per gestire il named bisogna innanzi tutto lavorare sul file di configurazione /etc/named.conf
e su /etc/rndc.conf
.
Esiste un comodo tool per creare un rndc.conf e si chiama rndc-confgen
, questa utility ha diverse opzioni per le quali rimando alla sua pagina del manuale in linea Unix.
Lanciando come root il comando senza opzioni si ottiene sullo standard output (quindi facilmente ridirezionabile ad un file) una serie di direttive da aggiungere poi a mano nei rispettivi file di configurazione:
bash-2.05a# rndc-confgen
# Start of rndc.conf
key "rndc-key" {
algorithm hmac-md5;
secret "m7Umc6qeKl1Q0eeMjVSq0g==";
};
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
# End of rndc.conf
# Use with the following in named.conf, adjusting the allow list as needed:
# key "rndc-key" {
# algorithm hmac-md5;
# secret "m7Umc6qeKl1Q0eeMjVSq0g==";
# };
#
# controls {
# inet 127.0.0.1 port 953
# allow { 127.0.0.1; } keys { "rndc-key"; };
# };
# End of named.conf
Una volta editato i due file rndc.conf
e named.conf
mantenendo queste direttive così come sono avremo la possibilità di utilizzare rndc solo da locale, dall'host cioè che fornisce il servizio named.
Per utilizzare rndc da remoto sarà importante cambiare la direttiva controls
in modo che rispecchi la nostra configurazione di rete e sarà necessario avere sulla macchina amministrativa un rndc.conf con la giusta chiave. Lo scambio di questo secret può avvenire in diversi modi, via email o via telefono, è importante ricordare che chiunque conosca la shared-key sarà ammesso al canale di controllo di named con ovvie ripercussioni sulla sua sicurezza, la chiave quindi va custodita con cura e non bisogna scordare che i file di configurazione devono essere leggibili da un ristretto gruppo di utenti "trusted".
La sua sintassi è la seguente:
rndc [opzioni] [comandi]
Vediamo ora le principali opzioni di rndc:
-c config_file
: permette di specificare un diverso file di configurazione dallo standard /etc/rndc.conf
.
-k key_file
: permette di specificare un diverso key_file dallo standard /etc/rndc.key
che verrà utilizzato per autenticare i comandi inviati al server in caso un rndc.conf
non sia presente (per approfondimenti leggere il manuale in linea unix di rndc-confgen
).
-s server
: permette di specificare un server a cui inviare i comandi. Se usata questa opzione sovrascrive la direttiva default-server
di rndc.conf
.
-y key_id
: rndc generalmente va a cercare nel file di configurazione del named l'istanza che identifica la chiave da usare per il sign delle comunicazioni. Questa opzione permette di specificare la chiave che si desidera utilizzare.
Per la gestione del server DNS rndc accetta vari comandi:
halt
: Ferma immediatamente il servizio DNS.
querylog
: Abilita il logging delle query che il named riceve dai suoi clienti.
refresh
: Fa effettuare al named un refresh dei suoi file di zona.
reload
: Simile al refresh permette di far rileggere al named i file di zona senza però fargli "pulire" la cache. In più accetta come parametro il nome del singolo file di zona evitando così di oberare il server nella lettura di file che non hanno subito cambiamenti. La sintassi così è: rndc reload file_di_zona
stats
: Esegue un dump delle statistiche attuali del server nel file /var/named/named.stats
.
stop
: Ferma il server in maniera "pulita" perchè permette al server di salvare ogni dynamic-update o qualunque dato IXFR prima di uscire.
restart
: Fa ripartire il server facendogli salvare tutti i dynamic-update e i dati IXFR e facendogli rileggere tutti i suoi file compreso il named.conf
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-05-16 15:18:46
Il server DNS di BIND è un demone chiamato named, il quale è principalmente gestito attraverso il suo file di configurazione ma supporta diverse opzioni direttamente dalla riga di comando.
Lanciato senza invocare alcuna opzione, named legge il suo file di configurazione, i relativi file di zona e resta in ascolto delle query.
Le sue opzioni non sono molte ma spesso vitali per aggiungere alcuni parametri di funzionamento non specificabili nel suo file di configurazione.
La sua sintassi è: named [opzioni]
Opzioni:
-c file_alternativo
: Permette di indicare al named un file di configurazione diverso da /etc/named.conf
. Per garantire che named rilegga correttamente il file dato dopo che ha cambiato la directory di lavoro come specificato con l'opzione directory
del file di configurazione bisogna specificare il PATH assoluto per il file.
-d valore
: Abilita il debug_mode. Va specificato il valore di verbosità del debug, un numero più alto indica messaggi di debug più accurati.
-f
: Fa girare il server in foreground.
-g
: Fa girare il server in foreground e invia tutti i messaggi di errore allo standard error (stderr).
-n #cpus
: Specifica il numero di cpu presenti sulla macchina. Questo fa creare tante threads quante che sono le cpu. Se non specificato named cerca di capire quante cpu sono presenti e attiva tanti processi quante cpu. Se non riesce crea un'unica thread per lavorare.
-p
: Permette di specificare una porta diversa dalla default 53 da usare per restare in ascolto delle query.
-s
: Stampa a monitor le statistiche dell'uso della memoria e poi esce. Questa opzione è intesa per l'uso da parte dei programmatori e verrà presto eliminata.
-t directory
: Fa cambiare directory "root" del processo (chroot()
) prima che venga letto il file di configurazione. E' intesa per l'uso associato con l'opzione -u
perchè constringere un processo ad una determinata directory non ha effetto se questo gira con i permessi di root che come si sa non ha limiti all'interno del file system.
-u user_id
: Cambia l'utente proprietario del processo dopo che aver eseguito quelle operazioni che richiedono i privilegi dell'utente root. Molto importante ai fini della sicurezza garantisce che in caso di compromissione del servizio non ci siano i privilegi per danneggiare ulteriormente il sistema.
-v
: stampa la versione del programma e esce.
SOURCE: Pagina del manuale in linea -
Configurazione di BIND |
Configurazione di BIND - In particolare la versione 9.x |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-05-14 19:17:43
La configurazione di bind, versione 9.x.x viene gestista dal file named.conf generalmente posto in /etc
o in /etc/bind
. Questo file che è un normale file di testo ASCII contiene direttive e commenti. Specifica inoltre i file delle zone e la loro ubicazione nel filesystem.
Per un elenco completo delle direttive utilizzabili (ne esistono realmente tante) e dei loro valori di default consultare il manuale ufficiale di BIND, generalmente posto in /usr/doc
o /usr/share/doc
. Le principali distribuzioni personalizzano la posizione di questi file, rivolgersi alla documentazione della propria distribuzione per la loro localizzazione.
Molti parametri possono essere lasciati al loro valore di default ma è bene specificare i più importanti anche perchè possono essere vitali ai fini della sicurezza del servizio.
Da ricordare: Ogni direttiva termina con un ";
". Tra parentesi graffe si inseriscono le direttive relative ad una direttiva principale. I commenti sono gli stessi che si utilizzano in linguaggio C, "//
"per aprire e chiudere o "/*
" per aprire e "*/
" per chiudere.
Vediamo le direttive principali e la loro sintassi:
acl: Access Control List. Questa direttiva permette di assegnare un nome arbitrario ad un determinato range di indirizzi per facilitarne poi la loro gestione in altre specifiche del named.conf.
La sua sintassi è la seguente:
acl nome-acl {
lista_di_indirizzi
};
Da notare: La acl e il suo rispettivo range di indirizzi va definito all'interno del file prima che possa essere utilizzata in qualunque altra direttiva. In sostanza named legge il suo file di configurazione dal principio alla fine e non ha la capacità di fare l'inverso.
Alcune acl sono implementate di default:
any: Tutti gli host.
none: Nessun host.
localhost: Corrispondenza per l'host locale.
localnets: Corrispondenza per ogni host presente nella rete in cui named è in ascolto.
controls: Permette la definizione di un canale usato dal system administrator per gestire il servizio. Questi canali sono principalmente usati dall'utility rndc per inviare comandi al server.
controls {
inet ( indirizzo_ip | * ) [ port numero_porta ] allow { acl }
keys { lista_chiavi };
};
key: Definisce una chiave segreta per l'autenticazione mediante signature (TSIG, DNSSEC) viene detta shared perchè è condivisa dal server e delle applicazioni che ne fanno uso.
key nome_chiave {
algorithm stringa;
secret stringa;
};
Il nome della chiave è arbitrario, va poi ovviamente ripetuto uguale in tutte le direttive che lo richiedono.
La direttiva algorithm in teoria potrebbe essere di tipo qualunque ma attualmente (BIND 9.2.2, marzo 2003) named supporta esclusivamente hmac-md5
.
La direttiva secret specifica una stringa a 64 bit utilizzata da algorithm per il signing delle connessioni.
include: Permette di definire un file esterno da cui estrapolare ulteriori direttive.
include nome_del_file;
Può essere utile nel caso in cui si ha necessità di dare l'accesso in lettura al named.conf a un gruppo di utenti ma non si vuole che la secret key sia accessibile. Si specifica così il parametro key
in un file esterno non leggibile e lo si "include" nel named.conf.
option: Sarebbe necessario redarre un how-to separato per descrivere tutte le opzioni possibili che sono numerosissime, rimando ancora alla documentazione ufficiale inclusa col pacchetto named per un'overview più dettagliata.
La sintassi è:
option {
directory /var/named;
listen-on { indirizzo_interfaccia; };
ulteriori opzioni ...;
};
Nel campo option si fanno rientrare numerose direttive:
directory: Specifica la directory di lavoro di named. Se non dichiarata named userà la directory da cui viene lanciato. Di norma si indica la directory dove si trovano i file di zona. Uno standard comune è che sia /var/named
ma non è obbligatorio.
pid-file: Si usa se si vuole utilizzare una directory differente dalla default /var/run
per salvare il pid-file. Named quando parte avvia più di un processo, il pid-file è usato da alcune applicazioni per conoscere il numero del processo "parente" quello cioè che ha poi generato gli altri processi "figli".
port: Serve a specificare una porta udp/tcp diversa dalla standard 53. E' inteso per l'utilizzo nei test di debug visto che un server che lavora su una porta diversa dalla 53 sarà completamente impossibilitato a comunicare con il resto del Domain Name System globale.
notify: Questa opzione ha una sintassi definibile come "booleana" in quanto accetta parametri come yes o no. Serve a impedire o permettere che il server notifichi i cambiamenti dei suoi file di zona ai server presenti nel record di risorsa NS e ai server specificati con l'opzione also-notify. Può essere specificato anche come opzione per singolo file di zona. Il suo valore di default è yes.
recursion: Anch'essa di sintassi booleana, se posta come yes il server cercherà di elaborare una risposta ad una query del client anche se non presente nella sua cache. Notare che se posta come no non impedisce ai client di ottenere una risposta dalla cache del servizio, l'unica cosa sarà che non vi saranno aggiunte nella cache in seguito a query dei clients. Il suo valore se non specificato è yes. Questa opzione può difendere il named da attacchi tipo DNS-poisoning che utilizzano la funzione di recursive quering.
forwarders: Con questa opzione posso definire gli indirizzi di altri server DNS ai quali il named si appoggerà per le risposte a query di cui non ha autorità e solitamente si definiscono i DNS del proprio Internet Service Provider. Di norma quando il server non ha la risposta in cache si appoggia ai root servers a meno che non si sia specificata questa opzione, in questo caso si possono tranquillamente eliminare i riferimenti alla zona radice "." nel named.conf.
forward: Serve a specificare la policy da usare in caso una richiesta non autoritativa non sia presente nella cache e si siano specificati dei forwarders. I suoi parametri sono first e only.
allow-notify: Permette di specificare una lista di indirizzi (o anche una precedentemente definita acl) a cui è permesso notificare i cambiamenti di un file di zona. Può essere specificata come opzione di una singola direttiva di zona e in tal caso sovrascrive la direttiva globale.
allow-transfer: Permette la specifica di una lista di indirizzi (o una acl) a cui è concesso effettuare un trasferimento di zona. Può essere specificato per un singolo file di zona e in tal caso sovrascrive l'opzione globale.
allow-recursion: Specifica la lista di indirizzi o l'eventuale acl ai quali è concesso effettuare query ricorsive. Si ricordi che non permettere ad un host di avere risposte a query ricorsive non impedisce che le ottenga se presenti in cache.
listen-on: Quando viene lanciato il named si mette in ascolto su tutte le interfacce disponibili per cui se un host ha tre schede di rete e quindi tre indirizzi ascolterà su tutti e tre più la loopback. Con questa opzione si può dire a named su quali indirizzi ascoltare e su quali no. Non si può specificare il nome dell'interfaccia (es. eth0) ma si deve usare il suo indirizzo IP.
Per finire il named.conf contiene le direttive dei file di zona che altro non sono che la loro dichiarazione e l'associazione al corrispettivo file del database DNS.
La sintassi è la seguente:
zone "db.esempio" {
type master;
file "/var/named/db.esempio";
};
Dove zone è la dichiarazione per la zona la quale comprende l'opzione type che ne identifica il tipo, master o slave, e l'opzione file che indica dove si trova il corrispettivo file del database.
Occorre che vi sia una direttiva per ogni file di zona più la specifica per la zona radice e una per i record PTR di localhost.
Dichiarazione per la zona radice:
zone "." IN {
type master;
file "/var/named/root.hint";
};
Dichiarazione per localhost:
zone "0.0.127.in-addr.arpa" IN {
type master;
file "/var/named/127.0.0.db";
};
Come già detto la direttiva per la zona radice può essere omessa nel caso in cui si sia specificata l'opzione forwarders. Il file root.hint è il file contenente le informazioni sui server radice del sistema DNS, potrebbe essere il caso di aggiornarlo ed è recuperabile all'indirizzo ftp://ftp.rs.internic.net.
SOURCE: Documentazione acclusa al pacchetto BIND. -
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-05-23 14:48:01
Il file di gestione principale per la configurazione di Bind può essere molto diverso a seconda del tipo di server che si intende implementare.
La sua posizione standard è nella directory /etc
ma talvolta alcune distribuzioni lo collocano in /etc/bind/
. Se si compila dai sorgenti si può decidere dove collocarlo con il flag --sysconfdir
.
Vediamo un esempio per un server caching-only o recursive che dir si voglia, un server che non è autoritativo per domini pubblici e demanda la risoluzione dei nomi ai server dell'Internet Service Provider mantenendo una cache dei record richiesti diminuendo il traffico di rete e i tempi di query DNS.
In fondo alla configurazione sono presenti degli esempi per delle zone relative alla rete locale in cui si trova il server.
acl "local" { 192.168.0.0/24; };
Definire una acl è una cosa che facilita parecchio la gestione del file di configurazione anche se non è obbligatoria, è comoda nel caso il server si trovi in una rete complessa e si abbia da configurare gli accessi in modo fine..
key rndc-key {
algorithm hmac-md5;
secret "fFh4kjMNL=\spI";
};
Dichiarazione di una shared key. La stessa stringa dovrebbe trovarsi anche all'interno dell'rndc.conf per permettere la gestione sicura mediante autenticazione degli accessi. Si possono specificare più chiavi per diversi tipi d'uso o avvalersi solo di una chiave per tutte le operazioni.
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
inet 192.168.0.1 port 953
allow { local; } keys { rndc-key };
};
Definizione di un canale per le comunicazioni amministrative con il server. In questo caso con inet si stabilisce la socket TCP di ascolto e la sua porta il cui valore di default è 953. Nel secondo caso il canale di controllo è settato per restare in ascolto sull'interfaccia con indirizzo 192.168.0.1. Con allow definisco invece chi è autorizzato a collegarsi al canale di controllo in questo caso da localhost e dagli host appartenenti alla acl "local" a patto che abbiano la definizione della chiave rndc-key nel rndc.conf.
options {
directory "/var/named/";
pid-file "/var/named/run/named.pid";
forwarders { DNS1_ISP; DNS2_ISP; };
DNS1_ISP e DNS2_ISP vanno sostituiti con gli indirizzi IP dei server DNS a cui il nostre server rivolgerà tutte le richieste
#forward first;
In questo caso è inserito un commento perchè forward first è il valore di default. Se invece si specifica forward only
o forward-only
si impedisce ogni query del nameserver a DNS diversi dai forwarders.
listen-on { 127.0.0.1; 192.168.0.1; };
Stabilisce gli indirizzi ip delle interfacce presenti sul server in cui si deve porre in ascolto per delle richieste, in questo caso esclusivamente sulla rete locale e la loopback. Se non specificato di default ascolterà su tutte le interfacce disponibili.
query-source address * port 53;
Con una wildcard * definisco gli indirizzi delle interfacce che named userà per rivolgere le richieste che non hanno ancora un record nella cache e definisco che utilizzi la porta 53. Questo è utile nel caso il server si trovi dietro un firewall che filtra i pacchetti UDP anche se non è valido per quanto riguarda le operazioni che implicano l'uso del TCP in cui usa sempre una porta casuale tra la 1024 e la 65535.
allow-query { 127.0.0.1; "local"; };
listen-on-v6 { "none"; };
notify no;
};
Stabilisce il comportamento del server in caso di cambiamenti nei file di zona di default è yes e che nel caso di un server cache-only non serve visto che non comunica con altri nameserver fuorchè i suoi forwarders.
//zone "." in {
// type hint;
// file "named.root";
//};
In questo caso è commentato vista la presenza dell'opzione forwarders non è più necessario che il nameserver utilizzi i server del dominio radice per le richieste non presenti in cache. Questo è fattibile per la verità solo se si specifica forward-only
perchè altrimenti se i forwarders non hanno la risposta o comunque tardano a rispondere di default named interpellerà i DNS del dominio radice.
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.db";
};
Si definisce la zona per la risoluzione inversa di "localhost". Notare che non necessita del flag IN perchè la loopback è in realtà una rete virtuale che nulla ha a che vedere con Internet.
zone "0.168.192.in-addr.arpa" IN {
type master;
file "192.168.0.db";
};
Occorrenza per il file incaricato della risoluzione inversa per la rete 192.168.0.0/24
zone "local" IN {
type master;
file "local";
};
Va definita per indicare al nameserver che la zona local non contiene nessun record.
zone "esempio.local" IN {
type master;
file "esempio.local";
};
Definisce il file dei nomi di dominio per la rete esempio.local
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-05-21 18:42:11
Vediamo la configurazione di un server DNS autoritativo: primario (master) per la zona esempio.com e secondario (slave) per la zona extra.esempio.com.
acl "slaves" { numero_ip_slave1; numero_ip_slave2; };
Definisco una acl per i server slave del master per la zona esempio.com
key rndc-key {
algorithm hmac-md5;
secret "fFh4kjMNL=\spI";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
In questo caso il canale di controllo è posto solo sulla loopback. Resta comunque valida l'ipotesi di inserire una acl che stabilisca quali host amministrativi hanno accesso.
logging {
channel security_info {
file "/var/log/named-auth.log";
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
category security { security_info; };
};
Abilito il log per i messaggi della categoria security nel file /var/log/named-auth.log e faccio in modo che salvi i messaggi dalla priorità info in su stampando il tipo, la severità e l'ora.
options {
directory "/var/named/";
pid-file "/var/named/run/named.pid";
query-source address * port 53;
allow-query { any; };
listen-on-v6 { "none"; };
recursion no;
};
In questo caso l'opzione allow-query è settata in modo globale ma va ricordato che è preferibile inserirlo come direttive per singolo file di zona e nel nostro caso per la zona su cui ha autorità il server, esempio.com. Specificando "recursion no" disabilito la possibilità che richieste ricorsive vengano processate dal server.
zone "." in {
type hint;
file "named.root";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.db";
notify no;
};
Disabilito la notifica alla zona dell'host locale
zone "1.168.192.in-addr.arpa" IN {
type master;
file "192.168.1.db";
allow-transfer { "slaves"; };
};
Specifica per la risoluzione inversa della zona esempio.com
zone "0.0.10.in-addr.arpa" IN {
type slave;
file "10.0.0.db";
masters 10.0.0.54
};
Specifica per la risoluzione inversa della zona extra.esempio.com, indicando 10.0.0.54 come server DNS primario
zone "esempio.com" IN {
type master;
file "esempio.com.db";
allow-transfer { "slaves"; };
};
Specifica per la zona su cui il server ha autorità e di cui solo gli host presenti nella acl "slaves" hanno il permesso di eseguire un trasferimento di zona
zone "extra.esempio.com" IN {
type slave;
file "extra.esempio.com.db";
masters 10.0.0.54
};
Specifico l'indirizzo del server master per la zona extra.esempio.com
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-05-23 21:25:17
Vista la struttura e la sintassi del named.conf passiamo ora ad analizzare i file di zona, semplici file di testo in cui si specificano le informazioni necessarie per la risoluzione dei nomi di dominio in indirizzi numerici e viceversa. Anche in questo caso si ha una sintassi specifica e alcune convenzioni da conoscere.
Vediamo in primis la struttura di un file di zona per la risoluzione dei nomi di dominio in indirizzi numerici. Questo file si vedrà essere il più importante in quanto contiene tutti i dati e i record necessari per la configurazione del dominio, del server di posta e degli alias, per citarne alcuni. Il file in questione si chiama esempio.com.db.
Per chiarezza lascerò come esempio l'intero file dopo di che mi addentrerò nella spiegazione della sua struttura.
$ORIGIN .
$TTL 172800 ; 2 days
esempio.com IN SOA ns1.esempio.com. root.ns1.esempio.com. (
2003021512 ; serial
28800 ; refresh (8 hours)
7200 ; retry (2 hours)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
NS ns1.esempio.com.
$ORIGIN esempio.com.
$TTL 3600 ; 1 hour
dhcpclient A 192.168.0.98
TXT "311e98e7bea987126c3037d1b1f4c7b99d"
$TTL 172800 ; 2 days
ns1 A 192.168.0.1
mac A 192.168.0.2
linux A 192.168.0.3
windows A 192.168.0.4
webftp A 192.168.0.5
mail A 192.168.0.6
;Aliases
www.esempio.com. CNAME webftp.esempio.com.
ftp.esempio.com. CNAME webftp.esempio.com.
win.esempio.com. CNAME windows.esempio.com.
;Definisco il mail server per il dominio
esempio.com. MX 10 mail.esempio.com.
esempio.com. MX 20 mail.nostroisp.com.
$ORIGIN .
Questo flag indica un nome di dominio che viene automaticamente appeso a tutti i nomi del file di zona che non terminano con un punto finale. In questo esempio si può vedere che sono specificate due direttive $ORIGIN. La prima va a completare la direttiva "esempio.com" mentre la seconda specifica il completamento per i nomi degli host. Alcuni la considerano obsoleta ma vale la pena conoscerla e capirne il significato.
$TTL 172800 ; 2 days
Questo campo indica il default time-to-live. Come si vede si applica globalmente a tutti i record che precedono qualunque altra direttiva di TTL, che può essere indicata anche per singolo host. Il nameserver specifica questo valore in tutte le risposte per la zona o il dato record indicando per quanto tempo gli altri nameservers possono tenerlo in cache. Se si ha un file di zona che subisce poche modifiche è consigliabile specificare un valore alto anche se è sconsigliabile superare la settimana.
esempio.com IN SOA ns1.esempio.com. root.ns1.esempio.com.
Questa è la parte principale del file di zona e serve a indicare lo Start of Authority per la zona esempio.com. In questo caso ns1.esempio.com è il nome del server autoritativo per la zona. Se ne può specificare uno solo e non di più. A seguire abbiamo un record che può creare confusione. Indica l'indirizzo del responsabile della gestione per la zona. I nameservers non utilizzaranno mai questa risorsa che è ad uso esclusivo di chi vuole comunicare con il gestore del dominio. Non si specifica l'indirizzo comune "root@ns1..." ma si deve sostituire l'@ con il punto, questo perchè la sintassi dei file di zona vuole che il simbolo @ si usi come il flag $ORIGIN. Può essere specificato un host differente da quello autoritativo ad esempio root.mail.esempio.com.
I campi chiusi tra le parentesi sono principalmente per gli slave server.
(
2003021512 ; serial
Indicazione del numero di serie. Importante aggiornarlo quando si eseguono modifiche al file per far sapere agli slave che si sono effettuati dei cambiamenti.
28800 ; refresh (8 hours)
Indica agli slave della zona ogni quanto devono verificare che i file sul master sono o meno cambiati. Va prestata attenzione al valore che si da soprattutto nel caso sia basso. Si sappia che uno slave effettua una SOA query per ogni zona ad intervalli specificati nel refresh e si tratta di una operazione molto intensiva in termini di utilizzo di CPU
7200 ; retry (2 hours)
Questo campo indica allo slave ogni quanto tempo riprovare a connettersi al master in caso un refresh non sia andato a buon fine (potrebbe essere momentaneamente down)
604800 ; expire (1 week)
Con expire indico allo slave dopo quanto tempo deve considerare una data zona non più valida. Deve necessariamente essere maggiore dei valori di refresh e di expire altrimenti considererebbe espirati i valori di una zona prima di averla caricata.
86400 ; minimum (1 day)
Questo campo è un TTL. Serve ad indicare quanto tempo un risposta negativa ad una query va tenuta dal nameserver nella cache.
)
NS ns1.esempio.com.
NS, nameserver, indica il nameserver o i nameservers autoritativi per una zona. In caso vi siano due o più DNS per una data zona vanno specificati qua.
$ORIGIN esempio.com.
$TTL 3600 ; 1 hour
dhcpclient A 192.168.0.98
TXT "311e98e7bea987126c3037d1b1f4c7b99d"
Questo record è per un host che utilizza il DHCP. Viene inserito dal server DHCP tramite update dinamico delle zone. Il campo TXT indica una stringa identificativa per il dato host ed è per uso interno al server DHCP ma può essere utilizzata per qualunque tipo di informazione si voglia specificare. In questo caso il TTL è al minimo visto che un record per un client non dotato di un indirizzo statico è soggetto a cambiamenti frequenti.
$TTL 172800 ; 2 days
ns1 A 192.168.0.1
mac A 192.168.0.2
linux A 192.168.0.3
windows A 192.168.0.4
webftp A 192.168.0.5
mail A 192.168.0.6
Questa è la parte che associa i nomi delle macchine ai loro ip. Il flag A sta per Address e indica che si tratta di record per la risoluzione da nome ad indirizzo.
;Aliases
www.esempio.com. CNAME webftp.esempio.com.
ftp.esempio.com. CNAME webftp.esempio.com.
win.esempio.com. CNAME windows.esempio.com.
Con questi campi invece definisco gli alias per alcuni host del dominio. L'esempio dimostra che è possibile assegnare più nomi ad un host. In questo caso il server web e ftp sono la stessa macchina raggiungibile sia se la si cerca come "www.esempio.com" che come "ftp.esempio.com".
;Definisco il mail server per il dominio
esempio.com. MX 10 mail.esempio.com.
esempio.com. MX 20 mail.nostroisp.com.
Con i record MX specifico quali host si occupano dell'instradamento della posta per il dominio esempio.com. Il valore numerico che segue il record MX indica la priorità. In questo caso se invio una mail ad un utente che si trova nel dominio esempio.com il mio client mail cercherà di inviare al server mail.esempio.com per primo. In caso questo fosse troppo occupato o comunque non disponibile il mio mailer si appoggerebbe a mail.nostroisp.com un server fornito dall'Internet Service Provider di esempio.com. Si possono specificare più server con lo stesso valore di priorità ed è consigliabile utilizzare valore numerici che abbiano un certo margine tra loro, questo solo per fini di comodità nell'amministrazione. Ad esempio se in questa zona si decide di implementare un nuovo mail server che poniamo sia una macchina molto potente e posta su un link molto veloce basterebbe dargli un valore di 5 o di 15 a seconda delle preferenze ma se avessimo usato valori tipo 1,2,3.. ci troveremmo obbligati a ristudiare il nostro file di zona. Se si vuole definire un server con priorità massima si può utilizzare il valore 0.
Per finire alcune note. In questo esempio si sono utilizzati valori numerici per indicare i TTL, i refresh, l'expire.. e sono posti con come unità il secondo quindi una settimana diventa 608400 secondi. Dalla versione 8 di BIND in poi si possono specificare anche con degli "argomenti" quindi 3600 secondi diventano 1h e così via si possono specificare valori di 2h35m, due ore e trentacinque minuti, 1d, un giorno, 2w, due settimane. Notare inoltre che la sintassi del file delle zone vuole che i commenti inizino con un ";". Va ricordato infine che vi sono molti record di cui non ho parlato, alcuni obsoleti altri poco usati, se si vuole averne un prospetto più chiaro fare riferimento alla documentazione ufficiale del bind.
SOURCE: DNS and BIND. isbn:0-596-00158-4 -
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-05-21 18:38:45
Abbiamo visto il file di zona per il dominio esempio.com ora vediamo il suo corrispettivo file per la risoluzione inversa. Anche questa volta lascio l'intero file disponibile per poi addentrarmi nelle sue caratteristiche.
Vediamo il file 192.168.0.db:
$TTL 2D
0.168.192.in-addr.arpa. IN SOA ns1.esempio.com. root.ns1.esempio.com. (
2003021502 ;serial
28800 ;refresh
7200 ;retry
604800 ;expire
28800 ) ;minimum
IN NS ns1.esempio.com.
1 IN PTR ns1.esempio.com.
2 IN PTR mac.esempio.com.
3 IN PTR linux.esempio.com.
4 IN PTR windows.esempio.com.
5 IN PTR webftp.esempio.com.
6 IN PTR mail.esempio.com.
Innanzi tutto occorre fare una premessa. Come si può vedere e come già trattato altre volte in questo file non ci sono in realtà riferimenti numerici bensì troviamo questo strano "in-addr.arpa".
Se volessimo cercare, conoscendo un indirizzo ip, il suo corrispettivo nome DNS il nameserver sarebbe costretto a cercare nell'intero albero DNS dal suo dominio di competenza fino alla radice per poi ridiscendere al dominio a cui appartiene l'ip eseguendo una ricerca all'interno dei file delle zone singolo record per singolo record. Come si può immaginare, visto il grande numero di indirizzi numerici esistenti, visto che molti amministratori creano subnet diverse nelle loro reti delegandole poi ad altri DNS, visto che gli indirizzi ip sono di diverse classi, privati e pubblici questo lavoro sarebbe impossibile per il DNS. In più il Domain Name Space indicizza i suoi dati, incluso quelli numerici per nome. Per questo visto che è semplice trovare le informazioni quando si fornisce il nome del dominio che mantiene i dati, gli sviluppatori hanno pensato di creare un dominio a se, che tratta gli indirizzi numerici come "etichette", in-addr.arpa. In questo modo il dominio in-addr.arpa comprenderà 256 sotto-domini i quali includeranno altri 256 sotto-domini il quale includerà altri 256 sotto-domini fino all'ultimo campo numerico di un ip che fornirà il nome di dominio completo per un dato host. La sua rappresentazione così diviene invertita, 192.168.0.1 diventa 1.0.168.192.in-addr.arpa., questo perchè si segue la relazione con il dominio radice ".". In questo modo l'indirizzo ip sarà letto correttamente nel nome di dominio.
192.168.0.1 = 1.0.168.192.in-addr.arpa. = ns1.esempio.com.
Analizziamo ora il nostro file:
$TTL 2D
0.168.192.in-addr.arpa. IN SOA ns1.esempio.com. root.ns1.esempio.com.
In questo caso il primo campo dopo il TTL poteva essere rappresentato con un @ facente riferimento all'origine specificata nella direttiva "zone" del named.conf e che viene appesa a tutti i nomi nel file che non terminano con un punto finale (
2003021502 ;serial
28800 ;refresh
7200 ;retry
604800 ;expire
28800 ) ;minimum
Questi campi hanno lo stesso significato spiegato nel file di zona "esempio.com.db".
IN NS ns1.esempio.com.
Si definisce il o i DNS autoritativi per la zona
1 IN PTR ns1.esempio.com.
2 IN PTR mac.esempio.com.
3 IN PTR linux.esempio.com.
4 IN PTR windows.esempio.com.
5 IN PTR webftp.esempio.com.
6 IN PTR mail.esempio.com.
Infine si specificano i nomi numerici delle macchine e i loro relativi nomi di dominio. Il flag PTR sta per Pointer e indica che si tratta di record per la risoluzione da indirizzo a nome. In questo esempio ho lasciato il flag IN diversamente da quanto fatto nel precedente esempio questo perchè la sua presenza, in specialmodo per i record delle macchine è implicita. Sta alla preferenza dell'amministratore e di solito lo si usa perchè si ottengono dei file più completi ed esaustivi. Come si nota ho usato solo il campo dell'ip che identifica l'host tralasciando il resto che viene automaticamente appeso ad ogni record che non termina con un punto.
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-05-31 22:09:35
Spesso succede che per necessità ci si trovi costretti a utilizzare il proprio nameserver sia per gestire le richieste della rete interna che le richieste provenienti da Internet.
Ci sono diversi modi di configurare il BIND per questo tipo di lavoro e uno dei più innovativi implementato dalla versione 9.1.x in su è l'uso dell'istruzione view.
Le views permettono di presentare una configurazione del nameserver per una comunità di host e una differente configurazione per un'altro gruppo di host. La sua sintassi è la seguente:
view "internal" {
};
Il nome che si da alla view è arbitrario e è buona norma che sia descrittivo per il tipo di lavoro che andiamo ad eseguire. Non è obbligatorio che sia quotato tra virgolette ma è consigliabile visto che si potrebbero usare nomi che collidono con direttive interne al named. Per specificare quali hosts vedono cosa e quali vedono altro si utilizza l'istruzione match-clients
view "internal" {
match-clients { 192.168.0.0/24; };
}
Volendo si può utilizzare una acl precedentemente assegnata:
acl "intranet" { 192.168.0.0/24; };
view "internal" {
match-clients { "intranet"; };
};
All'interno dell'istruzione view si possono definire molte direttive, si possono specificare le direttive per le zone, descrivere i nameserver remoti con l'istruzione server o configurare direttive key per l'uso di TSIG.
Si possono inoltre definire all'interno dell'istruzione view praticamente quasi tutte le options ricordando che sovrascriveranno ogni opzione globale precedentemente specificata per quegli host che rientrano nella direttiva match-clients
acl "intranet" { 192.168.0.0/24; };
view "internal" {
match-clients { "intranet"; };
recursion yes;
};
Vediamo ora un esempio di configurazione utilizzando le views:
acl "intranet" { 192.168.0.0/24; };
Definisco un Access Control List per gli host della rete interna
options {
directory /var/named;
pid-file /var/run/named.pid;
};
L'opzione directory può essere inclusa nella direttiva view nel caso ad esempio si abbiano molti file di zona e si voglia mantenere in directory separate i file interni e i file esterni.
view "internal" {
match-clients { "intranet"; };
Non specifico una opzione recursion perchè il suo valore di default è yes.
zone "esempio.com" {
type master;
file "esempio.com.db";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "192.168.0.db";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "esempio.com" {
type master;
file "esempio.com.db.external";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "192.168.0.db.external";
};
};
In questo caso si può notare che si utilizzano diversi file di zona per la view internal e per la external; questo non è necessariamente obbligatorio ad esempio si possono comunque utilizzare gli stessi file e definire solo chi ha la possibilità di effettuare recursive quering.
Quando ci si appresta a scrivere file di configurazione che utilizzano le direttive view bisogna prestare attenzione ad alcune regole:
Innanzi tutto l'ordine in cui si specificano le direttive, nel nostro caso per esempio se avessimo specificato prima la direttiva "external" questa avrebbe inevitabilmente occluso la direttiva interna perchè la direttiva esterna ha come match-clients chiunque.
E' importante inoltre ricordare che anche se si specifica una sola direttiva view tutte le direttive zone vanno poi specificate al suo interno.
SOURCE: DNS and BIND, isbn 0-596-00158-4 -
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-05-31 22:02:40
A meno da non acquistare dei costosi libri, la documentazione che spiega chiaramente come far si che il DHCP aggiorni i file di zona del DNS è realmente scarna e criptica.
Vediamo brevemente cosa si deve fare dal lato named per prepararlo a questo tipo di aggiornamenti.
Un server DHCP per comunicare con named e fargli aggiornare i file di zona utilizza il DNS Dynamic Update. Se si vuole approfondire l'argomento la request for comments interessata è la rfc 2136. Questo è disponibile dalla versione 8 del BIND e superiori, in precedenza non si era prevista questa funzione visto che si considerava il DNS un database per dati statici e che subivano pochi cambiamenti tranquillamente gestibili a mano dall'amministratore. Con l'ingrandirsi delle reti e l'ampiamento dell'uso di sistemi per l'assegnazione automatica degli ip si è reso necessario trovare uno strumento in grado di tenere traccia di questi cambiamenti, di inserire nuovi records e di cancellarli.
Qui vedremo quali direttive si rendono necessarie nel named.conf per implementare l'update dinamico di un server DHCP presente sulla stessa macchina.
key DHCP_UPDATER {
algorithm HMAC-MD5;
secret "Yj95beDnn=34fghSN";
};
Nonostante sia possibile con l'istruzione allow-update specificare un lista di indirizzi ip o una acl per controllare gli update dinamici è sconsigliato per ragioni di sicurezza e preferibile utilizzare TSIG per le autenticazioni. Pertanto si crea l'istanza per la chiave che il server DHCP userà per autenticare i suoi update. Nel dhcpd.conf si dovrà creare l'istanza per la chiave corrispondente
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "DHCP_UPDATER"; };
};
Stabilisco il canale di controllo attraverso il quale il mio server DHCP si connetterà per inviare i dati da aggiornare. In questo caso solo localhost ha la possibilità di accedervi.
options {
directory "/var/named";
pid-file "/var/run/named.pid";
};
zone "." in {
type hint;
file "named.root";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.db";
};
zone "0.168.192.in-addr.arpa" IN {
type master;
file "192.168.0.db";
allow-update { key DHCP_UPDATER; };
};
Per singolo file di zona delineo la direttiva che conceda la possibilità di update solo ai possessori della chiave giusta.
zone "esempio.com" IN {
type master;
file "esempio.com.db";
allow-update { key DHCP_UPDATER; };
};
Vediamo ora come named processa le richieste di update. Come immaginabile dovrebbe incrementare il numero di serie ogni volta che viene aggiunto o eliminato un record. Quando una richiesta di update arriva al server quest'ultimo dovrebbe andare ad aggiornare il relativo file di zona. Riscrivere un file di zona ogni volta che un update viene processato in casi in cui ci si trovi in un contesto di rete molto grosso e con molti update come immaginabile diventa un lavoro realmente oneroso per il server con il rischio che non sia possibile riuscire a processarli tutti. Infatti sia BIND 8 che BIND 9 quando ricevono una richiesta di update dinamico salvano questo record su un file di log che serve a tenere traccia dei nuovi record. In questo modo il nameserver ha sempre in memoria un file di zona con tutti i nuovi record ma si appresta a riscrivere i file di zona a intervalli (generalmente un'ora) prestabiliti. BIND 8 in seguito cancella questi file mentre BIND 9 li conserva perchè vengono utilizzati anche per gli incremental zone transfers. In BIND 9 questi file sono salvati con come nome il nome del file di zona e con estensione .jnl
, infatti vengono chiamati journal files. Non c'è da stupirsi infatti se ci si ritrova la directory contenente i file di zona piena di questi jnl files.
Per finire vediamo in breve quello che si dovrebbe aggiungere al dhcpd.conf per il nostro esempio.
Innanzi tutto la direttiva ddns-update-style
va settata utilizzando il metodo "interim". Esiste anche il metodo ad-hoc ma è deprecato e considerato obsoleto. Se si desidera approfondire l'argomento leggere il man per il dhcpd.conf.
Infine vanno date le specifiche per l'uso della chiave per l'autenticazione sicura.
La sintassi è la seguente:
key DHCP_UPDATER {
algorithm HMAC-MD5;
secret "Yj95beDnn=34fghSN";
};
zone esempio.com. {
primary 127.0.0.1;
key DHCP_UPDATER;
};
zone 0.168.192.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
};
In questo caso come si vede con l'istruzione primary definisco dove si trova il nameserver che in questo caso è localhost ma che va modificato se il dhcp e il DNS sono su due host differenti. Notare anche che nella direttiva zone si deve aggiungere il punto finale anche se in caso non presente il dhcp server dovrebbe aggiungerlo da solo.
(F)AQ: registare sul ddns client windows95/98 -
(F)AQ: i client windows 95/98 non si registrano -
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.
Tool grafici per l'amministrazione del sistema |
Le alternative grafiche alla command line per la gestione e configurazione di sistemi Linux / Unix. Webmin e altri tool grafici. |
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2006-03-23 11:55:26
Spiegare cosa fa un sistemista non è sempre ovvio.
Definire quali sono i suoi compiti è quantomeno pretenzioso.
Inquadrare gli skill di cui ha bisogno è limitativo, visto che di fatto, in molte realtà, un sistemista deve poter gestire e configurare hardware e software eterogenei che richiedono conoscenze ed esperienza disparate.
Le attività sistemistiche su un server con qualsiasi sistema operativo variano a seconda delle funzioni della macchina e del contesto lavorativo.
Generalmente il sistemista si dovrebbe preoccupare di:
1- Partecipare a riunioni e fornire la propria opinione sulla definizione dell'infrastruttura informatica e la scelta e il dimensionamento dell'hardware da utilizzare;
2- Installare le macchine;
3- Eseguire le procedure di post-installazione standard (aggiornamento software, rimozione servizi inutili, hardening del sistema, installazione di script e procedure custom);
4- Installare, configurare e testare i servizi richiesti per la macchina;
5- Monitorare performance, sicurezza e funzionalità del sistema;
6- Assistere e assecondare le richieste dirette o indirette degli utenti del sistema (sviluppatori e utenti dei servizi);
7- Eseguire backup e ripristino dei dati;
8- Automatizzare varie procedure nel sistema;
8- Documentare approfonditamente il lavoro svolto.
Troppo spesso il sistemista:
1- Non viene interpellato per una consulenza sulle tecniche più adeguate per le esigenze richieste;
2- Racka, cabla, se necessario smonta e rimonta, e installa le macchine;
3- Non ha una procedura standard di post installazione a cui attenersi;
4- Installa e configura i servizi necessari per la macchina, non sempre li testa a dovere;
5- Non controlla quasi mai i log di sistema, non implementa procedure di controllo;
6- Asseconda gli utenti ma li odia;
7- A volte prevede il backup dei dati, raramente esegue test di recupero;
8- Ripete spesso i soliti comandi;
9- La migliore documentazione la mantiene in testa, il resto in qualche file sul proprio computer.
Generalmente il tutto si spiega e si tende a giustificare con la cronica mancanza di tempo, spesso basterebbe un po' di lucidità progettuale e lungimiranza per riuscire ad ottenere tutti i risultati e alla lunga risparmiare tempo.
- La documentazione è fondamentale: permette di mantenere memoria storica del funzionamento dei sistemi e mette in grado il sistemista di delegare a colleghi meno esperti o appena arrivati di svolgere correttamente il lavoro che dovrebbe svolgere da solo.
- La partecipazione alle decisioni tecniche va richiesta con la giusta insistenza. E se ci ritrova a dover eseguire lavori, imposti dall'altro e tecnicamente discutibili, è doveroso quantomeno esprimere il proprio dissenso e suggerire le alternative più adeguate.
- Nonostante il knowledge generalmente vasto e variegato che spesso un sistemista deve avere, il suo compito di fatto è oscuro ai molti e a volte considerato di importanza trascurabile. Di solito ci si accorge del contrario quando un sistema in produzione va down e qualcuno deve farlo tornare a a funzionare.
- L'utente che usa i servizi della macchina o lo sviluppatore che riempe i contenuti di un sito web, per quanto generalmente poco sensibili alle esigenze e condizioni del sistemista, NON può e NON deve essere considerato un nemico. Di fatto è il motivo per cui il sistemista lavora e, in ogni caso, non ce se ne può disfare. L'unico modo per conviverci al meglio è educarlo all'uso del sistema e capire cosa gli serve per ridurre problemi e tempi di implementazione.
- Per quanto possibile è sempre consigliabile mantenere hardware e software omogenei: hardware dello stesso fornitore e non eterogeneo riduce complicazioni e velcoizza la sostituzione di pezzi di ricambio. Sistemi allineati (stesso OS, stessa distribuzione, stessa versione) rendono più facile, comoda e rapida l'attività sistemistica: gli aggiornamenti di software e kernel possono essere più rapidi e viene ottimizzato il tempo per seguire le problematiche di sicurezza di un sistema operativo.
SOURCE: Linux Corso Base - Coresis - http://www.coresis.com/linux/corsobase/
SOURCE: La Vera Storia di Linux Torwalds - Articolo su Apogeo OpenPress - http://www.apogeonline.com/openpress/articoli/art_9.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2004-05-23 16:15:32
Webmin e' un semplice tool web-based che permette, attraverso un interfaccia molto user-friendly, di poter amministrare praticamente l'intero sistema. E' anche un ottimo strumento "didattico", in quanto permette di verificare la sintassi di file di configurazione e le funzionalità di servizi e programmi vari, editandoli tramite una intuitiva interfaccia grafica.
E' composto da un server web (che di default lavora sulla porta 10000) e da numerosi CGI scritti in Perl che agiscono direttamente su file di sistema come /etc/inetd.conf e /etc/passwd.
Per poter utilizzare webmin, bisogna innanzi tutto scaricarlo dal sito ufficiale (disponibile sia il .tar.gz che l'RPM), dopodiche', tramite un piccolo script, eseguire l'installazione.
Durante l'installazione verranno chieste svariate cose (in linea di massima, a parte user name, le soluzioni di default vanno piu' che bene) tra cui file di configurazione, file di log, path del binario di perl, porta per il server web, utente e password.
Attenzione: se possedete una versione di webmin compresa tra la 0.91 e la 0.960, affrettatevi a scaricarne una piu' aggiornata, in quanto quelle versioni presentano un grave buco che spalanca le porte del vostro sistema ai cracker.
La falla riguarda il modo in cui comunicano il processo padre ed il processo figlio di webmin.
Sfruttando questo l'aggressore, da remoto, puo' ingannare il programma utilizzando il sessionID di un qualsiasi utente gia' loggato nel sistema, e poter cosi' eseguire ogni tipo di azione con i privilegi di root. Per fare questo si deve essere a conoscenza di almeno un nome utente valido, cosa non molto difficile, visto e considerato che di default webmin assegna il nome admin.
Webmin puo' essere compilato tranquillamente su una grande varieta' di sistemi operativi, da Linux alle piu disparate versioni di Unix, compreso il mac OS X.
La sua natura modulare ha permesso la creazione di innumerevoli plug-in in grado di gestire e configurare diversi servizi.
LINK: Sito ufficiale di Webmin - http://www.webmin.com
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2002-10-13 20:23:10
Linuxconf e' un tool che permette, tramite 3 interfacce diverse, di amministrare il proprio sistema Linux in maniera abbastanza semplice ed intuitiva.
E' facilmente installabile via rpm ( rpm -i linuxconf-ver-arch.rpm
)
Vi sono 3 interfacce per linuxconf: testuale, web e grafica.
La prima e' eseguibile da shell digitando linuxconf
(o digitando il path completo /sbin/linuxconf
) ed e' composta da menu e sottomenu a tendina con tanto di help per ogni singola voce.
La seconda e' eseguibile da un qualsiasi browser e lavora sulla porta 98 ( http://localhost:98
).
La terza (disponibile dalla versione 1.9 release 26-12) gira in ambiente grafico, ed ha un impostazione molto simile alla modalita' testuale, anche se e' un po piu' user-friendly di quest'ultima.
Tramite Linuxconf varie operazioni di amministrazione del sistema e di specifici servizi sono presentate con una intuibile interfaccia. In alcuni casi tende a riscrivere i file di configurazione secondo dei propri canoni e questo puo' creare confusione o problemi a chi lo usa.
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-11-12 17:50:35
PhpSysInfo è uno script PHP per la visualizzazione di informazioni sul sistema.
OVERVIEW
PhpSysInfo è uno script sviluppato in linguaggio PHP che permette di visualizzare tramite browser informazioni sul sistema riguardanti, la rete, la memoria, il filesystem, e l'hardware. E' rilasciato sotto licenza GPL ed è disponibile per tutti i sistemi BSD e le piattaforme Posix. Per utilizzare questo tool è necessario avere sulla macchina da monitorare, un web server con supporto di PHP.
DOWLOAD
E' possibile effettuare il download presso SourceForge.net:
root@Joker:/software# wget http://puzzle.dl.sourceforge.net/sourceforge/phpsysinfo/phpsysinfo-2.3.tar.gz
--18:31:38-- http://puzzle.dl.sourceforge.net/sourceforge/phpsysinfo/phpsysinfo-2.3.tar.gz
=> `phpsysinfo-2.3.tar.gz'
Resolving puzzle.dl.sourceforge.net... done.
Connecting to puzzle.dl.sourceforge.net[195.141.101.221]:80... connected. <br>
HTTP request sent, awaiting response... 200 OK
Length: 163,674 [application/x-gzip]
100%[=================================================================================================================================>] 163,674 3.62K/s ETA 00:00
18:32:23 (3.62 KB/s) - `phpsysinfo-2.3.tar.gz' saved [163674/163674]
In caso di utilizzo con PHP 5.0 o sucessivi, è necessario scaricare le versione 2.3.
INSTALLAZIONE
Una volta eseguito il download, il pacchetto andrà scompattato nella document root del webserver sull'host che di cui si vuole eseguire il monitoraggio:
root@Joker:/home/webuser# tar xvfz phpsysinfo-2.3.tar.gz
phpsysinfo-dev/
phpsysinfo-dev/includes/
phpsysinfo-dev/includes/lang/
phpsysinfo-dev/includes/lang/big5.php
phpsysinfo-dev/includes/lang/bg.php
phpsysinfo-dev/includes/lang/br.php
phpsysinfo-dev/includes/lang/ca.php
phpsysinfo-dev/includes/lang/cn.php
phpsysinfo-dev/includes/lang/cs.php
phpsysinfo-dev/includes/lang/ct.php
phpsysinfo-dev/includes/lang/da.php
phpsysinfo-dev/includes/lang/de.php
phpsysinfo-dev/includes/lang/en.php
...
Quindi è necessario rinominare il file principale di configurazione config.php.new
in config.php
:
root@Joker:/home/webuser/phpsysinfo-dev# cp config.php.new config.php
CONFIGURAZIONE
Per utilizzare il tool, si andrà ad inserire una entry nel file di configurazione del web server, in modo da potervi accedere via web. Un esempio di configurazone utilizzando Apache:
root@enigma:/home/webuser/phpsysinfo-dev# cat /usr/local/apache/conf/httpd.conf
...
Alias /sysinfo/ "/home/webuser/phpsysinfo-dev/"
<Directory "/home/webuser/phpsysinfo-dev">
Options Indexes
AllowOverride None
Order allow,deny
Allow from 192.168.0.
</Directory>
...
Le informazioni vengono richiamate puntando a http://nomehost/sysinfo e ne è permessa la visualizzazione solamente alle macchine della rete 192.168.0
L'ultimo settaggio riguarda il file php.ini
, il quale deve includere nela variabile include_path
il "."
e in cui la variabile safe_mode
deve essere settata a off
, in quanto lo script deve poter accedere in lettura alla directory /proc
del sistema al fine di ricavarne le informazioni. Terminate queste operazioni, dopo il riavvio del webserver, sarà possibile accedere alla pagina generata da PhpSysInfo.
LINK: PHP SysInfo Project - http://sourceforge.net/projects/phpsysinfo/
Esempi di configurazione di Iptables |
Esempi di configurazioni di un firewall Linux con iptables |
Tipo Infobox: SAMPLE - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-05-09 20:20:11
Vediamo un esempio pratico di configurazione di Iptables per un personal firewall, quindi da applicare su una macchina desktop che deve poter navigare e liberamente agire in Internet e che non deve esporre alcun servizio.
In un caso simile ci si deve concentrare sulle catene INPUT e FORWARD della tabella FILTER.
Configurazione essenziale
Una configurazione minima può essere molto semplice, l'output che segue è quello di iptables-save
, per utilizzarlo copiarlo in un file (es: /etc/firewall) e applicarlo con iptables-restore < /etc/firewall
).
In pratica:
- Di default si blocca il traffico in ingresso e destinato ad attraversa l'host
- Si lascia aperto il traffico in uscita dal proprio host
- Si permette in INPUT tutto il traffico di ritorno relativo a connessioni già esistenti
- Si permette il traffico sulla interfaccia di loopback, necessario per il buon funzionamento di alcuni programma di sistema:
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
COMMIT
Configurazione più elaborata
Un esempio più elaborato e con un controllo più stringente sul traffico può prevedere:
- Default DROP su tutte le catene
- Si permette in INPUT tutto il traffico di ritorno relativo a connessioni già esistenti
- Si permette il traffico sulla interfaccia di loopback (si interviene sia in INPUT che in OUTPUT)
- Si permette in uscita solo il traffico generato da applicativi usati dall'utente con UserID 501 (attenzione, questo limite potrebbe compromettere il funzionamento di alcun programmi non previsti, che magari girano come root (UID 0) o con altri utenti di sistema)
- Si permette l'aggiornamento del sistema (in questo esempio via http all'indirizzo arbitrario 213.215.144.242)
- Si loggano tutti i pacchetti, esclusi quelli di broadcast, droppati.
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m pkttype --pkt-type ! broadcast -j LOG --log-prefix "INPUT DROP: "
-A FORWARD -m pkttype --pkt-type ! broadcast -j LOG --log-prefix "FORWARD DROP: "
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -m owner --uid-owner 501 -j ACCEPT
-A OUTPUT -p tcp --dport 80 -d 213.215.144.242 -j ACCEPT
-A OUTPUT -m pkttype --pkt-type ! broadcast -j LOG --log-prefix "OUTPUT DROP: "
COMMIT
Tipo Infobox: SAMPLE - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-05-14 14:26:53
Analizziamo la configurazione di iptables per un server pubblico, che deve rendere accessibili dei servizi, con diversi livello di accesso, e che ha un firewall locale.
In questo caso si agisce sulle catene di INPUT e di OUTPUT della tabella FILTER.
Configurazione essenziale
Vediamo un esempio essenziale di una configurazione per un server web pubblico, che deve rendere accessibili a tutto il mondo le porte 80 e 443 e deve poter essere gestito da alcuni IP privilegiati.
La configurazione prevede:
- DROP di default su tutte le catene
- Si lascia aperto il traffico in uscita dal proprio host (OUTPUT) dopo aver sanitificato i pacchetti in uscita (--state)
- Si permette in INPUT tutto il traffico di ritorno relativo a connessioni già esistenti
- Si permette il traffico sulla interfaccia di loopback
- Si permette accesso, da tutta Internet, alle porte 80 e 443
- Si permette l'accesso via SSH (porta 22/TCP) da una arbitraria rete di amministrazione (es: 213.25.10.0/24)
- Si permette l'accesso FTP (porta 21/TCP + gestione del canale dati) da un arbitrario host di un webmaster (es: 143.20.12.7)
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT
-A INPUT -p tcp --dport 22 -s 213.25.10.0/24 -j ACCEPT
-A INPUT -p tcp --dport 21 -s 143.20.12.7 -j ACCEPT
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
Notare che per gestire correttamente il protocollo FTP è opportuno assicurarsi che venga caricato il modulo del kernel ip_conntrack_ftp. Se non viene fatto automaticamente dalla propria distribuzione, caricarlo, facendo eseguire durante la fase di boot (per esempio nel file /etc/rcd.d/rc.local
) il seguente comando:
modprobe ip_conntrack_ftp
Configurazione più elaborata
Un esempio più complesso di un simile sistema può prevedere:
- Default DROP su tutte le catene
- Si permette in INPUT tutto il traffico di ritorno relativo a connessioni già esistenti
- Si permette il traffico sulla interfaccia di loopback (si interviene sia in INPUT che in OUTPUT)
- Si permette in uscita solo il traffico di risposta al traffico in entrata permesso
- Si permette l'aggiornamento del sistema (in questo esempio via http all'indirizzo arbitrario 213.215.144.242)
- Si permette l'invio della posta tramite un unico smtp relay (in questo esempio con IP 213.15.44.22)
- Si loggano tutti i pacchetti di tipo unicast (escludendo quindi broadcast e multicast) con una syslog facility che ci permetta il logging su file separato
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT
-A INPUT -p tcp --dport 22 -s 213.25.10.0/24 -j ACCEPT
-A INPUT -p tcp --dport 21 -s 143.20.12.7 -j ACCEPT
-A INPUT -m pkttype --pkt-type unicast -j LOG --log-prefix "INPUT DROP: " --log-level 7
-A FORWARD -m pkttype --pkt-type unicast -j LOG --log-prefix "FORWARD DROP: " --log-level 7
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p tcp --sport 80 -j ACCEPT
-A OUTPUT -p tcp --sport 443 -j ACCEPT
-A OUTPUT -p tcp --sport 22 -d 213.25.10.0/24 -j ACCEPT
-A OUTPUT -p tcp --sport 21 -d 143.20.12.7 -j ACCEPT
-A OUTPUT -p tcp --dport 80 -d 213.215.144.242 -j ACCEPT
-A OUTPUT -p tcp --dport 25 -d 213.15.44.42 -j ACCEPT
-A OUTPUT -m pkttype --pkt-type unicast -j LOG --log-prefix "OUTPUT DROP: " --log-level 7
COMMIT
Per visualizzare il log su file separato è necessario configurare Syslog. Editare /etc/syslog.conf
(o analogo) e aggiungere una riga tipo:
kern.debug /var/log/firewall.log
.
Esempi di configurazioni particolari
Vediamo alcuni esempi che usano funzioni di iptables meno comuni e non sempre incluse nel kernel di una distribuzione.
- Aprire diverse porte con multiport
Se il nostro server deve esporre più porte può essere comodo il match multiport, che permette di definire più porte TCP o UDP in una singola regola.
Ad esempio per un server di posta completo di webmail, pop3, imap e corrispettivi SSL si può permette pubblico accesso con:
iptables -I INPUT -m multiport -p tcp --dport 25,80,110,143,443,993,995 -j ACCEPT
- Limitare rischi con tool di analisi log con owner
Spesso sul sistema vengono installati strumenti di analisi dei log, di qualsiasi tipo. Questi possono essere semplici programmi singoli o applicazioni più complesse, possono venire schedulati o eseguiti in background. Qualsiasi sia la loro natura, sono programmi che ricevono un input con il log da analizzare, che spesso contiene informazioni su attività generate dall'esterno. Log di server web, di firewall, di posta, per esempio, contengono dati che possono entro certi limiti essere manipolati direttamente da un potenziale intrusore, facendo richieste via HTTP anomale, inviando pacchetti invalidi ecc.
Spesso si sorvola sui potenziali rischi associati al parsing di log, soprattutto se questo viene fatto da programmi semplici e non particolarmente prudenti nel gestire i loro input e se magari vengono pure eseguiti con privilegi di root.
Si possono limitare gli effetti di potenziali vulnerabilità di questi strumenti anche via iptables, impedendo all'utente con cui sono eseguiti sul sistema di comunicare via rete.
Primariamente è opportuno che simili programmi vengano eseguiti con permessi non privilegiati, per cui se non già previsto , è opportuno fare in modo che tutti i log e dati che devono leggere e scrivere siano accessibili dall'utente con cui il programma gira.
Poi, si può usare il metodo di match "owner" con cui le iptables possono gestire il traffico a seconda dell'utente che lo ha generato (per logica questo match si applica solo alla catena di OUTPUT).
Ad esempio se il nostro programma di analisi dei log si chiama fwanalog e viene eseguito con utente logs, con UID 150, possiamo impedire che questo programma comunichi all'esterno (escludendo query DNS che potrebbe fare per reverse DNS lookup) con un comando tipo:
iptables -I OUTPUT -p udp --dport ! 53 -m owner --uid-owner 150 -j DROP
oppure, nei kernel dove è supportata questa estensione:
iptables -I OUTPUT -p udp --dport ! 53 -m owner --cmd-owner fwanalog -j DROP
Tipo Infobox: SAMPLE - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-05-23 14:41:16
Analizziamo quali possono essere le configurazioni di iptables per un firewall Linux adibito a default gateway di una rete locale in grado di nattare gli host interni e impedire accessi non autorizzati dall'esterno.
Configurazione essenziale
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -s 10.0.0.0/255.255.255.0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A FORWARD -s 10.0.0.0/255.255.255.0 -i eth0 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -s 10.0.0.0/255.255.255.0 -j MASQUERADE
COMMIT
SOURCE: sito web - http://www.safer-networking.org/it/download/index.html
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.
File sharing in una rete locale |
Visione d'insieme sul file sharing in LAN e le alternative possibili |
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-06-04 10:26:11
Quasi ogni ufficio ormai ha una rete di computer su cui operano tecnici e impiegati vari.
Generalmente via rete vengono scambiati file e condivise stampanti, anche se ovviamente le applicazioni possono essere molteplici.
Lo scenario di una rete in cui viene fatto file sharing può presentare diverse topologie e logiche:
- Condivisioni distribuite, presente su computer client diversi
- Condivisioni distribuite su diversi file-server
- Condivisione centralizzata su un singolo server
In genere è preferibile centralizzare su uno o più file server tutti i documenti aziendali che vanno condivisi. Questo facilità le operazioni di backup, l'omogeneità e l'integrità delle informazioni, la gestione di permessi sugli accessi.
Dato per assodato che in ufficio medio, tutti i documenti dovrebbere risiedere su un server centrale, che, a partire dalla scheda di rete utilizzata, dovrebbe avere dell'hardware adeguato al suo ruolo, resta da definire il protocollo con cui condividerli.
Se si lavora in un ambiente Unix, dove Unix sono sia i server che le workstation, l'uso di NFS sembra la scelta logica.
Se, più probabilmente, si lavora su una rete per gran parte composta da client Windows, è più logico utilizzare il protocollo CIFS/SMB su cui nativamente si appoggiano le reti Windows.
In questo caso il server centrale può comunque essere una macchina Unix/Linux con Samba e dovrebbe diventare almeno un WINS server per la rete locale, aumentando decisamente la velcoità di browsing delle risorse di rete senza particolari complicazioni in termini di configurazione e setup.
Se i client sono tutti almeno Windows 2000, XP o successivi, esiste la possibilità di accedere al file server centrale via WebDAV, soluzione particolarmente interessante nei casi in cui i file condivisi debbano essere raggiungibili anche via browser (HTTP).
Se la rete è unicamente basata su Mac, AppleTalk o AFS sono la soluzione semplice ed immediata.
Se si lavora in un ambiente Novell, si può considerare Netware su un server centrale, sapendo che il supporto sui vari sistemi operativi è disponibile.
Quando invece si ha a che fare con reti miste, dove sia client che server montano sistemi operativi diversi, gli scenari si allargano e diventano meno definiti. In genere, tramite funzionalità native o programmi di terze parti, con qualsiasi sistema operativo recente si è in grado di utilizzare tutti i protocolli utilizzati, per cui ogni caso richiederebbe valutazioni specifiche.
Una raccomandazione di massima, in questi casi, è comunque la centralizzazione dei dati su un server centrale, a cui accedere via IP utilizzando uno dei protocolli citati (quello supportato nativamente dalla maggior parte dei client, in linea di massima).
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-06-04 10:26:48
Per valutare quale soluzione di file sharing scegliere sulla propria rete locale è opportuno valutare cosa viene offerto e supportato sui sistemi operativi da desktop più comuni sul mercato.
WINDOWS
Su tutti i sistemi Microsoft, da Windows 3.11 in poi, è nativo il supporto di CIFS/SMB che è il protocollo utilizzato sulle normali Reti Windows che si possono browsare da Explorer o Gestione Risorse.
Il supporto NFS è previsto o tramite software di terze parti (in genere a pagamento) o con il Windows Services for Unix CD per Win2000 di Microsoft.
Il supporto AppleShare e Novell è nativo in Windows (i driver non vengono installati di default e su XP AppleTalk non è più supportato).
MAC
Sul mondo Apple va fatta una distinzione.
Mac OS X supporta nativamente praticamente tutto: SMB/CIFS, Novell, NFS, AppleTalk, WebDAV, su Mac OS precedenti il supporto per protocolli di rete non Apple non è sempre nativo e in alcuni casi ci si deve rivolgere a prodotti di tezri.
LINUX
Il supporto per tutti i file system di rete noti è presente anche se non sempre viene attivato sulle installazioni di default. Samba per SMB/CIFS, netaTalk per Apple Talk, un server NFS e Novell permettono a Linux di operare sia come client che come server in ambienti di rete eterogenei.
A livello pratico l'implementazione di alcuni servizi non è sempre semplicissima.
UNIX
In genere tutto il software opensource disponibile su Linux è compilabile su qualsiasi dialetto Unix, per cui vale quanto detto per Linux.
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-06-04 09:53:35
Quando le prime reti di computer iniziarono ad affermarsi negli uffici e negli ambienti lavorativi, il principale utilizzo che se ne faceva era la condivisione dei file fra i diversi computer, permettendo agli utenti di lavorare sugli stessi documenti senza doverseli "scambiare" con mezzi molto meno efficaci (floppy disk e analoghi).
La condivisione dei file, pur essendo una delle prime applicazione pratiche in una rete locale, resta un punto chiave per l'ottimizzazione dei processi e dei flussi informativi dentro un'azienda.
Oltre a rendere più comodi e rapidi gli scambi di informazione dentro un'azienda, comporta una serie di problematiche che si legano direttamente alle funzionalità che fornisce.
La sicurezza in tutte le sue sfaccettature è la più importante:
se un file può essere accessibile via rete, si deve prevedere un meccanismo di controllo su chi può leggerlo, chi può modificarlo e chi non deve nemmeno sapere che esiste.
Se lo stesso file è usato contemporaneamente da più persone si devono evitare sovrascritture o di dati o incongruenze e, nello stesso momento, assicurarsi che tutti lavorino sulla stessa copia, e non ci siano altre copie in giro che possano avere livelli di aggiornamento incoerenti.
La riservatezza dei documenti viene gestita tipicamente vincolando l'accesso ai dati all'inserimento di una login e una password, che permettono di identificare l'utente e quali permessi ha sul file.
Il backup dei file condivisi è ovviamente fondamentale e risulta molto più comodo da gestire se tutti i file vengono condivisi su un server centrale. E' generalmente una pessima idea lasciare che i singoli utenti condividano file direttamente dalle loro macchine.
La disponibilità dei documenti è fondamentale nel momento in cui gli utilizzatori non possono più accedere agli stessi (per problemi hardware, di rete, di applicativo ecc.) e si vedono limitati nella loro possibilità di lavorare.
Tutte queste componenti vanno considerate nell'implementare una infrastruttura di file sharing in grado di rispondere alle esigenze richieste, e sono da dimensionare sulla base dei livelli di criticità dei volumi di traffico previsti.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-06-08 00:04:34
La funzione di un file server è ovviamente quella di mettere a disposizione e condividere via rete file di varia natura a client eterogenei.
La modalità di condivisione può presentare una varietà di situazioni che vanno valutate:
- Protocollo di file sharing
Se ne possono usare diversi, volendo si possono anche usare contemporaneamente in modo da condividere tramite vie diverse la stessa directory locale. In linea di massima in un ambiente prevalentemente basato su client Windows la scelta d'obbligo è SMB, se i client sono Unix è più comodo NFS. Se il parco macchine è piuttosto eterogeneo (Windows, Max, Unix...) probabilmente SMB risulta la soluzione più comodamente implementabile.
Se i file vanno consultati solo in lettura, ha senso considerare l'uso di un server web, che permetta il browsing fra le directory e risulta particolarmente comodo in quanto a supporto di client eterogenei.
Se c'è una necessità di accesso anche in scrittura si può considerare WebDAV, ma solo se i client lo supportano.
- Password e gestione degli accessi
In ambienti reali l'accesso ai file richiede generalmente una login e una password e spesso è necessario gestire diverse login contemporaneamente con diversi livello di accesso ai file.
In questo senso è utile prevedere, in ambienti business, diversi gruppi, dai nomi generici relativi alle funzioni e alle categorie del caso (es: contabilità, magazzino, commerciale, direzione, produzione e via dicendo). Ad ogni gruppo è quindi possibile aggiungere i singoli membri, possibilmente identificati con nome e cognome, con password che hanno una scadenza e divisione dei file in directory basate su potenziali gruppi di accesso (gestire i diritti di accesso al livello di singoli file e non di directory può diventare piuttosto scomodo)
E' logico aspettarsi che un singolo utente possa far parte di più gruppi e che ci siano gruppi a loro volta composti da altri gruppi di utenti.
La logica con cui si possono scegliere i gruppi, i diritti di accesso in lettura o scrittura a date directory, la divisione stessa dei file in directory dipende dai contesti particolari ma va studiata sulla base delle esigenze attuali e di quelle prevedibili per il futuro.
- Struttura di rete
Un file server tipicamente deve gestire un traffico di rete superiore alla media, per cui anche la struttura del network in cui si trova deve essere adeguatamente disegnata.
La porta di rete a cui viene collegato il server dovrebbe essere la più performante possibile (100Mbit o 1Gbit), scelta su uno switch centrale, che possa essere ugualmente accessibile da parte degli hub o degli switch perimetrali. Il link dovrebbe essere full duplex e senza errori, il cavo di rete, come qualsiasi componente fisico del file server, dovrebbe essere in un modo fisicamente protetto e riparato.
- Hardware
Il sistema su cui gira un file server dovrebbe essere ragionevolmente protetto e ridondato, dal momento che questa funzione è spesso critica in una azienda. La ridondanza, che non esclude un valido meccanismo di backup, può venire fatta tipicamente a livello degli hard disk, con un RAID 1 o un RAID 5 e, in casi particolarmente critici, utilizzando un cluster.
Su un file server le componenti solitamente più sotto pressione sono gli hard disk (per questo è consigliabile valutare l'uso di hard disk SCSI) e il network (schede di rete almeno a 100Mbit). Memoria, soprattutto, e CPU vanno dimensionate rispetto alle proprie esigenze.
Di memoria, come sempre, più ce n'è e meglio è: secondo il Samba team sono necessari circa 460 Kb di memoria per ogni client che si collega ad un Samba 2.2.5 (su Windows 2000 bastano circa 330 Kb).
Se la memoria e il resto delle risorse bastano, Samba scala meglio di Windows quando molti client (più di 50) contemporaneamente accedono al server: il troughtput compessivo rimane tendenzialmente stabile senza decadere eccessivamente.
La CPU va dimensionata al carico e in certe situazioni può essere raccomandabile un sistema biprocessore rispetto ad uno, a parità di potenza di calcolo, a singola CPU: più processori degradano meno le performance del sistema quando è sotto stress.
Tendenzialmente un file server particolarmente utilizzato non dovrebbe svolgere altre funzioni, almeno di giorno, quando si presume debba svolgere gran parte della sua attività.
I dati condivisi dovrebbero stare su uno o più hard disk separati, rispetto a quelli dove sono presenti i file di sistema. Se questo non è possibile, prevedere almeno l'uso di partizioni distinte.
- Backup
Il backup dei file condivisi da un file server è fondamentale. Il supporto su cui viene fatta la copia dovrebbe essere rimuovibile (harddisk, nastri ecc.) e regolarmente portato in località remote. Si può prevedere un server che svolga la duplice funzione di backup dei dati e di macchina di standby, da attivare in tempi rapidi (automaticamente o in modo manuale) in caso di guasti del server principale.
- Sicurezza
Un file server per natura è una macchina delicata che può contenere file e documenti riservati. E' altamente improbabile che un simile sistema debba stare su IP pubblico, per cui sia il suo IP, sia gli IP dei suoi client, dvrebbero appartenere ad una rete privata.
L'accesso a tutti i documenti che non siano di pubblico dominio dovrebbe avvenire tramite password (non è il caso di regalare fiducia incondizionata a chiunque abbai accesso fisico alla rete locale).
A livello di host security, si dovrebbero disattivare tutti i servizi inutilizzati e mantenere aggiornati almeno quelli che ascoltano su porte raggiungibili via rete. Avere un sistema su una rete interna lo rende ragionevolmente sicuro da attacchi direttamente dall'esterno, ma non da attacchi perpetrati da host locali.
Se possibile evitare anche che il file server possa accedere ad Internet, semplicemente non impostandogli un default gateway: gli aggiornamenti del software, l'uso di mail e DNS e varie altre operazioni che richiedono la rete possono appoggiarsi ad altri server interni.
- Logging
A parte i meccanismi di logging di sistema, volti ad individuare eventuali problemi hardware, software o di sicurezza, può aver senso loggare ogni accesso, quantomeno in scrittura, sui file condivisi.
Nel log dovrebbe comparire il nome dell'utente che ha modificato o scritto un file.
I log vanno, come sempre, ruotati e archiviati, per evitare che crescano a dismisura andando ad esaurire lo spazio su disco.
Il protocollo CIFS/SMB |
Common Internet File System / Server Message Block |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2006-02-28 14:31:06
Quando si parla di NetBios, NetBEUI e SMB si rischia spesso di far confusione fra protocolli, livelli di applicazione, definizione e contesti. Non è un caso, questi sono argomenti di fatto anomali, nel mondo del networking, che si trascinano dietro due decenni di utilizzi in rete e relative implementazioni.
Cerchiamo di chiarire le cose a grandi linee, in modo da poter meglio individuare gli argomenti che ci interessano e contestualizzarli correttamente.
NetBios strettamente parlando più che un protocollo è un interfaccia di programmazione (API) fatta sviluppare da IBM nel 1983 per permettere a delle applicazioni di comunicare scambiandosi file e messaggi sui PC network del tempo, che avevano un basso numero di host e non prevedevano ancora l'uso del protocollo IP (già presente ma usato più su WAN che in LAN) per le comunicazioni di rete.
Con l'introduzione di Token Ring, IBM nel 1985 definì delle estensioni a NetBios (NetBIOS Extended User Interface NetBEUI) che permettevano di appoggiarsi ad un data-link 802.2 (Token Ring o Ethernet).
Microsoft ha iniziato ad usare NetBEUI come protocollo di rete su Windows for Workgroup (Windows 3.1) e poi su tutte le versioni successive ma, al contempo, con la diffusione di Novell IPX e di IP, si è iniziato a veicolare NetBios anche su IPX e IP, oltre che su altri protocolli.
E' quindi possibile trovare NetBios (tipicamente proposto come protocollo a livello di sessione) nella sua incarnazione originaria, come NetBIOS Frames Protocol (NBF) detto anche semplicemente NetBios o NetBEUI, che copre i livelli di network e trasporto, oppure incapsulato su IPX o TCP/IP con questi ultimi a gestire il network e transport layer e NetBios posizionato come session layer.
Il protocollo Server Message Block (SMB) e il suo derivato Common Internet File System (CIFS) agiscono a livello applicativo, direttamente su NetBEUI, NetBios su IPX o NetBios su IP (chiamato anche NBT o NetBT), CIFS, invece, nelle sue recenti versioni può anche essere trasportato direttamente dal TCP/IP, senza layer NetBios intermedio.
Caratteristiche di NetBios
L'indirizzamento di NetBios è flat, basato sul semplice nome di un host (generalmente fino a 15 caratteri) e senza elementi gerarchici (come il DNS) che di fatto lo rendono inadatto per gestire il routing fra network diversi. Il nome NetBios è lo stesso che viene utilizzato dai procotolli superiori come SMB/CIFS.
Per impedire che due host nella stessa rete abbiamo lo stesso nome viene utilizzato il protocollo Name Management Protocol (NMP), tramite il quale, a colpi di broadcast, un host annuncia la sua presenza in rete e avverte quando un nuovo host con lo stesso nome prova ad apparire.
Nella comunicazione fra host si usano lo User Datagram Protocol (UDP, diverso dall'UDP usato su IP), unreliable e basato su datagrammi fino a 512 byte e il Session Management Protocol (SMP), bidirenzionale, reliable e basato su sessioni che vengono stabilite fra due host. Meccanismi di controllo e di monitoring vengono gestiti dal Diagnostic and Monitoring Protocol (DMP).
Attualmente la forma maggiormente utilizzata è quella di NetBios incapsulato su TCP/IP (NetBios over TCP/IP o NBT). Questo standard è definito nelle RFC 1001 e RFC 1002 dove si affrontano le problematiche relative all'associazione di un nome di host ad un indirizzo IP (broadcast o server di nomi centralizzato) e i metodi di comunicazione (a datagrammi o a sessioni).
Le porte utilizzate per questi servizi sono:
netbios-ns 137/udp # NETBIOS Name Service
netbios-dgm 138/udp # NETBIOS Datagram Service
netbios-ssn 139/tcp # NETBIOS Session Service
Gestione dei nomi su NetBios
I nomi di host di NetBios su TCP/IP (che coincidono con i nomi SMB) possono essere registrati (annunciati) e risolti (trovati) sul network locale sia tramite broadcast che tramite un server di nomi centralizzato (NBNS NetBios Name Server, su sistemi Windows l'implementazione di un NBNS è il WINS server) che risulta, soprattutto su reti affollate, molto più efficace.
A seconda di come un host è configurato per gestire i nomi assume un tipo di nodo diverso:
b-node - Host che usa solo broadcast per la risoluzione e la registrazione degli host name.
p-node - Host che usa un server centrale (comunicazione point-to-point) per risoluzione e registrazione
m-node - Host che usa broadcast per la registrazione e la risoluzione, inoltre se porta a termine con successo una registrazione lo notifica ad un server NBNS, che viene usato anche quando la risoluzione via broadcast non ha successo.
h-node (hybrid) - Host che usa un server NBNS per risoluzione e registrazione dei nomi e, nel caso in cui il server NBNS non sia disponibile utilizza i broadcast. Questa modalità è stata introdotta da Microsoft, non appare nelle RFC 1001 e 1002.
Il tipo di nodo, su Windows, è visibile nell'output del comando ipconfig /all
dove si parla di NodeType
I nomi possono essere lunghi 15 caratteri (byte) e contenere caratteri alfanumerici standard ( a-z, A-Z, 0-9, ! @ # $ % ^ & ( ) - ' ). Il sedicesimo e ultimo byte indica il tipo di risorsa, a seconda del valore esadecimale indicato corrisponde una diversa risorsa, alcuni esempi:
00 - Normale workstation
03 - Servizio di messaggistica (WinPopup)
1B - Domain Master Browser
20 - Fileserver
NetBios inoltre prevede il concetto di gruppo (i Workgroup in ambiente Windows).
Principi di SMB
SMB è un protocollo di livello applicativo utilizzato per la condivisione di directory fra computer, la stampa via rete e lo scambio di file e messaggi. Si basa su una struttura client-server ed ha una logica di tipo request-response. Dalla sua introduzione originaria ha subito varie modifiche e varianti che modificano e aggiungono nuovi SMB (Server Message Blocks, di fatto i "comandi" utilizzabili). Su Windows 95 e NT per esempio viene utilizzata la variante NT LM 0.12, che viene supportata, fra gli altri, anche da Samba, un implementazione OpenSource del protocollo che è utilizzabile su gran parte degli Unix in circolazione.
SOURCE: NetBios, NetBEUI, NBF, SMB, CIFS Networking - http://ourworld.compuserve.com/homepages/timothydevans/contents.htm
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-03-25 16:09:46
Microsoft utilizza NetBios e SMB come protocolli di rete per condividere risorse su Windows fin da Windows 3.1. Rispetto alle versioni esistenti di questi protocolli ha introdotto alcune estensioni proprietarie:
- Domini Windows
- Browsing
- Server WINS
I Domini Windows
Fondamentalmente un dominio Windows è un workgroup con un server che agisce come Domain Controller con funzioni di autenticazione centralizzata per l'accesso alle risorse (file, stampanti, login sul sistema...) da parte tutti gli host che fanno parte del dominio.
Vengono usati protocolli differenti per Windows 95/98, Windows NT e Windows 2000 (dove il concetto di dominio viene ulteriormente allargato con le Active Directory).
Il Primary Domain Controller (PDC) è il server che mantiene un database di tutte le password (SAM): quando un client cerca di accedere alle risorse di un server, quest'ultimo verifica sul PDC se login e password fornite sono valide. Se questo accade al client viene permesso l'accesso alle risorse richieste e fornito un token di autenticazione con cui automaticamente riesce ad accedere ad altre risorse in rete accessibili dalla stessa login.
Il database delle password viene automaticamente copiato ad uno o più Backup Domain Controller (BDC) che possono essere utilizzati per autenticare i clinet nel caso in cui i PDC risulti inaccessibile.
Browsing
Per rendere più rapida l'individuazione degli host e delle risorse in una rete locale, Microsoft ha introdotto il Local Master Browser un computer che ha il ruolo di mantenere la lista degli host in rete (browse list) e che fa da riferimento per tutte le richieste e gli aggiornamenti da parte delle altre macchine in rete.
Praticamente ogni macchina Windows può agire da Local Master Browser o da Backup Browser (host che riceve la browse list da un Master Browser e viene utilizzata in caso di inagibilità di quest'ultimo). Queste funzionalità vengono definite automaticamente dagli host NetBios in una rete locale tramite una procedura chiamata elezione in cui tutti gli host partecipano tramite broadcast. A seconda del sistema operativo, della versione di protocollo utilizzata, del tempo di uptime nella rete e del nome dell'host viene automaticamente deciso chi deve operare come Master Browser e questo rimane tale fino a quando resta connesso o un nuovo host con migliori credenziali si aggiunge alla rete.
Quando si clicca, in Windows, su Risorse di Rete di fatto si ottiene dal Master Browser la browse list degli host in rete (notare che questa potrebbe essere non perfettamente aggiornata, con alcuni host che risultano presenti anche se magari sono spenti o disconnessi e non hanno avuto modo di comunicarlo al Master Browser), quando si clicca sul singolo host si ottiene l'elenco delle sue risorse condivise.
Server WINS
Il Windows Internet Name Service (WINS) è l'implementazione Microsoft di un NetBios Name Server (NBNS) che ha la funzione di mantenere la lista dei nomi NetBios degli host in rete e dei relativi indirizzi IP. Ovviamente questo serve quando si usa NetBios over TCP/IP ed è una soluzione consigliabile quando si ha una rete medio grande o si devono connettere workgroup presenti su network IP differenti.
Anche in questo caso, oltre ad un Primary Wins Server possono esistere uno o pià Secondary Wins Server con funzioni di ridondanza e backup.
Installazione e gestione di Samba |
Installazione di Samba tramite RPM e sorgenti, file installati e posizioni - Gestione del servizio |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2004-06-04 10:57:16
Installazione step by step di samba attraverso i pacchetti RPM e la compilazione dei sorgenti.
TAR.GZ - COMPILAZIONE DEI SORGENTI:
- Download dei sorgenti
Si scarica il tar.gz di Samba dal sito ufficiale o uno dei suoi mirror:
root@SATURNO root]# wget ftp://it.samba.org/pub/samba/samba-latest.tar.bz2
--16:45:01-- ftp://it.samba.org/pub/samba/samba-latest.tar.bz2
=> `samba-latest.tar.bz2'
Resolving it.samba.org... done.
Connecting to it.samba.org[217.56.103.6]:21...
[...]
- Scompattazione sorgenti
[root@SATURNO root]# tar -jxvf samba-latest.tar.bz2
[..]
[root@SATURNO root]# cd samba-2.2.8/
[root@SATURNO samba-2.2.8]# ls -l
total 102
-rw-r--r-- 1 783 783 17982 May 4 1996 COPYING
Directory contenente documentazione di vario genere e in vari formati
drwxr-xr-x 10 783 783 1024 Feb 5 17:24 docs
Directory contenente esempi di file di configurazione oltre a tools o script per la gestione della configurazione di samba
drwxr-xr-x 16 783 783 1024 Mar 15 05:28 examples
-rw-r--r-- 1 783 783 4551 Apr 30 2002 Manifest
Directory contenente files di configurazione e relativi script per la creazione di package per vari OS e distribuzioni di Linux
drwxr-xr-x 15 783 783 1024 May 3 2002 packaging
Directory contenente sorgenti di un semplice monitoring della shared memory
drwxr-xr-x 2 783 783 1024 May 3 2002 pcp
-rw-r--r-- 1 783 783 0 Aug 21 1997 Read-Manifest-Now
-rw-r--r-- 1 783 783 8412 Feb 28 16:56 README
-rw-r--r-- 1 783 783 1894 Apr 14 2001 Roadmap
Directory contenente i sorgenti
drwxr-xr-x 33 783 783 1024 Mar 15 05:28 source
Directory contenente il tool swat per la configurazione di samba via web
drwxr-xr-x 5 783 783 1024 Mar 15 05:28 swat
Directory contenente, script, sorgenti e altro per eseguire alcuni test su samba
drwxr-xr-x 9 783 783 1024 Mar 15 05:28 testsuite
-rw-rw-r-- 1 783 783 59481 Mar 15 05:44 WHATSNEW.txt
-Compilazione sorgenti
La compilazione dei sorgenti avviene come nella maggior parte dei casi con il lancio dello script configure per il settaggio di alcuni parametri e il comando make per la compilazione e installazione dei sorgenti.
[root@SATURNO samba-2.2.8]# cd source/
Per richiamare l'elenco delle opzioni e la relativa spiegazione, lanciare il seguente comando:
[root@SATURNO source]#./configure --help
Di seguito sono riportate le opzioni con relativa spiegazione utilizzati per la creazione dell' RPM per la distribuzione redhat.
Imposta il prefisso del path di installazione
--prefix=%{prefix} \
Imposta la directory ove il sistema scrive tutte quelle informazioni come log, pidfile etc.
--localstatedir=/var \
Imposta la directory contenente tutti i file di configurazione
--with-configdir=/etc/samba \
Specifica la directory ove viene messo smbpasswd
--with-privatedir=/etc/samba \
Specifica la directory dove risiedono i code page files
--with-codepagedir=/etc/codepages \
Abilita l'uso dei path fhs-compliant
--with-fhs \
Abilita il supporto per quota
--with-quotas \
Include il supporto per MS Dfs
--with-msdfs \
Abilita il supporto per smbmount
--with-smbmount \
Abilità il supporto per l'uso di PAM password database
--with-pam \
Include anche il modulo smbpass
--with-pam_smbpass \
Abilita il supporto del logging via syslog
--with-syslog \
Include utmp accounting
--with-utmp \
Specifica dove vengono installati i file riguradanti a swat
--with-sambabook=%{prefix}/share/swat/using_samba \
--with-swatdir=%{prefix}/share/swat \
Abilita la compilazione delle librerie dinamiche del client
--with-libsmbclient
[root@SATURNO source]# ./configure --prefix=/usr \
--localstatedir=/var \
--with-configdir=/etc/samba \
--with-privatedir=/etc/samba \
--with-codepagedir=/etc/codepages \
--with-fhs \
--with-quotas \
--with-msdfs \
--with-smbmount \
--with-pam \
--with-pam_smbpass \
--with-syslog \
--with-utmp \
--with-sambabook=/usr/share/swat/using_samba \
--with-swatdir=/usr/share/swat
[...]
checking for poptGetContext in -lpopt... yes
checking whether to use included popt... no
checking configure summary... yes
updating cache ./config.cache
creating ./config.status
creating include/stamp-h
creating Makefile
creating script/findsmb
creating include/config.h
Compilazione dei sorgenti
[root@SATURNO source]# make
Using FLAGS = -O -Iinclude -I./include -I./ubiqx -I./smbwrapper -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DLOGFILEBASE="/var/log/samba" -DCONFIGFILE="/etc/samba/smb.conf" -DLMHOSTSFILE="/etc/samba/lmhosts" -DSWATDIR="/usr/share/swat" -DSBINDIR="/usr/sbin" -DLOCKDIR="/var/cache/samba" -DCODEPAGEDIR="/etc/codepages" -DDRIVERFILE="/etc/samba/printers.def" -DBINDIR="/usr/bin" -DPIDDIR="/var/run/samba" -DLIBDIR="/usr/lib" -DHAVE_INCLUDES_H -DPASSWD_PROGRAM="/usr/bin/passwd" -DSMB_PASSWD_FILE="/etc/samba/smbpasswd" -DTDB_PASSWD_FILE="/etc/samba/smbpasswd.tdb"
[...]
Installazione
[root@SATURNO source]# make install
[...]
INSTALLAZIONE TRAMITE RPM
L'installazione completa di samba via rpm richiede più package scaricabili da repository come http://www.rpmfind.net oppure nel caso di Redhat ci si può appoggiare anche al suo repository di errata.
Supponiamo di aver scaricato i seguenti RPM:
Package principale contenente documentazione, manuali e binari per attivare il servizio.
samba-2.2.7-4.8.0.i386.rpm
Package contenente le utility e relativi manuali per il mounting delle share
samba-client-2.2.7-4.8.0.i386.rpm
Package contenente file di necessari sia al client che al server come l'utility smbpasswd o le code pages
samba-common-2.2.7-4.8.0.i386.rpm
Utility per la configurazione di samba via web
samba-swat-2.2.7-4.8.0.i386.rpm
Installazioe di tutti i vari rpm relativi a samba
[root@SATURNO root]# rpm -ihv samba-*.rpm
warning: samba-2.2.7-4.8.0.i386.rpm: V3 DSA signature: NOKEY, key ID db42a60e
Preparing... ########################################### [100%]
1:samba-common ########################################### [ 25%]
2:samba ########################################### [ 50%]
3:samba-client ########################################### [ 75%]
4:samba-swat ########################################### [100%]
Visualizzazione di ciò che i vari rpm hanno installato
[root@SATURNO root]# rpm -qil samba
[...]
File di configurazione per logrotate
/etc/logrotate.d/samba
File di configurazione per PAM
/etc/pam.d/samba
Script di gestione del servizio
/etc/rc.d/init.d/smb
File contenente la correlazione unix_name e smb_name
/etc/samba/smbusers
File contenente le opzioni passate ai vari demoni
/etc/sysconfig/samba
Uility per la creazione di file unicode per samba
/usr/bin/make_unicodemap
Script relativo alla gestione del file smbpasswd
/usr/bin/mksmbpasswd.sh
Script per la gestione degli utenti samba
/usr/bin/smbadduser
/usr/bin/smbcontrol
/usr/bin/smbstatus
/usr/bin/tdbbackup
Librerie e file header
/usr/include/libsmbclient.h
/usr/lib/libsmbclient.a
/usr/lib/samba/vfs
/usr/lib/samba/vfs/recycle.so
Binari relativi ai demoni
/usr/sbin/nmbd
/usr/sbin/smbd
Documnetazione
/usr/share/doc/samba-2.2.7
/usr/share/doc/samba-2.2.7/COPYING
/usr/share/doc/samba-2.2.7/LDAP
/usr/share/doc/samba-2.2.7/LDAP/README
/usr/share/doc/samba-2.2.7/LDAP/export_smbpasswd.pl
/usr/share/doc/samba-2.2.7/LDAP/import_smbpasswd.pl
/usr/share/doc/samba-2.2.7/LDAP/ldapchpasswd
/usr/share/doc/samba-2.2.7/LDAP/ldapsync.pl
[...]
Manuali
/usr/share/man/man1/make_unicodemap.1.gz
/usr/share/man/man1/smbcontrol.1.gz
/usr/share/man/man1/smbstatus.1.gz
/usr/share/man/man5/smbpasswd.5.gz
/usr/share/man/man7/samba.7.gz
/usr/share/man/man8/nmbd.8.gz
/usr/share/man/man8/pdbedit.8.gz
/usr/share/man/man8/smbd.8.gz
Directory di appoggio
/var/cache/samba
/var/log/samba
/var/run/samba
/var/spool/samba
[root@SATURNO root]# rpm -qil samba-common
[...]
Script di gestione del demone windbind
/etc/rc.d/init.d/winbind
File di configurazione
/etc/samba
/etc/samba/lmhosts
/etc/samba/smb.conf
Librerie dinamiche
/lib/libnss_winbind.so
/lib/libnss_winbind.so.2
/lib/libnss_wins.so
/lib/libnss_wins.so.2
/lib/security/pam_winbind.so
utility e binari di vario genere per l'amministrazione del servizio e degli utenti di samba
/usr/bin/make_printerdef
/usr/bin/make_smbcodepage
/usr/bin/smbpasswd
/usr/bin/testparm
/usr/bin/testprns
/usr/bin/wbinfo
/usr/sbin/winbindd
Manuali
/usr/share/man/man1/make_smbcodepage.1.gz
/usr/share/man/man1/testparm.1.gz
/usr/share/man/man1/testprns.1.gz
/usr/share/man/man1/wbinfo.1.gz
/usr/share/man/man5/lmhosts.5.gz
/usr/share/man/man5/smb.conf.5.gz
/usr/share/man/man8/smbpasswd.8.gz
/usr/share/man/man8/winbindd.8.gz
Directory contenente i codepages
/usr/share/samba
/usr/share/samba/codepages
[...]
[root@SATURNO root]# rpm -qil samba-client
[...]
links a /usr/bin/smbmount,binario per il mounting delle share
/sbin/mount.smb
/sbin/mount.smbfs
Utility per l'interrogazione del server smb e per il mountig delle share
/usr/bin/nmblookup
/usr/bin/rpcclient
/usr/bin/smbcacls
/usr/bin/smbclient
/usr/bin/smbmnt
/usr/bin/smbmount
/usr/bin/smbprint
/usr/bin/smbspool
/usr/bin/smbtar
/usr/bin/smbumount
Manuali
/usr/share/man/man1/nmblookup.1.gz
/usr/share/man/man1/rpcclient.1.gz
/usr/share/man/man1/smbcacls.1.gz
/usr/share/man/man1/smbclient.1.gz
/usr/share/man/man1/smbtar.1.gz
/usr/share/man/man8/smbmnt.8.gz
/usr/share/man/man8/smbmount.8.gz
/usr/share/man/man8/smbspool.8.gz
/usr/share/man/man8/smbumount.8.gz
Per la gestione del servizio ci si può appoggiare allo script: /etc/init.d/smb, specificando come parametro l'azione da eseguire, esempio start, stop o restart.
Opzioni disponibili:
- start : Avvia il servizio smb
- stop : killa i processi smb
- restart : Esegue in successione stop e start
- reload : esegue il reload del file di configurazione
- status : visualizza lo status dei demoni
- condrestart : Esegue il restart del servizio
Per richiamare le singole opzioni utilizzabili lanciare lo script senza argomenti
[root@SATURNO root]# /etc/init.d/smb
Usage: /etc/init.d/smb {start|stop|restart|reload|status|condrestart}
Esempi di avvio, restart e stop
[root@SATURNO root]# /etc/init.d/smb start
Starting SMB services: [ OK ]
Starting NMB services: [ OK ]
[root@SATURNO root]# /etc/init.d/smb restart
Shutting down SMB services: [ OK ]
Shutting down NMB services: [ OK ]
Starting SMB services: [ OK ]
Starting NMB services: [ OK ]
[root@SATURNO root]# /etc/init.d/smb stop
Shutting down SMB services: [ OK ]
Shutting down NMB services: [ OK ]
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-05-31 21:25:07
La suite Samba risulta essere veramente ricca di tools e script per la configurazione gestione e uso dei suoi servizi, uno di questi è molto utile per verificare prima di lanciare il demone che tutto sia a posto all'interno del file di configurazione.
testparm esegue un controllo sul file di configurazione specificato che per default, se si è installato dai sorgenti è dir_samba/lib/smb.conf
, dopo di che se è tutto ok stampa a monitor "Loaded services file OK." più qualche informazione ulteriore e dopo aver premuto [enter] mostra tutti i settaggi e come sono configurati.
La sua sintassi:
testparm [opzioni] path_file_conf [hostname indirizzo_IP]
Per l'ultimo campo quando si specifica l'hostname va sempre specificato anche l'indirizzo IP e in questo modo si effettua una verifica dei parametri host allow
e host deny
nel smb.conf per verificare che il dato host abbia accesso al server Samba.
Le opzioni sono:
-h
: Per avere in output un brief delle opzioni e della sintassi.
-L nome_server
: Per modificare il valore della macro %L nel valore nome_server.
-s
: Fa in modo che non faccia premere all'utente il tasto [enter] per avere il dump dei settaggi.
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-05-31 21:29:06
nmblookup è un'utility che permette la risoluzione dei nomi NetBIOS in indirizzi IP.
Il comando permette di effettuare richieste di nomi NetBIOS per la loro risoluzione in indirizzi IP usando NetBIOS over TCP/IP.
Le sue opzioni gli permettono di effettuare query dirette ad una particolare area broadcast o ad una macchina specifica. Tutte le richieste vengono inoltrate usando UDP.
Un po come nslookup è utile per recuperare informazioni su una rete NetBIOS dai semplici indirizzi a informazioni particolari come __MSBROWSE__ usate dai servizi dei nomi di Windows per fornire servizi di directory.
La sua sintassi è:
nmblookup [-opzioni] nome
Supporta varie opzioni che ne regolano il comportamento:
-A
: Interpreta un nome come un indirizzo IP e segue una richiesta node-status su quell'indrizzo.
-B indirizzo_broadcast
: Invia le richieste ad un particolare indirizzo broadcast. Il suo default è di utilizzare il valore di broadcast dell'interfaccia di rete primaria oppure come definito dal parametro interfaces
del smb.conf.
-h
: Stampa a monitor un breve brief dei comandi.
-M
: Effettua la ricerca del master browser locale. Viene eseguita una richiesta broadcast delle macchine che rispondono al nome speciale __MSBROWSE__ e poi chiede le informazioni a quella macchina al posto di effettuare un richiesta broadcast per la macchina cercata.
-R
: Abilita le richieste ricorsive. Si usa per effettuare richieste ad un WINS server.
-S
: Una volta ricavato l'indirizzo IP del nome richiesto effettua una richiesta node-status restituendo tutti i tipi di risorsa che la macchina ha e il loro valore numerico.
-s
: Permette di specificare il file di configurazione smb.conf da utilizzare.
-U indirizzo_unicast
: Effettua un richiesta unicast all'indirizzo specificato, si usa insieme all'opzione -R per fare richieste a server WINS sulla rete locale.
Vediamo l'otput di un node-status:
bash-2.05a$ nmblookup -A 192.168.0.1
Looking up status of 192.168.0.1
SMBSRV <00> - B
SMBSRV <03> - B
SMBSRV <20> - B
WORKGROUP <00> -
WORKGROUP <1e> -
__MSBROWSE__ <01> -
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-01-21 12:27:41
Abbiamo visto che anche con smbclient si possono gestire i back-up di risorse condivise ma nella suite Samba esiste un comando prettamente dedicato a questo lavoro, smbtar.
In realtà smbtar è uno shell script che gira sopra smbclient e permette di eseguire back-ups e restores usando opzioni più comprensibili. Le sue funzionalità sono simili a quelle del comando unix tar.
Supporta svariate opzioni, vediamone alcune delle principali, consiglio comunque di dare sempre un'occhiata alla relativa pagina di man per un prospetto completo.
-d directory
: Passa alla directory specificata prima di eseguire il backup o il restore dei file.
-N nomefile
: Esegue il backup solo dei file più recenti dell'ultima modifica al file specificato. Utile per i backup incrementali (vedi man).
-p password
: Indica la password da utilizzare per accedere alla risorsa condivisa.
-r
: Esegue il restore della risorsa condivisa dal file .tar specificato.
-s nomeserver
: Indica il nome della macchina che serve la risorsa condivisa interessata.
-t nastro
: Può essere una device, un'unità nastro o un file. Se non definito il default è la variabile di ambiente $TAPE e se non esiste il file tar.out.
-u utente
: Indica l'utente con il quale si desidera connettersi alla risorsa condivisa. Si può specificare anche la password nella forma nomeutente%password.
-x risorsacondivisa
: Permette di specificare il nome della risorsa condivisa a cui si desidera accedere. Di default usa backup che è un nome comune per risorse dedicate al backup e al restore.
Vediamo un esempio dell'uso del comando:
smbtar -s nomepc -x nomeshare -u nomeutente -p password -t backup.tar
SOURCE: Pagina man del comando. -
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-06-04 11:08:27
Ci sono diversi modi di accedere a risorse condivise con SMB e uno di questi è usare smbclient. Il suo uso non si discosta molto dall'usare un normale client ftp fuorchè il fatto che utilizza un diverso protocollo.
Questo comando è considerato tra i più usati della suite Samba. Non solo è una comoda utility per trasferire files da e verso risorse Samba ma ne permette anche l'archiviazione, è utile per il testing del server e per controllare quali servizi sono attivi.
La sua sintassi è:
smbclient //server/risorsa [-opzioni]
Le opzioni di smbclient sono molte, consultare la pagina man del comando per averne un prospetto completo, vediamo qui alcune delle più importanti.
-s config_file
: Permette di specificare un file di configurazione di Samba da usare.
-M NetBIOS_name
: Questa opzione permette di inviare un messaggio WinPopUp ad una macchina della rete. Una volta stabilita la connessione si digita il messaggio terminandolo con un ctrl+D
. Non c'è modo di sapere se il messaggio è arrivato a destinazione o meno e il limite dato dal protocollo è che non si superino i 1600 bytes. Può essere utile il suo uso associato a cat, ad esempio cat messaggio.txt | smbclient -M PIPPO
-n NetBIOS_name
: Con questo comando posso scegliere un nome NetBIOS a mio piacimento. Se non specificato Samba usa il nome del'host locale con lettere maiuscole.
-h
: Stampa a monitor un brief delle principali opzioni.
-I
: Permette di specificare l'indirizzo ip di una risorsa condivisa a cui si vuole accedere. In questo modo si forza il client a non cercare assolutamente di risolvere il nome della risorsa e di connettersi alla macchina specificata.
-U username[%password]
: Con questa opzione mi è possibile specificare un utente e eventualmente una password da usare per accedere a una data risorsa.
-A nome_del_file
: Questa opzione può essere utilizzata al posto di quella appena vista e permette di specificare un file da cui attingere lo USER e la PASSWD. E' stata studiata principalmente per l'uso negli script. Si può specificare anche il nome del dominio. La sintassi è:
username = valore
password = valore
domain = valore
-L
: Questa opzione è utile in fase di testing e permette di listare tutte le risorse condivise di un dato host.
-W WORKGROUP
: Questa opzione può essere necessaria per collegarsi ad alcuni server e permette di specificare un diverso WORKGROUP (dominio) da quello specificato nel smb.conf per la connessione in oggetto.
-T opzioni_di_tar
: Questa opzione permette di lavorare sui file di una risorsa per scopi di backup e di restore. Ha numerose sotto-opzioni, fare riferimento alle pagine man di smbclient per un prospetto completo. Vediamo un esempio di sintassi:
smbclient //server/nome_risorsa -Tsotto-opzioni
Le sotto-opzioni sono quasi complementari a quelle che usa il comando tar originale.
c
: Crea un nuovo archivio tar. Va seguito poi il nome dell'archivio.
x
: Estrae i file da un archivio.
N
: Sta per "newer than". Permette di archiviare solo i file più nuovi di un file che si specifica.
Quando si lancia senza paramentri smbclient si comporta come un client ftp da riga di comando e ci presenta un prompt così:
smb:\
In modalità interattiva si possono eseguire numerose operazioni, vediamone alcune:
?
: Questo comando stampa un lista informativa dei comandi e ne descrive brevemente il significato. Si può farlo seguire da il nome di un comando e stamperà una descrizione della sua funzione. Si può usare anche help
.
!
: Apre una shell sulla macchina locale. Si può farlo seguire dal comando che si vuole eseguire.
cancel id_stampa
: Permette di cancellare un job di stampa dalla coda sulla stampante. Va specificato il numero di job che si intende eliminare.
cd directory
: Permette di cambiare directory. Se usato senza specificare il path si comporta come pwd
mostrando la directory corrente.
del stringa
: Cancella dal server tutti i file della directory corrente che hanno una corrispondenza della stringa.
dir stringa
: Una lista di file contenenti la data stringa presenti nella directory di lavoro viene recuperata e mostrata.
exit
: Termina la connessione con il server e esce.
get file_remoto nome_file_locale
: Recupera un file definito e lo salva in locale con il nome specificato.
lcd directory
: Cambia la directory locale. Anche qui se non specificata la directory stampa il path della directory locale corrente.
ls stringa
: uguale a dir
.
mget stringa
: Permette di scaricare più di un singolo file o directory.
md
o mkdir
nome_directory: Crea una directory all'interno di quella attuale.
mput stringa
: Permette di mandare in upload più file o directory che hanno in comune la stringa specificata
print nome_file_stampa
: Stampa attraverso una stampante condivisa il file specificato.
put nome_file_locale nome_file_remoto
: Esegue l'upload di un file locale e se specificato lo rinomina nel nome dato.
queue
: Mostra la lista dei file in attesa di stampa.
rm stringa
: Rimuove tutti i file che hanno corrispondenza con la stringa data.
rmdir nome_directory
:rimuove la directory specificata.
tar
: Oltre all'uso dell'opzione -T in modo interattivo si usa questo comando. Supporta le stesse opzioni di -T.
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-06-04 11:07:47
Se una volta configurato il server Samba si desidera accedere alle risorse condivise come se fossero parte del filesystem Unix e non come se si accedesse ad una risorsa esterna, ad esempio usando smbclient, si dovrà "montare" la risorsa così come si montano le diverse partizioni del disco.
In questo modo sarà possibile eseguire operazioni sui file condivisi da una macchina Windows ad esempio come se si trattasse di file unix e quindi usando tutti i fantastici e versatilissimi comandi unix, grep, sort, df, du, ls, etc... etc.
Per far questo si utilizzano alcune utility fornite con il pacchetto Samba.
Smbmount, ristretta esclusivamente ai sistemi Linux è equivalente a usare il comando mount -t smbfs
. Per utilizzarla è necessario aver compilato i sorgenti assicurandosi che nel configure si sia abilitata l'opzione --with-smbmount
e bisogna accertarsi che il kernel abbia abilitato il supporto per il filesystem smb/cifs.
Smbmount è un demone e quindi una volta lanciato anche se si è smontata la risorsa continuerà ad essere attivo tra i processi listabili con un ps
o con top
. Per eseguire le operazioni si avvale del comando smbmnt.
Vediamo la sintassi e le opzioni possibili.
smbmount servizio punto_di_mount [ -o opzioni ]
Le opzioni si specificano separate con una virgola e con il modello chiave=valore, le più importanti sono:
username=arg
: Permette di specificare un utente con il quale accedere alla risorsa. Se non specificato verrà utilizzato l'utente dato dalle variabili di ambiente. Supporta anche l'uso di sintassi come user%password o user/workgroup o anche user/workgroup%password.
password=arg
: Permette di specificare una password. Se non definita si userà la variabile di ambiente PASSWD e se non trova nessuna password che vada bene, a meno che non si sia definita l'opzione guest, ci restituirà un prompt per digitarla.
credentials=nome_del_file
: Permette di definire un file esterno per la specifica dell'utente e della password. La sintassi del file sarà:
username = valore
password = valore
In questo modo si può evitare di avere queste specifiche in file condivisi da altri utenti nel sistema come /etc/fstab
.
netbiosname=arg
: Permette di specificare un nome netbios per la sorgente. Se non specificato viene usato il nome dell'host locale.
uid=arg
: Permette di specificare un utente che sarà proprietario per tutti i file presenti nella risorsa, si può specificare usando l'id numerico per l'utente o il suo nome.
gid=arg
: Permette di specificare il gruppo propietario per tutti i file della risorsa montata. Si può definire per id o per nome.
port=arg
: Specifica una porta diversa dalla standard 139 per comunicare con la risorsa remota.
fmask=arg
: Definisce i permessi dei file della risorsa montata. Se non specificato si usa la umask corrente.
dmask=arg
: Come sopra ma per le directory.
debug=arg
: Permette la specifica per il debug delle operazioni che si effettuano. Un valore consigliato può essere 4, se si specifica un valore troppo alto si rischia di avere troppi messaggi che impediscono poi la visualizzazione dei dati interessanti.
ip=arg
: Setta l'ip o il nome dell'host remoto a cui ci si vuole connettere.
workgroup=arg
: Permette di specificare il workgroup a cui si riferisce la risorsa condivisa da montare.
guest
: Non richiede una password.
rw
: Monta la risorsa in read and write mode.
ro
: Monta la risorsa in read-only mode
Una volta montata la risorsa la si può smontare con l'equivalente di umount, smbumount. Per la verità si è pensato a questo eseguibile per dare ai normali utenti più versatilità sulle risorse montate. Infatti questo comando è setuid ed è immaginabile che mettere setuid umount sia una cosa da pazzi. Root potrà comunque smontare le risorse con umount.
Non ha opzioni e la sua sintassi è:
smbumount punto_di_mount
I comandi appena descritti valgono per l'uso su sistemi Linux ma se si sta usando Solaris? O HP-UX?
Per questo è stato studiato un'altro metodo che, purtroppo ancora imperfetto e in via di sviluppo, permette di effettuare operazioni sui file di risorse condivise senza avere un supporto smbfs. Si abilita il suo uso in fase di compilazione dei sorgenti con l'opzione, da passare al configure
, --with-smbwrapper
e si utilizza per le operazioni l'eseguibile smbsh.
Smbsh quando lanciato fornisce un albero di directory sotto /smb
. Le sotto directory di /smb
corrispondono ai server e le loro sottodirectory agli share su disco e di stampa. Crea di fatto una subshell e i comandi impartiti dal suo prompt interagiscono con i file come se si trattassero di file locali al sistema unix della macchina.
Ha varie opzioni:
-d
: Setta il livello di debug dell'applicazione e quindi anche di log, i suoi valori vanno da 0 a 10. Il livello 0 registra solo i messaggi più importanti, l'uno è normale e da 3 in su è inteso solo per il debug visto il forte carico di lavoro a cui sottopone Samba.
-l file
: Imposta il nome del file di log da usare.
-P prefisso
: Imposta una divesa directory da /smb
su cui montare il filesystem SMB.
-R ordine
: Imposta l'ordine di risoluzione dei nameservers. Accetta i quattro paramentri lmhosts, host, wins e bcast in qualsiasi ordine.
-U utente
: Supporta il modo username%password
-W workgroup
: Imposta il workgroup NetBIOS al quale il client si connette.
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2004-06-04 11:06:42
Utility che permette di gestire (inviare comandi / messaggi ) ai demoni di smbd, nmbd e winbindd.
smbcontrol [ -d ] [ -s ] -i
oppure
smbcontrol [ -d ] [ -s ] destination message-type [ parameter ]
-d
Specifica il livello di debug (Accetta valori interi da 0 a 10)
-s
Specifica il file di configurazione
-i
Abilita l'interctive mode,
destination
Per destination si intende a quale processo dovrà essere inviato il messaggio, è possibile specificare sia l'ID oppure sia il nome: nmbd o smbd.
La differenza fra i due target nmbd e smbd oltre al nome del processo consiste nel fatto che il messaggio con destinazione nmbd viene mandato in modalità broadcast a tutti i processi nmbd attivi in quel momento mentre per smbd verrà inviato un singolo messaggio al processo con l'ID specificato nel pid file (smbd.pid)
message-type
Specifici che tipo di messaggio viene inviato. Ecco alcuni esempi:
- close-share
: Termina tutte le sessioni correnti dei client connessi alla share, come argomento si aspetta il nome della share.
- debug
: Setta il debug level
- force-election
: Forza l'elezione del master browser, unico target possibile è nmbd
- ping
: Invia dei ping ai processi evidenziati, stessa modalità dei pacchetti ICMP.
Come parametro si aspetta il numero di ping da inviare di conseguenza i PONG dei singoli processi.
- profile
: Invia un messagio ad un processo smbd per modificare i parametri del profile. I parametri possono essere settati ad on/off per attivarli o disattivarli oppure flush e count per azzerare o attivare i vari counter.
parameter
Parametri richiesti dal messaggio inviato, Es il livello di debugging o il numero di ping da inviare ad un certo processo.
Esempi:
Invio di ping ai processi nmbd
[root@trinity root]# smbcontrol smbd ping 1
PONG from PID 585
PONG from PID 30423
PONG from PID 29124
PONG from PID 29220
PONG from PID 29414
PONG from PID 29139
PONG from PID 29151
Abilitazione dell'interactive mode
[root@trinity root]# smbcontrol -i
visualizzazione dell'help
smbcontrol> ?
<destination> <message-type> <parameters>
<destination> is one of "nmbd", "smbd" or a process ID
<message-type> is one of: debug, force-election, ping, profile, profilelevel, debuglevel, printer-notify, close-share
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-04-04 21:24:55
Comando utile per debugging e gestione del servizio di smb, poichè permette di visualizzare a video un report sullo status delle connessioni.
smbstatus [opzioni] [-s configuration file] [-u username]
-s
Specifica il file di configurazione
-u
Visualizza solo le informazioni sull'utente specificato
-b
Visualizza un report minimo
-d
Visualizza un reposrt verboso
-p
Visualizza la lista dei processi smb
Visualizzazione dello status delle connessioni smb
[root@trinity root]# smbstatus
Samba version 2.2.7
Service uid gid pid machine
----------------------------------------------
nas root root 13039 castro (10.0.1.170) Fri Apr 4 10:26:33 2003
simone simone simone 12811 fox (10.0.1.163) Fri Apr 4 09:38:55 2003
fulvio fulvio fulvio 12808 yakumoscio (10.0.1.6) Fri Apr 4 09:37:55 2003
massimo massimo massimo 12803 blasco (10.0.1.18) Fri Apr 4 09:35:28 2003
IPC$ mas mas 12924 data (10.0.0.37) Fri Apr 4 09:48:48 2003
archive root root 13039 backup (10.0.1.70) Fri Apr 4 10:27:06 2003
aler aler aler 13266 jam (10.0.1.154) Fri Apr 4 11:05:53 2003
No locked files
Visualizzazione dei processi smb
[root@trinity root]# smbstatus -p
Samba version 2.2.7
Service uid gid pid machine
----------------------------------------------
13388
13039
[...]
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-04-04 21:27:21
Utility per il cambio della password di Samba.
smbpasswd [opzioni] [utente] [password]
-L
Permette di specificare le opzioni che solo l'utente root può utilizzare anche come utenti normali. Utilizzato per test o cambiamenti del file smbpasswd in locale.
-r remote hostname
Opzione che permette di specificare l'host remoto su cui cambiare la password per samba. Se si omette il valore di defaul è localhost
-t
Forza il cambiamento della password di un trusted machine account. Account creato per "registrare" la macchina nel dominio gestito dal smb server
-U username[%pass]
Opzione che permette di specificare, l'utente a cui verrà modificata la password. Opzione utilizzabile solo se affiancata all'opzione -r
-a
Opzione per aggiungere nuovi utenti nel file smbpasswd. L'utente che si vuole inserire deve già esistere come utente del sistema con la relativa entry nel file /etc/passwd
-s
Abilita il silent mode e si aspetta di leggere la nuova e vecchia password dallo standard input
-S
Permette di visualizzare il domain SID
-d
Opzione per disabilitare l'utente dal file smbpasswd in locale
-e
Opzione per abilitare l'utente dal file smbpasswd locale
-m
Opzione per specificare l'account è un account relativo ad un host
-n
Permette di settare la password a NULL
-x
Opzione che permette di cancellare l'utente dal file smbpasswd locale
-j Domain
Opzione utilizzata per registrare il server smb in un dominio NT
Nel caso in cui non venga specificato l'utente il comando interpreterà utilizzerà l'utente stesso che ha lanciato il comando per eseguire le operazioni.
Esempio:
Cambio della password dell'utente neo sul server smb trinity
[neo@dido neo]$ smbpasswd -r trinity -U neo
Old SMB password:
New SMB password:
Retype new SMB password:
Password changed for user neo
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-05-31 21:34:20
Un server Samba si compone di due principali demoni:
smbd per i servizi di condivisione di file e stampanti.
nmbd per il servizio di risoluzione dei nomi NetBIOS e di assistenza al browsing delle risorse.
Entrambi questi demoni si appoggiano al file smb.conf per funzionare e hanno opzioni da riga di comando specialmente per effettuare test e debug dei rispettivi servizi.
Smbd e nmbd necessitano di essere avviati insieme per poter garantire un funzionamento corretto del server Samba. E' consigliabile infatti far gestire il loro avvio da uno script di avvio e le principali distribuzioni vengono già fornite di comodi script come /etc/init.d/samba
anche se la loro posizione varia tra le diverse distribuzioni.
In altri casi si può usare il super-demone di gestione dei servizi inetd o infine si possono avviare da riga di comando ma a patto di essere l'utente root.
smbd: Come detto questo demone è responsabile della gestione delle risorse condivise, siano esse dischi o stampanti, tra il server Samba e i suoi client. Fornisce i servizi di condivisione dei file e delle stampanti, di browsing ai client di una o più sotto-reti e di gestione di tutti i messaggi di notifica che client e server si scambiano. Infine si occupa di autenticare gli utenti e di controllare le risorse condivise.
Smbd rilegge il suo file di configurazione automaticamente ogni minuto. Si può forzare il server a rileggere il suo file di configurazione con un SIGHUP. Ricaricare il file comunque non influirà sui client già connessi i quali dovranno sconnettersi e riconnetersi perchè le modifiche abbiano effetto.
Il modo esatto di lanciarlo e con l'opzione -D
che lo porta ad avviarsi come demone. Questa è anche l'opzione di default.
Le sue opzioni a parte quella appena descritta sono finalizzate al debug e sono principalmente ad uso degli sviluppatori. Con -h
si può avere la lista di queste, per approfondirle fare riferimento alla pagina di man.
nmbd: Questo demone è in realtà un semplice name server che imita le funzionalità di un WINS o di un NetBIOS name server. Ascolta e cattura le richieste per il name server e risponde con le informazioni in suo possesso. Si occupa inoltre di mantenere una lista per il browse delle risorse di rete e partecipa alla scelta del browsing. Se attivo il server WINS nmbd tiene il database dei nomi e degli indirizzi in un file chiamato wins.dat
. Un demone nmbd può anche rispondere alle richieste del protocollo di browsing delle Risorse di Rete di Windows. Il browsing è una serie di protocolli di annuncio, annuncio di servizi o di directory condivise che fornisce una directory dinamica che contiene i server e i dischi e le stampanti presenti nella rete NetBIOS. Se nmbd è il master browser locale mantiene i databases di browsing nel file browse.dat
.
Anch'esso se lanciato con l'opzione -D
si comporta come un demone andando in background e ascoltando sulla sua porta. Il resto delle opzioni anche in questo caso serve principalmente per effettuare test particolari e verifiche per gli sviluppatori. Con l'opzione -h
se ne può avere un brief veloce.
Documentazione e tool di configurazione di Samba |
Manuali, libri, documentazione online, risorse e tool grafici di configurazione su Samba |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-03 21:08:32
Quando ci si appresta a configurare approfonditamente un samba server ci si scontra inevitabilmente con la grande quantita di opzioni globali e di share. Averne un prospetto completo a mente è un'impresa titanica e a questo scopo ci si può avvalere di un comodo strumento di configurazione, swat.
Swat, Samba Web Administation Tool, viene comunemente installato con il pacchetto Samba e se si utilizza una distribuzione che installa la suite non necessita di ulteriori modifiche, a parte forse scommentarne la voce relativa nel file /etc/inetd.conf
a seconda della distribuzione.
In effetti si tratta di un servizio che viene generalmente invocato da inetd e fornisce un'interfaccia web utile per creare e modificare il file smb.conf e per studiarne le opzioni.
E' buona norma comunque se si vuole utilizzarlo controllare prima di tutto due file:
- /etc/services
e verificare che sia presente ed eventualmente aggiungere la voce:
swat 901/tcp
Definizione non ufficiale e che in alcune reti potrebbe entrare in conflitto con altri servizi
- /etc/inetd.conf
e verificare o aggiungere la riga:
swat stream tcp nowait.400 root /percorso/eseguibile/swat swat
Dove il percorso al file può variare a seconda della distribuzione usata o dove si è deciso di installare Samba
Una volta eseguite queste semplici operazioni si può aprire il nostro web browser preferito e digitare: http://localhost:901/
Ci apparirà una finestra che ci chiede di inserire nome utente e password e dovremo usare l'utente root e la sua relativa password di sistema.
A questo punto si ha accesso ad una serie di menu che in poco tempo ci permetterà di creare un file di configurazione per Samba. La cosa che trovo più utile e importante è che per ogni opzione settabile si ha un link ad un help che ne descrive il significato, i valori di default e così via. Non solo, prima l'ho descritto come tool anche per studiare, infatti sotto il menu HOME si ha la possibilità di accedere comodamente a un grande quantità di documentazione, pagine man e vari how-to, permettendo così di iniziare la nostra configurazione con un comodo appoggio per imparare.
Va ricordato che nonostante sia possibile collegarsi anche da macchine remote, swat non ha di default la possibilità di usare password crittografate con di conseguenza il rischio che qualcuno sulla rete possa sniffare i pacchetti e leggere in chiaro la password dell'utente root sul samba server. Esiste la possibilità di criptare le password anche se swat non lo supporta nativamente. Si può trovare un breve how-to introduttivo su www.samba.org chiamato swat_ssl.html.
Un'altro grande difetto di swat è il fatto che utilizzato su un file esistente ne modificherà anche il layout. Tutti i commenti eventualmente aggiunti e le opzioni include e copy verranno cancellati.
Questo ne fa a mio avviso un ottimo punto di partenza per il principiante, permettendo di creare un primo file di configurazione e in seguito editarlo finemente con un editor di testi.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-04 01:11:21
Se si ci si è appena avvicinati all'argomento e si desidera imparare a configurare un server Samba si avrà quasi certamente l'imbarazzo della scelta.
La documentazione non manca, a partire dal pacchetto dei sorgenti per arrivare a innumerevoli siti italiani e stranieri, passando per varie mailing-list.
Risorse locali
Innanzi tutto se si è scaricato il pacchetto contenente i sorgenti una volta scompattato si troveranno al suo interno alcune directory molto interessanti:
docs
e examples
Dentro docs troveremo tutta la documentazione necessaria, in html e in txt, molti howtos, le faq e un comodo pdf che raggruppa molti howtos: il Samba-HOWTO-Collection.pdf.
Di solito tutto questo materiale, se la propria distribuzione ha provveduto ad installare Samba si trova nella directory di sistema dedicata alla documentazione che generalmente si trova a partire dalla directory /usr
e se si è compilato dai sorgenti si troveranno questi file dove specificato dal configure
.
Come visto parlando dell'utility swat si può accedere a parecchia di questa documentazione nella sua pagina menu HOME.
Samba.org
Non dovesse bastare il primo posto dove cercare è dal sito di samba, www.samba.org.
Quando si accede alla pagina iniziale si trova una lista di mirror sparsi per il mondo. Attualmente ne esiste uno in Italia ma è per il download dei pacchetti, consiglio di usare un mirror vicino a noi per la visualizzazione del sito, tipo quello in Austria, di modo da non oberare di lavoro il server principale e anche per avere velocità di caricamento maggiori dovute alla vicinanza.
Molti how-to si trovano solo in questo sito, a volte perchè molto recenti, per questo consiglio vivamente a chiunque voglia cimentarsi seriamente con Samba di far diventare questo sito temporaneamente la sua homepage iniziale. Oltre alla documentazione sul sito si trovano tutte le mailing-lists ufficiali con le modalità di iscrizione e consultabili on-line.
Risorse online
A questo punto questo potrebbe essere sufficiente ma se si desidera approfondire basta andare su Google linux (www.google.com/linux) e cercare la parola chiave "samba" per trovare innumerevoli risorse. Anche se si cerca tra le pagine in italiano aggiungendo documentazione alle parole chiave si è proiettati in una spirale enorme di risorse.
Vediamo alcuni dei siti più interessanti per documentazione in italiano:
Esiste un libro, tradotto in italiano, che si chiama "Usare Samba" e comprabile in qualunque buona libreria convenzionata con la o'Reilly ma anche disponibile gratuitamente on-line all'url http://www.hopslibri.it/samba/root.html
Si tratta però della traduzione della prima edizione, tenerlo a mente perchè parecchie cose potrebbero e sono cambiate, resta comunque molto importante per comprendere meglio certi concetti che in lingua originale sono un po oscuri.
Un how-to che dà dei buoni spunti su cui lavorare si trova su
http://www.valtellinux.it/howto/samba/SMB-HOWTO.html
Un'altro how-to, tral'altro inserito nel mitico progetto "Appunti di informatica libera", è disponibile all'indirizzo
http://scuola.linux.it/docs/samba/samba.html
Un articolo che nello specifico tratta dell'implementazione di un samba server come Domain Controller in una rete windows:
http://mercury.chem.pitt.edu/~sasha/LinuxFocus/Italiano/March2002/article177.shtml
Per finire segnalo un simpatico sito che con un po di ironia offre alcune discussioni su problemi riscontrabili nella configurazione di vari servizi tra cui anche Samba raggiungibile su http://www.campana.vi.it/ottavio/linux/4pinguiniinpadella/4pinguiniinpadella.html
Mi sono fermato nella mia ricerca alla terza pagina di google ed ho omesso alcuni siti perchè trattavano argomenti basandosi su vecchie versioni di Samba o perchè fin troppo specifici. Come riscontrerete anche voi con un po di pazienza e delle ricerche mirate si possono trovare spunti e consigli utilissimi, raccomando di verificare sempre che il sito o l'how-to o il manuale trovati siano attuali prima di perdere i capelli chiedendosi perchè la tale opzione non funziona.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-06 00:28:28
Oltre all'ufficiale strumento di gestione swat compreso nella suite Samba in rete si possono trovare altri validi tool per configurare e lavorare con Samba.
Basta una semplice ricerca su freshmeat per accorgersi del grande numero di applicazioni disponibile.
Vediamo alcune valide alternative tra i tanti progetti presenti.
Utility di configurazione
Se si utilizza Webmin per amministrare il server ci si può avvalere di un suo modulo, solitamente installato di default ma scaricabile e installabile anche dopo in caso ad esempio si fosse in precedenza scelto di eliminarlo perchè inutilizzato.
Questo modulo permette di creare o editare il file smb.conf
, aggiungere shares e opzioni. Esiste anche un'altro modulo che non fa parte però di quelli standard di Webmin e che permette di editare i netlogon files, si chiama smblogin e si può reperire su freshmeat.
Smbconftool di cui ne parla bene anche lo stesso sito di Samba, è scritto in java e ha la peculiarità di non cancellare i commenti come invece fa swat. Si possono avere maggiori informazioni alla pagina http://www.eatonweb.com/samba/
I due principali Desktop Enviorment, KDE e Gnome, hanno entrambi la possibilità di usare delle applicazioni per configurare il server Samba.
Per Gnome esiste un progetto che però al momento il sito non è raggiungibile e si chiama Gnosamba.
Per KDE invece esiste un plugin per il Control Center che permette di abilitare un'interfaccia in cui poter settare praticamente quasi tutte le opzioni di configurazione e di creare, distruggere, modificare gli shares. Il suo nome è KSambaPlugin ed è disponibile su freshmeat.
Ci sono altri strumenti per la configurazione di Samba, scritti in linguaggi differenti e a volte nati per configurare server Unix e poi allargati alla gestione del smb.conf.
Utility per lavorare
Esistono svariati progetti per utilizzare gli strumenti della suite Samba quali smbclient o smbmount. Spesso si tratta di semplici frontend che utilizzano i comandi di Samba altre volte sono applicazioni più complesse.
xSMBrowser è una comoda GUI che permette di usare smbclient da un'interfaccia grafica. In se può essere paragonato a client ftp come gftp o kbear e infatti la somiglianza è grande, ci presenta una finestra con il filesystem locale e una con il filesystem remoto. Permette tutte le operazioni che si possono fare con smbclient.
Un'altro comodo frontend è Jags o Jagsmm acronimo per "Just another gnome samba-client" usa le librerie gtk e fornisce un'interfaccia al comando smbmount permettendoci di esplorare la rete e di montare le risorse disponibili.
A jags si appoggia una comoda utility trovabile su freshmeat, SambaSentinell che è una GUI in gtk per il comando smbstatus, permette di controllare lo stato dei samba server e delle relative connessioni ai loro share, mostrando l'utente connesso, il suo ip, i file che ha usato e addirittura di "uccidere" un processo in atto. In realtà questo strumento non richiede espressamente la presenza di jags ma se si vuole abilitarne la funzione di montaggio delle risorse condivise si deve averlo installato e funzionante.
LinNeighborhood è un'altra semplice GUI a smbmount e permette di effettuare il browse delle risorse condivise e di montare quelle di interesse.
I due principali desktop enviorment, KDE e gnome, sono dotati entrambi di applicazioni per esplorare networks Samba e per montare gli share.
Per gnome esiste Gnomba progetto a quanto pare rimasto offline per un certo periodo e ora ripreso. Il programma si può scaricare alla pagina http://gnomba.sourceforge.net/. Permette di scansire la rete alla ricerca di risorse condivise, offre un'interfaccia per la navigazione delle stesse e infine permette di montare localmente gli share.
Per KDE si trovano vari progetti tra cui komba2 che avvalendosi di praticamente quasi tutti gli strumenti di samba (smbmount, smbstatus, nmblookup, testparm) permette di navigare tra le risorse condivise e accedere agli share montandoli in locale.
Configurazione di Samba |
File di configurazione e settaggio dei parametri base e avanzati. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-03-25 17:14:42
La configurazione di Samba (i demoni smbd e nmbd) viene gestita dal file smb.conf, un normale file di testo ASCII con queste caratteristiche di massima:
- I parametri di configurazione vengono forniti nella forma opzione = valore
- Il file viene diviso in più sezioni che definiscono una share (condivisione), oltre alla sezione generale [global]
. Ogni sezione si indica fra parentesi quadre: [printers]
- Le righe di commento sono precedute da asterisco (#) o punto e virgola (;)
- Righe di configurazione possono estendersi su più righe di smb.conf utilizzando una backslash (\) a fine riga
- Le opzioni e i valori sono case insensitive, ma se si indica un path nel file system questo è case sensitive
- Per separare una serie di valori possono essere usati sia virgole (,) che spazi vuoti ( )
- Possono essere utilizzate delle variabili, precedute dal simbolo percento (%) all'interno dei valori (es: path = /home/%u
)
- Si può includere a smb.conf un altro file di configurazione con l'opzione include (es: include = /etc/samba/smb.conf.%a
)
Le opzioni di configurazione possono essere di 2 tipi fondamentali:
- global, appaiono solo nella sezione [global] e definiscono i comportamente generali del server Samba
- share, appaiono all'interno di specifiche share e definiscono il comportamento riguardo alla specifica share. Se appaiono in [global] definiscono i comportamenti di default.
Qualsiasi opzione deve essere inclusa una una sezione. Esistono le seguenti sezioni speciali:
[global] Sempre presente, di solito ad inizio file, definisce le opzioni di default valide per tutte le condivisioni (possono essere sovrascritte da opzioni contrarie presenti nelle specifiche sezioni) e i parametri generali di configurazione del server.
[printers] E' una sezione speciale utilizzata per condividere l'accesso via rete a delle stampanti
[homes] E' una sezione speciale che coincide con la home directory di un utente autenticato. Di fatto è una condivisione generica con il nome dell'utente che accede a Samba.
Oltre a queste sezioni speciali ne possono esistere un numero arbitrario di altre, il nome di ogni sezione coincide con il nome della relativa condivisione, così come appare al client SMB.
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-05-07 12:50:04
La sezione [global] è praticamente presente in ogni smb.conf.
Qui si definiscono le configurazioni generali riguardanti il server Samba e i suoi comportamenti di default.
Vediamo nel dettaglio alcune opzioni:
CONFIGURAZIONI BASE NETBIOS
Netbios name
Definisce il nome NetBios della macchina, così come viene visualizzato in rete. Di default coincide con il nome DNS per la parte relativa all'host (es: pippo.dominio.it prende di default il nome PIPPO). Es:
netbios name = PLUTONE
Server string
E' il commento che si può leggere visualizzando i dettagli su un host in rete. non è indispensabile ma può essere utile per indicare le funzioni o le caratteristiche della macchina. E' possibile usare variabili, per esempio:
server string = File Server - Samba %v (%h)
Workgroup
Definisce il workgroup di cui fa parte il server Samba. Di default il valore è "WORKGROUP", definito in fase di compilazione, ma può essere cambiato. Es:
workgroup = INTRANET
Netbios aliases
Questa opzione permette di assegnare più nomi NetBios allo stesso server oltre a quello definito con netbios name, in modo da farlo comparire fra le Risorse di rete di Windows come macchine diverse, su cui è necessario eseguire login autonomi, anche se di fatto restano lo stesso server. Questa funzionalità può essere utile. per esempio, per raggruppare su un singolo server diversi server SMB che prima risiedevano su macchine diverse senza modificare alcun parametro sui client. Es:
netbios aliases = vendite marketing amministrazione
GESTIONE DEL NETWORKING
Hosts allow - Hosts deny
Queste opzioni definiscono l'accesso al server. Hanno la stessa logica dei file /etc/hosts.allow e hosts.deny, possono essere presenti sia nella [global] che definiti per singola share. Come argomento si aspettano l'IP di una network o di un host (considerando che la rete 192.168.0.0/24, per esempio, si indica 192.168.0.) oppure un singolo hostname (pippo.dominio.com) o un nome di dominio o sottodominio (.dominio.com).
Sono accettati anche gli argomenti speciali ALL (tutti gli IP) e EXCEPT, seguito da indirizzi o nomi di host.
Samba segue una logica ben precisa per gestire gli accessi con queste opzioni:
- Se non sono definite, viene permesso l'accesso da ogni IP
- Se sono definite nella [global] queste si applicano ANCHE per le singole share (anche se si sono specificate a livello di share)
- Se esiste solo hosts allow
viene permesso quanto specificato come argomento e vengono esclusi tutti gli altrti IP
- Se esiste solo hosts.deny
sarà permesso l'accesso a tutti gli IP tranne a quelli specificati come argomento
- Se esistono sia hosts allow
che hosts.deny
vengono esclusi TUTTI gli IP tranne quelli che sono presenti in hosts.allow E non sono presenti in hosts.deny.
Nell'esempio che segue viene dato accesso a 192.168.0.10 e a tutti gli host della rete 10.0.0.0/24 tranne 10.0.0.15:
hosts allow = 10.0.0. 192.168.0.10
hosts deny = 10.0.0.15
Questo esempio corrisponde a:
hosts allow = 192.168.0.10 10.0.0. EXCEPT 10.0.0.15
Se invece si vuole permettere l'accesso solo alla rete 192.168.0.0/16 si può scrivere semplicemente:
hosts allow 192.168.
che coincide con:
hosts deny = ALL EXCEPT 192.168.
Interfaces - Bind Interfaces only
interfaces
definisce su quale interfacce di rete dell'host locale Samba si metterà in ascolto. Di default Samba utilizza l'interfaccia di rete principale, ma se si vuole che resti in ascolto su altre interfacce o si vuole essere certi che Samba scelga l'interfaccia voluta, queste vanno specificate tramite il loro indirizzo IP:
interfaces = 10.0.0.3/24 192.168.0.4/255.255.255.0
Il comando bind interfaces only
può avere valore yes
o no
(default). Se viene abilitato Samba ignorerà ogni pacchetto, anche di broadcast, che origina da rete diverse da quelle specificate con interfaces
. Notare che se si abilita, è necessario includere esplicitamente il localhost (127.0.0.1) nell'elenco delle interfacce su cui Samba deve stare in listening.
bind interfaces only = yes
GESTIONE DEL LOGGING
Log file
Specifica su quale file Samba va a scrivere i suoi log. L'argomento può contenere delle variabili, per cui è possibile avere diversi file di log per ogni utente, per tipo di client ecc. Per creare un log diverso per ogni client NetBios, per esempio, si può scrivere:
log file = /var/log/samba.log.%m
Log level
Specifica il livello di logging da usare, va da 0 (minimo) a 10 (estremamente verboso). Il valore di default è 1, su un server normale dovrebbe essere di 1 o 2, se si deve fare un po' di troubleshooting usare il livello 3, valori superiori servono soprattutto a chi sviluppa su Samba e rallentano notevolmente le operazioni:
log level = 2
Max Log Size
Definisce la dimensione massima in Kilobyte dei file di log. Quando viene raggiunto il limite, il file di log viene rinominato aggiungendo il suffisso .old (vengono eliminati eventuali file .old esistenti creati precedentemente) e si riparte con un file di log vuoto. Il valore di defalt è 5000 Kb, il valore suggerito dipende fondamentalmente dallo spazio su disco disponibile, evitare di impostare un valore troppo alto che rischia di occupare tutto lo spazio (considerando anche il file .old):
max log size = 2000
Debug Timestamp
Con questa opzione è possibile specifcare se inserire data e ora per ogni riga di log generata. Coincide con l'opzione timestamp logs
. Il valore di default è yes per cui nei log sono indicate data e ora in cui avvengono gli eventi. Per non specificare il timestamp scrivere:
debug timestamp = no
Syslog e syslog only
Queste opzioni regolano la possibilità di usare il demone syslog, invece o parallelamente al logging diretto.
Per poter usare il syslog è necessario compilare Samba con configure --with-syslog
e configurare /etc/syslog.conf
per gestire la facility daemon. Ad esempio con una riga tipo:
daemon.* /var/log/daemon.log
Il valore specificato (da 0 a 10, default 1) indica quali messaggi di log inviare a syslog e, in riferimento agli argomenti dell'opzione log level, cosa loggare direttamente sui file di log interni. Ad esempio:
log level = 3
syslog = 2
Con queste opzioni i log di livello 0 e 1 (inferiori a 2) vengono mandati a syslog, quelli di livello 2 e 3 (compresi tra syslog e log level) vengono scritti sul file di log interno.
Per loggare solo su syslog si deve attivare l'opzione syslog only:
syslog only = yes
GESTIONE DEL BROWSING
Local master - Domain master
Queste opzioni servono per spingere Samba a cercare di diventare rispettivamente Local Master Browser (il server che mantiene la browse list per una rete IP) e Domain Master Browser (il server che mantiene la browse list per un intero workgroup, anche esteso su più reti IP, nel qual caso raccoglie e coordina lo scambio di browse list dai Local Master Browser remoti). Di default Samba ha attivata l'opzione Local Master (con cui semplicemente gli viene detto di partecipare alle elezioni, senza la certezza di vincerle) e non ha attivata l'opzione Domain Master (è bene che il Domain Master Browser sia la stessa macchina che fa eventualmente da Primary Domain Controller, sia esso un Samba o un Windows server). Le impostazioni di default sono quindi:
local master = yes
domain master = no
Preferred Master - OS Level
Con queste opzioni si gestisce il comportamento di Samba nelle elezioni e la sua possibilità di vincerle.
La prima impone a Samba di chiamare un'elezione ogni volta che entra in rete e gli imposta una probabilità leggermente superiore di vincerle rispetto ad altre macchine con lo stesso livello. E' bene impostarla a yes quando si configura Samba come Domain Master Browser o Local Master Browser:
preferred master = yes
domain master = yes
E' comunque raccomandabile non avere troppe macchine in rete (Windows o Samba) che cercano di partecipare alle elezioni per evitare inutili e ripetuti broadcast e possibili incongrenze sulla browse list di riferimento.
L'opzione OS Master, invece setta esplicitamente il livello con cui Samba si presenta alle elezioni. Può avere valore da 0 a 255, più è alto e maggiore la possibilità di diventare Master Browser. Un valore di 34 basta per far vincere tutte le elezioni con server Windows ad eccezione di un PDC. Il valore di default è 20. Il seguente esempio dovrebbe bastare per vincere ogni elezione (ovviamente ad eccezione di altri server Samba con un OS level superiore):
os level = 65
.
Announce As - Announce version
Queste opzioni definiscono come Samba si presenta in rete. Announce as può avere come valori Win95, NT o WfW il default è:
announce as = NT
Announce version specifica la versione di Samba. Attualmente si presenta di default come:
announce version = 4.9
Generalmente non serve cambiare queste impostazioni di default.
remote browse sync - remote announce
Queste opzioni permettono di sincronizzare la browse list di un server Samba quando esistono diversi local master su reti diverse.
La prima permette di richiedere la sincronizzazione della brose list dai server delle reti remote specificate:
remote browse list = 10.0.0.255 192.168.0.255
Con la seconda opzione si può esplicitamente annunciare il server locale, con un workgroup arbitrario, ai server sulla rete remota specificata:
remote announce = 192.168.0.255/WROKGROUP
In entrambi i casi si possono indirzare direttamente gli IP dei server remoti o gli indirizzi di broadcast della loro rete (in questo caso il "directed broadcast" deve poter essere consentito sulla rete remota, di default i router Cisco non lo permettono).
GESTIONE DELLE PASSWORD
E' importante configurare la logica con cui Samba gestisce l'autenticazione e come eventualmente sincronizza le sue password con quelle di sistema. I dati relativi agli utenti sono mantenuti nel file smbpasswd
, che a sua volta si può modificare con l'omonimo comando shell.
Sulla gestione delle password esistono varie opzioni di configurazione.
encrypt passwords
Di default ha valore NO, non prevedendo l'invio in chiaro delle password via rete. Sui Windows recenti, comunque, (tutti esclusi NT4 pre SP3 e Windows 95) le password vengono inviate criptate. Per cui o si modifica il registro (esiste .reg adatto nel tar.gz ufficiale) sui Windows o, meglio, si abilita la criptazione delle password:
encrypt passwords = yes
.
password level
Di default samba esegue il matching delle password in lowercase (con caratteri minuscoli), compresa la prima lettera.
Password level permette di specificare, come nel caso di username level, quante lettere al massimo si possono rendere maiuscole per i tentativi di connettersi ad una smb share.
password level = 2
null password
Abilita o Disabilita la possibilità di utilizzare password (cryptate e non cryptate) pari a null.
Il valore di default è NO.
password level = yes
smb passwd file
Specifica il path del file contenente le password cryptate.
Il valore di default è : /usr/local/samba/private/smbpasswd
smb passwd file = /etc/samba/smbpasswd
CONFIGURAZIONE DEI DOMINI
SAMBA permette di usufruire dei domini di windows in varie modalità:
- PDC, samba può essere configurato come primary domain controller per i client windows/unix.
- BDC, (backup domain controller) features non del tutto funzionante per le versioni correnti (2.x), occorre aspettare la versione 3.x per avere il supporto completo.
- Host, facente parte di un dominio esistente.
Di seguito sonon riportate alcune opzioni utili per configurare il logon dei client nel dominio:
domain logons
Permette di loggarsi nel dominio tramite samba configurato come PDC server.
domain logons = yes
logon script
Specifica lo script che verrà lanciato sui client una volta loggati nel dominio.
logon script = logon.bat
logon home
Specifica l'home dell'utente, per i comandi DOS NET.
logon home = \\server\home\%U
logon path
Identifica la locazione dei roaming file.
logon path = \\server\profile\%U
RISOLUZIONE DEI NOMI CON SAMBA
E' possibile utilizzare una o più delle seguenti modalità di risoluzione dei nomi:
- Broadcasting
- LMHOST file
- Unix /etc/host o NIS
- WINS (Windows Internet Name Service), samba ha la facoltà di appoggiarsi ad un WINS server esterno oppure configurare lo stesso SAMBA per fungere da WINS server.
name resolve order
Opzione che permette di specificare con quali metodi e il rispettivo ordine da utilizzare per la risoluzione dei nomi.
name resolve order = wins hosts bcast
wins server
Permette di appoggiarsi ad un wins esterno specificando semplicemente l'IP, sarà SAMBA stesso a ridirigere le singole richieste al server specificato.
wins server = 10.0.0.100
wins proxy
Abilita il forwarding di tutte le richieste di risoluzione dei nomi anche ad WINS che sono esterni alla subnet del SAMBA server.
wins proxy = yes
wins support
Abilita il WINS server di SAMBA.
wins support = yes
dns proxy
Permette di appoggiarsi al DNS configurato sul server SAMBA (/etc/resolv.conf) per la risoluzione dei nomi fallita tramite WINS.
dns proxy = yes
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-05-31 21:47:24
Client per il managment delle ACL delle share SMB in un server NT.
smbcacls //server1/share1 filename [options]
Opzioni Comuni:
-U
Opzione per specificare l'utente utilizzato per conettersi al servizio remoto
-A [acls]
Aggiunge una ACL all'access list specificata
-D [acls]
Elimina le ACL specificate in linea di comando
-n
Visualizza le ACL in formato numerico
Formato ACL:
Le ACL sono formate da singole o più entry separate dalla virgola o più semplicemente ogni entry deve corrispondere ad una nuova linea. Esempio:
Specifica il numero della revisione della ACL lato NT server
REVISION:<revision number>
Owner e Group specificano owner e group sid dell'oggetto
OWNER:<sid or name>
GROUP:<sid or name>
ACL
ACL:<sid or name>:<type>/<flags>/<mask>
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-05-16 15:25:24
Le opzioni inserite nella sezione [share] fanno riferimento alla configurazione da applicare alla singola risorsa condivisa o alle share di sistema come [netlogon] o [printer] per abilitare/disabilitare alcune funzioni di samba stesso.
CONFIGURAZIONI BASE PER LE SINGOLE SHARE
Le seguenti opzioni sono le tipiche opzioni utilizzate in tutti i tipi di share e ne definiscono i caratteri generali come per esempio il nome della risorsa che si condivide.
[nome share]
Il nome delle singole share è settato con la seguente entry [nome share] nel file di configurazione dopo le opzioni relative alla sezione [global].
[docs]
path
Sinonimo di directory, indica il path locale della risorsa da condividere tramite Samba.
Nel caso in cui la share si riferisce ad una stampate identifica la directory che avrà la funzione da spool per la stampante stessa.
path = /home/docs
comment
E' possibile affiancare un commento al nome delle share, che verrà visualizzato lato client. Utile per descrivere il contenuto della risorsa.
comment= Documenti comuni
GESTIONE ACCESSI
La gestione degli accessi alle risorse può avvenire in vari modi a seconda del tipo di configurazione adottata nelle global options.
valid users - invalid user
La prima opzione viene utilizzata per specificare gruppi o utenti che possono accedere alla risorsa, la seconda invece per negarne definitivamente l'accesso.
valid users = pippo pluto joe
admin user
Determina quali utenti che accedono alla risorsa possono eseguire operazioni da utente root.
admin user = joe
guest ok
Abilita l'accesso alla risorsa all'utente guest.
guest ok = yes
guest account
Unix account utilizzato come guest access. L'account di default è nobody.
guest account = webmaster
guest only
Di default settata a no, limita l'accesso alla risorsa all'utente guest.
guest only = no
writable (write ok) -read only
Opzioni utilizzabili sia nella sezione global che share permette di abilitare o disabilitare gli attributi di scrittura.
I valori di default permettono la sola lettura (read only = yes e writable = no).
read only = no
writable = yes
browsable
Nega o permette la visualizzazione nella lista delle risorse del server samba. Di default è settata a yes.
browsable = yes
read - write list
Opzioni che permettono di eseguire un override della configurazione base di una share per la lista degli utenti specificati.
Rispettivamente, read list permette l'accesso con i soli diritti di lettura ad una share scrivibile mentre write list specifica quali utenti possono accedere, anche con i permessi di scrittura, ad una risorsa configurata per acconsetire gli accessi in sola lettura.
write list = webmasters developers
max connections
Specifica il numero massimo di connessioni ad una share. Settata di default a 0, permette connessioni illimitate alle risorse.
max connections = 10
SYSTEM SHARE
Samba prevede delle share con un nome specifico per abilitare alcune features o lo sharing di risorse particolari come stampanti.
netlogon
Share indispensabile nel caso in cui samba server faccia da PDC, permette il logon dei client nel dominio. Questa share deve avere le seguenti caratteristiche:
- Il nome non è modificabile, [netlogon]
- Non è possibile visualizzarla e scriverci.
- Non è possibile accederci come utente guest.
[netlogon]
Comment = share to domain logon
path = /samba/logon
public = no
writabl e = no
browsable = no
profile
E' possibile specificare tramite la share [profile] la risorsa che dovrà fungere da repository per tutti i roaming profile. Questa share non deve essere visualizzata nelle risorse dispobilli del server ma deve essere possibile scriverci.
[profile]
comment = Profili Utenti
path = /samba/profile
create mode = 0600
directory mode = 0700
writable = yes
browsable = no
homes
Share che visualizza in modo automatico la home dell'utente, senza dover mettere le relative entry nel file smb.conf per i singoli utenti. Tale share che prende il nome dell'utente è visibile e scrivibile solo dall'utente con cui si è eseguito il login sul server.
[homes]
comment = Home Directories
valid users = %S
read only = No
create mask = 0664
directory mask = 0775
browseable = No
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Roberto 'rpennol' Pennolino - Ultimo Aggiornamento: 2004-06-02 15:46:11
Esiste la possibilità di vietare il salvataggio di files con una determinata estensione in una cartella condivisa tramite SAMBA.
Occorre semplicemente aggiungere nella sezione [global] del file smb.conf
(/etc/samba/smb.conf) il seguente parametro:
veto files = /*.mp3/ /*.wav/ /*.mpeg/ /*.avi/
In questo caso non è permesso il salvataggio di files con estensione: mp3, wav, mpeg ed avi.
SMB troubleshooting |
Utilizzo dei log, del debug e di altri strumenti di diagnosi. |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-01-19 13:34:11
Il mondo delle reti CIFS presenta insidie di varia natura, il protocollo è a suo modo contorto e le implementazioni di diversi produttori possono dar luogo a problematiche diverse.
Per diagnosticare problemi con Samba esistono vari strumenti a disposizione degli utenti:
- I log di Samba stesso
- I vari tool Samba presenti nel pacchetto ufficiale
- Genericamente, i vari strumenti di sistema disponibili su Unix e Windows per diagnosticare problemi di rete e servizi.
I LOG DI SAMBA
Sono tipicamente fra le prime cose da guardare. Nel file di configurazione è possibile definire vari parametri tra cui:
log file = %m.log
- Il nome e la logica con cui vengono salvati i log (possono essere divisi per utente, macchina ecc);
debug level = 2
- La verbosità dei log stessi, con valori che vanno da 0 (nessun logging) a 10 (maggimo debugging). Un valore di debug di 3 o superiore è già fin troppo verboso e va usato solo per diagnosi, in quanto tende a rallentare il sistema.
E' possibile modificare il livello di logging inviando al processo smbd i segnali SIGUSR1 per incrementarlo di uno e SIGUSR2 per diminuirlo di uno.
UTILITY SAMBA
Varie sono le utility di Samba per diagnosticare problemi.
testparm
serve per verificare la correttezza della sintassi del file di configurazione e per verificare se un dato host può collegarsi alla macchina Samba locale (sulla base delle access list di smb.conf, altri impedimenti dovuti a iptables o altro non sono contemplati): testparm hostname 10.0.0.150
, per esempio, elenca per tutte le condivisioni del proprio sistema, se l'host 10.0.0.150 ha diritto di accesso.
smbclient
è comodo per enumerare le condivisioni di un server e capire come e cosa esporta. smbclient -L 10.0.0.150
enumera tutte le condivisioni di 10.0.0.150. Viene chiesta una password, dare invio per fare un accesso anonimo o specificare -U utente
(e poi relativa password) per accedere con specifiche credenziali.
nmblookup
si usa per ottenere i nomi NetBIOS e i relativi IP degli Host in rete, tramite broadcast o query diretta, nmblookup -d 3 '*'
, per esempio, individua, nella propria rete (dominio di broadcast), gli host che rispondono ad una query nmb.
UTILITY UNIX
La diagnosi di problemi con Samba coinvolge anche problematiche di rete: server e client devono poter comunicare via IP e avere accesso alle porte netbios-ns 137/udp, netbios-dgm 138/udp, netbios-ssn 139/tcp e microsoft-ds 445/tcp (usata da CIFS, se non è raggiungibile si usa la 139) non ci devono quindi essere firewall o altri impedimenti che impediscano lo scambio di dati.
La diagnosi inoltre coinvolge l'effettiva esistenza di un server in ascolto sulla porta 139 o 445 e l'eventuale sniffing dei pacchetti in transito. Comandi utili per queste attività sono:
ping
Comando tipico per testare la connettività di rete IP fra due host, in ogni caso da affiancare a un test diretto tipo telnet 10.0.0.150 139
per verificare se alla porta 139 del server indicato risponde qualcosa.
Su un server Samba, per verificare che il servizio sia partito e sia in ascolto e disponibile in rete, digitare netstat -natp
e cercare righe tipo tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 4608/smbd che indicano che il processo smbd è in ascolto (LISTEN) sulla porta 139 su tutti gli indirizzi (0.0.0.0, basterebbe anche l'indirizzo dell'interfaccie di rete).
Verificare inoltre che non si siano firewall esterni o interni che impediscano l'accesso alla prota 139 tcp (con iptables -L -n
si visualizzano le regole di firewalling sul proprio Linux).
Se il client può accedere via rete al server e su questo è in esecuzione il processo che gestisce SMB, eventuali problemi possono essere dovuti al protocollo SMB/CIFS stesso (autenticazione, ecc), per cui possono essere utilizzati i comandi Samba sopra indicati o si può provare a diagnosticare cosa accade sniffando direttamente i pacchetti con strumenti come tcpdump
(analizza solo le intestazioni dei pacchetti) o ethereal
(visualizza e analizza tutto il contenuto di un pacchetto).
A livello applicativo, sul server Samba, può servire utilizzare strumenti come ps -adef
per verificare che i processi smbd e nmbd siano in esecuzione, strace -p #PID
per analizzare a basso livello le chiamate di sistema del processo di cui si è indicato il PID, lsof
per visualizzare i file aperti dai processi in esecuzione.
Stampa e condivisione stampanti |
La stampa su Linux e la condivisione delle stampanti in rete. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2003-03-26 23:07:01
LPR (Line Printer Protocol) è il protocollo utilizzato per la comunicazione di stampa tra client e server, basato sul TCP. La porta sui cui va in ascolto è di default la 515, risponde a richieste provenienti dalle porte sorgenti da 721 a 731.
[pippo@SATURNO root]$ cat /etc/services | grep printer
printer 515/tcp spooler # line printer spooler
printer 515/udp spooler # line printer spooler
Nei sistemi Unix standard vi sono una serie di programmi che interagiscono con il processo di stampa:
- lpr ha il compito di gestire la coda di stampa
- lpq visualizza la coda di stampa
- lprm rimuove file dalla coda di stampa
- lpc programma di controllo della stampa e stampanti
LPRng di Patrick Powell è un altro software di stampa che migliora alcune funzionalità di sicurezza e portabilità rispetto a lpr.
LPRng può essere integrato con Samba, permette autenticazioni di stampa sicure supportando i principali software di crittografia.
LINK: SOURCE - http://www.ietf.org/rfc/rfc1179.txt?number=1179
LINK: SOURCE - http://www.lprng.com
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-23 22:16:41
Questo comando permette di visualizzare e modificare i settaggi per le opzioni e i valori di default da riga di comando.
La sua sintassi è complessa può variare a seconda del lavoro che si sta compiendo e può essere riassunta così
lpoptions [opzioni]
Un esempio:
lpoptions -h nome_server -d destinazione/istanza -o opzione=valore .... -o opzione=valore
Se lanciato senza argomenti mostra le opzioni settate per la coda di stampa di default. Le opzioni sono:
-E
: Abilita l'uso di connessioni criptate per comunicare con il server. Occorre aver abilitato il supporto OpenSSL per il server.
-d destinazione/istanza
: Specifica la stampante predefinita per la destinazione dichiarata. Se si utilizza un'istanza che, per chiarire, può essere paragonabile alla definizione di una coda si setta l'istanza come predefinita. Questa opzione sovrascrive la definizione della stampante di default per l'utente corrente.
-h nome_server
: Definisce il server cups con cui interagire.
-l
: Lista tutte le opzioni specifiche di stampa e indica con un simbolo asterisco *
quelle correntemente usate.
-o opzione=valore
: Permette la specifica delle varie opzioni. Con il chiave -l si possono ricavare le opzioni e i loro valori possibili.
-p destinazione/istanza
: Definisce la stampante o un'istanza a cui applicare le opzioni che si specificheranno. Se l'istanza non esiste ne viene creata una con il nome usato.
-r opzione
: Rimuove l'opzione specificata.
-x destinazione/istanza
: Rimuove tutte le opzioni per la destinazione o la coda definita.
Questo comando si appoggia su due distinti file di sistema. Uno, il principale, viene modificato quando l'utente root utilizza il comando e per installazioni di default si trova in /etc/cups/
e si chiama lpoptions
. Le definizioni in questo file coinvolgono tutte le destinazioni/istanze per tutti gli utenti. Per i settaggi del singolo utente queste informazioni sono salvate in un file all'interno della home dell'utente e si chiama .lpoptions
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-23 22:14:56
Oltre alla utile e pratica interfaccia web la suite Cups integra al suo interno vari comandi per la sua gestione e configurazione. Il comando lpadmin permette di configurare le stampanti e le classi con le rispettive code ed è utile conoscerlo in casi in cui si sia impossibilitati ad usare un browser.
Questo comando è molto utile se si deve abilitare la stampante predefinita, se si deve modificare code o stampanti, per aggiungere o eliminare classi e stampanti. La sua sintassi è
lpadmin [ opzioni ] destinazione/opzioni_stampante
Dove per destinazione si intende una stampante o una classe e le opzioni_stampante vengono specificate come vedremo dopo la chiave -o.
Le opzioni e le variabili settabili non sono moltissime:
-E
: Questa opzione può avere due significati diversi a seconda se utilizzata come opzione prima di ogni altra o di norma in fondo alla riga di comando. Nel primo caso implica l'uso di una connessione criptata con il server. Occorre aver configurato il server per l'uso di OpenSSL. Di norma se usata così necessita dell'opzione -h nome_server. Nel secondo caso abilita o disabilita la stampante, ha un significato equivalente ai comandi enable
e disable
.
-h nome_server
: Permette di specificare il server a cui inviare i comandi.
-c classe
: Aggiunge la stampante dichiarata alla classe.
-i interfaccia
: Si usa per specificare un file di interfaccia in sile System V, generalmente uno script, non può essere utilizzato con l'opzione -P file_PPD
-m modello
: Specifica un file System V o PPD situato nella directory dei modelli generalmente /usr/share/cups/model
.
-o opzione
: Questa chiave è molto importante e raggruppa sotto di se numerose sotto-opzioni per definire particolari specifiche per la coda.
-o nome=valore
: Permette di settare una opzione per un file PPD o una stampante.
-o job-k-limit=valore
: Specifica il limite di grandezza in Kilobyte su una base per singolo utente.
-o job-page-limit=valore
: Specifica il limite massimo di pagine stampabili in un singolo processo di stampa su una base per singolo utente. Le stampe su fronte-retro sono contate come due pagine.
-o job-quota-period=valore
: Specifica il periodo di accesso su una base per singolo utente. Il valore va specificato in secondi.
-r classe
: Rimuove la stampante dichiarata dalla classe. Se si sta eliminando l'ultima stampante di una classe quest'ultima verrà eliminata.
-u allow/deny:utente,utente
: [ -u deny:all; -u allow:none ] Specifica i permessi degli utenti su una specifica stampante.
-v device-URI
: Specifica il percorso per la device usata da una determinata stampante.
-D info
: Permette di specificare una descrizione della stampante.
-L locazione
: Setta una locazione per la stampante specificata.
-P file_PPD
: Specifica un file Postscript Printer Description da usare con la stampante.
-d destinazione
: Setta come default la destinazione per la stampante o la classe dichiarata.
-x destinazione
: Elimina la destinazione per la stampante o la classe dichiarata.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-23 21:56:29
Aggiungere una stampante in stile BSD in una rete Samba necessita di poche semplici configurazioni. Una volta configurato il sistema di stampa e accertato che tutto funzioni correttamente occorre per lo più lavorare sul file smb.conf.
In questo caso innanzi tutto si dovrà aggiungere alle opzioni [global] del server samba le seguenti direttive:
printing = bsd
printcap name = /etc/printcap
Con queste righe si specifica che si tratta di un sistema di stampa stile BSD e che il percorso del file di definizione delle stampanti è /etc/printcap
.
In seguito si dovranno definire lo share [printers] per le stampanti:
[printers]
comment = All Printers
security = server
path = /var/spool/lpd/lp
printable = Yes
create mask = 0600
browseable = No
e quello per la stampante specifica:
[deskjet]
security = server
path = /var/spool/lpd/lp
printer name = lp
writable = yes
guest ok = yes
printable = yes
print command = lpr -r -h -P %p %s
In questo modo si definisce il comportamento del samba server e con l'opzione print command si dichiara il programma di stampa e i parametri che ne regolano il risultato. In questo esempio si stabilisce inoltre che le autenticazioni sono gestite sulla rete SMB/CIFS da un server preposto ma questo non è obbligatorio.
Assicurandosi che il percorso specificato per la stampante corrisponda a quello inserito nel file printcap con una configurazione di questo tipo si può cominciare a stampare.
Essendo comunque un sistema complesso e ricco di variabili, tra cui ad esempio l'enorme numero di diversi modelli di stampanti in circolazione, è consigliabile fare riferimento alla documentazione ufficiale per configurazioni particolari.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-23 21:54:11
Per poter usare Cups in una rete windows, permettendo la stampa remota ai client Microsoft oppure usando una stampante condivisa da uno di essi, occorre utilizzare Samba che dalla versione 2.0.6 supporta l'interazione con questo potente sistema di stampa. Dalla versione 2.2 di Samba in poi si ha anche la possibilità di esportare i driver necessari per la stampa con Windows.
Gli accorgimenti da prendere per poter far stampare della macchine windows sulla rete usando una stampante linux configurata con cups non sono molti e riguardando in special modo la configurazione del server Samba.
Innanziutto occorrerà aggiungere alla opzioni globali i seguenti parametri
[Global]
printing = cups
printcap name = cups
A questo punto non dovrebbe essere necessaria alcuna altra configurazione per poter stampare attraverso cups anche se di norma sarà necessario definire anche la sezione [printers]
che permette a Samba di caricare come risorse condivise tutte le stampanti definite nel sistema di stampa e di configurarne alcuni parametri specifici.
[printers]
comment = All Printers
path = /var/tmp
printable = Yes
create mask = 0600
browseable = No
Volendo si può inoltre esportare i driver necessari ai client Windows e a tale scopo viene in aiuto un comodo comando cupsaddsmb che permette di esportare i drivers cups.
Una volta scaricati i driver e copiati nella directory drivers
all'interno della directory radice che di norma si trova in /usr/share/cups
e facendo attenzione perchè i nomi siano in maiuscolo si configura smb.conf aggiungendo lo share [print$] nel modo che segue
[print$]
comment = Printer Drivers
path = /var/lib/samba/drivers
write list = root
create mask = 0664
directory mask = 0775
A questo punto configurate le share [printers]
e [print$]
si può usare il comando cupsaddsmb per esportare i drivers.
Un comando di questo tipo aggiunge i driver a tutte le code di stampa per l'utente root
#cupsaddsmb -U root -a
L'opzione -a serve a specificare tutte le code configurate nel sistema cups.
Questo comando permette anche di aggiungere coda per coda in modo di permettere una configurazione fine della stampa remota per i client windows.
Se invece si desidera raggiungere una stampante condivisa da una macchina Windows usando cups si possono usare due metodi:
Il primo usa l'implementazione del protocollo lpd e il TCP/IP Printing Service di Windows mentre il secondo usa il protocollo SMB/CIFS.
All'interno di /usr/lib/cups/backend/
la directory in cui si trovano quei programmi che permettono a Cups di interagire con le device, dovrebbe trovarsi un link simbolico chiamato smb che punta al comando smbspool
, se non è così è necessario crearlo.
Infine con il comando lpadmin o con l'interfaccia web di amministrazione si creeranno le definizioni delle diverse code e stampanti che usano come device URI delle stringhe nella forma
smb://server/nome_risorsa
smb://workgroup/server/nome_risorsa
smb://user:pass@server/nome_risorsa
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-01-21 12:35:14
Il file di configurazione principale del sistema di stampa cups. Gestisce principalmente il comportamento del demone che fornisce i servizi di stampa e di amministrazione attraverso la sua interfaccia web. Permette di definire se occorre l'uso di cifratura delle comunicazioni, definire gli accessi alle risorse del server e se il server debba o meno notificare con messaggi broadcast la sua presenza e le code disponibili sulla rete.
Generalmente a installazione compiuta si ha un esempio di questo file con tutte le opzioni e i loro valori di default all'interno della directory di cups in /etc o dove specificato in fase di compilazione. Le direttive all'interno del cupsd.conf sono davvero molte e se i commenti del file non bastassero la sua documentazione è ampia. In se la sua struttura è uguale a quella di Apache così come la sua sintassi.
I valori di default a parte qualche configurazione fine possono andare benissimo specie in network non troppo grossi e con un traffico di rete medio.
Un file strutturato in questo modo potrebbe andare benissimo per un server in una piccola rete locale:
#cat /etc/cups/cupsd.conf
LogLevel info
Port 631
Browsing Off
BrowseAddress 192.168.0.255
< Location />
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
Allow From 127.0.0.2
Allow From 192.168.0.*
</Location>
In questo caso definisco l'accesso alla radice del sistema cups. Permetto così ai client remoti di stampare attraverso questo server, la location /printers che non è definita perchè "eredita" i settaggi della location radice /. Per questa direttiva non è specificata alcuna autenticazione degli accessi
< Location /admin >
AuthType Basic
AuthClass System
Queste direttive permettono di specificare l'autenticazione per la location /admin basata su una verifica degli utenti nel sistema, appartenenti al gruppo di sistema modificabile con la direttiva Systemgroup. Si specificano sempre racchise in un'istanza < Location>
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
</Location>
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-14 15:24:06
Cups è a tutti gli effetti il sistema di stampa proposto come autorevole sostituto dei metodo di stampa BSD.
Rivoluziona l'intero concetto di stampa, gestendo i filtri in proprio e infatti incorpora molti di questi programmi al suo interno ad esempio una versione specifica di ghostscript.
Il sistema cups utilizza un protocollo derivato da http chiamato IPP (Internet Printing Protocoll, rfc 2568) e incorpora un server http che gli permette di mantenere un'interfaccia amministrativa via web in ascolto sulla porta 631. Per determinare il comportamento di questa interfaccia e in generale del sistema di stampa si lavora sul file di configurazione cupsd.conf
che solitamente si trova dentro /etc/cups
. Questo file ha una sintassi ispirata al file di configurazione di Apache. In questo file si specificano il nome della macchina, il linguaggio di default, i parametri di accesso e la directory radice del sistema, tutti i parametri specifici della applicazione, file di log e comportamenti particolari in caso di eventi differenti.
Cups inoltre gestisce le informazioni necessarie all'elaborazione dati per la specifica stampante usata tramite dei file contenenti istruzioni di tipo MIME, chiamati file PPD e generalmente posti in /usr/share/cups/model/
.
Con cups si è in grado di configurare stampanti locali e inoltre permette di aggiungere stampanti remote sia che utilizzino il protocollo IPP che LPD. Supporta inoltre la stampa via SMB in un network Samba.
Con il comando lpadmin si possono aggiungere od eliminare stampanti logiche, inoltre una volta definite si possono abilitare o disabilitare e si possono definire le policy per i processi di stampa. In questo modo si ha la possibilità di amministrare i comportamenti di una determinata stampante. Se si disabilita una stampante questa continuerà ad accettare comunque i processi di stampa inserendoli nella sua coda e senza stamparli mentre se si è definito che deve rifiutare i processi di stampa non verrà accodata nessuna stampa.
Si possono stabilire inoltre delle classi che riuniscono sotto di se diverse stampanti, permettendo così una gestione anche di gruppo. Se un utente invierà un processo alla classe sarà cups a stabilire a quale stampante va inviato. Le classi accettano gli stessi parametri enable e disable, accept e refuse in modo da permettere una gestione complessiva per gruppi di stampanti logiche. Va tenuto conto tuttavia che le stampanti logiche non subiscono le direttive riferite ad una classe sicchè si può disabilitare una classe ma far elaborare processi di stampa ad una stampante del gruppo.
Le informazioni sulle stampanti e sulle classi vengono memorizzate rispettivamente su i file /etc/cups/printers.conf
e su /etc/cups/classes.conf
, due file che volendo sono editabili a mano ma che generalmente si gestiscono sempre attraverso i comandi di amministrazione tra cui lpadmin.
Per lavorare con cups si utilizzano i comandi standard del sistema BSD, lp o lpr. Per definire code di stampa remote si utilizza una sintassi del genere nome-coda@host-remoto.
Per compatibilità con programmi che potrebbero richiederne la presenza, cups permette di aggiornare il file printcap
e nel caso si desiderasse mantenere intatto questo file per il suo uso con sistemi BSD esiste una direttiva di configurazione che permette di specificarne uno alternativo, anche perchè comunque al suo interno si troveranno le specifiche per le stampanti ma i record classici di specifica delle stesse non sono necessari.
Questo versatile e potente sistema di stampa permette di gestire anche delle direttive per i client.
Il file principale per questo è /etc/cups/client.conf
ma si possono definire direttive per singolo utente in un file chiamato .cupsrc
posizionato all'interno della home directory delllo stesso. Un uso classico di questi file che generalmente sono vuoti può essere quello di specificare un percorso di una stampante predefinita per un utente diversa dalla stampante predefinita sulla workstation.
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-14 15:36:17
Il file centrale di un sistema di stampa LDP, BSD da cui si definiscono le stampanti, le diverse code a loro assegnate e i filtri da utilizzare. Come tanti file di configurazione si tratta di un file di testo soggetto a particolari regole di sintassi.
In questo esempio si definisce una stampante predefinita chiamata lp o HP Deskjet950 connessa al computer via usb che ha assegnata una coda di stampa nella directory /var/spool/lpd/lp. I backslash servono a dichiarare una continuazione di riga e non sono obbligatori se si usa un sistema di stampa LPRng ma alcuni wizard di configurazione li usano probabilmente per maggiore portabilità.
# Stampante predefinita
lp | HP Deskjet950:\
:lp=/dev/usb/lp0:\
:sd=/var/spool/lpd/lp:\
:sh:\
:mx#0:\
:if=/percorso/del/filtro:
:lf=/var/spool/lpd/lp/log:\
:af=/var/spool/lpd/lp/acct:\
I record sono specifiche per una stampante e defiscono il comportamento della coda.
In questo esempio
lp la device configurata e connessa alla stampante
sh specifica se stampare un foglio separatore tra i differenti processi di stampa e in questo caso è impostato in modo da non stampare nessun foglio.
mx limita la grandezza massima dei file da stampare. Nell'esempio è impostato a zero, nessun limite.
sd specifica il percorso alla cartella utilizzata per la coda di stampa.
if input filter, definisce il filtro usato per la conversione dati.
Per gli ultimi due, il file di log della direttiva lf e il file di registrazione informazioni sui processi di stampa della direttiva af devono prima essere creati perchè il sistema di stampa possa scriverli.
Per aggiungere una coda di stampa remota si utilizzano i record rm e rp.
# Stampante condivisa in rete da un printserver
printserver:\
:sd=/var/spool/lpd/printserver:\
:sh:\
:mx#0:\
:if=/percorso/del/filtro:
:rm=printserver.esempio.com:\
:rp=lp:\
I quali rispettivamente indicano il server remoto su cui è disponibile la coda di stampa e il nome della coda remota da utilizzare. In questo caso si usa una coda remota in stile BSD.
Da notare inoltre che usando lp come nome della stampante si definisce il nome standard della stampante predefinita modificabile attraverso la variabile di ambiente $PRINTER.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-14 15:31:15
Esistono diversi sistemi di stampa per Linux, oltre al classico lpd o anche detto BSD system, si trovano parecchi progetti diversi che offrono sistemi di stampa. La scelta può essere dettata dalla distribuzione che si sta utilizzando ma nessuno impedisce di installare il proprio. Ovviamente occorre sceglierne uno visto che non si possono utilizzare due sistemi diversi contemporaneamente.
LPD
L'originale e ormai classico BSD Unix Line Printer Daemon, è stato lo standard Unix per anni.
E' praticamente disponibile su ogni versione di Unix e nonostante sia ormai superato è un valido sistema di stampa di base. Con stampanti moderne occorre un ulteriore lavoro di configurazione con l'ausilio di script per i filtri e programmi front-end.
LPD è anche il nome dato al protocollo di stampa descritto nella rfc 1179. Questo protocollo è di fatto lo standard per la comunicazione con networks di stampa.
Se si medita di utilizzare LPD è comunque consigliabile l'uso di LPRng che offre una più evoluta forma di configurazione e supporta la cifratura delle connessioni, praticamente ogni versione di Unix abbastanza recente dovrebbe utilizzarlo ma ognuno aggiunge e modifica per cui è veramente difficile stabilire quale versione di lpd si stia utilizzando.
Riferirsi alla documentazione del sistema operativo Unix installato per approfondimenti.
Esistono diversi sistemi front-end per usare lpd e vista la complessità dell'argomento è più semplice usarne uno per configurare le stampanti. Tra questi xpdq per la sua semplicità è consigliato da Grent Taylor il curatore del Printig-HOWTO ma le principali distribuzioni generalmente forniscono una propria interfaccia per la configurazione.
PDQ
L'autore di questo software ironizza con il significato di questo nome e lo definisce "Print don't Queue". In effetti questo sistema di stampa rivoluziona il concetto di stampa in stile BSD facendo effettuare il lavoro di elaborazione dati alla workstation. In un contesto di rete con un print server a cui si collegano le workstation evita di sovraccaricare di lavoro il server portandolo ad un miglioramento delle prestazioni ed evitando la perdita di processi di stampa. Infatti questo sistema fa effettuare tutto il lavoro di filtraggio all'utente che genera il lavoro. Questo può avere dei difetti in caso di elaborazioni complesse rallentando la macchina su cui si sta lavorando, inoltre con l'uso di particolari driver per stampanti ad alta risoluzione ghostscript deve effettuare tutto il lavoro di traduzione prima che il processo possa essere inviato e si rischia di attendere diversi minuti prima che la stampa inizi.
Nel pacchetto è compreso xpdq un comodo front-end che permette di configurare e aggiungere le stampanti. Maggiori informazioni sul sito del progetto http://pdq.sourceforge.net/.
LPRng
In molti unix recenti si userà questo software che in se migliora e perfeziona il classico lpd aggiungendo features come l'assenza di eseguibili SUID e il supporto di autenticazioni con PGP e Kerberos infatti potrebbe essere considerato un lpd con un occhio in più alla sicurezza.
Inoltre rende la configurazione di network anche molto grossi ( tante workstation, diverse stampanti) più semplice e mantenibile.
Sul sito ufficiale http://www.lprng.com/ si può trovare tutta la documentazione relativa al pacchetto.
PPR
Questo sistema di spooling è dedicato a sistemi di stampa Postscript ma ha la capacità di utilizzare anche ghostscript per l'uso con stampanti.
Maggiori informazioni si possono trovare sul sito http://ppr.sourceforge.net/
CUPS
E' un sistema di stampa che si pone come standard sostitutivo di LPD anche dal punto di vista del protocollo utilizzato, per il quale Cups utilizza una implementazione di IPP (Internet Printing Protocoll) un protocollo simile ad http.
Fornito di interfacce di amministrazione sia web che gui e anche di un'interfaccia a riga di comando è considerato un potente sistema di stampa. Supporta la stampa remota attraverso Samba. Puntando il browser all'indirizzo locale localhost:631
si accede all'interfaccia che permette di aggiungere stampanti, configurarle, controllare i processi in corso e quelli compiuti. Inoltre si può visitare il sito ufficiale all'indirizzo http://www.cups.org/, una sorgente riccha di documentazione e informazioni sui driver.
SOURCE: Printing-HOWTO - http://www.tldp.org/
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-14 15:27:41
Non tutte le stampanti possono essere utilizzate con Linux. Come capire se la propria stampante va bene e dove trovare la relativa documentazione.
Se la propria stampante è una stampante Postscript non si necessita di driver speciali. Nella maggioranza dei casi però si dovrà scoprire se per la propria stampante esiste il driver Postscript che sia in grado di generare dati in un linguaggio comprensibile dal modello che si possiede.
Per capire se la stampante che si possiede è supportata vi sono diverse risorse online dove andare a cercare e ovviamente all'interno della directory dedicata alla documentazione che varia e si può trovare generalmente a partire dalla directory /usr
.
Esiste inoltre un how-to chiamato Printing-HOWTO che se non installato con la distribuzione in uso può essere recuperato a partire dall'indirizzo www.tldp.org, il quale raccoglie realmente quasi tutto quello che occorre sapere per affrontare l'argomento e i riferimenti ad ulteriore documentazione più specifica.
Sul sito www.linuxprinting.org si trova oltre a molta documentazione sull'argomento, il database delle stampanti supportate con i riferimenti ai relativi driver.
Una volta trovati i riferimenti per la stampante occorre capire se il pacchetto Ghostscript installato comprenda anche il driver che serve con il comando gs -h
che ci restituirà una lista dei driver disponibili.
Le ultime versioni di ghostscript comprendono ormai il supporto per quasi tutte la ultime stampanti uscite e si possono trovare ulteriori riferimenti sul sito www.cs.wisc.edu/~ghost/ a meno che non si abbia acquistato un modello che lavora con driver proprietari dipendenti dalla piattaforma (generalmente Microsoft).
Queste stampanti si chiamano GDI; GDI è un'interfaccia di sviluppo concepita da Microsoft per la rappresentazione grafica. Il problema non è rappresentato dall'interfaccia di sviluppo ma dal fatto che queste stampanti sono indirizzabili solo attraverso un linguaggio di stampante proprietario.
Alcune di queste oltre alla modalità GDI supportano, previa configurazione, anche un linguaggio standard. Di solito la modalità viene stabilita al momento dell'installazione, sicchè se si è utilizzato un'altro sistema operativo e si è abilitata la modalità GDI occorre, utilizzando il primo sistema operativo usato, riportarla alla modalità standard. Per alcune di queste stampanti è possibile che esista anche un driver per Linux, fare riferimento alla documentazione acclusa alla stampante e visitare il sito del produttore.
LINK: Linux Printing con Database stampanti supportate - http://www.linuxprinting.org/
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-14 15:20:05
Prima di affrontare i diversi sistemi di stampa esistenti per Linux occorre comprendere il funzionamento dell'interazione tra il sistema operativo e la stampante.
Con Linux si comunica con le stampanti attraverso le code di stampa (print queue).
I dati da stampare vengono memorizzati temporaneamente nella coda da dove lo spooler si occuperà di inoltrarli alla stampante. Spesso i dati da stampare non si trovano nel formato giusto per poter essere inviati direttamente alla stampante e di solito devono prima essere convertiti in un formato comprensibile di modo che possano essere emessi correttamente.
I filtri della stampante si occupano proprio di questo lavoro di traduzione dei dati in un linguaggio comprensibile alla stampante e che permetta di stamparli mantenendo le loro forma originale.
Vediamo alcuni esempi di linguaggi di stampanti standard.
Testo in ASCII: La maggior parte di stampanti è in grado di emettere direttamente testi ASCII.
Postscript: E' il linguaggio standard di Unix/Linux e permette di stampare direttamente su stampanti Postscript. Queste stampanti sono molto costose a causa della complessità di questo linguaggio che costringe ad una laboriosa elaborazione dei dati per giungere al risultato finale. In più a causa di un mero problema di licenze i costi aumentano e vanno tenuti presente in caso si meditasse l'acquisto di una di queste potenti stampanti.
Ghostscript : In realtà non è un linguaggio bensì si tratta di un software che mantiene un database di driver per stampanti e si occupa di tradurre i dati in un linguaggio adatto alla stampante in uso.
Il processo di stampa avviene in questo modo:
1. L'utente o l'applicazione genera un incarico di stampa.
2. I dati vengono memorizzati temporaneamente nella coda di stampa da cui lo spooler li inoltra al filtro della stampante.
3. Il filtro della stampante determina il tipo di dati da stampare. Se i dati non sono Postscript vengono convertiti nel linguaggio standard, ad esempio se si tratta di dati ASCII con il programma a2ps vengono convertiti in dati Postscript. Se la stampante è Postscript i dati vengono elaborati e stampati. Nel caso in cui la stampante non sia Postscript, nella maggioranza dei casi quindi, il programma Ghostscript utilizzando il driver adatto al modello di stampante genera i dati specifici della stampante e li invia in stampa.
4. Una volta che l'incarico di stampa e stato correttamente inviato lo spooler si occupa di cancellare i dati dalla coda di stampa.
HOWTO: The Linux Printing HOWTO - http://ldp.openskills.info/HOWTO/Printing-HOWTO/index.html
HOWTO: The Linux Printing Usage HOWTO - http://ldp.openskills.info/HOWTO/Printing-Usage-HOWTO.html
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-23 22:20:46
Questo comando della suite Cups permette di monitorare i processi di stampa e visualizzare informazioni sulle stampanti e le code presenti nel server.
Nonostante la presenza della comoda interfaccia web per controllare i processi e lo stato delle stampanti cups include lpstat una comoda utility da riga di comando.
La sua sintassi:
lpstat -opzioni
Se usato senza alcuna opzione lpstat stampa a monitor tutti i jobs accodati per l'utente che lo ha lanciato. Le sue opzioni sono uguali per alcuni casi a quelle usate in lpadmin e lpoptions.
-E
: Forza l'uso di connessioni cifrate con il server.
-h nome_server
: Specifica il server con cui si vuole interagire.
-a stampante/i
: Mostra lo stato di una o più stampanti restituendo informazioni sull'accettazione dei processi. Se usato senza specificare la stampante mostra tutte le stampanti e le istanze/code configurate e che accettano i jobs.
-c classe/i
: Mostra le classi e le stampanti comprese nella loro dichiarazione. Se usato senza argomenti mostra tutte le classi presenti nel sistema e se non fosse presente neanche una classe non restituisce nessun output.
-d
: Mostra la destinazione di default.
-l
: Mostra una lista delle stampanti, delle classi e dei jobs attivi.
-o destinazione/i
: Mostra le code di stampa per la o le destinazioni specificate. Se si omette la destinazione mostra tutti i jobs in coda.
-p stampante/i
: Mostra le stampanti e se accettano o meno i processi di stampa. Se usato senza specificare una o più stampanti mostra queste informazioni per tutte le stampanti.
-r
: Permette di verificare se il server CUPS sia attivo o no.
-R
: Mostra l'ordine dei jobs nella coda di stampa.
-s
: Mostra un sommario dello stato delle stampanti includendo la destinazione di default, le classi e le stampanti membro per ciascuna classe e tutte le stampanti associandole alla loro device-URI. E' equivalente ad usare insieme le opzioni -d, -c e -v.
-t
: Mostra un elenco completo di informazioni di stato per tutte le stampanti e le classi definite, è equivalente ad usare insieme le opzioni -r, -d, -c, -a, -p, -v e -o.
-u utente/i
: Permette di verificare i processi di stampa attivi per l'utente specificato. Se usato omettendo l'utente si ottiene una lista dei jobs associati all'utente corrente.
-W numero_job
: Permette la verifica dello stato dei jobs in esecuzione e di quelli eseguiti.
Reti miste Windows - Linux |
Casi e situazioni comuni con rete miste Windows-Linux - WINS - PDC. |
Tipo Infobox: SAMPLE - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-04-29 11:10:09
Segue un esempio di configurazione di un PDC di un dominio NT4 che agisce anche da Master Browser e Wins Server.
[global]
workgroup = LAB42
server string = Samba Server PDC
log file = /var/log/samba/%m.log
max log size = 50
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
printcap name = /etc/printcap
# Segue una direttiva comoda per creare automaticamente degli account macchina su /etc/passwd quando un nuovo computer joina il dominio
add machine script = /usr/sbin/useradd -d /dev/null -g machines -s /bin/false -M %u
# Le direttive che indicano a Samba di fare il PDC e permettere il login sugli ost che fanno parte del dominio
domain master = Yes
domain logons = Yes
# Direttive riguardanti la funzionalità di Master Browser
preferred master = Yes
os level = 250
# Direttive riguardanti la funzionalità di Wins Server
dns proxy = No
wins support = Yes
idmap uid = 16777216-33554431
idmap gid = 16777216-33554431
[homes]
comment = Home Directories
read only = No
browseable = No
[printers]
comment = All Printers
path = /var/spool/samba
guest ok = Yes
printable = Yes
browseable = No
[Documenti]
path = /tmp
guest ok = Yes
[Privato]
comment = Documenti Privati
path = /var/log
read only = No
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-04-29 11:43:32
Samba può svolgere le attività di PDC, Primary Domain Controller, in una rete di client Windows (o mista).
Le funzionalità supportate sono:
- Login sul dominio (domain logon) per client Windows NT/2000/XP.
- Sicurezza a livello utente per client Windows 9x/ME (questi client non hanno il concetto di dominio, ma supportano il login su un dominio)
- Roaming profiles, per avere utenti che possono loggarsi su client diversi mantenendo il proprio ambiente.
- Browse list e master browser
- Policy di sistema in stile NT4
- Possibilità di ottenere la lista degli utenti/gruppi presenti sul PDC Samba
- Gestione Active Directory (introdotta, parzialmente, dalla versione 3.x)
Le funzionalità ancora non supportate sono:
- Possibilità di fare da Domain Controller in un dominio ADS (Active Directory)
- Utilizzo come BDC (Backup Domain Controller) in un dominio NT4 con PDC Windows.
Per configurare Samba come PDC di un dominio Windows è necessario:
1- Installare Samba su un server Linux/Unix (tramite sorgenti o RPM)
2- Configurare smb.conf
3- Creare directory per i roaming profile e i domain logons
4- Aggiungere le login e le password per gli utenti e le macchine del dominio
5- Configurare i client Windows per unirsi al dominio.
Le istruzioni che seguono si applicano sia alla versione 2 che alla 3, tranne per la parte relativa alla direttiva add machine script.
1- Installazione di Samba
L'installazione per un PDC non richiede particolari accorgimenti rispetto ad una normale installazione di Samba, tramite rpm o tar.gz.
2- Configurazione di smb.conf
Vediamo un esempio del file di configurazione di un Samba PDC. Varie impostazioni sono comuni a qualsiasi installazione Samba, alcune sono specifiche per un PDC (domain master = yes , security = user , encrypt passwords = yes), altre sono necessarie se si vuole supportare l'esecuzione sul client di uno script al login (logon script e condivisione [netlogon] ) o l'uso dei roaming profiles (logon path , condivisione [profiles]).
Valutare attentamente quest'ultima opzione: ha la comodità di separare l'uso di una singola macchina fisica da un singolo utente (tutti gli utenti possono usare tutte le macchine), ma comporta ad ogni login il caricamento o la sincronizzazione di tutti i "Documents and Settings" Windows fra il client e il server, con un potenziale carico sul network non indifferente e maggiori attese da parte dell'utente.
Fatto il login l'utente agirà sui file della macchina locale, che poi vengono a loro volta sincronizzati con quelli sul server al momento del logout.
[global] ; Settaggi generali (validi su ogni configurazione Samba)
workgroup = intranet E' il nome del Dominio e/o del Workgroup
netbios name = serverone E' il nome del server Samba
server string = Samba PDC - Versione %v La descrizione del server
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=8192 SO_RCVBUF=8192 Settings TCP consigliabili di default
; Settaggi per un PDC e un master browser
os level = 64 Imposta il valore con cui partecipare alle elezioni per il Master Browser
preferred master = yes Forza una elezione quando si avvia e vi partecipa con maggiori possibilità di successo
local master = yes Fa partecipare Samba alle elezioni per il Local Master Browser
domain master = yes La riga che indica a Samba di operare com PDC
; Gestione utenti e sicurezza
security = user Impone di autenticare gli utenti localmente. E' necessario su un PDC Samba
encrypt passwords = yes Cripta login e password in fase di autenticazione: obbligatorio su un PDC e necessario per interagire senza problemi con client Windows NT o successivi
domain logons = yes Permette ai client Windows di loggarsi sul dominio autenticandosi con il server Samba
hosts allow = 127.0.0.1 192.168.0.0/255.255.255.0 Permette l'accesso solo dal localhost e dalla rete 192.168.0.0/24
add machine script = /usr/sbin/useradd -d /dev/null -g machines -s /bin/false -M %u (Solo su Samba 3) Aggiunge automaticamente al sistema l'account di una nuova macchina che entra nel dominio
; Gestione logging
log file = /var/log/samba/log.%m Definisce la posizione dei log e indica di creare log diversi on i nomi delle rispettive macchine client
log level = 2 Imposta a 2 il livello di logging, visualizzando tutti i file letti e scritti
max log size = 50 Imposta a 50 Kb la dimensione massima dei file di log
; User profiles, home directory e netlogon (a queste configurazioni in [global] vanno SEMPRE aggiunte le definizioni rispettivamente di [homes] , [profiles] e [netlogon] riportate più sotto
logon home = \\%L\%U\.profile Definisce la posizione del file .profile (per client Win9x/ME) in \\nomeserver\nomeutente
logon path = \\%L\profiles\%U Definisce la posizione della directory profiles (per client WinNT/2k/XP) in \\nomeserver\profiles\nomeutente
logon drive = H: Crea l'unità di rete H: al login su client Windows
logon script = netlogon.bat Specifica quale script eseguire sul client ad ogni login. Lo script viene cercato nella directory definita nella condivisione [netlogon]
[homes] Share speciale, che definisce la posizione delle home directory
comment = Home Directory per ogni User Descrizione della condivisione
browseable = no E' bene non rendere pubblicamente visibile le home dei singoli utenti
writeable = yes Ogni utente deve poter scrivere nella sua home
[profiles] Share speciale dove vengono scritti i file di profilo per i gli utenti roaming. Ad ogni login e logout il suo contenuto viene sincronizzato con la cartella dei documenti sul computer locale (C:/Documenti/NomeUtente.dominio)
path = /home/profiles La directory locale sul server Samba dove sono salvati i profili. Qui vengono, automaticamente, create delle sottodirectroy con i nomi degli utenti
writeable = yes I profili sono sincronizzati con il client al login e al logout e devono essere scrivibili
browseable = no Come per le home, anche i profili non devono essere visibili agli altri utenti
create mask = 0600 La maschera con cui vengono creati i file: Pieni permessi all'owner, nessun permesso per gli altri utenti
directory mask = 0700 La maschera con cui vengono create le directory: per l'owner devono essere anche eseguibili (sfogliabili)
[netlogon] Condivisione speciale che contiene gli script che vengono eseguiti sui client Windows al login sul dominio. Devono essere eseguibili su Windows e possono essere utilizzati per varie operazione di amministrazione centralizzata (backup di dati locali, aggiornamento programmi o antivirus, mappatura di nuove condivisioni di rete ecc.)
path = /home/netlogon La directory sul server in cui sono contenuti, in sottodirectory con nome uguale al login dell'utente, gli script definiti con la direttiva "logon script"
read only = yes Questi script devono essere accessbili solo in lettura...
write list = @admin ... tranne agli utenti del gruppo (@) admin
browseable = no Questa è una condivisione di servizio che è inutile mostrare agli altri utenti
3- Creazione delle directory supplementari
E' importante creare directory per i profile e i netlogon definiti in smb.conf con nomi e permessi corretti.
Sulla base della configurazione di esempio sopra riportata vanno eseguite le seguenti operazioni sul server Samba (come root):
[root@sambaserver root]# groupadd admin Si crea il gruppo admin, composto da utenti che possono editare gli script di logon. Considerare che questi script sono particolarmente importanti, in termini di sicurezza, visto che vengono eseguiti sui client Window
[root@sambaserver root]# mkdir -m 0775 /home/netlogon Crea la directory /home/netlogon, leggibile ed eseguibile da utti gli utenti e modificabile solo da owner e ownergroup
[root@sambaserver root]# chown root.admin /home/netlogon Si imposta root come owner della directory e admin come gruppo (con permessi di scrittura)
[root@sambaserver root]# mkdir /home/profiles Si crea una directory per i profili (uguale a quella definita in smb.conf)
[root@sambaserver root]# chmod 1757 /home/profiles Si imposta lo sticky bit e si rende questa directory scrivibile da root e le sue sottodirectory gestibili dai rispettivi utenti, senza possibilità di modificare quelle degli altri
4- Aggiungere login e password
Gestire gli utenti di un dominio con Samba non è una procedura immediata e vanno considerati alcuni aspetti fondamentali:
- Samba utilizza come file delle password /etc/samba/smbpasswd
(di default) che presenta una riga per ogni utente (sia di un dominio che di un server con normale autenticazione). In questo file è prevista una riga (con login , password criptata e altri dati) per ogni utente.
- Per ogni utente presente sul file smbpasswd DEVE essere presente un rispettivo utente sul normale file degli utenti Unix /etc/passwd
. Questo perchè Samba agisce sul sistema locale come un normale processo Unix e, anche se viene eseguito come root, accede al filesystem con i permessi degli utenti secondo quanto configurato.
- Quando Samba agisce come PDC, oltre a creare una login (sia in /etc/samba/smbpasswd che in /etc/passwd) per ogni utente, si deve creare una login speciale per ogni macchina del dominio. Questa login, definita trust account o computer account ha il nome NetBios del computer seguito dal segno dollaro ($). Al primo login da parte del trust account viene generata una sorta di password che viene utilizzata per autenticare le comunicazioni fra il PDC e il client e assicurarsi che non ci siano altre macchine che possano unirsi al dominio con lo stesso nome NetBios.
- La gestione delle login (sia per gli utenti che per i computer, sia su smbpasswd che su passwd) può essere fatta in maniera manuale, con i comandi sotto riportati, o in maniera automatica, tramite l'uso della direttiva add user script
- Windows9x/ME anche se possono eseguire un login su un dominio, NON sono strutturati per essere dei client a pieno titolo di un dominio in quanto non ne rispettano le logiche di sicurezza e trust.
Per aggiungere un computer account al dominio manualmente seguire la seguente procedura:
[root@sambaserver root]# groupadd machines Crea un gruppo per tutte i computer account
[root@sambaserver root]# useradd -g machines -d /dev/null -s /bin/false nomeNetBios$ Aggiunge al sistema una login, membro del gruppo machines, senza home directory, senza shell, con nome uguale al nome NetBios della macchina seguito dal segno $. Notare che questo account serve a Samba per agire sul sistema, ma è bene che non possa essere utilizzato per una normale login.
[root@sambaserver root]# passwd -l nomeNetBios$ Viene messo un lock sulla password, in modo da lasciarla nulla e non renderla modificabile se non da root
[root@sambaserver root]# smbpasswd -a -m nomeNetBios Si crea un nuovo computer account per /etc/samba/smbpasswd e si imposta la relativa password. L'opzione -a permette di crearlo, se non esiste, l'opzione -m indica che si tratta di un machine account, il nome NetBios della macchina da aggiungere NON va seguito da $, in questo caso, in quando questo carattere viene aggiunto automaticamente. Non è necessario ricordare la password inserita in quanto viene gestita direttamente fra PDC e client del dominio
Se si vuole evitare di aggiungere a mano un nuovo account per ogni macchina del dominio, si può provare ad aggiungere, come sopra indicato, la seguente riga a smb.conf (valida solo per Samba 3):
add machine script = /usr/sbin/useradd -d /dev/null -g machines -s /bin/false -M %u
Verificare il path e la sintassi del comando useradd e assicurarsi di avere il gruppo machines già creato (groupadd machines
).
Per aggiungere a mano le login degli utenti (non delle macchine) del dominio:
[root@sambaserver root]# useradd pippo Aggiunge l'utente al /etc/passwd di sistema
[root@sambaserver root]# passwd pippo Gli imposta la password. Se l'utente non deve accedere al sistema Unix, impostagli una shell nulla in /etc/passwd
[root@sambaserver root]# smbpasswd -a pippo Aggiunge l'utente pippo a /etc/samba/smbpasswd e gli imposta la password
NOTA: Quando si configura un client Windows NT/2k/XP per farlo diventare parte di un dominio, viene richiesta una password di amministratore. In questa situazione si deve usare la login di root con la relativa password, per cui è necessario aggiungere l'utente root anche al smbpasswd:
[root@sambaserver root]# smbpasswd -a root
Notare che se per caso si cambia la password di root con passwd e non la si aggiorna anche con smbpasswd, la password che fa testo è la seconda, quella presente in /etc/samba/smbpasswd.
Per questo ed altri motivi, una volta creato un utente è buona cosa fare in modo che la sua password sul sistema Unix sia allineata con quella usata da Samba via rete. Per fare in modo che una password cambiata tramite Samba si rispecchi anche sul /etc/passwd locale si devono aggiungere a smb.conf simili righe di configurazione:
unix password sync = yes Imposta la sincronizzazione delle password fra Samba e il sistema Unix locale
La procedura di matching per gestire le richieste in output di passwd. Assicurarsi che sul proprio sistema siano utilizzate le stesse parole
passwd program = /usr/bin/passwd %u La riga di comando per cambiare la password Unix. %u è la login dell'utente
passwd chat = *New*UNIX*password* %n\n *Retype*new*UNIX*password* %n\n *Enter* new*UNIX*password* %n\n *Retype*new*UNIX*password* %n\n *passwd: *all* authentication*tokens*updated*successfully*
Purtroppo questa procedura non funziona al contrario: se si cambia con passwd una password Unix, si dovrà cambiarla a mano con smbpasswd per tenere sincronizzata la password Unix con la password Samba.
5- Configurazione dei client
La configurazione di un sistema Windows per unirsi ad un dominio, varia a seconda della versione:
Windows 95/98/ME:
- Verificare che sia installato il "Client per Reti Microsoft" fra le proprietà di rete
- Assicurarsi che il Client per Reti Microsoft sia selezionato come protocollo di rete primario (Pannello di Controllo -> Rete -> Logon di rete primario).
- Andare su Pannello di Controllo -> Rete -> Client per reti Microsoft -> Proprietà -> Logon su Dominio NT.
- Se si è configurata su smb.conf l'opzione "add user script", selezionare il checkbox Crea un Computer Account, altrimenti creare a mano sul server Samba un utente con il nome della macchina Windows.
- Inserire il nome del proprio dominio e cliccare OK.
Windows NT:
- Andare su Pannello di Controllo -> Rete -> Identificazione Rete -> Proprietà
- Selezionare Dominio e inserire il nome del prorio dominio
- Selezionare Crea un Computer Account
- Alla richiesta della password di un amministratore inserire la login e la password di root, ricordarsi che l'utente root deve essere aggiunto a smbpasswd.
- Dovrebbe comparire un messaggio che ci da il benvenuto sul dominio.
Windows 2000:
Le procedure sono uguali a quelle per Windows NT tranne che i settaggi di rete sono trovati sotto Pannello di Controllo -> Sistema -> Identificazione Rete (oppure, sul Desktop, cliccare col tasto destro del mouse sull'icona Risorse del Computer, selezionare Proprietà, cliccare sulla tab Identificazione Rete e sul tasto Proprietà).
Windows XP:
La procedura con Windows XP è più complessa (lamentele a Microsoft che usa cambiare le specifiche e le implementazioni dei suoi protocolli anche per rendere più complicata l'interoperabilità con soluzioni alternative).
Notare che solo XP Professional Edition può essere usato per far parte di un dominio, Windows XP Home Edition non può far parte di un dominio (Samba o Windows based).
- Aprire l'editor delle policy di Sicurezza Locale (Start->Pannello di controllo->Strumenti di Aministrazione->Criteri di protezione locali->Criteri locali->opzioni di protezione)
- Disabilitare la voce "Domain member: Digitally encrypt or sign secure channel (always)" (Membro di dominio: aggiunta crittografia of irma digitale ai dati del canale protetto (sempre) )
- Disabilitare la voce "Domain member: Disable machine account password changes" (Controller di dominio: rifiuta cambio password account computer)
- Disabilitare la voce "Domain member: Require strong (Windows 2000 or later) session key" (Membro di dominio: richiesta chiave di sessione avanzata (Windows 2000 o versioni successive) )
- Scaricare da Samba.org (http://de.samba.org/samba/ftp/docs/Registry/WinXP_SignOrSeal.reg) la patch per il registro WinXP_SignOrSeal. Per applicarla cliccare due volte sul file .reg e rispondere Si alle domande
- A questo punto ci si può unire al dominio come su Windows NT/2000: Tasto destro su Risorse del Computer, selezionare Proprietà, Nome del Computer e tasto Modifica uppure cliccare su Identificazione di Rete ed eseguire il Wizard.
Linux/Unix:
Anche dei sistemi Linux, ovviamente, possono unirsi ad un dominio con un PDC Samba e se sono dei file server, si può configurare Samba per permettere l'autenticazione tramite il dominio.
Su smb.conf ci devono essere le seguenti righe:
[global]
workgroup =
netbios name =
security = DOMAIN
encrypt passwords = Yes
password server =
preferred master = False
domain master = False
Ovviamente sul PDC Samba deve essere creato un computer account per il nostro Samba locale (con il nome specificato in netbios name) e, anche in questo caso, il computer locale deve preventivamente unirsi al dominio, con una procedura che è paragonabile a quelle viste sopra per client Windows. Sul Linux/Unix locale basta scrivere:
smbpasswd -j
Bisogna fornire la password di root del PDC Samba (ricordarsi che è la password salvata in smbpasswd e non in passwd/shadow, nel caso fossero diverse).
LINK: Sistemisti Indipendenti: Samba: PDC in rete locale - http://www.sistemistiindipendenti.org/modules.php?name=News&file=article&sid=42
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2006-03-26 18:57:04
Le possibilità di interoperabilità fra client e server Windows e Samba in una rete locale per la condivisione dei file sono varie e si possono raggruppare in due scenari di riferimento:
- Windows server con client misti (Windows, Linux/Unix, MacOS).
- Linux/Unix Samba server con client misti.
E' possibile configurare Samba per:
- Operare come Primary Domain Controller (PDC di un dominio NT, ma non Domain Controller di una Active Directory) di una rete mista, gestendo anche i profili di macchine Windows e il login sul dominio. Una simile opzione permette ad una macchina Linux con Samba di eseguire le stesse funzioni di un PDC di dominio NT.
- Operare come normale File Server per client misti. I metodi di autenticazione possono essere vari e a seconda del metodo utilizzato possono essere necessari diversi interventi sul server e sui client.
- Operare come Domain Member con le funzionaità di file server accessibili sulla base delle login e password del dominio. Samba può essere parte sia di un dominio NT (Samba 2 o superiori) che di una Active Directory (Samba 3 o superiori)
- Operare come WINS server (o essere configurato per utilizzare un altro WINS server). In questo caso la configurazione è semplice, rapida ed efficace, non presentando particolari problemi di compatibilità e interoperabilità.
- Operare come Master Browser in una rete mista.
Samba NON permette invece di gestire una macchina come Backup Domain Controller di un PDC Windows, non può essere un Backup Browser e non può essere un Secondary Wins Server.
Sul lato client, invece, non ci sono particolari problemi ad usare Samba per connettersi a server Windows o Linux: la condivisione di rete remota viene normalmente montata sul file system locale e ci si può normalmente accedere con i permessi concessi.
LINK: The Story of Samba: Linux's Stealth Weapon - http://www.linux-mag.com/1999-09/samba_01.html
HOWTO: The Samba 2.2 PDC FAQ - http://de.samba.org/samba/ftp/docs/htmldocs/samba-pdc-faq.html#AEN263/htmldocs/samba-pdc-faq.html
Samba security |
Breve rassegna della security history, problematiche attuali |
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-05-21 21:33:58
Nell'Aprile 2003 è stata resa pubblica una seria vulnerabilità in Samba che, sfruttando un buffer overflow nella funzione call_trans2open di trans2.c, permette di eseguire comandi arbitrari su un server remoto con i permessi con cui gira il processo Samba: root.
Praticamente il tipo di security bug più temibile e pericoloso.
Questa vulnerabilità (codice CVE: CAN-2003-0201) segue di poche settimane un altro problema nella gestione di pacchetti SMB/CIFS frammentati (CVE: CAN-2003-0085), un problema dovuto alla non corretta gestione del cambio delle password criptate (CVE: CAN-2002-1318) e un problema nella gestione di file reg (CVE: CAN-2003-0086).
Queste vulnerabilità sono effettivamente gravi e vengono solo parzialmente mitigate dal fatto che è improbabile che esistano server Samba direttamente accessibili da Internet.
Sono affette dal Remote Buffer Overflow della CAN-2003-0201 tutte le versioni precedenti la 2.2.8a (che rispetto alla 2.2.8 ha solo la correzione dell'errore) e la 2.0.10a. Non ne sono affette le versioni del branch 3.x. Anche il progetto parallelo Samba-TNG è vulnerabile fino alla versione 0.3.2 esclusa.
Sono già in circolazione degli exploit in grado di sfruttare questa vulnerabilità, per cui è assolutamente necessario aggiornare il proprio Samba server ad una versione patchata o installare ex-novo una versione corretta.
I casi citati sono indicativo di quanto sia importante avere sistemi aggiornati e, possibilmente, server Samba non direttamente accessibili in Internet.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-06-05 19:10:18
A titolo esemplificativo elenchiamo una lista di vulnerabilità di Samba nel corso degli anni.
L'elenco è stato ottenuto da Security Focus, in alcuni casi si applica a strumenti di gerstione (SWAT), in altri, in particolare gli ultimi elencati, si applica a versioni di Samba recenti, che vanno assolutamente patchate.
2003-05-16: Samba Multiple Unspecified Remote Buffer Overflow Vulnerabilities
2003-05-16: Samba 'call_trans2open' Remote Buffer Overflow Vulnerability
2003-05-16: Samba SMB/CIFS Packet Assembling Buffer Overflow Vulnerability
2003-05-14: Samba REG File Writing Race Condition Vulnerability
2003-05-02: Samba Server Encrypted Password Buffer Overrun Vulnerability
2002-09-18: Samba Improperly Terminated Struct Buffer Overflow Vulnerability
2001-11-03: Samba Remote Arbitrary File Creation Vulnerability
2001-06-28: Samba Insecure TMP file Symbolic Link Vulnerability
2000-11-01: SAMBA SWAT Symlink Vulnerability
2000-11-01: SAMBA SWAT Logging Failure Vulnerability
2000-11-01: SAMBA SWAT Logfile Permissions Vulnerability
2000-09-11: NT Authentication PAM Modules Buffer Overflow Vulnerability
1999-07-21: Samba Pre-2.0.5 Vulnerabilities
1999-06-01: SAMBA Long Password Buffer Overflow Vulnerability
SOURCE: Security Focus - Vulnerabilities Archive - http://online.securityfocus.com/bid
Il protocollo SMTP |
Simple Mail Transfer Protocol: sintassi base |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-06-04 11:50:33
Simple Mail Transfer Protocol (SMTP) è il protocollo utilizzato per trasmettere messaggi di posta elettronica tra due host.
SMTP utilizza il protocollo di trasporto TCP, ed in particolare un SMTP server rimane costantemente in ascolto sulla porta 25. Il server SMTP si occupa poi di trasferire i messaggi nelle caselle di posta (mailbox) dei destinatari, oppure qualora non fosse il diretto responsabile di queste, inoltrarli (operazione di relay) al server che provvederà a farlo. La sintassi dei comandi è case-insensitive, ed è composta da istruzioni seguite da uno o più parametri terminate da un CRLF (Invio).
Il protocollo è descritto nella RFC 821, ma lavora in stretta collaborazione con altri standard come la RFC 822 che descrive la sintassi degli headers della mail, la RFC 1049 che definisce le strutture dati per interpretare correttamente il contenuto delle mail e la RFC 974 che si occupa del routing delle mail tramite DNS.
Lo standard definito dalla RFC 821, aveva diversi limiti riguardanti per esempio la dimensioni dei messaggi oppure la trasmissione di mail non in inglese o diverse dal semplice plain text. Per ovviare a questa restrizione è stato necessario estendere il protocollo tramite la RFC 1425 riguardante le SMTP Service Extensions.
I principali comandi SMTP:
HELO
: Identifica il client SMTP al server SMTP;
EHLO
: E' possibile usare anche questo comando per identificarsi, se il server supporta le SMTP Service Extensions riponderà in modo positivo altrimenti con un errore di tipo 500 (Syntax Error);
MAIL FROM:
<indirizzo mittente>: Indicata la mailbox del mittente del messaggio;
RCPT TO:
<indirizzo destinatario> : Indica la mailbox del desinatario (Recipient). E' possibile specificare attraverso molteplici RCPT TO diversi destinatari;
DATA
: Indica al server che quanto digitato successivamente saranno i dati del messaggio di posta;
RSET
: Annulla i comandi (Reset) precedentemente inviati nella sessione SMTP corrente;
VRFY
<stringa>: Chiede al server se la stringa di testo immessa rappresenta un
nome utente presente ed in tal caso visualizza l'intero indirizzo;
HELP
: Visualizza i comandi disponibili sul server;
NOOP
: Non esegue nessuna operazione restituisce solo un messaggio 250 (Ok) se il server risponde;
QUIT
: Termina la sessione SMTP corrente;
Una sessione SMTP attraversa almeno sei fasi:
1. Il client SMTP contatta il server sulla porta TCP 25. Se questo è in ascolto e la connessione è accettata risponde con un messaggio 220 (Ready);
2. Il client chiede di stabilire la sessione SMTP inviando il comando HELO
seguito dal FQDN (Fully Qualified Domani Name). Se il server accetta rispondo con un messaggio 250 (Ok);
3. Il client indica il proprio indirizzo tramite il comando MAIL FROM:
<indirizzo mittente>. Il server risponde con 250 (Ok) per ogni destinatario accettato;
4. Successivamente il client indica al server i destinatari del messaggio tramite RCPT TO:
<indirizzo destinatario> ed il server risponde per ogni destinatario accettato un codice 250 (Ok);
5. Il client comunica al server l'intenzione di scrivere il corpo del messaggio con DATA.
Il server risponde con un codice 354 e indica come marcare il termine del messaggio. I campi come Date, Subject, To, Cc, From vanno inseriti tra i dati della mail;
6. Completato il messaggio da scrivere tramite .
il server memorizza la mail. A questo punto è possibile, scrivere un nuovo messaggio oppure inviare il comando QUIT
, dopo il quale il server invia i messaggi e risponde con un codice 221 (Closing) e la connessione TCP viene terminata;
Esempio di una sessione SMTP da linea di comando:
homer@Joker:~$ telnet smtp.springmail.it 25
Trying 195.130.225.171...
Connected to smtp.springmail.it.
Escape character is '^]'.
220 mail.springmail.it ESMTP Service (6.5.032) ready
Tramite il programma telnet viene contattato il server SMTP sulla pora TCP 25
E' possibile notare dal messaggio ESMTP Service che il server supporta le SMTP Service Extensions
HELO
250 mail.springmail.it Missing required domain name in HELO, defaulted to your IP address [62.10.125.229]
Il client si identifica tramite il comando helo (non iniviando un nome di dominio, viene utilizzato l'indirizzo IP)
L'autenticazione avviene con HELO anziché EHLO e quindi il client non usufruisce delle SMTP Service Extensions qui supportate
HELP
214-Valid SMTP commands:
214- HELO, EHLO, NOOP, RSET, QUIT, STARTTLS
214- MAIL, RCPT, DATA, VRFY, EXPN, HELP, ETRN
214-For more info, use HELP <valid SMTP command>
214 end of help
HELP QUIT
214-Syntax: QUIT
214-Purpose: request closing of the connection
214 end of help
Il client richiede una lista dei comandi disponibili tramite help e successivamente un aiuto per il comando QUIT
MAIL FROM:<[email protected]>
250 MAIL FROM:<[email protected]> OK
RCPT TO:<[email protected]>
250 RCPT TO:<[email protected]> OK
DATA
Inizia l'inserimento del corpo della mail
354 Start mail input; end with <CRLF>.<CRLF>
From:Homer
To:Arnaldo
Subject:Il protocollo SMTP
Ciao,
questa mail serve per illustrare
il protocollo SMTP
---
Arnaldo aka [Homer]
.
250 Mail accepted
Il comando "." punto termina l'inserimento del messaggio; Il server SMTP lo accetta
QUIT
221 mail.springmail.it QUIT
Connection closed by foreign host.
La connessione TCP termina e si ritorna al prompt
homer@Joker:~$
Il client di posta elettronica (Kmail, Outlook o Eudora) si occupa solitamente di comunicare con il server al posto nostro in base alla propria configurazione.
Installazione e gestione di Sendmail |
Installazione di Sendmail tramite RPM e sorgenti, file installati e posizioni. Gestione del servizio |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-06-02 12:03:57
Sendmail può essere lanciato in diversi modi per eseguire operazioni diverse.
Alcune opzioni possibili corrispondono a comandi con nomi diversi, che di fatto eseguono Sendmail con modalità specifiche.
A titolo di reference vengono elencate le principali opzioni con cui Sendmail può essere lanciato.
hoststat (sendmail -bh)
Stampa statistiche sullo stato persistente dell'host, con informazioni sulle mail che ha gestito. Questo è possibile solo se è attivata l'opzione HostStatusDirectory:
sendmail.cf: O HostStatusDirectory=/path/to/dir
sendmail.mc: define(`confHOST_STATUS_DIRECTORY',`/path/to/dir')
Con hoststat -v
vengono visuliazzate le righe di info per esteso.
purgestat (sendmail -bH)
Ripulisce (rimuove) tutte le statistiche sullo stato persistente dell'host, presenti nella directory definita con l'opzione HostStatusDirectory.
Questo secondo il manuale, di fatto, almeno sul Sendmail di RedHat 9, con attivata la suddetta opzione, questo comando non sembra avere alcun effetto.
mailq (sendmail -bp)
Visualizza l'elenco delle mail in coda. La directory in cui sono salvate è definita con l'opzione QueueDirectory:
sendmail.cf: O QueueDirectory=/path/to/dir
sendmail.mc: define(`confQUEUE_DIR',`/path/to/dir')
Di default è /var/spool/mqueue
newaliases (sendmail -bi)
Ricostruisce il database degli alias generando il file /etc/aliases.db
(di solito, se si usa il database db di default) rendnedo attive le modifiche fatte su /etc/aliases
.
Considerare che gli script di startup (/etc/init.d/sendmail start
) previsti in molte distribuzioni automaticamente prima di lanciare il demone Sendmail eseguono un newaliases.
smtpd (sendmail -bd)
Lancia Sendmail in daemon mode, lasciando il processo in ascoltro sulla porta 25 (di default) e restituendo la shell. E' la modalità tipicamente utilizzata su un server SMTP che riceve posta.
sendmail -bm (default)
Invocato con questa opzione di default Sendmail invia il messaggio che gli arriva in standard input ai destinatari specificati come argomento della command line.
sendmail -bs
Questa è la modalità con cui lanciare Sendmail tramite (X)inetd: viene invocato in foreground, accetta i messaggi in stdin, consegna il messaggio e si chiude. In server di posta che lo utilizzano in questo modo (e non come demone sempre attivo) è opportuno processare periodicamente la coda dei messaggi in uscita (crontabbando un sendmail -q
)
sendmail -bt
Entra in modalità di test, con cui è possibile verificare come funzionano le regole di instradamento della posta. Si presenta una shell in cui è possibile premere ? per visualizzare un elenco dei comandi possibili.
Utile per troubleshooting e debugging avanzati.
sendmail -C /path/to/sendmail.cf
Utilizza un file di configurazione alternativo rispetto al solito /etc/sendmail.cf o /etc/mail/sendmail.cf. Utile per test sulle configurazioni.
sendmail -q
Processa la coda di mail in uscita. Comodo se si non si vogliono aspettare i tempi preimpostati e si vuole immediatamente processare la posta in coda. Può essere lanciato anche mentre un'altra istanza di Sendmail è in esecuzione in daemon mode.
sendmail -q30m
Esegue Sendmail in background e processa la coda di posta ogni 30 minuti. Può essere utile su sistemi che si colelgano in dialup ad Internet per evitare di alzare una connessione ogni volta che c'è un messaggio in uscita.
sendmail [email protected]
Processa tutta la posta in coda che ha come destinatari degli indirizzi che terminano con @dominio.com
sendmail -d (sendmail -d0-99.1)
Esegue Sendmail in debugging mode, utile per ottenere una grande quantità di informazioni su come è stato compilato e come gestisce e processa le sue macro. Esistono numerose modalità di debugging, definibili con una coppia di numeri separati da un punto che definisce la categoria di debugging e il livello di verbosità.
Se non si specifica nulla Sendmail di default visualizza il debugging per tutte le categorie (0-99) con livello 1.
Notare che in modalità di debug Sendmail funziona normalmente, per cui è possibile scrivere l'indirizzo del destinatario e il corpo del testo (da concludere con un punto "." e un INVIO) e vedere come Sendmail processa il messaggio
Alcune interessanti parametri (il secondo valore, che indica il livello di debug, può arrivare a 127, ma si consiglia di non superare il valore 99, anche se spesso gli output sono uguali anche a differenza di livello):
sendmail -d0.20
- Visualizza informazioni sulla versione, le opzioni compilate, il nome locale e le regole di delivery
sendmail -d8.20
- Visualizza informazioni sulle procedure di DNS lookup per il record MX del dominio destinatario.
sendmail -d10.20
- Visualizza informazioni sul destinatario del messaggio
sendmail -d11.20
- Traccia informazioni sulla consegna del messaggio
sendmail -d21.2
- Traccia le macro per il rewriting degli indirizzi
sendmail -d27.9
- Traccia le operazioni di aliasing
sendmail -d31.2
- Traccia il processing degli header della mail
sendmail -d41.50
- Informazioni sulla coda dei messaggi
sendmail -d48.2
- Traccia le chiamate ai rule sets check_
sendmail -d0-99.3
- Visualizza informazioni di debug su ogni categoria, con livello di verbosità 3
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-06-02 12:43:02
Generalmente su gran parte delle distribuzioni Linux, Sendmail viene installato di default e in molti casi viene eseguito all'avvio per restare in ascolto sulla porta 25 del localhost.
In questo modo viene usato per inviare la posta locale, ma non rimande in ascolto su un indirizzo pubblico.
Il pacchetto con cui viene fornito è sendmail ma in molti casi, se si vuole usare Sendmail su un server di posta SMTP che deve ricevere posta via rete, è necessario installare anche il pacchetto sendmail-cf che contiene le macro M4 necessarie per processare il file /etc/mail/sendmail.mc
(avente un formato semplice e comodo da modificare) e generare il file di configurazione /etc/mail/sendmail.cf
(con una sintassi piuttosto complessa ed intricata.
Installazione da RPM
La procedura è la solita. Ecco un esempio su Fedora 2:
rpm -i sendmail-8.12.11-4.6.i386.rpm
Fra i file installati si segnalano:
/etc/mail/ La directory dove sono inseriti tutti i file di configurazione
/etc/mail/access Il file che definiscea chi Sendmail permette il relay e a quali host vengono rifiutati
/etc/mail/local-host-names L'elenco dei domini per cui Sendmail riceve posta
/etc/mail/sendmail.cf Il file di configurazione
/etc/mail/sendmail.mc Il file M4 "human readable" con cui viene generato sendmail.cf
/etc/rc.d/init.d/sendmail Lo script di avvio e gestione del servizio Sendmail
/etc/sysconfig/sendmail Parametri e impostazioni che definiscono con quali argomenti viene lanciato Sendmail
/usr/sbin/sendmail.sendmail Il programma sendmail vero e proprio, per permettere la coesistenza con altri MTA (Postfix) il comando /usr/sbin/sendmail è un link che punta al file /etc/alternatives/mta che a sua volta è un link al programma vero e proprio
/var/log/mail/statistics File di statistiche sui movimenti di posta
/var/spool/mqueue La directory che contiene i messaggi di posta in coda
Installazione da sorgenti
Compilare Sendmail dai sorgenti è particolarmente semplice. Basta scaricare dal sito ufficiale i sorgenti:
[al@localhost al]$ wget ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.11.tar.gz
Scompattarli:
[al@localhost al]$ tar -zxvf sendmail.8.12.11.tar.gz
Lanciare lo script Build che provvede a compilare i sorgenti (di fatto è un make):
[al@localhost al]$ cd sendmail-8.12.11 ; ./Build
Copiare i file nelle directory di installazione (bisogna avere i privilegi di root):
[al@localhost sendmail-8.12.11]$ su ; ./Build install
Configurazione di Sendmail |
File di configurazione e settaggio dei parametri di Sendmail |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-10-03 08:58:23
La configurazione di Sendmail tramite il file sendmail.mc risulta particolarmente comoda e semplice anche se bisogna sempre ricordarsi di processare questo file con il preprocessore di macro m4 per ottenere il file sendmail.cf effettivamente usato dal programma.
Per farlo basta una riga tipo:
m4 sendmail.mc > sendmail.cf
Le macro che permettono di convertire un file sendmail.mc nel file sendmail.cf sono generalmente distribuite indipendentemente dal pacchetto di Sendmail per permettere una gestione più agevole degli aggiornamenti.
Su Linux tipicamente sono presenti nel pacchetto sendmail-cf.*.rpm
Le caratteristiche sintattiche di base di un file .mc:
- Le macro sono definite con una riga tipo: define(macro,valore)
- Si possono utilizzare degli apici (il primo è inverso, il secondo dritto) per impedire che il preprocessori interpreti i contenuti di un argomento: define(`macro',`valore')
- Il preprocessore m4 analizza il testo in input come un flusso di caratteri, per evitare che venga interpretata una riga si usano i caratteri dnl (Delete through New Line) che possono essere usati sia come i # per commentare una riga:
dnl define(`macro',`valore')
(la riga di configurazione non viene considerata)
sia a termine riga per evitare che venga generato uno spazio vuoto nel file di configurazione:
define(`macro',`valore')dnl
(la riga di configurazione viene considerata e viene ignorato tutto quello che è scritto dopo dnl fino a fine riga).
Ricordarsi che gli argomenti delle macro sono generalmente messi fra apici (prima inverso: ` e poi dritto: ').
Per costruire un file di configurazione m4 minimo sono necessarie le seguenti direttive:
OSTYPE()
- OBBLIGATORIO. Esempio: OSTYPE(`linux')
Definisce il sistema operativo su cui gira Sendmail. Un elenco dei SO supportati può essere visibile in /usr/share/sendmail-cf/ostype
o nella analoga directory in cui sono contenuti le macro di configurazione di sendmail.
MAILER()
- OBBLIGATORIO. Esempio: MAILER(`smtp')
Definisce l'egente di consegna di posta utilizzato. Sendmail supporta non solo il protocolli SMTP, ma anche metodi più antichi (tipo UUCP) o diversi. In genere su un server di posta normale è definito MAILER(`smtp')
per la gestione della posta in rete, e MAILER(`procmail')
o MAILER(`local')
per il delivery della posta locale.
DOMAIN()
- RACCOMANDATO. Esempio: DOMAIN(`generic')
Imposta una macro specifica per il dominio indicato. Il generic si riferisce ad una configurazione standard, buona per molti usi.
FEATURE()
- RACCOMANDATO. Esempio: FEATURE(`use_cw_file')
Molte funzionalità utili di Sendmail sono configurabili con specifiche features, che vanno dichiarate nel file .mc.
Fra queste segnaliamo:
FEATURE(`always_add_domain')
- Aggiunge sempre il nome di dominio agli indirizzi presenti negli header dei messaggi, anche se si riferiscono ad utenti locali, per cui non si è esplicitato un dominio.
FEATURE(`domaintable')
- Attiva il supporto di un file domaintable
in cui sono indicati (a sinistra in ogni riga) nomi di dominio la cui posta la si vuole far convergere nel proprio dominio locale (a destra in ogni riga). Questa feature può avere come ulteriore argomento un path alternativo e un alternativo tipo di DB di gestione del file (di default si utilizza un hash db standard): FEATURE(`domaintable',`hash -o /etc/mail/domaintable.db')
.
Una simile riga su sendmail.mc produrrà su sendmail.cf la seguente configurazione:
Kdomaintable hash -o /etc/mail/domaintable.db
R$* < @ $+ > $* $: $1 < @ $(domaintable $2 $) > $3
FEATURE(`genericstable')
- Attiva il supporto del file genericstable
in cui è possibile specificare come cambiare l'indirizzo del mittente (a sinistra) con un indirizzo alternativo (a destra).
Ha una logica simile a domaintable: il file di configurazione è un normale testo ASCII che viene convertito in un .db che di fatto è quello utilizzato da Sendmail. Anche in questo caso è possibile indicare path del file e database utilizzato: FEATURE(`genericstable',`hash -o /etc/mail/genericstable.db')
FEATURE(`local_procmail')
- Utilizza procmail per il delivery della mail locale.
FEATURE(`mailertable')
- Permette di utilizzare un file mailertable
per gestire metodi e rotte di delivery della posta custom. In /etc/mail/mailertable
(default sui Sendmail recenti), che funziona come gli altri file da convertire in .db, va scritto, in ogni riga: dominio a cui è destinata la posta (es: dominio.com) - metodo di delivery e dominio o indirizzo email di destinazione (es: smtp:[email protected]).
SOURCE: Manuale in linea. Documentazione pacchetto BIND -
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-06-03 20:37:03
Sendmail nel mondo Unix è noto per avere il file di configurazione più complesso che sia mai stato concepito da uno sviluppatore umano.
Geek humour in rete si spreca sulle caratteristiche di questo file e in genere su Sendmail stesso, un mostro sacro della posta elettronica che non nasconde le sue antichità, nel bene e soprattutto nel male.
Il file di configurazione è /etc/sendmail.cf
, a volte si trova in /etc/mail/sendmail.cf
o in altre posizioni.
Questo file ha una struttura che appare estremamente complessa perchè ha una sintassi molto ridotta ai minimi termini: i comandi sono tutti di una singola lettera e si aspettano argomenti che spesso sono di 2 sole lettere.
A vederlo sembra uno scherzo di natura informatica, un insieme di caratteri senza senso, ma una volta conosciuta la sua logica, in parte le nebbie si dipanano.
Dalla versione 8 in poi, Sendmail può essere configurato anche tramite un file chiamato sendmail.mc
che contiene comandi molto più semplici da intuire ma che va di fatto convertito, tramite un preprocessore di macro m4, nel file sendmail.cf vero e proprio.
Questa distinzione va ben compresa: il file di configurazione di Sendmail rimane sempre sendmail.cf, ma invece che editarlo direttamente, è possibile generarlo da un file sendmail.mc che ha una sintassi e una logica più semplice e che richiede di essere "precompilato" sulla base di regole e macro che generalmente vengono fornite su un pacchetto a parte nelle varie distribuzioni Linux (sendmail-cf.*.rpm).
Ogni volta che si modifica sendmail.mc va quindi rigenerato il relativo sendmail.cf:
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
. Nel corso della sua storia e nelle sue incarnazioni su diversi Unix flavour, Sendmail ha disseminato file di configurazione in posti diversi, con le ultime versioni si è cercato di fare pulizia e uniformare la situazione. Segue un elenco, tratto dalla documentazione ufficiale dove si vede come sono cambiate le posizioni e i nomi di alcuni file comunemente usati in Sendmail:
Vecchia posizione Nuova posizione
/etc/bitdomain /etc/mail/bitdomain
/etc/domaintable /etc/mail/domaintable
/etc/genericstable /etc/mail/genericstable
/etc/uudomain /etc/mail/uudomain
/etc/virtusertable /etc/mail/virtusertable
/etc/userdb /etc/mail/userdb
/etc/aliases (oppure: /etc/sendmail/aliases ; /etc/ucbmail/aliases ; /usr/adm/sendmail/aliases ; /usr/lib/aliases ; /usr/lib/mail/aliases ; /usr/ucblib/aliases)
/etc/mail/aliases
/etc/sendmail.cw (oppure: /etc/mail/sendmail.cw ; /etc/sendmail/sendmail.cw)
/etc/mail/local-host-names
/etc/sendmail.ct /etc/mail/trusted-users
/etc/sendmail.oE /etc/mail/error-header
/etc/sendmail.hf (oppure: /etc/mail/sendmail.hf ; /usr/ucblib/sendmail.hf ; /etc/ucbmail/sendmail.hf ; /usr/lib/sendmail.hf ; /usr/share/lib/sendmail.hf ; /usr/share/misc/sendmail.hf ; /share/misc/sendmail.hf)
/etc/mail/helpfile
/etc/service.switch /etc/mail/service.switch
/etc/sendmail.st (oppure /etc/mail/sendmail.st ; /etc/mailer/sendmail.st ; /etc/sendmail/sendmail.st ; /usr/lib/sendmail.st ; /usr/ucblib/sendmail.st)
/etc/mail/statistics
HOWTO: Sendmail + UUCP HOWTO - http://ldp.openskills.info/HOWTO/Sendmail+UUCP.html
HOWTO: sendmail address rewriting mini-HOWTO - http://ldp.openskills.info/HOWTO/Sendmail-Address-Rewrite.html
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-09-03 12:55:09
Esistono diversi modi per supportare la tecnica POP-before-SMTP su Sendmail, che permette di usare un server SMTP remoto, che normalmente non permette il relay, dopo che ci si è autenticati via pop3 o imap sul server stesso.
Fra i vari approcci al problema tipicamente il più utilizzato è quello di usare un programma, generalmente eseguito come demone, che controlla i log di posta, identifica i tentitivi di login pop3 o Imap eseguiti con successo e scrive in un database gli indirizzi IP dei client remoti, questo database viene poi controllato da Sendmail (opportunamente configurato) per aprire il relay agli indirizzi ivi contenuti.
Abbiamo trovato particolarmente rapido ed efficace il tool log2db per convertire in un db Berkeley (db 1, 2, 3, 4) le entry di un file di log e la macro popauth fornita direttamente dal sito di Sendmail.
Ecco la procedura utilizzata:
Installare e configurare log2db
Normale procedura, verificare su http://www.bestbits.at/log2db/ se esistono versioni più recenti:
[al@giraffa al]$ wget http://www.bestbits.at/log2db/log2db-0.5.7.tar.gz
[...]
[al@giraffa al]$ tar -zxvf log2db-0.5.7.tar.gz
[...]
[al@giraffa al]$ cd log2db-0.5.7
[al@giraffa log2db-0.5.7]$ ./configure
[...]
[al@giraffa log2db-0.5.7]$ make
gcc -o log2db.o -g -O2 -Wall -DVERSION=\"0.5.7\" -Iinclude -c log2db.c
gcc -o regsubst.o -g -O2 -Wall -DVERSION=\"0.5.7\" -Iinclude -c regsubst.c
gcc -o log2db log2db.o regsubst.o -ldb
[al@giraffa log2db-0.5.7]$ su
Password:
[root@giraffa log2db-0.5.7]# make install
/usr/bin/install -c -m 755 --strip log2db /usr/local/sbin
/usr/bin/install -c -m 755 log2db-wrapper /usr/local/sbin
A questo punto editare /usr/local/sbin/log2db-wrapper
(uno script shell che invoca il comando log2db
e gli passa gli argomenti corretti) per adattarlo al proprio sistema, in particolare verificare la posizione del log del server pop3/imap (su Linux di solito /var/log/maillog
e commentare/scommentare le regole di pattern matching relative al proprio server di posta (di default si adatta a Qpopper). Correggere eventualmente il path del file log2db: nella versione utilizzata (0.5.7) è /usr/sbin/log2db ma il comando viene installato in /usr/loacl/sbin/log2db.
Dopo le configurazioni del caso si può lanciare il wrapper in background e aggiungerlo ad uno script di startup: /usr/local/sbin/log2db-wrapper &
Configurare Sendmail
Seconda parte del lavoro è la configurazione di Sendmail. Anche in questo caso le vie possono essere varie, ma la migliore e la più semplice è quella che passa per sendmail.mc. Aggiungere a questo file le righe:
define(`POP_B4_SMTP_TAG', `')
HACK(`popauth')
e scaricare la macro m4 popauth da http://www.sendmail.org/~ca/email/rules/popauth.m4 (evitare copia e incolla, per non rischiare di avere problemi con tab e spazi vari). Questa macro va copiata nella sottodirectory hack
all'interno dei file necessari per la configurazione di Sendmail. Su RedHat questi stanno in /usr/share/sendmail-cf/
e sono forniti dal pacchetto sendmail-cf, su altri *nix possono stare altrove, ma in ogni caso se m4 non trova il file lo comunica in stderr:
[root@giraffa log2db-0.5.7]# m4 /etc/mail/sendmail.mc > /dev/null
/etc/mail/sendmail.mc:145: m4: Cannot open /usr/share/sendmail-cf/hack/popauth.m4: No such file or directory
Ecco quindi la procedura usata su una RedHat9 (dopo aver modificato /etc/mail/sendmail.mc), ovviamente sarebbe sempre opportuno eseguire una copia dei file modificati:
[root@giraffa log2db-0.5.7]# wget http://www.sendmail.org/~ca/email/rules/popauth.m4
[...]
[root@giraffa log2db-0.5.7]# mv popauth.m4 /usr/share/sendmail-cf/hack/
[root@giraffa log2db-0.5.7]# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
[root@giraffa log2db-0.5.7]# /etc/init.d/sendmail stop
[root@giraffa log2db-0.5.7]# /etc/init.d/sendmail stop
[root@giraffa log2db-0.5.7]# /etc/init.d/sendmail start
A questo punto Sendmail è pronto per appoggiarsi ad db /etc/mail/popauth.db
per aprire il relay agli indirizzi li presenti. Questo database viene costantemente aggiornato da log2db (eseguito tramite il wrapper e lasciato in background) e può essere monitorato con il comando log2db --db=/etc/mail/popauth.db --dump
.
Esiste la possibilità di aggiungere a mano dei indirizzi IP: (es: log2db --db=/etc/mail/popauth.db --add 192.168.0.1
), di rimuoverli ecc.
Per verificare se tutto funziona, tenere sotto controllo il log di posta e provare ad inviare posta da un IP remoto, che normalmente non viene relayato dopo aver eseguito un login pop3 sullo stesso server.
SOURCE: Relay control in sendmail for roaming users - http://www.sendmail.org/~ca/email/roaming.html
Postfix |
Installazione, configurazione, gestione |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-04-28 15:09:13
In questa breve guida si affronta l'installazione di Mailscanner integrato con Postfix su Fedora/RedHat. Quanto qui indicato si può applicare senza sostanziali differenze anche su altre distribuzioni.
Rimozione di Sendmail e installazione Postfix :
yum install postfix
rpm -e sendmail
La configurazione di Postfix va fatta secondo le proprie necessità. Semplificando al massimo, verificare e modificare i seguenti parametri in /etc/postfix/main.cf
:
myhostname, mydomain, inet_interface, mydestination, mynetworks.
Installazione di Mailscanner. Rigorosamente consigliato è l'uso dell'ottimo installer per sistemi basati su RPM dal sito ufficiale (prendere l'ultima versione stable):
wget
http://www.sng.ecs.soton.ac.uk/mailscanner/files/4/rpm/MailScanner-4.39.6-1.rpm.tar.gz
L'installazione richiede compilatore e strumenti per creare rpm, se non sono già installati procedere con yum:
yum install rpm-build
yum install gcc
Procedere con l'installazione. La fase di compilazione può durare qualche minuti, in quando l'installer ricrea ed installa i pacchetti RPM per il propri sistema dai rispettivi sorgenti:
tar -zxvf MailScanner-4.39.6-1.rpm.tar.gz
cd MailScanner-4.39.6-1
./install.sh
L'integrazione con Postfix è semplice, aggiungere alla fine di /etc/postfix/main.cf
la riga:
header_checks = regexp:/etc/postfix/header_checks
e creare il file /etc/postfix/header_checks
con questo contenuto:
/^Received:/ HOLD
La configurazione di MailScanner prevede numerose opzioni che possono essere adattate alle proprie esigenze. Le modifiche fondamentali su /etc/MailScanner/Mailscanner.conf
sono:
Run As User = postfix
Run As Group = postfix
Incoming Queue Dir = /var/spool/postfix/hold
Outgoing Queue Dir = /var/spool/postfix/incoming
MTA = postfix
Assicurarsi che l'utente postfix con cui gira Postfix e lo steso Mailscanner abbia permesso di lettura e scrittura sulle directory usate per le code di Mailscanner:
chown -R postfix /var/spool/MailScanner
A questo punto si può provare a riavviare i servizi Mailscanner e Postfix e guardare gli header delle mail in entrata e in uscita: se esistono header aggiunti da Mailscanner, facilmente riconoscibili, il filtro e attivo e la sua configurazione dipende da come si vuole integrare con sistemi antivirus e antispam. Considerare che porvvede lo script di avvio di MailScanner ad avviare Posftix:
/etc/init.d/postfix stop
/etc/init.d/MailScanner restart
Quando tutto funziona secondo le ns esigenze possiamo configurare l'avvio dei servizi al boot:
chkconfig --level 345 postfix off
chkconfig --level 345 MailScanner on
Per integrare Mailscanner con l'antispam Spamassassin aggiungere/modificare le seguenti righe in /etc/MailScanner/Mailscanner.conf
:
Use SpamAssassin = yes
SpamAssassin User State Dir = /var/spool/MailScanner/spamassassin
Ricordarsi di creare questa directory con i giusti permessi:
mkdir /var/spool/MailScanner/spamassassin
chown postfix.postfix /var/spool/MailScanner/spamassassin
Per integrarlo con l'antivirus ClamAV editare MailScanner.conf con:
Virus Scanners = clamav
Monitors for ClamAV Updates = /var/lib/clamav/*.cvd
LINK: Sito Ufficiale MailScanner - http://www.mailscanner.info
SOURCE: HowTo Mailscanner+Postfix su Debian - http://www.debianitalia.org/modules/wfsection/article.php?articleid=77
LINK: MailWatch for MailScanner - http://mailwatch.sourceforge.net/
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2005-01-05 16:16:54
Una richiesta sempre più frequente quando si installa e configura un mail server linux è la possibilità che quest'ultimo processi le email in arrivo per filtrare i virus, e le email di spam.
Tutto ciò è facilmente applicabile utilizzando i seguenti applicativi:
- Postfix (MTA)
- ClamAV (Engine Antivirus)
- Clamsmtpd (per gestire il passaggio della posta da Postfix a ClamAV)
- Procmail (per gestire il delivery della posta e filtrarla con Spamassassin)
- Spamassassin
Supponiamo di avere già installato Postfix e Spamassassin (tipicamente presenti come pacchetti in molte distribuzioni).
Gli altri due programmi (ClamAV e Clamsmtpd) sono invece, generalmente, da scaricare e da compilare a mano.
La versione ultima di ClamAV al momento in cui si scrive questo infobox è la 0.80 che potete trovare qui:
Clamav
Per quando riguarda invece Clamsmtpd l'ultima è la 1.2 disponibile qui:
Clamsmtpd
Dopo aver scaricato i due pacchetti spostiamo in /usr/local/src e scompattiamoli.
Per l'installazione e compilazione vi rimando a questo infobox. La configurazione la vedremo invece insieme.
CONFIGURAZIONE CLAMD
Di seguito vediamo cosa cambiare in /etc/clamd.conf per quello che vogliamo andare a fare:
LocalSocket /tmp/clamd
Commentare la seguente linea perchè andremo a far ascoltare il demone clamd sulla socket TCP 3310, per farlo scommentare la seguente riga:
TCPSocket 3310
Il resto della configurazione di default va benissimo così com'è.
FRESHCLAM
Freshclam è il sistema utilizzato da ClamAV per aggiornare il proprio database. Il default di /etc/freshclam.conf va bene in quanto sarà in modalità demone che provvede ad aggiornare il sistema AV ogni 2 ore.
INSTALLAZIONE E CONFIGURAZIONE CLAMSMTPD
Questo fantastico software ci permette di impostare e gestire i vari passaggi che devono avvenire tra Postfix e ClamAV per i processi di filtering delle email che arrivano all'MTA.
Prima di tutto dobbiamo compilare il programma, per farlo spostiamoci in clamsmtpd-1.2 sotto /usr/local/src.
La compilazione avviene in modo standard ./configure; make; make install
;
Al termine del tutto bisogna però spostare in /etc il file di conf che è presente nei sorgenti: cp clamsmtpd-1.2/doc/clamsmtpd.conf /etc/
.
Fatto questo vediamo come configurarlo secondo le nostre esigenze:
Rispetto alla configurazione di default bisogna apportare i seguenti cambiamenti:
OutAddress: 127.0.0.1:10026
Output address
ClamAddress: 127.0.0.1:3310
Parametro che imposta dove ascolta Clamd
Avviare il demone clamsmtpd con il seguente comando:
/usr/local/sbin/clamsmtpd -f /etc/clamsmtpd.conf
IMPOSTARE POSTFIX PER UTILIZZARE I DUE SOFTWARE INSTALLATI
A questo punto basta dire a Postfix che le email che arrivano devono essere passate a clamsmtpd che provvederà a passarle a clamav e se CLEAN le rigirerà a Postfix per lo smistamento o, come nel nostro caso, per i controlli di antispam.
Per farlo basta aggiungere a /etc/postfix/main.cf
le seguenti righe:
content_filter = filter:127.0.0.1:10025
receive_override_options = no_address_mappings
Ed in fondo a /etc/postfix/master.cf
:
# SMTP filter (used by content_filter)
filter unix - - n - 16 smtp
-o smtp_send_xforward_command=yes
# For injecting mail back into postfix from the filter
127.0.0.1:10026 inet n - n - 16 smtpd
-o content_filter=
-o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks_style=host
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
UTILIZZO DI SPAMASSASSIN
Dato per scontato che spamassassin sia installato, il modo più semplice per utilizzarlo è di gestire il tutto tramite procmail, per quanto questa soluzione non sia l'ideale per grossi volumi di posta.
In pratica bisogna configurare Postfix per gestire il local delivery delle email tramite procmail. Per fare ciò basta scommentare la seguente linea di /etc/postfix/main.cf
:
mailbox_command = /usr/bin/procmail
IMPORTANTE: prima di riavviare il servizio di postfix bisogna configurare /etc/procmailrc con cui configuriamo a livello globale sulla configurazione di procmail.
Editare /etc/procmailrc
come segue:
DROPPRIVS=yes
LOGFILE=/var/log/procmail.log
VERBOSE=yes
:0fw
* < 256000
## | spamc -f
| /usr/bin/spamassassin
:0:/tmp/spam.lock
*^X-Spam-Flag: YES
/var/spool/mail/spam
Spieghiamo ora brevemente le parti importanti di procmailrc:
- LOGFILE specifichiamo il file dove procmail logga le attività che svolge.
- * < 256000 Specifichiamo a procmail di chiamare spamassassin SOLO per le email più piccole di 256K, in caso contrario si rischia di appesantire il processo di parsing delle email stesse
- | /usr/bin/spamassassin Specifica di usare il binario di spamassassin (non uso il spamd perchè ho avuto problemi di mailbox bloccate quando muore il demone)
- *^X-Spam-Flag: YES - /var/spool/mail/spam
Se trova il flag nell'header dell'email (inserito da spamassassin per le email ritenute spam) sposta la mail in una mailbox chiamata appunto "spam"
Per concludere tenete presente che in caso di traffico mail notevole è necessaria una macchina ben carrozzata.
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2004-11-12 17:44:53
Il protocollo SMTP offre una serie di comandi utili per visualizzare informazioni inerenti il server di posta. Questi comandi però possono esser sfruttati per scopi non del tutto etici.
Per evitare ciò è consigliabile disabilitare alcuni comandi tra cui il VRFY che permette la verifica di inidirizzi email sul server. Ad Esempio:
telnet pippo.com 25
220 pippo.com ESMTP Postfix
vrfy pippo
252 pippo
Nel file di configurazione di Postfix ( main.cf
) inserire la seguente dichiarazione:
# disabilita il comando VRFY
disable_vrfy_command = yes
Per attivare la modifica alla configurazione di postfix è necessario ricaricare il servizio ( /etc/init.d/postfix reload
)
telnet pippo.com 25
220 pippo.com ESMTP Postfix
vrfy pippo
502 VRFY command is disabled
Il comando VRFY sul server pippo.com è disabilitato.
LINK: SMTP COMMAND - http://www.networksorcery.com/enp/protocol/smtp.htm
Tipo Infobox: PATH - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2008-02-18 23:49:39
E' il file di configurazione attraverso il quale specificare gli alias di posta del mailserver Postifx.
E' un file di testo, può contenere linee vuote e di commento (le quali iniziano con il carattere #). Può risiedere in /etc/posftix/
oppure in /etc/
. Ogni entry deve essere nel formato nome:valore
. Impostando webmaster:homer
sul sistema Joker.net, si indica a Postfix di reindirizzare le mail dirette all'utente [email protected] all'utente [email protected].
La parte nome
di ogni linea di configurazione è intesa come locale, di conseguenza non è neccessario aggiungere il nome di dominio.
Per quanto riguarda la parte valore
, essa può essere può contenere diversi tipi di destinazione:
- address: Un indirizzo email compatibile alla RFC 822;
- file/name: La mail viene accodata al file specificato. E' possibile utilizzare normali file, ma anche file speciali come /dev/null
;
- | comando: Le mail possono essere inviate tramite pipe ad un comando;
- :include:/file/name: La mail viene inviata agli indirizzi elencati nel file specificato;
Esempio di configurazione:
# Basic system aliases -- these MUST be present
#
MAILER-DAEMON: postmaster
postmaster: root
root: homer
# Alias generali
bin: root
daemon: root
named: root
nobody: root
uucp: root
www: root
ftp-bugs: root
postfix: root
# Alias locali
arnaldo: homer
webmaster: homer
Reindirizzamento di tipo address: le mail dirette ad hannibal vengono inviate ad alberto:
hannibal: alberto
Reindirizzamento file/name: Le mail inviate a bart verrano accodate nel file bartmail
bart: /home/bart/bartmail
La mail inviata a programmatori verrà inviata a tutti gli indirizzi presenti all'interno del file programmers-list.txt:
programmatori: :include:/list/programmers-list.txt
Una volta aggiunti i nuovi alias, al fine di rendere effettive le modifiche, è necessario lanciare il comando newaliases
, il quale si occuperà di aggiornare il database degli alias.
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-08-04 20:12:05
Amavisd è un demone scritto in Perl che permette di chiamare programmi esterni in grado di scomprimere, decodificare e classificare il contenuto dei messaggi e degli allegati di posta.
Accetta le mail dall'MTA usato, chiama moduli Perl esterni e programmi che controllano il messaggio di posta e infine li riinoltra all'MTA per la consegna, il rifiuto o la quarantena del messaggio.
Per usare amavisd-new bisogna assicurarsi che si stia utilizzando una versione di Postfix abbastanza recente e che supporti il parametro content_filter = valore
Innanzi tutto occorre creare un utente e un gruppo per usare questo demone.
Di norma si usa amavis come utente e sweep come gruppo. Per motivi di sicurezza non usare assolutamente utenti di sistema come nobody o altri relativi al sistema di posta come maildrop.
Il file una volta scompattato non occorre di compilazioni, all'interno del pacchetto si trovano l'eseguibile amavisd
e il suo file di configurazione amavis.conf
più uno script di init da inserire nella directory relativa ai file di init del sistema. Questi file vanno copiati nelle loro giuste directory prestando attenzione ai permessi e agli utenti che ne hanno la proprietà. Come home directory per l'utente si può definire /var/amavis/
o /var/lib/amavis/
#cp ./amavisd /usr/sbin/
#chown root /usr/sbin/amavisd
#chmod 755 /usr/sbin/amavisd
e di conseguenza il file di configurazione
#cp ./amavisd.conf /etc/
#chown root /etc/amavisd.conf
#chmod 644 /etc/amavisd.conf
Può essere utile creare una directory che serva da destinazione per i messaggi in quarantena.
#mkdir /var/quarantena
chown amavis.amavis /var/quarantena/
chmod 750 /var/quarantena/
A questo punto sarà necessario editare il file di configurazione amavisd.conf e di conseguenza anche i file di configurazione di Postfix.
Nel amavisd.conf
sarà importante fare attenzione ad alcuni parametri in particolare anche se è consigliabile leggerlo tutto perchè le opzioni possibili sono numerose.
Innanzi tutto si settano i parametri $daemon_user
e $daemon_group
specificando l'utente e il gruppo scelto per far girare il demone. In questo modo al momento del lancio, come root, di amavisd, automaticamente parte come se lanciato dall'utente specificato.
Le opzioni
$HOME
per definire la home directory dell'utente amavis.
$TEMPBASE
dove si definisce la directory in cui vengono temporaneamente posti i messaggi in elaborazione.
$QUARANTINEDIR
la directory di quarantena in cui i messaggi sospetti o certamente infetti vengono riposti per un eventuale controllo e pulizia.
E' possibile anche non creare nessuna directory di quarantena e fare in modo che tutta la mail destinata a questa "coda" sia inviata ad un account di posta preposto per questo.
Si crea una voce relativa nel file /etc/aliases
o a seconda dell'installazione /etc/postfix/aliases
infected = /var/spool/mail/infected
e a seconda che si desideri o meno un mailbox-style aggiungere uno slash finale. Lanciare il comando newaliases
o postalias /etc/postfix/aliases
per aggiornare il database.
Infine specificare nel file amavisd.conf la direttiva
$virus_quarantine_to = 'infected@';
in modo da inviare tutta la posta in quarantena all'indirizzo infected.
Sarà necessario poi prestare attenzione agli altri parametri presenti nella 'Section I', $mydomain
e @local_domains_acl = valore
, e per finire agire sui valori di specifica del software antivirus usato nella 'Section VII'. A questo punto amavisd può essere lanciato e se dovessero mancare alcuni prerequisiti, come qualche modulo Perl, uscirà con un errore mostrando una lista di cosa è venuto a mancare.
Configurato amavisd sarà necessario lavorare sui file di configurazione di Postfix main.cf e master.cf.
Nel master.cf dovranno essere aggiunte le seguenti voci
smtp-amavis unix - - y/n - 2 smtp
-o smtp_data_done_timeout=1200
-o disable_dns_lookups=yes
127.0.0.1:10025 inet n - y/n - - smtpd
-o content_filter=
Dove y/n corrispondono al campo "chroot" e serve ad indicare se si è o meno in un ambiente di lavoro chroot.
Infine con il comando
#postconf -e 'content_filter = smtp-amavis:[127.0.0.1]:10024'
si modifica il main.cf e si fa in modo che Postfix inizi a inviare tutta la posta che riceve ad amavisd.
Effettuare un relaod della configurazione con il comando
#postfix reload
Controllare i file di log di Postfix e di amavisd per verificare che tutto funzioni. Volendo all'interno della directory del pacchetto Amavis è presente una sotto-directory test-messages
contenente alcuni file utili per testare il funzionamento del nuovo sistema di filtraggio della posta.
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Fabrizio 'bluviolin' Tarizzo - Ultimo Aggiornamento: 2003-07-16 14:54:07
Come ottimizzare Postfix su workstation con connessione ad Internet non permanente.
La configurazione di Postfix generalmente utilizzata su macchine con una connessione non permanente ad Internet (ad esempio una workstation casalinga) prevede l'uso della direttiva defer_transports=smtp
, che consente di mantenere in coda la posta inviata evitando l'avvio automatico di connessioni PPP indesiderate.
La posta in giacenza verrà effettivamente inviata alla successiva connessione, tramite un postfix flush
nello script /etc/ppp/ip-up
.
Ciò è scomodo, in quanto costringe l'utente ad eseguire manualmente il flush
se desidera inviare un messaggio mentre la connessione è già attiva.
Una configurazione più funzionale istruisce Postfix a mantenere la posta in coda mentre la workstation non è connessa ad Internet e a spedirla immediatamente quando la connessione è attiva.
Ciò è possibile grazie al comando postconf
, aggiungendo le seguenti istruzioni in /etc/ppp/ip-up
o, meglio, in /etc/ppp/ip-up.local
(ricordo che per ragioni di sicurezza questi script vengono eseguiti in un environment protetto, le variabili di ambiente non sono disponibili ed è pertanto obbligatorio specificare il path per esteso di ciascun comando):
# Istruisce Postfix per inviare subito la posta
/usr/sbin/postconf -e "defer_transports="
/usr/sbin/postfix reload
# Invia la posta in coda
/usr/sbin/sendmail -q >dev/null 2>/dev/null &
In /etc/ppp/ip-down.local
rimettiamo le cose a posto:
/usr/sbin/postconf -e "defer_transports=smtp"
/usr/sbin/postfix reload
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-06-04 11:53:19
Postfix è integrabile con diversi sistemi di autenticazione, di controllo dei virus, di applicativi webmail e può raggiungere livelli molto elevati di complessità strutturale. Molti strumenti e metodi utilizzati con Sendmail sono disponibili anche con Postfix.
Sul sito ufficiale del pacchetto alla pagina http://www.postfix.org/addon.html sono disponibili diversi riferimenti a utility, patch e documentazione per implementare diverse funzioni.
Attualmente Postfix è integrabile con molti dei principali sistemi di posta pop3/imap come Cyrus IMAP, Qpopper, Courier-imap, con vari software antivirus, con sistemi di controllo delle autenticazioni before-smtp come DRAC, whoson o pop-before-smtp o con sistemi anti-UCE come SpamAssassin. Alcune di queste funzioni implicano la ricompilazione del pacchetto, altre necessitano di particolari accorgimenti, come spesso succede nel mondo Linux ci sono molti modi di ottenere lo stesso effetto ed è difficile stabilire quale sia il migliore.
Un metodo di autenticazione molto usato è pop-before-smtp.
Per far questo si può utilizzare DRAC Dinamic Relay Authorization Control, un demone che si occupa di scrivere un database di indirizzi autenticati attraverso pop3/imap ma implica alcuni fattori poco favorevoli quali l'uso di Remote Procedure Call e quindi la necessità di avere portmap attivo e il fatto di dover ricompilare i demoni usati per pop3/imap, si può usare whoson una patch per Postfix che quindi implica la sua ricompilazione oppure usare pop-before-smtp un demone scritto in Perl.
L'ultima è probabilmente la soluzione più funzionale e pratica, non implica ricompilazioni particolari ed è portabile su molte piattaforme differenti, unico neo che potrebbe far preferire DRAC a questo metodo è che non opera da remoto implica per ciò che i file necessari siano presenti sulla macchina del server di posta.
Il pacchetto, disponibile su sourceforge si può trovare in formato rpm o in formato tar.gz, una volta appurato che siano presenti i modili Perl necessari per far funzionare pop-before-smtp installabili attraverso un Bash script all'interno della directory contrib dei sorgenti scaricati, chiamato getfromcpan
che li scarica, ne crea il pacchetto rpm e se lanciato come root li installa o per i puristi con il comando Perl per accedere all'immenso archivio dei moduli di Perl:
#perl -MCPAN -e 'install Time::HiRes'
#perl -CPAN -e 'install File::Tail'
#perl -MCPAN -e 'install Date::Parse'
#perl -MCPAN -e 'install Net::Netmask'
A questo punto premesso di avere un'installazione funzionante di un sistema di posta, in questo caso poniamo un server pop3 e Postfix, sarà necessario lavorare principalmente sulla configurazione di pop-before-smtp e sul main.cf di Postfix.
Il file di configurazione principale pop-before-smtp-conf.pl
è molto ben commentato ed è consigliabile leggerlo tutto per chiarire appieno il funzionamento e le possibili configurazioni, di norma si dovrà fare attenzione ad alcuni parametri:
# Set the log file we will watch for pop3d/imapd records.
Con questo commento inizia la sezione che specifica il log file del server pop3d/imapd. Notare che è presente del codice che tenta di effettuare questa operazione automaticamente.
if (!-f $file_tail{'name'}) {
foreach (qw( /var/log/mail/info /var/log/mail.log
/var/log/messages /var/adm/messages )) {
if (-f $_) {
$file_tail{'name'} = $_;
last;
}
}
}
Mentre sarà importante fare attenzione alle definizioni della variabile $pat
per determinare le azioni da eseguire sui file di log, di cui il default è
# For UW ipop3d/imapd and their secure versions. This is the DEFAULT.
$pat = '^(... .. ..:..:..) \S+ (?:ipop3s?d|imaps?d)\[\d+\]: ' .
'(?:Login|Authenticated|Auth) user=\S+ ' .
'host=(?:\S+ )?\[(\d+\.\d+\.\d+\.\d+)\]';
Sarà necessario identificare il server pop3d/imapd usato e scommentare le righe di codice che lo riguardano.
A questo punto se è tutto a posto si potrà lanciare il comando o usando
#/usr/sbin/pop-before-smtp
o a seconda della distribuzione lo script di init
/etc/init.d/pop-before-smtp start
Di default dovrebbe creare il file pop-before-smtp.db
nella directory /etc/postfix/
e sarà necessario configurare il main.cf di conseguenza agendo sul parametro di restrizione dei recipienti
smtpd_recipient_restrictions = permit_mynetworks,reject_non_fqdn_recipient,
check_client_access hash:/etc/postfix/pop-before-smtp,
check_relay_domains
In questo modo quando un client si autenticherà via pop da qualunque indirizzo ip, poniamo dei dipendenti che viaggiano spesso e si collegano con il modem, il demone pop-before-smtp aggiornerà il file database contenente le informazioni sul client di modo che Postfix ne conceda l'inoltro (relay) della posta. I metodi possibili per gestire l'autenticazione per limitare il relay di Postfix sono molte, questo è forse uno dei metodi più semplici e pratici ma consigliabile fare riferimento alla documentazione presente in Internet per questo argomento che spesso contiene informazioni molto utili per la comprensione delle architetture implementabili con Postfix.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-07-15 20:55:17
Di default Postfix accetta esclusivamente connessioni dal network locale e dai domini che ospita ma in situazioni di rete complesse può essere necessario assumere un maggiore controllo sulle connessioni al server.
Per questo vengono incontro numerosi parametri del file main.cf con cui è possibile effettuare diversi controlli sul traffico di posta del server.
Attraverso il main.cf si può:
Stabilire il comportamento del server al momento della connessione del client.
Si lavora a livello del protocollo SMTP andando a modificare il comportamento del server.
Ad esempio costringendo il server ad accettare connessioni strettamente aderenti allo standard stabilito nella rfc 821 o modificandone il comportamento in concomitanza con alcuni comandi SMTP.
I parametri per queste operazioni riguardano comandi interni al protocollo SMTP, è consigliabile leggere le RFC sull'argomento e fare riferimento alla documentazione ufficiale del pacchetto.
Un parametro tra questi che può essere importante è
smtpd_helo_restrictions = valori
che permette di definire diverse regole di comportamento del server in relazione a quali host possono inviare un comando HELO
, l'inizio di norma di qualunque connessione SMTP. Questo parametro è equivalente e viceversa ad altri utilizzabili nel main.cf, come restringere i nomi dei client o i loro indirizzi IP con il parametro
smtpd_client_restrictions = valori
oppure agire sul campo sender
smtpd_sender_restrictions = valori
o sul comportamento del relay della posta
smtpd_recipient_restrictions = valori
Effettuare controlli sugli header di un messaggio e sul corpo dei messaggi.
Stabilendo delle regole di filtraggio delle intestazioni di un messaggio contenenti informazioni sul tipo di programma client e sulle macchine attraverso cui il messaggio è passato dando la possibilità in questo modo di implementare delle liste nere di server da cui non accettare mai la posta e filtrando i contenuti di un messaggio stabilendo delle liste di termini non permessi. Per i parametri e il metodo da usare per implementare questo tipo di controlli fare riferimento alla documentazione ufficiale di Postfix
Restringere l'inoltro della posta per quanto riguarda l'utente specificato nel campo "sender".
In questo modo si può stabilire che il server non accetti posta da client che non specificano un nome di dominio FDQN oppure accettare l'inoltro solo da utenti definiti.
Il parametro che si occupa di questa operazione è
smtpd_sender_restrictions = valori
La sua sintassi, simile nei parametri complementari visti in precedenza, permette di restringere l'uso del server di posta agendo sul campo sender. Opzioni possibili per questo sono
reject_unknown_sender_domain
reject_non_fqdn_sender
oppure un file database con le specifiche per i sender autorizzati con l'utilizzo di una sintassi particolare tipo_file:percorso_file
hash = /etc/postfix/access
Agire sui recipient di inoltro della posta.
Stabilendo regole sulla funzione di relay del server e agendo in sostanza sugli indirizzi concessi nel campo SMTP RCPT TO
di modo da limitare o dare accesso per il relay della posta a client non appartenenti alla sotto-rete del server. Questo metodo è consigliato quando si utilizzano controlli di accesso tipo pop-before-smtp
che permette l'uso del relay solo a client che si sono autenticati via pop precedentemente.
Il parametro principale è
smtpd_recipient_restrictions = valori
le cui opzioni impongono che sia presente sempre una voce tipo reject, defer, defer_if_permit o reject_unauth_destination altrimenti il server rifiuterà comunque la ricezione di posta.
Per esempio quindi si userà
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
Questo parametro è utilizzabile anche specificando un'opzione di controllo sui client
check_client_access = tipo_file:percorso_file
Le combinazioni di parametri e opzioni possono rendere una configurazione molto complessa e le possibilità offerte sono innumerevoli, è consigliabile prima di approfondire con la configurazione accertarsi di aver compreso come funziona il protocollo SMTP visitando il sito delle request for comments http://www.rfc-editor.org e cercando le rfc 821 e 2821.
SOURCE: Documentazione ufficiale - http://www.postfix.org/docs.html
SOURCE: Specifiche SMTP - http://www.groovyweb.uklinux.net/index.php?page_name=smtp%20commands
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-07-15 21:06:26
Mentre postsuper effettua operazioni di carattere amministrativo sui file delle code in Postfix, all'utente finale viene fornito uno strumento per agire sui propri file di posta. In se implementa operazioni che tradizionalmente sono disponibili con il comando sendmail di Postfix. Questo comando è ideato per essere set-group ID (SGID) di modo che possa comunicare con i processi appartenenti ai demoni interni al sistema di posta.
La sua sintassi
postqueue [-c directory_file_conf] [-f][-p] [-s sito] [-v]
Le opzioni sono poche
-c directory_file_conf
: Specifica la directory dove si trova il file di configurazione. A dimostrazione dell'attenzione prestata alla sicurezza per evitare che un utente smaliziato sia in grado di usare il set-group ID per i propri discutibili motivi, non si può in realtà specificare una directory arbitraria. Una directory arbitraria e concessa solo se se elencata nel file main.cf con il parametro alternate_config_directories oppure se il comando è lanciato dall'super-utente root.
-f
: Pulisce la coda. In sostanza tenta l'inoltro di tutta la posta in coda.
-p
: Produce una lista dei file nelle code. Usa uno stile alla "sendmail".
Per ogni file in coda mostra l'ID, la misura del messaggio, l'orario di arrivo, chi lo ha inviato e i recapiti a cui va inoltrato. Se la posta in questione non è stata inoltrata per qualche motivo mostra la ragione di questo fallimento. L'ID di un messaggio a volte viene mostrato seguito da un carattere speciale.
Se si trova un asterisco "*
" il messaggio si trova nella coda active e sta per essere inoltrato.
Se invece è presente un simbolo "!
" il messaggio si trova nella coda holde non sarà inoltrato finchè l'amministratore non lo rilascierà.
-s sito
: Con questa opzione si stabilisce l'inoltro di tutta la posta in coda per il dominio specificato. Di norma sono ammessi tutti i domini per cui Postfix è abilitato come relay-server o quelli presenti nel parametro di configurazione fast_flush_domains.
-v
: Opzione per avere maggiori informazioni sullo stato dei processi messi in atto dal comando. Se usato più volte abilita ulteriori informazioni. Da intendersi per l'uso in casi di debugging.
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-07-15 21:07:11
Questo comando è inteso per la gestione e la manutenzione dei processi nelle code di Postfix. L'uso di questo comando è inteso per il superutente, l'amministratore del sistema mentre l'utente semplice per agire sui file di una coda Postfix può usare postqueue
.
La sua sintassi
postsuper [-psv] [-c directory_file_conf] [-d][-h][-H][-r] [id_coda] [directory_coda]
Di default postsuper effettua le operazioni su tutte le directory di coda di Postfix, quindi incoming, active e deferred le principali code per i file di mail, e sulle directory con i log files, bounce, defer, e flush.
Le sue opzioni
-c directory_file_conf
: Specifica la directory dove si trova il main.cf per l'istanza di Postfix su cui si desidera lavorare.
-d id_coda
: Questa opzione elimina un messaggio che ha l'id specificato dalla code (di default: hold, incoming, active e deferred). Se si usa come id il simbolo "-
" il programma legge gli id dallo standard input. Questo rende possibile usare postsuper all'interno di script.
Per rimuovere tutti i messaggi si usa il suffisso ALL
che va specificato in maiuscolo per motivi di sicurezza. Se si definisce una coda in particolare verranno cancellati tutti i messaggi per quella coda:
postsuper -d ALL deferred
eliminerà tutti i file di posta presenti nella coda deferred.
Occorre notare che l'id di un file in coda viene riutilizzato dal sistema di posta. Questo comporta il rischio di eliminare il messaggio errato. Per esempio, il queue manager cancella il messaggio indicato da postsuper perchè ha finito il suo ciclo all'interno del sistema. Arriva posta nuova e ad un messaggio viene dato l'id che postsuper ha richiesto di rimuovere. Il messaggio nuovo viene eliminato al posto di quello giusto.
Occorre quindi prestare attenzione se si desidera eliminare dei messaggi mentre il sistema di posta è attivo.
-h id_coda
: Questa opzione sposta il messaggio definito dalla coda o dalle code (di default, incoming, active e deferred) alla coda hold di modo che nessuna operazione di inoltro venga effettuata prima del suo rilascio da parte del postmaster. Anche con questa opzione se al posto di un id di messaggio si utilizza il simbolo "-
" il programma legge gli id dall'input di tastiera. Anche questa opzione supporta la chiave ALL
che va utilizzata in maiscolo per forzare l'attenzione su questa delicata operazione.
-H id_coda
: Con questa opzione si esegue il rilascio della posta messa "on hold", trattenuta nella coda hold. La posta rilasciata viene messa all'interno della coda deferred Anche per questa funzione valgono le chiavi ALL
e "-
"
-p
: Pulisce i vecchi file temporanei che vengono creati in caso di un crash del sistema o del software di posta.
-r id_coda
: Rielabora nuovamente il messaggio specificato dall'inizio come fosse appena arrivato. Il messaggio viene preso dalla coda o dalle code (di default: hold, incoming, active e deferred). Per riimpostare file multipli è consigliato usare l'opzione più volte. Anche questo parametro supporta le chiavi "-
" e ALL
. Un messaggio riinserito in coda viene spostato nella coda maildrop da dove viene copiato dal pickup daemon in un nuovo file. Questo viene rielaborato, subendo nuovamente le operazioni di address rewriting e sostituzione. Questa operazione è utile quando si sono modificate alcune regole o la mappatura virtuale. Va ricordato che gli id delle code sono riutilizzati e quindi c'è una minima possibilità di effettuare questa operazione su un file sbagliato ma senza particolari conseguenze (non viene eliminato) e solo se il sistema di posta è attivo.
-s
: Questa operazione è importante e andrebbe eseguita sempre prima che Postfix venga lanciato. Effettua un controllo strutturale dei file e ripara gli errori.
In sostanza rinomina i file il cui nome non è associato all'inode giusto. Questo è utile in caso si stia recuperando la posta di un'altra macchina o da un backup. Infine sposta i file che non si trovano al posto giusto e rimuove le sotto directory che non sono più necessarie.
-v
: Abilita i messaggi per propositi di debug e testing. L'uso multiplo di questa opzione abilita maggiori informazioni.
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-30 21:18:47
Il comando postconf è una utility a riga di comando che permette diverse operazioni su un file di configurazione di Postfix. Con postconf si possono consultare i parametri presenti al momento nel sistema di posta, si può editare il file specificato, si possono verificare i valori di default per una particolare direttiva.
postconf [-dhmlnv] [-c directory_file_conf] [parametro ...]
postconf [-ev] [-c directory_file_conf] [parametro=valore ...]
La maggior parte delle opzioni riguardano principalmente il controllo dei valori configurati e di quelli standard.
-c directory_file_conf
: Permette di specificare la directory che contiene i file di configurazione su cui si desidera agire.
-d
: Mostra i valori di default per tutti i parametri.
-h
: Mostra esclusivamente i valori e non il nome dei parametri configurati.
-m
: Mostra una lista delle tipologie di tabelle supportate.
-l
: Mostra una lista di metodi per il lock delle mailbox.
-n
: Mostra tutti i valori che non sono default nel file specificato.
-e
: Questa è l'opzione più importante perchè è necessaria per editare un particolare parametro del file di configurazione.
Per avere un quadro quanto più complessivo delle numerose opzioni di Postfix occorre fare riferimento a diverse fonti. Con l'ausilio dei commenti del main.cf
standard, della lettura dei file di esempio e grazie a questa utility è possibile ottimizzare al meglio il proprio MTA (Mail Transfer Agent) e adattarlo a diverse architetture di accesso dati. Una grande utilità di questo comando è che se lanciato senza opzioni mostra tutti i valori della configurazione attuale in modo da avere una idea complessiva di tutti i parametri presenti nei file di esempio.
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2004-06-04 11:59:07
La suite di Postfix si compone di numerosi demoni e di una decina di comandi che servono a regolare specifiche operazioni. Il principale e più importante è il comando postfix che serve a controllare il programma stesso. Con esso si avvia o si ferma il demone master del sistema di posta, si verifica lo stato o si ricarica la configurazione.
La sua sintassi è semplice e senza troppe opzioni, ma ha vari sotto-comandi.
postfix [-Dv] [-c directory_file_conf] comando_interno
-D
: Usata solo con il sotto-comando start
permette di lanciare i demoni di postfix sotto il controllo delle direttive di debug specificate nel main.cf.
-v
: Anche questa opzione è orientata al debug del software, si possono specificare più volte per avere ancora più informazioni.
-c
: Permette di specificare una directory alternativa a quella di default in cui il comando andrà a cercare i file di configurazione. Utile nel caso si stiano eseguendo più server di posta sulla stessa macchina.
I comandi interni regolano diverse operazioni
start
: Avvia il sistema di posta. Effettua anche un controllo della configurazione come se si usasse il comando check
.
stop
: Ferma il sistema di stampa regolarmente. I processi in corso hanno modo di terminare quanto prima ma completando le loro operazioni.
abort
: Ferma il sistema di stampa forzatamente. I processi in corso sono costretti a fermarsi immediatamente.
check
: Verifica la configurazione del sistema di posta e mostra degli alert per errori nei permessi dei file o delle directory.
flush
: Forza l'inoltro di ogni messaggio in attesa di essere inviato. Utile nel caso si usi una connessione verso Internet di tipo PPP o ISDN che non è sempre attiva.
reload
: Permette di ricaricare i file di configurazione senza fermare il sistema di posta.
Questo comando va utilizzato esclusivamente dall'utente root.
HOWTO: postfix -
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-30 21:06:44
Una volta configurato il server con i parametri per l'invio, la ricezione e l'inoltro della posta si può prendere in considerazione l'ottimizzazione del servizio e un maggiore controllo delle sue funzioni.
Esistono molte possibilità per definire il comportamento di Postfix e in special modo per controllarne gli accessi, sia da un punto di vista di consumo delle risorse sia dal controllo di cosa può passare e cosa invece no per evitare, ad esempio, l'invio massivo attraverso il server di UCE (Unsolicited Commercial Email) o comunemente SPAM. Per controllare l'invio di SPAM di default l'SMTP-server di Postfix accetta esclusivamente la posta per il network o il dominio locale e per i domini ospiti del server, in modo che dagli estranei non si accetti alcuna connessione. Esistono diversi modi per assumere maggior controllo su questa problematica usando liste di accesso in stile Sendmail o RBL (Real Time Blackhole List) e per un approfondimento si può fare riferimento alla documentazione ufficiale disponibile sul sito di Postfix, www.postfix.org, o nella directory di sistema dedicata alla documentazione dei pacchetti installati.
E' importante inoltre controllare le quantità di posta processabile, ad esempio per limitare il numero di processi contemporanei anche se si dispone di un limite massimo di 1000 client.
default_process_limit = valore
permette di controllare il numero di processi in uscita e in entrata. Di default è settato a 100 ma nel caso di una piccola rete casalinga andrebbe benissimo un valore di 10 mentre per un mail server principale di un provider andrebbe meglio un valore di 1000 o 10000.
Per controllare che il server non sia usato per un attacco tipo DoS o per spam si usano alcune variabili che ai loro valori di default dovrebbero andare benissimo.
initial_destination_concurrency = valore
(default:2)
che controlla quanti messaggi sono inizialmente inviati verso la stessa destinazione prima di attuare un invio multiplo.
local_destination_concurrency_limit = valore
(default:2)
che controlla quanti messaggi sono inviati contemporaneamente allo stesso recipiente locale.
default_destination_concurrency_limit = valore
(default:20)
che impone il limite di messaggi inviabili contemporaneamente alla stessa destinazione.
Ulteriori parametri permettono quanto meno di limitare l'uso del server da parte di client sbadati o maliziosi, rallentando di fatto le loro connessioni fino a chiuderle senza troppi imbarazzi. Il server incrementa un conteggio per sessione degli errori dovuti a richieste da parte dei client non riconosciute valide o sconosciute e di tutte le richieste che in qualche modo violano le regole UCE. Questo conteggio si azzera quando un messaggio viene inviato correttamente. Se il conteggio aumenta il server limita i danni rallentando il client.
Le variabili che controllano queste funzioni sono:
smtpd_error_sleep_time = valore
(va bene il valore di default:1)
che in sostanza cerca di evitare gli errori di un client quando il conteggio è ancora basso ponendo un tempo limite in cui il server resta in pausa mentre comunica l'errore al client.
smtpd_soft_error_limit = valore
di default 10 stabilisce che quando il numero di errori per sessione supera il valore impostato il server attende il valore del conteggio in secondi prima di rispondere ad un'altra richiesta del client.
smtpd_hard_error_limit = valore
di default 20 e stabilisce che al superare nel conteggio del valore impostato il server SMTP taglia la connessione.
SOURCE: Documentazione ufficiale - http://www.postfix.org/docs.html
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-30 21:02:29
Postfix principalmente si controlla attraverso due importanti file, "main.cf" e "master.cf".
Rispettivamente regolano il comportamento generale dell'applicazione e la configurazione del master daemon che gestisce il comportamento di tutti i demoni che compongono questo sistema di posta.
Di norma il master.cf può essere lasciato intatto a meno che non si stia lavorando su configurazioni più complesse come ad esempio intergrare Postfix con Cyrus.
Il main.cf è il file più importante. Attraverso questo file è possibile configurare Postfix come un semplice relay server per una piccola rete casalinga fino ad arrivare a configurazioni di alto livello per sistemi "enterprise".
Il file si presenta molto ben commentato e spesso i valori di default vanno benissimo, ma rimane un file complesso e molto grosso, i diversi parametri sono molti, più di 250 stando a quanto scritto nelle primissime righe di commento. Per questo generalmente Postfix dispone di un nutrito set di file di esempio e molto utili se si desidera conoscere molti parametri di default che non sono presenti nel main.cf a installazione completata. Ci si può inoltre aiutare usando il comando postconf
.
Le direttive vengono separate tra di loro e riunite in categorie (Queue and process ownership, Internet host and domain name, Sending mail...) facilitando in questo modo la comprensione del significato dei singoli parametri.
Di norma per avere un sistema di posta funzionante non occorre che modificare poche variabili.
- Quale dominio usare per la posta in uscita.
- Quale invece di cui ricevere la posta.
- Quali client hanno modo di inviare la posta attraverso il server.
La direttiva
myorigin = valore
permette di specificare il dominio da usare per la posta inviata attraverso questo server. Il valore di default è la variabile $myhostname
ma a meno che non si utilizzi il server per una piccola rete locale sarà opportuno modificarlo con $mydomain
.
myorigin = $mydomain
mydestination = valore
specifica per quali domini il sistema di posta deve instradare localmente i messaggi anzichè inviarli ad un altro server. Generalmente si compone di una lista di nomi, si possono specificare anche file o tabelle, di norma occorrerà aggiungere $mydomain
ai valori di default in modo che il server sia il mail server del dominio.
mydestination = $myhostname localhost.$mydomain $mydomain
Dove i primi due valori sono quelli di default.
mynetworks = valore
Questa variabile volendo permette di impostare host per host le macchine che possono usare il server per l'inoltro dei messaggi. Di default si usa la direttiva complementare mynetworks_style.
mynetworks_style = [class] [subnet] [host]
subnet è il valore di default e indica che Postfix inoltrerà la posta per tutti i client nella sottorete locale.
class Postfix considererà validi tutti i client provenienti dal network di classe A, B o C a cui è collegato.
host l'inoltro sarà abilitato esclusivamente per la macchina locale.
myhostname = valore
Questo parametro permette di specificare una importante direttiva usata da altri parametri del file di configurazione con la variabile $myhostname
. Il nome dell'host va specificato nella forma FQDN (Fully Qualified Domain Name). Di default Postfix usa il nome dell'host locale ma se questo non fosse un nome di dominio completo o fosse in ascolto su un'interfaccia virtuale si deve specificare il nome di dominio completo per il server.
myhostname = mail.esempio.com
myhostname = mail.virtualesempio.com
mydomain = valore
Permette di specificare il dominio a cui appartiene il server. Di norma è usato il valore di $myhostname
togliendo la prima parte del nome a meno che non si riduca ad un dominio di primo livello.
mydomain = esempio.com
Configurati questi parametri si dovrebbe cominciare ad avere un server di posta utilizzabile.
Nel caso in cui la macchina che si sta usando possiede più di un indirizzo su un'interfaccia di rete o più interfaccie verrà utile specificare inoltre
inet_interfaces = valore
Di default in ascolto su tutti gli indirizzi (all
) con questa direttiva si possono specificare le interfaccie virtuali.
inet_interfaces = virtual.esempio.com
Perchè la modifica di questa variabile sia effettiva non basta effettuare un reload ma si deve fermare e riavviare il sistema di posta.
SOURCE: Documentazione ufficiale - http://www.postfix.org/docs.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-30 20:57:39
La maggior parte delle principali distribuzioni Linux comprende i pacchetti rpm di Postfix nel CD di installazione. Alcune come Suse lo hanno ormai sostituito a Sendmail nell'installazione di default. In certi casi comunque potrebbe essere necessario installare dai sorgenti.
Sul sito di Postfix, http://www.postfix.org, si trovano le indicazioni per scaricare i sorgenti dell'applicazione. Si noterà che, fedelmente al proposito di sostituire il diffusissimo Sendmail, è ormai disponibile il supporto per la compilazione su quasi tutte le versioni unix esistenti a patto di seguire in certi casi pochi accorgimenti.
Una volta scaricato e scompattato il pacchetto, cambiata la directory di lavoro in quella dei sorgenti appena creata, si può procedere con l'installazione.
All'interno dei sorgenti, tra i diversi file, si troveranno oltre alla documentazione ufficiale alcuni file utili per cominciare il processo di installazione. In caso si stia utilizzando un SO come Solaris che ha notevoli differenze da Linux, pur restando uno unix, nel file INSTALL si troveranno consigli utili per la compilazione su questa piattaforma e su altre che impongono diversi parametri.
Se si compila su un sistema che usa le GCC, vedi Linux, con il comando
make
si dà inizio al processo di compilazione. I parametri definibili in questa fase sono per lo più inerenti alla modifica della posizione di default dei file di configurazione o dei programmi che compongono Postfix.
Eseguita questa fase si procede nell'installazione. Si dovrà creare un utente dedicato che non necessita ne di una home directory ne di una shell con il comando
adduser postfix -s /bin/false -d /dev/null
e settare un record nel file delle password con il comando
passwd -l postfix
Dopo di che sarà necessario creare due gruppi, postfix e postdrop usando il comando groupadd
.
Queste operazioni sono necessarie per il successo dell'installazione.
Si procede con il comando
make install
per concludere l'installazione. Questo comando nel caso di Postfix è interattivo, permettendo di specificare parametri diversi da quelli di default, ponendo semplici domande e mostrando inoltre quali sono i valori standard.
Una volta installato tutto senza particolari modifiche ai valori standard si troveranno all'interno della directory /etc/postfix
tutti i file di configurazione e le tabelle.
Il file più importante è il main.cf
dove si specificano quasi tutti i parametri di configurazione, ma anche master.cf
, che regola il comportamento del programma master che si occupa di gestire gli altri programmi che compongono postfix e i parametri con cui questi programmi vengono eseguiti. Un'altro file di grande importanza e che generalmente viene editato prima di procedere con l'avvio del server è il file /etc/aliases
che a volte può trovarsi dentro la directory /etc/postfix/
. Ricordarsi che ogni volta che questo file viene modificato occorre lanciare il comando newaliases
perchè le modifiche abbiano effetto.
La directory radice dove si troveranno tutte le code si trova in /var/spool/postfix/
.
La documentazione verrà salvata in /usr/share/doc
o in /usr/doc
ma può cambiare a seconda della distribuzione usata.
La suite di postfix si compone di numerose applicazioni. Alla fine dell'installazione, se eseguita con i valori standard si troveranno tutti i demoni all'interno della directory /usr/libexec/postfix/
.
%ls -al /usr/libexec/postfix
drwxr-xr-x 2 root root 536 2003-05-31 22:24 .
drwxr-xr-x 100 root root 35976 2003-06-17 15:20 ..
-rwxr-xr-x 1 root root 159994 2003-03-17 16:35 bounce
-rwxr-xr-x 1 root root 192637 2003-03-17 16:35 cleanup
-rwxr-xr-x 1 root root 147535 2003-03-17 16:35 error
-rwxr-xr-x 1 root root 146107 2003-03-17 16:35 flush
-rwxr-xr-x 1 root root 185928 2003-03-17 16:35 lmtp
-rwxr-xr-x 1 root root 206273 2003-03-17 16:35 local
-rwxr-xr-x 1 root root 102287 2003-03-17 16:35 master
-rwxr-xr-x 1 root root 180167 2003-03-17 16:35 nqmgr
-rwxr-xr-x 1 root root 145316 2003-03-17 16:35 pickup
-rwxr-xr-x 1 root root 165959 2003-03-17 16:35 pipe
-rwxr-xr-x 1 root root 130586 2003-03-17 16:35 proxymap
-rwxr-xr-x 1 root root 174767 2003-03-17 16:35 qmgr
-rwxr-xr-x 1 root root 158236 2003-03-17 16:35 qmqpd
-rwxr-xr-x 1 root root 146374 2003-03-17 16:35 showq
-rwxr-xr-x 1 root root 227117 2003-03-17 16:35 smtp
-rwxr-xr-x 1 root root 257641 2003-03-17 16:35 smtpd
-rwxr-xr-x 1 root root 139319 2003-03-17 16:35 spawn
-rwxr-xr-x 1 root root 164847 2003-03-17 16:35 tlsmgr
-rwxr-xr-x 1 root root 150312 2003-03-17 16:35 trivial-rewrite
-rwxr-xr-x 1 root root 162184 2003-03-17 16:35 virtual
Le utility di gestione del servizio invece saranno all'interno della directory /usr/sbin/
%ls -al /usr/sbin/post*
-rwxr-xr-x 1 root root 132952 2003-03-17 16:35 /usr/sbin/postalias
-rwxr-xr-x 1 root root 27185 2003-03-17 16:35 /usr/sbin/postcat
-rwxr-xr-x 1 root root 145688 2003-03-17 16:35 /usr/sbin/postconf
-rwxr-sr-x 1 root postdrop 95451 2003-03-17 16:35 /usr/sbin/postdrop
-rwxr-xr-x 1 root root 69141 2003-03-17 16:35 /usr/sbin/postfix
-rwxr-xr-x 1 root root 75112 2003-03-17 16:35 /usr/sbin/postkick
-rwxr-xr-x 1 root root 71534 2003-03-17 16:35 /usr/sbin/postlock
-rwxr-xr-x 1 root root 68576 2003-03-17 16:35 /usr/sbin/postlog
-rwxr-xr-x 1 root root 125326 2003-03-17 16:35 /usr/sbin/postmap
-rwxr-sr-x 1 root postdrop 85781 2003-03-17 16:35 /usr/sbin/postqueue
-rwxr-xr-x 1 root root 84165 2003-03-17 16:35 /usr/sbin/postsuper
LINK: Postfix - Tutorial passo-passo per l'installazione di postfix con supporto mysql tables su MAC OS X - http://www.kdev.it/postfix.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-30 20:52:16
Postfix nasce con l'intento di sostituire Sendmail come server di posta. E' stato concepito quindi con un occhio di riguardo alla compatibilità con questo sistema di modo da facilitarne la migrazione.
Inoltre è studiato con molta attenzione nei riguardi della sicurezza tanto da venire considerato da molti il più sicuro mailer in circolazione.
Questo sistema di posta anzichè essere costituito da un unico grosso programma che effettua la maggior parte delle azioni è suddiviso in diversi programmi che svolgono una azione specifica e un programma principale che si occupa di chiamare il programma giusto quando necessario e di gestire le varie azioni. Solo il programma master necessita di privilegi elevati e va infatti lanciato da root, gli altri invece possono girare con privilegi molto bassi, ad esempio usando un utente creato appositamente, inoltre possono essere eseguiti in un ambiente "gabbia" chroot.
In questo modo si ha un isolamento dei singoli processi con un maggior controllo sulle singole azioni eseguite dal server. Inoltre è pensato per resistere a condizioni di lavoro con carichi di traffico elevati e utilizza particolari routines per evitare che un eventuale crash possa compromettere il comportamento dell'intera macchina. Oltre a non avere nessun programma SUID, Postfix non "crede" al contenuto delle code e in se non conosce il contenuto dei file in coda. I programmi che si occupano di un passaggio dell'elaborazione dati effettuano i controlli degli stessi allo scopo di indirizzarli verso il programma o la coda giusta.
Ogni programma che compone questo complesso sistema agisce in modo autonomo senza avere processi "figli" e in questo modo si cerca di evitare relazioni tra i processi che potrebbero condizionare il comportamento dei child in caso il processo "genitore" sia compromesso.
I dati che vengono ricevuti dalla rete vengono opportunamente filtrati e subiscono controlli diversi dai singoli programmi che si occupano della loro elaborazione, inoltre si evita di salvare tali dati sul disco ma vengono processati in primis dal programma e susseguentemente passati al programma successivo.
Postfix si avvale principalmente di quattro importanti code:
maildrop, incoming, active, deferred
La posta viene innanzitutto depositata in maildrop da dove dopo alcune elaborazioni passa alla coda incoming, questa coda è per la posta che è appena arrivata e che non è ancora stata elaborata dal manager delle code. La coda active invece è una piccola zona in cui la posta al suo interno è aperta dal manager ed è in attesa di essere instradata. Quella posta che non può, per vari motivi, essere instradata viene mandata alla coda deferred.
Il gestore delle code mantiene in memoria solo i dati presenti nella coda active in questo modo si evita che il processo si intasi in caso di una grossa mole di traffico.
Oltre a queste code Postfix mantiene due spazi "parcheggio" una si chiama hold e contiene tutti quei messaggi che sono congelati nella coda e per i quali non viene attuato nessun tentativo di smistamento. L'unico modo di rilasciare questi messaggi è con il comando postsuper. Il secondo parcheggio invece si chiama corrupt e al suo interno vengono salvati quei file che non sono riconosciuti validi, e vengono lasciati lì per permettere all'amministratore di controllarli.
Soluzioni Antivirus |
Rassegna delle soluzioni antivirus server based |
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-08-04 20:12:05
Amavisd è un demone scritto in Perl che permette di chiamare programmi esterni in grado di scomprimere, decodificare e classificare il contenuto dei messaggi e degli allegati di posta.
Accetta le mail dall'MTA usato, chiama moduli Perl esterni e programmi che controllano il messaggio di posta e infine li riinoltra all'MTA per la consegna, il rifiuto o la quarantena del messaggio.
Per usare amavisd-new bisogna assicurarsi che si stia utilizzando una versione di Postfix abbastanza recente e che supporti il parametro content_filter = valore
Innanzi tutto occorre creare un utente e un gruppo per usare questo demone.
Di norma si usa amavis come utente e sweep come gruppo. Per motivi di sicurezza non usare assolutamente utenti di sistema come nobody o altri relativi al sistema di posta come maildrop.
Il file una volta scompattato non occorre di compilazioni, all'interno del pacchetto si trovano l'eseguibile amavisd
e il suo file di configurazione amavis.conf
più uno script di init da inserire nella directory relativa ai file di init del sistema. Questi file vanno copiati nelle loro giuste directory prestando attenzione ai permessi e agli utenti che ne hanno la proprietà. Come home directory per l'utente si può definire /var/amavis/
o /var/lib/amavis/
#cp ./amavisd /usr/sbin/
#chown root /usr/sbin/amavisd
#chmod 755 /usr/sbin/amavisd
e di conseguenza il file di configurazione
#cp ./amavisd.conf /etc/
#chown root /etc/amavisd.conf
#chmod 644 /etc/amavisd.conf
Può essere utile creare una directory che serva da destinazione per i messaggi in quarantena.
#mkdir /var/quarantena
chown amavis.amavis /var/quarantena/
chmod 750 /var/quarantena/
A questo punto sarà necessario editare il file di configurazione amavisd.conf e di conseguenza anche i file di configurazione di Postfix.
Nel amavisd.conf
sarà importante fare attenzione ad alcuni parametri in particolare anche se è consigliabile leggerlo tutto perchè le opzioni possibili sono numerose.
Innanzi tutto si settano i parametri $daemon_user
e $daemon_group
specificando l'utente e il gruppo scelto per far girare il demone. In questo modo al momento del lancio, come root, di amavisd, automaticamente parte come se lanciato dall'utente specificato.
Le opzioni
$HOME
per definire la home directory dell'utente amavis.
$TEMPBASE
dove si definisce la directory in cui vengono temporaneamente posti i messaggi in elaborazione.
$QUARANTINEDIR
la directory di quarantena in cui i messaggi sospetti o certamente infetti vengono riposti per un eventuale controllo e pulizia.
E' possibile anche non creare nessuna directory di quarantena e fare in modo che tutta la mail destinata a questa "coda" sia inviata ad un account di posta preposto per questo.
Si crea una voce relativa nel file /etc/aliases
o a seconda dell'installazione /etc/postfix/aliases
infected = /var/spool/mail/infected
e a seconda che si desideri o meno un mailbox-style aggiungere uno slash finale. Lanciare il comando newaliases
o postalias /etc/postfix/aliases
per aggiornare il database.
Infine specificare nel file amavisd.conf la direttiva
$virus_quarantine_to = 'infected@';
in modo da inviare tutta la posta in quarantena all'indirizzo infected.
Sarà necessario poi prestare attenzione agli altri parametri presenti nella 'Section I', $mydomain
e @local_domains_acl = valore
, e per finire agire sui valori di specifica del software antivirus usato nella 'Section VII'. A questo punto amavisd può essere lanciato e se dovessero mancare alcuni prerequisiti, come qualche modulo Perl, uscirà con un errore mostrando una lista di cosa è venuto a mancare.
Configurato amavisd sarà necessario lavorare sui file di configurazione di Postfix main.cf e master.cf.
Nel master.cf dovranno essere aggiunte le seguenti voci
smtp-amavis unix - - y/n - 2 smtp
-o smtp_data_done_timeout=1200
-o disable_dns_lookups=yes
127.0.0.1:10025 inet n - y/n - - smtpd
-o content_filter=
Dove y/n corrispondono al campo "chroot" e serve ad indicare se si è o meno in un ambiente di lavoro chroot.
Infine con il comando
#postconf -e 'content_filter = smtp-amavis:[127.0.0.1]:10024'
si modifica il main.cf e si fa in modo che Postfix inizi a inviare tutta la posta che riceve ad amavisd.
Effettuare un relaod della configurazione con il comando
#postfix reload
Controllare i file di log di Postfix e di amavisd per verificare che tutto funzioni. Volendo all'interno della directory del pacchetto Amavis è presente una sotto-directory test-messages
contenente alcuni file utili per testare il funzionamento del nuovo sistema di filtraggio della posta.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-09-02 19:29:17
Molti fra i maggiori produttori di antivirus forniscono soluzioni per sistemi Linux, in particolare orientati a mail server, dove maggiore può essere l'utilizzo di un Antivirus con funzioni di protezione della posta anche per client Windows.
L'offerta di F-Prot per sistemi Linux si compone di:
F-Prot for Linux Workstation - Orientata a singoli utenti e al momento poco utile, vista la scarsa diffusione di virus per Linux;
F-Prot for Linux Mail Servers - La soluzione ideale per ISP e aziende che hanno un server di posta basato su Linux (Sendmail, Postfix, Qmail..)
F-Prot for Linux File Servers - Utile su file e ftp server di una rete locale aziendale.
L'engine di virus scanning e il database dei virus sono gli stessi delle rispettive versioni per Windows e vengono costantemente aggiornati. La versione per Mail Servers ha le seguenti componenti:
- F-Prot Antivirus Command-Line Scanner ( f-prot [options] [file or directory]
)
- F-Prot Antivirus Daemon Scanner ( f-protd /path/to/data/directory/
)
- F-Prot Antivirus Updater ( check-updates.pl [options]
)
- F-Prot Antivirus Mail Scanner ( scan-mail.pl [-backup]
)
- F-Prot Antivirus Preloadable Library Call Wrapper ( f-prot.so
)
L'installazione è piuttosto semplice, può essere eseguita direttamente tramite pacchetto RPM o DEP o scompattando un tar.gz e seguendo le relative istruzioni. Tutti i file vengono scritti nella directory /usr/local/f-prot
e a questi si aggiungono dei link simbolici per i comandi di basi in PATH tipici (bin, sbin), gli script di gestione del servizio f-protd in /etc/init.d/f-protd
e i relativi link SysV nelle directory rc#.
Alcuni comandi di F-Prot si basano su Perl 5 e richiedono i seguenti moduli:
scan-mail.pl: MIME::Base64, MIME::QuotedPrint
check-updates.pl: NET::FTP, IO::File, HTTP::Request, HTTP::Response, LWP::UserAgent
I signature files, contenenti le definizioni dei virus sono /usr/local/f-prot/MACRO.DEF
, SIGN.DEF
, SIGN2.DEF
, questi possono venir aggiornati tramite il comando check-updates.pl che va, ovviamente, inserito nel crontab (ad esempio con: 30 4,16 * * * /usr/local/f-prot/tools/check-updates.pl -cron
).
FileSystem Scan
Lo scan di virus sul filesystem può avvenire tramite il comando f-prot che ha varie funzioni e opzioni come:
f-prot /var -dumb -disinf -list
- Esegue uno scan sulla directory /var (e sottodirectory) senza considerare il tipo di file (-dumb), provando a disinfettare i file infetti (-disinf) e visualizzando tutti i file controllati (-list).
f-prot -virlist
- Visualizza l'elenco dei virus che possono venir riconosciuti.
Mail Delivery Scan
F-Prot può facilmente interfacciarsi con qualsiasi sistema di posta che si appoggia a Procmail per il delivery locale dei messaggi (o altri che permettano di passare e far filtrare da un programma esterno la mail prima di salvarla sulla casella postale del destinatario).
Per integrare F-Prot con Procmail basta editare /etc/procmailrc
oppure ~/.procmailrc
(per configurazioni relative a singoli utenti) ed aggiungere un testo tipo:
:0 fw
| /usr/local/f-prot/tools/scan-mail.pl
Allo script scan-mail.pl possono essre aggiunte opzioni come -backup
per eseguire una copia di tutte le mail e -quarantine
per copiare tutti i messaggi originali poi modificati perchè contenenti un virus. Le copie vengono messe nella directory /usr/local/f-prot/backup/
.
E' opportuno considerare che questo metodo controlla i virus solo sulle mail in entrata (nel momento in cui stanno per essere consegnata ad una casella postale locale) e non quelle in uscita. Per un controllo su tutte le mail che vengono gestite dal server esiste la possibilità di fare un:
Mail In-Transit Scan
Questo metodo utilizza il plugin libmilter per Sendmail, per cui non viene ufficialmente supportato su altri SMTP server. La configurazione è semplice, invece di intervenire su .fetchmail.rc si deve editare /tec/mail/sendmail.mc
ed aggiungere righe come:
INPUT_MAIL_FILTER(`f-prot-milter', `S=/var/run/f-prot.sock, F=T, T=E:5m')
Dopo va ricreato il file di configurazione definivo di Sendmail (m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
) e riavviato il servizio. Lo script scan-mail.pl va quindi avviato con l'opzione -milter
(lo si può fare editando direttamente le variabili definite nel codice Perl).
SOURCE: F-Prot Antivirus for Linux Mail Servers - http://www.f-prot.com/support/helpfiles/unix/linux_ms/index.html
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-19 18:08:54
ClamAV è uno dei più interessanti progetti OpenSource per lo scanning di virus.
Rilasciato sotto GPL, è Posix compliant e quindi disponibile per varie piattaforme *nix (Linux, *BSD, Solaris, MacOs X, lo stesso CygWin... ) e, rispetto ad altri progetti simili, ha il fondamentale pregio di mantenere un database in costante aggiornamento.
La versione analizzata, 0.70, identifica più di 20000 virus, è in grado di scompattare file compressi e di analizzare documenti di Office per Macro virus. NON corregge i file infetti, ma, nella sua applicazione più comune (antivirus correlato ad un sistema di posta) questa mancanza è assolutamente ininfluente.
INSTALLAZIONE
E' possibile scaricare sorgenti e binari precompilati per diverse distribuzioni dal sito ufficiale www.clamav.net.
Per compilare ClamAv è necessario avere i seguenti pacchetti: zlib, zlib-devel, oltre ovviamente alla suite gcc. Sono inoltre consigliati bzip2, bzip2-devel, gmp.
Per usarlo è necessario avere un utente non privilegiato con cui farlo eseguire:
groupadd clamav
useradd -g clamav -s /bin/false -c "Clam AntiVirus" clamav
Si può quindi procedere alla scompattazione del tar.gz scaricato:
tar -zxvf clamav-x.yz.tar.gz
cd clamav-x.yz
E alla compilazione (qui viene specificato di mettere il file di configuazione sotto /etc ):
./configure --sysconfdir=/etc
make
su -c "make install"
Binari e librerie vengono copiati in /usr/local, il file di configurazione, vista l'opzione --sysconfdir sopra specificata, diventa /etc/clamd.conf
.
Una volta eseguita l'installazione è possibile testate l'engine su dei file d'esempio forniti con il tar.gz:
clamscan -r -l scan.txt clamav-x.yz
CONFIGURAZIONE
Il file di configurazione /etc/clamav.conf
(o /usr/local/etc/clamav.conf
se si sono compilati direttamente i sorgenti senza aver impostato specifici parametri) contiene le varie voci che determinano il funzionamento di ClamAV. I parametri impostati di default sono generalmente adeguati e non è necessario modificarli per poter iniziare ad usarlo, bisogna solo provvedere a commentare la riga Example
(il che, quantomeno, obbliga l'utente a dare un'occhiata al file di configurazione ed avere barlumi di consapevolezza sulla sua logica).
Si segnalano comunque impostazioni quali:
LogFile /tmp/clamd.log
, LogFileMaxSize 2M
, LogVerbose
, LogSyslog
determinano posizione, dimensioni, verbosità ed eventuale utilizzo di Syslog per il file di log.
DatabaseDirectory /var/lib/clamav
la directory in cui viene scritto il database con le signature dei virus riconosciuti
TCPSocket 3310
, TCPAddr 127.0.0.1
la porta e l'indirizzo a cui si mette in ascolto clamd (di default si binda ad ogni indirizzo disponibile)
MaxConnectionQueueLength 15
, MaxThreads 5
il numero massimo di connessioni contemporanee e di thread su clamd (aumentare su sistemi con grossi carichi)
StreamMaxLength 10M
VirusEvent /usr/local/bin/send_sms 123456789 "VIRUS ALERT: %f: %v"
quale comando eseguire nel caso venga intercettato un virus
User clamav
L'utente con cui viene eseguivo clam. Di default "clamav", va creato in fase di installazione e deve avere permessi di lettura e scrittura sui log e il database dei virus.
ScanOLE2
, ScanMail
, ScanArchive
definiscono se eseguire scan su file Microsoft Office, su caselle postale e su file compressi. Notare che lo scan di mailbox è disabilitato di default.
ArchiveMaxFileSize 10M
, ArchiveMaxFiles 1000
[...] parametri vari che determinano dimensioni degli archivi su cui eseguire gli scan.
CONFIGURAZIONE AUTO AGGIORNAMENTO: FRESHCLAM
Freshclam è lo strumento migliore per tenere aggiornato il database di virus su cui lavora l'engine di ClamAV.
Può essere eseguito via command line e schedulato per un aggiornamento automatico, oppure essere lanciato come demone in costante esecuzione. Il suo file di configurazione è /etc/freshclam.conf
dove vengono definite informazioni quali:
DatabaseDirectory /var/lib/clamav
- La directory dove Clam trova il database dei virus, deve essere uguale a quanto definito in clamav.conf
UpdateLogFile /var/log/clamav/freshclam.log
- Il file dove vengono loggate le operazioni di freshclam, deve appartenere all'utente clamav e può avere permessi 0600
NotifyClamd /etc/clamav.conf
- Notifica clamd (va indicato il path corretto del suo file di conf) ogni volta che vengono aggiunti virus al database, in modo da riavviarlo per ricaricare il database aggiornato.
DatabaseMirror database.clamav.net
L'indirizzo da cui scaricare gli aggiornamenti. Il valore preimpostato è l'ideale perchè punta ad un pool, gestito con un round-robin DNS, di mirror ufficiali
Esistono altre opzioni che permettono di usare un proxy http, di eseguire comandi custom ad ogni aggiornamento o errore, di gestire la frequenza degli aggiornamenti (in modalità demone) o il numero di tentativi, ecc.
Per eseguire freshclam in daemon mode basta lanciare:
/usr/local/bin/freshclam -d
per lanciare una esecuzione schedulata, aggiungere a /etc/crontab
una riga tipo:
N * * * * /usr/local/bin/freshclam --quiet
dove N è un numero da 00 a 59 che indica il minuto in cui eseguire l'aggiornamento (ogni ora).
USARE CLAMAV
Clamav, in se, si "limita" ad analizzare il contenuto di un file o di un flusso di dati e ad individuare eventuali virus sulla base del database di firme che viene tenuto aggiornato con freshclam.
La sua natura aperta, comunque, gli permette di essere integrato ed interagire con altri programmi per poter essere utilizzato come antivirus su un server di posta o un file server o per eseguire un check direttamente su dei file specificati.
La modalità di funzionamento è duplice: esiste la possibilità di utilizzare l'engine tramite il comando clamscan
oppure di usufruire del demone clamd
.
clamscan se lanciato senza argomenti fornisce alcune informazioni e statistiche sul numero di virus riconosciuti, se viene seguito dal nome di una directory del file sistem, esegue un check di tutti i file ivi contenuti. Fra le opzioni e gli utilizzi più utili:
clamscan -r /home
Esegue lo scan ricursivo (-r
) di tutto il contentuto della directory /home
clamscan -r /home -l /var/log/antivirus.log
Salva il report dello scan di /home sul file antivirus.log (a video, in standard error, vengono visualizzati tutti i file contollati
clamscan -r /home -i
Stampa a video solo i nomi dei file infetti (oltre al report finale) e quindi risulta decisamente meno verboso.
Il demone clamd può stare in ascolto su una socket Unix (opzione di default: LocalSocket /tmp/clamd
nel file di conf) o, in alternativa, su una porta TCP (opzione TCPSocket 3310
).
Per eseguirlo basta lanciare il comando clamd
. Se si vuole usare un file di configurazione diverso da quello di default si puà usare l'argomento --config-file
, se si vuole abilitare il debug mode usare --debug
Il demone si presta ad integrarsi ed essere usato come filtro da parte di vari programmi esterni ed ha, comunque, un suo client chiamato clamdscan
che ha sostanzialmente le stesse opzioni di clamscan.
Se si ha clamd in esecuzione basta digitare clamdscan /home
, per esempio, per eseguire il controllo dei file in /home.
Notare che quando si usa clamdscan, si accede ai file da controllare tramite clamd per cui l'utente con cui il demone gira (di default clamav) deve averne almeno accesso in lettura.
MODALITA' D'USO
Essendo ClamAV fondamentalmente un filtro, che riceve un file in input e lo rilascia in output dopo aver verificato se contiene virus, i suoi ambiti di utilizzo sono svariati e si integrano con software e soluzioni diversi.
Sendmail Milter
Sendmail ha la possibilità con il supporto milter, di integrarsi con dei filtri che analizzano la mail mentre sta per essere ricevuta (e quindi prima del delivery completo).
Se si compila ClamAv con l'opzione (sono necessarie le librerie di development libmilter):
./configure --enable-milter
dopo la compilazione ci si ritroverà il file /usr/local/sbin/clamav-milter
(se si installa ClamAV tramite un pacchetto, il supporto milter con file clama-milter dovrebbero essere già presenti).
VA quindi configurato sendmail per usare il milter clamav, in /etc/mail/sendmail.mc
aggiungere:
INPUT_MAIL_FILTER(`clmilter',`S=local:/var/run/clmilter.sock,F=, T=S:4m;R:4m')dnl
define(`confINPUT_MAIL_FILTERS', `clmilter')
In clamav.conf
definire:
LocalSocket /var/run/clamd.sock
ScanMail
StreamSaveToDisk
A questo punto, oltre ad riavviare i servizi Sendmail e ClamAv si deve avviare il servizio clamav-milter:
/usr/local/sbin/clamav-milter -lo /var/run/clmilter.sock
Se si è fatta una installazione tramite rpm si avranno i seguenti file chiave:
/etc/rc.d/init.d/clamav-milter Script di gestione del servizio
/etc/sysconfig/clamav-milter File di configurazione con gli argomenti da passare al programma
/usr/sbin/clamav-milter Il binario di clamav-milter
Utilizzo di procmail
A differenza della precedente, in questa modalità il filtro viene fatto sulle mail quando sono state già ricevute dal server SMTP e prima di essere "consegnate", tipicamente tramite procmail, ad una casella postale locale.
Il vantaggio è che procmail di fatto può essere integrato con qualsiasi server SMTP.
Di fatto esistono diverse soluzioni e script che tramite procmail e clamav filtrano la posta. Ne citiamo alcuni:
clamassassin - Ha una logica simile a Spamassassin: la mail viene passata ad uno script perl che usando clam aggiunge un header specifico alle mail infette, le quali vengono poi redirezionate o cancellate, da una seconda regola di procmail.
trashcan - Incluso nel pacchetot ufficiale, si presta in particolare per singole postazioni, non su server di posta.
clamscan-procfilter - Semplcie script perl con una logica simile a quella di Clamassassin
Integrazione con Amavisd-NG
Amavis-Ng è una riscrittura di amavis (http://sourceforge.net/projects/amavis) dopo l'installazione basta scommentare in amavis.conf
la riga:
virus-scanner = CLAM
e eventualmente cambiare il path di clamscan:
[CLAM]
clamscan = /usr/local/bin/clamscan
Altri
Per un elenco completo dei plugin e delle possibilità di interazione di ClamAv con software vari (non soltanto in riferimento alla posta, è possibile anche integrarlo con Samba o con Apache) con relative istruzioni, fare riferrimento alla documentazione HTML ufficiale, nella parte relativa al "Third Party Software"
LINK: Risorse (sftware, pacchetti) correlate a ClamAV - http://clamav.or.id/
LINK: Clam AntiVirus HomePage - http://www.clamav.net
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2004-05-19 18:15:02
Un sistema molto semplice e comunque abbastanza efficace per filtrare una buona quantità di Virus, seppur in modo grossolano, è quello di implementare direttamente a livello di Procmail, senza l'uso di filtri esterni, un meccanismo di controllo per tutte le mail che hanno allegati sospetti.
Ecco come può apparire un /etc/procmailrc
o un $HOME/.procmailrc
:
:0
Si sposta la mail nella casella postale virus (che potrà essere controllata dall'utente POP£ virus
* ^X-Attachments:.*name=".*\.(pif|scr|bat|vbs|vba|lnk|com)" Si controlla il nome dell'attachment e se termina con una delle estensioni riportate (tutte tipiche di alcuni virus e difficilmente usate per scopi legittimi)....
/var/spool/mail/virus
Meccanismi Anti-Spam |
Verifica relay e implementazione di sistemi anti-spam |
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2004-06-04 12:00:59
Esistono in rete strumenti che permettono di verificare le possibilità di relay offerte da un server di posta.
Uno dei metodi più efficaci e utili è offerto dal sito mail-abuse.org che oltre a fornire informazioni varie permette di eseguire un relay test telnettando un server dedicato direttamente dal proprio server di posta:
telnet relay-test.mail-abuse.org
Il server remoto automaticamente visualizza il risultato di una serie di test su varie forme di relay permesse dal server SMTP locale.
Alcune possono essere necessarie (il relay per la ricezione di mail per domini locali) di altri se ne può abusare per l'invio di spam e vanno corrette.
Fra i siti dove è possibile controllare se si è inseriti in qualche Black List di IP usati per inviare spam si segnalano:
http://openrbl.org/ - OpenRBL
Ottimo ed essenziale sito che permette di verificare un indirizzo su molteplici black-list ed ottenere rapidamente altre informazioni come whois/dns lookups
http://moensted.dk/spam/ - drbcheck: dr. Jørgen Mash's DNS database list checker
La lodevole iniziativa di un sysadmin che permette il check di un indirizzo su moltissime liste, alcune delle quali non sono vere e proprie black list (in alcune è normale ritrovarci il proprio indirizzo)
http://ordb.org/ - ORDB
Database pubblico di relay aperti.
http://mail-abuse.org/cgi-bin/lookup - MAPS RBL
Pionieri delle RBL, offrono, commercialmente, l'uso di diverse black list basate su diversi criteri.
http://www.spamcop.net/ - Spam Cop
Altra storica black list, nota, suo malgrado e senza colpe, per essere stata coinvolta in un Hoax, a sua volta diffuso via spam.
LINK: OpenRPL: Ricerca in varie black list - http://openrbl.org/
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'ask' Nasuti - Ultimo Aggiornamento: 2003-05-22 22:39:18
Le versioni di Sendmail dalla 8.9 non permettono di default l'invio di posta (relay) a nessuno tranne localhost.
Su un server SMTP che debba offrire un servizio pubblico si devono configurare gli indirizzi che possono inviare posta e i domini per cui si ricevono email.
Una configurazione troppo aperta su chi può usare il servizio può essere sfruttata per azioni di spam, anche verso terzi, al contempo si ricorre sempre più spesso a Black List con liste di indirizzi IP da cui rifiutare posta.
Nel file /etc/mail/relay-domains
(default) si possono indicare i domini ai quali aprire il relay. Nella configurazione m4 le principali FEATURE per gestire relay e meccanismi antispam sono:
- FEATURE(relay_hosts_only)
In relay-domains si devono specificare tutti i singoli host, invece del solo nome di dominio, a cui aprire il relay
- FEATURE(relay_entire_domain)
Apre al relay tutto il dominio locale del server SMTP
- FEATURE(access_db)
Gestisce l'accesso al server per ogni host inserito nel file /etc/mail/access
(il file ha formato tipo: esempio.com RELAY)
- FEATURE(dnsbl)
Si rifiutano le email provenienti da indirizzi inseriti nella Realtime Blackhole List (RBL), basata su DNS, specificata
SOURCE: Allowing controlled SMTP relaying in Sendmail 8.9 and later - http://www.sendmail.org/tips/relaying.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/
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-30 21:06:44
Una volta configurato il server con i parametri per l'invio, la ricezione e l'inoltro della posta si può prendere in considerazione l'ottimizzazione del servizio e un maggiore controllo delle sue funzioni.
Esistono molte possibilità per definire il comportamento di Postfix e in special modo per controllarne gli accessi, sia da un punto di vista di consumo delle risorse sia dal controllo di cosa può passare e cosa invece no per evitare, ad esempio, l'invio massivo attraverso il server di UCE (Unsolicited Commercial Email) o comunemente SPAM. Per controllare l'invio di SPAM di default l'SMTP-server di Postfix accetta esclusivamente la posta per il network o il dominio locale e per i domini ospiti del server, in modo che dagli estranei non si accetti alcuna connessione. Esistono diversi modi per assumere maggior controllo su questa problematica usando liste di accesso in stile Sendmail o RBL (Real Time Blackhole List) e per un approfondimento si può fare riferimento alla documentazione ufficiale disponibile sul sito di Postfix, www.postfix.org, o nella directory di sistema dedicata alla documentazione dei pacchetti installati.
E' importante inoltre controllare le quantità di posta processabile, ad esempio per limitare il numero di processi contemporanei anche se si dispone di un limite massimo di 1000 client.
default_process_limit = valore
permette di controllare il numero di processi in uscita e in entrata. Di default è settato a 100 ma nel caso di una piccola rete casalinga andrebbe benissimo un valore di 10 mentre per un mail server principale di un provider andrebbe meglio un valore di 1000 o 10000.
Per controllare che il server non sia usato per un attacco tipo DoS o per spam si usano alcune variabili che ai loro valori di default dovrebbero andare benissimo.
initial_destination_concurrency = valore
(default:2)
che controlla quanti messaggi sono inizialmente inviati verso la stessa destinazione prima di attuare un invio multiplo.
local_destination_concurrency_limit = valore
(default:2)
che controlla quanti messaggi sono inviati contemporaneamente allo stesso recipiente locale.
default_destination_concurrency_limit = valore
(default:20)
che impone il limite di messaggi inviabili contemporaneamente alla stessa destinazione.
Ulteriori parametri permettono quanto meno di limitare l'uso del server da parte di client sbadati o maliziosi, rallentando di fatto le loro connessioni fino a chiuderle senza troppi imbarazzi. Il server incrementa un conteggio per sessione degli errori dovuti a richieste da parte dei client non riconosciute valide o sconosciute e di tutte le richieste che in qualche modo violano le regole UCE. Questo conteggio si azzera quando un messaggio viene inviato correttamente. Se il conteggio aumenta il server limita i danni rallentando il client.
Le variabili che controllano queste funzioni sono:
smtpd_error_sleep_time = valore
(va bene il valore di default:1)
che in sostanza cerca di evitare gli errori di un client quando il conteggio è ancora basso ponendo un tempo limite in cui il server resta in pausa mentre comunica l'errore al client.
smtpd_soft_error_limit = valore
di default 10 stabilisce che quando il numero di errori per sessione supera il valore impostato il server attende il valore del conteggio in secondi prima di rispondere ad un'altra richiesta del client.
smtpd_hard_error_limit = valore
di default 20 e stabilisce che al superare nel conteggio del valore impostato il server SMTP taglia la connessione.
SOURCE: Documentazione ufficiale - http://www.postfix.org/docs.html
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Roberto 'rpennol' Pennolino - Ultimo Aggiornamento: 2004-05-15 13:38:41
Lo spam è un fenomeno in crescita esponenziale.
L'uso quotidiano della posta elettronica e di Internet agevola sicuramente questo tipo di "pubblicità indesiderata". Molto spesso le mail di spam provengono da domini che non esistono o che non sono registrati come MX (Mail eXchanger) sui DNS.
Per chi utilizza Sendmail esiste un modo semplice per arginare il problema spam. Basta commentare la riga:
FEATURE(`accept_unresolvable_domains')dnl
che diventa in questo modo:
dnl FEATURE(`accept_unresolvable_domains')dnl
nel file /etc/mail/sendmail.mc
Di default Sendmail accetta posta da qualsiasi dominio, commentando la FEATURE si impone a Sendmail di non accettare mail da domini non risolvibili (di cui non è stato configurato il reverse DNS). Questo intervento, però, irschia di impedre la ricezione di mail da server SMTP validi per i quali non è stato correttamente configurato il DNS.
Fetchmail |
Overview e approfondimenti su fetchmail |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2004-06-02 10:00:42
Fetchmail è il più conosciuto software di mail retrieving per Linux, permette di collegarsi a diversi server di posta (POP3, IMAP4, ESMTP ETRN...) per lo scaricamento della mail da molteplici account e di smistare i messaggi sul server locale.
Un grande vantaggio nell'utilizzo di fetchmail è la garanzia che se il messaggio non viene smistato sul proprio MTA locale non viene perso, infatti al prossimo controllo di posta verrà nuovamente scaricato e fetchmail riproverà a smistarlo sino a quando non ci sarà un esito positivo.
Ci sono due modi per utilizzare fetchmail, da linea di comando passando determinati parametri, oppure utilizzando il file di configurazione ~/.fetchmailrc
, che quindi può essere gestito autonomamente da ogni utente del sistema.
AMBITI DI UTILIZZO
Spesso nasce l'esigenza all'interno di un'azienda di dotare tuui i propri dipendenti di posta elettronica per la comunicazione interna e di dover fornire ad altri "privilegiati" anche una mailbox raggiungibile da Internet.
In questi casi si può centralizzare lo scaricamento della posta, configurando i client per scaricare la propria posta esclusivamente da un mail server interno aziendale, dove fetchmail ha provveduto a scaricare la posta dal server di posta pubblico.
Un vantaggio di questo approccio è la possibilità di schedulare lo scaricamento via Internet dalla posta tramite fetchmail e risulta particolarmente utile (anche se in disuso) per società che si connettono ad Internet tramite connessioni dial-up.
Fetchmail inoltre permette di "sfioccare" tutta la mail pervenuta ad un account di posta pubblico (tipicamente un alias per ogni indirizzo di un dominio) in diverse caselle postali locali.
Inoltre, dotare i propri dipendenti di mailbox può causare il fatto che questi ultimi utilizzino la mailbox aziendale anche per scopi privati al di fuori dell'azienda, in tal caso con fetchmail il SysAdmin può attivare svariate mailbox pubbliche senza però fornire la password al dipendente che conoscerà solo quella della propria mail locale, raggiungibile solo dall'interno della rete aziendale.
Il fatto di diventare un punto intermedio fra il client (il comune programma di posta usato dagli utenti) e il server che riceve posta per i proprio domini, lo mette in grado di operare quelle funzioni di filtro (antispam, antivirus, aliasing e filtri custom) che è possibile centralizzare solo quando si ha il controllo del server di posta.
A prescindere dalle motivazioni e le scelte tecniche, Fetchmail di fatto non modifica la logica di configurazione dei client (devono sempre collegarsi ad un server POP3 o IMAP4 per scaricare la posta) e la necessità di avere un server di posta pubblico configurato come MX per i propri domini.
Solitamente Fetchmail si installa sulla stessa macchina in cui viene depositata la posta, per cui su questo sistema deve essere presente un server POP3/IMAP4. Il local delivery può essere fatto tramite un MDA (Sendmail Postfix ecc) o programmi come Procmail.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2004-06-02 10:04:20
Fetchmail può essere attivo sul sistema sia come demone, in cui a livello di file di configurazione si definisce ogni quanto tempo scaricare la posta, che in modalità standalone, demandando ad un lancio manuale o a cron le tempistiche di esecuzione.
La scelta di utilizzare l'una o l'altra soluzione è dipendente dal contesto di utilizzo di Fetchmail. Vediamo di seguito due casi dove in uno è meglio usare il software come demone e nell'altro lanciato da crontab.
SERVER LINUX CHE SI CONNETTE AD INTERNET IN DIAL UP
Anche se ormai in disuso Linux è spesso utilizzato come default gateway per reti LAN che lo utilizzano come dial up server per la condivisione della navigazione e il natting dei client/firewall.
In una situazione del genere è consigliabile eseguire Fetchmail da crontab in quanto è possibile impostare non solo il tempo tra un'esecuzione e l'altra ma anche i giorni in cui deve essere eseguito. Es. dal lunedì al venerdì dalle 08.00 alle 19.00
SERVER LINUX CHE SI CONNETTE AD INTERNET TRAMITE CONNESSIONE ALWAYS ON
In una situazione simile è inutile usare fetchmail da crontab ma conviene eseguirlo come demone all'avvio della macchina e lasciarlo in backgroud nel sistema.
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2004-06-02 11:55:52
Quando viene eseguito fetchmail utilizza di default il file di configurazione .fetchmailrc
sito nella home dell'utente. Spesso il file di conf va creato in /root/.fetchmailrc
essendo fetchmail eseguito come utente root, anche se questo può comportare complicazioni in termini di sicurezza.
Scaricamento di account POP3
Di seguito analizziamo brevemente la sintassi del file di configurazione per lo scaricamento di posta da un account POP3:
poll mail.openskills.info with proto POP3 user 'max' there with password 'prova' is maxgrante' here options keep
Analizzando attentamente la sintassi si capisce facilmente che viene settato con poll il server di posta esterno (mail.openskills.info), si specificano utente e password della mailbox remota (max, prova) con il relativo protocollo (POP3) ed infine viene detto a fetchmail a quale mailbox locale inoltrare la mail (maxgrante).
Naturalmente sul nostro server locale deve girare un MTA (sendmail, postfix ecc...) che possa ricevere la mail ed inoltrarla localmente. L'opzione keep dice a fetchmail di non cancellare la copia del messaggio sul server.
Ovviamente si possono aggiungere eventuali altri pop/imap server con i relativi account sulle diverse mailbox remote da far gestire al programma.
Scaricamento di un account multidrop
Uno dei punti di forza di Fetchmail è che può essere utilizzato per dividere la posta destinata ad un singolo account pubblico in diversi account locale.
Un esempio:
poll mail.openskills.info user 'info' there with password 'prova' to pippo pluto 'paperone'='paperino' here
In questo caso viene controllata la casella postale info e la mail viene smistata agli utenti locali pippo, pluto e paperino, considerando che tutta la mail destinata a paperone (sul server remoto) viene redirezionata all'utente paperino locale.
Il Web e i server Web |
Definizione del Web, visione d'insieme sui server disponibili, statistiche. |
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-06-11 15:05:21
Il www, acronimo di World Wide Web è il risultato dell'interconnessione fisica e logica fra un vasto numero di computer in rete.
Ogni computer su Internet viene definito host, ha un proprio indirizzo IP e può indifferentemente svolgere funzioni da client o server per una moltitudine di protocolli, a seconda del software installato ed utilizzato.
Nella sua forma base, un Server Web è un computer generalmente online 24 ore su 24, ha un indirizzo IP fisso a cui è associato un nome tipo www.dominio.com e, tramite un software dedicato (Apache, IIS, Zeus...) non fa altro che fornire file ai client (i browser come Netscape Navigator, Microsoft Internet Explorer, Opera...) che li richiedono.
Questi file sono tipicamente immagini (di solito in formato GIF e JPEG) e pagine HTML, normali file ASCII contenenti il testo di un linguaggio di programmazione ipertestuale che permette di formattare testo, grafica e link all'interno di schermate visualizzabili dal browser.
Il protocollo che gestisce il trasferimento di questi file fra client e server web è l'HTTP Hyper Text Transfer Protocol.
Di fatto mentre si naviga non si fa altro che trasferire file via rete, tramite il protocollo HTTP, dall'hard disk del server web al nostro computer, dove il browser interpreta le pagine HTML ricevute e le visualizza, richiedendo di volta in volta le immagini e gli altri file necessari per completare la visualizzazione delle pagine.
Cliccando su un link, l'utente richiede un diverso file html sul server su cui sta navigando o su un altro server che fisicamente potrebbe essere distante migliaia di chilometri dal primo.
Il gran numero di server web, che contiene una enorme quantità di pagine html che a loro volta includono innumerevoli link ipertestuali che collegano altre pagine, costituiscono l'ossatura di questa ragnatela globale che collega logicamente pagine e server fisicamente dislocati in ogni parte del globo.
Dal momento che sia il protocollo HTTP che il linguaggio di programmazione HTML sono definiti come standard, con regole ben precise, è normale e comune avere client e server web che "girano" anche su Sistemi Operativi diversi.
In pratica non c'è nessun problema a navigare con il proprio Windows 98 su un sito che risiede su un sistema Linux o Windows 2000 e viceversa.
HOWTO: Linux WWW HOWTO - http://ldp.openskills.info/HOWTO/WWW-HOWTO.html
HOWTO: Linux web browser station (formerly "The Linux Public Web Browser mini-HOWTO") - http://ldp.openskills.info/HOWTO/Public-Web-Browser.html
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: carlo 'carlo' - Ultimo Aggiornamento: 2003-11-03 14:19:42
E' grazie agli URL (Uniform Resource Locator) che i navigatori possono accedere alle informazioni del World Wide Web.
Il problema è che non esiste un indice principale, un unico punto di riferimento, che racchiuda in se tutte le risorse e le informazioni disponibili su Internet, quindi per recuperare una specifica informazione si possono utilizzare diversi protocolli e metodi.
I protocolli in questione sono:
HTTP = HyperText Transfer Protocol. Protocollo di trasferimento di ipertesto, quello che viene più utilizzato nel WWW.
FTP = File Transfer Protocol. Protocollo di trasferimento di file.
GOPHER = Gopher. Progenitore dell'HTTP, ormai poco usato.
TELNET = Telnet. Protocollo per accedere, tramite interfaccia testuale, ad un host (computer) remoto.
NEWS = Network News Transfer Protocol. Protocollo di trasferimento delle news.
Ciascun tipo di protocollo ha un formato leggermente diverso per identificare univocamente la locazione di una risorsa.
HTTP e FTP
Questi due protocolli hanno lo stesso formato in quasi tutti i casi.
Locazione risorsa=//nome_server/percorso_documento
ad esempio per individuare, tramite protocollo HTTP, il file pippo.htm, contenuto nella directory mio sul server xxx.yyy.it si utilizzerà l'URL:
http://xxx.yyy.it/mio/pippo.htm
.
Gopher
Il campo tipo è un singolo carattere che viene utilizzato dal protocollo Gopher per determinare il tipo di documento (quello predefinito è 1). Il resto del percorso è il documento o la stringa del selettore di risorse, come descritto nel protocollo Gopher.
Ad esempio, per accedere al documento principale sul server gopher.biz.com, si utilizza l'URL
gopher://gopher.biz.com/1
Telnet
Sulla maggior parte dei sistemi aprendo un URL di Telnet si lancia semplicemente un'applicazione esterna di telnet e ci si può connettere da lì.
Locazione risorsa=//nome_utente:password@nome_del_server
ad esempio per collegarsi a xxx.yyy.it come mariorossi si utilizza l'URL
telnet://[email protected]
News
Per la maggior parte dei programmi di ricerca si deve impostare una preferenza che indica quale server richiedere per gli URL di News. Ogni server ha i propri identificatori per ciascun articolo, quindi è meglio prima chiedere un elenco di articoli correnti omettendo le parole chiave primo e ultimo.
Locazione risorsa=gruppo di lettura delle news: primo articolo-ultimo articolo
Ad esempio per chiedere gli articoli in alt.flame si utilizza l'URL
news:alt.flame
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2003-02-03 11:38:28
Ci sono molti software con funzioni da server web disponibili sul mercato. Ecco un elenco dei piu rappresentativi con una breve descrizione
Apache (www.apache.org) sviluppato dalla Apache Software Foundation è diffuso sia nella versione 1.3 che nella 2.0
Pro: Gratis, open-source, espandibile grazie alla grande quantità di moduli che supporta, altamente e facilmente configurabile.
Contro: Performance non ottimali.
Il piu utilizzato, gira praticamente su tutte le piattaforme, Windows incluso. Il suo design modulare permette di aggiungere features facilmente..
Microsoft Internet Information Server (www.microsoft.com) sviluppato dalla Microsoft Corp.
Pro: Facile da usare; buon supporto tecnico; buone performance
Contro: Ha una storia travagliata in termini di sicurezza; non open-source ; tuning limitato
Ben integrato con Windows, permette una facile installazione e configurazione. Facile da usare, ha avuto seri e ripetuti problemi di sicurezza.
Zeus 4.0 (www.zeus.com) sviluppato dalla Zeus Technology Ltd.
Pro: Molto veloce; scalabile, interfaccia user-friendly.
Contro: Poco espandibile; costoso (1700 dollari circa a server).
Zeus web server ha features estensibili, una interfaccia ben fatta, ottime performance e gira su piattaforme Unix.
iPlanet Web Server Enterprise Edition (www.iplanet.com) sviluppato dalla iPlanet E-Commerce Solutions, poi definitivamente acquisita da Sun, deriva dal Netscape Server, a suo tempo un leader del mercato.
Pro: Eccellente supporto java, buone performance.
Contro: Poco espandibile, interfaccia poco intuitiva, costoso (poco meno di 1500 dollari per CPU).
Per una lista completa dei server Web disponibili è comoda la directory di DMOZ: http://dmoz.org/Computers/Software/Internet/Servers/WWW/
LINK: DMOZ: Web servers software - http://dmoz.org/Computers/Software/Internet/Servers/WWW/
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2003-02-03 11:39:43
Esistono in rete siti e studi che raccolgono informazioni sulla diffusione dei server Web e il loro utilizzo.
Il più significativo è senz'altro Netcraft che fornisce interessanti e attendibili statistiche su quali sono i server Web maggiormente utilizzati in rete e i relativi trend di sviluppo.
Il dominatore incontrastato del mercato è Apache, nelle sue varie versioni, presente su più del 60% dei webserver in rete.
A seguire, ben distanziato è IIS di Microsoft, più del 25% di installazioni.
Agli altri prodotti, commerciali o opensource, rimangono le briciole: iPlanet, Zeus, Rapidsite e una pletora di altri contano per il 2% o meno.
Oltre a Netcraft, altri siti in rete forniscono dati e statistiche. Fra questi il più promettente è il Securityspace Web Server Survey che offre statistiche dettagliate ed estrapolazioni interessanti.
SOURCE: Netcraft.com - http://www.netcraft.com/survey/
LINK: Security Space Web Server survey - http://www.securityspace.com/s_survey/data/index.html
Tipo Infobox: DESCRIPTION - Skill Level: 1- NOVICE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2006-03-24 10:11:32
L'utilizzo di soluzioni LAMP è sicuramente largo in termini numerici (numero di installazioni) e di varietà di applicazioni (contesti di utilizzo, livello di criticità e volumi di traffico), ma per avere un'idea ragionevolmente precisa della loro diffusione è opportuno apporggiarsi alle statistiche disponibili Online.
APACHE
La diffusione di Apache è enorme e comprovata dai dati mensili di Netcraft, la più autorevole fonte online sulle statistiche di utilizzo di server web in rete.
A Febbraio 2006 Apache è stato trovato su 51.810.676 siti web con il 68,01% di share (si considerano siti web, e non singoli host, che usano Apache su diversi sistemi operativi, tra cui Linux, FreeBsd, Windows, Solaris).
Anche Security Space fornisce interessanti statistiche sulla diffusione dei server Web. A Febbraio Apache è stato riscontrato su 12.523.422 siti con uno share del 71,66%
PHP
L'ascesa di PHP come linguaggio per il Web è inesorabile e costante, in http://www.php.net/usage.php è possibile vederne i dettagli, sempre basati su fonte Netcraft.
Interessante è inoltre il TIOBE Programming Community Index che valuta la diffusione di utilizzo di un linguaggio sulla base della diffusione di corsi e sviluppatori, calcoalata in base a query sui motori di ricerca. A Marzo 2006 PHP si piazza al quarto posto (dopo C, Java, C++) con un 9,948 % di diffusione e risulta di fatto il linguaggio Web oriented più diffuso (due anni prima era al sesto posto con il 7.421%).
Altra interessante e indicativa fonte per conoscere la diffusione di PHP è l'Apache Module Report di Security Space. A Febbraio 2006 PHP è presente nel 43,23% delle installazioni Apache monitorate, per un numero totale di 5.413.310.
MYSQL
Non esistono statistiche rilevanti sulla diffusione di MySQL per cui si possono fare solo constatazoni indirette sul suo utilizzo: è presente nella maggior parte delle distribuzioni Linux ed è ragionevole aspettarsi che sia il database backed più utilizzato in siti dinamici basati su PHP.
Ha inoltre conquistato una ottima reputazione in termini di velocità e una buona fama in termini di affidabilità. I case study e l'elenco dei principali clienti riportati sul sito di MySQL danno una idea sul suo utilizzo anche in ambienti enterprise.
Le ultime versioni, inoltre, sono fortemente orientate a colmare le principali lacune di MySQL (integrità referenziale, supporto di view, trigger e stored procedures, clustering) e buoni passi avanti sono stati fatti in questi campi.
LINK: Netcraft - http://www.netcraft.com
LINK: Security Space - http://www.securityspace.com
LINK: TIOBE Programming Community Index - http://www.tiobe.com/tpci.htm
I protocolli HTTP e HTTPS |
HyperText Transfer Protocol: sintassi, headers, URI e methods. Introduzione a HTTPS. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-02-03 12:01:44
Il protocollo HTTP (Hyper Text Transfer Protocol) viene usato da tutti i client e server web e gestisce il modo con cui questi si scambiano pagine HTML o altri file.
Il client web (cioè un browser come Microsoft Internet Explorer, Netscape Navigator, Opera ecc.) utilizza l'HTTP per richiedere file al server web. In primo luogo vengono richieste pagine HTML, che dopo essere state ricevute, vengono processate dal browser che provvede a fare richiesta di eventuali nuovi file richiamati nel codice HTML (immagini, fogli di stile css, script esterni ecc.) e a visualizzare il tutto sul monitor dell'utente.
Ogni richiesta http consta di:
- Metodo (GET, HEAD, PUT ...)
- URI (Uniform Resource Identifier) Il path o indirizzo completo della risorsa richiesta.
- Versione del protocollo (HTTP/1.0 o HTTP/1.1)
Un esempio tipico di una richiesta HTTP è:
GET / HTTP/1.0
Alla richiesta possono seguire degli HTTP headers come Accept-Language
, Date
, Expires
e vari altri (possono essere arbitrariamente definiti fra broswer e server).
Esistono attualmente 3 specifiche del protocollo HTTP:
HTTP/0.9 - Di fatto non è più utilizzato da nessuna parte
HTTP/1.0 - Ancora abbastanza utilizzato e supportato da ogni browser e web server
HTTP/1.1 - Introduce nuovi metodi (OPTIONS, TRACE, DELETE, PUT, CONNECT) e la gestione di Virtual Host. E' supportato da tutti i browser e server non troppo vecchi ed è utilizzato nella maggior parte dei casi.
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-02-03 12:05:32
Un metodo HTTP può considerarsi un comando proprio del protocollo HTTP che il client richiede al server.
Ne esistono vari, ma di fatto i più utilizzati sono GET (per richiedere un file) e POST (per inviare informazioni al server).
GET - Richiede un file al server. La risposta è composta da vari header separati con due Carriage Return dalla risorsa effettivamente richiesta (il file HTML che contiene l'home page del sito). All'inizio della risposta viene specificato il protocollo usato (HTTP/1.1) e lo Status Code che indica l'esito della richiesta fatta (200 OK vuol dire che la richiesta ha avuto successo e il server ha fornito i dati chiesti).
GET / HTTP/1.0
HTTP/1.1 200 OK
Date: Wed, 23 Oct 2002 08:18:47 GMT
Server: Apache/1.3.26 (Unix) PHP/4.2.3
X-Powered-By: PHP/4.2.3
Set-Cookie: PHPSESSID=8fd7c6a69c84da8276187e18a3067b85; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: close
Content-Type: text/html
[Contenuto della pagina HTML..]
HEAD - Richiede solo l'header, senza la risorsa (il file HTML, l'immagine, ecc.). Di fatto viene usato soprattutto per diagnostica.
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Date: Wed, 23 Oct 2002 08:31:36 GMT
Server: Apache/1.3.26 (Unix) PHP/4.2.3
X-Powered-By: PHP/4.2.3
Set-Cookie: PHPSESSID=d0226985ad2282fd9e2d9f6fb868b92a; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: close
Content-Type: text/html
POST - Invia informazioni all'URI specificato. Le informazioni sono presenti in coppie attributo=valore&attributo=valore e vengono processate dal server sulla base di come è configurato e di come è fatto il file a cui vengono postate.
Viene qui riportato il POST di un browser reale, con tutti gli header inviati dal browser stesso e l'inizio delle coppie attributo=valore.
POST /modify/modify.php HTTP/1.1
Host: openskills.info
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
Accept-Language: en-us, en;q=0.50
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
Cookie: PHPSESSID=fdcb56ecb694a7564dc814b422dd2a7d
Referer: http://openskills.info/modify/modify.php?table=box&IDbox=357&boxtype=infobox&LANGUAGE=ita
Content-Type: application/x-www-form-urlencoded
Content-Length: 2431
IDbox=357&box_title=I+metodi+HTTP&[attributi=valori]
HTTP/1.1 200 OK
Date: Wed, 23 Oct 2002 08:38:51 GMT
Server: Apache/1.3.26 (Unix) PHP/4.2.3
X-Powered-By: PHP/4.2.3
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Keep-Alive: timeout=25, max=85
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
[HTML della pagina di risposta]
I metodi finora elencati sono comuni sia al protocollo HTTP/1.0 che all'HTTP/1.1, quelli che seguono invece sono esclusivi del HTTP/1.1 e, spesso, non vengono permessi dai server.
Nella configurazione di default di Apache, per esempio, sono disattivati.
Se si prova ad utilizzarli su server che non li permettono si ottiene uno Status code: 405 Method not allowed.
Quando si usa il protocollo HTTP/1.1 è necessario specificare l'host a cui si intende fare la richiesta.
OPTIONS - Richiede l'elenco dei metodi permessi dal server.
OPTIONS * HTTP/1.1
Host: openskills.info
TRACE - Traccia una richiesta, visualizzando come viene trattata dal server.
TRACE * HTTP/1.1
Host: openskills.info
DELETE - Cancella una risorsa (file) sul server. L'utente con cui gira il web server deve poter avere permessi in scrittura sul file indicato e il server deve essere configurato per poterlo fare.
DELETE /info.html HTTP/1.1
Host: openskills.info
PUT - Uploada un file sul server, creandolo o riscrivendolo, con il nome indicato e i contenuti specificati nella parte che segue gli header.
PUT /info.html HTTP/1.1
Host: openskills.info
[Contenuto file]
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2003-02-03 12:25:30
Gli header HTTP vengono trasferiti fra client e server e generalmente contengono meta-informazioni sul contenuto effettivo della risorsa (file) trasferita.
Il loro formato è:
NomeHeader: Valore (CRLF)
in una richiesta o una risposta HTTP possono esistere un numero arbitrario di header, il loro ordine non è importante ma è raccomandato un ordine sulla base delle categorie sotto indicate.
Esistono 4 categorie di header, di queste citiamo solo le voci più significative:
1 - GENERAL HEADERS
Contengono informazioni generali non relative al server, al client, al dato trasferito o al protocollo HTTP.
Cache-Control: direttive
- Definisce le direttive sia associate a richieste che a risposte (separate da virgola) a cui devono obbedire tutti i sistemi di caching fra client e server. Quando sul proprio browser si cambiano le impostazioni relative alla cache, di fatto si modificano le direttive gestite con questo header.
Date: data_rfc-1123
- (es: Wed, 23 Oct 2002 18:59:12 GMT) La data è quella in cui il messaggio viene originato.
Pragma: no-cache
- Il contenuto richiesto non deve essere messo in alcuna cache (del browser, di un proxy ecc.). Fondamentale per pagine dinamiche che devono essere sempre aggiornate.
Via: protocollo host_ricevente [commento]
- Va aggiunto da proxy o gateway per indicare i protocolli e gli host intermedi fra client e server attraverso i quali è passata la richiesta.
Upgrade: protocollo/versione
- Permette al client di specificare che supporta una versione di protocollo superiore a quella che si sta utilizzando (tipicamente HTTP/1.1 rispetto a HTTP/1.0) e al server di indicare su quale protocollo ha switchato.
2 - REQUEST HEADERS
Sono riservati alla richieste che il client esegue e contengono informazioni riguardo la richiesta stessa o il client.
Accept: tipo/sottotipo [;q=valore]
- Indica quali tipi di file sono accettati dal client, in formato MIME (es: text/html). Con il parametro q (valori da 0 a 1) si definisce la preferenza relativa al tipo indicato (es: Accept: text/plain; q=0.5, text/html; q=0.8).
Accept-Charset: charset [;q=valore]
- Indica i charset (set di caratteri per le diverse lingue) il client accetta e in che ordine.
Accept-Encoding: encoding-type [;q=valore]
- Indica il tipo di encoding che il client può accettare (es: Accept-Encoding: gzip, default, compress;q=0.9).
Accept-Language: lingua [;q=valore]
- Indica la lingua che il client preferisce e quali può comunque accettare (es: Accept-Language: en-us, en;q=0.5).
Authorization: credenziali
- Quando l'utente si è autenticato e accede a pagine protette, il client con questo header fornisce le credenziali richeste ed evita ultetiori richieste di autenticazione da sottoporre all'utente.
3 - RESPONSE HEADERS
Sono riservati alle risposte del server e contengono info sul server stesso o sulla risorsa richiesta. Fra questi:
Age: secondi
- Tempo stimato da quando è stata generata la risposta sul server.
Server string
- Contiene informazioni sulla versione del software utilizzata dal server
4 -ENTITY HEADERS
Contengono meta-informazioni sull'entità (file) trasferito.
Content-Encoding: encoding
- Indica quali tipi di encoding (es: gzip) sono stati fatte sul contenuto del messaggio, per permettere al client di decodificarlo.
Content-Language: lingue
- Indica la lingua presunta dell'utente che riceve il file, si basa sull'analogo Request header Accept-Languages.
Content-Lenght: bytes
- Indica la lunghezza in byte del file servito.
Expires: data
- Indica la data dopo la quale il file servito è da considerare obsoleto. Va considerata da tutti i meccanismi di cache coinvolti nella richiesta.
Last-Modified: data
- Indica la data di ultima modifica del file.
LINK: W3C: Object Header lines in HTTP - http://www.w3.org/Protocols/HTTP/Object_Headers.html
LINK: Quick reference to HTTP headers - http://www.cs.tut.fi/~jkorpela/http.html
SOURCE: RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1 - http://www.w3.org/Protocols/rfc2616/rfc2616.html
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2003-02-03 12:32:57
I server HTTP rispondono utilizzando linee di status che informano il client sull'esito della richiesta.
Gli status contengono 3 campi: versione del protocollo HTTP, status code e descrizione.
Lo status code è dato da un numero a 3 cifre con i seguenti significati:
1XX - Informational
2XX - Client request successful
3XX - Client request redirected, futher action necessary
4XX - Client request incomplete
5XX - Server errors
1xx - INFORMATIONAL
Questa classe di status consiste solo nella status line e in headers opzionali. HTTP/1.0 non definisce nessuno status code 1XX.
100 Continue - Il client può continuare con la sua richiesta. Questa risposta intermedia è inviata al client dal server per informarlo che la parte iniziale della sua richiesta non è stata respinta. Il client ora può completarla o ignorare la risposta se la richiesta è gia stata inviata per intero. Quando la richiesta è stata completamente inviata il server invierà una risposta finale.
101 Switching Protocols - Il server riceve una richiesta per il cambiamento del protocollo per quella connessione.
2xx - SUCCESSFUL CLIENT REQUEST
I seguenti status code indicano che la richiesta da parte del client è stata ricevuta, capita e accettata.
200 OK - La richiesta è stata accolta, il server risponde con i dati richiesti. E' la risposta normale per un file correttamente trasferito.
201 Created - La richiesta è stata effettuata ed una nuova risorsa è stata creata. L'URI rinviato nella risposta fa riferimento alla nuova risorsa creata.
202 Accepted - La richiesta è stata accettata ma non ancora processata.
203 Non-Authorative Information - L'insieme delle informazioni rimandate contenute nell'entity-header non è l'insieme di informazioni mandate dal server di origine ma provengono da una copia fatta in locale o da terzi.
204 No Content - Il server ha effettuato la richiesta ma non si necessita il rinvio dell'entity-body. A questa risposta il browser non dovrebbe aggiornare il documento visualizzato.
205 Reset Content - Il browser alla ricezione di questo status code dovrebbe resettare il contenuto del form che ha causato l'invio della richiesta.
206 Partial Content - Il server ha effettuato un GET parziale della risorsa. Questo succede quando risponde a una richiesta contenente un Range header.
3xx - CLIENT REQUEST REDIRECTED
Questa classe di status indica che si necessita di un'ulteriore azione per far si che la richiesta sia correttamente effettuata.
300 Multiple Choices L'URI richiesto corrisponde a piu documenti (per esempio un documento disponibile in piu lingue).
301 Moved Permanently - La risorsa richiesta è stata assegnata definitivamente ad un nuovo URI.
302 Moved Temporarily - La risorsa richiesta è stata assegnata temporaneamente ad un nuovo URI. Il client può usare il nuovo URI per le attuali richieste, ma in futuro (quando non vi sarà piu redirezione) dovrà usare il vecchio URI.
303 See Other - La risorsa richiesta si trova in un altro URI specificato nel Location header.
304 Not Modified - Il Client ha effettuato una richiesta GET condizionale usando l'If-Modified-Since header, ma la risorsa non è stata ancora modificata. La risorsa non viene mandata in quanto il client la possiede gia in locale.
305 Use Proxy - La risorsa richiesta deve passare per un proxy il cui l'URI è dato nel Location field.
4xx - CLIENT REQUEST ERRORS
La classe di status 4XX è riservata ai casi in cui il client commette degli errori.
400 Bad Request - Richiesta non capita dal server causa sintassi errata.
401 Authorization Required - Questo risultato è dato dal WWW-Authenticate header per indicare che la richiesta era sprovvista dell'autorizzazione che quella determinata risorsa richiede.
402 Payment Required - Questo codice è riservato ad usi futuri.
403 Forbidden - Il server capisce la richiesta ma si rifiuta di compierla. La richiesta non dovrebbe essere ripetuta.
404 Not Found - Il server non ha trovato nulla che corrisponda all'URI richiesto. Dopo il codice 200, questo è tipicamente quello più riscontrato nei log dei server web.
405 Method Not Allowed - Il metodo specificato nella request line non è disponibile per l'URI richiesto
406 Not Acceptable (encoding) - La risorsa identificata tramite richiesta può solo generare una risposta che ha caratteristiche incompatibili con gli accept headers contenuti nella richiesta.
407 Proxy Authentication Required - Questo codice indica che il client deve prima autenticarsi con il proxy, usando l'header Proxy-Authenticate.
408 Request Timed Out - Il client non ha fornito una richiesta nel tempo massimo di attesa del server.
409 Conflict - La richiesta non puo essere completata causa conflitto con il corrente stato della risorsa.
410 Gone - La risorsa richiesta non è piu disponibile sul server e il server non conosce indirizzi su cui ridirezionare.
411 Length Required - Il server si rifiuta di accettare la richiesta in quanto il client non ha definito il Content-Length.
412 Precondition Failed - Una o piu condizioni specificate negli IF request headers è risultata falsa al momento del test del server.
413 Request Entity Too Large - La richiesta è piu grande rispetto a quello che il server può processare.
414 Request URI Too Long - L'URI richiesto è troppo lungo per essere interpretato dal server.
415 Unsupported Media Type - Il corpo della richiesta è in un formato non supportato.
5xx - SERVER ERRORS
Questa classe di status è riservata ai casi in cui il server commette un errore o non è in grado di performare la richiesta. In genere richiede un intervento sistemistico sul server.
500 Internal Server Error - Il server è in una situazione inaspettata e non può rispondere alle richieste.
501 Not Implemented - Il server non è implementato per rispondere correttamente alla richiesta effettuata.
502 Bad Gateway - Il server collegato ad un gateway o ad un proxy, riceve una risposta non valida da questo.
503 Service Unavailable - Il server non può rispondere causa temporaneo overload.
504 Gateway Timeout - Il server collegato ad un gateway o ad un proxy, non riceve una risposta da questo nel tempo di attesa massimo impostato.
505 HTTP Version Not Supported - Il server non supporta la versione del protocollo HTTP utilizzato per fare la richiesta.
Installare e compilare APACHE |
Installazione e upgrade di Apache tramite package e sorgenti. |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2003-02-03 17:02:43
Ci sono due modi per compilare ed installare Apache 1.3 direttamente dai sorgenti:
Il primo prevede l'utilizzo del processo APACI, descritto sotto, il secondo è il metodo piu classico, che segue le procedure descritte nel file /src/INSTALL.
Entrambi i 2 metodi hanno pregi e difetti: APACI è piu nuovo e un po più grezzo, ma permette una rapida installazione, il secondo metodo è più lungo, ma può risultare più familiare a molti e permette una installazione piu minuziosa.
I requisiti di sistema sono:
- 12 Mbyte di spazio libero sull'harddisk durante l'installazione, anche se alla fine ne occuperanno generalmente 3 (dipende poi da quali e quanti moduli si desidera installare)
- ANSI-C Compiler: Prima di iniziare l'installazione bisogna essere certi di aver installato un compilatore ANSI-C. E' raccomandato il compilatore GNU GCC.
- Perl 5 Interpreter [opzionale]: Per alcuni script come 'apxs o 'dbmmanage" (scritti appunto in perl) il Perl interpreter è richiesto (se manca comunque APACI farà l'installazione, ma gli script in Perl non andranno). Se si possiedono piu interpreti Perl (esempio Perl 4 e Perl 5), si consiglia di utilizzare l'opzione --with-perl per selezionare quello giusto.
- Dynamic Shared Object (DSO) support [opzionale]: Apache ha la capacità di poter caricare moduli mentre è in esecuzione attraverso DSO utilizzando chiamate di sistema come dlopen()/dlsym(). Se in un sistema non è presente il supporto DSO, Apache non riuscirà a caricare i moduli durante l'esecuzione (c'è da dire che tanti preferiscono configurazioni statiche, ossia senza l'utilizzo dei moduli).
INSTALLARE APACHE 1.3 CON APACI
Overview:
./configure --prefix=PREFIX
make
make install
PREFIX/bin/apachectl start
Dove PREFIX è il path dove Apache viene installato, di default /usr/local/apache/
Configurare l'albero delle sorgenti:
Una corretta configurazione è essenziale per una buona installazione di Apache, in funzione della piattaforma e dei requisiti personali. Il parametro piu importante è il path dove Apache viene installato. Per una lista completa delle opzioni disponibili lanciare ./configure --help
.
Nel seguente esempio è riportata la configurazione di Apache con un particolare compilatore C e con l'installazione dei 2 moduli mod_rewrite e mod_proxy.
CC="pgcc" OPTIM="-O2" \
./configure --prefix=/usr/local/apache \
--enable-module=rewrite --enable-shared=rewrite \
--enable-module=proxy --enable-shared=proxy
Costruire il pacchetto:
Per costruire il pacchetto, compilando i sorgenti secondo le configurazioni definite, basta semplicemente lanciare il comando make
.
Se si possiede una macchina abbastanza lenta e si intende installare parecchi moduli si dovra attendere qualche minuto.
Installare il pacchetto:
Per installare il pacchetto nel path prima specificato (--prefix=...), basta lanciare il comando make install
.
Testare Apache:
Per testare se l'installazione è avvenuta correttamente avviare Apache lanciando PREFIX/bin/apachectl start
, aprire il browser, andare su http://localhost
e vedere se risponde alla richiesta.
INSTALLARE APACHE 1.3 CON IL METODO TRADIZIONALE
Il metodo tradizionale permette di installare Apache piu minuziosamente e senza dover digitare tutte le opzioni desiderate.
Configurare l'installazione:
La compilazione di Apache può essere suddivisa in 3 step: primo selezionare i moduli da includere, secondo creare la configurazione in funzione del proprio sistema operativo, terzo compilare l'eseguibile.
- Per selezionare i moduli basta scommentare le linee nel file di configurazione dell'installazione relative ai moduli desiderati o, nel caso si vogliano inserire nuovi moduli non presenti nell'installazione standard (es mod_PHP) basta aggiungerene la riga relativa.
- Per configurare Apache solitamente basta lanciare lo script, ma puo capitare di avere richieste particolari (come, per esempio delle librerie necessarie ad un modulo), per cui serve editare nel file di configurazione le seguenti opzioni: EXTRA_CFLAGS, LIBS, LDFLAGS, INCLUDES:
./configure
Using nomefile.conf as config file
+ configured for OS platform
+ setting C compiler to OS *
+ setting C compiler optimization-level to OS *
+ Adding selected modules
+ doing sanity check on compiler and options
Creating Makefile in support
Creating Makefile in main
Creating Makefile in os/unix
Creating Makefile in modules/standard
Questo è un esempio di standard output, per cui le parti commentate varieranno in funzione della piattaforma su cui si installa Apache e del file di configurazione usato. Le parti contrassegnate da '*' possono anche non essere printate, dipende sempre dal sistema operativo e dalla configurazione utilizzata. Per quanto riguarda il file di configurazione è possibile passargli un file alternativo lanciando lo script con l'opzione --file nomefile.conf.
Compilare Apache
Per compilare Apache lanciare il comando make
.
Installare Apache
Ora abbiamo il binario chiamato httpd. Apache è fatto per essere configurato ed eseguito nella stessa directory dove e' stato compilato. Ora bisogna configurare il file di configurazione principale httpd.conf.
Testare apache:
Per testare se l'installazione è avvenuta correttamente startare Apache lanciando PREFIX/bin/apachectl start
, aprire il browser, andare su http://localhost e vedere se risponde alla richiesta.
HOWTO: Apache Compile HOWTO - http://ldp.openskills.info/HOWTO/Apache-Compile-HOWTO/index.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2003-08-06 12:22:56
Fra i vari modi con cui è possibile installare Apache su distribuzioni RedHat based, quello più semplice è tramite pacchetti RPM.
Per farlo, innanzitutto bisogna scaricare il pacchetto apache-ver.arch.rpm appropriato per la propria distribuzione Linux, dove ver sta per versione e arch per architettura.
Una volta fatto questo andare dove si è scaricato il pacchetto e lanciare il comando (esempio per Apache 1.3):
[root@eberk diego]# rpm -ihv ./apache-1.3.9-4.i386.rpm
/etc/httpd/conf
/etc/httpd/conf/access.conf
/etc/httpd/conf/httpd.conf
/etc/httpd/conf/magic
/etc/httpd/conf/srm.conf
/etc/httpd/logs
[...]
/home/httpd
/home/httpd/cgi-bin
/home/httpd/html
/home/httpd/html/index.html
[...]
/usr/sbin/httpd
/usr/sbin/logresolve
/usr/sbin/rotatelogs
/usr/sbin/suexec
[...]
Ora Apache è installato.
Attenzione, alcuni moduli per Apache non sono contenuti nell'RPM di installazione (per esempio mod_PHP, mod_PERL ecc...), e vanno installati tramite gli appositi RPM.
In genere su qualsiasi distribuzione è già inclusa, e installabile fin dall'inizio, una versione di Apache.
Per aggiornarla con una versione più recente basta il solito:
[root@eberk diego]# rpm -Uv ./apache-1.3.9-4.i386.rpm
Per gestire correttamete le dependencies, per esempio con un Apache con MOD_php con supporto MySQL e MOD_ssl seguire questo ordine: Apache, Mysql (pacchetto base + server + devel), PHP, MOD_php, php-mysql, OpenSSL, MOD_ssl.
Su RedHat, Apache 2.0 è stato introdotto di default dalla versione 8.0 (notare che il nome del pacchetto è httpd-versione.rpm e non più apache-versione.rpm). I pacchetti relativi sono:
httpd - Il server web Apache (2.0)
httpd-devel - Le librerie che permettono la compilazione di moduli addizionali (non serve se non si compilano a mano)
redhat-config-httpd - Un semplice tool di configurazione visuale (non serve se si edita a mano httpd.conf)
httpd-manual - le pagine del manuale di Apache
mod_ssl - Supporto delle criptazioni dei dati per https (richiede openssl)
mod_perl - Modulo Apache per il supporto Perl
mod_python - Modulo Apache per il supporto Python
php - Supporto PHP (come modulo Apache o standalone). Se servono moduli specifici per PHP questi vanno installati (es: php-mysql, php-imap, php-snmp...)
Notare che sui sistemi RedHat la DocumentRoot
, direcrtoty dove di default vanno inserite le pagine html di un sito), era /home/httpd/html
nelle versioni fino alla 6.2 ed è diventata /var/www/html
nelle versioni successive.
LINK: RPMFIND: Ricerca e il download di RPM - http://www.rpmfind.net
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-02-03 14:00:32
Molte opzioni di compilazione di Apache si riferiscono al path da utilizzare per varie directory (dir di base, documenti, log, configurazioni, binari ecc.).
E' possibile specificarle singolarmente oppure usare dei layout predefiniti, che presentano dei template di base, sulla posizione delle directory, che si adattano a diversi sistemi.
Nel file config.layout
all'interno del tar.gz ufficiale si trovano alcuni template predefiniti.
Fra questi segnaliamo quello di default, che mette tutto nella directory /usr/local/apache e in sue sottodirectory:
<Layout Apache>
prefix: /usr/local/apache
exec_prefix: $prefix
bindir: $exec_prefix/bin
sbindir: $exec_prefix/bin
libexecdir: $exec_prefix/libexec
mandir: $prefix/man
sysconfdir: $prefix/conf
datadir: $prefix
iconsdir: $datadir/icons
htdocsdir: $datadir/htdocs
manualdir: $htdocsdir/manual
cgidir: $datadir/cgi-bin
includedir: $prefix/include
localstatedir: $prefix
runtimedir: $localstatedir/logs
logfiledir: $localstatedir/logs
proxycachedir: $localstatedir/proxy
</Layout>
Un'altro template spesso usato è quello utilizzato da distribuzioni Linux derivate da RedHat e basate su RPM:
<Layout RedHat>
prefix: /usr
exec_prefix: $prefix
bindir: $prefix/bin
sbindir: $prefix/sbin
libexecdir: $prefix/lib/apache
mandir: $prefix/man
sysconfdir: /etc/httpd/conf
datadir: /var/www
iconsdir: $datadir/icons
htdocsdir: $datadir/html
manualdir: $datadir/manual
cgidir: $datadir/cgi-bin
includedir: $prefix/include/apache
localstatedir: /var
runtimedir: $localstatedir/run
logfiledir: $localstatedir/log/httpd
proxycachedir: $localstatedir/cache/httpd
</Layout>
Per utilizzare uno specifico layout si usa la direttiva --with-layout, per esempio:
./configure --with-layout=Solaris
Nella versione 1.3.27 sono predefiniti i seguenti layout: Apache, GNU, BinaryDistribution, Mac OS X Server, Darwin, RedHat, opt, beos, SuSE, BSDI, Solaris, FreeBSD, OpenBSD, Cygwin.
E' possibile utilizzare un layout di base e approntare modifiche su specifici path. Per esempio:
./configure --with-layout=RedHat --data-dir=/home/httpd/html
Fra le direttive che agiscono sulla posizione dei vari file le più significative sono:
--prefix=PATH
- Indica la directory di base di installazione e il valore di default della server root.
--target=NOME
- Modifica il nome di base dell'eseguibile httpd, dei file di lock e scoreboard, delle directory in cui sono contenuti i vari file. Come --prefix, è utile per far convivere 2 diverse versioni di Apache sulla stessa macchina.
Tramite l'opzione --show-layout è inoltre possibile visualizzare, senza compilare nulla, i vari path di installazione e compilazione:
./configure --with-layout=GNU --target=althttpd --show-layout
Configuring for Apache, Version 1.3.27
+ using installation path layout: GNU (config.layout)
Installation paths:
prefix: /usr/local
exec_prefix: /usr/local
bindir: /usr/local/bin
sbindir: /usr/local/sbin
libexecdir: /usr/local/libexec
mandir: /usr/local/man
sysconfdir: /usr/local/etc/althttpd
datadir: /usr/local/share/althttpd
iconsdir: /usr/local/share/althttpd/icons
htdocsdir: /usr/local/share/althttpd/htdocs
manualdir: /usr/local/share/althttpd/htdocs/manual
cgidir: /usr/local/share/althttpd/cgi-bin
includedir: /usr/local/include/althttpd
localstatedir: /usr/local/var/althttpd
runtimedir: /usr/local/var/althttpd/run
logfiledir: /usr/local/var/althttpd/log
proxycachedir: /usr/local/var/althttpd/proxy
Compilation paths:
HTTPD_ROOT: /usr/local
SHARED_CORE_DIR: /usr/local/libexec
DEFAULT_PIDLOG: var/althttpd/run/althttpd.pid
DEFAULT_SCOREBOARD: var/althttpd/run/althttpd.scoreboard
DEFAULT_LOCKFILE: var/althttpd/run/althttpd.lock
DEFAULT_ERRORLOG: var/althttpd/log/error_log
TYPES_CONFIG_FILE: etc/althttpd/mime.types
SERVER_CONFIG_FILE: etc/althttpd/althttpd.conf
ACCESS_CONFIG_FILE: etc/althttpd/access.conf
RESOURCE_CONFIG_FILE: etc/althttpd/srm.conf
Tipo Infobox: STDOUT - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-11-06 22:56:49
Aggiornare Apache con regolarità e sopratutto in caso di patching di nuovi buchi di sicurezza è un'attività fondamentale che non richiede molto tempo.
Segue lo standard output della procedura di aggiornamenti di Apache dalla versione 1.3.26 alla versione 1.3.27. Quanto qui riportato è ovviamente fattibile anche con altre versioni (ma non con un passaggio dalla 1.3 alla 2.0).
In questo caso la compilazione viene eseguita sul server stesso su cui gira Apache e usando la base directory di default ( /usr/local/apache ).
Per sicurezza si fa un backup preventivo di tutta la basedir di Apache
[root@socrate al]# tar -zcvf backup.tar.gz /usr/local/apache
Download dei sorgenti con wget
[root@socrate al]# wget http://nagoya.apache.org/dist/httpd/apache_1.3.27.tar.gz
--09:46:37-- http://nagoya.apache.org/dist/httpd/apache_1.3.27.tar.gz
=> `apache_1.3.27.tar.gz'
Resolving nagoya.apache.org... done.
Connecting to nagoya.apache.org[192.18.49.131]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2,306,052 [application/x-tar]
100%[====================================>] 2,306,052 16.80K/s ETA 00:00
09:48:52 (16.80 KB/s) - `apache_1.3.27.tar.gz' saved [2306052/2306052]
Scompattazione del tarball
[root@socrate al]# tar -zxvf apache_1.3.27.tar.gz
apache_1.3.27/
apache_1.3.27/cgi-bin/
apache_1.3.27/cgi-bin/printenv
apache_1.3.27/cgi-bin/test-cgi
apache_1.3.27/ABOUT_APACHE
apache_1.3.27/Announcement
apache_1.3.27/INSTALL
apache_1.3.27/LICENSE
apache_1.3.27/Makefile.tmpl
apache_1.3.27/README
[...]
apache_1.3.27/src/Configuration
Si entra nella directory appena scompattata. Allo stesso livello si ha la directory apache_1.3.26 con i sorgenti della versione precedente
[root@socrate al]# cd apache_1.3.27/
Si esegue lo script config.status in apache_1.3.26 che contiene il ./configure con i parametri utilizzati nell'ultima compilazione. Ovviamente la compilazione la si fa sui sorgenti della versione 1.3.27 (trovandosi nella relativa directory).
[root@socrate apache_1.3.27]# ../apache_1.3.26/config.status
Configuring for Apache, Version 1.3.27
+ using installation path layout: Apache (config.layout)
Creating Makefile
Creating Configuration.apaci in src
Creating Makefile in src
+ configured for Linux platform
+ setting C compiler to gcc
+ setting C pre-processor to gcc -E
+ checking for system header files
+ adding selected modules
[...]
Si compilano i sorgenti...
[root@socrate apache_1.3.27]# make
===> src
make[1]: Entering directory `/home/al/apache_1.3.27'
[...]
Si installano i binari compilati. Se si vuole evitare potenziali complicazioni di conflitti sui file, a questo punto è possibile stoppare il server web. In questo caso non lo si è fatto e non si sono avuti problemi.
[root@socrate apache_1.3.27]# make install
make[1]: Entering directory `/home/al/apache_1.3.27'
===> [mktree: Creating Apache installation tree]
./src/helpers/mkdir.sh /usr/local/apache/bin
[...]
Si riavvia il server Web. Il file di configurazione non è stato cambiato e tutto torna a funzionare correttamente
[root@socrate apache_1.3.27]# /usr/local/apache/bin/apachectl restart
/usr/local/apache/bin/apachectl restart: httpd restarted
Per scrupolo si verifica la versione corrente:
[root@socrate apache_1.3.27]# httpd -V
Server version: Apache/1.3.27 (Unix)
Server built: Nov 6 2002 09:53:02
Server's Module Magic Number: 19990320:13
Server compiled with....
-D HAVE_MMAP
[...]
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-02-03 13:31:18
Le opzioni che possono essere specificate in sede di configurazione per la compilazione di Apache sono molte e possono creare confusione.
Facciamo alcuni esempi che si adattano ai casi reali più comuni.
COMPILARE UN APACHE STATICO CON ALCUNI MODULI SELEZIONATI
Se non si vuole il supporto dinamico dei moduli e si intende creare un Apache in un unico file che contiene gran parte (ma non tutti) dei moduli si può usare:
./configure --enable-module=most
Questo compila in un unico binario quasi tutti i moduli, esclusi alcuni. Se non viene specificato si compilano solo quelli che risultano abilitati ./configure --help
.
Si può sempre selezionare singolarmente i moduli da inserire o togliere rispetto alle indicazioni di base:
./configure --enable-module=most --disable-module=mod_rewrite --disable-module=mod_auth
COMPILARE UN APACHE CON SUPPORTO DI MODULI DINAMICI
Quando si compila Apache per supportare moduli caricati dinamicamente (secondo quanto indicato in httpd.conf) è sempre il caso di compilare TUTTI i moduli e selezionare da file di configurazione quali effettivamente caricare:
./configure --enable-module=all --enable-shared=max
Notare che l'opzione --enable-module deve comunque essere presente, per permettere la compilazione dei moduli indicati.
Quando si usa --enable-shared il modulo mod_so, che gestisce i moduli dinamici viene automaticamente inserito nell'httpd core.
Principi di configurazione di Apache |
Prima analisi di httpd.conf, settaggio dei parametri base. Tool grafici per la configurazione. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-02-07 19:08:04
Tutta la configurazione di Apache può essere fatta operando con un editor di testi sul file httpd.conf
che di trova in /usr/local/apache/conf/
oppure in /etc/httpd/conf/
o dove è stato specificato in fase di compilazione (provare un locate httpd.conf
per trovarlo).
Alternativamente o in parallelo alla modifica manuale del file di configurazione si possono usare diversi strumenti di configurazione grafici, sia dedicati come Comanche o Apache Configuration di RedHat, che parte di più ampi strumenti grafici di configurazione del sistema come Linuxconf o Webmin.
Ogni riga nel file di configurazione di Apache può contenere o un # per indicare che segue un commento che non viene processato o una direttiva con cui definire le varie configurazioni.
Alcune direttive (Limit, LimitExcpet, Directory, DirectoryMatch, Files, FilesMatch, Location, LocationMatch, VirtualHost) definiscono un container, individuano cioè una directory, un dato tipo di file o, genericamente, un insieme di file per i quali si possono definire specifiche direttive.
Per esempio, per indicare che l'accesso a tutti i file nella directory /home/www/private è possibile solo da certi indirizzi si scrive:
<Directory /home/www/private> # Direttiva container Directory, con la quale si definisce una directory e tutto quello che vi è contenuto
order deny,allow # All'interno della directory definita si limita l'accesso secondo l'ordine indicato
deny from all # Viene negato l'accesso a tutti gli indirizzo
allow from 10.0.0 # Viene permesso l'accesso agli indirizzi della rete 10.0.0.0/24
</Directory> # Il container Directory viene chiuso, le direttive che seguono non si applicano più a questa directory
Le direttive si dividono in diverse categorie, a seconda di dove possono essere usate nel file di configurazione:
- Server-Level - Possono essere usate solo nella parte della configurazione che riguarda l'intero server, quindi non all'interno di container.
- Globali e locali - Possono essere usare sia a livello dell'intero server, definendo i comportamenti di default, che valgono per tutti i documenti, che all'interno di container, per gestire casi specifici e sostituire quanto definito al server-level.
- Solo locali - Possono essere usate solo all'interno di un container, in quanto non avrebbero senso nella configurazione generale.
Per impostare una configurazione di base servono alcune informazioni, che l'amministratore deve fornire:
- Nome del server (può essere il nome effettivo della macchina o un nome arbitrario), si definisce con la direttiva ServerName
- La porta a cui mettere in listening il web server. Per il protocollo http la porta di default è l'80, ma volendo se ne può definire una alternativa. Si può inoltre definire a quale IP locale appoggiarsi (nel caso si stia usando una macchina con più IP). La direttiva raccomandata è Listen
. Nella versione 1.3 di Apache vengono usate anche le direttive BindAddress
e Port
che però sono deprecate.
- L'utente e il gruppo con cui gira il processo httpd. E' meglio che siano utenti comuni non privilegiati (di solito "nobody" o "apache"). Per definirli si usano le direttive User
e Group
- La directory che contiene i file HTML che fanno parte del sito che si vuole rendere pubblico con Apache. Si definisce con la direttiva DocumentRoot
. Notare che questa è diversa dalla direttiva ServerRoot
che definisce la directory di base di Apache, partendo dalla quale il programma cerca file di configurazione, log ecc.
- Se si usa un Apache con supporto dei moduli è probabile che solo il modulo di core mod_so sia effettivamente incluso nel binario httpd, per cui per poter funzionare Apache richiede il caricamento, tramite file di configurazione, degli altri moduli. Con Apache 2.0 basta la direttiva LoadModule
, con Apache 1.3 ci vuole ANCHE la direttiva AddModule
.
- Non è obbligatorio ma è prassi comune indicare l'indirizzo e-mail dell'amministratore del sistema, che può venir visualizzato in pagine di errore o altri casi. Lo si imposta con la direttiva ServerAdmin
.
Un esempio di un file di configurazione minimale, senza caricamento di moduli, è quindi:
ServerName pippo
Listen 80
User apache
Group apache
DocumentRoot /home/httpd/html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2003-02-03 22:50:25
Il file httpd.conf è il file di configurazione principale di Apache. Ci sono veramente tante opzioni possibili da settare, ed è per questo che è importante fare spesso riferimento al manuale ufficiale, che offre una documentazione completa su Apache. Il seguente esempio di configurazione riporta una configurazione minima di Apache con commenti su ogni direttiva usata.
### Section 1: Global Environment
ServerType standalone
La direttiva ServerType specifica come Apache deve girare sul sistema. E' possibile farlo girare tramite il super daemon inetd (che invoca Apache quando riceve connessioni sulla porta 80) o come tramite server standalone, costantemente in esecuzione sul sistema. E' altamente raccomandabile questa seconda alternativa, per ridurre i tempi di latenza ed evitare i potenziali problemi che si possono avere invocando Apache da inetd.
ServerRoot "/etc/httpd"
Specifica la directory di base di Apache dove si trovano i file di configurazione e altri file importanti. Eventuali PATH di ulteriori directory, se non altrimenti specificato, sono relativi a questa directory.
PidFile /var/run/httpd.pid
Specifica dove viene scritto il PID di httpd quando si avvia. Questa opzione è richiesta solo quando Apache gira in standalone mode.
ResourceConfig /dev/null
Specifica la locazione del file srm.conf che Apache legge quando finisce di leggere il file di configurazione httpd.conf. Nelle versioni più recenti di Apache, viene tutto scritto in httpd.conf e non si usa più usare un file srm.conf separato. /dev/null, in questo caso indica che NON esiste un srm.conf separato.
AccessConfig /dev/null
L'opzione AccessConfig specifica la locazione del file access.conf, che Apache legge quando finisce di leggere il file di configurazione httpd.conf. Come sopra, impostando come argomento /dev/null non si specifica alcun file esterno per questa parte di configurazione (relativa ai permessi di accesso al web.
Timeout 300
Specifica il tempo di attesa massimo di Apache per le richieste (GET, POST, PUT). Su server a traffico normale si puo tranquillamente mantenere l'opzione di default, altrimenti può aver senso ridurla per liberare risorse più rapidamente.
KeepAlive On
L'opzione KeepAlive, se settata On, permette di usare, come da specifiche HTTP/1.1, la stessa connessione TCP per inviare più file. Per migliori performance è consigliato settarla On evitando che venga aperta una connessione TCP per ogni richiesta HTTP.
MaxKeepAliveRequests 100
Specifica il numero di richieste permesse per connessione (sempre che l'opzione KeepAlive venga settata On). Se questa opzione è settata a 0, una connessione rimane attiva e file continuano ad essere scambiati fino a quando non va in timeout.
KeepAliveTimeout 15
Specifica quanto tempo, in secondi, Apache deve attendere per una successiva richiesta prima di chiudere la connessione. Un valore di 15 secondi è molto buono (parlando sempre di performance di Apache).
MinSpareServers 16
Specifica il numero minimo di processi figli in attesa di ricevere una richiesta. Apache, fa uno spawn di nuovi figli, mano a mano che quelli esistenti vengono occupati da nuove richieste. Dal momento che l'operazione di spawning non è rapidissima, questa opzione è molto importante per quanto riquarda le performance di Apache. Per un server che deve gestire un numero medio alto di accessi, 16 è il valore piu usato.
MaxSpareServers 64
Specifica il numero massimo di processi figli in attesa di ricevere una richiesta, un valore alto permette ad Apache di rispondere più rapidamente a picchi di traffico, ma occupa maggiormente le risorse del sistema. Per un server che deve gestire un numero medio alto di accessi, 64 è il valore piu usato.
StartServers 16
Specifica il numero di processi figli che devono essere creati da Apache in start-up. Anche questo è un parametro importante per quanto riguarda le performance di Apache. Per un server che deve gestire un numero medio alto di accessi ha senso aumentare questo valore.
MaxClients 256
Specifica il numero massimo di richieste simultanee che Apache può supportare. Anche questo parametro è fondamentale per il discorso performance. Considerare che nella compilazione di default di Apache, questo parametro non può superare 256.
MaxRequestsPerChild 100000
Specifica il numero di richieste che un singolo processo figlio può gestire. Con 0 si indica un numero infinito, ma per evitare un potenziale degradamento del sistema è utile mettere un numero alto ma finito.
### Section 2: 'Main' server configuration
Port 80
Indica la porta TCP su cui Apache deve ascolare. 80 è la porta di default per un server http. Questa direttiva, insieme a BindAddress, che indica l'IP su cui ascoltare, è destinata ad essere soppiantata dalla più flessibile Listen
Listen *:80
Indica di ascoltare su tutti gli IP locali sulla porta 80. Si possono specificare anche singoli indirizzi e più righe con diversi IP e porte in Listen
User nobody
Lo user con cui Apache gira. E' importante creare un nuovo utente con i minimi permessi usati allo scopo di far girare il servizio. Notare che Apache avrà, nell'accesso al file system locale, i privilegi dell'utente qui specificato.
Group nobody
Il gruppo con cui Apache gira.
DirectoryIndex index.htm index.html index.php index.php3 default.html index.cgi
Specifica i nomi di file che Apache considera come home page. In altre parole, se viene fatta una GET che non specifica il nome di un file specifico ma solo la directory (quello che succede abitualmente, quando su un browser si indica un indirizzo tipo http://www.yahoo.com) Apache cerca, nell'ordine indicato, i file sopra citati e se non ne trova alcuni visualizza, se questo è permesso nel resto della configurazione, l'elenco dei file contenuti della directory
Include conf/virtual-domains.conf
Specifica la posizione di altri files che si possono includere insieme al file di configurazione httpd.conf. In questo caso è stato incluso il file virtual-domains.conf, contenuto nella directory /etc/httpd/conf.
HostnameLookups Off
Questa opzione, se settata off, specifica di disabilitare il DNS reverse lookup degli IP dei client in fase di logging. Per evitare tempi di latenza eccessivi, è consigliabile lasciare Off la risoluzione degli IP, che potrà essere fatta successivamente e autonomamente da strumenti di analisi dei log.
ServerAdmin [email protected]
L'indirizzo email di chi amministra il server. Può essere indicato in alcune pagine di errore
ServerName www.domain.com
Il nome del server web
DocumentRoot "/home/httpd/folder"
La directory dove sono contenuti i file html che costituiscono il sito offerto dal server
<Directory "/home/httpd/folder">
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>
Si definisce un container Directory, al cui interno si impostano delle direttive limitate agli oggetti ivi contenuti
<Files .pl>
Options None
AllowOverride None
Order deny,allow
Deny from all
</Files>
Altro esempio di container. Qui si impedisce la lettura di tutti i file .pl
<IfModule mod_mime.c>
TypesConfig /etc/httpd/conf/mime.types
</IfModule>
Indica di caricare il file specificato con l'elenco dei MIME file type, se è presente il modulo mod_mime, in grado di gestirli.
DefaultType text/plain
Indica con quale MIME type il server web fornisce i suoi file
ErrorLog /var/log/httpd/error_log
LogLevel warn
La posizione del file di log per quanto riguarda gli errori, e il livello di debugging
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
CustomLog /var/log/httpd/access_log combined
Si definisce il formato di un file di log (per quanto riguarda le richieste HTTP), lo si chiama "combined" e, con la direttiva CustomLog si definisce dove scriverlo.
<IfModule mod_alias.c>
ScriptAlias /cgi-bin/ "/home/httpd/cgi-bin/"
<Directory "/home/httpd/cgi-bin">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>
</IfModule>
Se è presente il modulo mod_alias si definisce un alias per una directory che contiene script CGI e si impostano direttive specifiche per quella directory
ErrorDocument 500 "The server made a boo boo.
ErrorDocument 404 http://192.168.1.1/error.htm
ErrorDocument 403 "Access Forbidden -- Go away.
Definisce come reagire in caso di errore, a seconda del codice di errore. Si può visualizzare una scritta, aprire un file html locale o puntare ad un URL remoto
<IfModule mod_setenvif.c>
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
BrowserMatch "RealPlayer 4\.0" force-response-1.0
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0
</IfModule>
Se è presente il modulo mod_setenvif, si impostano specifici header di risposta per richieste effettuati da specifici Browser
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-06-23 21:01:48
Attualmente il gruppo di sviluppo di Apache mantiene due tree differenti del progetto HTTP server:
- Apache1.3: La release più vecchia, anagraficamente e concezionalmente parlando ma inevitabilmente più testata rispetto alla nuova release.
- Apache2.0: Il nuovo tree comprendente nuove features e nuova logica nella gestione delle richieste http e della configurazione del servizio.
Di seguito sono riportate le principali features della nuova release:
Configurazione
Sono state apportate alcune modifiche a livello di file di configurazione e delle direttive da utilizzare per semplificare parti come il caricamento dei moduli e il binding di indirizzi ip e porte.
Inoltre vengono utilizzate di default direttive come ServerTokens per modificare i vari header contenenti informazioni sul server e la direttiva Include per gestire il servizio con più file di configurazione.
E' garantita la compatibilità della vecchia versione, di cui mantiene gran parte delle direttive.
Miglior supporto per piattorme non Unix e supporto unicode nativo di WIN NT
Molta attenzione è stata destinata nel migliorare le stabilità e le performance in sistemi non unix come BeOS, OS/2 e Windows ove si è utilizzato anche utf-8 per l'encoding per i file name. Tale soluzione funziona solo con sistemi basati su tecnologia NT (Win NT, 2000 e XP) poichè gli altri sistemi operativi come win 98, ME utilizzano le codepage locali.
RegEx
Apache 2 supporta le regular expression in formato perl5 grazie al nuovo motore PCRE conforme allo standard POSIX.2
Gestione del Multilanguage
Attulamente si ha la possibilità di gestire risorse web multilanguage tramite le preferenze dell'utente (ovvero tramite i vari header inviati dal client contenente i settaggi del browser) oltre che per la scelta del set dei caratteri.
Questa localizzazione del contenuto è stata introdotto anche per la gestione degli errori.
Nuovi Moduli
Alcuni moduli come il modulo proxy sono stati riscritti ed altri aggiunti nel pool di moduli che vengono installati di default come mod_dav per gestire il protocollo webdav.
Inoltre la nuova API permette di unire le funzionalità di più moduli e quidi di utilizzare moduli come se fossero dei filtri per la gestione delle risorse web.
Thread
La struttura di Apache 1.3 prevedeva che le rischieste http venissero gestite da un pool di processi che aumentavano o dimuniavano a seconda del carico.
Con Apache2 le richieste http possono essere gestire dai thread, assimilabili come dei canali all'interno di un processo, questo in termini di performance e gestione delle richieste risulta essere un passo avanti.
La gestione dei fork dei processi e dei thread viene gestito dai moduli MPM (Multi Process Modules).
MPM
Ecco i moduli MPM base disponibili per linux e sono attivabili con la compilazione dei sorgenti:
- Prefork
Metodo utilizzato anche nella vecchia release (Apache1.3) di fatto i thread sono disabilitati.
Quando apache viene attivato un pool di processi (definiti tramite la direttiva StartServer) vengono inizializzati e tale pool di processi crescerà a seconda del carico che dovranno gestire, il numero minimo e massimo dei processi vengono settati tramite la direttive: MinSpareServers e MaxSpareServers.
- Worker
Soluzione ibrida implementa sia la funzionalità dei multiprocessi che dei multithread.
Ovvero viene generato un pool di processi di cui ogni singolo processo a sua volta genera un numero fisso di thread, l'adeguamento al carico avviene con la creazione di nuovi processi.
- Perchild
All'avvio del servizio vengono generati un numero fisso di processi i quali generano un numero variabili di thread a seconda del carico. Il vantaggio nell'adottare questa soluzione, rispetto a quella denominata Worker, risiede nel fatto che ogni processo figlio gli si può assegnare un UID e privilegi diversi e vincolare tale processo ad un singolo virtualhost.
Ipoteticamente parlando sarà possibile creare e dedicare dei processi a un virtualhost specifico, con owner e permessi sulle directory differenti.
La soluzione più idonea per un server pubblico che deve offrire un servizio h24 rimane ancora la prefork, per motivi di affidabilità e nel caso in cui si voglia installare nuovi moduli MPM occorrerà patchare e ricompilare i sorgenti.
Inoltre bisogna tenere in considerazione della possibilità che dei moduli sviluppati da terze parti (ovvero da gruppi esterni ad Apache) possono essere incongruenti con la nuova struttura API di apache 2.0 .
LINK: Features apache 2 - http://httpd.apache.org/docs-2.0/new_features_2_0.html
LINK: Upgrading da apache 2 a 1.3 - http://httpd.apache.org/docs-2.0/upgrading.html
Gestione del servizio httpd |
Avvio, chiusura, verifica del servizio, opzioni di invocazione. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2003-02-03 17:47:31
Su Unix, Apache gira generalmente come demone in esecuzione continua in background ("Standalone") gestendo le richieste dei client. E' anche possibile far invocare Apache dal super demone inetd modificando la voce ServerType nel file di configurazione di Apache, anche se questo è sconsigliato, soprattutto su server con traffico che non sia minimo e occasionale.
Se nel file di configurazione la listening port è la 80 (o qualsiasi altra porta sotto la 1024), è necessario avere i privilegi di root per poter avviare il servizio. Una volta che il server ha terminato una serie di operazioni preliminari come leggere il file di configurazione e aprire i file di log, esegue un numero configurabile di processi figli che si mettono in attesa di richieste.
Il processo httpd padre continua a girare con user root, ma i processi figlio, che gestiscono le richieste dei client, possono tranquillamente girare con user con privilegi inferiori.
AVVIO LANCIANDO DIRETTAMENTE HTTPD
La posizione del file di configurazione httpd.conf è settata quando httpd viene compilato, ma è possibile specificare una locazione alternativa per avviare Apache usando un altro file di configurazione con l'opzione. Per esempio:
[root@eberk diego}# /usr/local/apache/bin/httpd -f /home/diego/test_httpd.conf
Cosi facendo il server partirà con la configurazione contenuta in /home/diego/test_httpd.conf anziché quella originale presente in /etc/httpd/conf/httpd.conf
(Posizione preimpostata in molte distribuzioni Linux) o /usr/local/apache/conf/httpd.conf
(Posizione di default in un Apache compilato direttamente dai sorgenti).
AVVIO TRAMITE APACHECTL
Un'alternativa all'esecuzione diretta del binario httpd è lo script apachectl, che viene usato per controllare il demone httpd lanciando semplici comandi come apachectl start
e apachectl stop
.
Apachectl può essere usato anche per altre operazioni come verificare la correttezza del file di configurazione ed può essere utilizzato su ogni dialetto Unix, in quanto comando distribuito direttamente con i sorgenti di Apache.
AVVIO TRAMITE /ETC/INIT.D/HTTPD START
Su molti sistemi Unix e in tutte le distribuzioni Linux con Apache installato tramite relativo package, inoltre, si trova lo script init di gestione: /etc/rc.d/init.d/httpd start
(in alcuni casi basta anche/tec/init.d/httpd start
avvia il servizio.
Se durante lo startup tutto va bene, il prompt dei comandi tornerà ad essere utilizzabile. Questo significa che il server è su e che sta girando correttamente. Un test sicuro è utilizzare un browser, connettersi al server (http://indirizzo_server:80) e vedere se compare il contenuto della Document root.
Se Apache da errore in fase di start-up, si può visualizzarne la causa in console o nel file specificato nella direttiva ErrorLog di httpd.conf.
Uno degli errori più frequenti è "Unable to blind to port xxxx".
Questo errore puo essere causato da:
- Tentato start con listening ad una porta sotto la 1024 senza essere root.
- Tentato start con listening ad una porta gia utilizzata da un altra istanza di Apache o di un qualsiasi altro server.
Un altro errore comune è un "Syntax Error on line xxx" che indica la riga nel file di configurazione che contiene una direttiva errata. I motivi possono essere:
- Errore di sintassi nella scrittura della direttiva;
- Utilizzo di una direttiva che viene fornita da un modulo non caricato.
Se si desidera startare il server in fase di boot, bisogna aggiungere la "chiamata" ad httpd o ad apachectl nei file di startup del sistema (solitamente /etc/rc.d/rc.local
o nella struttura di init con un symlink tipo /etc/rc.d/rc.3/S70httpd
che punta a /etc/rc.d/init.d/httpd
).
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2003-02-03 17:51:54
Se si controllano i processi in esecuzione sul proprio server web, si potranno vedere svariati processi httpd che stanno girando, tutti con PPID coincidente con il PID del processo httpd padre, l'unico che dovrebbe girare come utente root.
Ogni operazione di controllo del server web, gestita tramite l'invio di segnali, va quindi fatta sul PID del processo httpd padre.
Se per esempio si vuole fermare il servizio si può scrivere:
[root@eberk diego]# kill -TERM `cat /usr/local/apache/logs/httpd.pid`
Qui 'cat /usr/local/apache/logs/httpd.pid' indica semplicemente il PID del processo, che viene generalmente scritto in un file chiamato httpd.pid, il cui path completo può cambiare a seconda di come si è impostata l'opzione --runtimedir in fase di compilazione.
E' possibile verificare il progresso delle nostre operazioni analizzando i file di log, per esempio con:
[root@eberk diego]# tail -f /usr/local/apache/logs/error_log
Notare che i path dei file di pid e di log indicati possono variare anche tramite httpd.conf, per impostare le loro posizioni si usano le direttive PidFile
e ErrorLog
nel file di configurazione.
Ci sono 3 tipi di segnali che sono comunemente usati: TERM, HUP e USR1.
Segnale TERM: stop
Mandando il segnale TERM al processo padre, si causa l'immediato kill di tutti i processi figlio e il processo padre termina. Tutte le richieste http in gestione terminano immediatamente, e fino a quando il server non viene restartato nessuna richiesta verrà accolta. Il delay tra quando si lancia il comando e l'effettivo stop del server è di qualche secondo (in funzione di quanti sono i processi figlo).
Segnale HUP: restart
Mandando il segnale HUP al processo padre, si causa l'immediato kill di tutti i processi figlio, ma non del processo padre. Il processo padre rilegge il file di configurazione e riapre i file di log. Una volta fatto ciò ricrea i processi figlio che continueranno ad accogliere richieste.
Segnale USR1: graceful restart
Nota: Nelle versioni precedenti alla 1.2b9, questo segnale è leggermente instabile, e si consiglia di non usarlo.
Lanciando questo segnale, il processo padre dirà ai processi figli di terminare non appena hanno finito di gestire le richieste correnti (o di stopparsi immediatamente se non ne stanno gestendo), nel frattempo rilegge il file di configurazione, riapre i file di log e rigenera nuovi figli.
Questo è il metodo migliore per modificare e ricaricare la configurazione su un server che sta gestendo del traffico, senza interrompere alcuna sessione corrente.
Tramite lo script apachectl presente con i sorgenti di Apache, è possibile gestire in modo semplice l'avvio e la chiusura del web server, oltre ad avere la possibilità di invocare altre opzioni come il controllo dello stato del servizio e la verifica della configurazione.
Provare ad eseguire /usr/local/apache/bin/apachectl
(o in un PATH diverso da quello di default, dopo averlo cercato con un locate apachectl
) senza argomenti per visualizzare le opzioni disponibili.
Tipo Infobox: BOFH - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2003-02-03 17:56:31
Richiama le direttive IfDefine.
Dalla versione 1.3.1, Apache supporta le direttive <IfDefine>, che permettono di definire parti di configurazione.
L'opzione -D permette ad Apache di avviarsi utilizzando diversi set di configurazioni utilizzando un unico file di configurazione.
Per esempio:
[root@eberk diego]# /usr/local/apache/bin/httpd -D no_network
Puo essere usato se httpd.conf contiene nella configurazione una direttiva tipo:
<IfDefine no_network>
Listen 127.0.0.1
<IfDefine>
Questo sostituirà l'opzione di default Listen *, negando ad Apache la possibilità di rispondere alle richieste provenienti dalla rete.
Questa feature è utilizzabile per svariati impieghi, tipo attivare o disattivare moduli, abilitare o disabilitare autorizzazioni, cambiare rapidamente parametri come la DocumentRoot o il DefaultIndex.
Tipo Infobox: BOFH - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2002-11-20 12:30:22
Ridefinisce la ServerRoot
Con questa opzione, è possibile modificare la server root di Apache, ossia la directory di base che contiene file di configurazione, log files, documenti html ecc.
Deve essere specificato un path assoluto, per esempio:
[root@eberk diego]# /usr/local/apache/bin/httpd -d /home/diego/Apache_test
Cosi facendo Apache non utilizzerà la ServerRoot specificata in httpd.conf ma userà quella sopra specificata.
Tipo Infobox: BOFH - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2005-06-11 18:02:17
Specifica il file di configurazione da usare.
L'opzione -f specifica ad Apache di avviarsi utilizzando il file di configurazione specificato invece di quello di default.
Se si specifica un path relativo (cioè che non inizia con '/'), il path farà riferimento alla ServerRoot, per esempio
[root@eberk diego]# /usr/local/apache/bin/httpd -f conf/Apache_test.conf
utilizzerà il file di configurazione contenuto in /[ServerRoot]/conf/Apache_test.conf.
Se il file di configurazione non è contenuto nella ServerRoot è necessario specificare un path assoluto, per esempio:
[root@eberk diego]# /usr/local/apache/bin/httpd -f /home/diego/mytest/Apache_test.conf
Tipo Infobox: BOFH - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2003-02-03 17:55:24
Testa il file di configurazione.
Con questa opzione Apache testa il file di configurazione senza avviarsi realmente.
Vengono visualizzati a schermo gli eventuali errori trovati. Per esempio
[root@eberk diego]# /usr/local/apache/bin/httpd -t
Syntax error on line 34 of /etc/httpd/conf/httpd.conf
Invalid command 'BogusDirective", perhaps misspelled or defined by a module not included in the server configuration
Se il file di configurazione non ha errori Apache scriverà:
[root@eberk diego]# /usr/local/apache/bin/httpd -t
Syntax OK
Può essere usato anche da scripts per testare la funzionalità di Apache prima di avviarsi, in quanto httpd -t ritorna un valore 0 se la sintassi è corretta, e non 0 se c'è qualcosa che non va.
Tipo Infobox: BOFH - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-11-20 14:38:39
Visualizza informazioni sui parametri usati in fase di configurazione.
Questa opzione è utile per capire come è stato compilato Apache e visualizzare alcuni parametri fondamentali come la posizione standard del file di configurazione, di log, del pid ecc.
Visualizza inoltre la versione e la data di compilazione e i parametri che sono stati passati al ./configure
in fase di compilazione. Es:
[root@95 al]# httpd -V
Server version: Apache/1.3.26 (Unix)
Server built: Aug 26 2002 14:15:55
Server's Module Magic Number: 19990320:13
Server compiled with....
-D HAVE_MMAP
-D HAVE_SHMGET
-D USE_SHMGET_SCOREBOARD
-D USE_MMAP_FILES
-D HAVE_FCNTL_SERIALIZED_ACCEPT
-D HAVE_SYSVSEM_SERIALIZED_ACCEPT
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D HTTPD_ROOT="/usr"
-D SUEXEC_BIN="/usr/sbin/suexec"
-D DEFAULT_PIDLOG="/var/run/httpd.pid"
-D DEFAULT_SCOREBOARD="/var/run/httpd.scoreboard"
-D DEFAULT_LOCKFILE="/var/run/httpd.lock"
-D DEFAULT_ERRORLOG="/var/log/httpd/error_log"
-D TYPES_CONFIG_FILE="/etc/httpd/conf/mime.types"
-D SERVER_CONFIG_FILE="/etc/httpd/conf/httpd.conf"
-D ACCESS_CONFIG_FILE="/etc/httpd/conf/access.conf"
-D RESOURCE_CONFIG_FILE="/etc/httpd/conf/srm.conf"
Manuali, libri, risorse online su Apache |
Documentazione e risorse su Apache. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-11-04 22:01:38
Come prevedibile la quantità di informazioni online su Apache è notevole e sufficiente a soddisfare la sete di conoscenza anche dei più insaziabili.
Il punto di riferimento principale è ovviamente la documentazione ufficiale, direttamente reperibile sul sito di Apache.
http://httpd.apache.org/docs/ - La documentazione ufficiale di Apache 1.3
http://httpd.apache.org/docs-2.0/ - La documentazione ufficiale di Apache 2.0
Ulteriore documentazione si può trovare su altri siti:
http://www.refcards.com/about/apache.html Apache RefCard. Una comoda reference essenziale e pratica.
http://www.onlamp.com/apache/ ONLAMP. La sezione su Apache di O'Reilly Network.
Esistono numerosi siti di informazione, news e discussione su Apache. Fra questi:
http://www.apacheweek.com/ - Apache Week. Una popolare newsletter, un sito, molte news.
http://apachetoday.com - Apache Today. News e reviews.
Fra i siti che parlano di progetti collaterali ad Apache indichiamo:
http://www.apache-tools.com/ Apache Tools. Un completo elenco di moduli, programmi e strumenti di configurazione, benchmark ecc.
http://www.apachetoolbox.com/ Apache Toolbox. Uno script che automatizza e semplifica la compilazione di Apache con svariati moduli.
Fra i forum e le community segnaliamo:
http://www.faqts.com/knowledge_base/index.phtml/fid/56/ FAQTs: Apache. Domande e risposte su Apache.
http://slashdot.org/index.pl?section=apache La sezione di Slashdot interamente dedicata ad Apache. Discussioni e approfondimenti della enorme community di Slashdot.
http://www.tek-tips.com/gthreadminder.cfm/lev2/3/lev3/22/pid/65 Affollato Apache forum su Tek Tips.
LINK: Apache Documentation Project - http://httpd.apache.org/docs-project/
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-02-18 13:21:58
Vari siti in lingua italiana parlano più o meno estesamente di Apache.
Vediamo alcuni dei più interessanti:
http://www.apache3000.net/ - APACHE 3000, un sito interamente dedicato ad Apache ed applicazioni web.
http://www.html.it/apache/ - HTML.it presenta un tutorial ben sviluppato oltre ad una serie di FAQ.
http://www.pluto.linux.it/journal/pj0201/apache1.html - Su Pluto un tutorial ben scritto.
http://www.na.infn.it/compreso/apache/apache.pdf - Un PDF che, tra l'altro, spiega come chrootare Apache.
http://www.phpcenter.it/course/index.php?id=16 - Su PHPCenter c'è un breve ma utile corso sull'installazione di MySQL+PHP+Apache, combinazione tipica in molti siti.
http://www.latoserver.it/apache/ - LatoServer presenta una sezione dedicata ad Apache con alcuni docs.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-02-03 23:44:40
La quantità di libri in inglese ed italiano su Apache è tutt'altro che trascurabile e, pur essendo generalmente buona la qualità media di certe pubblicazioni, generalmente ne basta uno ben fatto per approfondire le proprie conoscenze su Apache.
Per questo motivo è più importante scegliere un unico buon libro che tanti diversi libri che, di fatto, alla fine parlano degli stessi argomenti.
Il solito Amazon fornisce una ampia scelta di pubblicazioni sul tema:
http://www.amazon.com/exec/obidos/search-handle-form/002-6471686-1404048 Risultato della ricerca di Apache nella categoria books.
Fra i libri letti ci sentiamo di consigliare: "Professional Apache" di Peter Wainwright, Wrox Press Ltd. ISBN 1-861003-02-1, un libro completo, approfondito, interessante e ben scritto.
Monitoring di Apache |
Server-status, server-info, uso di netstat, top, vmstat, ldd, lsof, strace. Environment variables. |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-11-05 10:56:44
Sono disponibili vari strumenti per monitorare e capire il funzionamento di Apache, il suo stato e quello che sta facendo.
Comandi Unix di Sistema
Vari comandi comuni sono utili per verificare cosa sta facendo Apache (come qualsiasi altra applicazione):
ps -adef | grep httpd
Visualizza se fra i processi in esecuzione c'è Apache (dovrebbero vedersi varie righe con httpd, una per ogni child in esecuzione, oltre al httpd padre di tutti i processi (l'unico eseguito come root).
netstat -natp
Visualizza tutte le connessioni Internet esistenti sul sistema, tra cui quelli in LISTENING sul sistema. Per ogni connessione si mostra anche il processo che la gestisce.
ldd /usr/sbin/httpd
o ldd /usr/local/apache/bin/httpd
(o ldd /path/httpd) Visualizza tutte le librerie dinamiche utilizzate da Apache. Utile per capirne le dependencies.
strace -p PID
(Dove il PID è quello di un child di Apache) Traccia le system call di un singolo processo.
strace apachectl start
Traccia le system call del processo che avvia Apache, utile per diagnosticare eventuali problemi all'avvio di Apache (verificare prima i log).
lsof | grep httpd
Visualizza tutti i file aperti da Apache. Utile per verificare, tra la'ltro, dove sono i log e quali moduli sono utilizzati.
Log di Apache
I log di Apache sono il primo posto dove cercare la soluzione di problemi (oltre che, ovviamente, analizzare il traffico Web sul sito). Di default sono in /usr/local/apache/logs
ma se si è installato Apache tramite un RPM li si potranno trovare in /var/log/httpd
o comunque dove specificato nel file di configurazione principale (verificare la direttiva ErrorLog
e definire la verbosità dei log con LogLevel
(per diagnostica mettere LogLevel debug
per il massimo della verbosità, in condizioni normali lasciare LogLevel warn
).
Server-status e Server-info
Apache fornisce due moduli che permettono all'amministratore di visualizzare informazioni utili in tempo reale.
Server-status mostra info sulle connessioni esistenti, l'uptime del server, il traffico generato, la CPU impegnata, la versione di Apache. E' possibile avere lo status sia in modalità normale che in modalità estesa, dove per ogni connessione si vedono maggiori informazioni. Di default, se abilitato, si trova su http://www.sito.com/server-status/
Server-info fornisce dettagliate informazioni sulla configurazione di Apache e sulle direttive relative ad ogni singolo modulo. Di default, se abilitato, si trova su http://www.sito.com/server-info/
Opzioni di invocazione
Anche le opzioni che possono essere passate ad Apache, eseguendo httpd
danno informazioni utili:
httpd -V
Mostra il numero di versione, e i parametri usati in fase di configurazione
httpd -l
Mostra i moduli compilati direttamente nel file httpd.
httpd -L
Mostra tutte le direttive che possono essere usate con i moduli direttamente compilati (vengono escluse tutte quelle che sono fornite dai moduli caricabili dinamicamente).
httpd -t
Esegue un test sulla configurazione di Apache e segnala eventuali errori di sintassi.
Variabili d'ambiente
Apache setta ed utilizza una serie di variabili d'ambiente che possono essere utilizzate da script CGI, PHP, Perl o trattate in sede di configurazione per gestire il comportamento del server sulla base dell'ambiente generale e delle singole connessioni. Per visualizzarle esistono vari metodi indiretti, per esempio uno è quello di utilizzare PHP all'interno di pagine HTML: <?php echo $REMOTE_ADDR ?>
visualizza l'IP del client remoto.
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-11-07 17:44:23
Apache fornisce la possibilità di monitorare in tempo reale, direttamente via web, il suo stato, l'uptime, il tempo di CPU occupato, le connessioni che sta gestendo, i processi child in esecuzione e altre informazioni utili.
Questa funzionalità è fornita dal modulo mod_status che prevede delle specifiche direttive utilizzabili con una configurazione simile:
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from .dominio.it
</Location>
Con questo esempio viene definita una Location accessibile all'url: http://www.dominio.it/server-status/ in cui vengono visualizzate informazioni varie sullo stato del server Web. In questo caso l'accesso è consentito solo da host nel dominio.it. Lasciando solo la riga SetHandler server-status
si lascia accessibile a tutto il mondo la location server-status (opzione generalmente non consigliabile, in quando vengono visualizzate informazioni utili anche a potenziali intrusori).
Se si specifica, nella configurazione la direttiva ExtendedStatus On
le informazioni fornite sono molto più dettagliate (per ogni connessione vengono indicati IP e porta del client, PID del child che la gestisce e altre info).
Su server in produzione ad alto traffico è consigliabile NON usare l'ExtendedStatus che appesantisce e rallenta il sistema.
E' possibile aggiornare automaticamente la visualizzazione dello status di un server digitando sul browser un ULR tipo:
http://openskills.info/server-status?refresh=3
(la pagina viene aggiornata ogni 3 secondi).
E' anche possibile visualizzare lo status da shell Unix, con: apachectl status
(si deve aver installato il browser testuale Lynx sul server o, se si ha solo Links avere un link simbolico di /usr/bin/lynx che punta a /usr/bin/links).
SOURCE: APACHE DOCS: Module mod_status - http://httpd.apache.org/docs/mod/mod_status.html
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-11-05 17:30:51
Apache può fornire molte informazioni sui moduli utilizzati e le direttive supportate.
Tramite il modulo mod_info è possibile abilitare la funzionalità server-info e visualizzarne le informazioni del caso in un URL tipo http://www.dominio.it/server-info
con queste righe nella configurazione generale:
<Location /server-info>
SetHandler server-info
</Location>
All'URL indicato si possono visualizzare molte informazioni utili sulla configurazione di Apache al momento in cui è stato eseguito. In particolare è interessante la possibilità di vedere quali direttive sono utilizzate nella configurazione e quali sono i moduli che le forniscono.
Anche in questo caso le informazioni visibili sono piuttosto sensibili dal punto di vista della sicurezza, per cui è fortemente consigliato limitare l'accesso all'URL server-info da IP trusted.
<Location /server-info>
SetHandler server-info
Order deny,allow
Deny from all
Allow from 192.168.5.1 192.168.5.2
</Location>
Analisi e gestione dei log httpd |
Configurazione, analisi e gestione dei log di un server Web. Software di analisi dei log. |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-11-07 10:59:28
L'attività di logging è fondamentale per ogni servizio in esecuzione su una macchina.
Su Apache oltre a fornire informazioni su eventi che riguardano il funzionamento del servizio, nei log si tiene traccia di tutte le richieste http eseguite al server web.
Il modulo mod_log_config gestisce tutte le attività di logging da Apache 1.3.5 in poi.
Generalmente su un server web si prvedono 2 diversi tipi di log:
I LOG DI ERRORE: Error_log
Contiene traccia di tutti gli errori incontrati da Apache. Di default viene scritto in /server_root/logs/error.log
ma la sua posizione può essere configurata:
ErrorLog /var/log/httpd/error_log
.
Ci può essere solo un ErrorLog nella configurazione generale, ma ne può essere definito uno per ogni VirtualHost. Non si può impedire ad Apache di loggare gli errori ma si possono evitare i tempi di scrittura su disco: ErrorLog /dev/null
.
E' possibile definire il livello di logging (in ordine di importanza: emerg - alert - crit - error - warn - notice - info - debug) con la direttiva LogLevel:
LogLevel warn
E' inoltre possibile utilizzare syslog per il logging, di default Apache usa la facility local7:
ErrorLog syslog
Ma si può definire una propria facility per gestire più facilmente /etc/syslog.conf. Con l'esempio che segue si passano al syslog i messaggi di errore utilizzando la facility apache:
ErrorLog syslog:apache
I LOG DI ACCESSO: Transfer_log
Qui vengono registrate tutte le richieste HTTP fatte al server dai client in rete. Sono fondamentali per poter analizzare il traffico su un sito Web e vengono allo scopo processati da appositi software di log analysys.
Il formato dei log di accesso può essere customizzato dall'utente ed includere i dati che interessano.
Al contrario dei log di errore, i transfer log vanno esplicitamente configurati e possono essere evitati.
L'impostazione di base del log viene fatto con la direttiva TransferLog ed è nel Common Log Format (host ident authuser date request status bytes):
TransferLog /var/log/httpd/access_log
.
Con la direttiva LogFormat si può scegliere cosa scrivere nel file di log e si definisce il nome del tipo di log, che può poi venir utilizzata con la direttiva CustomLog (nel caso che segue il nome del formato è common).
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common
SOURCE: APACHE DOCS: Log files - http://httpd.apache.org/docs/logs.html
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-11-07 14:41:33
Apache permette di scrivere nei propri log di accesso una serie di informazioni relative ad ogni richiesta fatta via HTTP.
Con la direttiva LogFormat si assegna un nickname al log e si decide il formato dei dati che deve contenere.
La sintassi di base si riferisce al log di default, utilizzato dalla direttiva TransferLog:
LogFormat formato
E' comunque possibile definire un nickname associato al formato impostato, che può essere utilizzato con la direttiva CustomLog:
LogFormat formato nickname
I dati che possono essere scritti nel log sono vari e vengono identificati con lettere o stringhe precedute dal simbolo %:
%b - Le dimensioni in byte del file trasferito (coincide con l'header Content-Lenght)
%f - Il nome del file e il path completo del documento richiesto
%h - L'hostname o, se non viene risolto, l'indirizzo IP del client
%a - L'indirizzo IP del client. E' uguale a %h se l'hostname non viene risolto
%A - L'indirizzo IP del server.
%l - Il nome dell'utente remoto, se fornito da un identd lookup (Poco utile e inaffidabile)
%p - La porta TCP del server, a cui è arrivata la richiesta del client (di solito 80)
%P - Il PID del child di Apache che ha gestito la richiesta
%r - La prima righa della richiesta HTTP,che contiene il metodo usato (GET, POST...)
%s - Lo status code HTTP della risposta
%t - Date e ora della richiesta. Customizzabile con %{formato}t
%T - Il numero di secondi impiegati da Apache per processare la richiesta
%u - Il nome dell'utente eventualmente autenticato sul server
%U - L'URL richiesta dal client. Contenuta anche in %r
%v - Il canonical server name, come definito nella direttiva ServerName
%V - Il server name secondo quanto definito in UseCanonicalName
%{Variabile}e - Una variabile d'ambiente, così come definita dal server
%{Header}i - Un header http nella richiesta del client (esempi comuni: %{User-Agent}i %{Referer}i )
%{Header}o - Un header http nella risposta del server (es: %{Last-Modified}o )
%{Nota}n - Una stringa che può essere scambiata fra il core di Apache e un modulo (esempio tipico, per il mod_usertrack: %{Cookie}n )
Un esempio tipico di log custom è incluso nella configurazione standard di Apache:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
che genera un log simile:
217.148.96.21 - - [07/Nov/2002:14:27:05 +0100] "GET /gfx/morecoresisproject.jpg HTTP/1.1" 304 - "http://www.openskills.info/" "Opera/6.02 (Linux 2.4.17-GANDALF i686; U) [en]"
Una variazione sul tema, che cerca di raccogliere il maggior numero di informazioni sui visitatori (ma di fatto difficilmente fornisce più informazioni di un combined log) può essere:
LogFormat "%h %t \"%r\" %l %u \"%{Referer}i\" \"%{User-Agent}i\" \"%{From}i\"" user
SOURCE: APACHE DOCS: Module mod_log_config - http://httpd.apache.org/docs/mod/mod_log_config.html
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-11-08 12:22:56
Una volta attivato, il trasfer loggin di Apache scrive una riga di log per ogni oggetto richiesto dai client. In siti con molto traffico o molte immagini può essere utile evitare di scrivere innumerevoli righe di log per tutte le immagini richieste e limitare il logging alle pagine html o simili.
Per farlo si possono usare alcune caratteristiche evolute della direttiva che può eseguire controlli e decisioni sulla base delle variabili d'ambiente.
Queste variabili possono anche essere definite con la direttiva SetEnvIf disponibile con il modulo mod_setenvif.
Di fatto per non loggare le immagini nel proprio log si può usare una configurazione simile:
# Identifica negli URI i file .gif, .jpg e .png e li assegna alla variabile images
SetEnvIf Request_URI \.gif$ image=gif
SetEnvIf Request_URI \.jpg$ image=jpg
SetEnvIf Request_URI \.png$ image=png
# Specifica di non loggare nel CustomLog le entry che matchano le imamgini
CustomLog logs/access_log common env=!image
(F)AQ: Coma faccio a non loggare le GET alle immagini sui log di Apache? -
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-02-05 11:03:40
Il processo di ruotare i log su Apache, se fatto manualmente, richiede una certa attenzione, ma può essere automatizzato con script e tool specifici.
La procedura manuale, richiede un riavvio del server web.
Quando infatti si rinomina un file di log, Apache continua a loggare sullo stesso, almeno fino ad un riavvio del servizio.
I comandi sono di questo tenore:
mv access_log access_log.old
mv error_log error_log.old
apachectl graceful
sleep 600
gzip access_log.old error_log.old
Si può anche fare un restart più rapido e brutale (apachectl restart
) che non aspetta la chiusura delle connessioni esistenti.
Questa operazione può essere automatizzata direttamente in configurazione con filtri come Cronolog o il comando rotatelogs, distribuito con Apache (guardare la parte sui Piped Log).
Alternativamente si possono usare programmi come LogRotate che gestiscono la rotazione di ogni tipo di log.
LINK: Cronolog Home Page - http://www.cronolog.org/
Tipo Infobox: TIPS - Skill Level: 5- SENIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-11-07 19:00:01
Una interessante e flessibile funzionalità del sistema di logging di Apache è la possibilità di inviare i dati di un log (sia un error log che un transfer log) ad un programma, tramite una normale pipe, invece che scriverli direttamente su un file.
Il programma che riceve il log in standard input potrà processarli e scriverli in standard output secondo criteri assolutamente gestibili.
Va notato che il programma a cui si passano i log viene eseguito con i permessi di Apache, quindi di root, per cui bisogna prestare attenzione ai possibili rischi in termini di sicurezza.
Per questa funzione basta sostituire al nome del file la pipe e il nome del programma (o la command line) a cui inviare i log.
Alcuni esempi possono essere illuminanti sulle enormi possibilità che si aprono con questa funzione:
Compressione dei log on-the-fly:
CustomLog "|/usr/bin/gzip -c >> /var/log/access_log.gz" common
Reverse lookup sui client IP in quasi real-time, senza ritardare le risposte del server come accade con la direttiva HostNameLookup:
CustomLog "|/usr/local/apache/bin/logresolve >> /var/log/access_log" common
Esegue la rotazione automtica dei log ogni 24 ore (86400 secondi):
CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" combined
Usando il tool cronolog si creano log mensili con nomi che contengono mese e anno:
CustomLog "|cronolog /var/log/apache/DOMAIN/%Y/%Y-%m-access.log" combined
Si invia il log ad un proprio programma filtro.sh:
CustomLog "|/usr/local/bin/filtro.sh" combined
In un caso simile filtro.sh deve poter ricevere in STDIN dei dati, gestirli e scriverli da qualche parte. Un esempio, che logga in un file a parte tutte le richieste generate da worm come Nimda è questo:
#!/bin/sh
NIMDA_LOG=/var/www/httpd/nimda_log
NORMAL_LOG=/var/www/httpd/access_log
STRING=cmd.exe
while /bin/true;
do
read loginput
if [ `echo "$loginput" | grep -c $STRING ` == 1 ]
then
echo "$loginput" >> $NIMDA_LOG &
else
echo "$loginput" >> $NORMAL_LOG &
fi
done
SOURCE: APACHE DOCS: Piped logs - http://httpd.apache.org/docs/logs.html#piped
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-02-01 10:52:22
La gestione e l'analisi dei log è un'attività sistemistica che richiede le sue attenzioni.
Su macchine ad alto traffico, o sotto attacco DOS o con particolari problemi ricorrenti, le dimensioni dei log possono crescere a dismisura in pochissimo tempo, fino a saturare il file system.
Per questo motivo è sempre consigliabile montare la directory /var
, dove generalmente risiedono i log, in una partizione indipendente, che, anche se riempita, non blocca il funzionamento del sistema.
E' inoltre importante poterli gestire, ruotandoli ad intervalli fissi e compattando i log vecchi, preparandoli per un'archiviazione.
Su molte distribuzioni Linux è incluso Logrotate, un'applicazione che semplifica l'amministrazione dei log, permette di comprimere, rimuovere ed inviare il log via mail oltre a eseguire una rotazione di file con vari criteri.
Il file di configurazione è /etc/logrotate.conf
In sistemi che usano RPM , solitamente, le regole di gestione dei singoli log sono inserite nella directory /etc/logrotate.d/
.
Generalmente gli script che eseguono logrotate sono inseriti nel crontab e di default sono configurati per gestire i log standard di sistema.
Altra applicazione che viene spesso usata per gestire, in particolare, i log di Apache è Cronolog, che rende particolarmente semplice la segmentazione di log in file diversi generati secondo unità di tempo configurabili (es: un file diverso ogni giorno). E' particolarmente utile per gestire siti ad alto traffico, in cui le dimensioni dei log tendono a crescere in modo spropositato.
Viene tipicamente usato come un filtro che riceve un log dallo standard input e lo scrive in stdout su più diversi file, secondo le specifiche indicate in un template. La sintassi di base è /path/cronolog [opzioni] template
. Per esempio:
/usr/sbin/cronolog /web/logs/%Y/%m/%d/access.log
divide il log che riceve in stdout in tanto diversi log in diverse directory secondo il criterio /web/logs/anno/mese/giorno/access.log, con risultati tipo: /web/logs/2003/01/17/access.log.
Viene tipicamente usato in httpd.conf sfruttando la funzionalità di Apache di inviare i log ad un comando esterno:
TransferLog "|/usr/sbin/cronolog /web/logs/%Y/%m-%d-access.log"
ErrorLog "|/usr/sbin/cronolog /web/logs/%Y/%m-%d-errors.log"
Crea un file di log diverso ogni giorno e li mette in directory divise per anno.
Il vantaggio di simili programmi è quello di sollevare l'amministratore dalla noiosa e insidiosa pratica di gestione e archiviazione dei log, che se non automatizzata può portare a spiacevoli conseguenze quali file system riempiti al 100%, file di log enormi, perdita di dati e simili contrattempi.
LINK: Home page di cronolog - http://www.cronolog.org/
LINK: Cronolog Home Page - http://www.cronolog.org/
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-10-18 17:07:57
Chiunque pubblica su Internet un suo sito web è interessato a sapere quanti lo visitano, cosa guardano, da dove vengono e magari perchè lo fanno.
Ogni server web logga, tiene traccia, di ogni file servito agli irrrequieti browser suoi client.
Il tipo di informazioni loggate da un server web sono, per ogni file (immagine o HTML) servito: data e ora della richiesta, IP del client remoto, client (browser) utilizzato, referrer (URL della pagina che ha il link al file richiesto), nome del file.
L'analisi dei log prodotti può essere automatizzata e analizzata per ottenere statistiche interessanti e comprensibili.
Esistono in circolazione una moltitudine di log analyzers, programmi, gratuiti o a pagamento, che analizzano i log di server Web vari e producono un output, tipicamente in HTML, che con tabelle, schemi, grafici e statistiche riassumono ed elencano innumerevoli dati sul traffico web generato da un sito.
Su Linux / Unix i più diffusi e validi programmi opensource o comunque freeware per l'analisi del traffico web sono:
WEBALIZER: http://www.webalizer.org - Veloce, diffuso, con interesanti grafici e statistiche
ANALOG: http://www.analog.cx/ - Statistiche dettagliate
AWSTATS: http://awstats.sourceforge.net/ - Ottima presentazione e grafici interessanti
Esistono moltissime alternative commerciali e anche diversi approccia all'analisi del traffico web.
I tool qui presentati analizzano i log dei server web, altri tool utilizzando delle proprie "sonde" all'interno di pagine Web, che registrano i dati sui visitatori su un server centrale, alcuni inseriscono pezzi di codice, per esempio in PHP, che logga su un database gli accessi.
Alcuni strumenti, infine, si adattano bene a grosse quantità di log anche su sistemi distribuiti, altri sono più limitati, alcuni processano senza problemi pagine dinamiche e i relativi accessi, altri lavorano bene solo su pagine statiche.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-03-14 12:08:02
Webalizer è uno tra i più diffusi software per l'analisi dei log di un web server.
E' un software Open Source, il quale permette di generare dei report statistici in diverse lingue (tra cui anche l'italiano) in formato HTML, quindi visualizzabili facilmente con qualunque browser, partendo da un log file di un Web Server.
I dati possono essere analizzati su base annuale, mensile, giornaliera ed oraria. E' possibile visualizzare diversi tipi di informazioni relative ai visistatori di un sito web quali per esempio, url, referrer, browser, search string di un motore di ricerca, paese di provenienza ecc. La presentazione dei report viene effettuata tramite la creazione di diverse pagine HTML corredate di grafici in formato png generati grazie all'ausilio delle librerie grafiche GD.
Per quanto riguarda i formati di log supportarti, Webalizer è in grado di elaborare log in formato CLF (Common Log Format) e Combined log format. Tra le caratteristiche interessanti, la possibilità, oltre ad classico utilizzo per l'analisi dei dati forniti da un Web Server, di generare report sia per FTP Server che utilizzano il formato xferlog, sia per Squid Proxy Server. Inoltre, qualora i log da analizzare fossero in formato .gz, quindi compressi tramite gzip, Webalizer è in in grado di decomprimerli momentaneamete al fine di leggerne i dati per elaborarli.
Infine tra le features di Webalizer sono presenti l'Incremental Processing e il Reverse DNS Lookups.
L'Incremental Processing, disponibile dalla versione 1.2x, permette di elaborare grossi file di log, dividendoli in file più più piccoli elaborati separatamente, permettendo quindi all'amministratore di sistema una maggiore flessibilità per quanto riguarda il rotate dei log senza perdere nessun dettaglio in merito alle statistiche generate. Il Reverse DNS Lookups, disabilitato di default, permette invece a Webalizer di recuperare il nome host associato ad un indirizzo IP presente in un file di log.
LINK: Home Page Webalizer - http://www.webalizer.org/
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2003-10-26 13:11:47
Installazione di Webalizer tramite RPM e compilazione dei sorgenti.
INSTALLAZIONE TRAMITE RPM
L'Installazione via RPM avviene in soli due passi: Download ed installazione. E' possibile fare il download del software da un repository quale per esempio http://www.rpmfind.net:
[root@Enigma Software]# wget --passive-ftp ftp://fr.rpmfind.net/linux/redhat/9/en/os/i386/RedHat/RPMS/webalizer-2.01_10-11.i386.rpm
--16:09:42-- ftp://fr.rpmfind.net/linux/redhat/9/en/os/i386/RedHat/RPMS/webalizer-2.01_10-11.i386.rpm
=> `webalizer-2.01_10-11.i386.rpm'
Resolving fr.rpmfind.net... done.Connecting to fr.rpmfind.net[194.199.20.114]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /linux/redhat/9/en/os/i386/RedHat/RPMS ... done.
==> PASV ... done. ==> RETR webalizer-2.01_10-11.i386.rpm ...done.
Length: 101,903 (unauthoritative)
100%[=================================================================================>] 101,903 4.67K/s ETA 00:00
16:10:06 (4.67 KB/s) - `webalizer-2.01_10-11.i386.rpm' saved [101903]
Successivamente si passa all'installazione:
[root@Enigma Software]# rpm -ivh webalizer-2.01_10-11.i386.rpm
Preparing... ########################################### [100%]
1:webalizer ########################################### [100%]
INSTALLAZIONE TRAMITE COMPILAZIONE DEI SORGENTI
Dal sito ufficiale è possibile procedere con il download dei sorgenti:
root@Joker:/software# wget --passive-ftp ftp://ftp.mrunix.net/pub/webalizer/webalizer-2.01-10-src.tgz
--18:44:58-- ftp://ftp.mrunix.net/pub/webalizer/webalizer-2.01-10-src.tgz
=> `webalizer-2.01-10-src.tgz'
Resolving ftp.mrunix.net... done.
Connecting to ftp.mrunix.net[209.114.200.24]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /pub/webalizer ... done.
==> PASV ... done. ==> RETR webalizer-2.01-10-src.tgz ... done.
Length: 418,680 (unauthoritative)
100%[==================================================================================>] 418,680 4.45K/s ETA 00:00
18:46:50 (4.45 KB/s) - `webalizer-2.01-10-src.tgz' saved [418680]
SCOMPATTAZIONE
Si prosegue poi con la scompattazione dei sorgenti:
root@Joker:/software# tar -zxvf webalizer-2.01-10-src.tgz
webalizer-2.01-10/
webalizer-2.01-10/aclocal.m4
webalizer-2.01-10/CHANGES
webalizer-2.01-10/webalizer_lang.h
webalizer-2.01-10/configure
webalizer-2.01-10/configure.in
[...]
webalizer-2.01-10/sample.conf
webalizer-2.01-10/webalizer.1
webalizer-2.01-10/webalizer.c
webalizer-2.01-10/webalizer.h
webalizer-2.01-10/webalizer.LSM
webalizer-2.01-10/webalizer.png
root@Joker:/software#
CONFIGURAZIONE
La scompattazione crea la directory Webalizer seguita dalla versione del programma, all'interno della quale è necessario spostarsi per avviare le operazioni di configurazione, compilazione ed installazione:
root@Joker:/software# cd webalizer-2.01-10
root@Joker:/software/webalizer-2.01-10# ./configure --help
Usage: configure [options] [host]
Options: [defaults in brackets after descriptions]
Configuration:
--cache-file=FILE cache test results in FILE
--help print this message
--no-create do not create output files
[...]
--enable-dns Enable DNS lookup code
--with-language=language Use 'language' (default is english)
Tra le varie opzioni di configurazione visualizzabili con il comando ./configure --help, interessanti sono --enable-dns che permette di abilitare la possibilità di eseguire query inverse sul DNS e --with-language che permette di generare report scegliendo tra le numerose lingue supportate
Una volta scelte le opzioni si procede con la creazione del makefile:
root@Joker:/software/webalizer-2.01-10# ./configure --with-language=italian
In questo caso l'installazione viene effettuata specificando di volere i report in italiano
loading cache ./config.cache
checking for gcc... (cached) gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
[...]
creating Makefile
linking ./lang/webalizer_lang.italian to webalizer_lang.h
root@Joker:/software/webalizer-2.01-10#
Durante la creazione del makefile è necessario che siano individuate le librerie grafiche gd. Qualora siano presenti nel sistema, ma non trovate durante la configurazione, è possibile specificarne il percorso tramite l'apposito flag --with-gdlib=<path-to-gd-library>
.
COMPILAZIONE
Effettuata la configurazione, è possibile compilare il codice:
root@Joker:/software/webalizer-2.01-10# make
gcc -Wall -O2 -DETCDIR=\"/etc\" -DHAVE_GETOPT_H=1 -DHAVE_MATH_H=1 -c webalizer.c
gcc -Wall -O2 -DETCDIR=\"/etc\" -DHAVE_GETOPT_H=1 -DHAVE_MATH_H=1 -c hashtab.c
gcc -Wall -O2 -DETCDIR=\"/etc\" -DHAVE_GETOPT_H=1 -DHAVE_MATH_H=1 -c linklist.c
...
gcc -Wall -O2 -DETCDIR=\"/etc\" -DHAVE_GETOPT_H=1 -DHAVE_MATH_H=1 -c output.c
gcc -Wall -O2 -DETCDIR=\"/etc\" -DHAVE_GETOPT_H=1 -DHAVE_MATH_H=1 -I/usr/local/include -c graphs.c
gcc -o webalizer webalizer.o hashtab.o linklist.o preserve.o parser.o output.o dns_resolv.o graphs.o -lgd -lpng -lz -lm
rm -f webazolver
ln -s webalizer webazolver
root@Joker:/software/webalizer-2.01-10#
INSTALLAZIONE
Terminata correttamente la compilazione, è possibile installare il software:
root@Joker:/software/webalizer-2.01-10# make install
/usr/bin/ginstall -c webalizer /usr/local/bin/webalizer
/usr/bin/ginstall -c -m 644 webalizer.1 /usr/local/man/man1/webalizer.1
/usr/bin/ginstall -c -m 644 sample.conf /etc/webalizer.conf.sample
rm -f /usr/local/bin/webazolver
ln -s /usr/local/bin/webalizer /usr/local/bin/webazolver
root@Joker:/software/webalizer-2.01-10#
Elementi base della configurazione di Apache |
Le direttive per la gestione della configurazione: IfModule, IfDefine, Include, Options e Overrides. |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-02-07 19:38:41
Apache prevede una serie di direttive chiamate container, che identificano un certo gruppo di risorse (file, directory ecc.) relativamente alle quali vengono attivate determinate direttive di configurazione.
Un container si definisce tale perchè, a differenza della maggior parte delle direttive di configurazione di Apache, e similmente ai tag HTML, ha una riga di apertura, che definisce l'ambito di applicazione e una di chiusura. All'interno di queste si possono inserire delle configurazioni che sono valide solo per l'ambito specificato.
Con l'esempio che segue si limita l'accesso alla directory /home/www/private solo agli indirizzi della rete 10.0.0.0/24:
<Directory /home/www/private>
Order deny,allow
Deny from all
Allow from 10.0.0
</Directory>
Sono previste le seguenti direttive container, che possono essere, in alcuni casi, anche incluse una dentro l'altra:
Directory - Definisce una directory (e tutte le sue sottodirectory), relativa al file system locale, per la quale si applicano le direttive specificate.
DirectoryMatch - Definisce una directory esprimibile anche con regular expressions. Per esempio DirectoryMatch "/home/(a|A)*"
definisce ogni directory in /home che inizia con a o A.
Files - Come Directory, ma si riferisce a uno o più file. Può inglobare wildcard (Files *.jpg
)
FilesMatch - Come DirectoryMatch può definire insiemi di file tramite regular expressions moderatamente complesse
Location - Come Directory, ma invece di applicarsi al PATH completo nel file system, si applica a degli URL, relativi all'indirizzo Web di un sito. Si usa tipicamente con directory virtuali generare dinamicamente da Apache come Location /server-info
LocationMatch - Come DirectoryMatch, permette di definire regular expression per identificare delle Location relative al server web
VirtualHost - Fondamentale per la gestione di domini virtuali, di fatto può prevedere molte direttive, anche a server-level, per gestire più siti indipendenti (DocumentRoot, path dei log, email dell'amministratore ecc.)
Limit - Si riferisce a determinati metodi http, tipicamente usato per gestire accessi a determinate risorse con criteri diversi. Quasi sempre viene incluso all'interno di altri container. (es: Limit PUT POST
)
LimitExcept - Come Limit, ma funziona com un NOT logico. Per esempio LimitExcept GET
indica tutti i metodi http tranne GET.
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-02-07 19:38:18
Apache prevede direttive per gestire in modo dinamico la configurazione e attivarne blocchi interi se sono riscontrate determinate condizioni:
IfModule viene usata come una direttiva container (anche se non è propriamente un container): tutte le righe di configurazione che stanno al suo interno vengono processate se il modulo specificato è caricato in memoria. Per esempio:
<IfModule mod_dir.c>
DirectoryIndex index.html
</IfModule>
attiva la direttiva DirectoryIndex index.html
solo se il modulo che la gestisce (mod_dir) è attivo.
Il vantaggio di una configurazione simile è che si può rimuovere il caricamento del modulo in questione senza dover modificare altre parti del file di configurazione (se non ci fosse IfModule, Apache, in mancanza di mod_dir non riuscirebbe a partire e darebbe un messaggio di errore per una direttiva, DirectoryIndex, sconosciuta).
IfModule è ampiamente utilizzata nelle configurazioni standard di Apache.
IfDefine ha sintassi simile a quella di IfModule e viene utilizzata per definire pezzi di configurazione che possono essere caricati se Apache viene avviato usando il flag -D Definizione. Per esempio:
<IfDefine Debugga>
<Location /server-info>
SetHandler server-info
</Location>
<Location /server-status>
SetHandler server-status
</Location>
ExtendedStatus On
LogLevel debug
</IfDefine>
In questo modo, se si lancia Apache con httpd -D Debugga
verranno attivate una serie di direttive che facilitano le operazioni di troubleshooting e debugging.
Tipicamente la direttiva IfDefine e l'invocazione di Apache tramite httpd -D sono usate in casi particolari per prove, test e verifiche di parti di configurazione, considerando anche che un kill -HUP
o un apachectl restart
riavviano Apache in modalità normale, senza l'inclusione delle direttive specificate all'interno della direttiva IfDefine.
Oltre a queste direttive che gestiscono il caricamento di parte di configurazioni secondo la presenza di un dato modulo o la definizione invocata con l'opzione -D, esiste la possibilità di includere nella conf principale, altri file di configurazione esterni.
La direttiva Include permette di aggiungere file singoli, file definiti con una wildcard o il contenuto di intere directory, alla configurazione principale. Esempi:
Include conf/virtual-domains.conf
aggiunge, dal punto in cui si trova, il contenuto del file virtual-domains.conf (presente nella subdirectory conf rispetto alla ServerRoot) alla configurazione di Apache;
Include /etc/httpd/conf.d/*.conf
aggiunge tutti i file che terminano con .conf presenti nella directory (assoluta) /etc/httpd/conf.d/;
Include /etc/httpd/conf.d
aggiunge tutti i file presenti nella directory /etc/httpd/conf.d.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-02-07 19:03:22
Apache ha due metodi di controllo, Options e Overrides per la gestione delle feature disponibili per una data directory.
Options: E' la direttiva che gestisce il comportamento di Apache nei confronti del filesystem. Ogni parametro modifica il comportamento in presenza di condizioni diverse come un file eseguibile, link simbolico, CGI etc.
Per esempio Options
FollowSymlinks indica che i link simbolici vengono seguiti e i file a cui puntano vengono serviti da Apache anche se non sono nella sua DocumentRoot.
Questa direttiva può risiedere sia nella configurazione generale che all'interno dei container Directory e Virtual Host
AllowOverride: Controlla quali direttive possono essere definite nel file autonomo .htaccess, che può essere presente in ogni directory e, per ogni directory, può impostare delle configurazioni specifiche che si aggiungono o sostituiscono quelle del file di configurazione generale.
E' possibile definire quali tipi di configurazioni possono essere aggiunte nei file .htaccess, per esempio AllowOverride
FileInfo Indexes limita la possibilità di override da parte di .htaccess solo per direttive che riguardano la gestione dei file type e gli indici.
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-02-05 14:06:58
E' possibile tramite la direttiva AllowOverride disabilitare la lettura del file .htaccess ed evitare la possibilità di modificare le direttive del file di configurazione principale.
Se non si ha la necessità di lasciare agli utenti che uploadano i contenuti di un sito, di modificare autonomamente il proprio file .htaccess e quindi impostare delle configurazioni specifiche per le proprie directory, è decisamente consigliato disabilitare la lettura stessa del file da parte di Apache.
Questo ha un duplice vantaggio:
- Prestazioni: Il web server non deve controllare ogni volta l'esistenza di un .htaccess per ogni directory su cui va a leggere file.
- Sicurezza: Nessun utente/webmaster può impostare autonomamente, uploadando, per esempio via FTP, un file .htaccess in grado di modificare le configurazioni di Apache (per la directory in cui si trova il file).
Per disabilitare in generale l'uso di .htaccess aggiungere a httpd.conf le seguenti righe:
<Directory />
AllowOverride None
</Directory>
E' poi sempre possibile abilitare l'override per specifiche directory, meno generali.
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-02-05 14:05:36
Apache da la possibilità di definire delle direttive specifiche per singola directory direttamente con un file di testo (di default chiamato .htaccess) presente in singole directory e quindi gestibile anche da chi non può intervenire direttamente sul file di configurazione principale.
Questa funzione è gestita con la direttiva AllowOverride
, il nome del file in cui possono essere impostate direttive che fanno un "override" della configurazione principale è definito con la direttiva:
AccessFileName
.htaccess (Il valore di default può essere modificato)
Quando Apache deve processare una richiesta, verifica se per quella directory è abilitato l'overriding e verifica se per ogni parent-directory esiste o meno il file .htacces.
Quando tutte le directory sono state verificate, Apache esegue il merge dando la precedenza a quelle opzioni abilitate nei file .htaccess trovati nei livelli più bassi.
La sintassi della funzione AllowOverride è simile a quella di Options, in totale ci sono 5 opzioni possibili oltre ad All e None
AuthConfig Permette l'utilizzo delle direttive Authname, AuthType, AuthUserFile (richiede il caricamento del modulo mod_auth)
FileInfo Permette l'uso delle direttive per il controllo dei file types come AddType, DefaultType, AddEncoding, AddLanguage, ErrorDocument etc..
Indexes Abilita le direttive per il controllo dell'output del contenuto delle directory
Limit Abilita l'uso del modulo mod_access e delle relative direttive, allow, deny, order per l'accesso alle risorse.
Options Abilita l'uso di Options e XBitHack
Anche per AllowOverride come per Options è possibile modificare semplicemente le direttive ereditate dai livelli più alti, utilizzando il prefisso - per disabilitare e il prefisso + per abilitare. Per esempio:
AllowOverrides
-Indexes +AuthConfig
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-02-05 12:26:49
La gestione dei file e del filesystem viene regolata attraverso la direttiva Options, la quale tratta una o più opzioni come parametri. Ogni parametro controlla un diverso aspetto della gestione del file.
Per esempio: Options
ExecCGI FollowSymLinks con il primo parametro permette ad Apache di eseguire file .cgi (o come altrimenti definiti) come cgi scripts, mentre il secondo permette ad Apache di "seguire" i link simbolici.
Le opzioni permesse sono 7, escluse le opzioni globali All e None, abilitate tutte di default tranne MultiViews.
All Abilita tutte le features tranne MultiViews. Default setting.
ExecCGI Abilita l'esecuzione di script CGI, inoltre è richiesto per ogni contenuto eseguibile.
FollowSymLinks I link simbolici vengono "seguiti".
SymLinksIfOwnerMatch Il server seguirà i link simbolici i cui target hanno lo stesso owner UID del link. Opzione disabilitata da FollowSymLinks se sono entrambe specificate o se si usa All.
Includes Abilita l'uso di server-side includes.
IncludesNOEXEC Permette i server-side include disabilitando l'esecuzione di comandi locali (potenzialmente pericolosa).
Indexes Se l'URL richiesta punta ad una directory priva di una index (index.php, index.html...), Apache genera una lista del contenuto della directory.
MultiViews Viene abilitata la Content negotiation.
None Disabilita tutte le opzioni. Per motivi di sicurezza è bene che venga utilizzata come opzione di default ed abilitate le singole opzioni per directory.
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-02-05 14:08:17
Direttive multiple di Options possono essere unite in una sola riga di configurazione (merge) oltre che essere ereditate dalla directory di livello superiore.
Per esempio:
Options
Indexes Includes
Options
FollowSymLinks
equivale a:
Options
Indexes Includes FollowSymlinks
Se una directory non ha settato in modo esplicito le Options vengono ereditate dalla directory di livello superiore. Queste direttive ereditate possono essere modificate sempre tramite la entry Options usando i simboli - o + come prefissi alle singole direttive da eliminare o da aggiungere.
Ammettiamo che una directory abbia le seguenti direttive Options abilitate:
Options
Indexes Includes FollowSymlinks
e nella sottodiretcory si vuole togliere la direttiva FollowSymLinks e aggiungere ExecCGI
Options
-FollowSymlinks +ExecCGI
Questo vale anche per un tree maggiore di directory:
- DocumentRoot Options
Indexes Includes FollowSymlinks
- 1° SubDir Options
+ExecCGI -Indexes
- 2° SubDir Options
-Includes +IncludeNoExec
Risultato, le Direttive valide nella 2° SubDir equivalgono alla seguente riga
Options
FollowSymLinks ExecCGI IncludeNoExec
Default index e directory listings |
Gestione della visualizzazione di directory. Definizione index predefiniti. |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2005-06-11 18:03:30
Molto spesso quando si naviga sul web non si specifica il nome di un file html specifico, ma semplicemente quello di una directory. Per esempio, l'URL http://www.openskills.info/ indica la directory principale ( / ) del web server www.openskills.info.
In questi casi il server web automaticamente visualizza un file predefinito.
Tramite la direttiva DirectoryIndex è possibile impostare il nome dei Default Index cioè delle pagine che vengono processate quando l'url richiesta corrisponde ad una directory.
La sintassi è la seguente:
DirectoryIndex nome.file nome.file ...
Per esempio:
DirectoryIndex index.php index.php3 index.html index.htm
E' possibile elencare più nomi di file come nell'esempio, questi hanno priorità progressiva: nel caso indicato Apache mostra index.php se esiste, altrimenti index.php3, poi index.html e a seguire.
Se si vuole evitare in modo semplice e veloce il listing di una directory in un server basta creare una pagina vuota con uno dei nomi indicati come DirectroyIndex:
Il comando shell touch /home/www/html/index.htm
crea un file vuoto, che il server web legge e serve al browser che visualizza una pagina vuota (invece, se previsto dalla configurazione del web server) dell'elenco dei file e delle directory contenuti in /home/www/html.
Notare che la scelta di index.html come home page predefinita (o di Default.htm, comune in ambienti Windows, sotto IIS) è assolutamente arbitraria e infatti è facilmente configurabile con la direttiva DirectoryIndex,
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2005-06-11 18:04:37
Ogni volta che Apache deve processare un URL può rispondere in tre modi:
- Restituisce la risorsa richiesta.
- Restituisce un errore.
- Restituisce una pagina html contenente l'elenco degli oggetti contenuti nella directory.
La terza possibilità viene identificata come Directory listing e viene gestita tramite il modulo mod_autoindex.
Tramite la direttiva Options è possibile abilitare e disabilitare la visualizzazione dei file contenuti in una directory, quando non esiste la DirectoryIndex, cioè un file predefinito come home page:
Options +Indexes
Options -Indexes
Per motivi di sicurezza e riservatezza è generalmente consigliabile disabilitare l'opzione di Indexes a meno che l'intento sia proprio quello di mostrare tutto il contenuto di una directory.
L'aspetto della pagina html generata on-the-fly dipende inanzitutto dal contenuto della directory e da varie opzioni settatte tramite le direttive sotto indicate.
Di default viene generata una pagina html con l'opzione FancyIndexing ed in modo automatico viene visualizzato il possibile contenuto di un file readme e HEADER.
Di fatto le configurazioni preimpostate di Apache sono più che adeguate, l'unica attenzione va posta su quali directory permettere il Listing e su quali impedirlo.
IndexOptions
Modifica la visualizzazione del contenuto, con la possibilità di modificare a piacere le dimensione delle icone o visualizzare o meno alcuni attributi dei file contenuti nella directory:
IndexOptions FancyIndexing
HeaderName
E' la direttiva che permette di definire il nome di un file che verrà incluso e visualizzato in modo automatico come header, prima dell'elenco dei file nella directory:
HeaderName intro
IndexIgnore
Direttiva che permette di non visualizzare specifici file nel listing della directory:
IndexIgnore *.doc *.mp3
AddIcon, Addalt
Permette di associare una icona e un alt-text ad un tipo di file:
AddIcon /icons/jpg.gif .jpg
Addalt "JPG Image" .jpg
AddType, AddIconByType, AddAltByType
Permette di associare una icona e un alt-text ad un di file a seconda del suo MIME type.
AddEncoding, AddIconByEncoding, AddAltByEncoding
Permette di associare una icona e un alt-text ad un di file a seconda del suo MIME Encoding.
DefaultIcon
Setta la icona di default che viene visualizzata nel caso in cui il tipo di file non è associato a nessuna icona:
DefaultIcon /icons/blank.gif
AddDescription
Direttiva che permette di aggiungere la descrizione ad eventuali tipi di file:
AddDescription "GIF IMAGE" *.gif
Configurazione di VirtualHost |
Configurazione di Virtual Hosts named based e ip based. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-02-10 17:40:05
Sullo stesso computer è possibile ospitare diversi siti fra loro indipendenti.
Apache prevede diversi metodi per per farlo:
- User Home (tutte le home vengono visualizzate tramite la direttiva UserDir)
- Istanze multiple di Apache (Più Apache, anche di versioni diverse, installati e in esecuzione sulla stessa macchina)
- VirtualHost Ip-based (Più domini virtuali su IP diversi)
- VirtualHost Name-based (Più domini virtuali sullo stesso IP)
Il metodo più utilizzato per erogare più servizi con Apache è quello di creare dei VirtualHost IP o name based.
Ovvero tramite sullo stesso server è possibile creare virtualmente tanti host quanti sono i servizi (siti) che devono essere erogati.
IP-Based
Ad ogni Host virtuale corrisponde un IP differente. Soluzione comoda ma poco utilizzabile quando si hanno molti domini virtuali da usare, per l'inutile spreco di indirizzi IP.
Name-Based
Apache supporta anche il virtual-hosting basato sul nome del server e non sull'IP, quindi più virtual-host Name based possono puntare allo stesso indirizzo IP. Questo richiede l'utilizzo del protocollo HTTP version 1.1, per cui non funziona con browser molto vecchi.
Il vantaggio rispetto all'IP-based è proprio quello di risparmiare indirizzi IP, in quanto è possibile avere anche migliaia di domini con lo stesso indirizzo.
LINK: Apache Virtual Host documentation - http://httpd.apache.org/docs/vhosts/index.html
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-02-10 17:42:07
Il vantaggio del virtual hosting basato su IP è che ogni virtual host corrisponde ad un IP e non ha bisogno di essere identificato con un nome, inoltre viene supportato anche dai vecchi browser che non supportano il protocollo HTTP/1.1.
Lo svantaggio è che per ogni dominio avremo bisogno di un differente IP.
A livello di configurazione bisogna specificare su quali indirizzi e quali porte il server Apache deve rimanere in ascolto.
La direttiva per identificare l'indirizzo IP è BindAddress e la porta Port:
BindAddress *
Rimane in ascolto su tutte le interfacce
Port 80
alla porta 80
Una possibile altrenativa è la direttiva Listen che permette di specificare porta ed indirizzo IP sulla stessa linea di configurazione:
Listen 192.168.208.3:80
Apache binda la porta 80 all'ip 192.168.208.3
oppure
BindAddress 192.168.208.4
Viene bindato l'indirizzo 192.268.208.4
Listen
80
Listen
443 sia alla porta 80 che 443
La direttiva che definisce il VirtualHost nel file di configurazione è VirtualHost
<VirtualHost IP:PORT>
[...]
</VirtualHost>
I primary Object utilizzati per definire le proprietà di un VirtualHost sono:
ServerAdmin La e-mail dell'amministratore del serverweb
ServerName Il canonical name per il virtualhost
DocumentRoot Path dove risiedono file HTML, immagini e contenuti del sito da rendere disponibili
ErrorLog Il log degli errori
CustomLog Il log sui file trasferiti
Esempio:
<VirtualHost 192.168.208.3:80 >
ServerAdmin [email protected]
DocumentRoot /usr/local/apache/htdocs/sick/
ServerName sick-internals
ErrorLog logs/sick-internals-error_log
CustomLog logs/sick-internals common
<Directory "/usr/local/apache/htdocs/sick/">
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
Ognuna di queste direttive tranne ServerName verrebbe ereditata dalla configurazione principale, ma si preferisce per ovvi motivi (non mischiare i log, avere piu' ServerAdmin etc...) definire nuovi parametri per ogni Virtualhost.
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-02-10 17:46:06
L'alternativa al virtual hosting basato su IP è quello Name-based, cioè con più domini condivisi sullo stesso IP. Apache esaminando l'header "Host:" (es: Host: www.dominio.com) inviato dal client interpreta di conseguenza la richiesta, ed eroga il servizio relativamente all'Host richiesto. Questa procedura è valida solo se il client supporta il protocollo HTTP/1.1.
A livello di configurazione la differenza fra il virtual host IP-based e name-based è SOLO la direttiva
NameVirtualHost che va aggiunta alla conf generale per identificare l'IP utilizzato dai vari virtual host, il resto è identico, compresa la sintassi della direttiva container VirtualHost
e il suo contenuto.
E' possibile avere più IP a cui sono associati più domini virtuali. Per esempio:
Prima Dichiarazione dell'IP per i Virtual Host
NameVirtualHost 192.168.208.2
Inizializzazione del primo Virtual Host
<VitualHost 192.168.208.2>
ServerName www.openskills.info
[...]
</VirtualHost>
Inizializzazione del secondo Virtual Host sullo stesso IP
<VirtualHost 192.168.208.2>
[...]
Seconda Dichiarazione dell'IP per altri Virtual Host
NameVirtualHost 192.168.208.3
Inizializzazione di nuovi VirtualHost sul secondo IP
<VirtualHost 192.168.208.3>
[...]
La direttiva NameVirtualHost "cattura" tutte le richieste per l'IP specificato e tramite il confronto fra l'header Host: e la direttiva ServerName o ServerAlias deduce quale risorsa è stata richiesta, se in nessun caso si ha un matching il server risponde con un errore.
ServerAlias La direttiva server Alias permette come nella direttiva ServerName di settare il nome a cui dovrà rispondere il virtualhost ma con la differenza che si ha la possibilità di utilizzare i wildcard characters * e ? . Per esempio:
<VirtualHost 192.168.208.2>
ServerName www.coresis.com
ServerAlias www.coresis.it
In questo caso questo Virtualhost risponderà sia per www.coresis.com che per www.coresis.it
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-11-22 19:31:30
Un piccolo elenco delle direttive che non avrebbe senso mettere nella configurazione di un virtual host con la relativa spiegazione.
ServerType
Direttiva che determina se Apache è un demone standalone o gestito da inet e richiede per forza di cose di essere inserito nella "global section". I parametri di avvio cambiano a seconda del ServerType.
StartServers, MaxSpareServers, MinSpareServer e MaxRequestsPerChild
Tutte queste direttive controllano tutti i processi di Apache per le singole richieste ma è esclusa qualsiasi tipo di correlazione a singoli virtualhost poiché i vari child sono indifferentemente usati da Apache per gestire richieste a virtual host diversi.
BindAddress, Listen
La configurazione principale richiede un IP e una porta per stabilire a quale indirizzo Apache deve rimanere in ascolto, nella configurazione dei singoli virtualhost il binding dell'indirizzo avviene secondo criteri e direttive diverse.
ServerRoot
Direttiva che definisce il path delle configurazioni o di altre risorse in comune a tutti i virtualhost.
PidFile
File contenente il process ID del main server, poiché il file è settabile solo dal main server e non esiste una correlazione virtual-host/processi, deve essere definita nella global section.
TypesConfig
Indica il nome del file MIME Type, per definizione è settabile solo nella configurazione globale.
NameVirtualHost
Definisce l'IP da relazionare ai virtualhost name-based e quindi non avrebbe senso definirlo nelle configurazione dei singoli virtual host.
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-02-10 18:01:11
La direttiva VirtualHost accetta sia i canonical name che gli indirizzi IP, ma per evitare problemi di sicurezza e di performance è bene utilizzare sempre gli IP.
Anche se è proprio la direttiva VirtualHost a configurare a quale indirizzo IP o nome dovrà rispondere il Virtualhost è consigliato mettere sempre l'IP e la porta a cui deve rispondere, sarà proprio la direttiva ServerName che eviterà al server Apache di lanciare inutili query al DNS per scoprire la corrispondenza IP e nome VirtualHost.
HOWTO: OPENVPN:Tunneling Win to Linux - http://www.sistemistiindipendenti.org/modules/news/article.php?storyid=66
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-02-10 17:48:56
Per facilitare la gestione dei virtual host, per permettere l'aggiunta di nuovi domini virtuali ad amministratori che non dovrebbero avere accesso al file di configurazione generale o per qualsiasi simile necessità, è consigliabile inserire la parte di configurazione riguardante i virtual host su file separati.
Tramite la direttiva Include possibile includere nel file di configurazione principale httpd.conf file contenenti ulteriori direttive.
Aggiunge alla direttiva principale, tutte le direttive scritte nel file indicato
Include conf/vhost.conf
E' possibile anche usare wildcard ed inserire diversi file intere directory:
Include conf/*.conf
Il caso sopra citato è comodo anche per attivare o disabilitare intere parti di configurazione rinominando semplicemente il nome del file, facendo in modo che non concluda con .conf
Ricordarsi che ogni modifica nel file di configurazione principale o nei vari file inclusi tramite la direttiva Include richiede l'avvio del server web per essere resa operativa.
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-02-10 17:56:19
Con la direttiva Listen si possono specificare due opzioni: l'IP e la porta o solo una delle due ma senza aver la possibilità di utilizzare gli hostname, invece la direttiva BindAddress accetta sia gli ip che gli hostname (configurazione sconsigliata) ma senza la possibilità di specificare la porta.
Per specificare la porta occorre affiancare alla direttiva BindAddress o la direttiva Listen o la direttiva Port. Per esempio:
BindAddress 213.198.151.253
Port 80
coincide con:
Listen 213.198.151.253:80
e con:
BindAddress 213.198.151.253
Listen 80
la documentazione ufficiale di Apache raccomanda di usare Listen in quanto le direttive Port e BindAddress sono destinate all'obsolescenza.
Tipo Infobox: BOFH - Skill Level: 4- ADVANCED - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-11-21 19:12:46
Questo comando permette di alzare il numero massimo di file che un applicativo o un utente possono aprire contemporaneamente.
Esistono casi reali in cui questo limite può essere raggiunto. Per esempio su sistemi con un Apache che gestisce una gran quantità di siti, per i quali deve aprire i relativi log indipendenti.
Il parametro va reimpostato ad ogni avvio, alcune distribuzioni prevedono un file di configurazione predefinito per impostare "limits" come questo.
Per visualizzare tutti i parametri
[neo@dido neo]$ ulimit -a
core file size (blocks) 0
data seg size (kbytes) unlimited
file size (blocks) unlimited
max locked memory (kbytes) unlimited
max memory size (kbytes) unlimited
open files 1024
pipe size (512 bytes) 8
stack size (kbytes) 8192
cpu time (seconds) unlimited
max user processes 2047
virtual memory (kbytes) unlimited
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2003-02-10 17:53:04
Apache può gestire un'infinità di virtual host, e prevede strumenti per la gestione automatica di un gran numero di domini virtuali, che rende estremamente comoda la vita di grandi provider, registrar e chiunque si ritrova a gestire più di poche decine di domini virtuali su un singolo server.
Fondamentalmente sono utilizzabili 3 diversi metodi, tramite tre moduli.
- mod_rewite
- mod_perl (script perl)
- mod_vhost_alias
MOD_REWRITE
Tramite la direttive gestite dal modulo mod_rewrite è possibile configurare dinamicamente dei virtual host name-based.
Abilitazione del modulo mod_rewrite
RewriteEngine on
Test per l'host header per estrarre il nome del dominio
RewriteCond %{HTTP_HOST} ^www\.(.+)$
Rewrite dell'URL per redirezionare il client alla risorsa richiesta
RewriteRule ^/(.+)$ /home/www/%1/$1 [L]
In questo caso se il client richiede http://www.openskills.info/index.php le rule di rewrite convertiranno la richiesta per accedere alla risorsa che risiederà in /home/www/openskills.info/index.php.
Il vantaggio di utilizzare questo metodo è che non bisogna riavviare Apache per aggiungere un virtualhost ma semplicemente aggiungere la entry nel prorio DNS.
Lo svantaggio, come con tutti i domini virtuali name based, è che può funzionare solo con i browser che utilizzano il protocollo HTTP/1.1 e che ogni dominio deve poter essere risolto con il dns.
MOD_PERL
E' possibile tramite il linguaggio di programmazione perl scrivere un piccolo script da includere nel file httpd.conf fra i tag <perl> .
Esempio:
Apertura del tag perl ed inizializzazione dello script da includere nel file httpd.conf
<Perl>
#!/usr/bin/perl -w
Definizione di alcune variabili
local ($ip,$host,$admin,$vroot,$aliases);
local ($directive,$args);
Apertura e parsing del file di configurazione
open (FILE,"/usr/local/apache/conf/vhost-perl.conf")
while (<FILE>) {
Skippa tutte le linee che iniziano con #
next if /^\s*(#|$) / ;
if (/^d+/) {
($ip,$host,$admin,$vroot,$aliases)=split /\s*,\s*/, $_;
$VirtualHost{ip}= {
ServerName =>$host,
ServerAdmin => $admin,
DocumentRoot => "/home/www/".$vroot,
ErrorLog => "logs/".$host."_error.log",
TransferLog =>"logs/".$host."_access.log"
};
Gestione Alias
$VirtualHost {$ip} {ServerAlias} =$aliases if $aliases;
Gestione della direttiva port
$VirtualHost {$ip} {Port} =$1 if ($ip=~/:(\d+)$/);
Aggiunta di eventuali direttive, specificate nel file di configurazione /usr/local/apache/conf/vhost-perl.conf
} elseif ($ip) {
($directive,$args)=split / /, $_,2;
$VirtualHost {$ip} {$directive}=$args;
}
}
Chiusura del file e dello script
close (file);
_END_
<Perl>
Il passo successivo è quello di creare il file di configurazione /usr/local/apache/conf/vhost-perl.conf secondo la seguente sintassi:
IP(:port), hostname,ServerAdmin,document root, aliases
Direttive Opzionali
Esempio:
213.198.151.253:80, openskills.info, [email protected] /home/www/openskills
MOD_VHOST_ALIAS
La configurazione base per i virtualhost name-based è la seguente:
UseCanonicalName off
VirtualDocumentRoot /home/www/%0
Invece per i virtualhost ip-based:
UseCanonicalName DNS
VirtualDocumentRoot /home/www/%0
Dove %0 è l'hostname dedotto dall'host header inviato dal client nel primo caso e nel secondo è il risultato della query effettuata al DNS.
Inoltre è possibile affiancare altre direttive per completare la configurazione di un virtualhost:
-VirtualDocumentRootIP
E' possibile identificare la document root attraverso l'IP piuttosto che con il nome dell'host.
VirtualDocumentRootIP /home/www/%0
Dove %0 è l'IP dell'host, quindi l'url verrà rimappata in /home/www/213.198.151.253 nel caso di openskills.info.
-VirtualScriptsAlias e VirtualScriptsAliasIP per specificare le directory dove risiedono i CGI:
VirtualDocumentRoot /home/www/%0/html
VirtualScriptsAlias /cgi-bin/ /home/www/%0/cgi-bin
o
VirtualDocumentRootIP /home/www/%0/html
VirtualScriptsAliasIP /cgi-bin/ /home/www/%0/cgi-bin
-ScriptAliasMatch
Direttiva simile a VirtualScriptsAliasIP e VirtualScriptsAlias che permette di definire una singola directory contenente cgi-script per tutti i virtual host:
ScriptAliasMatch /cgi/bin /home/www/.*/cgi-bin/
LINK: Ufficial Docs Dynamic VirtualHosting - http://httpd.apache.org/docs/vhosts/mass.html
Apache performance tuning |
Suggerimenti e informazioni per migliorare le performance di Apache. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-11-26 17:41:19
Apache è stato sviluppato dando priorità alla stabilità, integrità e espandibilità del servizio mentre meno attenzione è stata data alla performance brutale, pur essendo stati fatti notevoli sforzi al riguardo, in particolare con la versione 2.0.
Per questo motivo, in performance test di laboratorio, Apache non risulta sempre la soluzione più veloce, anche se spesso, in condizioni e con necessità reali, le sue feature risultano di fatto più efficaci.
Esistono comunque diversi modi per migliorare le performance di Apache, fondamentalmente riguardano la configurazione e la quantità di features che si intendono utilizzare.
Restando inteso che il tuning del proprio sistema va fatta sulla base delle specifiche esigenze, per cui non è semplice dare indicazioni assolute, valide in ogni contesto, è possibile fornire dati utili su come configurare il proprio server per migliorarne le prestazioni, sia in termini di velocità che in termini di occupazione delle risorse del sistema e scalabilità.
In generale:
- Un Apache compilato staticamente, senza il supporto di moduli dinamici, risulta generalmente più efficiente. Gli stessi moduli da caricare dinamicamente (o da compilare staticamente) possono essere limitati e selezionati nel numero, a seconda delle direttive effettivamente utilizzate in modo da ridurre l'impronta in memoria del binario in esecuzione.
Uno strumento comodo per capire cosa effettivamente serve è server-info che indica quali direttive sono usate nel proprio file di configurazione e da quali moduli sono fornite.
- httpd.conf presenta una serie di direttive che riguardano esplicitamente le performance del sistema. Il loro tuning permette di adeguare meglio il proprio Web Server a situazioni di traffico diverse. Nel BOX dedicato si possono leggere i dettagli.
- Altre direttive influiscono in vario modo sulle performance, in particolare esistono direttive, presenti nel file di configurazione di default, che possono essere rimosse senza problemi perchè riguardano funzionalità che non vengono sfruttate sul proprio sistema.
- A livello di risorse hardware è la RAM quella che di fatto, come spesso accade, influisce maggiormente sulle performance. Su un server web performante non si dovrebbe mai utilizzare il file di SWAP, per cui ci si deve attrezzare per aumentare la memoria fisica.
- Nella maggior parte dei casi reali il vero collo di bottiglia di un sito web è la generazione dei contenuti dinamici. Spesso quindi il fine tuning di Apache ha un impatto trascurabile rispetto all'architettura generale del sito, agli Application Server e l'accesso al database di backend. In questi casi va spostata la propria attenzione sull'ottimizzazione del codice e delle query, l'indicizzazione delle tabelle del DB, la staticizzazione di parte dei contenuti dinamici.
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-11-26 17:33:34
Vediamo alcune direttive di Apache che espressamente riguardano le performance e il dimensionamento di un server web.
GESTIONE DEI PROCESSI
Su Unix Apache 1.3 opera come un pre-forking server, dove un processo iniziale provvede a generare dei child che devono effettivamente gestire le richieste dei client.
Alcune direttive permettono di gestire il numero dei processi da aprire all'avvio e il quanti tenermi in standby, in attesa di richieste:
StartServers 5
- Imposta (di default a 5) il numero di processi figli che vengono laciati da Apache. Visto che la fase di forking di un nuovo figlio è onerosa in termini di risorse richieste, su siti ad alto traffico ha senso aumentare considerevolmente questo valore.
MinSpareServers 5
- Imposta (di default a 5) il numero minimo di child che devono essere sempre essere disponibili per gestire nuove richieste. Anche in questo caso su siti ad alto traffico e in particolare soggetti a picchi di attività, ha senso aumentare questo valore.
MaxSpareServers 10
- Imposta (di default a 10) il numero massimo di child che possono essere liberi in attesa di nuove richieste. Ovviamente questo valore ha senso se è superiore a MixSpareServers, ma non è il caso di impostarlo troppo alto, per non rischiare di avere un server che dopo un picco di attività, rimane con troppi processi figli inutilizzati.
MaxClients 256
- Imposta (di default a 256) il numero massimo di client che possono accedere contemporaneamente al server. Questo valore è piuttosto importante perchè di fatto limita il numero di utenti e permette di evitare che il server collassi sotto un carico troppo alto (a fronte di un messaggio di errore del tipo "Server Unavailable" ai client in eccesso). Va dimensionato secondo i limiti massimi gestibili dall'hardware: un valore troppo basso rischia di escludere, sotto carico, alcuni client che potrebbero essere serviti, un valore troppo alto rende il server soggetto al totale collasso.
E' IMPORTANTE sottolineare che nei sorgenti e nei binari generalmente distribuibili, 256 è un limite massimo (a prescindere da quanto viene scritto nella configurazione). Per cui se si vuole avere un Apache in grado di gestire più di 256 client contemporaneamente si devono modificare i sorgenti, in particolare il file httpd.h, aumentare il valore associato alla voce HARD_SERVER_LIMIT e ricompilare il Apache.
MaxRequestsPerClient 0
- Imposta (di default a infinito, indicato con 0) il numero di richieste HTTP che ogni singolo processo di Apache deve gestire prima di essere terminato. Ha senso mettere un valore alto ma finito (esempio: 10000) per evitare potenziali memory leaks di un processo. In pratica, nel nostro esempio, dopo 10000 richieste gestite un child di Apache viene volontariamente terminato e sostituito da uno nuovo.
TUNING SU TCP/IP E HTTP
Alcune direttive di Apache influenzano il modo con cui il server utilizza i protocolli di rete su cui si basa.
SendBufferSize 32768
- Imposta, in byte, le dimensioni del buffer da allocare per gestire l'output da parte di ogni singolo child di Apache. Questo rende più efficiente il trasporto dei dati su TCP/IP in caso di latenze alte, ma aumenta l'occupazione di memoria (e può diventare critico sotto alto carico).
KeepAlive on
- Permette al server di gestire più richieste HTTP fra uno specifico client e il child del server con cui comunica, utilizzando la stessa sessione TCP. Questo aumenta considerevolmente la velocità e l'ottimizzazione della gestione delle richieste, in quanto non richiede una nuova fase syn-synack per ogni GET del client. Su browser vecchi, che non supportano HTTP/1.1, questa opzione non funziona e può creare problemi (nella configurazione di default di Apache, con la direttiva BrowserMatch, si corregge il comportamente del server quando ha a che fare con questi client obsoleti).
KeepAliveTimeout 15
- Imposta il numero di secondi che un child di Apache aspetta senza ricevere nuove richieste dal client con cui sta comunicando prima di chiudere la connessione e tornare IDLE.
Su server sotto alto carico, questo valore è meglio che sia basso (intorno ai 15 secondi indicati) per evitare di occupare inutilmente risorse per troppo tempo.
MaxKeepAliveRequests 100
- Imposta il numero massimo di richeste che Apache può servire sulla stessa connessione. E' bene impostare un valore finito e non esageratamente alto. Un valore troppo basso, di fatto, rende inutile il KeepAlive.
TimeOut 300
- Imposta il tempo in secondi (300 il valore di default) di inattività in generale, prima di terminare una connessione HTTP. Un valore troppo basso rischia di impedire il POST di grosse quantità di dati su link lenti, un valore troppo alto aumenta l'esposizione del server a DOS attack e ne sfrutta male le risorse.
ListenBacklog 511
- Imposta il numero di richieste da mettere in code quando Apache è troppo occupato per gestirle tutte. Con questa direttiva Apache imposta la lunghezza della coda e invece di droppare le richieste eccedenti, le processa appena possibile. Il valore di default è 511, non è il caso di aumentarlo troppo perchè è probabile che client messi in coda, dopo un certo tempo di mancata risposta da parte del server, abbiano già dirottato altrove le loro richieste.
SOURCE: Apache Performance Notes - http://httpd.apache.org/docs/misc/perf-tuning.html
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-03-13 11:37:16
Apache prevede nel file di configurazione di default una serie di direttive (alcune soltanto commentate) che da un lato ne aumentano le proprietà e le funzionalità, dall'altro impattano in modo non trascurabile sulle performance del sistema.
Alcune di queste impostazioni possono essere necessarie per il nostro servizio e non se ne può prescindere, altre, spesso, risultano di fatto inutilizzate ed inutilmente configurate.
Vediamo alcuni casi.
REVERSE DNS LOOKUP DEI CLIENT
Ogni richiesta HTTP che arriva al server viene fatta da un HOST in rete con un proprio indirizzo IP che viene loggato da Apache. E' possibile scegliere se provare anche a loggare il nome dell'host completo invece dell'IP, facendo una apposita query DNS (un REVERSE LOOKUP, che da un IP cerca di ottenere il rispettivo hostname). Assicurarsi che questa funzionalità venga disattivata e che Apache non perda tempo a risolvere gli indirizzi IP:
HostNameLookup off
Esistono svariati e migliori modi per procedere alla risoluzione degli IP loggati da Apache in un tempo successivo per dare statistiche sul traffico Web indicative si domini da cui arrivano i client.
GESTIONE DEI SYMLINK
Con la direttiva Options si può istruire Apache su come gestire i link simbolici.
Si può impedirgli di seguirli al di fuori della sua DocumentRoot o gli si può forzare un controllo sull'owner del link. Si risparmiano chiamate di sistema aggiuntive, e cicli di clock, se si evita ad Apache l'onere di controllare se un file è un link simbolico o no e, ancor più, di verificare il suo owner.
In termini di performance quindi la migliore scelta per qualsiasi container è :
Options FollowSymLinks
che dice ad Apache di seguire i symlink e di non stare a controllarne l'owner.
Considerare che questa direttiva (insieme a Options SymLinksIfOwnerMatch) hanno una loro ragione d'essere in termini di sicurezza, per cui, come spesso accade, va valutato il giusto compromesso.
GESTIONE DEGLI OVERRIDE
La direttiva AllowOverride permette di definire in file separati (.htaccess) delle configurazioni specifiche per le directory in cui si trovano e in quelle figlie. In termini di performance l'abilitazione dell'Override comporta da parte di Apache una serie di controlli sull'esistenza effettiva del file .htaccess che inevitabilmente impattano sulle prestazioni. Per questo motivo, salvo eventualmente le directory in cui è strattamente necessario, si consiglia vigorosamente di disattivare l'override della configurazione generale con file locali .htaccess:
<Directory/>
AllowOverride None
</Directory>
Questo, per una volta, da benefici anche in termini di sicurezza.
Disattivando gli override diventa pleonastica anche la seguente parte di configurazione, presente negli httpd di default, che quindi può essere commentata:
#AccessFileName .htaccess
#<Files ~ "^\.ht">
# Order allow,deny
# Deny from all
# Satisfy All
#</Files>
STATUS E EXTENDED STATUS
Il mod_status fornisce un utile strumento di diagnostica, la location /server-status consultabile per visualizzare in tempo reale lo stato delle connessioni al server web. Con la direttiva ExtendedStatus, inoltre, è possibile visualizzare ulteriori interessanti informazioni.
Inutile dire che anche queste funzionalità impattano sulle risorse del sistema, in particolare l'ExtendedStatus, per cui, salvo necessità specifiche è bene disattivarle. Nel httpd.conf di default sono già scommentati:
#<Location /server-status>
# SetHandler server-status
# Order deny,allow
# Deny from all
# Allow from .your-domain.com
#</Location>
#ExtendedStatus On
COOKIE E SESSION TRACKING
Tracciare le sessioni di navigazione degli utenti tramite cookie o altri strumenti può essere comodo per l'analisi dei log o fondamentale per il corretto funzionamento di certi siti dinamici, ma se non serve è bene farne a meno, disattivando direttamente il relativo modulo:
#LoadModule usertrack_module lib/apache/mod_usertrack.so
#AddModule mod_usertrack.c
Di fatto, anche caricando questo modulo, Apache non setta cookie a meno che non si indichino le specifiche direttive ( CookieDomain, CookieExpires, CookieName ...)
CONTENT NEGOTIATION
In genere, la documentazione di Apache suggerisce che i vantaggi di poter gestire la content negotiation prevalgono sui benefici in termini di prestazioni che si hanno disattivandola.
Un eccezzione è la direttiva DirectoryIndex, che accetta anche nomi di file senza suffissi (es: DirectoryIndex index) ma che è preferibile definire per ogni file che si vuole utilizzare come home page:
DirectoryIndex index.php index.htm index.html index.cgi
LIMITAZIONE DEL LOGGING
Di default Apache logga ogni richiesta ricevuta per cui scrive, per ogni file servito, almeno una riga di log in un file aperta del proprio file system. In server particolarmente affollati questa operazione può determinare un ulteriore appesantimento del sistema (oltre che enormi file di log difficili da gestire).
L'access log può essere completamente disattivato oppure limitato alle sole richieste di pagine (senza appesantirlo con il logging delle GET a immagini e altri file collaterali), l'error log, che non può essere disattivato, può essere impostato per abbassare il numero di informazioni da loggare:
LogLevel error
(di default è "warn).
Per disabilitare l'access loggin basta commentare ogni direttiva CustomLog o TransferLog:
# CustomLog /var/log/httpd/access_log common
RIMOZIONE DI MODULI INUTILIZZATI
La configurazione di Apache permette, tramite la funzione IfModule, di attivare una serie di direttive soltanto se il modulo che le fornisce è presente. In questo modo è possibile testare le funzionalità del web server, attivando o disattivando intere sezioni di configurazione, semplicemente commentando la riga che carica il relativo modulo:
#LoadModule perl_module modules/libperl.so
Inoltre, aiutandosi con le informazioni fornite da server-info, è possibile rimuovere direttamente i moduli che forniscono direttive che non vengono nemmeno considerate.
Per migliorare le prestazioni e diminuire l'occupazione di memoria di Apache, si può evitare di caricare tutti i moduli che non servono sia perchè non si utilizzano per niente le relative direttive, sia perchè si decide di rinunciare alle funzionalità offerte da direttive incluse in un container IfModule.
SOURCE: Apache Performance Tuning - http://httpd.apache.org/docs/misc/perf-tuning.html
Design di una infrastruttura Web |
Design della rete, dei server, dei servizi. |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-11-28 16:21:35
Le scelte su come strutturare una rete che debba erogare servizi Web, e non solo, dipendono da molti fattori diversi:
- Risorse economiche (il budget a disposizione per l'intero progetto)
- Skill disponibili (le conoscenze del personale interno, la disponibilità di consulenti esterni)
- Infrastruttura esistente (eventuali vincoli dovuti ad una situazione preesistente)
- Traffico previsto (è importante dimensionare le strutture per gestire senza problemi il carico previsto e scalare facilmente quando questo aumenta)
- Tipo di informazioni e servizi offerti online (se si trattano dati personali, sensibili, critici, come vanno inseriti e gestiti)
- Criticità del servizio (un'idea di quanto è sopportabile un down del servizio da indicazione sui sistemi di High Availability da implementare)
- Variabilità ed espandibilità del servizio (avere un'idea se la nostra web farm è destinata ad aumentare i servizi erogati).
- Necessità di interfacciamento con altri sistemi (se è necessario uno scambio di dati con altri sistemi, eventualmente non su Internet, se sono richieste compatibilità e interoperabilità con sistemi proprietari, ecc)
Questi ed altri fattori inevitabilmente influenzano il tipo di infrastruttura Web che si deve mettere in campo.
Semplificando, e lasciando a BOX di approfondimento i dettagli e le distinzioni del caso, possiamo ipotizzare tre principali categorie di implementazione:
Singolo server per gestire basso traffico - Può essere il singolo sito aziendale, statico o dinamico, con un traffico relativamente basso (meno di 2000 visite al giorno, gestibile con meno di 512Kb/s di banda) o anche un hosting server di un provider con vari siti virtuali con poco traffico.
Per simili casi può bastare una singola macchina Unix che contenga tutto quanto serve per erogare anche pagine dinamiche. Il trittico Apache-PHP-MySQL su piattaforma Linux appare una soluzione economica, affidabile e testata, ma non è certo necessariamente l'unica.
Le funzioni di firewalling possono essere fornite da un dispositivo esterno o anche dalla macchina stessa.
Infrastruttura distribuita per medi carichi - Può riferirsi a siti con traffico medio (da 512Kb/s a qualche Megabit al secondo) o caratteristiche complesse. In questo caso diverse macchine forniscono diversi servizi. Oltre a un DB server autonomo è legittimo prevedere uno o più application server, uno o più web server, eventuali cache server e firewall indipendenti. Un caso simile può presentare una notevole varietà di soluzioni e implementazioni, secondo i fattori sopra indicati e il livello di ridondanza richiesto
Infrastruttura complessa per alti carichi - Necessaria per gestire siti che erogano traffico per varie decine di Megabit al secondo. E' ovviamente distribuita, con diverse macchine, o pool di macchine, a fornire diversi servizi.
La scalabilità orizzontale dovrebbe essere prevista per ogni livello (i web server su cui viene fatto bilanciamento di carico devono poter aumentare in numero senza problemi, e lo stesso vale, per gli altri servizi), la ridondanza e l'high availability diventano, su siti ad alto traffico, quasi obbligatorie, per cui è prevedibile che si debba implemntare a tutti i livelli. Meccanismi di caching e staticizzazione delle pagine sono quasi obbligatori, visto l'alto carico e la natura quasi certamente dimanica di un simile sito.
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-11-28 16:48:17
Se le nostre stime sul traffico Web da sostenere non sono alte e si presume che, quantomeno in una fase iniziale, possono bastare meno di, indicativamente, 512 Kbit di banda e un server in grado di gestire qualche centinaio di visite medie al giorno o qualche migliaia di pageviews, probabilmente una singola macchina può bastare.
Ovviamente è un'indicazione di massima, che si adatta a contesti medi con queste caratteristiche e necessità di uptime non estreme.
Se il nostro web server è il frontend di un datawarehouse di un TeraByte di dati, è ovvio che ci dovrà essere almeno una macchina separata per gestire il DB, se dovrà ospitare un sito estremamente sicuro, si dovrà considerare una o più macchine aunomome con funzioni di intrusion detection e traffic analysys, se il servizio deve avere uptime nell'ordine del 99,9% ci sarà da considerare l'implementazione di un cluster o di un'altra struttura di HA, e così dicendo.
Dimensionamento hardware
Casi particolari a parte, le necessità richieste possono essere erogate con un sistema Linux munito di Apache + PHP o Mod_Perl, con database MySql su un singolo server Intel Based, con RAM di almeno 256Mb (minimo), dischi EIDE di capacità sufficienti per ospitare le pagine web e i dati del DB, scheda di rete a 10/100 Mbit/sec, processore Pentium 3 o superiore.
Ovviamente visti i costi sempre descrescenti dell'hardware, è preferibile acquistare una macchina nuova, con le garanzie di assistenza del caso, che ormai offre capacità superiori.
La RAM, in particolare influisce sulle prestazioni del server, i 256 MB indicati probabilmente non bastano a riempire i 512 Mbit di banda ipotizzati con contenuti dinamici.
Software installati
Se la scelta è l'OpenSource le soluzioni sono quasi ovvie: Linux o *BSD come sistema operativo, Apache come web server, PHP o Perl come linguaggio più comune per la gestione di pagine dinamiche (anche se le alternative sono molte), MySQL o PostgreSQL come database server. Si possono installare programmi o servizi specifici (ftp server per l'uplodad delle pagine del sito, traffic analyzer per statistiche sul traffico web ecc.) e considerare l'uso di un sistema di firewalling interno: le Iptables su Linux sono estremamente efficaci e "leggere" e rappresentano un buon modo per limitare l'accesso pubblico a tutte le porte che non siano l'80 su cui deve essere erogato il servizio web pubblico.
Impostazione della struttura applicativa
Molte scelte che influenzano in modo determinante la possibilità di espansione di un sito dipendono da come si impostano, fin dall'inizio, le strutture a livello applicativo.
MAI, per quasi nessun motivo, si dovrebbe inserire all'interno del codice (PHP, Perl o altri) degli indirizzi IP fissi, che inchiodano il server ad uno specifico indirizzo che renderebbe complicata e faticosa ogni migrazione o upgrade.
Usare sempre nomi di host diversi per diversi servizi: se ci si deve collegare al database, chiamarlo in modo diverso da come si chiama la macchina su cui gira il web server (e il database stesso). Usare un alias, ad esempio db.openskills.info: il giorno in cui il sito crescerà e ci sarà bisogno di una macchina separata per il DB, basterà cambiare una entry nel DNS senza dover intervenire sul codice nelle pagine.
Individuare i diversi servizi logici del sistema chiamandoli con nomi diversi fin dall'inizio facilita la possibilità di scalare in tempi successivi.
Usare classi, oggetti, include: evitare di scrivere lo stesso dato legato al contesto specifico e quindi potenzialmente mutabile (per esempio i parametri di connessione al DB) in file diversi.
Backup dei dati
Esistono molteplici modi per fare un backup, l'unica cosa che li accomuna è il FARLO.
Non è pensabile, in alcuna situazione, di non prevedere un sistema di backup di qualche tipo dei propri dati.
Alcune regole generali possono comunque essere indicate:
- Eseguire un backup remoto, su una macchina diversa dal server stesso e, se possibile in un edificio diverso.
- Se non si hanno grandi quantità da backuppare è preferibile usare un hard disk più che un nastro, come medium su cui scrivere le copie: permette tempi di recovery più rapidi e maggiore affidabilità.
- Può bastare backuppare solo i dati (pagine del sito, dump del db) e le configurazioni custom, in caso di guasti un nuovo sistema Linux/Unix si mette in piedi in tempi relativamente rapidi.
- Valutare l'opportunità di avere un server di backup che operi anche come cold standby: con poche riconfigurazioni e procedure è possibile far diventare la macchina che fa la copia dei dati anche una macchina di backup per il servizio stesso.
- Fra i metodi di backup via rete più efficaci che conosciamo, per moli di dati nell'ordine dei Gigabyte, segnaliamo rsync che permette copie differenziali di intere directory fra macchine remote (e possibilità di ripristino dei dati in tempi rapidi e con pochi sforzi).
Ridondanza
Come sempre, il budget influenza in modo determinante le tecniche di ridondanza praticabili. Per il dimensionamento indicato, ipotizzando un budget ridotto, ci sentiamo di consigliare l'uso di hardware relativamente cheap (dischi IDE e non SCSI, niente mirror hardware, nessun specifico hardware di ridondanza) e prevedere la predisposizione di un server gemello, da usare per il backup e il cold standy.
Una simile configurazione, con un server principale in produzione, basato su economico hardware Intel-like e un server analogo configurato per eseguire regolare backup dei dati e già predisposto e configurato per offrire gli stessi servizi in caso di guasto del main server, può successivamente evolvere in una struttura ridondata più complessa, eventualmente con un hot standby.
In pratica, se il budget è un issue, l'esperienza di vari anni di utilizzo sia di hardware cheap che di soluzioni costose e più affidabili, ci porta a preferire una ridondanza completa di macchine economiche piuttosto che più costose soluzioni di ridondanza di singoli componenti.
Sicurezza
I requisiti minimi sono gli stessi prevedibili per ogni sistema presente su Internet:
- Esposizione ad IP pubblici solo delle porte strettamente necessarie per erogare il servizio;
- Aggiornamento costante, in presenza di nuove vulnerability, almeno del software che ascolta sulle porte pubbliche;
- Verifica di potenziali problemi di sicurezza degli script e delle pagine dinamiche a cui si può accedere tramite la porta pubblica (l'80, per il nostro web server).
Tutto quello che viene in più (Intrusion Detection a livello di rete, integrity check, statistiche ecc.) può essere utile o divertente, ma perde ogni significato se i 3 punti sopra elencati non vengono seguiti.
Per esporre il minor numero possibile di porte al pubblico, oltre ad eliminare tutti i servizi che di fatto non vengono utilizzati, si possono utilizzare firewall esterni o direttamente meccanismi di firewalling a livello dello stesso host.
Per certe porte ausiliarie (porta FTP per l'upload dei dati, porta TELNET o SSH per la gestione remota, porta utilizzata dal sistema di Network Backup in essere ecc.) è raccomandabile permettere l'accesso solo da range di IP limitati e fidati.
La struttura del network su cui appoggiare il proprio Web Server può ricalcare uno dei modelli tipici per il design di network pubblici, con presenza o meno di DMZ, firewall perimetrali e interni, bastion host ecc, la logica comunque deve rimanere quella esposta: lasciare accesso pubblico soltanto alle porte necessarie (solo la 80 per il server web), limitare il range di IP abilitati ad accedere a porte per i servizi accessori.
HOWTO: Linux WWW HOWTO - http://ldp.openskills.info/HOWTO/WWW-HOWTO.html
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2002-11-28 17:42:45
E' impossibile fornire uno schema di rete e logico di una infrastruttura distribuita senza avere punti precisi da cui partire: necessità specifiche, requirements, idea dei flussi di dati previsti, indicazione dei servizi utilizzati ecc.
Proviamo comunque a fornire alcuni spunti che possono essere sviluppati ed adattati a casi specifici, mantenendo come riferimenti la necessità di gestire un sito dinamico in grado di erogare traffico medio giornaliero di qualche Megabit al secondo.
Hardware
Il dimensionamento delle singole macchine che vanno a costituire la struttura generale dipende ovviamente da innumerevoli fattori. Noi propendiamo per la serializzazione dell'hardware con tanti piccoli server a distribuire il carico, ma per alcuni servizi questo approccio presenta più problemi che benefici, per cui diventano preferibili singole macchine particolarmente potenti.
Per esempio se individuiamo 3 servizi logici in un sito complesso: web server, application server e database server, i primi due potranno essere gestiti con una farm di macchine relativamente economiche a carico bilanciato, ma il database dovrà stare su hardware potente eventualmente in cluster.
Software
Le soluzioni Open Source permettono scalabilità e stabilità all'altezza del compito, ma per certe applicazioni critiche potrebbero essere sfavorite rispetto a soluzione proprietarie con un affidabile servizio di assistenza.
Il web server può, inevitabilmente, essere Apache.
L'application server può basarsi su PHP o Perl, con i relativi moduli, ma più probabilmente, per presenza sul mercato e buona scalabilità, potrà basarsi su Java.
Come database, Oracle potrebbe venir preferito a MySQL e PostgreSQL per assistenza, scalabilità, integrità e gestione delle transazioni sotto alto carico.
E' importante cercare di mantenere omoneneità nelle versioni dei sistemi operativi installati e implementare sistemi per un aggiornamento rapido del software di produzione e l'installazione di nuovi server (Jumpstart o Kickstart).
Backup
Su un sistema distribuito il backup deve preferibilmente essere centralizzato, con un backup server eventualmente collegato ad una SAN o una libreria di nastri.
E' pensabile, anche se aumenta considerevolmente la complessità del sistema, prevedere una LAN di amministrazione, che collega su una seconda interfaccia di rete i vari server, per l'accesso da parte degli amministratori, le operazioni di backup e di gestione, in modo che questo traffico non si sovrapponga con quello per i servizi di produzione.
Ridondanza
Oltre a soluzioni di clustering per certi servizi (tipicamente il database server) è pensabile una struttura con tanti piccoli server paralleli e bilanciati per i server Web.
In questi casi, oltre alla soluzione di load balancing scelta (appliance dedicata, soluzioni software come LVS ecc) è importante considerare la modalità di accesso ai dati da parte dei singoli server.
Le configurazioni e le pagine del sito web possono essere accessibili via rete, per esempio via NFS, da un unico punto centralizzato o distribuite con sistemi tipo rdist, rsync o cvs.
Ogni alternativa ha i suoi svantaggi e vantaggi.
Un unico repository raggiungibile via NFS garantisce l'integrità e l'omogeneità dei dati sui diversi web server ma aumenta latenza, point of failure e traffico di rete.
Un sistema di distribuzione dei contenuti sui singoli server richiede maggiore storage locale, rischia di portare a directory di documenti non omogenee sulle diverse macchine e richiede procedure custom per la distribuzione dei contenuti. Al contempo non ha i difetti di una soluzione basata su un network file system.
Sicurezza
Quando le macchine da gestire iniziano a diventare molte è consigliabile centralizzare le policy di packet filtering introducendo un firewall perimetrale che permette dall'esterno solo l'accesso ai servizi pubblici.
Tipicamente un simile firewall, che va ridondato, tende a riempirsi di specifiche regole per la gestione dei contenuti da parte di fornitori o redattori esterni, o per l'amministrazione remota da parte di partner vari ecc.
Il rischio diventa quindi quello di appesantire il firewall di frontend con molte regole specifiche.
In ogni caso, anche in presenza di un filtro esterno sui pacchetti in entrata, è opportuno eseguire un hardening minimo sulle macchine dietro il firewall: rimozione dei servizi inutili, aggiornamento dei software sia per i servizi di produzione che per quelli accessori.
Linux firewalling: Introduzione a Iptables |
Overview, gestione, utilizzo di iptables su Linux per packet filtering |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2005-05-14 23:11:57
Netfilter è il framework con cui vengono gestite tutte le operazioni di firewalling, natting e manipolazione di pacchetti nel kernel Linux.
Netfilter viene gestito con il comando iptables con cui si determinano e configurano tutte le regole con cui gestire il traffico di rete.
Breve storia dei firewall Linux
Il codice di firewalling di Linux ha subito diverse modifiche nella storia del kernel.
Nella versione 2.0.x viene usato il sistema ipfwadm che viene sostituito nelle versione 2.2.x dalle ipchains che introducono il concetto di catene di regole (access-list) a cui un pacchetto può essere indirizzato.
Dalla versione 2.4 in poi il kernel si basa sull'infrastruttura netfilter/iptables che permette con semplicità estrema di configurare un firewall di fare packet filtering (stateless, statefull), diversi tipi di NAT (Network Address Translation) e packet mangling (modifica di alcuni flag dei pacchetti trattati).
Il progetto NETFILTER/IPTABLES nasce da Paul "Rusty" Russell e dal Core Team (i quali tutt'ora continuano il lavoro di sviluppo), nel lontano 1999.
Componenti
Il framework netfilter/iptables si può identificare in diversi componenti:
1- la parte riguardante il kernel, ovvero tutto il codice che lavora in kernel space e che con diversi moduli introduce funzionalità base e avanzate.
In quasi tutte le distribuzioni netfilter è installato, in alcune specifiche sulla sicurezza possono essere anche installati moduli aggiuntivi sperimentali.
2- L'interfaccia utente, ovvero sostanzialmente il comando iptables
che permette di impostare regole e gestire il firewall.
Solitamente fornita con un pacchetto chiamato... iptables.
LINK: Home Page del progetto Netfiltering/Iptables - http://www.netfilter.org/
HOWTO: Elenco di How-To ufficiali Netfiltering/Iptables - http://www.netfilter.org/documentation/index.html#HOWTO
LINK: Info, link utili da linuxGuruz.org - http://www.linuxguruz.org/iptables/
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-05-15 13:32:22
E' essenziale capire e familiarizzare con la logica di iptables prima di cimentarsi nella stesura delle policy di un firewall, altrimenti si rischia di non ottenere i risultati voluti o comprometterne la funzionalità.
Logica di tabelle, catene, regole.
Di default iptables lavora su 3 tabelle (tables) (filter, nat, mangle) che prevedono diverse catene (chains) (INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING...) all'interno delle quali esistono elenchi di regole (rules).
Ogni regola identifica pacchetti di rete secondo diversi criteri sulla base di variegati match (tcp, udp, state, pkttype e molti altri, alcuni sperimentali) con le relative opzioni e termina con un target che determina cosa fare del pacchetto matchato (ACCEPT, DROP, REJECT, SNAT, DNAT, LOG...).
Tabella di filter
Quando si usa il comando iptables questa è la tabella di default, implicita.
Prevede 3 catene di default che di fatto corrispondono alle possibili destinazioni del pacchetto rispetto alla macchina che funziona da firewall:
INPUT
Catena in cui passano tutti i pacchetti in entrata dalle interfacce di rete del sistema. Si usa comunemente per permettere o negare l'accesso da IP remoti a porte locali.
OUTPUT:
Considera tutti i pacchetti che sono originati ed escono dal proprio sistema. Si usa per controllare il traffico in uscita, sia per le risposte a pacchetti permessi in INPUT che per nuove connessioni in uscita.
FORWARD:
Riguarda i pacchetti che devono "attraversare" il firewall, avendo IP sorgente e destinazione diversi da quello della macchina su cui gira iptables.
Si usa tipicamente su router o firewall di rete.
Tabella di nat
Questa tabella riguarda alcune alterazioni che si possono fare su un pacchetto, in particolare la variazione degli IP e delle porte sorgenti o di destinazione . Viene richiamata con l'opzione -t nat
e prevede le seguenti catene di default:
PREROUTING
- Catena in cui vengono processati i pacchetti in ingresso, prima che il sistema prenda le decisioni di routing. Si usa tipicamente per fare destination natting usando il target DNAT
.
POSTROUTING
- Catena in cui passano i pacchetti dopo che sono stati routati sulla interfaccia di destinazione. Si usa per modificare l'IP e/o la porta sorgente di un pacchetto, tipicamente usato su default gateway di una rete con funzioni di Port Address Translation (su Linux definito Masquerading). Prevede i target SNAT
e MASQUERADE
.
OUTPUT
- Catena utilizzata per modificare l'IP sorgente di un pacchetto uscito dal sistema stesso.
Tabella di mangle
Si può utilizzare per modificare vari parametri negli header di un pacchetto. Viene richiamata con -t mangle
e prevede le catene di default PREROTING, INPUT, FORWARD, OUTPOUT, POSTROUTING. L'uso più comune è per alterare il TOS di un pacchetto IP. Non ci si ritroverà ad usarla spesso.
Il comando iptables
Iptables è sia il nome dell'infrastruttura a catene con cui si definiscono le policy di firewalling di un sistema basato su netfilter che il comando, utilizzabile da shell, con cui si configura e gestisce il tutto.
La sua sintassi è piuttosto variegata e prevede opzioni e impostazioni anche sulla base dei moduli aggiuntivi supportati e permette di: azzerare le catene esistenti, aggiungere regole, rimuovere regole, impostare le policy di default, creare nuove catene custom, azzerare i contatori ecc.
Comodi comandi ausiliari sono iptables-save
e iptables-restore
che si usano rispettivamente per salvare e ripristinare le configurazioni del firewall.
Le impostazioni sono immediatamente applicate sul sistema fino al momento in cui non si riavvia, per ripristinarle dopo un reboot, è necessario salvare su un file.
Le distribuzioni Linux possono avere file diversi di configurazione e diversi script di avvio, con cui le iptables sono gestite come un servizio, ma la sintassi del comando iptables resta comunque comune.
Attraversamento delle catene
La sequenza con cui vengono processate le varie catene dal Kernel ha questa logica, nel caso si faccia forwarding:
RETE A - MANGLE PREROUTING - NAT PREROUTING - ROUTING - FILTER FORWARD - ROUTING - RETE B
Oppure, per pacchetti in entrata o in uscita:
RETE A - MANGLE PREROUTING - NAT PREROUTING - ROUTING - FILTER INPUT - LOCAL PROCESS - MANGLE OUTPUT - NAT OUTPUT - FILTER OUTPUT - ROUTING - RETE B
I pacchetti attraversano le catene che sono destinati a percorrere, secondo l'ordine delle regole impostate. Se un pacchetto matcha le condizioni definite in una regola, allora segue le indicazioni specificate nel target (ACCEPT, DROP, DNAT) e , in molti casi, interrompe l'attraversamento. Se non matcha nessuna regola di una catena, segue la policy di default impostata per quella catena.
Per questo motivo è fondamentale l'ordine con cui sono inserite le regole in una catena.
Tipo Infobox: COMMANDS - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2005-05-23 14:29:18
Iptables è il comando utilizzato per settare, modificare e cancellare rule riguardanti il packet filtering del kernel linux.
Di seguito verranno riportati le principali opzioni e le sintassi più utilizzate:
Aggiunge una regola alla fine della catena scelta oppure la modifica o cancella:
iptables -[ADC] chain rule-specification [options]
Sostituisce regola o la inserisce all'inizio della catena
iptables -[RI] chain rulenum rule-specification [options]
Visualizza, svuota o azzera i contatori della catena selezionata:
iptables -[LFZ] [chain] [options]
Crea o aggiunge una nuova catena
iptables -[NX] chain
Setta la policy di default della catena
iptables -P chain target [options]
COMANDI
-A, --append
Aggiunge una regola in fondo alla catena
-D, --delete
Cancella una regola
-R, --replace
Esegue il replace di una regola
-I, --insert
Inserisce la regola all'inizio della catena o alla posizione indicata.
-L, --list
Visulizza l'elenco delle regole inserite
-F, --flush
Svuota le catene predefinite
-Z, --zero
Azzera i contatori di ogni catena
-N, --new-chain
Crea una nuova catena custom
-X, --delete-chain
Cancella una catena (creata dall'utente)
-P, --policy
Setta la policy di default per una catena
PARAMETRI
-p ,--protocol [protocol]
Specifica su quale protocollo deve matchare la regola
-s, --source address[/mask], -src
Specifica l'IP sorgente.
-d, --destination address[/mask], -dst
Specifica l'IP destinazione
-j, --jump
Specifica il target a con cui gestire il pacchetto matchato: può essere una catena custom o un target esistente (drop,accept etc..)
-i, --interface
Specifica da quale interfaccia è in entrata un pacchetto. Opzione valida solo per INPUT, FORWARD e PREROUTING.
-o, --out-interface
Specifica l'interfaccia d'uscita di un pacchetti. Opzione valida per FORWARD, OUTPUT e POSTROUTING.
TARGET
DROP
I pacchetti che "matchano" la regola vengono droppati.
ACCEPT
I paccheti che "matchano" la regola vengono fatti passare.
RETURN
Il pacchetto smette di attraversare la catena e passa a quella successiva o segue il comportamente di default
QUEUE
Se il kernel lo supporta il pacchetto passa a livello user-space dove può essere manipolato da programmi vari.
REJECT
Il pacchetto viene rifiutato con un messaggio di notifica al mittente (es: icmp destination unreachable)
LOG
Il pacchetto viene loggato via syslog.
MARK
Il pacchetto viene marcato per essere gestito da programmi in user space.
MASQUERADE
L'IP del pacchetto viene mascherato.
MIRROR
Viene rimandato al mittente un pacchetto speculare a quello ricevuto
REDIRECT
Il pacchetto viene redirezionato ad una porta locale
ALTRE OPZIONI
-v --verbose
Abilita il verbose mode
-n
Abilita la visualizzazione numerica, senza DNS reverse lookup
--linenumbers
Quando viene eseguito il list delle regole viene aggiunto un numero ad ogni regola che corrisponde la posizione della regola nella sua catena.
!
Inverte il significato dell'opzione che lo segue
Tipo Infobox: COMMANDS - Skill Level: 4- ADVANCED - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2002-10-03 18:07:14
Comando su Linux che permette di configurare in run-time e visualizzare alcuni parametri del kernel.
Particolarmente utile per il tuning del sistema, in particolare:
- Tuning dei Parametri della Network
- Tuning dei Parametri della memoria virtuale
- Tuning dei Parametri del filesystem
Per verificare le opzioni:
sysctl [-n] [-e] variable ...
sysctl [-A]
Per modificare le opzioni:
sysctl [-n] [-e] -w variable=values
Per rileggere il file di condfigurazione:
sysctl [-n] [-e] -p [file di configurazione]
-A
Printa in stdout tutti i valori attualmente disponibili
-n
Disabilita il print in stdout del nome della variabile
-e
Ignora eventuali errori nel nome della variabile
-w
Opzione per modificare il settaggio di sysctl
-p
Carica le opzioni di sysctl da un file. Default /etc/sysctl.conf
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2004-04-01 12:13:42
File di configurazione contenente le opzioni del kernel modificabili in run-time.
Di seguito verra' riportato un esempio di questo file con alcune opzioni abilitate di default da RedHat.
E' fondamentale abilitare net.ipv4.ip_forward (forwarding dei pacchetti IP) se il proprio Linux deve fare da firewall/router.
Di fatto vengono modificati i parametri contenuti nel /proc filesystem.
Abilitando (1) ,disabilitando (0), o il Tuning di alcuni parametri del kernel:
Precisamente si possono modificare i valori del kernel in run-time per i seguenti campi
- Virtual memory
- File System
- Network
Ecco il cat del file in configurazione RedHat Standard:
[neo@dido neo]$ cat /etc/sysctl.conf
# Disables packet forwarding
net.ipv4.ip_forward = 0
# Enables source route verification
net.ipv4.conf.default.rp_filter = 1
# Disables the magic-sysrq key
kernel.sysrq = 0
A causa di un bug di alcuni router, inoltre, se l'ECN (Explicit Congestation Notification) è abilitato, ciò che sta dietro a tali router NON sarà raggiungibile.
Il tutto si risolve disabilitando l'ECN nel kernel, intervenendo in /etc/sysctl.conf con una riga tipo:
net.ipv4.tcp_ecn= 0
iptables - Linux natting e packet mangling |
Utilizzo di iptables per natting, masquerading e mangling di pacchetti. |
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2004-06-04 10:47:19
NAT ovvero Network Address Tranlation permette di manipolare un pacchetto IP modificando l'indirizzo IP sorgente o di destinazione.
Ovviamente il dispositivo che esegue il NAT quando riceve il pacchetto di ritorno esegue l'operazione inversa, sulla base di una tabella di natting che si tiene in memoria.
Il Nat viene utilizzato in varie occasioni, dove si ha la necessità ad esempio di redirezionare il traffico su un unico IP, oppure forwardare il traffico con una certa porta di destinazione ad un'altro host oppure su un'altra porta.
Su Linux si usa definire il natting con due modalità specifiche:
SNAT: Source NAT, cioè l'alterazione dell'IP sorgente del primo pacchetto che apre la connessione. Avviene sempre dopo che il pacchetto ha subito il routing (post-routing).
Un esempio di SNAT è il masquerading, con cui tutti gli IP sorgenti di una rete locale vengono convertiti in un unico IP sorgente (del dispositivo che fa masquerading) con cui i pacchetti vengono mandati in rete.
DNAT: Destination NAT, cioè l'alterazione dell'IP di destinazione del primo pacchetto.
A differenza del SNAT il DNAT avviene sempre prima che il pacchetto subisca il routing (pre-routing).
Una forma di DNAT è il port-forwarding e trasparent proxy.
Per quanto riguarda iptables, le catene (chain) da considerare per i vari tipi di NAT sono:
PREROUTING (DNAT, per i pacchetti in arrivo).
Esiste inoltre un "caso speciale" chiamato redirection. E' un DNAT effettuato esclusivamente sull'interfaccia di ingresso del pacchetto. Ovvero si può eseguire un redirect di tuti i pacchetti provenienti su eth0 con destination port 80 e redirezionarli sempre su eth0 ma sulla porta 12345.
OUTPUT (DNAT, per i pacchetti generati della macchina locale)
POSTROUTING (SNAT, per i pacchetti in uscita)
Esempi di NAT:
Port forwarding
iptables -A PREROUTING -t nat -p tcp -d 10.0.0.150 --dport 8080 -j DNAT --to 172.16.1.128:80
Ovvero tutti i pacchetti che hanno destinazione 10.0.0.150 sulla porta 8080vengono riderizionati al'ip 172.16.1.128 alla porta 80.
Source Natting
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 10.0.0.1
Tutti i pacchetti che escono dall'interfaccia eth0, subiscono una variazione dell'ip sorgente in 10.0.0.1
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 10.0.0.1-10.0.0.254
Come sopra, con la differenza che l'ip sorgente può essere alterato sia in 10.0.0.1 o 10.0.0.154
Masquerading
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Tutto ciò che passa in uscita dal proprio modem viene mascherato con l'ip pubblico assegnato dal proprio ISP.
Destination Natting
iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 -j DNAT --to 10.0.0.1:8080
Tutti i pacchetti TCP, arrivati dall'interfaccia eth1 con destinazione porta 80 vengono "dirottati" all'ip 10.0.0.1 alla porta 8080.
LINK: How-to NAT in italiano - http://www.netfilter.org/documentation/HOWTO/it/NAT-HOWTO.txt
Tipo Infobox: DESCRIPTION - Skill Level: 4- ADVANCED - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-05-22 20:39:41
Segue un esempio di script che esegue il masquerading di una rete locale e il destination natting di un server PPTP interno a dei limitati IP pubblici.
Può essere modificato e adattato ai propri scopi.
#!/bin/sh
#
# masquerading.sh - Version 20040531 - Coresis
#
#### DEBUGGING ###
set -x
### FLUSHING CHAIN ### Azzera e pulisce ogni regola esistente
/sbin/iptables -F
/sbin/iptables -F -t nat
/sbin/iptables -X
/sbin/iptables -Z
### DEFAULT CHAIN ### Imposta le policy di default
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT DROP
/sbin/iptables -t nat -P POSTROUTING DROP
/sbin/iptables -t nat -P PREROUTING DROP
### SETTING IPFORWARDING ### Abilita il forwarding di pacchetti non locali - FONDAMENTALE
/bin/echo "1" > /proc/sys/net/ipv4/ip_forward
### DISABLE RESPOND TO BROADCAST ### Non risponde ai ping inviati al browadcast della subnet
/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
### ENABLE BAD ERROR MESSAGE PROTECTION ### Ignora finti messaggi di errore ICMP
/bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
### DISABLE ICMP REDIRECT ACCEPTANCE ### Non accetta pacchetti ICMP di route redirection
/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
### SETTING ANTISPOOFING PROTECTION ###
/bin/echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
### DON'T RESPOND TO BROADCAST PINGS ###
/bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
### Qui vengono definite alcune variabili che successivamente sono usate nelle regole - MODIFICARE SECONDO I PROPRI PARAMETRI
# External Public Interface
EXTIF="eth1"
# Internal Private Interface
INTIF="eth0"
# Host Public IP (su eth1)
EGO="211.121.111.111"
# Internal LAN IP (su eth0)
LANIN="10.0.0.0/24"
# Trusted public network (da cui si permettono collegamenti SSH)
TRUSTED="13.18.151.0/24"
# IP/rete di un utente esterno abilitato a connetterci al server VPN interno
USER="112.56.10.32/28"
# IP Interno del server VPN
VPNSERVER="10.0.0.77"
# RFC IPs Classi di indirizzi dedicate a utilizzi privati o particolari e non routate su Internet
LOOPBACK="127.0.0.0/8"
CLASS_A="10.0.0.0/8"
CLASS_B="172.16.0.0/12"
CLASS_C="192.168.0.0/16"
CLASS_D_MULTICAST="224.0.0.0/4"
CLASS_E_RESERVED_NET="240.0.0.0/5"
# ANTISPOOF Adesso iniziano le regole vere e proprie. Le prime sono generiche regole anti-spoof per IP noti dall'interfaccia pubblica.
/sbin/iptables -A INPUT -i $EXTIF -s $EGO -j DROP
/sbin/iptables -A INPUT -i $EXTIF -s $CLASS_A -j DROP
/sbin/iptables -A INPUT -i $EXTIF -s $CLASS_B -j DROP
/sbin/iptables -A INPUT -i $EXTIF -s $CLASS_C -j DROP
/sbin/iptables -A INPUT -i $EXTIF -s $CLASS_D_MULTICAST -j DROP
/sbin/iptables -A INPUT -i $EXTIF -s $CLASS_E_RESERVED_NET -j DROP
/sbin/iptables -A INPUT -i $EXTIF -d $LOOPBACK -j DROP
# LOOP RULE Permettiamo il traffico di loopback
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT
# LAN IN ACCESS Regole che permettono l'accesso al firewall Linux dagli IP della rete Interna - Potrebbero essere più ristrette e limitarsi all'IP dell'amministratore
/sbin/iptables -A INPUT -i $INTIF -s $LANIN -j ACCEPT
/sbin/iptables -A OUTPUT -o $INTIF -d $LANIN -j ACCEPT
# LAN IN OUT Seguono le regole che gestiscono il masquerading della rete interna
/sbin/iptables -A FORWARD -s $LANIN -d 0/0 -j ACCEPT Forwarda tutti i pacchetti dalla rete interna a qualsiasi destinazione
/sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -d $LANIN -j ACCEPT Permette il forwarding di tutti i pacchetti correlati a comunicazioni esistenti
/sbin/iptables -t nat -A POSTROUTING -o $EXTIF -s $LANIN -j MASQUERADE Maschera gli IP sorgenti Interni con l'IP dell'interfaccia pubblica
# GENERAL Regole generali per permettere all'host locale di collegarsi a IP remoti e ricevere i pacchetti di risposta (Nota: si riferiscono alle attività che vengono fatte direttamente dalla macchina Linux locale e non dagli host che la usano come firewall)
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
# SSH Regole per permettere l'accesso al server SSH locale da un IP esterno fidato precedentemente indicato
/sbin/iptables -A INPUT -s $TRUSTED -p TCP --dport 22 -j ACCEPT
# VPN NATTING Esegue un DNAT di un server VPN che usa pptp (TCP porta 1723) e GRE (IP type 47) e permette l'accesso al server solo da un IP sorgente definito
/sbin/iptables -A FORWARD -s $USER -p TCP --dport 1723 -j ACCEPT
/sbin/iptables -t nat -A PREROUTING -d $EGO -p tcp --dport 1723 -j DNAT --to-dest $VPNSERVER:1723
/sbin/iptables -t nat -A PREROUTING -d $EGO -p 47 -i eth1 -j DNAT --to-dest $VPNSERVER
# LOGGING Log di tutti i pacchetti, esclusi i broadcast, prima di essere droppati dalla regole di default. I logging viene fatto con livello debug per isolarlo da altri log di sistema. Per cui è necessario scrivere in /etc/syslog.conf una riga tipo:
kern.debug /var/log/iptables.log
/sbin/iptables -A INPUT -m pkttype --pkt-type ! broadcast -j LOG --log-level=DEBUG --log-prefix="[INPUT DROP] : "
/sbin/iptables -A OUTPUT -m pkttype --pkt-type ! broadcast -j LOG --log-level=DEBUG --log-prefix="[OUTPUT DROP] : "
SQUID Proxy server |
Installazione e configurazione del proxy server Squid |
Tipo Infobox: PATH - Skill Level: 3- INTERMEDIATE - Autore: Giorgio 'neo' Colombo - Ultimo Aggiornamento: 2005-04-27 11:04:44
Il file di configurazione principale di Squid è squid.conf
, il prefix cambia a seconda del package utilizzato per l'installazione, esempio il prefix del file di configurazione dei sorgenti è /usr/local/etc
mentre per l'rpm di redhat è /etc/squid
.
Il file di configurazione base risulta essere molto verboso e ostico per il numero di parametri configurabili, ma teoricamente si potrebbe commentare tutte le voci e il demone partirebbe con i valori settati a quelli di default.
Di seguito sono riportati le principali opzioni settabili nel file di configurazione con relativa spiegazione:
http_port
Specifica la porta ove squid si metterà in ascolto, come nell'esempio è possibile specificare più porte, La porta di default è 3128
Esempio: http_port 7575 8080
cache_dir
Specifica la directory ove risiede la cache gestita da squid; i valori a seguire risulatano essere, la dimensione della cache in mega (512) e il numero delle sottodirectory di primo livello (16) e secondo (256). Come nel caso di http_port è possibile specificare più entry per lo stesso operatore.
I valori di default sono: 100 16 256.
Esempio: cache_dir /var/cache/ 512 16 256
cache_effective_user , cache_effective_group
Parametro per specificare l'owner dei processi di squid.
Per motivi di sicurezza è bene evitare di utilizzare l'owner di root ma di un utente creato ad hoc.
Di default, se le opzioni sono commentate, l'owner del processo corrisponde a quello dell'utente che ha lanciato il demone.
Esempio:
cache_effective_user squid
cache_effective_group squid
cache_peer
Abilitata questa opzione, squid ha la possibilità di comunicare con altri squid nella stessa network, con una specificata gerarchia, per gestire in modo più funzionale la cache distribuita nei vari nodi.
Esempio: cache_peer proxy.openskills.info parent 3128 3130 default
Il primo campo specifica l'hostname dell'affiliato ovvero l'host con il quale comunicherà per l'interrogazione della cache. Il secondo campo specifica un vero e proprio grado di parentela fra i due host. Il terzo campo specifica la porta http del server destinatario, mentre il quarto valore specifica la porta ICP (UDP) query port, ovvero la porta utilizzata per l'interrogazione della cache remota, l'ultimo e quinto valore specifica le opzioni.
cache_mem
Specifica l'ammontare della shm (shared memory) in mega da dedicare alla cache. Da ricordare che squid di fatto acquisisce tre volte tanto il valore specificato
cache_mgr
Parametro per configurare l'email del "cache manager", visualizzato anche nelle pagine di errore.
acl, http_access, icp_access
L'uso delle acl permette usufruire di uno strumento molto flessibile per il controllo degli accessi alle risorse del proxy. Tipicamente viene utilizzata la regola generale di negare a tutti quanti e di limitare l'accesso ai soli host appartenenti alle proprie network ma è possibile limitare l'accesso per altre discriminanti come l'ora locale e il dominio di destinazione, per il tipo di browser o addirittura per la comunity SNMP.
Per definire le acl occorre differenziare due elementi:
classi : Identificano le regole che gestiscono l'accesso per un gruppo di client con una determinata descriminante. Per esempio per ip o per dominio.
operatori : Gestiscono le regole o le stessi classi per uno specifico protocollo. Esempio: http_access, icp_access and snmp_access
Esempio di classe:acl all src 0.0.0.0/0.0.0.0
Creazione di una acl chiamata "all" che identifica tutti i client (src 0.0.0.0/0.0.0.0)
Esempio di operatore:http_access deny all
Uso dell'operatore http_access per negare l'accesso in modo indiscriminato.
Sintassi acl
acl name type (string|"filename") [string2] [string3] ["filename2"]
La sintassi minima prevede come primo argomento un nome univoco per determinare la acl stessa(name), il tipo della acl come secondo argomento (type) e come terzo argomento la descriminante (string)
Sintassi operatore
operatore allow|deny [!]aclname [& [!]aclname2 ... ]
il primo argomento specifica l'azione ovvero permette (allow) o nega (deny) l'acl che segue. L'acl deve essere specificata con il suo nome e possono essere specificate + acl sulla stessa linea di configurazione.
SOURCE: Official Docs - http://squid-docs.sourceforge.net/latest/html/x495.html
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2007-04-13 15:27:39
E' possibile configurare Squid per autenticare gli utenti che possono usare il proxy usando le credenziali di un dominio Active Directory o di tipo NT4.
L'autenticazione si basa su winbind, il demone fornito con Samba che permette l'autenticazione degli utenti locali di una macchina Linux su un domain controller di un dominio di tipo Active Directory o NT4.
Il servizio winbind deve essere in esecuzione (anche non configurato) e la macchina su cui gira Squid deve aver joinato il dominio.
In /etc/squid/squid.conf
devono essere presenti le seguenti configurazioni:
Settaggi relativi al sistema di autenticazione:
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic
Alternativa che negozia automaticamente la password dell'utente loggato sul dominio
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol= squid-2.5-ntlmssp
Se si vuole permettere accesso solo a utenti del gruppo "navigatori" del dominio "DOMINIO" usare invece questa alternativa:
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --require-membership-of="DOMINIO+navigatori"
Notare che è necessario avere "winbind separator = +
" in smb.conf (il file di configurazione di Samba) se si lascia il separator normale \ non funziona!
Le seguenti righe devono essere invece sempre presenti:
auth_param ntlm children 5
auth_param ntlm max_challenge_reuses 0
auth_param ntlm max_challenge_lifetime 2 minutes
auth_param ntlm use_ntlm_negotiate on
E' poi necessario configurare le acl di Squid per forzare la richiesta di autenticazione (cambiare gli ip della local_network secondo le proprie esigenze):
acl password proxy_auth REQUIRED
acl local_network src 192.168.171.0/24
http_access allow local_network password
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2007-04-13 15:48:18
E' possibile configurare Squid per filtrare tutte le richieste web che vengono eseguite dagli utenti con l'antivirus engine ClamAV.
Uno dei metodi utilizzabili prevede la configurazione di SquidClamAVredirector.
Scaricare SquidClamAVredirector dal sito ufficiale.
Prerequisiti sono Squid, ClamAV, Python e le librerie Python per interfacciarsi con ClamAV: pyclamav disponibili all'indirizzo: http://xael.org/norman/python/pyclamav/ .
Installazione pyclamav (Usare l'ultima versione disponibile)
Scaricare PyClamav dal sito ufficiale
tar -zxvf pyclamav-0.3.2.tar.gz
cd pyclamav-0.3.2
python setup.py build
python setup.py install
Installazione SquidCLamAV Redirector (SCAVR):
Scaricare SCAVR dal sito ufficiale.
tar -zxvf SCAVR.tar.gz
cp SquidClamAV_Redirector.py /usr/local/bin/
chmod +x /usr/local/bin/SquidClamAV_Redirector.py
cp SquidClamAV_Redirector.conf /usr/local/squid/etc/
chown squid /usr/local/squid/etc/SquidClamAV_Redirector.conf
vi /usr/local/squid/etc/SquidClamAV_Redirector.conf
Esempio di SquidClamAV_Redirector.conf
[SquidClamAV]
# restricted = http://virus.jackal-net.at/infected.php?virus=restricted
virusurl = http://10.0.0.178/infected.php
#virusurl = http://virus.jackal-net.at/infected.php
cleancache = 300
ForceProtocol = http or https
MaxRedirection = 99
MaxRequestsize = 2Mb
log_priority = LOG_INFO
log_facility = LOG_LOCAL6
acceptredirects = 300 301 302 303
MIMETypes = all image/bmp image/gif image/jpeg image/png image/tiff text/html
Timeout = 60.0
[Debug]
Infected = true
Clean = true
Error = true
Ignored = true
[Extensions]
pattern = all .jpg .exe .zip .rar .ar .com .bzip .gz
## [Proxy]
### http = http://localhost:3128
[Whitelist]
www.jackal-net.at = 0
Configurazione Squid
In squid.conf
inserire le seguente righe, utilizzando ovviamente i path corretti relativi a dove si è copiato lo script SquidClamAV_Redirector.py (deve essere eseguibile) sul proprio sistema:
redirect_program /usr/local/bin/SquidClamAV_Redirector.py -c /usr/local/etc/squid/SquidClamAV_Redirector.conf
redirect_children 5
redirector_access deny localhost
http_reply_access allow all
NOTA: La direttiva "redirector_access deny localhost" va messa dopo "acl localhost src 127.0.0.1/255.255.255.255" (che già esiste).
LINK: SquidClamAV Redirector - http://www.jackal-net.at/tiki-read_article.php?articleId=1
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: Andrea 'franz' Francesconi - Ultimo Aggiornamento: 2004-07-16 00:31:01
Già discussi e ridiscussi sono i benefici di un proxy all'interno nella infrastruttura di rete, primo fra tutti la gestione centralizzata delle restrizioni ai siti consentiti alla navigazione. La personalizzazione in questo contesto può essere mirata nel dettaglio, inutile dire che la presenza di numerose macchine sotto proxy aumenta proporzionalmente le difficoltà di gestione, favorendo ad esempio la possibilità di abusi da parte di utenti legittimi.
La funzione del Transparent Proxy è quella di intercettare ogni richiesta di un particolare servizio (in questo caso richiesta HTTP) per poi redirigerla a un proxy (Squid) affinchè svolga tutte le funzioni del caso (semplice content filtering piuttosto che caching). Nel dettaglio la funzionalità di intercettare traffico appartiene ai vari packet filtering, Squid assolve eslusivamente i compiti di proxy.
I benefici portati da una implementazione simile sono notevoli: la forzatura a utilizzare il proxy lato client è trasparente per l'utente; l'amministratore è relativamente certo di controllare il traffico HTTP per tutte le workstation che gestisce.
L'analisi viene effettuata su un'unica macchina che assolve entrambi i compiti di packet filtering e proxyserver (opzione sicuramente discutibile).
Si considera la config di Squid:
...
# Forzo il binding di Squid su localhost
http_port 127.0.0.1:3128
...
# Direttive minime per le funzionalità di proxy
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
L'opportuna gestione delle ACL di Squid terminerà la config del proxy, implementando politiche di navigazione per indirizzi ip / subnet ip che daranno origine alla richiesta.
Lato packet filtering si considera la configurazione per pf (OpenBSD):
#/etc/pf.conf
...
rdr on $int_if inet proto tcp from any to any port www -> 127.0.0.1 port 3128
...
e iptables (Linux):
#iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
in entrambi i casi si redirige il traffico HTTP sullo Squid locale.
Osservazioni
Come già accennato risulta sicuramente discutibile la scelta di integrare packet filter e proxy sulla stessa macchina, da valutare in base al contesto di utilizzo della soluzione.
Inoltre, l'attuale configurazione redirige OGNI richiesta HTTP, incurante della sorgente e delle destinazione del traffico (da rivalutare con l'eventualità di webserver all'interno della rete).
Infine, una centralizzazione di questo tipo porta a un "single point of failure" rappresentato dal proxy; anche in questo caso risulta doverosa l'analisi sulla eventuale implementazione di una soluzione ridondata.
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2004-05-31 18:24:30
Tra i molteplici vantaggi di SQUID c'è da considerare il logging delle navigazioni effettuate tramite proxy da parte dei client che lo utilizzano.
Vediamo alcune configurazioni che si possono fare in squid.conf per customizzare il logging in base alle proprie esigenze.
ATTIVAZIONE LOGGING CON LO STILE DI QUELLO DEI WEB SERVER
emulate_httpd_log off/on
Di default SQUID logga con una sua propria modalità e quindi il default di questo parametro di configurazione è impostato ad OFF.
Esempio di logging secondo il formato nativo di Squid:
1084289766.082 410 blasco.intranet TCP_MISS/200 28491 GET http://openskills.info/ - DIRECT/213.198.151.253 text/html
Impostando ad ON il suddetto parametro Squid inizierà a loggare nel seguente modo:
blasco.intranet - - [11/May/2004:17:29:33 +0200] "GET http://openskills.info/modify/modify.php? HTTP/1.0" 200 16486 TCP_MISS:DIRECT
Indubbiamente l'emulazione del logging stile web server rende l'analisi dei log di più facile lettura e risulta utilizzabile da un maggior numero di programmi di analisi e statistiche di traffico.
ATTIVAZIONE LOGGING CON DNS LOOKUP
log_fqdn off/on
Anche per questa configurazione di SQUID il default è OFF e non abilita un reverse lookup per ottenere il come completo di ogni IP che si collega al proxy.
E' sempre consigliabile lasciare il default in quanto la risoluzione dell'hostname da parte di SQUID può introdurre delle latenze e rallentare il proxy, ovviamente in alcuni casi però può essere utile attivare questa opzione.
Ovviamente per ottenere effetto sulle proprie modifiche occorre riavviare il servizio squid.
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: Andrea 'franz' Francesconi - Ultimo Aggiornamento: 2004-04-30 11:11:51
Le ragioni che portano all'utilizzo di un proxy sono molteplici, considerate le numerose funzioni che tale apparato è in grado di soddisfare. Nel dettaglio, il reverse proxy risulta indicato nel caso in cui sia necessario eseguire relay di un client esterno verso un server interno. I vantaggi di una simile implementazione spaziano da motivi prestazionali (riducendo il carico del server) fino a considerazioni che riguardano la security, sia dell'applicazione che del server che la ospita.
La configurazione di esempio sotto riportata simula l'implementazione di un reverse proxy per un server web installato su una diversa macchina.
# Forzo l'ascolto di Squid sulla porta 80
http_port 80
# Definisco una ACL...
acl allowed_hosts src 0.0.0.0/0.0.0.0
# ... e ne autorizzo il traffico sopra definito
http_access allow allowed_hosts
# Definisco l'indirizzo IP del server web interno
httpd_accel_host 192.168.51.67
# Definisco la relativa porta sul quale è in ascolto il server interno
httpd_accel_port 9900
# Le richieste non presenti in cache vengono dirottate sul server interno
httpd_accel_single_host on
# Attivo funzioni di application proxy e caching
httpd_accel_with_proxy on
# Da abilitare nel caso in cui il server interno utilizzi VirtualHost
httpd_accel_uses_host_header off
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Andrea 'franz' Francesconi - Ultimo Aggiornamento: 2004-05-31 18:22:26
Squid contiene funzionalità di proxy "anonimizzante", permettendo di nascondere al sito visitato l'IP dal quale ha origine la richiesta HTTP client.
Le istruzioni da aggiungere al file di configurazione squid.conf
:
# Disabilito il sistema di cache logging
cache_access_log /dev/null
cache_store_log none
cache_log /dev/null
# Eventuali ip loggati vengono forzati a 0.0.0.0
client_netmask 0.0.0.0
# Tutti possono accedere al proxy
http_access allow all
# Forzo il client a non fornire alcuna identità al server richiedente
forwarded_for off
# Disabilito le statistiche sui client che si connettono
client_db off
Le istruzioni sopra riportate permettono la non tracciabilità da parte del server verso il client autore della richiesta HTTP, ma non riguardano la cifratura del traffico tra il client e il server proxy; con uno sniffer potrebbe essere possibile analizzare il traffico, poichè non criptato.
Una comunicazione sicura in questo senso può essere implementata con:
- Squid in modalità SSL (su HTTPS), con cifratura appunto SSL del traffico tra client e proxy server;
- tunnel SSL (con stunnel) tra client e server.
Tipo Infobox: TIPS - Skill Level: 4- ADVANCED - Autore: Roberto 'rpennol' Pennolino - Ultimo Aggiornamento: 2004-04-19 22:35:16
Il Web Proxy Autodiscovery Protocol è un protocollo di livello 7 elaborato da un gruppo di produttori software (Microsoft, RealNetworks, Sun Microsystem ed InkTomi.....) che consente all'utente finale di configurare il proprio browser web in maniera trasparente, ovvero senza fare ricorso ad alcuna configurazione manuale.
Il protocollo WPAD permette ad alcuni browser (quali ad esempio Microsoft Internet Explorer) di autoconfigurare il proxy server tramite un semplice javascript che viene cercato automaticamente all'indirizzo (se esiste) http://wpad[.dominio.it]//wpad.dat
Alcuni grossi Internet Provider (tin.it per esempio) preferiscono indicare agli utenti il percorso del file di autoconfigurazione. Ma in piccole realtà aziendali è preferibile far fare tutto al browser.
Fondamentale è configurare regolarmente il proxy server Squid e poi:
- Modificare il file /etc/mime.types
per specificare il MIME TYPE dei file .dat
- Creare nella document root di APACHE il file wpad.dat
- Creare un alias di tipo “wpad.dominio.it” sul server web su cui abbiamo creato il file wpad.dat
Ma procediamo con ordine.
Innanzitutto apriamo con un editor di testo il file mime.types
presente in /etc ed aggiungiamo la riga:
application/x-ns-proxy-autoconfig pac dat
Creiamo nella document root del server web configurato per rispondere a wpad.dominio.it (generalmente /var/www/html) il file wpad.dat
con un semplice javascript tipo:
function FindProxyForURL( url, host )
{
if( isPlainHostName( host ) || // se nessun dominio viene specificato
dnsDomainIs( host, "intranet.palermo" ) || // se viene richiesto un url del dominio locale indicato
shExpMatch( url, "https*" ) || // se si usano protocolli sicuri
shExpMatch( url, "snews*" ) )
return "DIRECT";|| // Non si usa alcun proxy
else
return "PROXY 192.168.1.1:3128; " + // Altrimenti usare il proxy indicato
"DIRECT";
}
Dove:
192.168.1.1 -> indirizzo ip del proxy server
3128 -> posta di default di ascolto del server proxy SQUID
intranet.palermo -> dominio (in questo caso non esistente nella realtà) locale per il quale non usare il proxy
Editiamo il file relativo agli indirizzi dns per la zona dominio.it inserendo (nel caso di utilizzo di una distribuzione Fedora Core 1 sotto /var/named/chroot) la riga che fa riusolvere wpad.dominio.it con lìIP del server web dove è stato inserito il file wpad.dat:
wpad IN A 192.168.1.10
Rifacciamo partire SQUID, NAMED e HTTPD.
Selezioniamoo in Microsoft Internet Explorer Strumenti -> Opzioni Internet -> Connessioni -> Impostazioni LAN -> Configurazione automatica (rileva impostazioni automaticamente).
In questo modo il browser utilizzerà il proxy in modo trasparente all’utente.
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2004-05-31 18:03:10
All'interno di un'azienda la navigazione spesso viene gestita dal Proxy per svariati motivi:
- Autorizzazione alla navigazione tramite autenticazione degli utenti
- Gestione Access List che permettono di autorizzare/negare la navigazione alle macchine ad esempio in base agli indirizzi IP
- Logging di tutte le richieste fatte dai singoli client che navigano sulla linea internet aziendale
- Risparmio di banda grazie alla gestione da parte del proxy da parte del proxy server
- Possibilità di blocco di diversi indirizzi web.
La scelta del proxy server ricade quasi esclusivamente su Squid per le sue performance, affidabilità e per il fatto che è Open Source e quindi nella visione (distorta) di questo fenomeno da parte dei dirigenti aziendali, gratuito.
Squid può essere configurato per limitare l'accesso o meno a determinati siti web, per fare ciò bisogna utilizzare il TAG url_regex
con cui è possibile indicare i file contenenti la lista delle parole chiave selezionate che non possono essere presenti negli URL richiesti dal client.
Esempio:
acl badlanguage url_regex "/etc/squid/squidblock/badlanguage.txt"
acl entertainment url_regex "/etc/squid/squidblock/entertainment.txt"
acl games url_regex "/etc/squid/squidblock/games.txt"
acl mp3 url_regex "/etc/squid/squidblock/mp3.txt"
acl pirates url_regex "/etc/squid/squidblock/pirates.txt"
acl porno url_regex "/etc/squid/squidblock/porno.txt"
A questo punto basta applicare le ACL che abbiamo appena definito tramite il TAG http_access
come nell'esempio:
http_access deny badlanguage
http_access deny entertainment
http_access deny games
http_access deny mp3
http_access deny pirates
http_access deny porno
Per poter avere una lista aggiornata di siti web da bloccare si segnalano un paio di siti che forniscono e aggiornano i files contenenti i vari domini negati:
http://www.squidblock.com
http://www.squidguard.org
In particolare quest'ultimo permette tramite un semplice script sul server di scaricare gli aggiornamenti che sono veramente molto frequenti.
LINK: SquidGuard - Tool e blacklist per Squid - http://www.squidguard.org
LINK: SquidBlock: Elenco di blacklist di siti da integrare in Squid - http://www.squidblock.com
LINK: Malware Block List (for Squid & SpamAssassin) - http://www.malware.com.br/
LINK: DansGuardian Home Page - http://dansguardian.org/
Tipo Infobox: TIPS - Skill Level: 3- INTERMEDIATE - Autore: lorenzo 'lorenz' urbinati - Ultimo Aggiornamento: 2003-06-30 21:45:28
I parametri da inserire nel file di configurazione di squid per abilitare l'autenticazione base degli utenti non sono molti e i commenti all'interno del file sono molto chiari e specifici.
Se ci si avvale di un'installazione di default di squid non occorre compilare programmi aggiuntivi come consigliato nello squid.conf. Bisogna operare sulla direttiva auth_param. Di norma i valori di default saranno sufficienti e occorrerà in caso si desideri abilitare l'autenticazione base scommentare la riga che riguarda questo tipo.
La riga dovrebbe apparire come segue
#auth_param basic program < uncomment and complete this line >
Quello che occorre è specificare il percorso del programma esterno che si occupa di autenticare gli utenti e il percorso del file delle password.
Per un'autenticazione base il programma che occorre si chiama ncsa_auth e si trova su RedHat9.0 in /usr/lib/squid/
Per il file delle password il percorso è arbitrario e va creato con il comando di Apache htpasswd.
La sua sintassi è la seguente
htpasswd -c [nome del file] [nome dell'utente]
Se non ci si trova nella directory scelta per questo file occorrerà specificare l'intero percorso oltre al nome del file.
Una volta effettuata questa operazione la riga del file squid.conf deve essere modificata come segue:
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squidpasswd
Ora non resta che specificare una acl che abiliti l'autenticazione con l'istruzione proxy_auth.
acl nomeacl proxy_auth REQUIRED
e di seguito permettere l'accesso a questa acl
http_access allow nomeacl
In questo modo all'accesso di un browser al proxy si dovrebbe aprire una finestra che chiede di inserire utente e password.
Questa forma di autenticazione, come detto, è base e i parametri utente e password sono inviati in chiaro; per approfondire e implementare un'altro tipo di autenticazione leggere la documentazione ufficiale di squid. Da notare che si possono specificare più metodi in comune e verranno considerati dal client in ordine di sicurezza dalla più alta a quella base.
LINK: Integrating Squid and Samba3 with NTLM authentication - http://mkeadle.org/?p=13
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Massimo 'maxgrante' Caselli - Ultimo Aggiornamento: 2004-05-31 18:24:15
Il proxy server è uno strumento che permette di condividere tra più client un singolo accesso ad Internet, gestendo una cache delle informazioni precedentemente scaricate che consente di risparmiare banda e velocizzare la navigazione.
SQUID è un software che ci permette di implementare un proxy server sulla nostra rete interna senza grandi difficoltà e con ottimi risultati.
SQUID supporta oltre al protocollo HTTP anche FTP, Gopher, SSL e altri protocolli Internet.
L'installazione più semplice avviene tramite RPM, addirittura in molti casi l'installazione avviene direttamente dall'installazione della nostra distribuzione Linux. Per sapere se Squid è già installato sul nostro sistema è possibile verificarlo con il classico comando:
rpm -q squid
Se squid è già installato procedere con lo scaricamento dell'ultima release stabile per la propria distribuzione linux ed eseguire:
rpm -U squid-2.x.x-xx.i386.rpm
Nel caso non sia già installato eseguire invece il comando:
rpm -iv squid-2.x.x-xx.i386.rpm
A questo punto SQUID sarà installato nel nostro sistema ed avviabile tramite il comando /etc/init.d/squid start
. Il primo avvio potrebbe impiegare un pò di tempo in quanto dovrà settare la cache in /var/spool/squid
. Con il file di configurazione di default il servizio dovrebbe risultare da subito avviabile senza particolari interventi sulla configurazione e restare in ascolto sulla porta di default 3128.
E' probabile che a questo punto sia comunque necessario configurare squid per permettere di essere utilizzato dai client abilitati. Intervenire su /etc/squid/squid.conf
(sempre ben commentato) per il tuning della configurazione.
Traffic monitoring |
Tools per il monitoraggio del traffico IP |
Tipo Infobox: TIPS - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2005-04-28 11:17:49
Breve guida alla configurazione di MRTG su Fedora.
Quanto qui riportato può essere adattato a qualsiasi distribuzione.
Le fasi essenziali per mettere in funzione un sistema di monitoraggio basato su MRTG sono:
- Configurazione di una community (read only) sugli apparati di frete da monitorare
- Installazione di MRTG
- Scelta della directory dove mettere i file (log e graifici) di MRTG. Si consiglia una sottodirectory per ogni host monitorato
- Creazione dei file di configurazione (uno per ogni apparato monitorato) con cfgmaker
- Creazione della pagina di indice per i grafici delle interfacce dell'host, con indexmaker
- Configurazione di Apache per esportare via http la directory dove MRTG salva i grafici
- Schedulazione, tramite cron, dell'esecuzione di mrtg (una per ogni file di configurazione)
Vediamo, velocemente, come procedere su Fedora/RedHat, utilizzando i path e gli standard propri del pacchetto rpm di mrtg per Fedora.
In questo esempio si valuta il monitoraggio di un unico apparato.
Installazione:
yum install mrtg
Elenco dei file installati (non necessario ma sempre interessante):
rpm -ql mrtg
Creazione di un file di configurazione secondo le logiche di Fedora (nell'esempio l'apparato monitorato ha IP 192.168.1.100 e community "prova"):
cfgmaker [email protected] --global "WorkDir: /var/www/mrtg" > /etc/mrtg/mrtg.cfg
Prova di funzionamenteo (non necessaria ma utile). Notare che è necessario modificare la variabile d'ambiente LANG, perchè quella di default su Fedora è in formato Unicode (es: en_US.UTF-8) e crea problemi con vari programmi Perl, tra cui lo stesso MRTG:
export LANG=C
mrtg /etc/mrtg/mrtg.cfg
Creazione di un file html con l'elenco delle interfacce monitorate sulla base del file di configurazione appena creato:
indexmaker /etc/mrtg/mrtg.cfg > /var/www/mrtg/index.html
Configurazione di Apache per permettere l'accesso ai grafici di MRTG da indirizzi esterni a localhost.
vi /etc/httpd/conf.d/mrtg.conf
Modificare Allow from 127.0.0.1 in, per esempio, Allow from 192.168.0.
Riavviare Apache:
/etc/init.d/httpd reload
A questo punto dovrebbe essere possibile visualizzare i grafici di MRTG del nostro server Linux con IP ipotetico 192.168.0.2 all'URL : http://192.168.0.2/mrtg
La schedulazione di mrtg usando il file di configurazione /etc/mrtg/mrtg.cfg è già operativa grazie al file di cron, installato con il pacchetto rpm: /etc/cron.d/mrtg
.
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2003-06-27 00:18:25
Ntop è uno dei più diffusi ed apprezzati programmi di network monitoring. Si basa sulle librerie libcap ed è stato sviluppato per girare su molteplici piattaforme. E' stato sviluppato in Italia e rilasciato sotto licenza GPL.
Ntop è un utility di Traffic Monitoring (e non solo) sviluppata traendo ispirazione dal programma Unix per la visualizzazione dei processi top. Tra le caratteristiche maggiormente volute dagli sviluppatori quella di essere portabile in modo da girare su diverse piattaforme Unix.
Sono disponibili versioni per: Linux, IRIX, Solaris, Sparc, HP-UX, FreeBSD, AIX e MacOSX.
Ntop può utilizzare anche software esterni per i propri compiti come per esempio nmap, lsof o mySql ma è fondamentale la presenza della libreria libpcap utilizzata per l'analisi dei pacchetti.
Le modalità di utilizzo di ntop sono due:
- interactive: visualizza le informazioni tramite la shell in modo simile a top (funzione a breve non più supportata);
- web mode: grazie al web server incorporato è possibile visualizzare le informazioni fornite collegandosi tramite browser all'indirizzo hostname:numero-porta (Es.: http://enigma:3000/ oppure http://192.168.0.2:3000) ;
Le principali funzioni svolte da ntop sono:
- Misurazione del traffico
- Monitoraggio del traffico
- Ottimizzazione e pianificazione della rete
- Individuazione di problemi di sicurezza
Misurazione del traffico
Ntop raccoglie le informazioni osservando il traffico che passa sulla rete e generando statistiche per ogni host monitorato. Ogni pacchetto viene catturato e classificato in base alla coppia sorgente:destinazione.
Le informazioni visualizzate da ntop per ogni host sono le seguenti:
- Dati Inviati/Ricevuti: Traffico totale generato o ricevuto dall'host, classificato in base al protocollo e protocollo IP;
- Utilizzo di banda: Valore attuale, medio e picchi di utilizzo della banda;
- Ip Multicast: Totale traffico Multicast generato o ricevuto dall'host;
- Sessioni TCP: Sessioni TCP stabilite, e relative statistiche di traffico;
- Traffico UDP: Traffico UDP ordinato per porta;
- Servizi TCP/UDP: Elenco dei servizi TCP e UDP utilizzati e degli ultimi cinque host che li hanno utilizzati;
- Distribuzione del traffico: Traffico locale, traffico verso hosts remoti, traffico da hosts remoti;
- Distribuzione del traffico IP: Rapporto tra TCP e UDP;
Le statistiche visualizzate a livello globale sono:
- Distribuzione del traffico: Rapporto tra traffico locale e traffico remoto ;
- Distribuzione pacchetti: Il numero totale di pacchetti ordinati per dimensione, rapporto fra unicast e broadcast e fra traffico IP e traffico non IP;
- Utilizzo della banda: Valore attuale, medio e picchi di utilizzo della banda;
- Distribuzione vari protocolli: Distribuzione del traffico in relazione al protocollo e alle coppie sorgente:destinazione;
- Matrice del traffico interno: Monitoraggio del traffico per ogni coppia di Host;
- Flussi di rete: Flussi di traffico di particolare interesse per l'amministratore;
Monitoraggio del traffico
Il monitoraggio del traffico consiste nel controllare quando la rete presenta un carico eccessivo oppure non sono rispettate le policy stabilite. Ntop è utile per vedere rapidamente una situazione anomala la quale può derivare per esempio da errate configurazioni di networking. Tra i tipi di problemi individuati da ntop abbiamo:
- Uso di indirizzi IP duplicati;
- Identificazione di con schede di rete configurate in modalità "promiscuous mode";
- Errata configurazione di software di rete (ricavata in basi all'analisi dei protocolli);
- Uso non consentito di protocolli;
- Uso improprio di servizi;
- Identificazione di router (Workstation configurate da router e che permettono quindi traffico non consentito);
- Eccessivo utilizzo di banda.
Ottimizzazione e pianificazione della rete
Analizzando i risultati ottenuti da ntop è possibile individuare protocolli inutilmente attivi sulla rete, problemi di routing oppure host che generano un inutile spreco di banda e prendere quindi le dovute azioni al fine di migliorare le performances della rete.
Individuazione di problemi di sicurezza
Sotto il profilo security, ntop è in grado di individuare casi di IP Spoofing, schede di rete in promiscuous mode, attacchi di tipo Denial of Services, Troian Horses su porte note, e portscanning. Una volta individuato un problema di sicurezza sono disponibili diverse opzioni per segnalarlo al network administrator (e-mail, SNMP oppure SMS) oppure porre in essere specifiche azioni al fine di limitare o bloccare l'attacco.
LINK: Home page ntop - http://www.ntop.it/
SOURCE: ntop Documentation - http://www.ntop.it/documentation.html
Tipo Infobox: ETCETERA - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-06-04 10:49:10
Tra gli ambienti per cui è stato sviluppato ntop sono presenti anche i sistemi Windows 95/98/ME/NT/2K/XP.
Mentre le varie versioni Unix sono distribuite free of charge, la versione precompilata completa per Windows è disponibile a pagamento. Gli autori hanno fatto questa scelta in quanto lo sviluppo per questo ambiente comprende i costi per la lincenza del sistema operativo e per il relativo software di sviluppo.
La versione Windows fa comunque parte dello stesso albero sorgente delle versioni Unix ed il codice è liberamente scaricabile. Una versione demo precompilata è disponibile per il download sul sito degli autori, ma con la limitazione alla cattura di 1000 pacchetti. Per usufruire della full version sono possibili due vie: ricompilare i sorgenti togliendo la limitazione oppure registrare la propria versione di ntop per Windows in modo da ottenere quella senza restrizioni.
LINK: ntop Windows Version - http://www.ntop.it/support.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-11-30 16:45:44
MRTG (Multi Router Traffic Grapher) è uno strumento per il traffic monitoring di rete in grado di generare una serie di pagine HTML contenenti la rappresentazione grafica del traffico.
Questo tool, rilasciato sotto licenza GPL, consiste sostanzialmente in due componenti principali: uno script in linguaggio Perl ed un programma scritto in linguaggio C. Lo script Perl, grazie all'ausilio del protocollo SNMP (Simple Network Management Protocol) legge i contatori di traffico dei router, mentre il programma C si occupa di tenere traccia del traffico letto e di generare la rappresentazione grafica in formato PNG visualizzabile successivamente tramite un web browser.
MRTG fa uso di alcune librerie esterne: gd per la grafica, libpng per le immagini PNG e zlib per comprimere le immagini create. Se queste librerie non sono già presenti nel proprio sistema è necessario installarle.
Le caratteristiche principali di MRTG sono:
- Portabilità: E' disponibile per diverse veresioni UNIX ed anche per Windows;
- Perl: Il programma è scritto in Perl ed il codice è liberamente disponibile e modificabile;
- Supporto SNMP: possibilità di monitorare qualsiasi variabile SNMP ed anche SNMPv2;
- Log di lunghezza costante: viene utilizzato un algoritmo che permette di mantenere costante la dimensione dei log;
- Identificazione affidabile interfaccia di rete: MRTG per identificare l'interfaccia di rete di un router puo' utilizzare oltre all'indirizzo IP anche la descrizione oppure l'ethernet address (MAC);
- Performance: le parti critiche del codice sono state scritte in linguaggio C;
- Personalizzazione: le pagine HTML prodotte da MRTG sono completamente personalizzabili;
- Grafica Free: le immagini PNG sono generate dalle librerie open source gd;
- Configurazione automatica: la configurazione è facilitata da alcuni tools forniti a corredo del programma;
- RRDtool: esiste la possibilità di utilizzare RRDtool (creato dallo stesso autore) per generare i grafici;
SOURCE: Home Page MRTG - http://people.ee.ethz.ch/~oetiker/webtools/mrtg/
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-06-04 10:49:26
E' l'eseguibile dell'utilty di traffic monitoring ntop.
Ntop permette di monitorare il traffico di rete in base ad un numero decisamente elevato di opzioni. Di seguito alcune tra le più utilizzate.
La sintassi è:
ntop [opzioni]
@nomefile
: è possibile utilizzare un file, contenente linee vuote o linee di commento (le quali inziano con #), dove inserire tutte le opzioni con cui lanciare ntop. Questa caratteristica puo' essere usata anche in combinazione con opzioni date a linea di comando;
-a <percorso>
: per default ntop non mantiene traccia delle connessioni al suo web server. Tramite questa opzione è possibile specificare il file di log relativo agli accessi. Il formato di logging è simile a quello di Apache Web Server;
-d
: avvia ntop come demone in background senza occupare nessuna finestra di terminale;
-l <nomefile>
: salva i dati sul file specificato in formato leggibile da tcpdump;
-h
: visualizza l'help in linea sulle opzioni disponibili:
-i
: specifica quali interfacce vengono utilizzate da ntop;
-l <nomefile>
: salva i dati sul file specificato in formato pcap;
-m <indirizzo>
: Indica le subnets da consideare locali;
-n
: visualizza l'indirizzo IP anzichè il nome simbolico dell'interfaccia;
-p
: specifica i protocolli TCP/UDP da monitorare;
-u
: indica i privilegi utente con i quali gira ntop, se non specificato viente utilizzato nobody;
-z
: disabilita il tracking delle sessioni TCP;
-r <percorso>
: specifica il tempo in secondi per gli aggiornamenti dei dati;
-V
: stampa la versione di ntop ed esce;
-w <porta>
: avvia il web server incorporato sulla porta specificata (di default viene avviato sulla porta 3000);
-A
: setta la password di amminstratore di ntop ed esce;
-D
: identifica il dominio locale (utile se ntop non riesce ad indentificarlo automaticamente);
-E
: permette a ntop di avvelersi dell'ausilio di tools esterni;
-L <facility>
: utilizza syslog anzichè lo standard output per visualizzare i log;
-M
: mantiene le statistiche separate per ogni interfaccia di rete;
-P <percorso>
: specifica dove si trova il database con le password di ntop;
-W <porta>
: avvia il web server con supporto SSL sulla porta specificata (di default porta 3001)
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2004-06-01 22:32:06
L'installazione di ntop può essere eseguita tramite compilazione dei sorgenti oppure scaricando i pacchetti di precompilati disponibili per la propria distribuzione Linux.
PREREQUISITI
Prereqisito fondamentale prima di installare ntop è la presenza delle librerie libpcap.
INSTALLAZIONE TRAMITE RPM
E' possibile reperire i pacchetti RPM da uno dei molti mirror di SourgeForge.net:
[root@Enigma software]# wget http://switch.dl.sourceforge.net/sourceforge/ntop/ntop-2.2-0.i386.rpm
--22:55:55-- http://switch.dl.sourceforge.net/sourceforge/ntop/ntop-2.2-0.i386.rpm
=> `ntop-2.2-0.i386.rpm'
Resolving switch.dl.sourceforge.net... done.
Connecting to switch.dl.sourceforge.net[195.176.255.8]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3,465,148 [application/x-rpm]
100%[=================================================================================>] 3,465,148 4.18K/s ETA 00:00
23:09:12 (4.18 KB/s) - `ntop-2.2-0.i386.rpm' saved [3465148/3465148]
Il pacchetto RPM di ntop richiede la presenza di rrdtool, librrd.so.0, libcrypto.so.2, libssl.so.2. Solo gli ultimi due file menzionati sono necessari per il programma, mentre i file relativi ad rrd non sono indispensabili almeno che non si decida di utilizzare RRDtool per la generazione dei grafici. Una volta effettuata questa scelta è possibile installare il programma:
[root@Enigma software]# rpm -ivh --nodeps ntop-2.2-0.i386.rpm
Preparing... ########################################### [100%]
1:ntop ########################################### [100%]
In questo caso si è scelto di non utilizzare gli rrdtool e quindi si è utilizzato rpm con l'opzione --nodeps altrimenti l'installazione si sarebbe bloccata per problemi di dipendenze
INSTALLAZIONE TRAMITE COMPILAZIONE DEI SORGENTI
Anche per la versione in sorgente è possibile usufruire di vari mirror:
root@Joker:/software# wget http://switch.dl.sourceforge.net/sourceforge/ntop/ntop-2.2.tgz
--08:04:56-- http://switch.dl.sourceforge.net/sourceforge/ntop/ntop-2.2.tgz
=> `ntop-2.2.tgz'
Resolving switch.dl.sourceforge.net... done.
Connecting to switch.dl.sourceforge.net[195.176.255.8]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2,551,153 [application/x-gzip]
100%[==================================================================================>] 2,551,153 3.57K/s ETA 00:00
08:16:42 (3.57 KB/s) - `ntop-2.2.tgz' saved [2551153/2551153]
Una volta scaricati i sorgenti è necessario scompattarli.
root@Joker:/software# tar -zxvf ntop-2.2.tgz
A questo punto verrano create due directory rispettivamente per le librerie grafiche /ntop-2.2/gdchart0.94c/
e /ntop-2.2/ntop/
per il programma vero e proprio:
root@Joker:/software/ntop-2.2# ls
gdchart0.94c ntop
Per prima cosa è necessario compilare le librerie grafiche:
root@Joker:/software/ntop-2.2# cd gdchart0.94c/
root@Joker:/software/ntop-2.2/gdchart0.94c# ./configure
...
Configurazione delle librerie GD
root@Joker:/software/ntop-2.2/gdchart0.94c# cd gd-1.8.3//libpng-1.2.4
root@Joker:/software/ntop-2.2/gdchart0.94c/gd-1.8.3/libpng-1.2.4# cp scripts/makefile.linux Makefile
root@Joker:/software/ntop-2.2/gdchart0.94c/gd-1.8.3/libpng-1.2.4# make
...
Compilazione delle librerie per la gestione delle immagini in formato PNG
root@Joker:/software/ntop-2.2/gdchart0.94c/gd-1.8.3/libpng-1.2.4# cd ../../zlib-1.1.4/
root@Joker:/software/ntop-2.2/gdchart0.94c/zlib-1.1.4# ./configure
root@Joker:/software/ntop-2.2/gdchart0.94c/zlib-1.1.4# make
...
Compilazione delle librerie zlib per la decompressione PNG
root@Joker:/software/ntop-2.2/gdchart0.94c/zlib-1.1.4# cd ..
root@Joker:/software/ntop-2.2/gdchart0.94c# make
Infine compilazione delle librerie GD
Una volta compilate le librerie di supporto si può passare alla directory ntop per la parte principale del programma:
root@Joker:/software/ntop-2.2# cd ntop
root@Joker:/software/ntop-2.2/ntop# ./configure
Welcome to ntop, Version 2.2
copyright (c) 1998-2003 Luca Deri
Configuration script version v2.2.000-2003-04-14
...
root@Joker:/software/ntop-2.2/ntop# make
...
root@Joker:/software/ntop-2.2/ntop# make install
CONFIGURAZIONE POST INSTALLAZIONE
La prima volta che il programma viene eseguito, deve essere creato l'utente administrator di ntop. Questo può essere fatto grazie all'ausilio dell'opzione -A
:
Ntop viene quindi lanciato con l'opzione -A
:
root@Joker:# ntop -P /usr/share/ntop -u ntop -A
Wait please: ntop is coming up...
18/Jun/2003 09:04:04 Initializing gdbm databases
18/Jun/2003 09:04:04 THREADMGMT: Started thread (1026) for network packet analyser
18/Jun/2003 09:04:04 THREADMGMT: Idle Scan thread (0) started
18/Jun/2003 09:04:04 THREADMGMT: Packet processor thread (1026) started...
18/Jun/2003 09:04:04 THREADMGMT: Started thread (2051) for idle hosts detection
18/Jun/2003 09:04:04 THREADMGMT: Started thread (3076) for DNS address resolution
18/Jun/2003 09:04:04 THREADMGMT: Address resolution thread started...
Please enter the password for the admin user: ntop2003
Please enter the password again: ntop2003
18/Jun/2003 09:05:49 Admin user password has been set
A questo punto ntop è pronto per l'utilizzo. Può essere lanciato da linea di comando all'occorenza oppure dedicare ad esso un macchina per il monitoraggio della rete e lanciarlo tra gli script d'avvio.
Tipo Infobox: DESCRIPTION - Skill Level: 3- INTERMEDIATE - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2008-04-13 15:44:24
MRTG è disponibile in rete sia in formato RPM che sorgente, di seguito la procedura di installazione e la configurazione di base per potere utilizzare questo strumento.
PREREQUISITI
L'utilizzo di MRTG per il monitoring del traffico necessita di avere installati alcuni software sulla propria macchina per poterlo utilizzare. In particolare deve essere presente un interprete Perl con il quale è sono stato scritto gran parte del codice del programma, e le librerie per la creazione e gestione dei grafici, ovvero zlib, libpng e gd. Ultimo requisito è l'esistenza un un agent SNMP sull'apparato da monitorare, in quanto MRTG ricava da esso i dati.
INSTALLAZIONE DA SORGENTI
E' possibile procedere al download dei sorgenti tramite il sito degli autori <a href="http://www.mrtg.org">http://www.mrtg.org:
root@Joker:/software# wget
http://people.ee.ethz.ch/~oetiker/webtools/mrtg/pub/mrtg-2.9.29.tar.gz
--02:44:15 --http://people.ee.ethz.ch/%7Eoetiker/webtools/mrtg/pub/mrtg-2.9.29.tar.gz
=> `mrtg-2.9.29.tar.gz.1'Resolving people.ee.ethz.ch... done.
Connecting to people.ee.ethz.ch[129.132.2.204]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1,026,837 [application/x-tar]
100%[=================================================================================>] 1,026,837
4.32K/s ETA 00:00 02:48:09 (4.32 KB/s) - `mrtg-2.9.29.tar.gz.1' saved [1026837/1026837]
Successivamente si procede alla scompattazione dei sorgenti:
root@Joker:/software# tar xvfz mrtg-2.9.29.tar.gz
mrtg-2.9.29/ANNOUNCE
mrtg-2.9.29/THANKS
mrtg-2.9.29/CHANGES
mrtg-2.9.29/COPYING
...
mrtg-2.9.29/doc/mrtg.html
mrtg-2.9.29/doc/mrtg.pod
mrtg-2.9.29/doc/mrtg.txt
Una volta scompattati i sorgenti e' necessario posizionarsi nella directory appena creata e lanciare direttamente il comando ./configure
o ./configure --help
per le opzioni di configurazione:
homer@Joker:/scambio$ cd mrtg-2.9.29
root@Joker:/software/mrtg-2.9.29# ./configure --prefix=/usr/local/mrtg
checking for gcc... gcc checking for C compiler default output... a.out
checking whether the C compiler works... yes
...
ordering CD from http://people.ee.ethz.ch/~oetiker/wish .... just kidding ;-)
Infine per terminare l'installazione si utilizzano i classici make
e make install
:
root@Joker:/scambio/mrtg-2.9.29# make
gcc -DGFORM_GD=gdImagePng -g -O2 -Wall -Wpointer-arith -Wcast-align -Wmissing-declarations -Wnested-externs -Winline -W -DHAVE_CONFIG_H -c ./src/rateup.c -o bin/rateup.o
In file included from /usr/include/string.h:360,
...
/usr/bin/perl -0777 -p -i~ -e 's@^#!\s*/\S*perl@#! /usr/bin/perl@' ./bin/cfgmaker ./bin/indexmaker ./bin/mrtg
/usr/bin/perl -0777 -p -i~ -e 's@GRAPHFMT="...";@GRAPHFMT="png";@' ./bin/mrtg ./bin/indexmaker
root@Joker:/scambio/mrtg-2.9.29# make install
/bin/sh ./mkinstalldirs /usr/local/mrtg/bin
mkdir /usr/local/mrtg
mkdir /usr/local/mrtg/bin
...
for x in ./doc/*.1; do \
/usr/bin/ginstall -c -m 644 $x /usr/local/mrtg/man/man1; done
INSTALLAZIONE DA RPM
Per quanto riguarda i pacchetti RPM aggiornati e' possibile trovarli sul sito di Henry Gomez <a href="http://ftp.falsehope.com/home/gomez/">http://ftp.falsehope.com/home/gomez/:
[root@Enigma software]# wget http://ftp.falsehope.com/home/gomez/mrtg/mrtg-2.9.22-2.7.2.i386.rpm
--02:35:49-- http://ftp.falsehope.com/home/gomez/mrtg/mrtg-2.9.22-2.7.2.i386.rpm
=> `mrtg-2.9.22-2.7.2.i386.rpm' Resolving ftp.falsehope.com... done.
Connecting to ftp.falsehope.com[12.163.168.5]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1,011,368 [application/x-rpm]
100%[=================================================================================>] 1,011,368 4.87K/s ETA 00:00
02:39:13 (4.87 KB/s) - `mrtg-2.9.22-2.7.2.i386.rpm' saved [1011368/1011368]
In seguito si installa il pacchetto:
[root@Enigma software]# rpm -ivh mrtg-2.9.22-2.7.2.i386.rpm
warning: mrtg-2.9.22-2.7.2.i386.rpm: V3 DSA signature: NOKEY, key ID 307a10a5
Preparing... ########################################### [100%]
1:mrtg ########################################### [100%]
CONFIGURAZIONE
Una volta installato, MRTG deve essere configurato in modo e quindi istruito su quali device di rete deve monitorare. Il file di configurazione e' mrtg.cfg
e puo' essere generato grazie all'ausilio dell'utility cfgmaker fornita con il programma.
root@Joker:/# /usr/local/mrtg-2/bin/cfgmaker \
indica la password SNMP per l'apparato da interrogare
--global "Workdir: /home/homerweb/arnaldotest" \ Workdir indica la directory in cui verrano salvate le pagine HTML generate
--global "options[_]: bits, growright" \ Indica di utilizzare i bit com unita' di misura e che la direzione del grafico e' da sinstra a destra
--output /etc/mrtg.cfg \ Indica il percorso ed il nome del file di configurazione
jkrnet@joker
--base: Get Device Info on jkrnet@joker:
--base: Vendor Id:
--base: Populating confcache
--snpo: confcache jkrnet@joker: Descr lo --> 1
--snpo:confcache jkrnet@joker: Descr eth0 --> 2
--snpo: confcache jkrnet@joker: Ip 127.0.0.1 --> 1
--snpo: confcache jkrnet@joker: Ip 192.168.0.1 --> 2
--snpo: confcache jkrnet@joker: Type 24 --> 1
--snpo: confcache jkrnet@joker: Type 6 --> 2
--snpo: confcache jkrnet@joker: Eth --> 1
--snpo: confcache jkrnet@joker: Eth 00-48-54-6e-e4-a2 --> 2
--base: Get Interface Info
--base: Walking ifIndex
--base: Walking ifType
--base: Walking ifAdminStatus
--base: Walking ifOperStatus
--base: Walking ifSpeed
--base: Writing /etc/mrtg.cfg
Vengono acquisite le informazioni per la configurazione e generato il relativo file
A questo punto MRTG ha tutti i dati necessari per essere avviato.
UTILIZZO DI MRTG
E' possibile utilizzare MRTG in due modi, inserire una entry nel file di configurazione di crontab in modo da eseguirlo ad intervalli regolari, oppure avviarlo tra gli script di avvio come demone.
Per quanto riguarda l'utilizzo con crontab e' possibile inserire una riga di configurazione simile a:
root@Joker:/# crontab -l
...
# CONFIGURAZIONE MRTG
*/5 * * * * /usr/local/mrtg/bin/mrtg /etc/mrtg.cfg --logging /var/log/mrtg.log
Esegue mrtg ogni 5 minuti, utilizzando come configurazione quanto definito in /etc/mrtg.cfg ed
eseguendo il log delle operazioni in /var/log/mrtg.log
Nel caso si voglia invece utilizzare MRTG come demone si deve aggiungere a mrtg.cfg la riga: RunAsDaemon: yes
e richiamare tra gli script d'avvio MRTG.
Una volta creato l'utente mrtg per avviare il programma e' possibile scrivere uno script d'avvio come:
[root@Enigma /]# cat /etc/rc.d/init.d/mrtg
#! /bin/sh
cd /usr/local/mrtg/bin && ./mrtg --user=mrtg-user \
/etc/mrtg.cfg --logging /var/log/mrtg.log
In questo caso mrtg viene avviato con le credenziali dell'utente mrtg-user, leggendo
la configurazione /etc/mrtg.cfg e abilitando il logging
Infine sara' necessario inserire un link in /etc/rc3.d/
come S91mrtg
per avviare MRTG quando il sistema entra nel runlevel 3.
LINK: MRTG Templates Repository - http://www.somix.com/support/mrtg_repository.php
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Arnaldo 'homer' Zitti - Ultimo Aggiornamento: 2005-06-14 10:44:37
Scritto da Alexei Vladishev, e disponibile per diverse piattaforme quali Linux, Solaris, HP-UX, AIX, Free BSD, Open BSD, OS X, e Windows, Zabbix è un tool di network e system monitoring che permette di generare report e grafici, sullo stato di salute di un sistema e notificare eventuali anomalie via mail.
Tra i dati analizzati da Zabbix: carico del processo, numero di processi nel sistema, numero di processi attivi, attività dei dischi, stato della partizione di swap, e della disponibilità di memoria ecc.
Il funzionamento di Zabbix è di tipo client/server. Sulle macchine da monitorare dette client vengono installati degli agent, i quali inviano i dati su una macchina server che si occuperà di memorizzare i valori in un database. E' quindi possibile, definire dei trigger in modo da segnalare al verificarsi di determinate condizioni, al system administrator eventuali anomalie, attraverso mail, oppure avvalendosi di programmi esterni per l'invio di SMS o altri metodi di notifica.
Tra le caratteristiche principali:
- supporto di polling e trapping come metodo di cattura degli eventi di sistema;
- server disponibile per Linux, Solaris, HP-UX, AIX, Free BSD, Open BSD, OS X;
- client nativo disponibile per Linux ,Solaris, HP-UX, AIX, Free BSD, Open BSD, OS X, Windows NT4.0, Windows 2000, Windows 2003, Windows XP;
- monitor senza l'ausilio di agent esterni;
- autenticazione;
- interfaccia web;
- notifica via email;
Zabbix è un software open source, distribuito sotto licenza GPL. Per essere utilizzato necessita di Apache Web Server, PHP, ed un motore database quale MySQL oppure PostgreSQL.
LINK: Zabbix Home Page - http://www.zabbix.com/
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.
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/
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).
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
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
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
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/
Disaster recovery |
Backup e disaster recovery |
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2002-10-28 11:19:08
Per backup si intende un procedimento di salvataggio di files o directory (o addirittura interi filesystem) attraverso il quale e' possibile in caso di danni o altre svariate necessita' ripristinare le condizioni di funzionamento del sistema, da qui si capisce la sua fondamentale importanza.
In caso di mancato backup, la perdita di dati importanti puo essere una vera tragedia e un buon backup può fare la differenza fra un disastro e una scocciatura.
Ci sono svariate procedure e filosofie sul backup ma uno degli aspetti importanti e' che i dati salvatirisiedano in un luogo fisico differente rispetto a quello dei file originali (anche in un diverso supporto nella stessa macchina).
Per il backup di dati si possono utilizzare da floppy-disks (ne bastano 3 per backuppare /etc), fino ad interi raid di harddisks (arrivando cosi a dimensioni di svariati Terabyte). I supporti piu' comuni utilizzati sono floppydisks, Zipdisks, CDR, DVD, tapes e harddisks. La scelta del supporto dipende sia dalla quantita' di dati da backuppare
(a volte si preferisce salvare solo dati essenziali, a volte si opta per il backup di interi filesystem) sia dalla frequenza del backup (che comunque dipende dalla quantita', in quanto e' difficile che giornalmente si effettuino backup di 500Gb).
Generalmente le procedure di backup avvengono quando non ci sono users operanti sul sistema e quando il carico della rete e' basso, cosa che avviene spesso e volentieri la notte.
Fra le svariate utility per il backup nel mondo Unix troviamo Dump e Restore (con nomi diversi fra i vari
OS Unix-based, anche se di poco), comandi molto sofisticati con una semplice interfaccia ed opzioni essenziali che permettono di backuppare e restorare semplicemente (con la possibilita' di scieglierne il livello) interi devices e filesystems, anche da remoto.
Altro comando di rilievo e' cpio, non potente come dump ma con piu' features.
Tools importanti per il backup di filesystems sono AMANDA (performato dall'universita' del Maryland permette di settare un singolo master backup server in grado di backuppare piu hosts), BURT (altra utility, ottimizzata per il backup e restore da nastri) e CD backup Linux (performato per backup e restore automatici creando un CD-Rs bootabile mentre si lavora sul sistema).
Per il backup e' inoltre possibile utilizzare anche comandi di archiviazione (o compressione) come tar, gzip ecc...
Oltre alle opzioni elencate qui sopra vi sono anche un'infinita' di utility commerciali per backup e restore dei dati. Le case produttrici piu' importanti a livello commerciale di software per il backup sono VERITAS Software, FalconStor Software, BakBone Software, Arkeia.
HOWTO: Linux Complete Backup and Recovery HOWTO - http://ldp.openskills.info/HOWTO/Linux-Complete-Backup-and-Recovery-HOWTO/index.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2002-10-28 11:22:01
Rsync e' un comando (ed un protocollo) che permette la copia di file via rete, ottimizzando i tempi di backup e ripristino dei dati.
L'host da backuppare (su cui si devono leggere o scrivere file) deve avere in esecuzione rsync in modalita' server (rsync --daemon
), e deve essere presente il file /etc/rsyncd.conf
dove sono contenute le informazioni relative alla condivisione necessaria per il backup.
Sull'host remoto che deve leggere o scrivere file sulla macchina dove rsync gira come daemon, viene eseguito il comando rsync con una logica simile a quella di cp.
I parametri da settare in /etc/rsyncd.conf
sono:
- [nomecondivisione] e' il nome della condivisione rsync;
- path e' il path locale a cui fa riferimento la condivisione;
- read only e' un opzione che protegge i file dalla scrittura (se settata = yes);
- uid e gid sono l'utente ed il gruppo con cui rsync accede al filesystem;
- host allow rappresenta gli IP da cui e' possibile collegarsi via rsync;
- list e' un opzione che prevede di poter impedire di elencare le condivisioni disponibili sul server rsync (se settata = false);
La prima volta che si esegue un backup da un certo host vengono copiati tutti i files specificati nella condivisione, le altre volte solo quelli modificati dall'ultimo backup.
Per un utilizzo sicuro di rsync (le password non vengono richieste!), e' consigliabile:
- Selezionare accuratamente gli IP degli host che possono accedere al server rsync;
- Consentire esclusivamente ingressi in sola lettura;
- Non utilizzare root come uid e gid ( a meno che non sia necessario per esigenze di backup).
La sintassi del client rsync è:
rsync [opzioni] [host da backuppare]::nomecondivisione/files /[directory host locale]
opzione spesso utile e' -av
, che specifica di copiare i file mantenendo ownership, permessi e in modalita' "directory recursive".
LINK: Sito ufficiale di rsync - http://samba.anu.edu.au/rsync/
Tipo Infobox: COMMANDS - Skill Level: 2- JUNIOR - Autore: Diego 'Eberk' Carobbio - Ultimo Aggiornamento: 2002-10-03 17:02:48
Programma di archiviazione progettato per immagazzinare ed estrarre file da un archivio conosciuto come un tarfile.
Un tarfile può essere fatto su un'unità a nastro magnetico o su un file normale.
tar [opzioni] file1, file2, ... , fileN
-A, --catenate, --concatenate
aggiunge i file ad un archivio
-c, --create
crea un nuovo archivio
--delete
elimina dall'archivio (da non usare sui nastri magnetici!)
-r, --append
aggiunge i file alla fine di un archivio
-t, --list
elenca il contenuto di un archivio
-u, --update
aggiunge solamente i file che sono pi recenti della copia nell'archivio
-x, --extract, --get
estrae i file da un archivio
-f, --file [NOME_HOST:]F
usa il file di archivo o dispostivo F (default /dev/rmt0)
-L, --tape-length N
cambia il nastro dopo aver scritto N*1024 byte
-p, --same-permissions, --preserve-permissions
estrae tutte le informazioni relative ai permessi
-v, --verbose
elenco minuzioso dei file elaborati
-z, --gzip, --ungzip
filtra l'archivio attraverso gzip
LINK: Sito ufficaile di tar - http://www.gnu.org/software/tar/tar.html
Tipo Infobox: DESCRIPTION - Skill Level: 2- JUNIOR - Autore: Alessandro 'al' Franceschi - Ultimo Aggiornamento: 2003-04-07 13:02:00
Il "disastro" per una azienza può avere molte facce e sfumature, ne può colpire parti diverse (gli edifici, le risorse umane, i sistemi informatici, la documentazione cartacea...) e può causare una quantità di danni ingente, fino anche all'annullamento di fatto dell'azienda stessa.
Limitando il campo di analisi alle problematiche di natura informatica e quindi ai sistemi (computer, server, apparati di rete, linee...) che gestiscono i dati e le attività di una azienda, i punti su cui concentrare l'attenzione quando si deve redarre o quantomeno ipotizzare un piano di analisi del rischio e disaster recovery, sono vari:
- Integrità fisica dei sistemi informatici, che può essere messa a repentaglio da calamità naturali (alluvioni, terremoti, fulmini...), cause accidentali (incendi, allagamenti, crollo di un edificio, caduta di un rack o un computer) o cause esterne (furto, rivolte e devastazioni, raptus di follia di personale interno);
- Integrità delle infrastrutture necessarie al funzionamento dei sistemi: elettricità, connettività di rete, eventualmente impianto di condizionamento.
- Integrità dei dati da azioni di cracking, errori umani, virus, guasti hardware ecc.
Le minacce possibili sono molte e disparate e l'analisi dei relativi rischi deve considerare la loro probabilità e il valore dei dati o dei beni da proteggere. E' ovvio che qualsiasi dispositivo e misura di disaster recovery non deve costare più di quanto valgano i beni stessi da proteggere.
E' altrettanto ovvio che nel concepire un piano di disaster recovery (che può essere sia un completo documento di policy e analisi del rischio, redatto internamente o da società specializzate, che una approssimativa analisi, ben più economica e incompleta, dei rischi e delle procedure per gestirle) si devono considerare vari aspetti:
- Costo delle procedure di sicurezza e protezione;
- Efficacie di queste misure in riferimento a diversi tipi di rischio;
- Analisi dei rischi, delle loro probabilità e livello di pericolo;
- Valore dei dati e dei beni da preservare.
- Tempi di ripristino della normale funzionalità, o quantomeno della funzionalità minima indispensabile dei sistemi;
- Costi per il ripristino (oltre ai costi di backup o preparazione al disastro);
- Impatto delle relazioni con i clienti e con il pubblico e metodi per limitarne il danno d'immagine.
A questo proposito si illustrano alcune precauzioni e indicazioni di massima per prepararsi ad un disastro e limitarne o prevenirne i danni. Hanno campi di applicazione e costi diversi, ma riassumono la maggior parte delle procedure e accorgimenti comunemente previsti:
- Backup dei dati. E' la condizione minima indispensabile: tutti i dati importanti vanno backuppati. Il mezzo su cui viene mantenuto il backup dovrebbe essere mantenuto in un lougo ed edificio fisicamente distante, test di ripristino e di verifica dell'integrità dei dati dovrebbero essere svolti regolarmente così come un analisi di quali dati vengono effettivamente copiati e se questi sono tutti i dati da copiare.
- Impianto elettrico a norma, che offra inoltre sufficente protezione da fulmini, con UPS che suppliscano a brevi interruzioni di elettricità ed eventualmente generatori (tipicamente a gasolio) per far fronte a prolungati black-out.
- Impianto anti incendio a norma, in grado possibilmente di individuare ed estinguere automaticamente principi di incendio, possibilmente senza compromettere la funzionalità dei dispositivi elettronici stessi.
- Linee di backup o di emergenza, in grado di subentrare in caso di guasti di varia natura, dal normale down della linea principale, a problemi di scala maggiore, tali per cui ha senso utilizzare per il backup linee di fornitori diversi che si attestino su centrali diverse e, possibilmente, viaggino su tratte locali diverse.
- Piccoli accorgimenti di costo minimo e buon senso per proteggere fisicamente i sistemi informatici: tenere le macchine sollevate da terra per limitare i danni da allagamento; fissarle a rack o altri supporti per evitare cadute accidentali o causate da lievi scosse telluriche; mantenerle in un posto riparato (lontano da finestre che possano rompersi e da luoghi di passaggio o di lavoro fisico); sistemare i cavi vari (alimentazione, rete, video...) in modo tale da evitare che qualcuno rischi di inciamparci e via dicendo.
- Assicurazione sui dispositivi elettronici e i dati, che copra rischi di varia natura e che copra sia i costi dei danni che quelli di ripristino.
- Disponibilità di una sede di backup sia per l'attività delle persone che per un datacenter, in caso di grave o totale distruzione della sede principale. Ovviamente una simile precauzione ha costi molto alti, che possono essere in qualche modo ridimensionati con compromessi di entità variabile.
Fonte: OpenSkills.info | Rilasciato sotto licenza Creative Commons Attribuzione - Non commerciale - Condividi allo stesso modo. |