Ricerche IT

Su un server Linux, uno strumento indispensabile per l’amministrazione del server stesso è il server SSH, come OpenSSH, tramite il quale possiamo avere un accesso sicuro alla shell del sistema operativo, per poter amministratore comodamente il nostro server Linux.

In ambiente Windows, un accesso SSH non è una cosa indispensabile, risulta più utile avere un accesso via Remote Desktop per amministrare il server, allo stesso tempo però, può comunque avere un senso l’accesso SSH su server Windows, un po’ per determinate operazioni da svolgere via riga di comando, un po’ per poter scaricare o caricare file da o sul server attraverso SCP e SFTP, che possono diventare comodi soprattutto se ci connettiamo al server in remoto, via VPN, oppure se dobbiamo amministrare o trasferire dati da una macchina Linux ad una macchina Windows, in questo modo non saremo costretti ad utilizzare X oppure ad installare Samba per il trasferimento dati da/verso Windows.

Per quanto concerne il software che funge da server SSH, ne esistono diversi, e direi che più o meno tutti sono un’implementazione di SSH in ambiente emulato Cygwin; io ne ho provati due, Freesshd e CopSSH, che rispondono a due esigenze diverse, in particolare, Freesshd fornisce l’ambiente di shell di Windows, mentre CopSSH fornisce un sottoinsieme dei comandi presenti nella shell Bash di Linux.

Personalmente, tra un’implementazione completa della shell di Windows come quella di Freesshd (che appunto richiama direttamente l’interprete dei comandi di Windows, cmd.exe) ed una che (secondo le mie prove, che ammetto non essere state esaustive) risulta, all’atto pratico, avere una parte dei comandi Bash ed una parte dei comandi di Windows, come accade con CopSSH, preferisco Freesshd; tanto per fare un esempio, con Freesshd riesco a vedere i processi in esecuzione con il comando tasklist, cosa che non riesco a fare con Copssh.

Per poter utilizzare un server SSH su Windows, l’utente col quale faccio il logon al server deve obbligatoriamente consentire l’accesso interattivo al server, se così non è, va modificata l’opportuna policy (si tratta di policies diverse a seconda se il server è controller di dominio oppure no) sul server Windows, e questo può comportare qualche problema di sicurezza in più, cosa che secondo me rappresenta il vero svantaggio dell’avere attivo un server SSH su Windows. Entrambi i software hanno una procedura che permette di specificare quali utenti definiti sul server Windows possono accedere via SSH al server stesso, va da sé che, se vogliamo amministrare decentemente il server Windows, dovremo accedere allo stesso con un’utenza amministrativa, se invece necessitiamo del solo SFTP, è sufficiente abilitare l’utente all’accesso, dopodiché saranno le autorizzazioni impostate sulle cartelle del server Windows a stabilire le possibili azioni dell’utente.

Tornando a FreeSSHD, l’installazione del prodotto è decisamente banale, basta cliccare sempre su Avanti (Next); durante l’installazione verrà creato il servizio FreeSSHDService, in modo che il “demone” sia sempre attivo, quindi dovremo accedere alla configurazione del programma, cliccando col tasto destro sull’icona del programma posta nella systray e, scegliendo la voce Settings dal menu contestuale, è possibile gestire il server SSH, e soprattutto, è possibile abilitare o disabilitare l’accesso SSH agli utenti di Windows tramite la scheda Users, come mostrato in figura 1:

Figura 1 - Scheda Users di FreeSSHD

A questo punto, è sufficiente utilizzare un client SSH come Putty in ambiente Windows, o utilizzando il comando ssh in ambiente Linux/Unix, e collegandosi al server (finora ho provato solamente con nome utente e password, senza utilizzare certificati) si può testare il corretto accesso al server Windows.

Purtroppo, per un motivo che non sono ancora riuscito a capire, al primo tentativo viene restituito l’errore “Incoming packet was garbled on decryption” con Putty oppure l’errore “Bad packet length” su Linux, seguito da un numero; la cosa strana è che tentando una seconda volta, senza cambiare nulla, la connessione avviene senza nessun problema, se qualcuno sa o ha idea da cosa possa dipendere, farebbe cosa molto gradita scrivendolo nei commenti.

Una volta verificato il corretto accesso al server Windows, è possibile configurare anche SFTP, andando a specificare nella configurazione di FreeSSHD qual è la directory root SFTP del server Windows tramite la scheda SFTP, come mostrato in figura 2:

Figura 2 - Scheda SFTP di FreeSSHD

Ora non ci resta che testare il corretto funzionamento di una connessione SFTP; per Windows, si possono utilizzare due programmi, WinSCP (che a dispetto del nome consente anche la connessione SFTP) e FileZilla, il quale, oltre alle normali connessioni FTP, permette di stabilire connessioni SFTP basandosi sull’onnipresente Putty.

Questa configurazione, secondo le prove che ho potuto fare, funziona abbastanza bene, con alcuni difetti: per prima cosa, ho letto sul Web che FreeSSHD peccherebbe un po’ in stabilità, finora io non ho avuto problemi, ma non ne ho fatto un uso intensivo; secondariamente, per quanto riguarda SFTP, l’unica configurazione possibile riguarda la root directory accessibile dagli utenti, impedendo agli stessi di poter accedere alle cartelle di livello superiore, e ciò è positivo dal punto di vista della sicurezza, poiché in questo modo si possono abilitare diversi utenti che comunque non hanno la possibilità di gironzolare per il disco, però, allo stesso tempo, questa impostazione riguarda TUTTI gli utenti, per cui anche gli utenti con privilegi amministrativi, utilizzando SFTP, non possono operare ad un livello superiore rispetto alla home directory, anche se, in realtà, utilizzando Linux, è possibile superare questa limitazione utilizzando scp, per poterlo fare però bisogna conoscere il percorso esatto del file da prelevare; altra limitazione, la shell fornita per default da FreeSSHD è quella di Windows, per cui WinSCP non funziona in modalità SCP, funziona però perfettamente in modalità SFTP.

In conclusione, installare un server SSH su Windows, è utile, secondo me, solo in determinate occasioni, soprattutto se da client Linux dobbiamo accedere o condividere file con un server Windows, oppure può risultare utile su connessioni remote particolarmente lente, altrimenti, secondo me è più utile utilizzare Remote Desktop, utilizzabile anche da Linux tramite il pacchetto rdesktop.

La versione pacchettizzata di MySQL Server 5 per Linux Debian Etch 4.0 ha una caratteristica, non accetta connessioni sulla porta 3306 (la porta a cui risponde MySQL) se non da localhost, cioè sé stesso. Questo può essere un problema se vogliamo o dobbiamo tenere due macchine separate per un’applicazione (o sito) ed il relativo database.

La soluzione al problema è molto semplice, si tratta di commentare la seguente voce

bind-address = 127.0.0.1

presente nel file di configurazione di MySQL, /etc/mysql/my.cnf, dopodiché, dobbiamo abilitare uno o più utenti per poter connettersi in remoto su un particolare database utilizzando l’istruzione SQL GRANT:

GRANT ALL privileges ON testDB.* TO 'testUSR'@'192.168.0.3' IDENTIFIED BY 'testPWD'

così facendo, si abilita l’utente testUSR a connettersi al database testDB dall’host 192.168.0.3. A questo punto, è sufficiente far ripartire il demone di MySQL per abilitare la modifica effettuata al file my.cnf:

/etc/init.d/mysql restart

e questo è tutto.

Se si deve gestire un firewall Linux con iptables, in determinate situazioni può riverlarsi indispensabile poterne gestire il logging nel modo più lineare possibile; il passo più logico per raggiungere questo scopo è quello di effettuare un logging su file delle attività di iptables che si intende monitorare. Si tenga presente che questi passaggi sono stati effettuati su Debian Etch.

L’operazione consta di più passaggi:

1. configurazione di iptables per fare in modo che venga fatto il logging di determinati tipi di traffico su file;
2. installazione e configurazione di syslog-ng, che consentirà di specificare uno specifico file su cui redirigere il logging di iptables;
3. configurazione di logrotate per poter ruotare i file di log di iptables.

Configurazione di iptables

Per prima cosa, dobbiamo decidere quale tipo di traffico vogliamo monitorare, in questo caso, scegliamo di monitorare il traffico icmp verso l’ipotetica interfaccia esterna del nostro firewall. Se si prende come riferimento l’articolo precedente riguardante iptables, bisogna aggiornare lo script di iptables, caricando per prima cosa il modulo ipt_LOG tramite la direttiva:

modprobe ipt_LOG

Ora è possibile specificare un’istruzione per il logging del traffico ICMP sull’interfaccia esterna, assumendo che questa prenda il nome eth1:

iptables -A INPUT -i eth1 -p icmp -j LOG --log-level 4 --log-prefix='LOG_ICMP '

quest’istruzione è da inserire prima dell’eventuale direttiva che consente o nega il traffico ICMP verso l’interfaccia eth1. Da notare la direttiva log-prefix, che farà precedere le stringhe di logging da ciò che abbiamo specificato tra apici (nel nostro caso LOG_ICMP ). Con questo comando termina la configurazione di iptables.

Installazione e configurazione di syslog-ng

In questo secondo passaggio andremo a sostituire il server syslog classico con syslog-ng, un server syslog più evoluto che permette una gestione più raffinata dei messaggi di log provenienti da kernel e demoni. Prima di configurare syslog-ng, dobbiamo però fare in modo che i log di iptables non compaiano in console (che in pratica si traduce nella comparsa dei vari log sul monitor del PC), cosa decisamente fastidiosa: ciò è possibile editando il file /etc/sysctl.conf:

nano /etc/sysctl.conf

quindi, dobbiamo decommentare la riga 1 del seguente listato sostituendola con la riga 3:

1
2
3

#kernel.printk = 7 4 1 7
 
kernel.printk = 4 4 1 7

in tal modo, indicando il valore 4 in vece del valore 7, si indica che il logging a console viene abilitato solo per il logging di livello inferiore a 4, avendo indicato noi nello script di iptables che il nostro logging è di valore 4, la console rimarrà immacolata.

AGGIORNAMENTO
Un metodo alternativo per raggiungere lo stesso scopo è quello di editare il file /etc/default/syslog-ng decommentando l’ultima riga, che diventerà:

CONSOLE_LOG_LEVEL=4

al posto di 4, potremo mettere, nel caso, anche un numero inferiore fino ad arrivare a 1. Una volta riavviato il demone di syslog-ng, verrà modificato come visto in precedenza il file kernel.printk per prevenire la visualizzazione sulla console dei log di iptables.
FINE AGGIORNAMENTO

Ora, installiamo syslog-ng con il classico apt:

apt-get install syslog-ng

che non si limita ad installare syslog-ng ma disinstalla anche il classico syslog, di cui va a prendere il posto. A questo punto va configurato syslog-ng per far sì che i log non vadano a finire nei file /var/log/messages, /var/log/kern.log e /var/log/syslog, editando il file /etc/syslog-ng/syslog-ng.conf:

nano /etc/syslog-ng/syslog-ng.conf

dove bisogna aggiungere in fondo al file le seguenti righe:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# configurazione logging di iptables
 
destination df_firewall {
        file("/var/log/iptables.log");
};
 
filter f_firewall {
match("LOG_ICMP ");
};
 
log {
        source(s_all);
        filter(f_firewall);
        destination(df_firewall);
};

Le righe da 3 a 5 servono per parametrizzare il file dei log di iptables, le righe da 7 a 9 rappresentano il criterio con cui viene deciso, da parte di syslog-ng, quando redirigere le stringhe di logging verso il file specificato in precedenza attraverso la condizione

match("LOG_ICMP ")

mentre le righe da 11 a 15 rappresentano la direttiva vera e propria verso syslog-ng per loggare tutto ciò che proviene da iptables contenente la stringa “LOG_ICMP “.

Lasciando le cose in questo modo, il logging verso il file /var/log/iptables.log funziona perfettamente, però i log vengono inviati anche verso i file “canonici” di log del kernel. Per ovviare al problema, bisogna modificare il file /etc/syslog-ng/syslog-ng.conf in modo che syslog-ng non scriva i messaggi provenienti da iptables nei file indicati in precedenza; primo passo, la modifica del filtro f_kern:

1
2
3

filter f_kern { facility(kern); };
 
filter f_kern { facility(kern) and not match("LOG_ICMP "); };

dove la riga numero 1 viene sostituita dalla riga numero 3, così da evitare che le voci di log vadano a finire nel file /var/log/kern.log; il passo successivo riguarda la modifica della voce relativa al filtro f_syslog:

1
2
3

filter f_syslog { not facility(auth, authpriv); };
 
filter f_syslog { not facility(auth, authpriv) and not match ("LOG_ICMP "); };

dove andremo a sostituire la riga numero 1 con la riga numero 3, per impedire che il logging di iptables vada a popolare il file /var/log/syslog. Ora rimane da modificare il filtro f_messages, che da così

filter f_messages {
        level(info,notice,warn)
            and not facility(auth,authpriv,cron,daemon,mail,news);
};

diventa così

filter f_messages {
        level(info,notice,warn)
            and not facility(auth,authpriv,cron,daemon,mail,news)
                and not match ("LOG_ICMP ");
};

modifica che inibisce il logging di iptables nel file /var/log/messages. In tutte e tre le situazioni, abbiamo aggiunto la condizione

and not match ("LOG_ICMP ")

condizione che istruisce syslog-ng ad ignorare, per quel determinato filtro, tutti i log che contengono la stringa “LOG_ICMP “, per cui, se si modifica la configurazione di iptables utilizzando, per il logging, un prefisso diverso da quello indicato (tramite la direttiva log-prefix di iptables), tutte le segnalazioni finiranno nei file “normali” e non nel file /var/log/iptables.log che abbiamo creato.

Configurazione di logrotate

Tenendo le cose così come sono, con l’andare del tempo il file /var/log/iptables.log assumerà dimensioni sempre più grandi, rendendo quindi i log di difficile lettura. La soluzione al problema sta nell’istruire logrotate (che dovrebbe essere già presente in Debian Etch) per routare il nostro file di log personalizzato secondo i criteri che preferiamo. Prima di configurare logrotate, vediamo brevemente come funziona.

Logrotate ha un file di configurazione, /etc/logrotate.conf, in cui sono indicate le opzioni generali di configurazione, ed ha una directory, /etc/logrotate.d, in cui vi sono i file di configurazione riguardanti il logging delle singole applicazioni; questi file di configurazione vengono richiamati dalla direttiva presente nel file /etc/logrotate.conf

# packages drop log rotation information into this directory
include /etc/logrotate.d

Nel nostro caso, dovremo creare un file chiamato iptables nella directory /etc/logrotate.d, quindi editarlo per indicare a logrotate come routare il nostro file:

touch /etc/logrotate.d/iptables
nano /etc/logrotate.d/iptables

Nel file /etc/logrotate.d/iptables andremo ad inserire questo contenuto:

1
2
3
4
5
6
7
8

/var/log/iptables.log {
        weekly
        rotate 4
        compress
        notifempty
        missingok
        endscript
}

Vediamo di esaminare nel dettaglio le varie istruzioni del file: weekly indica che il file di log viene routato con cadenza settimanale, rotate 4 significa che vengono conservati 4 log già routati, compress specifica che i file di log routati vengono compressi, notifempty sta ad indicare a logrotate di non routare il file di log se questo è vuoto, missingok permette a logrotate di non segnalare errori se per qualche motivo il file di log non esiste, endscript indica semplicemente il termine delle istruzioni di configurazione per il file corrente. Per ulteriori informazioni sulle opzioni di logrotate è possibile consultare le pagine man di logrotate oppure gli ultimi due collegamenti nella sezione Link di riferimento di quest’articolo.

Ora non rimane che verificare nel tempo il corretto funzionamento di logrotate.

Link di riferimento

http://tuttodebian.blogspot.com/2008/05/iptables-and-syslog-how-to-log-in.html
http://www.linux.it/~rubini/docs/printk/printk.html
http://openskill.info/infobox.php?ID=779
http://www.uielinux.org/blog/14-usare-linux/87-ubuntu-professionale-usiamo-il-logrotate.html

Facendo riferimento al precedente articolo, che trattava la configurazione degli host virtuali in Apache su un sistema Debian, proseguiamo sulla stessa falsariga e vediamo come configurare in modo opportuno un server FTP che consenta una gestione separata dei diversi siti, impedendo nello stesso tempo agli utenti di girare per il file system e quindi di accedere ad aree della macchina che non competono loro; in questo articolo parlerò di ProFTPD, anche se nell’articolo precedente avevo citato vsftpd, purtroppo, nell’installazione in cui ho in funzione vsftpd, ho avuto alcuni problemi di cui non sono riuscito a capire l’origine, problemi che mi hanno costretto ad utilizzare un altro server FTP, ProFTPD appunto.

Ora dobbiamo configurare in modo opportuno ProFTPD in modo da avere due utenti distinti che gestiscano i due siti creati come descritto nell’articolo precedente, creando due siti FTP virtuali, con l’ausilio di un database dedicato su MySQL; installiamo quindi ProFTPD con il supporto per MySQL:

# apt-get install proftpd proftpd-mysql

Ora dovremo creare il database per ProFTPD, entrando in MySQL col comando:

$ mysql -u root -p

quindi, dopo aver inserito la password, creiamo il database proftpd col comando:

> CREATE DATABASE proftpd;

ed ora, creiamo l’utente MySQL proftpd, al quale diamo le autorizzazioni del caso al database proftpd:

> GRANT SELECT, INSERT, UPDATE, DELETE ON proftpd.* TO ‘proftpd’@'localhost’ IDENTIFIED BY ‘pwdProFTPD’;
> FLUSH PRIVILEGES;

dove, al posto di pwdProFTPD metteremo la password che più ci aggrada.

A questo punto, seguiamo le istruzioni contenute nel preziosissimo tutorial di Howtoforge, che spiega passo passo come realizzare un server FTP che permetta di definire dei virtual host, a cominciare dalle indicazioni su come creare un utente ed un gruppo di sistema per ProFTPD, per poi passare alle istruzioni su come creare le tabelle nel database MySQL riguardanti gli utenti e le ftpquotas (le quote di spazio riservato su disco per ogni utente), dopodiché, a pagina 2 della guida, viene spiegato quali righe aggiungere al file di configurazione /etc/proftpd/proftpd.conf per consentire a ProFTPD di utilizzare un database MySQL come supporto. In particolare, vediamo la riga SQLConnectInfo (in cui vanno inseriti i parametri di connessione al database), la quale, se utilizziamo un database MySQL configurato come descritto in precedenza, va scritta così:

SQLConnectInfo proftpd@localhost proftpd pwdproftpd

Giunti qui, dobbiamo inserire gli utenti nel database MySQL, in particolare nella tabella ftpuser (ho tralasciato volutamente la parte riguardante le quote disco); la guida presente su Howtoforge è fatta molto bene, ma ha il difetto di inserire le password degli utenti in chiaro nella tabella del database, cosa che comporta problemi di sicurezza, per cui, dovremo per prima cosa cambiare una direttiva nel file di configurazione di ProFTPD, per poi utilizzare un’istruzione SQL INSERT diversa da quella riportata su Howtoforge. Il primo passaggio, come detto, consiste nel modificare la direttiva SQLAuthTypes, impostandola in questo modo:

SQLAuthTypes Crypt Plaintext

che significa che le password degli utenti definiti nel database MySQL devono essere criptate, altrimenti l’utente non riuscirà ad autenticarsi su ProFTPD. Ora , dopo aver fatto ripartire il demone proftpd, passiamo all’inserimento vero e proprio degli utenti nel database proftpd in MySQL, in cui dobbiamo prestare attenzione ad indicare la home directory su cui verrà rimbalzato l’utente che si autentica su ProFTPD; in particolare, facendo riferimento all’articolo riguardante l’hosting virtuale con Apache, creeremo un utente chiamato u_webtest con password p_webtest (password insicura, utilizzata per comodità) e home directory /var/www/webtest, quindi creeremo un altro utente chiamato u_webprova con password p_webprova e home directory /var/www/webprova:

> INSERT INTO ftpuser (userid, passwd, uid, gid, homedir, shell, count, accessed, modified) VALUES
> (’u_webtest’, ENCRYPT(’p_webtest’), 2002, 2002, ‘/var/www/webtest’, ‘/sbin/nologin’, 0, ”, ”);

> INSERT INTO ftpuser (userid, passwd, uid, gid, homedir, shell, count, accessed, modified) VALUES
> (’u_webprova’, ENCRYPT(’p_webprova’), 2003, 2003, ‘/var/www/webprova’, ‘/sbin/nologin’, 0, ”, ”);

Da notare che per inserire la password è stata usata la funzione di MySQL ‘ENCRYPT’, la quale utilizza la chiamata di sistema crypt() presente sul sistema operativo, quindi di fatto utilizza lo stesso metodo di cifratura utilizzato da Linux per cifrare le password degli utenti di sistema. Ora, rimangono da impostare i permessi sulle directory dei due siti web, per far sì che gli utenti FTP possano scrivere al loro interno, dando l’autorizzazione in scrittura all’utente ftpuser creato in precedenza:

# chown -R ftpuser:www-data /var/www/webtest
# chown -R ftpuser:www-data /var/www/webprova
# chmod -R 775 /var/www/webtest
# chmod -R 775 /var/www/webprova

Arrivati fin qui, dobbiamo solamente utilizzare un client FTP per testare la funzionalità del nostro server FTP, e, se tutto è andato bene, dovremmo essere pronti per utilizzare il nostro ProFTPD.

Se un server Linux Debian viene utilizzato come server Web, è abbastanza probabile che questo ospiti più siti, ed è piuttosto comune che questi siti vengano gestiti da persone diverse, che debbono avere quindi un accesso FTP dedicato per poter caricare i file del proprio sito, e magari poter avere l’accesso al proprio database MySQL tramite PhpMyAdmin, facendo in modo che gli operatori non vadano a gironzolare su directory o database non di loro competenza.

In questo primo articolo (il prossimo tratterà della configurazione del server FTP vsftpd), darò per scontato che siano già installati (tramite il solito apt) Apache2, PHP5, MySQL; ipotizziamo quindi di dover creare due siti, webtest.it e webprova.it, e creiamo le relative directory:

# mkdir /var/www/webtest
# mkdir /var/www/webprova

Ora, create le directory, dobbiamo configurare gli host virtuali in Apache. Apache2, in Debian, consente la configurazione degli host virtuali inserendo un file di configurazione per ogni host virtuale che si intende creare nella directory /etc/apache2/sites-available, per cui, andremo a creare i due file per i due domini:

# touch /etc/apache2/sites-available/webtest.it
# touch /etc/apache2/sites-available/webprova.it

A questo punto, creati i file vuoti, vanno editati con questi contenuti:

File /etc/apache2/sites-available/webtest.it

NameVirtualHost *:80
<VirtualHost *:80 >
ServerAdmin webmaster@webtest.it
ServerName www.webtest.it
DirectoryIndex index.html index.php
DocumentRoot /var/www/webtest
<Directory "/var/www/webtest">
Order Deny,Allow
Allow from all
Options -Indexes
</Directory>
ErrorLog /var/log/apache2/webtest.it.log
LogLevel warn
CustomLog /var/log/apache2/access.webtest.it.log combined
</VirtualHost>

File /etc/apache2/sites-available/webprova.it

<VirtualHost *:80 >
ServerAdmin webmaster@webprova.it
ServerName www.webprova.it
DirectoryIndex index.html index.php
DocumentRoot /var/www/webprova
<Directory "/var/www/webprova">
Order Deny,Allow
Allow from all
Options -Indexes
</Directory>
ErrorLog /var/log/apache2/webprova.it.log
LogLevel warn
CustomLog /var/log/apache2/access.webprova.it.log combined
</VirtualHost>

Ora i due siti sono configurati con impostazioni "normali", vediamo il loro significato:

NameVirtualHost *:80
Serve per definire su quale interfaccia di rete e su quale porta deve rimanere in ascolto l’host virtuale Apache, in questo caso rimane in ascolto su tutte le interfacce sulla porta 80

<VirtualHost *:80 >
Identifica l’apertura della sezione relativa alla configurazione dell’host virtuale, l’indicazione successiva a VirtualHost (*:80) deve essere identica a quella della direttiva NameVirtualHost

ServerAdmin webmaster@webtest.it
Indica l’indirizzo e-mail dell’amministratore del dominio

ServerName www.webtest.it
Rappresenta il nome FQDN del sito, è fondamentale scrivere bene questa voce altrimenti il nostro sito non sarà visibile

DirectoryIndex index.html index.php
Esprime l’ordine di ricerca di determinate pagine Web rappresentanti la home page quando viene fatta da un browser una richiesta del tipo www.webtest.it/ o www.webtest.it/test/, se in queste directory non esiste una pagina chiamata index.html o index.php (o qualsiasi altro nome file indicato nella direttiva DirectoryIndex), Apache restituirà un errore 403 Forbidden se usiamo la direttiva "Options -Indexes" (come effettivamente faremo), oppure, se questa direttiva non viene utilizzata, visualizzeremo i files presenti nella directory

DocumentRoot /var/www/webtest
Indica la directory in cui sono posizionati i file del nostro sito

<Directory "/var/www/webtest">
Identifica l’inizio della configurazione delle autorizzazioni per la directory del sito

Order Deny,Allow
Allow from all
Queste due righe stanno ad indicare che il sito è visibile a tutti

Options -Indexes
Come indicato in precedenza, questa opzione permette di visualizzare un errore 403 di accesso negato se si digita un indirizzo del tipo www.webtest.it/test/ ed in questa directory non esiste un file chiamato con uno dei nomi file indicati nella direttiva DirectoryIndex; se non si specifica questa opzione, sarà visibile il contenuto dell’intera directory, cosa da evitare.

ErrorLog /var/log/apache2/webtest.it.log
LogLevel warn
CustomLog /var/log/apache2/access.webtest.it.log combined
ErrorLog fornisce un percorso per il file di log contenente le segnalazioni di errore che incontra Apache, mentre LogLevel indica la verbosità delle operazioni di logging attraverso un sistema di livelli, di cui "warn" è uno dei più bilanciati; CustomLog identifica la posizione del file di log che registra gli accessi al sito Web.

Giunti qui, andiamo a creare i file di log che abbiamo specificato nei file di configurazione dei virtual hosts:

# touch /var/log/apache2/access.webtest.it.log
# touch /var/log/apache2/webtest.it.log
# touch /var/log/apache2/access.webprova.it.log
# touch /var/log/apache2/webprova.it.log

dopodiché, bisogna abilitare i siti virtuali, e ciò è possibile tramite il comando a2ensite, il quale crea dei link simbolici nella cartella /etc/apache2/sites-enabled/ che puntano ai file di configurazione creati in precedenza nella cartella /etc/apache2/sites-available/:

# a2ensite webtest.it
# a2ensite webprova.it

ciò è necessario poiché nel file di configurazione di Apache (/etc/apache2/apache2.conf) vi è una direttiva che include i file presenti nella cartella /etc/apache2/sites-enabled/.

Ora non rimane altro che riavviare Apache ed avremo i nostri virtual hosts funzionanti.

Giunti qui, rimane da fare un’unica cosa, cioé installare e configurare PhpMyAdmin per poter gestire il proprio database MySQL tramite sito Web. Per installare PhpMyAdmin, possiamo utilizzare il comando

# apt-get install phpmyadmin

dopodiché, dobbiamo creare un alias su ogni sito sul quale vogliamo rendere disponibile PhpMyAdmin; l’alias si rende necessario poiché l’installazione di PhpMyAdmin viene effettuata nella directory /usr/share/phpmyadmin, per cui, o si fa l’alias, oppure si copia la directory phpmyadmin nella directory del sito, ma ciò non conviene, poiché:

1. è un’operazione che dovremmo ripetere per ogni aggiornamento di PhpMyAdmin
2. nel caso di più host virtuali che utilizzano PhpMyAdmin, dovremmo ripetere la copia per ogni host virtuale che utilizza PhpMyAdmin

per cui, è bene utilizzare un alias per ogni virtual host, che mappi una directory virtuale (ad esempio, /phpmyadmin) per ogni host virtuale che utilizza PhpMyAdmin. Configurare l’alias è molto semplice, prendendo ad esempio i file di configurazione dei due domini citati precedentemente, basta aggiungere questa riga dopo l’istruzione DocumentRoot:

Alias /phpmyadmin /usr/share/phpmyadmin

quindi, dopo aver chiuso e salvato il/i file di configurazione, basta far ripartire Apache per poter utilizzare PhpMyAdmin, la cui configurazione esula dagli scopi di questo articolo; in ogni caso, tenere presente che, se PhpMyAdmin è configurato con un livello di sicurezza ‘cookie’, nome utente e password richiesti per entrare in PhpMyAdmin, non sono altro che gli utenti definiti in MySQL, per cui, bisogna fare attenzione alle autorizzazioni che si assegnano ai vari database, onde evitare che certi utenti possano accedere a database non di loro competenza.

Link di riferimento
Gestione Moduli e Virtual Hosts di Apache2 su Debian e Ubuntu
HowTo: Configurazione dei Virtual Hosts (alias) con Apache2 su Debian ETCH

Uno dei possibili utilizzi dell’Asus eeepc (il nuovo subnotebook di Asus con schermo da 7"), è quello di avere un pratico gingillo da portare sempre con sé e da utilizzare, se necessario, per brevi operazioni di amministrazione su server Linux (tramite ssh) o su server Windows, connettendosi con rdesktop su quei server Windows Server 2003 su cui è abilitato Remote Desktop.

Rdesktop è un’utilità già presente sull’installazione predefinita dell’eeepc, che consente appunto di connettersi ad un qualsiasi computer Windows con attivo il servizio RDP; la particolarità di rdesktop presente su eeepc è che… non funziona. Per essere più precisi, rdesktop non ha alcun problema in sé, ma se lanciamo dal terminale il comando:

$ rdesktop -a 16 -f nomeserver

cercando di connetterci ad un server Windows Server 2003, ci viene presentata la schermata di login dove, se inseriamo nome utente e password, ci butta fuori dando un errore "segmentation fault" nella finestra del terminale.

La ragione di quest’errore, è che, per impostazione predefinita, X.org montato sull’eeepc funziona con una profondità di colore di 16 bit, per cui bisogna modificare quest’impostazione lanciando da terminale il comando:

$ sudo kwrite /etc/X11/xorg.conf

e andando a modificare il valore della voce "DefaultDepth", portandolo da 16 a 24. Salvare il file modificato, quindi riavviare X, ad esempio con la combinazione di tasti (brutale ma veloce) CTRL+ALT+BACKSPACE, e, da una finestra di terminale, dare di nuovo il comando:

$ rdesktop -a 16 -f nomeserver

quindi immettere nome utente e password, ed amministrare il proprio server Windows Server 2003 alla risoluzione di 800×480 pixel, non comodissima ma utilizzabile per periodi non troppo lunghi.

Una macchina Linux prende l’ora di sistema dall’orologio hardware del PC, per cui, se vogliamo avere l’ora corretta sul nostro calcolatore, è necessario che anche l’ora impostata nel BIOS sia corretta. In realtà però, ciò potrebbe non essere sufficiente, in quanto Linux considera anche il fuso orario impostato durante l’installazione del sistema operativo, quindi potremmo trovarci nella situazione in cui l’orario è avanti o indietro di qualche ora rispetto all’orario corrente. In questo caso, avendo un collegamento ad Internet, la cosa migliore da fare è sincronizzare l’ora del proprio sistema con un server dedicato allo scopo utilizzando il protocollo NTP. Per compiere questa operazione, dobbiamo essere loggati come root, in quanto solamente il superutente ha la facoltà di cambiare l’ora del sistema, ma prima dobbiamo installare il pacchetto ntpdate, se non installato, tramite il comando (su Debian e derivate):

# apt-get install ntpdate

Ora possiamo lanciare il comando che ci permette di sincronizzare l’ora del sistema con il server NTP time.ien.it

# ntpdate time.ien.it

Ora il nostro sistema è sincronizzato col server NTP, quindi, a questo punto, non ci rimane che schedulare il comando tramite cron per permetterci di mantenere sincronizzata nel tempo la nostra macchina Linux, e, se vogliamo, possiamo pensare anche di inserire il comando appena descritto in uno script di avvio.

In una rete locale con un server Linux e n client Windows "recenti" (quindi da Windows 2000 in poi), per far sì che le comunicazioni di rete avvengano in modo efficiente, è necessario avere un server DNS che sia in grado di risolvere i nomi host dei vari PC in rete, nonostante in linea teorica sia possibile utilizzare Samba come server WINS, che svolge grosso modo le stesse funzioni di un server DNS anche se ad un livello diverso. Siccome però, come detto precedentemente, lo strumento principe di risoluzione dei nomi host in ambiente Windows è DNS, occorre utilizzare un’architettura di rete con almeno un server DNS in grado di svolgere questo compito in rete locale. Linux risponde benissimo a quest’esigenza col pacchetto Bind, che è appunto il server DNS più utilizzato in ambiente Linux. Il problema però è che se abbiamo una rete abbastanza estesa e con cambi frequenti, dovremmo aggiornare a mano i record A e PTR del server DNS, cosa alquanto scomoda per ovvi motivi, senza considerare che un inserimento manuale si presta benissimo ad errori di digitazione.

Per ovviare a questo problema, è bene far lavorare Bind in stretto contatto con un server DHCP (dhcp3 su Linux), il quale assegnerà dinamicamente la configurazione IP ai vari host, e contestualmente aggiornerà dinamicamente i record DNS su Bind, in modo che l’intervento manuale dell’amministratore di sistema sia ridotto al minimo. Dulcis in fundo, il server DNS sarà utilizzato anche per risolvere i nomi di dominio Internet, impostando uno o più forwarders da interrogare se un dominio non è stato definito sul server DNS locale.

Il primo passo per organizzare questa architettura di rete è quello di installare Bind9 sul server Linux (la solita Debian Etch) e le relative utilità, col comando:

# apt-get install bind9 dnsutils

A questo punto va configurato Bind in modo che possa risolvere i nomi host per il dominio che andremo a creare. Il primo passo, consiste nel dire al server Linux che la risoluzione dei nomi dev’essere delegata a sé stesso, editando opportunamente il file /etc/resolv.conf. Successivamente, bisogna modificare il file /etc/bind/named.conf, che è il file principale di configurazione di Bind, il quale indica dove sono posizionati i file in cui sono definite le zone corrispondenti ai vari domini che si vogliono configurare. Ipotizziamo quindi di avere un dominio test.lan sulla rete 192.168.1.0: dovremo configurare due file di zona, uno chiamato /etc/bind/db.test ed uno chiamato /etc/bind/db.192.168.1, che rappresenta il file in cui inserire i record PTR (quelli di ricerca inversa). Di seguito vediamo come impostare il file /etc/resolv.conf, dopodiché vedremo il contenuto del file di configurazione generico di Bind9 /etc/bind/named.conf, ed infine esamineremo i file di zona /etc/bind/db.test e /etc/bind/db.192.168.1:

/etc/resolv.conf

search casa.lan
nameserver 127.0.0.1

/etc/bind/named.conf

include "/etc/bind/named.conf.options";

zone "1.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.192.168.1";
};

/etc/bind/db.test

$TTL 86400      ; 1 day
test.lan.       IN SOA  ns1.test.lan. hostmaster.test.lan. (
                                2007081501 ; serial
                                86400      ; refresh (1 giorno)
                                28800      ; retry (8 ore)
                                604800     ; expire (1 settimana)
                                86400      ; minimum (1 giorno)
                                );
                IN      NS      ns1.test.lan.
;
ns1             IN      A       192.168.1.1
client          IN      A       192.168.1.3

/etc/bind/db.192.168.1

;
; BIND reverse data file for local loopback interface
;
$TTL    604800
@       IN      SOA     test.lan.       hostmaster.test.lan. (
                                2007081501   ; serial
                                604800       ; refresh
                                86400        ; retry
                                2419200      ; expire
                                604800       ; negative cache ttl
                                );
@       IN      NS      ns1.test.lan.
1       IN      PTR     ns1.test.lan.
3       IN      PTR     client.test.lan.

Fatta la configurazione, bisogna riavviare il demone bind9:

# /etc/init.d/bind9 restart

Ora il server DNS può risolvere i nomi host per il dominio test.lan presente sulla rete LAN, a condizione che gli IP indicati nel file di configurazione non cambino (da tenere presente che i valori indicati sono puramente indicativi); ciò implica che la nostra rete deve essere configurata con indirizzi IP statici, condizione accettabile se i PC non superano le 10 unità, altrimenti si deve considerare l’utilizzo di un server DHCP. Altra cosa da considerare, è che in questa situazione, Bind non riesce a risolvere i nomi di dominio Internet; per ovviare al problema, bisogna indicare a Bind uno o più server DNS pubblici che possano soddisfare le richieste che il server Linux fa per conto dei client, editando opportunamente il file /etc/bind/named.conf.options aggiungendo queste righe:

forwarders {
151.99.125.2;
151.99.250.2;
};

In questo modo i client potranno tranquillamente risolvere sia i nomi host in LAN sia i nomi di dominio Internet.

A questo punto prendiamo in considerazione l’ipotesi di necessitare dello stesso tipo di configurazione, ma per una rete locale di 20 (o più) host: in questo contesto, non è saggio mantenere un indirizzamento di rete con IP fissi, è sicuramente più indicato utilizzare un indirizzamento dinamico, servizio fornito da un server DHCP. Nella situazione indicata in precedenza però, i file di zona del dominio test.lan dovranno essere editati ogniqualvolta cambia l’assegnazione dell’indirizzo IP ad un host, per cui va a farsi benedire la comodità dell’utilizzo di un server DHCP; è evidente quindi che la situazione ideale consiste nell’assegnazione di indirizzi IP dinamici agli host e nel contestuale aggiornamento dinamico della corrispondenza indirizzo IP -> nome host. Per fortuna, in Linux ciò è possibile, poiché sarà il server DHCP, opportunamente configurato, ad effettuare gli aggiornamenti dinamici sul server DNS, il quale dev’essere configurato per accettare gli aggiornamenti inviati dal server DHCP.

Il primo passaggio della messa in opera della configurazione appena esaminata consiste nell’installazione ed attivazione del server DHCP, senza per il momento prendere in esame l’aggiornamento dinamico del server DNS; per installare il pacchetto dhcp3, utilizzare il solito apt:

# apt-get install dhcp3-common dhcp3-server

quindi, fare una copia di salvataggio del file di configurazione di esempio, crearne uno nuovo vuoto ed editarlo:

# mv /etc/dhcp3/dhcpd.conf /etc/dhcp3/dhcpd.old
# touch /etc/dhcpd3/dhcpd.conf
# nano /etc/dhcp3/dhcpd.conf

Ora, aggiungere un ambito DHCP con le opzioni del caso che ci permetta di distribuire i parametri della configurazione TCP/IP ai client della LAN, operazioni che si traducono nel seguente contenuto del file dhcpd.conf:

server-identifier 192.168.1.1;
ignore client-updates;

subnet 192.168.1.0 netmask 255.255.255.0
        {
        range 192.168.1.100 192.168.1.150;
        option subnet-mask 255.255.255.0;
        default-lease-time 604800;
        max-lease-time 2592000;
        option broadcast-address 192.168.1.255;
        option routers 192.168.1.254;
        option domain-name-servers 192.168.1.1;
        option domain-name "test.lan";
        option netbios-name-servers 192.168.1.1;
        option netbios-node-type 8;
        }

A questo punto, far partire (o ripartire) il demone dhcp3-server per attivare la configurazione:

# /etc/init.d/dhcp3-server start

Giunti fin qui, rimangono da configurare gli aggiornamenti dinamici del server DNS. In questo caso, come già esposto, sarà il server DHCP ad aggiornare dinamicamente il server DNS, al quale dovremo dire che sono consentiti gli aggiornamenti dinamici solamente da parte degli host coinvolti nel processo. In questo caso, ipotizzando che DNS e DHCP siano sulla stessa macchina, abiliteremo solamente localhost all’aggiornamento dinamico del server DNS, e come ulteriore misura di sicurezza, specificheremo che l’aggiornamento delle zone coinvolte avverrà solamente utilizzando una chiave segreta che viene creata automaticamente all’installazione di Bind ed il cui nome file è /etc/bind/rndc.key. Il primo passaggio consiste nel modificare il file /etc/bind/named.conf per indicare che il server DNS accetta aggiornamenti dinamici solamente da localhost utilizzando la chiave segreta:

include "/etc/bind/rndc.key";

controls {
        inet 127.0.0.1 allow {localhost; } keys { "rndc-key"; };
};

Un’ulteriore modifica da fare al file /etc/bind/named.conf è relativa alle zone create in precedenza, poiché anche in esse è necessario indicare che è possibile l’aggiornamento solamente tramite l’utilizzo della chiave segreta:

zone "test.lan" {
        type master;
        file "/etc/bind/db.test";
        allow-update { key rndc-key; };
};

zone "1.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.192.168.1";
        allow-update { key rndc-key; };
};

Fatto questo, far ripartire il demone bind9. Ora, rimane da configurare il server DHCP, il quale sarà incaricato di effettuare gli aggiornamenti sul server DNS, e che quindi dovrà obbligatoriamente "autenticarsi" su Bind utilizzando la chiave segreta /etc/bind/rndc.key. Ciò si traduce nell’aggiunta delle seguenti opzioni nel file di configurazione /etc/dhcp3/dhcpd.conf:

ddns-update-style interim;
ddns-domainname "test.lan.";
ddns-rev-domainname "in-addr.arpa.";
include "/etc/bind/rndc.key";
authoritative;

zone 1.168.192.in-addr.arpa. {
        primary 192.168.1.29;
        key rndc-key;
        }

L’ultimo passaggio consiste nel rendere la directory /etc/bind scrivibile anche per l’utente bind, in modo tale che Bind possa creare i file di zona con estensione .jnl che contengono i record DNS generati dinamicamente tramite l’aggiornamento di Bind da parte del server DHCP:

# chmod 775 /etc/bind

Ora, un riavvio del demone dhcp3-server completerà l’opera, ed avremo una rete con i PC che prendono la configurazione IP da un server DHCP, il quale aggiorna dinamicamente il server DNS in modo tale che tutte le operazioni di risoluzione dei nomi host avvengano correttamente sull’intera rete locale. Il vantaggio di questa soluzione è l’elevata automatizzazione dei processi descritti, che comporta un intervento dell’amministratore di sistema che si limita alla configurazione iniziale ed alla normale manutenzione del server, senza dover svolgere noiosi, inutili e ripetitivi aggiornamenti manuali.

Aggiornamento: ringrazio Croccobiscotto per avermi segnalato tramite un suo articolo una mia dimenticanza che riguarda l’aggiunta della direttiva "authoritative;" alla configurazione del server DHCP, la quale, da quel che ho letto, va indicata se il server DHCP è quello "ufficiale" della rete locale. Devo dire che al momento ho in "produzione" un solo server DHCP con Linux su cui avevo inserito a suo tempo la direttiva, facendo qualche prova a casa non ho inserito la direttiva ed il server DHCP e gli aggiornamenti dinamici funzionavano comunque bene, certo è che le prove che posso fare a casa non sono molto significative.

Se si dispone di uno o più indirizzi IP pubblici statici con la propria connessione ad Internet, è abbastanza consueto che si voglia approfittarne per pubblicare un proprio server Web, un proprio server di posta, o altri servizi che necessitano di un IP pubblico statico, come una VPN. In questi casi, una buona politica di sicurezza è far passare tutto il traffico diretto verso uno di questi servizi pubblicati attraverso un firewall, che poi ridirigerà le richieste verso un server posto verso la rete "interna", che prenderà il nome di DMZ (zona demilitarizzata), una rete "intermedia" che è posta tra la rete pubblica (Internet) e la rete locale e su cui saranno posti solamente quei server che devono pubblicare servizi verso Internet, oltre ad un eventuale firewall che connetta LAN e DMZ.

Per fare in modo che il firewall "esterno" rediriga le richieste verso il/i server in DMZ, esiste un meccanismo chiamato "port forwarding", che dal firewall esterno riceve la comunicazione in ingresso su una determinata porta con un determinato protocollo di trasporto, e la "rimbalza" verso il server in DMZ con lo stesso protocollo di trasporto e su una porta che spesso è identica a quella della richiesta originaria, ma che può anche cambiare.

Se si utilizza un firewall Linux, il port forwarding è impostato tramite iptables, che oltre a fungere da firewall è perfettamente in grado di gestire anche la redirezione del traffico. In particolare, si prenda in esame una configurazione di iptables come quella mostrata qui, dove la cosa di cui tenere conto quando si configura il port forwarding, è che il comportamento predefinito relativo alla catena di FORWARD consiste nel blocco del traffico, per cui, oltre all’istruzione necessaria per indicare la redirezione vera e propria, è necessario impostare una regola di FORWARD  che abilita il traffico dall’interfaccia esterna (eth1) alla DMZ (la cui interfaccia di rete definita sul firewall Linux è eth0) solamente per il tipo di richiesta necessaria. Si consideri la pubblicazione di un server Web che risponde alla canonica porta 80, e la cui interfaccia di rete in DMZ ha indirizzo IP 192.168.20.1; questa esigenza viene soddisfatta scrivendo queste due righe di configurazione di iptables:

iptables -A FORWARD -i eth1 -o eth0 -p tcp –dport 80 -j ACCEPT
iptables -A PREROUTING -t nat -p tcp -i eth1 –dport 80 -j DNAT –to 192.168.20.1:80

A questo punto, se dall’esterno si digita in un browser l’indirizzo IP (o il corrispondente nome host) dell’interfaccia eth1, si vedrà il sito pubblicato tramite il port forwarding di iptables.

Può capitare, avendo un sito web composto da diverse directory e/o sottodirectory, di dover consentire l’accesso ad una particolare directory solamente ad alcuni utenti. Avendo un web server come Apache su piattaforma Linux (le informazioni indicate di seguito le ho provate su una Debian Etch), è possibile utilizzare un file .htaccess, da creare nella directory a cui si vuole limitare l’accesso, per raggiungere lo scopo prefisso.

Il primo passo consiste appunto nella creazione del file .htaccess e nell’assegnazione dei corretti permessi al file stesso:

# touch /var/www/sito/dirProtetta/.htaccess
# chmod 644 /var/www/sito/dirProtetta/.htaccess

Fatto questo, editare il file .htaccess col proprio editor preferito inserendo queste righe:

AuthName "Area protetta"
AuthType Basic
AuthUserFile /var/www/sito/dirProtetta/.htpasswd
<Limit GET PUT POST>
Require valid-user
</Limit>

L’istruzione nella prima riga rappresenta il titolo della finestra di richiesta autenticazione, la seconda riga indica invece il tipo di autenticazione alla directory, cioé l’autorizzazione di tipo Basic, che consente il passaggio in chiaro del traffico di autenticazione, a differenza dell’autenticazione di tipo Digest; la terza riga specifica il percorso del file .htpasswd, che altri non è che il file contenente le accoppiate username -> password degli utenti a cui è consentito autenticarsi. Di seguito abbiamo il tag <Limit>, con gli attributi GET, PUT e POST che rappresentano le operazioni consentite in relazione alla directory (rispettivamente download, upload e invio informazioni tramite form), al cui interno vi è l’istruzione "Require valid-user" che dice ad Apache di consentire l’accesso alla directory solamente agli utenti riconosciuti come validi, cioé che hanno fornito le corrette credenziali d’accesso.

Eseguiti questi passaggi, bisogna creare gli utenti del caso tramite il comando htpasswd. La creazione del primo utente comporta anche la creazione del file .htpasswd, tramite questo comando:

# htpasswd -c /var/www/sito/dirProtetta/.htpasswd utente1

Digitato questo comando, verrà chiesta per due volte la password da assegnare all’utente, e contestualmente verrà creato il file .htpasswd nella directory specificata con l’opzione -c; a questo file vanno assegnati adeguate autorizzazioni, in particolare il gruppo www-data (il gruppo che contiene l’utente omonimo che esegue il demone apache2) dovrà poter accedere al file almeno in lettura:

# chown root:www-data /var/sito/dirProtetta/.htpasswd
# chmod 640 .htpasswd

Ora possiamo creare gli altri utenti in questo modo:

# htpasswd /var/www/sito/dirProtetta/.htpasswd utente2

Creati gli utenti, abbiamo fatto quasi tutto; l’ultimo passaggio consiste nel modificare la configurazione di Apache in modo tale che sia consentito l’accesso ai file .ht per la directory che vogliamo proteggere, infatti, almeno in Debian (non so se è così anche con altre distribuzioni), l’accesso ai file .ht è inibito per default, quindi bisogna dire ad Apache che vogliamo sovrascrivere questa impostazione limitatmente alla directory specifica. In particolare, cercare all’interno del file /etc/apache2/apache2.conf il tag <Files> in modo tale che la configurazione finale sia questa:

<Files ~ "^\.ht">
    Order allow,deny
    Deny from all
</Files>

<Directory /var/www/sito/dirProtetta/>
    AllowOverride AuthConfig Limit
</Directory>

dove il tag <Directory> rappresenta appunto la sovrascrittura delle impostazioni date all’interno del tag <Files>.

E’ tutto, ora quando un utente accede a questa particolare directory del sito si ritroverà davanti alla richiesta di inserimento di username e password che Apache dovrà autenticare o meno.