Utilizzare Rsync per sincronizzare directory Linux e Windows

Il demone Rsync nativo in ambiente Unix/Linux, è particolarmente efficace per la sincronizzazione di Filesystem e quindi per mantenere allineati “contenitori” differenti.

Può essere utilizzato per sincronizzare sorgenti Linux verso destinazioni Linux, sorgenti Linux verso destinazioni Windows, sorgenti Windows verso destinazioni Linux, e perché no tra sorgenti e destinazioni Windows, anche se in questo scenario sono disponibili molti altri tool.

Rsync utilizza la porta 873/tcp quindi le sue connessioni sono facilmente identificabili e le regole da definire su un Firewall, ad esempio per la sincronizzazione tra un contenuto in rete interna e la DMZ, relativamente più semplici.

Un ulteriore vantaggio che Rsync offre è che vengono replicati soltanto i file o le parti di questi che effettivamente vengono modificate sulla sorgente, rendendo notevolmente leggero il traffico di rete, si adatta quindi bene a trasferimenti su connessioni geografiche con poca banda disponibile.

Replica Windows –> Linux

In questo scenario è riportata la configurazione per effettuare la replica di un albero di directory a partire da Windows verso un server Linux ( distribuzione Oracle Linux Enterprise 6.x ) Questa distribuzione è di fatto assimilabile ad una Centos o Redhat di pari versione.

la replica viene effettuata con cadenza di 4 ore ed originata dalla macchina Windows pertanto sul server Linux dovrà essere attivo un servizio Rsync in grado di ricevere le repliche e configurato “esponendo” la cartella che ospiterà i dati replicati.

Operazioni da effettuare lato Linux

  • installazione del servizio Rsync su Linux  – yum install rsync
  • attivazione del servizio Rsync a boot time del sistema operativo tramite Xinetd

per poter avviare automaticamente Rsync tramite Xinetd è necessario all’interno della cartella /etc/xinetd.d/ editare il file rsync e modificare la riga disable = yes in disable = no in questo modo il servizio Xinetd all’avvio attiverà il rsync con i parametri definiti nel file stesso

# default: off
# description: The rsync server is a good addition to an ftp server, as it
#       allows crc checksumming etc.
service rsync
{
disable = no
socket_type     = stream
wait            = no
user            = root
server          = /usr/bin/rsync
server_args     = –daemon
log_on_failure  += USERID

}

effettuata questa modifica è necessario editare il file /etc/rsyncd.conf ed impostare le opzioni con cui il servizio Rsync concede l’accesso ed espone le risorse.

[root@serverlinux]#vi rsyncd.conf
uid = root
read only = no
use chroot = no
transfer logging = true
log format = %h %o %f %l %b
log file = /var/log/rsyncd.log

[DESTINAZIONE_REPLICA]
read only = no
path = /CARTELLA_DESTINAZIONE_REPLICA
hosts allow = a.b.c.d

in questo file si dovrà dichiarare tra [] il nome della risorsa a cui riferirsi quando verrà inviata la replica, il path della risorsa, le modalità con cui viene consentito l’accesso, gli hosts che possono utilizzarla, il log etc.

Operazioni da effettuare lato Windows

  • Recuperare ed installare i software Rsync per windows qui dove sono disponibili due versioni; free e commerciale
  • Installare il software sull’host windows ( per il caso descritto non è necessario installarlo come servizio )
  • creare un file batch strutturato come segue
  • rsync -vr –delete-after /cygdrive/c/ARCHIVIO_SORGENTE utente@server::DESTINAZIONE_REPLICA

modifica dei permessi

le opzioni utilizzate nel comando Rsync sono le seguenti

  • -v log completo
  • -r ricorsione nelle sottodirectory
  • –delete-after questa opzione cancella i files non più necessari sulla destinazione dopo aver fatto la sincronizzazione, di default vengono cancellati durante la sincronizzazione
  • /cygdrive/c/ARCHIVIO_SORGENTE utilizza un percorso “linux like”  su ambienti Windows tramite Cygwin
  • utente@server::CARTELLA_DESTINAZIONE_REPLICA utente di accesso al server di destinazione seguito dal riferimento alla risorsa utilizzata da Rsync sulla destinazione per archiviare il files.

 

Tramite il task scheduler di windows, attivare il batch creato per eseguire la replica con la frequenza desiderata della cartella, dal server windows al server linux.

 

Riferimenti:

http://rsync.samba.org/

una sezione interessante per alcuni esempi proposti

http://rsync.samba.org/examples.html

Rsyncd per ambiente Windows

https://www.itefix.no/i2/cwrsync-get

Postfix Rimappare il Return-Path di un mittente di posta

Nell’utilizzo di POSTFIX come mail server può essere necessario rimappare il formato del nome utente/dominio, ad esempio se il server deve inviare notifiche all’esterno di una amministrazione.

Un semplice modo con cui si può effettuare la rimappatura dell’indirizzo è il seguente.

  • Editare il file /etc/postfix/main.cf
    • individuare la stringa smtp_generic_maps  se non presente inserirla nel seguente formato  smtp_generic_maps = hash:/etc/postfix/generic
  • esecuzione del comando
    • postmap /etc/postfix/generic
  • riavvio del servizio postfix

La configurazione definita fa si che il campo Return-Path: dell’ Header SMTP diventi utente@nuovo.dominio.it anziché il default utente@dominio.locale

Definizione di una Global Address List su Active Directory per Zimbra (7.2)

A seconda delle esigenze Zimbra può essere utilizzato per ottenere l’elenco degli utenti da una Global Address List esterna oppure interna, nel primo caso la GAL può riferirsi  analogamente a come avviene per l’autenticazione, ad un dominio AD.

La configurazione della GAL esterna è abbastanza semplice e richiede pochi minuti

Dal menu di  configurazione del dominio sul server Zimbra è sufficiente scegliere Configura GAL

imagequi a fianco è riportata una configurazione minima per l’accesso, ossia con GAL solamente esterna, ma si può effettuare una configurazione con accesso sia all’elenco interno che esterno.

il tipo di server è stato definito Active Directory ed il server di riferimento è un Global Catalog, quindi in porta 3268

è possibile specificare un intervallo temporale con  cui la GAL esterna viene aggiornata se il campo è lasciato senza impostazioni le ricerche vengono effettuate nel momento in cui un utente richiede l’elenco.

imageper poter funzionare correttamente è necessario impostare la Base DN nel formato DC=nome,DC=dominio

imageè richiesto poi un account per l’accesso alla struttura Active Directory per effettuare le ricerche, a tal fine è buona norma utilizzare un account appositamente definito in AD con permessi minimi e senza scadenza password, è consigliabile anche impostarlo in modo che l’accesso possa avvenire soltanto dal server Zimbra, in modo da evitare accessi inappropriati.

NON è richiesto che l’account abbia permessi di amministrazione.

Autenticazione di accesso su Zimbra (7.2) tramite Active Directory

Zimbra ha la possibilità di autorizzare i propri account esternamente prescindendo dal sistema di autenticazione locale al server, una delle possibilità offerte è di autorizzare  gli utenti riferendosi ad una sorgente Active Directory esterna.

E’ possibile specificare sorgenti esterne diverse per domini di posta diversi gestiti dallo stesso server

La configurazione è semplice, dal menù di gestione del dominio di posta ( in console di amministrazione) è sufficiente selezionare Configura Autenticazione  da qui, successivamente, selezionare Active Directory Esterna

Nei tre campi che vengono proposti dovremo inserire rispettivamente,

  • il nome del dominio AD tramite il quale viene autenticato l’utente
  • il nome FQDN del server AD
  • la porta su cui il servizio risponde, la porta è la 3268, ossia quella del servizio  Global Catalog, nel caso in cui il dominio Active Directory sia articolato in più server con funzioni differenti  è necessario che il servizio di autenticazione si riferisca ad un GC.

image_thumb1

proseguendo nella configurazione viene richiesto un riferimento al dominio AD, riferimento che dovrà essere fornito in termini di utente/pwd per effettuare un Test di autenticazione

image_thumb

Da questo momento, quando verrà creato un utente su zimbra,  se verrà creato con riferimento al dominio per cui si è definita l’autenticazione esterna,  accederà soltanto se fornirà le credenziali definite sul dominio AD

Dichiarazione del record SPF su DNS Bind

Sender Polcy Framework, per Microsoft  Sender ID, è un’implementazione disponibile sui principali  mailserver, nasce con lo scopo di consentire a chi riceve un messaggio di posta di verificare se l’host mittente è autorizzato all’invio del messaggio SMTP, e viceversa a chi è proprietario di un dominio di dichiarare quali sono i server autorizzati alla spedizione per quel dominio.

Il principio è semplice, se sto ricevendo un messaggio da utente@dominio.prova, alla ricezione controllo se l’ip che richiede la connessione per la consegna è elencato nel DNS server di dominio.prova .

Se la verifica è positiva il messaggio può considerarsi legittimo ed essere consegnato, diversamente spetterà alle regole impostate sul mio mailserver gestire il messaggio; annotarlo e consegnarlo, inviarlo ad un repository di messaggi potenzialmente spam etc.

Questa implementazione se utilizzata da tutti i gestori di posta eliminerebbe quasi totalmente lo SPAM, e per essere efficace richiede, come detto sopra, che mittente e destinatario la implementino; il primo esponendo su DNS un record opportunamente strutturato ed il secondo configurando il mailserver per leggere tale record alla ricezione di un messaggio.

La definizione di questo record non è particolarmente complessa, ed in aiuto troviamo in rete alcuni siti che dopo aver richiesto alcune informazioni lo compongono e lo rendono disponibile, un servizio on line utile a tale scopo è fornito da Microsoft a questo link.

image

il risultato prodotto è questo  v=spf1 mx mx:mx1.dominio.test mx:mx1.dominio.test ~all  a questo punto è sufficiente inserirlo tra “” come riga strutturata nel file .zone del dns BIND ( qui sotto ne è riportato un esempio )

mx1.dominio.test ed mx2.dominio.test sono i mailserver autorizzati per il dominio.

dominio.test.      IN TXT          “v=spf1 mx mx:mx1.dominio.test mx:mx1.dominio.test ~all 

il sito DNSSTUFF è utile per verificare la correttezza della configurazione.

Squid usato come Reverse Proxy per protezione di Exchange OWA

Qui di seguito, riporto una configurazione utilizzabile con Squid, in questo caso la 3.1.15, per consentire di anteporre un reverse proxy al vero e proprio server OWA.

Il vantaggio di questa architettura consiste nel non “esporre” in DMZ un server membro di Dominio, la configurazione proposta lavora con un server OWA di versione 2003 (non ho avuto modo di utilizzarla con altre versioni), ma può essere ripresa per proteggere servizi web che richiedono autenticazione ad esempio altri mailserver.

Il tunnel HTTPs viene terminato sul reverse proxy e da questo le richieste vengono inoltrate al server WEB in HTTP

Nel caso specifico di questa configurazione Squid è installato su un sistema OPENBsd ma può tranquillamente essere utilizzato su altre distribuzioni, unico accorgimento è che deve essere compilato con l’opzione ‘–enable-ssl’.

In rete sono disponibili numerosi pacchetti già preparati e pronti per l’installazione, queste distribuzioni, di solito sono compilate con un grande numero di opzioni, per la maggior parte non necessarie.

E’ consigliabile, dato che si utilizza a “protezione” di un servizio, che Squid sia compilato con le sole opzioni necessarie, questo al fine di rendere meno vulnerabile il sistema stesso.

in questo caso le opzioni di compilazione sono:

#squid –-v (comando per ottenere le info sull’installazione di Squid)

Output:

Squid Cache: Version 3.1.15
configure options: ‘–enable-ssl’ ‘–enable-err-language=eng’ ‘-disable-ipv6’ –enable-ltdl-convenience

File squid.conf

cache_effective_user squiduser
cache_effective_group wheel

https_port 443 accel vhost cert=/usr/local/squid/certificato/dns1.crt key=/usr/local/squid/certificato/dns1.key # cert e key sono il certificato e la chiave con cui viene attivato SSL il certificato e relativa chiave devono essere generati in precedenza
cache_peer 10.1.1.1 parent 80 0 no-query originserver login=PASS proxy-only # cache_peer è il riferimento al server a cui squid redirige le chiamate in ingresso

front-end-https=auto name=webmail
redirect_rewrites_host_header off

acl TUTTI src all #definizione ACL chiamata TUTTI con source all ossia accesso libero alla cache Squid
http_access allow TUTTI #consente accesso all’ ACL TUTTI alla cache

#definizione della posizione dei log del formato e della rotazione
logfile_rotate 30
emulate_httpd_log on
log_mime_hdrs off
access_log /var/log/squid/log/access.log
cache_store_log /var/log/squid/log/store.log
cache_log /var/log/squid/log/cache.log

#definizione della posizione della cache
cache_dir ufs /var/log/squid/cache 100 16 256
cache_mem 50 MB
pid_filename /var/run/squid.pid

riferimenti:

http://wiki.squid-cache.org/SquidFaq/ReverseProxy

http://wiki.squid-cache.org/ConfigExamples/Reverse/VirtualHosting

http://wiki.squid-cache.org/ConfigExamples/Reverse/OutlookWebAccess

Eseguire un controllo su filtro SPAM

A volte può essere utile verificare se un server mail o meglio il suo motore antispam è funzionante.

Spamassassin ed Office 365 sono  “testabili” con un semplice messaggio di posta

Lo scopo del test è simile  a quanto si può effettuare con il file EICAR per  i prodotti antivirus. Ossia attivare le varie regole, o più semplicemente attivare il motore antispam

E’ sufficiente inserire la seguente stringa all’interno del corpo di un messaggio email ed inviarlo ad un utente ospitato sul mail server da verificare

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

il messaggio una volta ricevuto dal mailserver, o meglio dal filtro antispam del mailserver, attiverà quest’ultimo secondo le impostazioni definite dall’amministratore.

http://en.wikipedia.org/wiki/GTUBE

https://technet.microsoft.com/it-it/library/jj200684(v=exchg.150).aspx

http://spamassassin.apache.org/gtube/