{"id":1341,"date":"2022-08-27T09:53:56","date_gmt":"2022-08-27T09:53:56","guid":{"rendered":"https:\/\/www.budus.it\/Blog\/?p=1341"},"modified":"2022-08-27T09:53:57","modified_gmt":"2022-08-27T09:53:57","slug":"rsync-inibire-accessi-indesiderati-da-localhost-127-0-0-1","status":"publish","type":"post","link":"https:\/\/www.budus.it\/Blog\/rsync-inibire-accessi-indesiderati-da-localhost-127-0-0-1\/","title":{"rendered":"RSYNC: Inibire accessi indesiderati da localhost (127.0.0.1)"},"content":{"rendered":"\n

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.<\/p>\n\n\n\n\n\n\n\n

Premesso che, ovviamente, anche il Firewall pu\u00f2 essere una soluzione, non necessariamente alternativa, \u00e8 comunque possibile inibire questo tipo di accessi spoofati<\/em> anche tramite la configurazione di RSYNC.<\/p>\n\n\n\n

In pratica nel LOG (\/var\/log\/rsync.log<\/code>) ci si trova messaggi di questo tipo:<\/p>\n\n\n\n

AAAA\/MM\/GG HH:MM:SS [PID] connect from localhost (127.0.0.1)\nAAAA\/MM\/GG HH:MM:SS [PID] rsync: safe_read failed to read 1 bytes [Receiver]: Connection reset by peer (104)                                                              \nAAAA\/MM\/GG HH:MM:SS [PID] rsync error: error in rsync protocol data stream (code 12) at io.c(285) [Receiver=3.1.3] <\/code><\/pre>\n\n\n\n
Queste connessioni risultano da localhost (cio\u00e8 dal Server stesso), tuttavia, ho il sospetto si tratti di connessioni provenienti dall’esterno in qualche modo malformate cos\u00ec da risultare da 127.0.0.1<\/em>; anche non sia cos\u00ec, trovo questi messaggi fastidiosi e ho voluto sopprimerli.<\/p>\n\n\n\n
Per inibire questi accessi indesiderati da localhost (127.0.0.1) \u00e8 necessario usare nel file \/etc\/rsyncd.conf<\/code> questa istruzione:<\/p>\n\n\n\n
hosts deny = localhost<\/code><\/pre>\n\n\n\n
Tuttavia, se si desidera tagliare la testa al toro<\/em> ed adottare un metodo pi\u00f9 sicuro e drastico, il metodo opposto – quello di stabilire quali hosts hanno diritto a collegarsi<\/strong><\/em> – \u00e8 decisamente meglio, ad esempio:<\/p>\n\n\n\n
hosts allow = 192.168.0.0\/255.255.0.0,10.9.8.0\/255.255.255.0<\/code><\/pre>\n\n\n\n
(la riga sopra \u00e8 solo di esempio, consente l’accesso a 2 reti distinte, ad esempio la LAN locale e la VPN; andr\u00e0 modificata secondo le proprie esigenze)<\/sub><\/p>\n\n\n\n
Un’altra riga che suggerisco di aggiungere per evitare accessi indesiderati<\/em> \u00e8 la possibilit\u00e0 di inibire la richiesta dell’elenco dei Moduli forniti dal Server RSYNC<\/strong><\/em> (i “Moduli” sono come degli account ai quali si associa una cartella con relative credenziali di accesso); lo si fa tramite questa istruzione:<\/p>\n\n\n\n
list = false<\/code><\/pre>\n\n\n\n
Anche questa istruzione concorre a rendere pi\u00f9 sicuro il Server RSYNC, perch\u00e9 le richieste “LIST” da parte di malintenzionati non riceveranno risposta, saranno ignorate e non appariranno nel LOG.<\/p>\n\n\n\n
Non attivarla significa che, da remoto, \u00e8 possibile ottenere l’elenco dei Moduli, quindi, con un banale<\/em> brute-force \u00e8 teoricamente possibile violare il sistema.<\/p>\n\n\n\n
A tale proposito, per proteggersi ulteriormente, consiglio l’installazione di Fail2Ban<\/a>.<\/p>\n\n\n\n
Giusto a titolo di esempio fornisco un template<\/em> di \/etc\/rsyncd.conf<\/code>:<\/p>\n\n\n\n
uid = <user>\ngid = <group>\nuse chroot = no\nmax connections = 3\nlist = false\n#reverse lookup = no\ntimeout = 60\n#hosts allow = 192.168.0.0\/255.255.0.0,10.9.8.0\/255.255.255.0\nhosts deny = localhost\nlog file = \/var\/log\/rsync.log\n\n[<MODULO>]\npath = \/...\/path\/modulo\ncomment = <description>\nauth users = <username>\nread only = no\nincoming chmod = Da+rwx,Fa+rw,Fa-x\nsecrets file = \/etc\/rsyncd.secrets\npost-xfer exec = \/usr\/local\/bin\/check_rsync_access.sh<\/code><\/pre>\n\n\n\n
Ovviamente gli elementi “<…>” vanno personalizzati, esistono delle istruzioni commentate<\/em> (quelle che iniziano con “#”) ed, infine, lo script da eseguire alla fine di ogni accesso (check_rsync_access.sh<\/code>) \u00e8 qualcosa di personalizzato e non indispensabile, pu\u00f2 essere omesso (nel mio caso ha lo scopo di sistemare i permessi<\/em> ed inviare una e-mail di notifica).<\/p>\n\n\n\n
Per chiarezza incollo anche un esempio:<\/p>\n\n\n\n
uid = utente\ngid = gruppo\nuse chroot = no\nmax connections = 3\nlist = false\nreverse lookup = no\ntimeout = 60\nhosts deny = localhost\nlog file = \/var\/log\/rsync.log\n\n[PROVA]\npath = \/mnt\/RSYNC\/PROVA\ncomment = Archivio RSYNC PROVA\nauth users = prova\nread only = no\nincoming chmod = Da+rwx,Fa+rw,Fa-x\nsecrets file = \/etc\/rsyncd.secrets<\/code><\/pre>\n\n\n\n
La riga:<\/p>\n\n\n\n
reverse lookup = no<\/code><\/pre>\n\n\n\n
Serve per inibire il tentativo di RSYNC di risolvere l’indirizzo IP del Client che si collega con un Hostname<\/em>; laddove i Client non sono perfettamente identificati da un Hostname<\/em> (cio\u00e8 chi si collega via Internet e non dalla LAN), pu\u00f2 evitare che nel LOG vengano notificati errori circa l’impossibilit\u00e0 di risolvere l’indirizzo<\/em>, un’altra faccenda fastidiosa.<\/p>\n\n\n\n
Giusto per completezza, vi dico anche che il file \/etc\/rsyncd.secrets<\/code> prevede questa sintassi, per ogni utente (ogni riga identifica un utente):<\/p>\n\n\n\n
<username>:<password><\/code><\/pre>\n\n\n\n
Ad esempio:<\/p>\n\n\n\n
prova:qwerty<\/code><\/pre>\n\n\n\n
(ovviamente suggerisco di utilizzare password ben pi\u00f9 sicure di “qwerty” !)<\/sub><\/p>\n","protected":false},"excerpt":{"rendered":"
Inibire accessi indesiderati al Server RSYNC.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[48,3,25,193,1,6],"tags":[111],"class_list":["post-1341","post","type-post","status-publish","format-standard","hentry","category-internet","category-networking","category-operating-system","category-security","category-senza-categoria","category-software","tag-rsync"],"_links":{"self":[{"href":"https:\/\/www.budus.it\/Blog\/wp-json\/wp\/v2\/posts\/1341","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.budus.it\/Blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.budus.it\/Blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.budus.it\/Blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.budus.it\/Blog\/wp-json\/wp\/v2\/comments?post=1341"}],"version-history":[{"count":4,"href":"https:\/\/www.budus.it\/Blog\/wp-json\/wp\/v2\/posts\/1341\/revisions"}],"predecessor-version":[{"id":1345,"href":"https:\/\/www.budus.it\/Blog\/wp-json\/wp\/v2\/posts\/1341\/revisions\/1345"}],"wp:attachment":[{"href":"https:\/\/www.budus.it\/Blog\/wp-json\/wp\/v2\/media?parent=1341"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.budus.it\/Blog\/wp-json\/wp\/v2\/categories?post=1341"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.budus.it\/Blog\/wp-json\/wp\/v2\/tags?post=1341"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}