Di default il web server apache esegue gli script php di un sito con l’utente “www-data”. Per permettere ad uno script di memorizzare dati all’interno di una directory, allora i permessi di quest’ultima devono essere settati a 777 oppure il proprietario della cartella deve essere l’utente “www-data”. In questo caso, se sul vostro server web e’ attivo piu’ di un sito internet, allora uno script di un dominio potrebbe modificare i dati di un’altro. Come fare per ovviare a questo problema?  Eseguendo gli script di ogni sito con un utente distinto installando la suexec, mod_fcgid ed utilizzando il php in modalita’ cgi. Piu’ difficile a dirsi che a farsi, bastano difatti pochi comandi e qualche minuto per configurare il tutto:

1) Occorre disabilitare SELinux

setenforce 0

Editare il file /etc/selinux/config ed impostare SELINUX a ‘disable’

SELINUX=disabled

2) Installare mod_fcgid. Questo modulo  non e’ disponibile nel repository ufficiale di CentOS ma possiamo prelevarlo da un’altra fonte

cd /etc/yum.repos.d/
wget http://centos.karan.org/kbsingh-CentOS-Extras.repo

Editare /etc/yum.repos.d/kbsingh-CentOS-Extras.repo ed impostare gpgcheck a 0 ed enabled a 1 nella sezione [kbs-CentOS-Testing]:

[...]
[kbs-CentOS-Testing]
gpgcheck=0
enabled=1
[..]

Eseguire adesso questo comando

yum install mod_fcgid

4)
Commentare tutte le righe del file /etc/httpd/conf.d/php.conf (per evitare che il php venga caricato come modulo), anteponendo il carattere # ad inizio riga

5)
Adesso dovremo forzare il PHP a correggere il percorso del cgi in modo conforme alle specifiche PATH_INFO/PATH_TRANSLATED. Bastera’ aggiungere nel php.ini (/etc/php.ini) questa direttiva:

cgi.fix_pathinfo = 1

6) Creiamo l’utente con cui dovranno essere eseguiti gli script del sito

groupadd sito1
useradd -s /bin/false -d /var/www/sito1 -m -g web1 web1
chmod 755 /var/www/sito1

7) Creiamo la cartella che dovra’ ospitare i file del sito

mkdir -p /var/www/sito1/htdocs
chown sito1:sito1 /var/www/sito1/htdocs

Creiamo il wrapper che utilizzeremo per avviare il php e configurare mod-fcgid:

mkdir -p /var/www/fcgid-conf-sito1

9) Inseriamo queste righe nel file /var/www/fcgid-conf-sito1/sito1.conf

#!/bin/sh
export PHPRC=/etc/
export PHP_FCGI_MAX_REQUESTS=400
export PHP_FCGI_CHILDREN=2
exec /usr/bin/php-cgi

PHPRC,PHP_FCGI_MAX_REQUESTS e PHP_FCGI_CHILDREN sono opzionali e se verranno omessi sara’ impostato il valore di default. Sono utili per poter indicare il percorso del php.ini, permettendo cosi’ di utilizzare una configurazione diversa da sito a sito, oppure per definire il numero di child per processo ed il numero di richieste che puo’ gestire prima di terminare.

10) Impostiamo i corretti permessi/proprietario

chmod 755 /var/www/fcgid-conf-sito1/sito1.conf
chown -R sito1:sito1 /var/www/fcgid-conf-sito1

11) Creiamo in /etc/httpd/conf/httpd.conf la configurazione del sito

<VirtualHost *:80>
ServerName www.sito1.it
ServerAdmin postmaster@sito1.it
DocumentRoot /var/www/sito1/htdocs/

<IfModule mod_fcgid.c>
SuexecUserGroup sito1 sito1
PHP_Fix_Pathinfo_Enable 1
<Directory /var/www/sito1/htdocs/>
Options +ExecCGI
AllowOverride All
AddHandler fcgid-script .php
FCGIWrapper /var/www/fcgid-conf-sito1/sito1.conf .php
Order allow,deny
Allow from all
</Directory>
</IfModule>

# ErrorLog /var/log/apache2/error.log
# CustomLog /var/log/apache2/access.log combined
ServerSignature Off

</VirtualHost>

12) Salvare il file e riavviare il web server

/etc/init.d/httpd restart

In Parallels Plesk 9 attualmente abbiamo disponibili due MTA per gestire la posta: Qmail e Postfix.
Questa guida è stata testata con Plesk 9.2.3

Per vedere l’MTA attualmente configurato lanciare il comando:

/opt/psa/admin/sbin/mailmng –features | grep SMTP_Server

Per passare da qmail a postfix:

/usr/local/psa/admin/sbin/autoinstaller –select-release-current –install-component postfix

Per passare da postfix a qmail

/usr/local/psa/admin/sbin/autoinstaller –select-release-current –install-component qmail

Prima di eseguire il passaggio è necessario fermare l’MTA e processare completamente la coda dei messaggi.

In questa guida affronteremo la procedura per l’installazione del ORDBMS (Object-Relational Database Management System) PostgreSQL, sviluppato in varie fasi fin dal 1977. Il progetto iniziale si chiamava Ingres e venne sviluppato a Berkeley, presso l’Università della California.Nel 1986 continuò lo sviluppo del codice di Ingres, sempre a Berkeley, per realizzare un sistema di database relazionale ad oggetti chiamato Postgres. Nel 1996, il nome di Postgres venne cambiato in PostgreSQL, in virtù degli accrescimenti funzionali attuati.

Utilizzeremo la modalità d’installazione con i pacchetti debian.

Nello specifico dobbiamo utilizzare il seguente comando.

apt-get install postgresql-8.3

Il sistema vi installerà altri pacchetti aggiuntivi:

postgresql-client-8.3 postgresql-client-common postgresql-common

A questo punto se utilizziamo il client psql di postgresql per connetterci al DB, questo è il messaggio d’errore ricevuto:

psql -l
psql: FATAL:  Ident authentication failed for user “utente”

Il messaggio ci indica che l’utente con il quale stiamo tentando di accedere non è abilitato. In fase d’installazione è stato creato automaticamente l’utente postgres, con il quale, per il momento, possiamo accedere al server postgresql.

sudo su – postgres

psql -l
Lista dei database
Nome | Proprietario | Codifica
———–+————–+———-
postgres | postgres | UTF8
template0 | postgres | UTF8
template1 | postgres | UTF8
(3 rows)

Ora vediamo come configurare l’accesso ad altri utenti oltre a postgres. La modalità d’accesso ad un DB PostgreSQL viene stabilita dentro il file :

/etc/postgresql/versione/main/pg_hba.conf

Analizziamo il contenuto del file pg_hba.conf.

# Database administrative login by UNIX sockets
local all postgres ident sameuser

# TYPE DATABASE USER CIDR-ADDRESS METHOD

# “local” is for Unix domain socket connections only
local all all ident sameuser
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5

La prima riga identifica l’amministratore del DB, nel caso specifico postgres, mentre le altre righe sono di facile comprensione. Quello che va detto è riferito alla colonna METHOD, ovvero il metodo d’autenticazione del client, che differisce dai permessi sul DB.

Analizziamo i metodi d’autenticazione:

• trust: Permette a qualsiasi utente proveniente dall’host, indicato in CIDR-ADDRESS, di connettersi senza usare una password.
• reject: Nega automaticamente l’accesso per quell’host o quell’utente.
• password: Indica che deve esistere una password per ogni utente abilitato ad accedere dentro la tabella di sistema pg_shadow, la password viene inviata in chiaro.
• crypt: Simile al metodo password, solo che la password viene inviata criptata.
• krb5: Autenticazione mediante il sistema Kerberos.
• ident: Dovrebbe essere creata dentro il file pg_ident.conf una mappa con utente e password che hanno l’accesso. Con l’opzione sameuser indica che il client si può connettere solo al database che ha come nome lo stesso nome dell’utente. Deve essere, prima, creato un db e un utente con il superuser postgres.

Quindi nel nostro caso utilizzeremo il seguente schema:

# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD
local   all         all                                 password

A questo punto possiamo accedere con il nuovo utente creato.

Il servizio ftp viene utilizzato quotidiamente da milioni di utenti in tutto il mondo per aggiornare il proprio sito web. Non tutti sanno pero’ che sia l’autenticazione che il trasferimento dei dati avviene in ‘chiaro’, permettendo cosi’ a chi gestisce il tratto di rete che congiunge la vostra postazione al sito web (ci riferiamo ad esempio al vero e proprio gestore oppure ad un hacker) di poter catturare le credenziali di autenticazione o copiare i file  mentre vengono inviati sul sito. In questo precedente articolo

http://www.deec.it/wp-admin/post.php?action=edit&post=1152

Abbiamo visto come installare il servizio proftpd, ma vediamo ora come configurandolo per utilizzare il protocollo TLS garantendo cosi’ l’autenticazione e la comunicazione crittografata. In questo caso, se i nostri dati fossero catturati non potrebbero esser letti.

Per default in proftpd viene gia’ caricato il modulo mod_tls. Possiamo verificarlo accedendo nel file /etc/proftpd/modules.conf e cercando:

LoadModule mod_tls.c

Dobbiamo decommentare (eliminando il carattere # ad inizio riga) questa riga nel file /etc/proftpd/proftpd.conf

Include /etc/proftpd/tls.conf

Generiamo il certificato autofirmato in questo modo

openssl req -x509 -newkey rsa:1024 -keyout /etc/ssl/private/proftpd.key -out /etc/ssl/certs/proftpd.crt -nodes -days 365

Generating a 1024 bit RSA private key
………………………++++++
……………++++++
writing new private key to ‘/etc/ssl/private/proftpd.key’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [GB]:IT
State or Province Name (full name) [Berkshire]: Lazio
Locality Name (eg, city) [Newbury]: Frosinone
Organization Name (eg, company) [My Company Ltd]:Deec
Organizational Unit Name (eg, section) []: Reparto_Tecnico
Common Name (eg, your name or your server’s hostname) []: www.deec.it
Email Address []: luca@deec.it

N.B. Se l’appliazione “openssl” non viene trovata dovrete installare il paccehtto “openssl”. Si fa in questo modo “apt-get install openssl”

Decommentiamo queste direttive in /etc/proftpd/tls.conf

TLSEngine
TLSLog
TLSProtocol
TLSRSACertificateFile
TLSRSACertificateKeyFile
TLSOptions
TLSVerifyClient
TLSRequired

N.B. Impostando ad “on” il valore della direttiva “TLSRequired” il servizio accettera’ solamente connessioni TLS, impostandolo invece ad “off” allora gli utenti potranno collegarsi sia con il certificato che senza.

E riavviamo il servizio

/etc/init.d/proftpd restart