Scelta di una buona password

Se il nostro server non permette open relay l’unico modo per poterlo utilizzare per inviare messaggi è sfruttare una utenza valida.

La regola base prevede di evitare, nella scelta di una password, nomi o termini ricavabili da vocabolario, quindi deve essere una sequenza più o meno casuale di caratteri alfanumerici maiuscoli e minuscoli, possibilmente con l’aggiunta di caratteri speciali.

La lunghezza della password costituisce un buon requisito per la robustezza, ad esempio una password lunga 4 caratteri è individuabile in circa 41 milioni di tentativi, mentre una password di 8 caratteri richiede nel caso peggiore 16*10^16 tentativi.

L’elenco completo di regole per la costruzione di una buona password è il seguente:

Non utilizzare nomi e vocaboli da dizionario o qualcosa che vi possa essere ricondotto (es. numero di telefono o data di nascita)
Utilizzo di caratteri alfanumerici maiuscoli e minuscoli
Utilizzo di caratteri speciali (possibilmente da utilizzare all’interno della password e non alla fine)
Evitare le ripetizioni di caratteri (maiuscoli o minuscoli) o numeri
Evitare di mettere consecutivamente sequenze di lettere solo maiuscole, solo minuscole o numeriche.

La prevenzione rispetto la compromissione di una password è una attività complessa, anche perché spesso è scelta dall’utente e l’amministratore ha poco margine di controllo sulla scelta.

Zimbra permette di definire delle regole, che permettono di validare la password scelta dall’utente

I tecnici Argonavis potranno fornirti informazioni tecniche e commerciali su Zimbra di cui potresti avere bisogno

Richiedi Informazioni

LibraESVA Graymail management

La maggior parte dei messaggi che riceviamo sono e-mail commerciali, newsletter o notifiche di social network.

Spesso accade che gli utenti che avevano scelto di ricevere questi messaggi, perdano interesse e considerino spam questi messaggi (che in realtà formalmente non lo sono) o che la funzionalità di rimozione pur presente, non funzioni.

La funzionalità Graymail management serve a bloccare questi tipi di messaggi.

Dopo una analisi dei messaggi ricevuti negli ultimi trenta giorni, una funzione Euristica calcola la probabilità che quel messaggio possa essere una Greymail e ci mostra quei messaggi che risultano essere più probabilmente spam.

Individuata la tipologia di messaggio ed inserita fra quelli bloccati, quel genere di mail verrà bloccata automaticamente, per quel dominio.

Potrebbe essere scambiata per una regola di blacklist, però spesso questi messaggi hanno mittenti o server mittenti diversi per lanci differenti, e la regola di blacklist non risulta essere efficace, mentre questa tecnica che si basa su una funzione euristica è efficace e blocca correttamente quella tipologia di messaggio.

I tecnici certificati su LibraESVA di Argonavis sono a tua disposizione per supportarti sull’utilizzo di LibraESVA

Richiedi Informazioni

Open Relay

Il protocollo SMTP, utilizzato per l’invio dei messaggi di posta non prevede una autenticazione, per poter inviare dei messaggi.
Come accade per la posta cartacea, nella busta o all’interno della lettera possiamo anche scrivere un mittente differente rispetto alla nostra identità.

Tuttavia mentre la società che si occupa di consegnare la posta cartacea guadagna per ogni messaggio inviato, e comunque il destinatario può riconoscere facilmente la grafia del mittente con la posta elettronica non avviene altrettanto.

Inoltre mentre l’ufficio postale non ha responsabilità sui messaggi inviati nel caso della posta elettronica, il server che invia dei messaggi indesiderati rischia di entrare in una blacklist pubblica (RBL) con la conseguenza che nessun messaggio spedito in seguito venga recapitato.

Per impedire l’invio tramite il proprio sistema è necessario far autenticare gli utenti prima di permettere l’invio. I server, ad esempio quelli dei provider telefonici, che permettono l’invio non autenticato vengono chiamati “open relay“.

In realtà gli operatori telefonici non operano completamente come open relay, perché ammettono messaggi di posta solamente dalle loro reti, quindi avrebbero modo di tracciare il loro cliente avendo l’associazione tra indirizzo ip e cliente.

Introdotto il concetto di “open relay” vediamo come configurare Zimbra per accettare posta dalla propria rete richiedendo l’autenticazione per messaggi che non provengono da queste reti.

Il comando corretto per configurare le reti trust ovvero quelle reti da cui vogliamo accettare posta senza autenticazione é:

su zimbra
postconf mynetworks
mynetworks = 127.0.0.0/8 <rete...1> <rete...n>

La rete 127.0.0.0/8 è obbligatoria e serve al funzionamento interno di Zimbra

Per verificare la configurazione attualmente in uso eseguire il comando

zmprov gs <nome server> zimbraMtaMyNetworks

Avremo in output l’elenco di reti considerate trust

Condividere rapidamente con più mailbox una risorsa in Zimbra

Zimbra non ha disposizione una rubrica del dominio disponibile in automatico per tutte le mailbox del dominio.

Una soluzione possibile è data dal creare in una mailbox una agenda da condividere poi con tutti gli altri utenti. Quando il numero di mailbox è elevato può risultare lungo condividere con gli strumenti messi a disposizione da Zimbra.

Questo script può dare un aiuto, infatti questo script crea la condivisione e la accetta automaticamente, riducendo il tempo necessario.

#!/bin/bash
# ------------------------------------------------------------------
# author: Angelo Penduzzu <apenduzzu@argonavis.it>
# ------------------------------------------------------------------
#
# Utente che possiede la risorsa da condividere
proprietario=""
# Utenti che riceveranno la condivisione della risorsa, se sono più indirizzi, separarli con uno spazio (es. test@domain.it test1@domain.it)
destinatario=""
# Cartella da condividere
cartella=""
# [Opzionale] Prefisso da visualizzare nel nome della risorsa condivisa 
prefisso=""
# [Opzionale] Suffisso da visualizzare nel nome della risorsa condivisa 
suffisso=""
#    (r)ead - search, view overviews and items
#    (w)rite - edit drafts/contacts/notes, set flags
#    (i)nsert - copy/add to directory, create subfolders action
#    (x) - workflow actions, like accepting appointments
#    (d)elete - delete items and subfolders, set \Deleted flag
#    (a)dminister - delegate admin and change permissions 
permesso=""
# Tipologie ammesse: appointment,contact,conversation,document,message,task
tipo=""
arr=( $destinatario )
for dest in "${arr[@]}"
do
    zmmailbox -z -m ${proprietario} mfg /"${cartella}" account ${dest} rwixd
    zmmailbox -z -m ${dest} cm --view ${tipo} -F# /"${prefisso}${cartella}${suffisso} ${proprietario}" /"${cartella}"
done

E’ possibile introdurre una variante, scegliendo di applicare in automatico a tutto il dominio. Per ottenere tutti gli utenti del dominio, usare:

destinatario=$( /opt/zimbra/bin/zmprov -l gaa <dominio> )

Cyan Secure Web in Italiano

Cyan Network ha annunciato il rilascio di Secure Web 2.1.27

A partire da questa versione, sia il WebUI e la reportistica del sistema sono disponibili in italiano. Visto il successo commerciale e la crescente quantità di clienti in Italia, hanno convinto gli sviluppatori a tradurre tutti i testi di italiano.

Su richiesta dei clienti, sono stati aggiunti alcuni nuovi report. In uno di questi report, è possibile vedere il tempo che un utente ha trascorso su un determinato dominio e la categoria a cui questo dominio appartiene. In un’altro report, si mostra quanto tempo un utente ha trascorso, per domini di primo livello (it, com, gov…).

Oltre a queste caratteristiche, sono stati corretti alcuni problemi che causavano un blocco quando si cercava di caricare grandi certificati o catene di certificati nel reverse proxy.

Il problema con la categoria ‘Humor’ che non riusciva ad essere filtrata correttamente è stato individuato e riparato.

Come al solito quando si effettua l’aggiornamento di Cyan Secure Web , si raccomanda di aggiornare Secure Web Authentication Service all’ultima versione disponibile. E comunque obbligatorio avere installata la versione 2.1.14 di Secure Web Authentication Service.

Nelle versioni virtual Appliance, si consiglia di effettuare uno snapshot prima effettuare l’aggiornamento e di consolidarlo appena è stato verificato che l’aggiornamento si è concluso con successo.

Se hai necessità di supporto per aggiornare la tua installazione o vuoi maggiori informazioni su Cyan Secure Web, Argonavis dispone di tutte le competenze tecniche e commerciali necessarie.

Richiedi Informazioni

Categorie