lunedì 30 agosto 2010

Linux un sistema operativo free software: applicazioni nel campo dei sistemi informativi aziendali.

Grazie alla possibilità di scambio rapido, economico ed efficiente di informazioni dovuto alla diffusione delle reti geografiche di calcolatori (Internet in testa), si diffonde sempre più capillarmente la pratica di utilizzare software di pubblico dominio, cioè ideato e realizzato senza scopo di lucro da privati o istituzioni.

Il fenomeno ha già permeato la comunità degli utenti di Personal Computer con applicazioni varie, ma sta estendendosi fino al software di base, cioè i sistemi operativi. In particolare è molto interessante il sistema operativo LINUX, che è un clone di UNIX, sviluppato da un gruppo di volontari sparsi in tutto il mondo e auto-coordinatisi attraverso la rete Internet, con piene funzionalità in grado di operare praticamente su qualsiasi PC Intel con prestazioni di tutto rispetto ottenute al costo del solo media e senza royalties per gli usi successivi.

Queste caratteristiche lo pongono in ottima posizione per applicazioni varie nel campo dei sistemi informativi aziendali, giacché possono portare ad una significativa riduzione dei costi di acquisto e manutenzione sia del parco hardware che del software, mantenendo livelli di prestazione e funzionalità del tutto in linea con quelle dei sistemi commercialmente disponibili. Inoltre, l'uso di hardware PC consente la riconversione ad applicazioni DOS/Windows del sistema in caso di necessità, riducendo al minimo i rischi dell'iniziativa. Il progetto di ricerca afferisce appunto all'individuazione ed alla verifica delle possibilità di introduzione di sistemi LINUX nella pratica corrente.


Metodi.

Data la larga compatibilità di LINUX con i sistemi PC attualmente in commercio, è assai agevole e di basso costo dotarsi di una piattaforma di caratteristiche adeguate: un PC con processore Intel 80386, 4Mb RAM e circa 100Mb di spazio su disco è sufficiente ad effettuare tutte le attività previste con un costo inferiore ai 3 milioni di Lire.

Il sistema operativo LINUX si ottiene direttamente da Internet mediante accesso ai numerosi ftp-servers esistenti, oppure può essere acquistato per poche decine di dollari su CD-ROM presso diversi distributori.


Data la scarsità di applicazioni sviluppate su questo sistema operativo, una piattaforma LINUX non può essere utilizzata al momento come workstation di produzione, a meno di non effettuare direttamente il porting dell'applicazione stessa: è quindi più proficuo indagare sulla possibilità di inserimento di tale macchina come generico server di rete, per servizi di file storage, backup, stampa e networking.


Si è quindi proceduto in tal senso, implementando un file server con protocollo NFS, un mail server SMTP e POP, un network router locale e remoto, un firewall system per il controllo della sicurezza rispetto ad accessi remoti, un ftp server in modalità anonymous, un NIS server per la gestione coordinata delle risorse di rete locale secondo gli standard TCP-IP ed ISO-OSI.


Risultati teorici e sperimentali.


Le applicazioni di LINUX sono finora state a livello amatoriale o di ricerca a scopo personale: occorre quindi verificare in dettaglio robustezza e funzionalità delle soluzioni implementate.

Data la stretta aderenza di tutto il codice LINUX ai protocolli RFC di Internet, la compatibilità teorica con altri ambienti UNIX è teoricamente assicurata. Inoltre, gran parte del codice sviluppato per lo UNIX BSD in ambiente universitario statunitense è portabile su LINUX mediante semplice ricompilazione. Ciò è assai promettente in vista di possibili incrementi di funzionalità anche di sviluppo autonomo da parte dell'utenza, essendo disponibili gratuitamente tutti gli ambienti di sviluppo necessari.


Dal punto di vista sperimentale si sono ottenuti i seguenti risultati:

  • NFS Server e Client - Piena funzionalità in modalità read/write agendo direttamente attraverso i sistemi operativi. Il throughput dipende fortemente dalle caratteristiche di I/O su disco e RAM del sistema target. Alcuni problemi di compatibilità possono sorgere quando LINUX è acceduto direttamente da applicazioni remote che fanno uso di file locking mediante RPC proprietarie, che non sono a priori supportate: il problema peraltro non si presenta in modalità read-only.
  • Mail server - Essendo SMTP assai stabilizzato nel tempo la sua implementazione è assai robusta. In particolare le funzionalità di address parsing sono più potenti di quelle normalmente disponibili in flavours UNIX ben più blasonati. Alcuni problemi possono verificarsi in fase di fine tuning data la presenza di alcune incongruenze nella locazione dei files di configurazione da parte delle procedure automatiche previste: la documentazione peraltro è corretta e consente un rapido isolamento del problema. POP ha notevole robustezza pur se qualche difficoltà di configurazione in pi&ugrave.
  • Routing - Sono presenti sia i demoni routed che il più moderno named, di cui è consigliato l'uso. Il routing viene effettuato in modo agevole e trasparente anche su rete geografica. Il supporto X.25 come host-based PAD richiede la presenza di schede apposite, non per tutte le quali sono disponibili i drivers: è quindi consigliabile l'uso di X.25 routers esterni, che risultano del tutto trasparenti a LINUX. Qualche problema generale di configurazione TCP-IP a livello di netmask e broadcast address, che peraltro può dipendere dalla rete esistente alla quale ci si collega, è facilmente risolvibile con un po' di buon senso.
  • Firewall - Al momento non sono disponibili su LINUX meccanismi di security a livello C2 (ad es. password shadowing ed ageing). La presenza del sorgente dei programmi che gestiscono il login (getty, agetty, login, passwd) consente peraltro di implementare direttamente tali caratteristiche. Nel caso di un firewall, che gestisce un numero limitato di passwords e protegge gli altri sistemi di rete da accessi indesiderati, il problema risulta minore in quanto la creazione di captive accounts impedisce l'esplorazione del sistema. Altri meccanismi di self- monitoring, basati ad esempio sul controllo degli eseguibili con SUID e GUID e sull'accounting, sono facilmente implementabili.
  • FTP Server - La creazione di un anonymous ftp server è semplice e ben guidata. La security, che pure è generalmente critica in tale modalità, è ben presidiata a patto di non rilassare le protezioni sul file system. È invece scarsa, come del resto nella generalità dei sistemi UNIX commerciali, la documentazione di supporto al system manager per l'attivazione di funzionalità semplici (ad esempio i README di directory, i prompts, ecc.) ma assai utili per la presentazione ed il corretto uso del sistema.
  • NIS Server - L'inserimento di un sistema LINUX in un dominio esistente è quasi banale, data la completa automazione del task. La creazione di un nuovo dominio, invece, richiede maggiore attenzione, seppure del tutto proporzionata alla complessità del problema. Un baco nel meccanismo di gestione delle mappe causa l'append del NIS-passwd al passwd locale, cosa che pur avere pesanti applicazioni in termini di security. L'indagine in corso stabilirà se il problema avviene in fase di configurazione, ed è quindi gestibile in fase preliminare all'uso, oppure durante le normali operazioni.


Discussione dei risultati.

Le funzionalità implementate nel corso del progetto sono quelle normalmente presenti sui sistemi UNIX più diffusi in commercio. I risultati dei tests effettuati hanno dato conforto alle ipotesi di applicazione di LINUX in ambienti operativi aziendali anche di grande complessit&agrave. La funzionalità ed il livello di prestazioni sono ottimi pur se il sistema in test disponeva di limitate risorse.

La robustezza, soprattutto in considerazione del fatto che il sistema è stato sviluppato in piena ``anarchia'', è veramente a tutta prova, tanto che non è stato osservato alcun crash o core dump anche in circostanze di stabilità marginale dell'ambiente e delle applicazioni. Nessun problema è sorto dall'uso di componentistica commerciale non specificamente selezionata, mentre si è verificata l'esistenza di una ``Incompatibility List'' assai dettagliata e tale da evitare acquisti di parti inadatte. I problemi minori osservati nell'interfacciamento con altri sistemi sono aggirabili con un po' di astuzia e quindi resi inoffensivi.

Prospettive e conclusioni.

I costi da sostenere per l'acquisto e l'installazione di un sistema come quello proposto sono relativi in pratica al solo hardware, poiché la distribuzione e la replicazione di LINUX sono completamente libere e quindi ogni attività su di esso è tale da non violare la legge sulla tutela dei diritti d'autore sul software. Si ritiene tuttavia che, almeno nella fase di iniziale diffusione sul mercato, LINUX richieda la presenza all'interno dell'azienda utente di persone competenti in grado di gestirne adeguatamente le fasi di configurazione ed avviamento: pertanto, l'applicazione è al momento accessibile in generale solo ad aziende a contenuto tecnologico medio-alto.

Data la tendenza al ribasso nei costi di acquisizione dell'hardware, l'uso di sistemi LINUX diventa assai competitivo rispetto all'adozione di soluzioni commerciali che, anche se normalmente supportate da hardware di elevate prestazioni, non hanno costi di acquisto paragonabili e comportano ingenti oneri di manutenzione. Pertanto, LINUX è una valida alternativa per applicazioni che richiedano servizi generici a basso costo ed elevata produttività, mentre si affacciano sul mercato le prime applicazioni commerciali basate su questo sistema operativo.


Riepilogo.


Il progetto ha verificato la possibilità di introduzione di PC con sistema operativo di pubblico dominio LINUX nella pratica dei sistemi informativi aziendali. I vantaggi previsti sono principalmente dovuti al basso costo dell'hardware necessario (quello di un comune PC) ed alla possibilità di libero uso, distribuzione, duplicazione e modifica di LINUX, al riparo dai rigori della legge.

Le funzionalità di LINUX sperimentate sono relative all'utilizzo del sistema come server generico di rete, per applicazioni di file e print services, routing, mailing, network management. I test effettuati hanno dato esito complessivamente positivo, dando sostegno alle tesi esposte e validando la tecnologia e le sue possibilità di applicazione. Il prototipo funzionante, ottenuto parzialmente con materiali di recupero ad un costo complessivo di circa Lit. 2.000.000=, è attualmente in fase di test di affidabilità in vista di un utilizzo H24 in ambiente industriale su rete locale Ethernet.

domenica 22 agosto 2010

Installazione e configurazione di un server Linux, seconda parte.

Postfix + Clamav + Courier + Spamassassin + Postgrey

postfix è un server di posta sviluppato tenendo d'occhio la sicurezza. Su una macchina Linux gli utenti di sistema, di default hanno una casella di posta. I diversi servizi associati alla posta elettronica (smtp, pop, imap, ...) controllano e inoltrano le email verso la casella di posta dell'utente. Questa è una configurazione sconsigliabile, benché molo facile da configurare (in pratica bisogna installare il software e poco più), dal momento che per abilitare la posta a un utente bisogna creare un utente di sistema, con ovvie ricadute negative dal punto di vista della sicurezza.


Quindi, in questo articolo proporremo una configurazione "virtuale", nel senso che le caselle di posta saranno delle cosiddette caselle di posta virtuali, slegate dagli utenti del sistema. Le credenziali di autenticazione e altri parametri necessari saranno definiti in un database mysql.


Gli altri programmi associati a questo servizio sono:

  • courier, che fornisce i servizi pop e imap;

  • clamav, l'antivirus;

  • spamassassin e postgrey, per il controllo antispam.


Il sistema proposto avrà quindi due sistemi antispam:

  • inizialmente postgrey rifiuta tutta la posta che arriva per la prima volta al server (dove il criterio per discriminare se accettare la posta o meno è costituito dalla combinazione di host inviante, mittente e destinatario). Il server inviante aspetta un po' e, se è configurato correttamente, riprova ad inviare il messaggio dopo un certo tempo. Quando un messaggio con la combinazione di parametri sopra indicata arriva di nuovo al server, dopo essere stato rifiutato da postgrey, viene lasciato passare, dal momento che il programma considera che il sistema mittente "si comporta bene", secondo le RFC relative a questo tipo di servizi Internet. Questo semplice meccanismo stronca alla radice il 90% dello spam che ci arriverà, dal momento che molti spammer non hanno un vero server di posta e inviano i messaggi con un normale client, per cui i messaggi vengono ricevuti solo una volta;

  • i messaggi che passano il filtro di postgrey vengono passati a un sistema antispam vero e proprio, che controlla il contenuto e altri aspetti del messaggio, dando dei punteggi a un certo numero di parametri, come ad esempio se contiene codice html o certe ricorrenze di parole. Questo sottosistema, costituito fondamentalmente da spamassassin, valuta se lasciare passare o mettere in quarantena il messaggio. Il tutto può essere configurato in modo che l'amministratore del server riceva un messaggio per ognuna delle email fermate da spamassassin.


A questi due sottosistemi si aggiunge anche il controllo che postfix può realizzare sul messaggio in arrivo in base a un certo numero di restrizioni che possono essere impostate. Ad esempio, possiamo scegliere di accettare solo i messaggi che hanno un FQDN valido, oppure controllare se il mittente si trova in qualche blacklist di spammer. Questo controllo viene realizzato prima dell'inoltro del messaggio al sottosistema gestito da postgrey. Questo triplo meccanismo, nella mia esperienza, è enormemente efficiente nella gestione dello spam che arriverà sul nostro server.


L'interfacciamento tra postfix e il sistema antivirus/antispam avviene attraverso un software aggiuntivo, chiamato amavis-new.


  1. Innanzitutto installiamo tutto il software necessario, incluse le librerie che permettono l'interfacciamento di postfix e courier a mysql:

    aptitude install postgrey postfix courier-pop courier-imap courier-authlib courier-authlib-mysql postfix-mysql clamav clamav-daemon razor spamassassin amavisd-new

  2. Impostiamo alcuni parametri di configurazione di postfix, definiti nel file /etc/postfix/main.cf:

    # See /usr/share/postfix/main.cf.dist for a commented, more complete version
    smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)  
     
    # appending .domain is the MUA's job. 
    append_dot_mydomain = no 
     
    # Uncomment the next line to generate "delayed mail" warnings 
    delay_warning_time = 4h 
     
    alias_maps = hash:/etc/aliases
    alias_database = hash:/etc/aliases 
    myorigin = $mydomain 
    mynetworks = 127.0.0.0/8 192.168.0.0/24 
    mailbox_command = procmail -a "$EXTENSION" 
    mailbox_size_limit = 0 
    message_size_limit = 30360000 
    recipient_delimiter = +

    Direttive importanti sono alias_maps e alias_database, che contengono le impostazioni degli alias, usati anche da programmi come mailman (ulteriormente aggiungeremo le direttive per specificare la tabella di mysql dove verranno registrati gli alias virtuali), mynetworks che definisce le reti per le quali i client sono definiti locali (in pratica le reti dalle quali postfix accetterà posta). mailbox_size_limit = 0 indica che la casella di posta è senza limiti.

  3. Abbiamo detto che tutti gli account saranno definiti in un database mysql. Quindi creiamo un database di nome postfix e un utente postfix che sarà l'unico a poter accedere a questo db:

    CREATE DATABASE postfix;
    GRANT ALL ON postfix.* TO postfix@localhost IDENTIFIED BY 'password';

    dopodiché bisogna definire la struttura delle tabelle del db postfix:

    CREATE TABLE `admin` (
      `username` varchar(255) NOT NULL default ",
      `password` varchar(255) NOT NULL default ",
      `created` datetime NOT NULL default '0000-00-00 00:00:00',
      `modified` datetime NOT NULL default '0000-00-00 00:00:00',
      `active` tinyint(1) NOT NULL default '1',
      PRIMARY KEY  (`username`),
      KEY `username` (`username`)
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Virtual Admins'; 
     
    CREATE TABLE `alias` (
      `address` varchar(255) NOT NULL default ",
      `goto` text NOT NULL,
      `domain` varchar(255) NOT NULL default ",
      `created` datetime NOT NULL default '0000-00-00 00:00:00',
      `modified` datetime NOT NULL default '0000-00-00 00:00:00',
      `active` tinyint(1) NOT NULL default '1',
      PRIMARY KEY  (`address`),
      KEY `address` (`address`)
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Virtual Aliases'; 
     
    CREATE TABLE `domain` (
      `domain` varchar(255) NOT NULL default ",
      `description` varchar(255) NOT NULL default ",
      `aliases` int(10) NOT NULL default '0',
      `mailboxes` int(10) NOT NULL default '0',
      `maxquota` int(10) NOT NULL default '0',
      `transport` varchar(255) default NULL,
      `backupmx` tinyint(1) NOT NULL default '0',
      `created` datetime NOT NULL default '0000-00-00 00:00:00',
      `modified` datetime NOT NULL default '0000-00-00 00:00:00',
      `active` tinyint(1) NOT NULL default '1',
      PRIMARY KEY  (`domain`),
      KEY `domain` (`domain`)
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Virtual Domains'; 
     
    CREATE TABLE `domain_admins` (
      `username` varchar(255) NOT NULL default ",
      `domain` varchar(255) NOT NULL default ",
      `created` datetime NOT NULL default '0000-00-00 00:00:00',
      `active` tinyint(1) NOT NULL default '1',
      KEY `username` (`username`)
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Domain Admins'; 
     
    CREATE TABLE `log` (
      `timestamp` datetime NOT NULL default '0000-00-00 00:00:00',
      `username` varchar(255) NOT NULL default ",
      `domain` varchar(255) NOT NULL default ",
      `action` varchar(255) NOT NULL default ",
      `data` varchar(255) NOT NULL default ",
      KEY `timestamp` (`timestamp`)
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Log'; 
     
    CREATE TABLE `mailbox` (
      `username` varchar(255) NOT NULL default ",
      `password` varchar(255) NOT NULL default ",
      `name` varchar(255) NOT NULL default ",
      `maildir` varchar(255) NOT NULL default ",
      `quota` int(10) NOT NULL default '0',
      `domain` varchar(255) NOT NULL default ",
      `created` datetime NOT NULL default '0000-00-00 00:00:00',
      `modified` datetime NOT NULL default '0000-00-00 00:00:00',
      `active` tinyint(1) NOT NULL default '1',
      PRIMARY KEY  (`username`),
      KEY `username` (`username`)
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Virtual Mailboxes'; 
     
    CREATE TABLE `vacation` (
      `email` varchar(255) NOT NULL default ",
      `subject` varchar(255) NOT NULL default ",
      `body` text NOT NULL,
      `cache` text NOT NULL,
      `domain` varchar(255) NOT NULL default ",
      `created` datetime NOT NULL default '0000-00-00 00:00:00',
      `active` tinyint(1) NOT NULL default '1',
      PRIMARY KEY  (`email`),
      KEY `email` (`email`)
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Postfix Admin - Virtual Vacation';

  4. Per la configurazione delle caselle di posta virtuali, usiamo le seguenti direttive in /etc/postfix/main.cf:

    # VIRTUAL MAILBOXES 
    virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf
    virtual_gid_maps = static:105 
    virtual_mailbox_base = /var/mail/virtual/ 
    virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf 
    virtual_mailbox_limit = 0 
    virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf 
    virtual_minimum_uid = 104 
    virtual_transport = virtual 
    virtual_uid_maps = static:104 
     
    # quota support 
    virtual_create_maildirsize = yes 
    virtual_mailbox_extended = yes 
    virtual_mailbox_limit_maps = mysql:/etc/postfix/mysql_virtual_mailbox_limit_maps.cf 
    virtual_mailbox_limit_override = yes 
    virtual_maildir_limit_message = Mi dispiace, la casella di posta dell'utente ha superato il suo limite 
    virtual_overquota_bounce = yes 

    Importanti sono le direttive virtual_uid_maps e virtual_gid_maps, che indicano l'id dell'utente e del gruppo di sistema dell'utente postfix. Questi id si possono trovare in /etc/passwd e /etc/group-.

    Con questa configurazione, il server è pronto per il supporto quote, che però non vedremo in questo articolo per non allungare eccessivamente la trattazione. Il file mysql_virtual_mailbox_limit_maps.cf contiene i riferimenti alla tabella dove vengono registrate eventuali impostazioni per le quote utenti.

    Vediamo i file contenenti la configurazione per l'accesso alle diverse tabelle del db postfix:

    • mysql_virtual_alias_maps.cf

      user = postfix 
      password = <password> 
      hosts = 127.0.0.1 
      dbname = postfix 
      table = alias 
      select_field = goto 
      where_field = address 

    • mysql_virtual_domains_maps.cf

      user = postfix 
      password = <password> 
      hosts = 127.0.0.1 
      dbname = postfix 
      select_field = description 
      table = domain 
      where_field = domain

    • mysql_virtual_mailbox_maps.cf

      user = postfix 
      password = <password>
      hosts = 127.0.0.1 
      dbname = postfix 
      table = mailbox 
      select_field = maildir 
      where_field = username

    • mysql_virtual_mailbox_limit_maps.cf

      user = postfix 
      password = <password>
      hosts = 127.0.0.1 
      dbname = postfix 
      table = mailbox 
      select_field = quota 
      where_field = username

  5. È il momento di applicare alcune restrizioni alla configurazione del server smtp. A questo scopo scriviamo, sempre nel file /etc/postfix/main.cf:

    smtpd_recipient_restrictions =
      permit_mynetworks,
      permit_sasl_authenticated,
      reject_non_fqdn_hostname,
      reject_non_fqdn_sender,
      reject_non_fqdn_recipient,
      reject_unauth_destination,
      reject_unauth_pipelining,
      reject_invalid_hostname,
      check_policy_service inet:127.0.0.1:60000

    che in pratica consente il relay mail ai client appartenenti alle sottoreti definite in mynetworks e in cui gli host mittente e destinatario sono ben formati. L'ultima direttiva (check_policy_service) gira tutto quello che arriva al servizio di rete in ascolto sulla porta 60000, in pratica postgrey, come vedremo più avanti.

    E' possibile specificare altre direttive in smtpd_recipient_restrictions che permettono il controllo del mittente sulle blacklist di spammer, ad esempio:

    smtpd_recipient_restrictions =
      permit_mynetworks,
      permit_sasl_authenticated,
      reject_non_fqdn_hostname,
      reject_non_fqdn_sender,
      reject_non_fqdn_recipient,
      reject_unauth_destination,
      reject_unauth_pipelining,
      reject_invalid_hostname,
      check_policy_service inet:127.0.0.1:60000,
      reject_rbl_client opm.blitzed.org,
      reject_rbl_client list.dsbl.org,
      reject_rbl_client bl.spamcop.net,
      reject_rbl_client sbl-xbl.spamhaus.org 

  6. Una cosa conveniente da fare è girare l'utente root a una delle caselle di posta virtuali valide create (per i compiti amministrativi). A questo scopo si può modificare il file /etc/aliases in modo da avere qualcosa come:

    root: email@dominio

    poi bisogna lanciare il programma newaliases o postalias /etc/aliases per aggiornare la tabella degli alias (file /etc/aliases.db).

  7. Resta da creare la cartella dove sarà immagazzinata tutta la posta in arrivo per le diverse caselle, dando i permessi corretti, come specificato nella configurazione di postfix e courier:

    mkdir /var/mail/virtual
    chown postfix:postfix /var/mail/virtual/
    chmod ug+rwx /var/mail/virtual/
    chmod -s /var/mail/virtual/
    chmod o-rwx /var/mail/virtual/
    /etc/init.d/postfix restart

    Bisogna ricordarsi che, nel caso di domini virtuali, la username per il login sui servizi pop e imap deve essere specificata comprensiva del dominio.

  8. La configurazione di courier (il server pop/imap) è definita, fondamentalmente, nei file /etc/courier/authdaemonrc:

    authmodulelist="authmysql"
    authmodulelistorig="authcustom authcram authuserdb authldap authpgsql authmysql authpam"
    daemons=5
    authdaemonvar=/var/run/courier/authdaemon

    e /etc/courier/authmysqlrc:

    # The server name, userid, and password used to log in.
    MYSQL_SERVER            127.0.0.1
    MYSQL_USERNAME          postfix
    MYSQL_PASSWORD          <password> 
     
    # MYSQL_PORT can be used with MySQL version 3.22 or later to specify a port to
    # connect to.
    MYSQL_PORT              0 
     
    # Leave MYSQL_OPT as 0, unless you know what you're doing.
    MYSQL_OPT               0 
     
    # The name of the MySQL database we will open:
    MYSQL_DATABASE          postfix 
     
    # The name of the table containing your user data.  See README.authmysqlrc
    # for the required fields in this table.
    MYSQL_USER_TABLE        mailbox 
     
    # Either MYSQL_CRYPT_PWFIELD or MYSQL_CLEAR_PWFIELD must be defined.  Both
    # are OK too. crypted passwords go into MYSQL_CRYPT_PWFIELD, cleartext
    # passwords go into MYSQL_CLEAR_PWFIELD.  Cleartext passwords allow
    # CRAM-MD5 authentication to be implemented.
    MYSQL_CRYPT_PWFIELD     password 
     
    # MYSQL_UID_FIELD - contains the numerical userid of the account
    MYSQL_UID_FIELD         104 
     
    # Numerical groupid of the account
    MYSQL_GID_FIELD         105 
     
    # The login id, default is id.  Basically the query is:
    #
    #  SELECT MYSQL_UID_FIELD, MYSQL_GID_FIELD, ... WHERE id='loginid'
    MYSQL_LOGIN_FIELD       username 
     
    MYSQL_HOME_FIELD        '/var/mail/virtual' 
     
    # The user's name (optional)
    MYSQL_NAME_FIELD        name
    MYSQL_MAILDIR_FIELD     maildir 
     
    # MYSQL_AUXOPTIONS_FIELD        CONCAT("disableimap=",disableimap,",disablepop3=",disablepop3,",disablewebmail=",disablewebmail,",sharedgroup=",sharedgroup)

    Oltre alle direttive che specificano i parametri di connessione al server mysql, sono molto importanti MYSQL_UID_FIELD e MYSQL_GID_FIELD, che specificano l'utente postfix e il gruppo di appartenenza tramite il quale si accederà ai servizi di courier, in modo simile a quanto detto relativamente al file main.cf di postfix.
    Finito tutto facciamo ripartire tutti i servizi:

    /etc/init.d/courier-authdaemon restart
    /etc/init.d/courier-pop restart
    /etc/init.d/courier-imap restart

  9. Vediamo adesso l'interfacciamento tra postfix e il sistema antivirus/antispam. La prima cosa è inserire la seguente direttiva nel file /etc/postfix/main.cf:

    content_filter = amavis:[127.0.0.1]:10024

    che come si vede, viene configurato come un servizio di rete in ascolto sulla porta 10024. Nel file /etc/postfix/master.cf, dobbiamo inserire:

    amavis    unix  -       -       n       -       3       smtp -o smtp_data_done_timeout=1200 -o disable_dns_lookups=yes 
    127.0.0.1:10025 inet n -       n       -       -       smtpd -o content_filter

    quindi, amavis ascolta sulla porta 10024, ma poi gira tutto alla porta 10025, dove vengono applicate le direttive specificate in master.cf.

  10. Vediamo adesso la configurazione di amavis. Su una Debian etch, la configurazione è divisa in file multipli, come specificato in /usr/share/doc/amavisd-new/README.Debian:

    • Read-only configuration: /usr/share/amavis/conf.d/

      • 10-debian_scripts: Stuff you'd better not override

      • 20-package: Packaging decisions, override at will

    • Read-write conffiles: /etc/amavis/conf.d/

      • 01-debian: Rarely modified settings

      • 05-domain_id: mydomain autodetection, local_domains config

      • 05-node_id: myhostname autodetection

      • 15-av_scanners: AV scanner interface configuration

      • 15-content_filter_mode: Use this to re-enable spamassassin/av checks

      • 20-debian_defaults: Commonly modified settings

      • 50-user: Place your overrides here, if you want

      If the package detects legacy config files, it renames them adding a ".disabled" extension, and the amavisd-new initscript will refuse to start the service until these files with a ".disabled" extension are removed or renamed. The legacy config files are /etc/amavis.conf and /etc/amavis/amavis.conf.

    Come si vede, la configurazione di amavis è piuttosto complessa e articolata. Seguendo quanto consigliato nel file README.Debian, noi inseriremo le nostre direttive personalizzate in /etc/amavis/conf.d/50-user, che essendo l'ultimo file ad essere letto, sovrascrive tutta la configurazione definita precedentemente dagli altri file di configurazione. Le direttive più importanti in questo file sono:

    # $MYHOME serves as a quick default for some other configuration settings.
    # More refined control is available with each individual setting further down.
    # $MYHOME is not used directly by the program. No trailing slash!
    $MYHOME = '/var/lib/amavis';   # (default is '/var/amavis') 
     
    # $mydomain serves as a quick default for some other configuration settings.
    # More refined control is available with each individual setting further down.
    # $mydomain is never used directly by the program.
    $mydomain = 'dominio';      # (no useful default) 
     
    # Set the user and group to which the daemon will change if started as root
    # (otherwise just keeps the UID unchanged, and these settings have no effect):
    $daemon_user  = 'amavis';       # (no default (undef))
    $daemon_group = 'amavis';       # (no default (undef)) 
     
    # Runtime working directory (cwd), and a place where
    # temporary directories for unpacking mail are created.
    # if you change this, you might want to modify the cleanup()
    # function in /etc/init.d/amavisd-new
    # (no trailing slash, may be a scratch file system)
    $TEMPBASE = $MYHOME;           # (must be set if other config vars use is) 
     
    # Run the daemon in the specified chroot jail if nonempty:
    #$daemon_chroot_dir = $MYHOME;  # (default is undef, meaning: do not chroot)
    $pid_file  = "/var/run/amavis/amavisd.pid";  # (default: "$MYHOME/amavisd.pid")
    $lock_file = "/var/run/amavis/amavisd.lock"; # (default: "$MYHOME/amavisd.lock") 
     
    # POSTFIX, or SENDMAIL in dual-MTA setup, or EXIM V4
    # (set host and port number as required; host can be specified
    # as IP address or DNS name (A or CNAME, but MX is ignored)
    $forward_method = 'smtp:127.0.0.1:10025';  # where to forward checked mail
    $notify_method = $forward_method;          # where to submit notifications 
     
    # Net::Server pre-forking settings
    # You may want $max_servers to match the width of your MTA pipe
    # feeding amavisd, e.g. with Postfix the 'Max procs' field in the
    # master.cf file, like the '2' in the:  smtp-amavis unix - - n - 2 smtp
    $max_servers  =  2;   # number of pre-forked children          (default 2)
    $max_requests = 10;   # retire a child after that many accepts (default 10)
    $child_timeout=5*60;  # abort child if it does not complete each task in n sec
                          # (default: 8*60 seconds) 
     
    # With Postfix (2.0) a quick reminder on what local domains normally are:
    # a union of domains specified in: $mydestination, $virtual_alias_domains,
    # $virtual_mailbox_domains, and $relay_domains.
    @local_domains_acl = ( ".$mydomain" );  # $mydomain and its subdomains 
     
    # SMTP SERVER (INPUT) PROTOCOL SETTINGS (e.g. with Postfix, Exim v4, ...)
    #   (used when MTA is configured to pass mail to amavisd via SMTP or LMTP)
    $inet_socket_port = 10024;        # accept SMTP on this local TCP port 
     
    # SMTP SERVER (INPUT) access control
    # - do not allow free access to the amavisd SMTP port !!!
    #
    # when MTA is at the same host, use the following (one or the other or both):
    $inet_socket_bind = '127.0.0.1';  # limit socket bind to loopback interface
                                      # (default is '127.0.0.1')
    @inet_acl = qw( 127.0.0.1 );      # allow SMTP access only from localhost IP
                                      # (default is qw( 127.0.0.1 ) ) 
     
    # Notifications
    $notify_spam_sender_templ = read_text('/var/lib/amavis/notify_spam_sender.txt'); 
     
    # The following symbolic constants can be used in *destiny settings:
    #
    # D_PASS     mail will pass to recipients, regardless of bad contents;
    #
    # D_DISCARD  mail will not be delivered to its recipients, sender will NOT be
    #            notified. Effectively we lose mail (but will be quarantined
    #            unless disabled). Losing mail is not decent for a mailer,
    #            but might be desired.
    #
    # D_BOUNCE   mail will not be delivered to its recipients, a non-delivery
    #            notification (bounce) will be sent to the sender by amavisd-new;
    #            Exception: bounce (DSN) will not be sent if a virus name matches
    #            $viruses_that_fake_sender_re, or to messages from mailing lists
    #            (Precedence: bulk|list|junk);
    #
    # D_REJECT   mail will not be delivered to its recipients, sender should
    #            preferably get a reject, e.g. SMTP permanent reject response
    #            (e.g. with milter), or non-delivery notification from MTA
    #            (e.g. Postfix). If this is not possible (e.g. different recipients
    #            have different tolerances to bad mail contents and not using LMTP)
    #            amavisd-new sends a bounce by itself (same as D_BOUNCE).
    #
    # Notes:
    #   D_REJECT and D_BOUNCE are similar, the difference is in who is responsible
    #            for informing the sender about non-delivery, and how informative
    #            the notification can be (amavisd-new knows more than MTA);
    #   With D_REJECT, MTA may reject original SMTP, or send DSN (delivery status
    #            notification, colloquially called 'bounce') - depending on MTA;
    #            Best suited for sendmail milter, especially for spam.
    #   With D_BOUNCE, amavisd-new (not MTA) sends DSN (can better explain the
    #            reason for mail non-delivery, but unable to reject the original
    #            SMTP session). Best suited to reporting viruses, and for Postfix
    #            and other dual-MTA setups, which can't reject original client SMTP
    #            session, as the mail has already been enqueued.
    $final_virus_destiny      = D_BOUNCE; # (defaults to D_BOUNCE)
    $final_banned_destiny     = D_BOUNCE;  # (defaults to D_BOUNCE)
    $final_spam_destiny       = D_BOUNCE;  # (defaults to D_REJECT)
    $final_bad_header_destiny = D_BOUNCE;  # (defaults to D_PASS), D_BOUNCE suggested
    $virus_admin = "antivirus\@$mydomain";
    $spam_admin = "antispam\@$mydomain"; 
     
    # whom notification reports are sent from (ENVELOPE SENDER);
    # may be a null reverse path, or a fully qualified address:
    #   (admin and recip sender addresses default to $mailfrom
    #   for compatibility, which in turn defaults to undef (empty) )
    #   If using strings in double quotes, don't forget to quote @, i.e. \@
    $mailfrom_notify_admin     = "antivirus\@$mydomain";
    $mailfrom_notify_recip     = "antispam\@$mydomain";
    $mailfrom_notify_spamadmin = "antispam\@$mydomain"; 
     
    # 'From' HEADER FIELD for sender and admin notifications.
    # This should be a replyable address, see rfc1894. Not to be confused
    # with $mailfrom_notify_sender, which is the envelope return address
    # and should be empty (null reverse path) according to rfc2821.
    #
    # The syntax of the 'From' header field is specified in rfc2822, section
    # '3.4. Address Specification'. Note in particular that display-name must be
    # a quoted-string if it contains any special characters like spaces and dots.
    $hdrfrom_notify_sender = "Antispam <antispam\@$mydomain>"; 
     
    # Location to put infected mail into: (applies to 'local:' quarantine method)
    #   empty for not quarantining, may be a file (mailbox),
    #   or a directory (no trailing slash)
    #   (the default value is undef, meaning no quarantine)
    $QUARANTINEDIR = '/var/lib/amavis/virusmails';
    $virus_quarantine_to  = 'virus-quarantine';    # traditional local quarantine
    $spam_quarantine_to = 'spam-quarantine'; 
     
    # Add X-Virus-Scanned header field to mail?
    $X_HEADER_TAG = 'X-Virus-Scanned';      # (default: undef)
    $X_HEADER_LINE = "by $myversion (Debian) at $mydomain"; 
     
    # a hash lookup table can be read from a file, 
    # one address per line, comments and empty lines are permitted: 
    read_hash(\%whitelist_sender, '/var/lib/amavis/whitelist'); 
    read_hash(\%blacklist_sender, '/var/lib/amavis/blacklist'); 
    read_hash(\%spam_lovers, '/var/lib/amavis/spam_lovers');

    Chiaramente, bisogna definire due caselle virtuali: antivirus@dominio e antispam@dominio, per poter ricevere le notifiche amministrative quando amavis identifica un virus o un messaggio di spam. Le tre direttive finali indicano la posizione della blacklist e whitelist (si rimanda alla documentazione ufficiale per la sintassi utilizzata in questi file). Ho preferito essere prolisso nell'illustrare questa configurazione, in modo da inserire i commenti esplicitativi presenti nello stesso file.

    Il file /var/lib/amavis/notify_spam_sender.txt contiene il template del testo con cui il mittente verrà avvisato che il messaggio non è stato recapitato perché non ha superato il filtro antispam:

    From: AutoSpamChecker <antispam@dominio>
    Subject: **Message you sent blocked by our SPAM filter**
    [? %m |#|In-Reply-To: %m]
    Message-ID: <SS%n@%h> 
     
    Your message to: %R
    has triggered our SpamAssassin SPAM filters and has been rejected. 
    The email you sent with the following subject has NOT BEEN DELIVERED: 
     
    Subject: %j 
     
    Our company uses a set of email filters to help block the delivery of 
    unsolicited commercial email, otherwise known as SPAM. For more 
    information on SPAM, please visit http://spam.abuse.net. 
     
    If you believe that you have received this message in error, please 
    accept our sincere apologies. We ask that you please reply to this 
    email message. When we receive your reply, we will add your email 
    address to our list of approved senders so that in the future 
    we can avoid making this mistake again. Please note that this is a 
    manual process and is only done during business hours. 
     
    The report below will help you determine why your message was flagged 
    as SPAM.   If you continue to have problems, please contact our 
    administrator at abuse@dominio. 
     
    Thank you very much,
    Postmaster 

    SpamAssassin report:
    [%A
    ]\

    dove si suppone che abuse@dominio sia una casella di posta valida.

    Se facciamo un /etc/init.d/amavis restart, possiamo leggere in /var/log/syslog alcune righe relative alla configurazione di amavis che ci danno indicazione dei moduli caricati (decompressori, il modulo per spamassassin, ecc.):

    Jan 12 17:16:46 marte amavis[32333]: Module Archive::Tar 1.30
    Jan 12 17:16:46 marte amavis[32333]: Module Archive::Zip 1.16
    Jan 12 17:16:46 marte amavis[32333]: Module Compress::Zlib 1.42
    Jan 12 17:16:46 marte amavis[32333]: Module Mail::SpamAssassin 3.002003
    Jan 12 17:16:46 marte amavis[32333]: Module Razor2::Client::Version 2.81
    ...

    e se i sottosistemi antivirus e antispam sono funzionanti:

    Jan 12 17:16:46 marte amavis[32333]: Amavis::DB code loaded
    Jan 12 17:16:46 marte amavis[32333]: ANTI-VIRUS code loaded
    Jan 12 17:16:46 marte amavis[32333]: ANTI-SPAM code loaded
    Jan 12 17:16:46 marte amavis[32333]: ANTI-SPAM-SA code loaded
    Jan 12 17:16:46 marte amavis[32333]: Unpackers code loaded
    ...
    Jan 12 17:16:46 marte amavis[32333]: Using internal av scanner code for (primary) Clam Antivirus-clamd
    Jan 12 17:16:46 marte amavis[32333]: Found secondary av scanner Clam Antivirus - clamscan at /usr/bin/clamscan
    Jan 12 17:16:46 marte amavis[32333]: Creating db in /var/lib/amavis/db/; BerkeleyDB 0.31, libdb 4.4

    razor è un sistema distribuito di blacklisting per spammers, e viene usato da spamassassin per realizzare una verifica sul mittente del messaggio, prima dell'analisi effettiva del contenuto. razor verrà implementato e configurato più avanti, come parte del sottosistema relativo a spamassassin.

  11. Vediamo adesso la configurazione di clamav, l'antivirus. C'è un difetto nella configurazione di default quando si usa amavis, ed è che il file di configurazione imposta il proprietario del database come clamav, l'utente antivirus, anziché amavis, che è l'utente che effettivamente deve aver accesso ai file interni di clamav. Quindi, sostituiamo

    DatabaseOwner clamav

    con

    DatabaseOwner amavis

    nel file /etc/clamav/freshclam.conf. Poi cambiamo tutti i permessi dei file di lavoro interessati:

    /etc/init.d/clamav-daemon stop
    /etc/init.d/clamav-freshclam stop
    chown -R amavis:amavis /var/log/clamav
    chown -R amavis:amavis /var/run/clamav
    chown -R amavis:amavis /var/lib/clamav
    sed -i 's/clamav adm/amavis adm/' /etc/logrotate.d/clamav-daemon
    sed -i 's/clamav adm/amavis adm/' /etc/logrotate.d/clamav-freshclam
    sed -i 's/User clamav/User amavis/' /etc/clamav/clamd.conf
    /etc/init.d/clamav-freshclam start
    /etc/init.d/clamav-daemon start

  12. Vediamo adesso la configurazione di spamassassin e razor. La configurazione di spamassassin la si trova in /etc/spamassassin/local.cf:

    # This is the right place to customize your installation of SpamAssassin.
    #
    # See 'perldoc Mail::SpamAssassin::Conf' for details of what can be
    # tweaked.
    #
    ###########################################################################

     
    rewrite_header Subject *****SPAM*****
    report_safe                             1
    required_hits                           5.0
    skip_rbl_checks                         0
    rbl_timeout                             10
    dns_available                           yes
    ok_locales                              all
    score DCC_CHECK                         3.8
    score RAZOR_CHECK                       2.5
    score PYZOR_CHECK                       2.5 
     
    # dcc
    use_dcc 1
    dcc_path /usr/bin/dccproc
    dcc_add_header 1
    dcc_dccifd_path /usr/sbin/dccifd 
     
    #pyzor
    use_pyzor 1
    pyzor_path /usr/bin/pyzor
    pyzor_add_header 1 
     
    #razor
    use_razor2 1
    razor_config /etc/razor/razor-agent.conf 
     
    #bayes
    use_bayes 1
    use_bayes_rules 1
    bayes_auto_learn 1
    bayes_auto_learn_threshold_nonspam      0.1
    bayes_auto_learn_threshold_spam         10.0

    Per completezza, riporto anche la configurazione di dcc e pyzor (altri due sistemi di verifica spammer distribuiti) che ho usato in passato. Per quanto riguarda razor (/etc/razor/razor-agent.conf):

    # See razor-agent.conf (5)
    # Change this to 5 for safer classification of MIME attachments.  This will let more spam through
    logic_method = 4 
     
    # Uncomment the next line for logging via syslog
    #logfile = sys-syslog
    # If you do log to syslog, consider using logrotate
    # (see /usr/share/doc/razor/logcheck.ignore.eg)

    C'è un altro file in /var/lib/amavis/.razor/razor-agent.conf, che però viene autogenerato dallo stesso software:

    #
    # Razor2 config file

    # Autogenerated by Razor-Agents v2.81 
    # Thu Jul 12 11:29:12 2007
    # Non-default values taken from /var/lib/amavis/.razor/razor-agent.conf 

    # see razor-agent.conf(5) man page 
    #
    debuglevel             = 3
    identity               = identity
    ignorelist             = 0
    listfile_catalogue     = servers.catalogue.lst
    listfile_discovery     = servers.discovery.lst
    listfile_nomination    = servers.nomination.lst
    logfile                = razor-agent.log
    logic_method           = 4
    min_cf                 = ac
    razordiscovery         = discovery.spamnet.com
    rediscovery_wait       = 172800
    report_headers         = 1
    turn_off_discovery     = 0
    use_engines            = 4,8
    whitelist              = razor-whitelist

    A questo punto bisogna dire al sistema di far partire spamassassin come servizio all'avvio della macchina. Questa operazione la si fa mettendo ENABLED = 1 nel file /etc/default/spamassassin:

    # /etc/default/spamassassin
    # Duncan Findlay
    # WARNING: please read README.spamd before using.
    # There may be security risks.
    # Change to one to enable spamd
    ENABLED=1 
     
    # Options
    # See man spamd for possible options. The -d option is automatically added.
    # SpamAssassin uses a preforking model, so be careful! You need to
    # make sure -max-children is not set to anything higher than 5,
    # unless you know what you're doing.
    OPTIONS="-create-prefs -max-children 5 -helper-home-dir" 
     
    # Pid file
    # Where should spamd write its PID to file? If you use the -u or
    # -username option above, this needs to be writable by that user.
    # Otherwise, the init script will not be able to shut spamd down.
    PIDFILE="/var/run/spamd.pid" 
     
    # Set nice level of spamd
    #NICE="-nicelevel 15"
    # Cronjob
    # Set to anything but 0 to enable the cron job to automatically update
    # spamassassin's rules on a nightly basis
    CRON=0

    Poi facciamo partire il servizio:

    /etc/init.d/spamassassin start

  13. L'ultimo punto è costituito dal sottosistema postgrey. Abbiamo già visto la direttiva da inserire nella configurazione di postfix al punto 5. La configurazione si trova nel file /etc/default/postgrey:

# postgrey startup options, created for Debian
# (c)2004 Adrian von Bidder <avbidder@fortytwo.ch>
# Distribute and/or modify at will.
# you may want to set
#   -delay=N   how long to greylist, seconds (default: 300)
#   -max-age=N delete old entries after N days (default: 30)
# see also the postgrey(8) manpage
POSTGREY_OPTS="-inet=127.0.0.1:60000" 
 
# the -greylist-text commandline argument can not be easily passed through
# POSTGREY_OPTS when it contains spaces.  So, insert your text here:
#POSTGREY_TEXT="Your customized rejection message here"




giovedì 19 agosto 2010

Installazione e configurazione di un server Linux, prima parte.

I servizi che è possibile attivare all'interno di un moderno server dipartimentale, così come la configurazione dello stesso sistema operativo, impongono al sistemista la realizzazione di un gran numero di operazioni in un ordine logico ben preciso. Il presente articolo aiuta a non dimenticare le "cose da fare" per alcuni servizi importanti all'interno di un server Linux.

Il titolo di questo articolo è molto generico. Tuttavia, è opportuno fare alcune precisazioni. Lo scopo dell'articolo è quello di fornire indicazioni dettagliate che si devono seguire per mettere in piedi servizi importanti all'interno di un server Linux, ma facendo in modo di poter avere tutto "alla mano", senza dover cercare (e perdersi, direi) all'interno dell'imponente massa di documentazione disponibile per questi servizi.


Naturalmente, non c'è niente di nuovo sotto il sole. Tutto quello che leggerete in questo articolo lo si trova in Rete, disponibile liberamente, ma penso che un piccolo compendio che riassuma le più importanti operazioni da realizzare sia utile, anche se mi rendo conto che si tratta di un parere opinabile.


Ritengo che la scelta della distribuzione sia importante ma non essenziale. Comunque, dato che questa scelta può portare a fare delle considerazioni che differiscono da altre distribuzioni, noi ne sceglieremo una in particolare. Anche se io non ne ho provate moltissime, parto dell'idea che "quello che funziona non si cambia" e, visto che l'articolo lo scrivo io, quanto sarà detto farà riferimento esplicitamente a una Debian etch.


Sempre nell'ottica di motivare il più possibile le scelte, che sono comunque in gran misura personali e dipendenti dalla storia e dalla formazione del sistemista, posso dire che apprezzo enormemente la stabilità e robustezza dei server Debian. Inoltre, sono dell'opinione che il sistema di aggiornamenti dei pacchetti sia tra i migliori in circolazione. A differenza delle altre distribuzioni non ho mai avuto problemi nel processo di aggiornamento del software, neppure nel passaggio dalla sarge alla etch, infatti è bastato modificare i sorgenti dei pacchetti e apt si è occupato di aggiornare l'intero sistema. Per quanto riguarda il software di aggiornamento dei pacchetti Debian, noi faremo riferimento a aptitude anziché apt, come consigliato dallo stesso team Debian, e che dovrebbe consentire una gestione più efficiente di alcune dipendenze, oltre a racchiudere nello stesso frontend tutta una serie di pacchetti apt (apt-get, apt-cache, ecc.).


Una buona "ricetta".

Quindi, il risultato di questo articolo sarà una "ricetta". Il concetto di ricetta è noto e comune ad altre categorie professionali. Pensiamo ad esempio ai cuochi oppure ai chimici. Entrambi usano dei protocolli chiamati nel gergo "ricette", che consistono sostanzialmente nell'elencare il tipo, il numero e l'ordine dei passaggi da seguire. La ricetta risparmia lo sforzo di dover ricordare ogni singolo passaggio, evitando quindi di perdere operazioni che potrebbero essere dimenticate, velocizzando enormemente l'intero processo di configurazione. Inoltre ci permette di standardizzare la sequenza di operazioni, utile nel caso l'operatore proponga ai suoi clienti lo stesso sistema.


Naturalmente, quanto detto non significa che le cose non debbano essere capite. Soprattutto perché non c'è modo di risolvere un problema, qualora si presenti, se non si comprende bene il sistema. Ma questo è uno sforzo che si fa le prime volte, dopodiché si può procedere molto più velocemente, senza dover focalizzare l'attenzione ogni volta sul singolo passaggio.


Quanto segue è il risultato di alcune note personali che ho costruito negli ultimi anni su queste problematiche, e che risultano sempre di enorme utilità. Spero che qualcuno di voi, alla fine della lettura, sarà della stessa opinione. Discuterò anche qualche opzione di configurazione che ho fatto fatica a reperire nella documentazione ufficiale, e che ho appreso su alcuni forum grazie all'aiuto di qualche collega.


Cominciamo.


I servizi.

I punti che discuteremo sono i seguenti:

  1. installazione e configurazione minimale del server Debian;

  2. MySQL 5;

  3. Postfix + Clamav + Courier + Spamassassin + Postgrey, con virtualizzazione delle caselle di posta con un database MySQL;

  4. Apache 2 + phpmyadmin + postfixadmin;

  5. Hylafax;

  6. Rsnapshot.

Il sistema.

I sistemi che io metto in piedi sono in genere formati da due dischi identici in RAID1, senza LVM. Preferisco una installazione minimale iniziale partendo da una installazione da rete:

  1. Masterizzare l'immagine ISO netinstall scaricata dal sito ufficiale Debian (http://www.debian.org/).

  2. Installare il sistema, seguendo le indicazioni in RAID1, eventualmente con il supporto LVM. Il programma di installazione Debian consente molto intuitivamente di definire le partizioni dei singoli dischi che verranno "integrate" nei diversi volumi RAID. Ovviamente bisogna prima partizionare ciascun disco.

    Il corretto partizionamento dei dischi è un punto soggetto a controversie, ma noi non ci soffermeremo a discuterlo per non allungare ulteriormente l'articolo. Per un disco da 160 GB (SATA) su un sistema con un 1 GB di RAM, in genere faccio il seguente partizionamento:

    # fdisk /dev/sda

    Disk /dev/sda: 160.0 GB, 160000000000 bytes
    255 heads, 63 sectors/track, 19452 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot Start End Blocks Id System
    /dev/sda1 * 1 122 979933+ fd Linux raid autodetect
    /dev/sda2 123 1338 9767520 fd Linux raid autodetect
    /dev/sda3 1339 1460 979965 fd Linux raid autodetect
    /dev/sda4 1461 19452 144520740 5 Extended
    /dev/sda5 1461 3284 14651248+ fd Linux raid autodetect
    /dev/sda6 3285 19452 129869428+ fd Linux raid autodetect

    La procedura di installazione si occupa per noi di assegnare il corretto id alla partizione; l'asterisco indica la partizione di boot. Io definisco 3 partizioni primarie (sda1 di 1 GB per la partizione di boot, sda2 di 10 GB per la partizione di root e sda3 di 1 GB per la swap, che è anch'essa in RAID) e una partizione estesa (sda4), che poi viene ridefinita in due partizioni logiche (sda5 di 15 GB per /usr e sda6 con il resto della capienza del disco per /var). La scelta di avere anche la swap in RAID1 permette, al prezzo di un rallentamento trascurabile, di avere un sistema completo se uno dei dischi si guasta. La partizione più grande è assegnata a /var dato che su un sistema Debian è qui che si verrà a trovare la maggior parte dei dati (posta, fax, ecc.). Lo stesso partizionamento deve essere fatto sull'altro disco (sdb).

    Fatto il partizionamento, le partizioni sono raggruppate per formare i diversi volumi RAID (definiti sempre comodamente dalla procedura di installazione):

    # cat /proc/mdstat
    Personalities : [raid1]
    md4 : active raid1 sda6[0] sdb6[1]
    129869312 blocks [2/2] [UU]

    md3 : active raid1 sda5[0] sdb5[1]
    14651136 blocks [2/2] [UU]

    md2 : active raid1 sda3[0] sdb3[1]
    979840 blocks [2/2] [UU]

    md1 : active raid1 sda2[0] sdb2[1]
    9767424 blocks [2/2] [UU]

    md0 : active raid1 sda1[0] sdb1[1]
    979840 blocks [2/2] [UU]

    unused devices: <none>

    che alla fine danno luogo al filesystem Linux:

    # cat /etc/fstab
    # /etc/fstab: static file system information.
    #
    # <file system> <mount point> <type> <options> <dump> <pass>
    proc /proc proc defaults 0 0
    /dev/md1 / ext3 defaults,errors=remount-ro 0 1
    /dev/md0 /boot ext3 defaults 0 2
    /dev/md3 /usr ext3 defaults 0 2
    /dev/md4 /var ext3 defaults 0 2
    /dev/md2 none swap sw 0 0

  3. Per gli utenti, oltre al root, è meglio definire un altro utente, diciamo admin, il quale è l'unico a cui si potrà accedere da remoto tramite ssh, per ragioni di sicurezza.

  4. A questo punto è necessario modificare i sorgenti del package manager. Infatti, per qualche strana ragione, dopo l'installazione, il file dove sono definiti i sorgenti contiene una configurazione come se il sistema fosse caricato da CDROM. Quindi editiamo il file /etc/apt/sources.list e inseriamo, se non ci sono, le seguenti righe:

    # cat /etc/apt/sources.list
    deb http://ftp.it.debian.org/debian/ etch main
    deb-src http://ftp.it.debian.org/debian/ etch main

    deb http://security.debian.org/ etch/updates main contrib
    deb-src http://security.debian.org/ etch/updates main contrib

    # Debian volatile
    deb http://volatile.debian.org/debian-volatile etch/volatile main contrib

    che definiscono gli host http da dove il sistema di aggiornamento reperisce i pacchetti. Il server security è importante e contiene frequenti patch di sicurezza. Il server volatile, invece, contiene pacchetti necessari per alcuni programmi che hanno bisogno di frequenti modifiche, tipicamente usato per aggiornare clamav e la definizione dei virus. Tutti e tre i server sono indispensabili per il corretto aggiornamento del sistema.

    La configurazione precedente è valida per un sistema che ha una installazione stable (la versione etch al momento di scrivere questo articolo) della distribuzione Debian. Per le versioni testing o unstable la configurazione sarà in genere differente. Al momento di un cambio nella versione stable, il file sources.list va modificato secondo le specifiche che si troveranno sul sito ufficiale.

  5. Installare il sistema base. I pacchetti addizionali verranno installati in seguito. Questo consente di avere più controllo, a mia opinione, sul software effettivamente caricato sul server.

  6. Aggiornare il file /etc/hosts con il nome corretto della macchina:

    # cat /etc/hosts
    127.0.0.1 localhost
    192.168.x.y server.dominio server

  7. Verificare l'hostname della macchina ed eventualmente settarlo con il comando hostname oppure scrivendo nome e dominio nel file /etc/hostname:

    # cat /etc/hostname
    server.dominio

  8. A questo punto è necessario fare alcune modifiche nel file di configurazione di mdadm, il programma che si occupa della gestione del RAID dal punto di vista amministrativo. In particolare, editiamo il file /etc/mdadm/mdadm.conf e inseriamo o cambiamo le seguenti direttive:

    # automatically tag new arrays as belonging to the local system
    HOMEHOST server.dominio

    # instruct the monitoring daemon where to send mail alerts
    MAILADDR email@dominio

    dove definiamo il nome del server e l'indirizzo di posta al quale verranno inviati eventuali messaggi. Se, ad esempio, il demone che gestisce il RAID verifica un guasto su uno dei dischi, invierà una comunicazione all'indirizzo di posta elettronica indicato in mdadm.conf.

    Salviamo le modifiche e facciamo ripartire il demone RAID:

    /etc/init.d/mdadm restart

  9. Per l'aggiornamento del sistema, creo un piccolo script update_system.sh che lancia in sequenza tutti i comandi necessari:

    #!/bin/sh
    apt-get update
    apt-get -u dist-upgrade
    apt-get clean

    che lancio periodicamente, in genere una volta al mese. C'è un pacchetto Debian per fare la stessa cosa, ma io preferisco lanciare a mano questo script per avere il controllo su eventuali domande e messaggi di avvertimento generati durante il processo di aggiornamento. Dopo l'installazione del sistema, è opportuno lanciare questo script per la prima volta, in modo da aggiornare tutti i pacchetti del sistema all'ultima versione stabile.

  10. È arrivato il momento di installare grub sul mbr di entrambi i dischi. La procedura prevede i seguenti passaggi:

    # grub
    grub> root (hd0,0)
    Filesystem type is ext2fs, partition type 0xfd
    grub> setup (hd0)
    Checking if "/boot/grub/stage1" exists... yes
    Checking if "/boot/grub/stage2" exists... yes
    Checking if "/boot/grub/e2fs_stage1_5" exists... yes
    Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 16 sectors are
    embedded.
    succeeded
    Running "install /boot/grub/stage1 (hd0) (hd0)1+16 p
    (hd0,0)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded
    Done.

    grub> root (hd1,0)
    Filesystem type is ext2fs, partition type 0xfd
    grub> setup (hd1)
    Checking if "/boot/grub/stage1" exists... yes
    Checking if "/boot/grub/stage2" exists... yes
    Checking if "/boot/grub/e2fs_stage1_5" exists... yes
    Running "embed /boot/grub/e2fs_stage1_5 (hd1)"... 16 sectors are
    embedded.
    succeeded
    Running "install /boot/grub/stage1 (hd1) (hd1)1+16 p
    (hd1,0)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded
    Done.
    grub> quit

    In questo modo, se uno dei dischi si guasta, il disco rimanente ha tutte le informazioni per poter far ripartire il sistema e per lavorare normalmente, swap inclusa. L'aggiornamento del mbr di entrambi i dischi è necessario ad ogni cambiamento del kernel.

    Facciamo un reboot.

  11. Installiamo il server ssh:

    aptitude install openssh-server

    Modifichiamo il file /etc/ssh/sshd_config in modo da non permettere il login al root, tramite la direttiva:

    PermitRootLogin no

    e facciamo un restart del servizio:

    /etc/init.d/ssh restart

    Gli accessi ssh al server dovranno essere realizzati accedendo inizialmente con l'utente admin. Questo aumenta la sicurezza del sistema al costo di un doppio passaggio. Naturalmente, non si deve permettere all'utente admin l'esecuzione di comandi come root tramite sudo per non invalidare quanto detto.

  12. Sui server che faccio io, installo anche il dns per fare in modo che sia la macchina a occuparsi dei compiti di risoluzione dei nomi:

    aptitude install bind9

    Facciamo capire al server che sarà lui stesso a occuparsi della risoluzione dei nomi, aggiungendo nel file /etc/resolv.conf:

    search dominio
    nameserver 127.0.0.1

    In genere non installo il pacchetto resolvconf.

    Adesso però bisogna tenere in mente che, a differenza di quando si sceglie di utilizzare il dns del provider, non abbiamo previsto un sistema per aggiornare l'elenco dei root dns, che in genere varierà nel tempo. Il file che contiene questo elenco è definito nel file /etc/bind/named.conf:

    // prime the server with knowledge of the root servers
    zone "." {
    type hint;
    file "/etc/bind/db.root";
    };

    e dove il file db.root contiene qualcosa come:

    ; <<>> DiG 9.3.4-P1.1 <<>> @e.root-servers.net . ns
    ; (1 server found)
    ;; global options: printcmd
    ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10584
    ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14

    ;; QUESTION SECTION:
    ;. IN NS

    ;; ANSWER SECTION:
    . 518400 IN NS L.ROOT-SERVERS.NET.
    . 518400 IN NS J.ROOT-SERVERS.NET.
    . 518400 IN NS I.ROOT-SERVERS.NET.
    . 518400 IN NS D.ROOT-SERVERS.NET.
    . 518400 IN NS M.ROOT-SERVERS.NET.
    . 518400 IN NS C.ROOT-SERVERS.NET.
    . 518400 IN NS G.ROOT-SERVERS.NET.
    . 518400 IN NS H.ROOT-SERVERS.NET.
    . 518400 IN NS E.ROOT-SERVERS.NET.
    . 518400 IN NS F.ROOT-SERVERS.NET.
    . 518400 IN NS K.ROOT-SERVERS.NET.
    . 518400 IN NS B.ROOT-SERVERS.NET.
    . 518400 IN NS A.ROOT-SERVERS.NET.

    ;; ADDITIONAL SECTION:
    A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4
    A.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:ba3e::2:30
    B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201
    C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12
    D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90
    E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10
    F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241
    F.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:2f::f
    G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4
    H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53
    H.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:1::803f:235
    I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17
    J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30
    J.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:c27::2:30

    ;; Query time: 243 msec
    ;; SERVER: 192.203.230.10#53(192.203.230.10)
    ;; WHEN: Mon Dec 1 06:52:02 2008
    ;; MSG SIZE rcvd: 500

    derivante dal lanciare il comando dig senza parametri. Per aggiornare questo file, costruiamo il seguente script:

    #!/bin/sh #
    # Update the nameserver cache information file once per month.
    # This is run automatically by a cron entry.
    #
    # Original by Al Longyear
    # Updated for BIND 8 by Nicolai Langfeldt
    # Miscelanious error-conditions reported by David A. Ranch
    # Ping test suggested by Martin Foster
    # bind up-test suggested by Erik Bryer.
    #
    (

    PATH=/sbin:/usr/sbin:/bin:/usr/bin:
    export PATH
    # NOTE: /etc/bind must be writable only by trusted users or this script
    # will cause root compromise/denial of service opportunities.
    cd /etc/bind 2>/dev/null || {
    echo "Subject: Cannot cd to /etc/bind, error $?"
    echo
    echo "The subject says it all"
    exit 1
    }

    dig @e.root-servers.net . ns > db.root.new 2> errors

    case `cat db.root.new` in
    *NOERROR*)
    # It worked
    :;;
    *)
    echo "Subject: The db.root file update has FAILED."
    echo echo "The db.root update has failed"
    echo "This is the dig output reported:"
    echo cat db.root.new errors
    exit 1
    ;;
    esac

    # echo "Subject: The db.root file has been updated"
    echo
    echo "The db.root file has been updated to contain the following information:"
    echo
    cat db.root.new

    chown root:root db.root.new
    chmod 444 db.root.new
    rm -fv db.root.old errors
    mv -v db.root db.root.old
    mv -v db.root.new db.root

    /etc/init.d/bind9 restart
    echo
    echo "The nameserver has been restarted to ensure that the update is complete."
    echo "The previous db.root file is now called /etc/bind/db.root.old."
    ) 2>&1 | mail -s 'The db.root file has been updated' email@dominio
    exit 0

    Basta mettere questo script nella cartella /etc/cron.monthly perché venga eseguito una volta al mese. Se qualche cosa va storto, possiamo sempre recuperare il file di backup /etc/bind/db.root.old.

  13. webmin è un programma utile per realizzare certi compiti di amministrazione. La etch non lo riporta più come pacchetto ufficiale, per cui bisogna scaricarlo e installarlo separatamente (c'è un apposito pacchetto .deb nel sito ufficiale del programma). webmin funziona come servizio a sé attraverso la porta 10000, nella configurazione di default. Per ragioni di sicurezza, imposto l'eventuale firewall o router a valle del server con la porta 10000 chiusa, in modo da impedire l'accesso dall'esterno. Il collegamento avviene attraverso vpn.

  14. Installo apache, nella versione 2 e con alcune dipendenze, che poi sarà necessario per molti servizi che andremo a configurare più avanti:

    aptitude install apache2 libnet-ssleay-perl openssl libauthen-pam-perl libio-pty-perl libmd5-perl

  15. Ci rimane qualche cosetta da fare. In primo luogo, accertarci che il sistema aggiorni l'ora periodicamente. A questo scopo, installiamo un client ntp:

    aptitude install ntpdate

    e scheduliamo l'aggiornamento di data e ora all'avvio del server e una volta al giorno. Io in genere lo faccio attraverso il crontab del root, inserendo le righe:

    @reboot /usr/sbin/ntpdate ntp1.ien.it
    @daily /usr/sbin/ntpdate ntp1.ien.it

  16. Per ultimo, cambio lo strip rotate, e cioè il numero massimo di periodi che verranno conservati per i file di log da logrotate. Io in genere utilizzo una periodicità settimanale e conservo 52 periodi, equivalenti a un anno:

# cat /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 52 weeks worth of backlogs
rotate 52

MySQL.

mysql è il database server che verrà utilizzato da tanti altri servizi, ad esempio dal server di posta postfix per la virtualizzazione delle caselle di posta. È un server affidabile e leggero. La configurazione prevede i seguenti passaggi:

  1. aptitude install mysql-server-5.0

    che installa anche tutta una serie di dipendenze associate.

  2. Cambiare la password di root per mysql:

    mysqladmin -u root password <new password>

  3. Per dare accesso da remoto oltre a localhost al server mysql, seguire la seguente procedura:

    • commentare la riga bind-address = 127.0.0.1 in /etc/mysql/my.cnf;

    • entrare nella console di mysql con mysql -u root -p;

    • inserire la query:

      GRANT ALL ON *.* TO root@w.x.y.z IDENTIFIED BY 'password';

      cambiando l'ip w.x.y.z e la password password;

    • /etc/init.d/mysql restart

    • provare da remoto a collegarsi con:

      mysql -h w.x.y.z -u root -p

  4. Alcuni programmi hanno bisogno della compatibilità password con la versione 4 di mysql. Per settare la compatibilità per un utente mioutente password miapassword, inserire dalla console del programma:

UPDATE mysql.user SET PASSWORD = old_password( 'miapassword' ) WHERE User = 'mioutente'.

fonte: Pluto



martedì 17 agosto 2010

Come rendere più sicura la LinuxBox: idee e qualche piccolo accorgimento.

Molti utenti linux newbie, ma anche utenti che non sono più alle prime armi, spesso danno poca importanza alla sicurezza di una LinuxBox, ritenendo Linux un sistema sicuro per antonomasia.

Che Linux sia un sistema sicuro è fuori da ogni dubbio, ma non è il più sicuro e soprattutto non lo è se non si seguono alcuni accorgimenti.

Prima di passare ad una serie di spiegazioni, ricordate che :

Ogni cosa che si installa e non si usa potrebbe essere fonte di exploit.

Ogni servizio che si attiva, e non si usa può crearci problemi, infatti il mancato utilizzo ci porta ad un abbassameno della guardia.

Procedendo per gradi, tratterò un argomento troppo spesso lasciato al caso e alla poca fantasia, di cosa stò parlando? Delle password oviamente.

Molte volte mi sono trovato di fronte a Linux Box che avevano l'utente "pippo" con password "pluto" avente i permessi di root.

No non stò bestemmiando è la pura verità ed è grave.

Occhio! Questo utente è in italia il più usato, e quindi un mal'intenzionato, utilizzerà proprio questa combinazione utente/password nel primo tentativo.

E se avete creato questo utente con la password descritta? Beh siete fregati!

Il mal'intenzionato in questione accede alla vostra macchina e poi avendo i permessi di root, gioca quanto vuole e come gli pare all'interno del vostro sistema.

Quindi, per prima cosa, togliete l'utente "pippo" dal vostro sistema.

La scelta della password, non deve essere lasciata al caso, ma ragionata.

Una password composta da caratteri, numeri e punteggiatura può essere difficile da individuare no?

E allora diamoci da fare.

Una password di difficile individuazione è composta da almeno 8 caratteri alfanumerici posti a caso.

Ad esempio : "10Anguri3Xme"

Certo è che ricordarsi a memoria una cosa del genere può risultare difficile anche per chi l'ha scritta, e allroa che fare?

Semplice, usate le iniziali di una frase a voi nota e che vi ricordate facilmente, ad esempio :

"Nel mezzo del cammio di nostra vita "

la password risultante sara : nmdcdnv

a questo punto aggiungete un carattere di punteggiatura ed il gioco è fatto :

Con una semplice ricerca su Internet potrete anche trovare le password da non usare.

Importante:

tutte le modifiche riportate di seguito sono da effettuare con l'utente root

Chiarito questo primo, ma secondo me molto importante punto, passiamo alla rimozione di una serie di utenti che non servono a nulla, ma che drante l'isntallazione del sistema vengono creati in quanto legati ad un relativo servizio.

Questa la lista degli utenti da eliminare :

adm
lp
halt
operator
gopher
shutdown
news
guest
pippo
test
admin

e la lista dei gruppi da eliminare :

adm
lp
news
pppuser (se non si hanno utenti che usano ppp)
slipuser
popuser (se non si hanno utenti che utilizzano server pop)

Per eliminare un utente utilizzare il comando : userdel nome_utente
Per eliminare un gruppo utilizzare il comando : groupdel nome_gruppo

Andiamo avanti e modifichiamo alcuni file e permessi presenti nel nostro sistema.

/etc/host.conf

Contiene alcuni parametri relativi all'host.

Impostatelo in questa maniera :

order bind,hosts
multi on
nospoof on

Salviamo il tutto e andiamo avanti

/etc/login.defs

Questo file contiene il numero minimo di caratteri minimini che dovranno comporre una password ed altre informazioni, il default di solito è 5, quindi mettiamo un numero superiore (sempre consigliato 8 o maggiore)
Quindi identificate una linea simile o uguale alla seguente :

PASS_MIN_LEN 5

e sostituitela con :

PASS_MIN_LEN 8

vi consiglio di dare uno sguardo un po' più ampio al file in questione, in quanto contiene alcune impostazioni molto interessanti.

/etc/exports

Questo file contiene la lista di tutte le directory che vengono esportate verso altri computer tramite NFS.
Sarebbe sempre meglio evitare l'esportazione delle directory, ma se proprio non se ne può fare a meno allora esportiamole nel modo più restrittivo possibile, specificando quindi quale host deve vederle e soprattutto dando i permessi di sola lettura :

/dir_da_esportare host.dominio.com (ro,root_squash)

ro = sola letture
root_squash = neanche root ci può scrivere :-)

Una volta aggiunte tutte le directory da esportare dovremo scrivere :

/usr/sbin/exportfs -a per rendere effettive le modifiche

Volendo aumentare la sicurezza della nostra LinuxBox, potremmo aggiungere una password a LILO

/ect/lilo.conf

inserendo queste 2 righe :

restricted
password=la_password_che_abbiamo_pensato

Attenzione :
La password è scritta in chiaro, ed è quindi visibile ad ogni utente.....non mi sembra molto sicuro no?

Per ovviare a questo inconveniente, permetteremo soltanto a root di poter accedere al file utilizzando il comando chmod :

chmod 600 /etc/lilo.conf

per verificare che la configurazione sia corretta ed attuare le modifiche lanceremo :

lilo -v


E' inoltre buona norma rendere illegibile a tutti gli utenti, ad esclusione di root, del file services presente sempre nella cartella /etc

chmod 600 /etc/services

e dulcis in fundo rendere l'accesso agli script presenti in /etc/rc.d/init.d soltanto a root

chmod -R 700 /etc/rc.d/init.d*


Questo piccolo tutorial, non rende inespugnabile la vostra linuxBox, ma può aiutarvi a renderla più sicura.

La sicurezza di un sistema, richiede molto studio quindi documentatevi il più possibile.
Quello che oggi è sicuro potrebbe non esserlo tra qualche giorno, quindi vi consigilio di iscrivervi alle mailing list della vostra distro.
Aggiornare i pacchetti della vostra distribuzione, prestando particolare attenzione a quelli contrassegnati come Urgente/Importante/Sicurezza.

Ultima cosa, se volete, provate a crakkarvi le password.
Esistono in rete molti programmi per effettuare il crack delle password, scaricateli e testate.

Se il vostro PC naviga molto su intenet, utilizzate un firewall.Linux ha già un suo sistema firewall chiamato iptables che non tratterò in questo tutorial, ma in uno dedicato.

Per configurarlo in modo semplice e visuale,scaricatevi dalla rete il programma "guarddog".

sabato 14 agosto 2010

Untangle software open source che permette di controllare al 100% una rete.

Untangle è un software Open Source che permette di controllare al 100% una rete, può bloccare siti, spam, pubblicità, creare VPN e molto altro.

Untangle è probabilmente il primo software Open Source e freeware che permette di gestire totalmente una rete, non solo casalinga ma anche aziendale, governativa, scolastica, di settori pubblici, ecc. anche con migliaia di computer, ha praticamente tutto quello che serve per poter gestire una rete privata.

Stavo cercando un'alternativa gratuita a Network Magic, software Cisco che permette di configurare semplicemente una rete, Untangle è meglio, non la permette di configurare ma la può gestire, operazione necessaria che deve fare il padre di famiglia, il datore di lavoro/l'amministratore di sistema di qualsiasi ente pubblico o privato.

A differenza di qualche anno fa, oggi è impensabile che qualsiasi ufficio, scuola o laboratorio, sia carente di un collegamento Internet. L’utilizzo della grande Rete è ormai appannaggio di tutti e in qualunque luogo, sia esso cablato che raggiungibile in modalità wireless.

Attualmente in commercio vengono venduti una nutrita varietà di dispositivi che, oltre a stabilire il collegamento fisico alla rete, permettono l’utilizzo di internet senza poter porre restrizioni sul traffico in uscita o proteggere gli utenti da virus e pericoli sempre in agguato (a meno di non acquistare costosissimi dispositivi Cisco o similari).

Ragion per cui, il solo condividere un collegamento Internet non basta. Specie in luoghi delicati come le scuole, dove bisogna garantire il controllo del traffico per evitare che i giovani entrino in contatto con la pornografia o facciano conoscenze che in futuro si riveleranno non gradite. Ovviamente, reti molto grandi necessitano di strumenti complessi e di qualità capaci di rendere l’uso della rete sicuro e protetto compatibilmente all’elevato volume di traffico.

Da non sottovalutare, inoltre, la necessità di personale qualificato capace di domare gli strumenti a disposizione. E le piccole reti? Ovviamente i network di piccole dimensioni necessitano di strumenti proporzionati all’uso quotidiano con una complessità tale da non essere costretti ad assumere una persona qualificata. Non a caso, il più delle volte, per risparmiare i costi di hardware specializzato e personale, si realizza una soluzione “fai da te” utilizzando una distribuzione Linux e un pizzico di conoscenza.

Grazie a un computer e qualche scheda di rete, possiamo sopperire alle deficienze dei comuni modem/router ADSL, senza dover rinunciare alle funzionalità più avanzate che alcuni dispositivi forniscono nativamente.La quasi totalità di questi software trasformano il computer in una macchina dedicata unicamente alla gestione della rete locale e come nodo di transito per l’accesso a Internet. Giusto per fare due nomi famosi, è giusto menzionare PfSense (www.pfsense.com) basato su Bsd e Ipcop (www.ipcop.org) basato su Linux, i quali attualmente sono considerati i prodotti opensource/liberi migliori. Entrambi forniscono una comoda interfaccia di gestione via web.

Untangle permette di:

* Filtrare siti internet, ad esempio facebook, myspace, quello che si vuole;
* Bloccare spam;
* Fermare virus;
* Proteggere da spyware;
* Controllare i protocolli di rete che si vuole, si può bloccare il peer to peer ad esempio;
* Ha un firewall integrato;
* Può generare report dell'utilizzo della rete dei vari computer ad essa connessi;
* Può bloccare la pubblicità, utile non solo per evitare distrazioni al lavoro ma anche per scongiurare click sui propri annunci AdSense da parenti;
* Creare una VPN tra internet e la rete.

Un'altra comodità di Untangle è che tutte queste funzionalità sono scaricabili separatamente, oppure, è possibile installare Untangle su un computer dedicato (Dedicated Untangle Server), come un sistema operativo oppure su un computer windows con Windows XP SP3 o Vista, solo su sistemi a 32 bit momentaneamente visto che la versione per windows è in fase di sviluppo beta.

Per chi volesse di più sono presenti delle funzionalità che è possibile aggiungere a pagamento ad Untangle come ad esempio l'assistenza personalizzata, la protezione della rete con antivirus Kaspersky ed altro.

Questa è la homepage di Untangle, potete approfondire tutte le caratteristiche ed ovviamente ci sono i collegamenti per fare il download di Untangle, al suo forum, il Wiki ed altro.