Archivi tag: vsftpd

Abilitare FTPS esplicito su VSFTPD

Sicurezza, , , , , , ,

Scenario

Il server FTPS esplicito (ovvero che utilizza la porta canonica TCP 21 per la ricezione dei comandi) si trova dietro un firewall, che filtra sia i tentativi di connessione in ingresso che quelli in uscita. Inoltre, tale firewall è nattato su indirizzo IP pubblico mediante uno screened router.

Anche il client è posizionato dietro un’accoppiata firewall/screened router e proprio per questo motivo si è deciso di utilizzare la modalità FTP passiva piuttosto che quella attiva.

Generazione del certificato

Ecco il comando per generare il certificato X.509 da utilizzare per l’autenticazione della fonte e per la confidenzialità:

nightfly@nightbox:~$ sudo openssl req -new -x509 -nodes -out vsftpd.pem -keyout vsftpd.pem

 

vsftpd, ftps, x.509, ssl, tls, filezilla client, fireftp, SmartFTP client

Configurazione del demone vsftpd

La configurazione del demone vsftpd per abilitare FTPS prevede le seguenti direttive:

rsa_cert_file=/etc/vsftpd.pem
rsa_private_key_file=/etc/vsftpd.pem

ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=NO
force_local_logins_ssl=YES

ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO

require_ssl_reuse=NO
ssl_ciphers=HIGH

pasv_address=<IP Pubblico Screened Router>
pasv_min_port=5012
pasv_max_port=5012

Le prime due righe servono a specificare il pathname del certificato e della chiave privata (a sua volta contenuta nel certificato).

La direttiva:

force_local_data_ssl=NO

fa in modo che il traffico dati non venga cifrato (preferisco usare questa impostazione perchè garantisce una maggiore velocità di trasferimento, l’importante è che vengano cifrati i comandi inviati al server e dunque anche le credenziali di accesso).

Come si evince dallo stralcio di configurazione che ho riportato, il protocollo di cifratura utilizzato è TLS (più robusto del suo predecessore SSL, il quale è stato esplicitamente disabilitato), mentre nelle ultime due righe ho specificato la porta su cui il client potrà instaurare la connessione dati. Tale porta dovrà essere consentita sul firewall, lanciando, ad esempio, il seguente comando (nel caso in cui si abbia a che fare con Netfilter):

iptables -A INPUT -i eth1 -m state --state NEW -m tcp -p tcp --dport 5012 -j ACCEPT

Inoltre, utilizzando il seguente paramentro di configurazione:

pasv_address=<IP Pubblico Screened Router>

si fa in modo che il server risponda al comando PASV inviando l’indirizzo IP pubblico dello screened router anzichè il proprio indirizzo privato. Inoltre, sarà necessario creare, direttamente sul router, un’opportuna regola di port forwarding per la porta TCP 5012.

Occorre precisare che la suddetta direttiva implica che su Netfilter venga abilitato il traffico in ingresso sulla porta in questione, poichè il modulo nf_conntrack_ftp funziona solo ed esclusivamente per i pacchetti che contengono gli indirizzi IP privati della linux box che funge da firewall.

Riavviamo vsftpd:

nightfly@nightbox:~$ sudo service vsftpd restart

e proviamo a connetterci al server, utilizzando un client che supporta FTPS. A tal proposito, vi sconsiglio di utilizzare FireFTP (in quanto presenta diversi bug relativi al protocollo FTPS) e FileZilla Client (perchè pialla la connessione se individua un certificato X.509 non firmato da una CA).

Solo con scopi di test (e per un periodo limitato) potete utilizzare un prodotto shareware, ovvero SmartFTP Client (lo trovate qui).

Enjoy.

Aggiornamento #1

A quanto pare le ultime versioni di FileZilla Client (quella che ho testato personalmente è la 3.17.0.1), consentono le connessioni verso il server FTPS anche in presenza di un certificato X.509 self-signed, a patto che all’interno della configurazione di VSFTPD vi sia la direttiva ssl_ciphers=HIGH.

Realizzare un honeypot con VSFTPD

Sicurezza, , , ,

Stanco ormai dei numerosissimi attacchi bruteforce basati su dizionario e diretti al mio server FTP, ho deciso di realizzare un piccolo honeypot utilizzando vsftpd e PAM.

honeypot, pam, vsftpd, pam_storepw.so, pam_logpw.so

Per prima cosa ho installato tutte le librerie necessarie per compilare una versione modificata di pam_storepw.so, il cui sorgente potete scaricarlo da qui.

I comandi che ho lanciato sono i seguenti:

nightfly@nightbox:~$ sudo apt-get install libpam0g-dev

Successivamente ho compilato e linkato il sorgente, digitando:

nightfly@nightbox:~$ gcc -c -fpic chng-pam_storepw.c
nightfly@nightbox:~$ gcc -shared -lc -o pam_logpw.so chng-pam_storepw.o
nightfly@nightbox:~$ sudo mv pam_logpw.so /lib/security/

Adesso che il modulo pam_logpw.so è finalmente pronto per l’uso, non mi resta che modificare il file /etc/pam.d/vsftpd, il cui contenuto dovrà essere il seguente:

@include common-password

auth    required       pam_unix.so obscure sha512
auth    optional        pam_logpw.so

Riavviamo vsftpd per rendere effettive le modifiche appena apportate:

nightfly@nightbox:~$ sudo service vsftpd restart

In particolare, le credenziali digitate dall’attaccante per accedere allo spazio FTP verranno salvate nel file /var/log/passwords, il cui contenuto sarà simile al seguente:

host = 88.11.22.33 : username = guest : password = sdinna

ATTENZIONE

questo file registrerà in chiaro anche le credenziali di accesso corrette (ovvero le vostre e quelle degli utenti leggittimi). Per questa ragione vi sconsiglio di utilizzare vsftpd per il trasferimento di file e di ripiegare quindi su SCP (a tal proposito un ottimo tool è rappresentato da WinSCP).

Una volta ottenuto il giusto numero di credenziali utilizzate per i login attempt, potrete ad esempio ricavare delle statistiche (username e password più utilizzate) che vi consentiranno eventualmente di risalire ai tipi di dizionario impiegati durante i tentativi di cracking.

Enjoy.

Creare uno spazio FTP condiviso tra due utenti

SO: Linux, , , , ,

Qualche giorno fa ho dovuto creare una directory FTP condivisa tra me ed un mio collega, da utilizzare come punto di riferimento per l’upload/download delle pagine Web che stiamo realizzando.

 

ftp_icon.png

Ecco la procedura:

per prima cosa occorre creare un gruppo, denominato gruppoweb, in cui inserire il nostro nome utente e quello utilizzato dal nostro collega.

Nella fattispecie, il comando da lanciare è il seguente:

nightfly@nightbox:~$ sudo groupadd gruppoweb

Successivamente è necessario aprire in scrittura il file /etc/group aggiungendo la seguente entry:

gruppoweb:x:1006:vostroutente,utentecollega

Dopodichè si devono apportare delle piccole modifiche al file di configurazione del demone FTP attivo sulla nostra Linux box (assumendo che si tratti di vsftpd). Tali modifiche riguardano il parametro umask e l’aggiunta della direttiva file_open_mode (il cui valore di default è 0666):

file_open_mode=0777
local_umask=0002

Così facendo tutti i file caricati mediante FTP avranno come permessi di default 775.

A modifica completata riavviamo il demone vsftpd:

nightfly@nightbox:~$ sudo service vsftpd restart

Infine, occorre scaricare un piccolo applicativo in grado di lanciare un determinato comando al verificarsi di un evento (trigger) nella directory da esso monitorata. Tale software prende il nome di incrond:

nightfly@nightbox:~$ sudo apt-get install incrond

Ad installazione avvenuta si dovrà rimuovere il file /etc/incron.allow (poichè insicuro, dato che per default tutti gli utenti possono utilizzare incrond):

nightfly@nightbox:~$ sudo rm /etc/incron.allow

e successivamente tale file dovrà essere ricreato con privilegi di root:

nightfly@nightbox:~$ su root
Password:
root@nightbox:/home/nightfly# nano /etc/incrond

aggiungendo la direttiva: 

root

A modifica completata soltanto root potrà utilizzare incrond.

Ora dobbiamo fare in modo che ad ogni modifica di una pagina preesistente oppure ad ogni upload di un nuovo file, venga lanciato il comando chown per definire il gruppo proprietario, ovvero gruppoweb.

Configuriamo dunque tale regola su incrond, lanciando il comando:

root@nightbox:/home/nightfly# incrontab -e

e successivamente modificando il file appena aperto nel seguente modo:

/var/www/dirshared/ IN_MODIFY,IN_CREATE chown :gruppoweb -R $@

dove la wildcard $@ rappresenta la directory monitorata (ovvero /var/www/dirshared).

Verifichiamo che la configurazione sia stata aggiornata digitando:

root@nightbox:/home/nightfly# incrontab -l

ed abbiamo finito.

A presto.

PS: sicuramente vi starete chiedendo perchè non ho creato un unico utente per accedere allo spazio FTP condiviso… bhè la risposta è semplice: perchè voglio controllare (e loggare) le operazioni effettuate da ciascun utente.

Swatch: configurazione per il monitoraggio dei server FTP (vsftpd)

Sicurezza, , , , , ,

Ecco la configurazione di swatch che sto utilizzando sui miei server per tenere d’occhio il demone vsftpd:

ignore /127.0.0.1/

#FTP File Status OK
watchfor  /150 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP File Status OK

#FTP Command Not Implemented
watchfor  /202 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Command Not Implemented

#FTP User Logged Out
watchfor  /221 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP User Logged Out

#FTP Directory Send OK
watchfor  /226 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Directory Send OK

#FTP User Logged In
watchfor  /230 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP User Logged In

#FTP Requested File Action Ok
watchfor  /250 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Requested File Action Ok

#FTP Service Not Avaliable
watchfor  /421 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Service Not Available

#FTP Can't Open Data Connection
watchfor  /425 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Can't Open Data Connection

#FTP Transfer Aborted
watchfor  /426 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Transfer Aborted

#FTP File Unvailable
watchfor  /450 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP File Unvailable

#FTP Command Unrecognized
watchfor  /500 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Command Unrecognized

#FTP Syntax Error
watchfor  /501 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Syntax Error

#FTP Command Not Implemented
watchfor  /502 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Command Not Implemented

#FTP Bad Sequence Of Commands
watchfor  /503 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Bad Sequence Of Commands

#FTP Login Incorrect
watchfor  /530 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Login Incorrect

#FTP Illegal File Name
watchfor  /553 /
     echo
     mail addresses=vostro.indirizzo@email.it,subject=SWATCH HOME: FTP Illegal File Name

 

ftp,vsftpd,simple watchdog,status code,logging,swatch,rc.local

Come potete notare, le espressioni regolari verificano che all’interno del file /var/log/vsftpd.log siano presenti gli status code tipici del protocollo FTP.

Occorre precisare, però, che per default vsftpd non prevede il logging degli status code. Per abilitare tale funzione occorre modificare il file /etc/vsftpd.conf nel modo seguente:

xferlog_enable=YES

log_ftp_protocol=YES

xferlog_std_format=NO

A modifica completata riavviamo il demone in questione:

nightfly@nightbox:~$ sudo service vsftpd restart

ed infine inseriamo una entry nel file /etc/rc.local in modo da rendere automatica l’esecuzione di swatch per il monitoraggio di vsftpd ad ogni avvio del sistema:

swatch -c /etc/swatchftp.conf -t /var/log/vsftpd.log

Ora anche vsftpd può definirsi “sotto controllo”.

Alla prossima.

PS: per una lista (semi)completa degli status code relativi al protocollo FTP, potete consultare questo link.

Gabbie chroot per gli utenti FTP mediante vsftpd.conf

SO: Linux, , , , ,

Recentemente mi è capitato di dover creare un nuovo account utente per l’accesso sul mio server FTP. Fin qui nulla di strano, è stato sufficiente digitare:

nightfly@nightbox:~$ useradd <nomeutente>

e successivamente:

nightfly@nightbox:~$ sudo passwd <password> <nomeutente>

 

vsftpd

A questo punto si è reso necessario ingabbiare l’utente nella sua home. Per fare ciò ho editato il file vsftpd.conf, che si trova nella directory /etc:

nightfly@nightbox:~$ sudo nano /etc/vsftpd.conf

decommentando (e dunque abilitando) la seguente opzione:

chroot_local_user=YES

Infine ho effettuato uno stop/start del demone vsftpd, digitando:

nightfly@nightbox:~$ sudo service vsftpd stop

nightfly@nightbox:~$ sudo service vsftpd start

e fine dei giochi.

PS: se volete cambiare la home directory dell’utente (che per default è /home/nomeutente), facendolo atterrare, ad esempio, in una sottodirectory di /var/www (per l’upload/download di pagine Web), vi basterà lanciare il comando:

nightfly@nightbox:~$ sudo usermod -d /var/www/nomecartella nomeutente

Se la directory /var/www/nomecartella esiste già, sarà necessario modificare il suo owner, partendo dal presupposto che essa abbia i permessi settati su 755:

nightfly@nightbox:~$ sudo chwon nomeutente:nomeutente /var/www/nomecartella

In alternativa, si potrebbe creare un gruppo ad hoc, chiamato ad esempio web, al quale associare i vari utenti che possono eseguire operazioni di lettura e scrittura su una data directory.

Per creare il gruppo occorre digitare:

nightfly@nightbox:~$ sudo groupadd nomegruppo

Successivamente aggiungiamo i vari utenti al gruppo, mediante il comando:

nightfly@nightbox:~$ sudo usermod -g web nomeutente

A procedura terminata, verifichiamo che gli utenti siano stati effettivamente aggiunti al gruppo, listandone il contenuto:

nightfly@nightbox:~$ sudo groups nomegruppo

Infine, possiamo modificare solo il gruppo proprietario della directory /var/www/nomecartella, digitando:

nightfly@nightbox:~$ sudo usermod :web /var/www/nomecartella

e cambiamo i permessi della directory, settandoli su 775:

nightfly@nightbox:~$ sudo chmod 775 /var/www/nomecartella

PPS: questa configurazione del file vsftpd.conf ingabbierà nella loro home tutti gli utenti di sistema che si collegheranno al server FTP. Se volete fare una selezione degli utenti che saranno ingabbiati e di quelli che non lo saranno, disabilitare l’opzione:

chroot_local_user=YES

commentandola o settandone il valore a NO:

#chroot_local_user=YES

In seguito abilitate l’opzione:

chroot_list_enable=YES

e specificate il file in cui è contenuta la lista degli utenti da ingabbiare, che per default è vsftpd.chroot_list:

chroot_list_file=/etc/vsftpd.chroot_list

Infine, inserite in questo file i nomi utente da chrootare (uno per riga).

A presto.

Verificare la presenza di una backdoor in vsftpd 2.3.4 su *buntu

Sicurezza, , , ,

Circa un mese fa è stata individuata una backdoor all’interno del sorgente di vsftpd, famoso demone FTP server.

vsftpd

  Questa backdoor consente l’accesso alla shell semplicemente digitando come username “X:)“, lasciando il campo password vuoto (maggiori dettagli sulla tarball compromessa li trovate qui). Avendo aggiornato vsftp alla versione 2.3.4 poco dopo il suo rilascio (orientativamente durante gli ultimi giorni di giugno), ho voluto verificare che il demone installato sui miei server non fosse infetto. Ho quindi cercato qualche tool che mi permettesse di effettuare tale controllo, trovando uno scrip per nmap che fa proprio al caso mio. Lo scrip in questione lo potete scaricare da qui. Una volta scaricato, modificatelo ed aggiungete una descripion, ad esempio:

descripion = "check vsftpd 2.3.4 backdoor vulnerability"

da inserire subito dopo categories. Ora assicuratevi che all’interno della directory /usr/share/nmap/nselib/ sia presente la libreria ftp.lua (in caso contrario potete scaricarla da qui). Infine, lanciate lo scrip seguendo la sintassi:

nmap --scrip ftp-vsftpd-backdoor -p 21 <host>

Se l’output di tale scrip sarà simile al seguente:

PORT   STATE SERVICE
21/tcp open  ftp
| ftp-vsftpd-backdoor:
|   This installation has been backdoored (CVE-2011-2523): VULNERABLE
|     Shell command: id
|_    Results: uid=0(root) gid=0(root) groups=0(root)

dovrete correre ai ripari sostituendo la versione “bucata” di vsftpd con quella corretta.

A presto.

PS: ho avuto fortuna, in quanto nessuno dei demoni vsftpd presenti sui miei server conteneva backdoor.

Installare vsftpd 2.3.4 su *buntu

SO: Linux, , , , ,

Dopo aver scoperto che tutte le versioni di vsftpd precedenti alla 2.3.4 (ovvero l’ultima release) sono vulnerabili ad attacchi di tipo DoS (Denial of Service), ho deciso di effettuare un upgrade del demone in questione.

vsftpd

 

Prima, però, mi sono sincerato che vsftpd non fosse già aggiornato, lanciando il comando:

nightfly@nightbox:~$ vsftpd -v

il cui output è stato il seguente:

vsftpd: version 2.2.2

Bene, come sospettavo, il demone non era aggiornato. Ho provato quindi un aggiornamento tramite aptitude:

nightfly@nightbox:~$ sudo apt-get update

nightfly@nightbox:~$ sudo apt-get upgrade

Lettura elenco dei pacchetti... Fatto
Generazione albero delle dipendenze
Lettura informazioni sullo stato... Fatto
0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.

Niente da fare, secondo aptitude, vsftpd è all’ultima versione.

Alla luce di ciò, ho proceduto con un’installazione manuale dello stesso.

Per prima cosa ho scaricato la tarball con i sorgenti puntando alla URL ftp://vsftpd.beasts.org/users/cevans/vsftpd-2.3.4.tar.gz

nightfly@nightbox:~$ wget ftp://vsftpd.beasts.org/users/cevans/vsftpd-2.3.4.tar.gz

Successivamente ho scompattato la tarball:

nightfly@nightbox:~$ tar -xzvf vsftpd-2.3.4.tar.gz

Mi sono quindi posizionato nella directory di riferimento:

nightfly@nightbox:~$ cd vsftpd-2.3.4

ed ho lanciato il comando:

nightfly@nightbox:~/vsftpd-2.3.4$ make

A questo punto, lanciando un ls ho notato la presenza del binario di vsftpd all’interno della directory.

Ho dunque proceduto con la sostituzione della versione precedente del demone, presente in /etc/init.d, con questa versione appena compilata, previo backup:

nightfly@nightbox:~/vsftpd-2.3.4$ cd /etc/init.d

nightfly@nightbox:/etc/init.d$ sudo mv vsftpd vsftpd.bak

Poi ho effettuato la sostituzione vera e propria:

nightfly@nightbox:/etc/init.d$ cd /home/nightfly/vsftpd-2.3.4

nightfly@nightbox:~/vsftpd-2.3.4$ sudo cp vsftpd /etc/init.d

Dopo aver fatto ciò, ho verificato che la versione di vsftpd fosse quella giusta:

nightfly@nightbox:~$ vsftpd -v

ricevendo come output:

vsftpd: version 2.2.4

Infine ho proceduto con il riavvio del servizio:

nightfly@nightbox:~$ service vsftpd restart

Ed ecco che il mio server FTP risultava finalmente patchato.

Alla prossima.