Archivi tag: sftp

Creazione di una logging facility mediante logrotate ed expect

Scenario

Diversi siti Web (Apache) con N virtual host, ciascuno dei quali utilizza 2 file di log dedicati (access ed error), per il salvataggio degli accessi (nel primo caso) e degli errori generati (nel secondo caso).

Problema

Data l’enorme mole di utenza, è necessario comprimere e salvare i suddetti file di log con cadenza settimanale, spostando l’archivio appena ottenuto su di una logging facility (nella fattispecie una linux box), utilizzando il protocollo SFTP.

Soluzione

Integrare lo scrip di logrotate con alcuni scrip expect fatti in casa.

logging-facility

Logrotate

Lo scrip logrotate che si occuperà della vera e propria rotazione dei file di log (con cadenza settimanale) è il seguente:

/var/log/httpd/*log {
    rotate 1
    missingok
    notifempty
    sharedscrips
    dateext
    compress
    copytruncate
    weekly
    postrotate
        /sbin/service httpd restart > /dev/null 2>/dev/null || true
    endscrip
    lastaction
        /root/logrotation/autoputlog/apache > /var/log/autoputlog/apache.log
    endscrip
}

/var/log/httpd/virtual/*/*log {
    rotate 1
    missingok
    notifempty
    sharedscrips
    dateext
    compress
    copytruncate
    weekly
    postrotate
        /sbin/service httpd restart > /dev/null 2>/dev/null || true
    endscrip
    lastaction
         /root/logrotation/autoputlog/apachecustom > /var/log/autoputlog/apachecustom.log
    endscrip
}

Nella fattispecie, la prima parte si occupa della rotazione dei file di log relativi alla root directory canonica di Apache, ovvero /var/www/html, mentre la seconda parte si occupa dei virtual host veri e propri.

I suddetti scrip ci permettono di integrare logrotate con expect grazie alla direttiva lastaction. In particolare, essa farà in modo che, una volta completata la rotazione (con la creazione di una tarball opportuna), venga eseguito lo scrip expect apache (nel primo caso) ed apachecustom (nel secondo caso), presenti nella directory /root/logrotation/autoputlog.

L’output realtivo al processo di esecuzione degli scrip in questione verrà salvato rispettivamente all’interno del file apache.log ed apachecustom.log, presenti in /var/log/autoputlog. Inoltre, sarà necessario creare i file in questione prima che la rotazione venga testata, utilizzando i comandi :

[root@frontend ~]# mkdir -p /var/log/autoputlog

e

[root@frontend ~]# touch apache.log apachecustom.log

Infine, di seguito riporto il contenuto dello scrip expect apache:

#!/usr/bin/expect
set timeout 60
set password "vostrapassword"
spawn sftp admin@iplogfacility:array1/logs/frontend1/httpd
expect "*?assword:*"
send "$password\r"
expect "sftp"
send "put /var/log/httpd/*.gz\r"
expect "sftp"
send "exit\r"
expect eof

ed apachecustom:

#!/usr/bin/expect
set timeout -1
set password "vostrapassword"
spawn sftp admin@iplogfacility:array1/logs/frontend1/httpd
expect "*?assword:*"
send "$password\r"
expect "sftp"
send "cd vhost1\r"
expect "sftp"
send "put /var/log/httpd/virtual/vhost1/*.gz\r"
expect "sftp"
send "cd ../vhost2\r"
expect "sftp"
send "put /var/log/httpd/virtual/vhost2/*.gz\r"
expect "sftp"
send "cd ../vhost3\r"
expect "sftp"
send "put /var/log/httpd/virtual/vhost3/*.gz\r"
expect "sftp"
send "exit\r"
expect eof

Non ci rimane che lanciare forzatamente logrotate per testarne il funzionamento, utilizzando il comando:

[root@frontend ~]# logrotate -f /etc/logrotate.d/httpd

ed abbiamo finito.

A presto.

Server SFTP multiutenza su CentOS 6

Scenario

Server Web su cui N sviluppatori hanno la necessità di caricare i nuovi contenuti. Poichè tale server risulta già raggiungibile via SSH, si vuole utilizzare il protocollo SFTP per il trasferimento dei file, sostanzialmente per due ragioni:

1) Esporre su Internet il minor numero di porte. Infatti, il protocollo SFTP sfrutta la stessa porta TCP del protocollo SSH (ovvero la 22);

2) SFTP è molto più robusto del File Transfer Protocol (FTP), in quanto garantisce alcuni meccanismi di sicurezza quali confidenzialità e soprattutto autenticazione della fonte.

 

sftp,ssh,user,group,chmod

Inoltre, la directory target di ogni sviluppatore è la medesima ed i file caricati da uno devono essere accessibili in lettura/scrittura da tutti gli altri (tenendo sempre traccia di chi-ha-fatto-cosa, ecco spiegato il perchè della necessità di un server SFTP multiutenza).

Preparazione della macchina

La prima cosa da fare è, ovviamente, creare le utenze per ciascun sviluppatore. E’ possibile fare ciò semplicemente utilizzando il comando useradd:

[root@serverWeb ~]# useradd devel1
[root@serverWeb ~]# useradd devel2
[root@serverWeb ~]# useradd devel3

A questo punto, è necessario settare la password di default per ciascuna utenza. Essa potrà essere modificata in un secondo momento dallo sviluppatore stesso:

[root@serverWeb ~]# echo 'devel1:passworddevel1'|chpasswd
[root@serverWeb ~]# echo 'devel2:passworddevel2'|chpasswd
[root@serverWeb ~]# echo 'devel3:passworddevel3'|chpasswd

Notate che ho utilizzato tale sintassi anzichè il classico comando interattivo:

[root@serverWeb ~]# passwd <nomeutente>

in quanto risulta più comoda nel caso in cui si dovessero creare molte utenze.

A questo punto creiamo il gruppo di che identificherà gli sviluppatori

[root@serverWeb ~]# groupadd web

e facciamo in modo che essi ne facciano parte (modificando il loro gruppo di default che è semplicemente uguale al nome utente scelto):

[root@serverWeb ~]# usermod -g web devel1
[root@serverWeb ~]# usermod -g web devel2
[root@serverWeb ~]# usermod -g web devel3

Infine, modifichiamo la home directory degli utenti appena creati, mediante il comando usermod (consentendo loro di atterrare direttamente sulla dir in cui dovranno essere caricati i contenuti Web):

[root@serverWeb ~]# usermod -d /var/www/html devel1
[root@serverWeb ~]# usermod -d /var/www/html devel2
[root@serverWeb ~]# usermod -d /var/www/html devel3

Posizioniamoci adesso nella dir /var/www/ e lanciamo i seguenti comandi:

[root@serverWeb ~]# chown root:web -R html
[root@serverWeb ~]# chmod 775 -R html
[root@serverWeb ~]# chmod g+s -R html

Con il primo comando abbiamo semplicemente modificato il gruppo proprietario della directory html; con il secondo comando abbiamo fatto in modo che tutti i file (e le subdirectory) garantiscano tutte le operazioni (read, write, execute) all’owner (root) ed al gruppo proprietario (web).

Infine, con il terzo comando, stiamo facendo in modo che qualunque nuovo file o directory che verrà creato all’interno di html abbia come proprietario il gruppo Web.

Configurazione di sshd

Questa è sicuramente “la parte facile” della guida, in quanto è sufficiente inserire una piccola flag all’interno del file di configurazione del demone SSH, ovvero /etc/ssh/sshd_config. In particolare, la entry:

Subsystem       sftp    /usr/libexec/openssh/sftp-server

dovrà diventare:

Subsystem       sftp    /usr/libexec/openssh/sftp-server -u 002

dove -u significa umask e rappresenta i permessi di default dei nuovi file e directory che verranno caricati mediante SFTP.

Riavviamo sshd:

[root@serverWeb ~]# service sshd restart

ed abbiamo finito.

Ora gli sviluppatori ci ringrazieranno.

Alla prossima.

File Transfer Protocol in tutte le salse

Chiunque abbia un background sistemistico avrà sentito parlare del File Transfer Protocol (FTP). Esso si basa sul protocollo TCP (lato trasporto) e dunque implica dei collegamenti di tipo affidabile. Inoltre, sfrutta le porte 20 e 21 (dette rispettivamente Data e Command), la prima per il trasferimento dei dati e la seconda per l’invio dei comandi.

Ma andiamo con ordine. Il suddetto protocollo può funzionare in 2 modalità:

1) attiva;

2) passiva.

Nel primo caso il client contatta il server sulla porta 21, inviandogli il comando PORT, in cui specifica appunto la porta ( >1023) su cui il server potrà provare a connettersi. A questo punto, dato che il server conosce la suddetta porta, lancerà un tentativo di connessione proveniente dalla porta 20 e diretta a quella precedentemente specificata dal client.

activeftp.gif

Nel secondo caso, invece, il client invia al server (sempre mediante la porta 21), il comando PASV (tentativo di connessione in modalità passiva) a cui il server risponde con il comando PORT (specificando una porta >1023). A questo punto sarà il client a tentare di instaurare la connessione dati verso la porta specificata dal server (a differenza di quanto avveniva nella modalità attiva).

passiveftp.gif

Ma quando utilizzare una o l’altra modalità? Semplice. Potrebbe accadere che il client si trovi dietro un firewall e che quindi i tentativi di connessione provenienti dal server vengano droppati. In questo caso è necessario utilizzare la modalità passiva, poichè in questo modo sarà sempre il client ad effettuare i tentativi di connessione, aggirando le restrizioni imposte dal suddetto firewall (essi, salvo eccezioni, solitamente non filtrano i tentativi di connessione in uscita da porte “alte”).

Avrete notato che la denominazione delle modalità avviene prendendo come punto di riferimento il server: se il traffico dati avviene mediante connessione instaurata dal server verso il client parliamo di modalità attiva; viceversa, se è il client ad effettuare la connessione dati verso il server parliamo di modalità passiva.

Ora, poichè il protocollo FTP è piuttosto datato, esso risulta abbastanza vulnerabile, soprattutto nei confronti operazioni di sniffing del traffico (poichè il trasferimento dati e l’invio di comandi viaggiano in chiaro).

Poprio per questo motivo negli anni si è cercato di correre ai ripari, creando dei meccanismi di cifratura che potessero garantire:

1) autenticazione della fonte;

2) confidenzialità.

Il primo tentativo di questo tipo prese il nome di SFTP (che sta per SSH File Transfer Protocol), ovvero un protocollo basato su SSH versione 2 (anche se esistono delle varianti basate su SSHv1, ma non tutti i client sono compatibili). Esso, più che un protocollo di trasferimento file, rappresenta una sorta di “file system remoto”, consentendo dunque di effettuare operazioni quali la creazione di nuove directory, la cancellazione dei file, ecc. Una restrizione del suddetto protocollo è rappresentata da SCP (Secure Copy), che consente solo il trasferimento dei file.

Entrambi i protocolli menzionati in precedenza, però, presentano una limitazione: necessitano di shell account per funzionare.

Proprio per evitare ciò è stato creato FTPS (FTP over SSL), che sfrutta i meccanismi di cifratura messi a disposizione dai protocolli SSL/TLS.

Esso può essere di due tipologie:

1) implicito;

2) esplicito.

Nel primo caso il server è in ascolto su una porta diversa dalla 21 (solitamente la 990) e tale tipologia è stata creata soprattutto per questioni di retrocompatibilità.

Nel secondo caso, invece, il server è in ascolto sulla classica porta 21 (FTP Command), ed accetta il comando esplicito AUTH <meccanismo di cifratura>, ad esempio AUTH TLS.

Dopo questa piccola premessa, prossimamente vedremo come abilitare FTPS su vsftpd.

A presto.