RSYNC: Inibire accessi indesiderati da localhost (127.0.0.1)

Avere un server RSYNC aperto su Internet espone ad attacchi al servizio da parte di malintenzionati piuttosto sgradevoli e comunque “sporca” il LOG. Ma esiste almeno una soluzione.

Premesso che, ovviamente, anche il Firewall può essere una soluzione, non necessariamente alternativa, è comunque possibile inibire questo tipo di accessi spoofati anche tramite la configurazione di RSYNC.

In pratica nel LOG (/var/log/rsync.log) ci si trova messaggi di questo tipo:

AAAA/MM/GG HH:MM:SS [PID] connect from localhost (127.0.0.1)
AAAA/MM/GG HH:MM:SS [PID] rsync: safe_read failed to read 1 bytes [Receiver]: Connection reset by peer (104)                                                              
AAAA/MM/GG HH:MM:SS [PID] rsync error: error in rsync protocol data stream (code 12) at io.c(285) [Receiver=3.1.3] 

Queste connessioni risultano da localhost (cioè dal Server stesso), tuttavia, ho il sospetto si tratti di connessioni provenienti dall’esterno in qualche modo malformate così da risultare da 127.0.0.1; anche non sia così, trovo questi messaggi fastidiosi e ho voluto sopprimerli.

Per inibire questi accessi indesiderati da localhost (127.0.0.1) è necessario usare nel file /etc/rsyncd.conf questa istruzione:

hosts deny = localhost

Tuttavia, se si desidera tagliare la testa al toro ed adottare un metodo più sicuro e drastico, il metodo opposto – quello di stabilire quali hosts hanno diritto a collegarsi – è decisamente meglio, ad esempio:

hosts allow = 192.168.0.0/255.255.0.0,10.9.8.0/255.255.255.0

_{(la riga sopra è solo di esempio, consente l’accesso a 2 reti distinte, ad esempio la LAN locale e la VPN; andrà modificata secondo le proprie esigenze)}

Un’altra riga che suggerisco di aggiungere per evitare accessi indesiderati è la possibilità di inibire la richiesta dell’elenco dei Moduli forniti dal Server RSYNC (i “Moduli” sono come degli account ai quali si associa una cartella con relative credenziali di accesso); lo si fa tramite questa istruzione:

list = false

Anche questa istruzione concorre a rendere più sicuro il Server RSYNC, perché le richieste “LIST” da parte di malintenzionati non riceveranno risposta, saranno ignorate e non appariranno nel LOG.

Non attivarla significa che, da remoto, è possibile ottenere l’elenco dei Moduli, quindi, con un banale brute-force è teoricamente possibile violare il sistema.

A tale proposito, per proteggersi ulteriormente, consiglio l’installazione di Fail2Ban.

Giusto a titolo di esempio fornisco un template di /etc/rsyncd.conf:

uid = <user>
gid = <group>
use chroot = no
max connections = 3
list = false
#reverse lookup = no
timeout = 60
#hosts allow = 192.168.0.0/255.255.0.0,10.9.8.0/255.255.255.0
hosts deny = localhost
log file = /var/log/rsync.log

[<MODULO>]
path = /.../path/modulo
comment = <description>
auth users = <username>
read only = no
incoming chmod = Da+rwx,Fa+rw,Fa-x
secrets file = /etc/rsyncd.secrets
post-xfer exec = /usr/local/bin/check_rsync_access.sh

Ovviamente gli elementi “<…>” vanno personalizzati, esistono delle istruzioni commentate (quelle che iniziano con “#”) ed, infine, lo script da eseguire alla fine di ogni accesso (check_rsync_access.sh) è qualcosa di personalizzato e non indispensabile, può essere omesso (nel mio caso ha lo scopo di sistemare i permessi ed inviare una e-mail di notifica).

Per chiarezza incollo anche un esempio:

uid = utente
gid = gruppo
use chroot = no
max connections = 3
list = false
reverse lookup = no
timeout = 60
hosts deny = localhost
log file = /var/log/rsync.log

[PROVA]
path = /mnt/RSYNC/PROVA
comment = Archivio RSYNC PROVA
auth users = prova
read only = no
incoming chmod = Da+rwx,Fa+rw,Fa-x
secrets file = /etc/rsyncd.secrets

La riga:

reverse lookup = no

Serve per inibire il tentativo di RSYNC di risolvere l’indirizzo IP del Client che si collega con un Hostname; laddove i Client non sono perfettamente identificati da un Hostname (cioè chi si collega via Internet e non dalla LAN), può evitare che nel LOG vengano notificati errori circa l’impossibilità di risolvere l’indirizzo, un’altra faccenda fastidiosa.

Giusto per completezza, vi dico anche che il file /etc/rsyncd.secrets prevede questa sintassi, per ogni utente (ogni riga identifica un utente):

<username>:<password>

Ad esempio:

prova:qwerty

_{(ovviamente suggerisco di utilizzare password ben più sicure di “qwerty” !)}