[WORKLOG] - Installazione e configurazione di un server di posta SOHO.

Pagina 2 di 4
prima
1 2 3 4 ultimo
Visualizzazione dei risultati da 11 a 20 su 33
  1. #11
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,114
    configurazione

    Predefinito 5.1_ Restrizione dell'accesso ai siti di amministrazione.

    Il file iRedMail.tips, riporta gli url dei siti configurati in apache e dai quali è possibile raggiungere la webmail e le altre applicazioni.
    Ad eccezione della webmail, nessuno degli altri siti relativi ai vari tool di amministrazione hanno necessità di essere raggiunti dall'esterno. Inoltre, la maggior parte di questi tool sono i più noti strumenti di amministrazione disponibili nel mondo linux e pertanto, analizzando i log dei server pubblicati è frequente vedere dei tentativi di raggiungere le homepage di accesso da parte di scanner e bot di vario tipo.
    E' quindi raccomandabile, come riportato anche nel wiki di iRedmail, restringere l'accessibilità di questi siti secondo le specifiche esigenze.
    Originariamente inviato da iRedMail.tips
    Roundcube webmail:
    []
    * URL:
    - http://server.fracassetti.lan/mail/
    - https://server.fracassetti.lan/mail/ (Over SSL/TLS)
    - http://server.fracassetti.lan/webmail/
    - https://server.fracassetti.lan/webmail/ (Over SSL/TLS)
    [...]
    * See also:
    - /etc/apache2/conf.d/roundcubemail.conf

    phpLDAPadmin:
    [...]
    * URL:
    - https://server.fracassetti.lan/phpldapadmin/
    - https://server.fracassetti.lan/ldap/
    [...]
    * See also:
    - /etc/apache2/conf.d/phpldapadmin.conf

    phpMyAdmin:
    [...]
    * URL:
    - https://server.fracassetti.lan/phpmyadmin
    * See also:
    - /etc/apache2/conf.d/phpmyadmin.conf

    Awstats:
    [...]
    * URL:
    - https://server.fracassetti.lan/awstats/awstats.pl
    - https://server.fracassetti.lan/awsta....pl?config=web
    - https://server.fracassetti.lan/awsta...pl?config=smtp
    [...]

    iRedAdmin - official web-based admin panel:
    [...]
    * URL:
    - https://server.fracassetti.lan/iredadmin/
    [...]
    * See also:
    - /etc/apache2/conf.d/iredadmin.conf
    Nel mio caso, tutti i siti devono essere raggiungibili solo dalla rete locale, ad eccezione della webmail che deve essere raggiungibile anche da internet.
    Dagli url indicati nel file, si vede anche che l'installer ha utilizzato per tutti i siti (e per la generazione del certificato SSL) il nome host che ho scelto di non modificare: Poco male, funziona tutto ma è poco elegante e comporta una segnalazione di errore nel browser quando si accede via SSL ad uno dei siti.
    Per correggere queste impostazioni, è necessario intervenire nella configurazione dei siti che si trova in apache. I files e le directory che ci interessano sono principalmente questi:

    Apache & PHP:
    * Configuration files:
    - /etc/apache2
    - /etc/apache2/apache2.conf
    - /etc/apache2/conf.d/*
    - /etc/php5/apache2/php.ini
    * Directories:
    - /usr/share/apache2
    - /var/www

    La restrizione di accesso ad un particolare sito/directory si può ottenere sfruttando il modulo di apache "authz_host". Per abilitarlo, è sufficiente lanciare il comando:
    codice:
    root@server:/etc/apache2# a2enmod authz_host
    Enabling module authz_host.
    Run '/etc/init.d/apache2 restart' to activate new configuration!
    ma io ce lo avevo già abilitato.

    La configurazione predefinita di apache prevede la creazione di un sito "default" che risponde a tutte le chiamate http che arrivano al server. I siti diventano due nel caso sia attivato anche il supporto ad SSL. La configurazione di questi siti è contenuta nei file disponibili nella directory "/etc/apache2/sites-available":
    codice:
    root@server:/etc/apache2# ls /etc/apache2/sites-available
    default  default-ssl
    Il file "default" gestisce il sito che risponde alle chiamate http, il file default-ssl l'equivalente per il protocollo SSL. Ogni applicazione fà riferimento ad una specifica sottodirectory, ciascuna delle quali dotata di un proprio files di configurazione. Per restringere l'accesso a queste directory, è sufficiente modificare una direttiva contenuta nel relativo file di configurazione:
    Originariamente inviato da /etc/apache2/conf.d/iredadmin.conf
    codice HTML:
    WSGISocketPrefix /var/run/wsgi
    WSGIDaemonProcess iredadmin user=iredadmin threads=15
    WSGIProcessGroup iredadmin
    
    AddType text/html .py
    
    <Directory /usr/share/apache2/iredadmin/>
        Order allow,deny
        Allow from all
    </Directory>
    In questo file, è sufficiente sostituire la direttiva "Allow from all" con "Allow from 192.168.149.0/255.255.255.0" per specificare le reti da cui consentire l'accesso (ovviamente impostando il valore appropriato) separate da spazi. In alternativa, è possibile specificare singoli indirizzi IP o anche nomi host o specifici domini.
    Nel caso venga tentato l'acceso da una rete/host non autorizzato, apache dovrebbe restituire questo risultato:
    [WORKLOG] - Installazione e configurazione di un server di posta SOHO.-28_apache_forbidden.png

    Ripetere uguale per i files "/etc/apache2/conf.d/awstats.conf" ed "/etc/apache2/conf.d/phpldapadmin".
    Per "/etc/apache2/conf.d/phpmyadmin.conf" la procedura è leggermente diversa perchè è necessario aggiungere anche l'opzione "Order allow,deny", dato che di default non è presente.

    In ultimo, ridurre al minimo indispensabile gli alias configurati nel file "default" e "default-ssl" può aiutare a ridurre la "superficie d'attacco" al server, che male non fà mai.
    Ultima modifica di frakka : 26-08-2012 a 13:58


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  2. #12
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,114
    configurazione

    Predefinito 6.1_ Filtri antispam: SPF Check.

    Ho accennato in precedenza alla creazione di un record SPF per il mio mailserver.

    Di default, però, il plugin per il controllo del record SPF non è installato ne abilitato in postfix quindi io fornisco questa informazione agli altri server ma non ne faccio uso per verificare il mio traffico in ingresso. Il wiki di iRedMail fornisce le istruzioni per abilitare questo controllo in Postfix quindi ne approfitto e lo installo anche sul mio server (pagina ufficiale del progetto).

    Come prima cosa, è necessario installare il plugin che effettua il controllo. Su Debian, si trova già pacchettizzato nei repository quindi per installarlo con le relative dipendenze è sufficiente lanciare il comando:
    codice:
    root@server:/home/matteo# apt-get install postfix-policyd-spf-python python-dns python-spf
    Non è una versione "recentissima" (0.8.0-2) ed in "testing" è disponibile anche la 1.0x che richiede però un aggiornamento di python quindi per ora va bene così (Qui è eventualmente possibile reperire i .deb).

    Il file di configurazione si trova nel percorso "/etc/postfix-policyd-spf-python/policyd-spf.conf" e si presenta così:

    Originariamente inviato da /etc/postfix-policyd-spf-python/policyd-spf.conf
    # For a fully commented sample config file see policyd-spf.conf.commented

    debugLevel = 1
    defaultSeedOnly = 1

    HELO_reject = SPF_Not_Pass
    Mail_From_reject = Fail

    PermError_reject = False
    TempError_Defer = False

    skip_addresses = 127.0.0.0/8,::ffff:127.0.0.0//104,::1//128
    Il modulo supporta anche diversi livelli di whitelist, le istruzioni di configurazione complete sono reperibili nella manpage con il comando "man 5 policyd-spf.conf". Altre utili informazioni per la gestione del whitelisting su postfix si possono trovare qui.

    La configurazione di default è funzionante, per abilitarla è però necessario aggiungere un paio di istruzioni in postfix, seguendo le istruzioni del wiki o anche del link precedente:

    1. Editare il file "/etc/postfix/master.cf" ed aggiungere in fondo le seguenti istruzioni:
      codice:
      # SPF check
      spfpolicy unix  -       n       n       -       -       spawn
          user=nobody argv=/usr/bin/python /usr/bin/policyd-spf
    2. Editare il file "/etc/postfix/main.cf" ed aggiungere alla riga "smtpd_recipient_restrictions" la policy: "check_policy_service unix:private/spfpolicy" in una posizione adeguata (le istruzioni vengono eseguite in sequenza). La mia policy ora si presenta così:
      codice:
      smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unlisted_recipient, check_policy_service unix:private/spfpolicy, check_policy_service inet:127.0.0.1:7777, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, check_recipient_access, hash:/etc/postfix/accept_special, check_policy_service inet:127.0.0.1:10031
    3. Riavviare postfix.




    [EDIT del 05∕02∕2013]
    Mi è venuta la necessità di utilizzare il mio server di posta elettronica con un normale client anche dall'esterno della mia rete locale. Andando a configurare l'account mi sono reso conto che non potevo spedire messaggi in uscita. Il server mi rispondeva sempre così:
    Si è verificato un errore durante l'invio della posta. Il server di posta ha risposto: 5.7.1 : Recipient address rejected: Message rejected due to: SPF fail - not authorized. Please see SPF: Why. Controllare il destinatario del messaggio mia-email@fracassetti.it e riprovare.
    In pratica, il plugin SPF rifiutava le mie stesse email perchè il client configurato, tentando una connessione SMTP al mio server per spedire la mail, si presentava con un IP diverso da quello indicato nel record SPF.
    Come accennato in precedenza, la posizione in cui vengono inserite le istruzioni in postfix è fondamentale: Per risolvere il problema ho dovuto modificare l'istruzione precedente in modo che il controllo SPF sulle email in ingresso avvenisse dopo l'istruzione "permit_sasl_authenticated".
    codice:
    smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unlisted_recipient, check_policy_service inet:127.0.0.1:7777, permit_mynetworks, permit_sasl_authenticated, check_policy_service unix:private/spfpolicy, reject_unauth_destination, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, check_recipient_access hash:/etc/postfix/accept_special, check_policy_service inet:127.0.0.1:10031
    In questo modo, le mail in ingresso vengono comunque verificate dal plugin SPF ma solo se la mail non arriva da un mittente autenticato. L'alternativa sarebbe quella di modificare il record SPF per risultare più permissivo ma, a mio parere, questa scelta ne annullerebbe l'efficacia.
    Ultima modifica di frakka : 05-02-2013 a 01:59


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  3. #13
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,114
    configurazione

    Predefinito 6.2_ Filtri antispam: Greylisting.

    Il Greylisting è uno strumento nella lotta allo spam tanto semplice quanto geniale.

    Si basa e sfrutta il fatto che un mail server attendibile ha come scopo principale quello di garantire che il traffico email che gli viene affidato arrivi correttamente a destinazione mentre un mass-mailer per la generazione di spam ha interesse a raggiungere il maggior numero di utenti nel più breve tempo possibile: Mentre un mail server "vero" impiega le proprie risorse di banda e cpu per far si che tutti i messaggi vengano recapitati ai destinatari, a costo di provarci più volte, uno spammer ha come priorità che il messaggio raggiunga il più ampio numero possibile di destinatari, a costo di perderne qualcuno per strada.

    Un server "vero" con greylisting abilitato, quindi, come prima cosa respinge al mittente ogni messaggio in ingresso, generalmente con un codice di errore che indica un rifiuto temporaneo (4XX), ad esempio:
    codice:
    Aug 28 21:06:55 server postfix/smtpd[20553]: NOQUEUE: reject: RCPT from smtp.mssupport.microsoft.com[131.107.1.37]: 450 4.7.1 : Recipient address rejected: Policy Rejection- Please try later.; from= to= proto=ESMTP helo=
    • Se l'originatore del messaggio è un server "vero" (configurato decentemente) sicuramente, vedendosi rifiutare un messaggio, riproverà altre volte a recapitarlo. Tipicamente un server di posta tiene un messaggio in coda fino ad un paio di giorni (dipende dalle scelte dell'amministratore) per evitare che temporanei problemi di connettività o disservizi tecnici possano impedire il recapito di un messaggio.
    • Se l'originatore del messaggio è uno spammer, tipicamente il messaggio respinto si perde nel nulla perchè il server mittente non ha, appunto, come priorità il recapito di ogni messaggio ma il recapito al maggior numero possibile di destinatari.



    Il sistema greylisting si basa sulla generazione di una "tripletta" e cioè sulla registrazione in una base dati di 3 informazioni per ogni messaggio di posta in arrivo: Un riferimento del server emittente (tipicamente l'indirizzo ip), l'indirizzo e-mail del mittente e l'indirizzo e-mail del destinatario.
    Queste informazioni vengono memorizzate dal server ricevente che incrementa un contatore nel caso arrivi un'altra mail con la medesima tripletta: Probabilmente, il server originario stà tentando nuovamente di consegnare il messaggio ma anche questa volta il messaggio potrebbe essere rifiutato. Il mittente, tipicamente, rimette il messaggio in coda e proverà a recapitarlo di nuovo dopo un intervallo di tempo di più lungo, magari dopo 15', 1h, 4h e 1giorno prima di rinunciare definitivamente e restituire al mittente un avviso di mancato recapito.
    Dopo un numero di rimbalzi stabiliti dall'amministratore del server che riceve, la tripletta verrà considerata attendibile ed il messaggio, se supera gli altri controlli configurati, verrà preso in carico dal server ricevente per essere consegnato al destinatario. Inoltre, per un tempo stabilito, la tripletta verrà memorizzata e considerata attendibile in modo da non dover ripetere tutta la procedura di validazione per combinazioni risultate "trusted". La maggior efficacia di questo filtro si ottiene, ovviamente, con un tempo di validazione della tripletta piuttosto lungo ma questo ha il contro di ritardare la ricezione della mail da parte dei legittimi destinatari e la cosa non è generalmente ben accettata dagli utenti.

    Ovviamente questo metodo, efficacissimo appena introdotto (poteva bloccare, da solo, oltre il 90% dello spam in arrivo), ha progressivamente perso efficacia: Gli spammers si sono fatti furbi ed hanno iniziato ad implementare per le loro spedizioni delle code o dei server smtp comuni.
    Rimane ancora piuttosto efficace, soprattutto se usato in combinazione con gli altri filtri normalmente presenti su un server di posta. Inoltre richiede pochissime risorse se confrontato con i tradizionali sistemi di scan dei messaggi quindi costituisce ancora una delle prime linee più utili per "sgrossare" la quantità di spam da verificare con gli altri filtri.

    iRedMail lo prevede installato e configurato di default: L'attivazione/disattivazione "server-wide" del filtro si fà direttamente dal file di configurazione del demone "policyd", editando il file "/etc/policyd.conf" ed impostando il valore "GREYLISTING" a "0" per disattivare il servizio ed a "1" per attivarlo, riavviando il demone per applicare le modifiche. Nello stesso file si trovano anche diverse opzioni per il tuning di questo servizio.
    La versione "Pro" di iRedMail permette di abilitare/disabilitare il greylisting anche per singolo dominio o per singolo utente, tramite un comodo menù.


    Riferimenti:
    - greylisting.org.
    - Wikipedia: Greylisting.
    - iRedMail, attivazione/disattivazione del greylisting.
    - Greylist e SPF con Exim e Postfix
    Ultima modifica di frakka : 16-09-2012 a 20:33


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  4. #14
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,114
    configurazione

    Predefinito 7.1_ Creazione di una lista di distribuzione.

    Non stò a parlare della configurazione dei singoli utenti di ciascun dominio: La versione free di iredadmin è relativamente limitata in quanto ad opzioni e funzionalità raggiungibili dall'interfaccia e la creazione di un nuovo utente è estremamente semplice.
    Le versioni free di iredadmin, contrariamente alle controparti a pagamento, non dispone però di un'interfaccia per la configurazione di liste di distribuzione: E' comunque possibile procedere manualmente, seguendo le procedure documentate sul wiki di iredmail.
    La procedura cambia in base allo specifico backend che si è scelto di utilizzare e non è comodissima. Però per un singolo dominio è comunque accettabile mentre, se i domini e gli indirizzi da gestire aumentano, è una di quelle funzionalità che giustificano il passaggio alla versione a pagamento.

    Io ho installato la versione con backend LDAP e la documentazione ufficiale per questa procedura è reperibile qui.

    La creazione di una lista di distribuzione si divide in due parti: consiste nella creazione di un oggetto nella struttura LDAP del dominio interessato e nella successiva aggiunta di ogni membro a questa lista. In assenza di iRedAdmin Pro, lo sviluppatore ha previsto l'installazione durante il setup di un noto tool per la gestione di queste strutture di dati da un'interfaccia web. Il tool si chiama phpLDAPAdmin, è un progetto opensource e, salvo modifiche post-installazione, è raggiungibile agli url "https://ip_del_server/phpldapadmin/" o "https://ip_del_server/ldap/" e per ottenere l'accesso amministrativo è necessario utilizzare la password del manager LDAP fornita in fase di installazione.
    Un riepilogo di queste informazioni è comunque disponibile nel file "iRedMail.tips" generato dal tool di installazione di iRedMail.


    L'interfaccia del tool mostra, sulla sinistra, il tree che costituisce la radice della directory, avente come root il domain indicato in fase di installazione per la struttura LDAP. All'interno del tree si trovano diversi oggetti tra cui l'oggetto "o=domains" che contiene tutti i domini virtuali che il server gestisce mentre sulla destra si trovano il dettaglio degli oggetti selezionati e i campi modificabili.

    Come prima cosa, all'interno del tree "o=domains" individuare il dominio all'interno del quale si vuole creare la lista di distribuzione e selezionare il tree "o=Groups". Sulla destra, selezionare poi "Create a child entry" creare un nuovo oggetto all'interno di questo tree.
    La guida sul sito ufficiale propone poi di selezionare il template "default" e successivamente "mailList" nel menù "ObjectClasses": Il template non l'ho trovato, mi risulta già selezionato come si può vedere dalle indicazioni riportate nel top del questo frame, probabilmente la guida si riferisce ad una versione più vecchia. Nella seconda ed ultima fase di questa procedura c'è da selezionare "mail" nel menù a tendina e compilare i sottostanti campi necessari.


    Le informazioni di inserire, opportunamente ripartite nei relativi campi, sono: l'indirizzo email della lista di distribuzione ("Email"), i permessi di accesso a questa lista (una policy che definisce chi è autorizzato a scrivere alla lista di distribuzione), lo stato della lista (attivata/disattivata, "accountStatus"), un nome semplice per la visualizzazione ("cn" o Common Name) con un testo descrittivo (Description) ed i servizi per cui questo oggetto è autorizzato.

    Le accessPolicy sono predefinite disponibili sono "public", "domain", "subdomain", "membersOnly", "moderatorsOnly", "memebersAndModeratorsOnly": sono gestite e documentate con un tool apposito, sempre facente parte di iRedMail. L'uso di queste policy è molto utile per ridurre la solita valanga di spam in ingresso, restringendo l'accesso solo agli utenti che ne hanno effettivo bisogno.
    Un altro attributo su cui è necessaria una specifica sono gli "enabledService": La guida riporta per questo attributo 3 valori da inserire ma mi risulta che il tool permetta in realtà l'inserimento di un solo valore alla volta... Conviene quindi inserirne solo uno, aggiungendo i successivi solo in un secondo momento. La procedura mostrata nello screenshoot non mi risulta funzionante.
    Inserite le informazioni si può cliccare sul pulsante "Create Object" e, verificata la correttezza, procedere con la creazione dell'oggetto. Una volta creato, può essere modificato per aggiungere i valori mancanti all'attributo "enabledService":


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  5. #15
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,114
    configurazione

    Predefinito 7.2_ Aggiunta di un utente "interno" alla lista di distribuzione.

    La lista appena creata esiste ora come oggetto LDAP ma non è popolata: In assenza di membri assegnati, postfix tratterà la lista come un utente inesistente, restituendo nei log del server di posta il seguente errore:
    codice:
    Recipient address rejected: User unknown in virtual mailbox table;
    L'appartenenza alla lista è gestita come attributo del singolo utente: Non è quindi possibile modificare aggiungere in un colpo solo tutti gli utenti (a meno, ad esempio, di modificare il template per i nuovi utenti, per rendere questo attributo parte degli attributi predefiniti del nuovo utente) ed è necessario agire aggiungendo un utente alla volta.

    Espandendo il tree "ou=Users", sempre sotto il tree del dominio in cui stiamo creando la lista, è possibile individuare l'account che si vuole aggiungere e selezionarlo:
    Se è la prima volta che l'utente viene aggiunto ad una lista, l'attributo "memberOfGroup" non sarà disponibile e dovrà essere aggiunto tramite la funzione "Add new attribute -> memberOfGroup" e valorizzando il campo compilabile con l'indirizzo email della lista, selezionando "Update Object" per salvare le modifiche. In caso contrario, sarà sufficiente aggiungere un valore all'attributo esistente, similmente a come fatto in precedenza per l'attributo "enabledService". Non ci sono particolare limitazioni al numero di liste a cui può essere aggiunto l'utente.

    Dalla rubrica della webmail, se è stato precedentemente attribuito il valore "displayedInGlobalAddressBook" all'attributo "enabledService" della lista di distribuzione, è ora possibile verificare se il nuovo oggetto compare nell'elenco degli indirizzi disponibili nell'elenco indirizzi globale e se il funzionamento è quello atteso:


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  6. #16
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,114
    configurazione

    Predefinito 7.3_ Aggiunta di un utente "esterno" al dominio alla lista di distribuzione.

    La procedura precedente permette di gestire solo contatti email registrati all'interno del dominio specifico. Creare una lista che permetta di inoltrare messaggi ad indirizzi non appartenenti al dominio gestito dal server non è problematico ma segue una procedura leggermente diversa: La lista in sè è identica ma è necessario creare un oggetto "contatto email" nell'apposito tree "Externals" ed aggiungervi l'attributo "memberOfGroup", similmente a quanto visto in precedenza.
    A queste liste, è possibile applicare gli stessi attirbuti e gli stessi valori visti in precedenza, sia per quanto riguarda le policy di accesso che per gli enabled services.

    La procedura che cambia leggermente è la creazione del contatto email, che si fà espandendo il tree "Externals" e selezionando la tipologia "mailExternalUser".

    [WORKLOG] - Installazione e configurazione di un server di posta SOHO.-11_externals.jpg

    Per aggiungere alla lista un utente interno già esistente, è sufficiente aprirne il profilo e aggiungere un "Value" all'attributo "memberOfGroup" dell'utente.

    [WORKLOG] - Installazione e configurazione di un server di posta SOHO.-12_externals.png


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  7. #17
    la mucca di Sunnyvale L'avatar di Daniele
    Registrato
    Sep 2000
    Località
    Alessandria
    Età
    42
    Messaggi
    8,247
    configurazione

    Predefinito

    Iscrittissimo! Leggero' con interesse come al solito!

    Inviato dal mio LG-P990 con Tapatalk 2

  8. #18
    mebibyte L'avatar di pgfiore
    Registrato
    Jun 2011
    Località
    Genova
    Età
    56
    Messaggi
    565

    Predefinito

    Bel lavoro!

    Certo che la lotta allo spam è una bella rogna; aziendalmente non c'è verso che riesca a trovare il giusto compromesso...

  9. #19
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,114
    configurazione

    Predefinito

    Molte grazie a tutti e due.

    Sì, è vero: E' un bella lotta ma trovare un compromesso accettabile è possibile.

    E' un lavoro continuo, non è mai "finito": Implementare bene il maggior numero di filtri operanti a livello SMTP (greylisting, SFP, DKIM... le RBL non mi piacciono per nulla) riduce di molto il carico di lavoro (ed il margine di errore) dei filtri successivi ma non sono tutte attività su cui l'amministratore del server ha il diretto controllo (ad esempio, l'implementazione di SPF è responsabilità di chi gestisce il server mittente, così come un server mittente che gestisca correttamente i "retry" imposti dal greylisting).
    Poi ci sono le verifiche che si possono effettuare sul contenuto dei messaggi ma queste sono quelle con il più alto margine di errore purtroppo ed un filtro troppo stretto provoca falsi positivi, che sono deleteri.

    Inoltre gli strumenti a disposizione dell'amministratore non sempre collaborano... Sul server Exchange in ufficio abbiamo sia l'antivirus/antispam di Kaspersky che il tool antispam di GFI: Comunque un'elevata percentuale dello spam sfugge ai controlli e non riusciamo a capirne il motivo (i log dei due strumenti fanno pena...).

    Se poi ci metti che la maggior parte degli strumenti ha le liste di keyword tarate per la lingua inglese... Ecco che l'utilità dei filtri a livello smtp viene ribadita.


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  10. #20
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,114
    configurazione

    Predefinito 8_ Fail2ban.

    Come accennato, tra i vari tool che iRedMail installa e preconfigura c'è anche "Fail2Ban".

    Fail2ban è un tool con architettura client-server scritto in python. Sostanzialmente si occupa di analizzare i log di sistema alla ricerca di corrispondenze con delle stringhe indicate in "jail" configurabili e applicare per ogni occorrenza un'azione stabilita.
    L'utilizzo tipico è quello che creare delle jail per matchare le signature dei portscanner più noti o per individuare dei tentativi di brute-forcing sul server e mettere in drop nel firewall del server l'IP attaccante. Il tool funziona piuttosto bene anche se ci potrebbe essere bisogno di qualche fix manuale o di un leggero tuning iniziale ma richiede una certa dimestichezza con le espressioni regolari (regex) in Perl che vengono utilizzate per analizzare i log di sistema. In questo non sono molto ferrato quindi le regex che ho implementato sono piuttosto rudimentali ma sufficientemente efficaci...

    Il tool utilizza due file di configurazione principali reperibili in /etc/fail2ban oltre ai file contenenti le espressioni regolari (contenuti nella sottodirectory filter.d) ed ai files contenenti le azioni da intraprendere in caso di match (action.d).
    I files di configurazione principali di fail2ban sono "fail2ban.conf" e "jail.conf": In base alla documentazione ufficiale, questi files non devono essere direttamente modificati per evitare problemi in sede di aggiornamento. Per personalizzarne il funzionamento è sufficiente creare una copia del file sostituendo l'estensione da ".conf" a ".local" ed apportare le modifiche su quest'ultimo file: Il tool provvede autonomamente ad effettuare il merge delle impostazioni tra i due files, mantenend come dominanti per impostazione del file ".local".


    codice:
    root@server:/etc/fail2ban# service fail2ban status
    Status of authentication failure monitor:fail2ban is running.
    La versione per CentOS è più simpatica... Indica anche il numero di jail in esecuzione. Comunque il demone è attivo e funzionante.
    Sempre su CentOS 6 ho avuto modo di verificare un bug noto, provocato dalla sovrapposizione dei comandi inviati ad iptables per la creazione delle chain nel firewall: questo provoca la comparsa nel log di fail2ban di numerosi errori (codificati con numerazioni pari a 100 o multiple di 100) e l’inserimento solo parziale di alcune regole nel firewall (con risultati imprevedibili).

    codice:
    root@server:/etc/fail2ban# tail -40 /var/log/daemon.log | grep ERROR
    Sep 20 00:55:55 server fail2ban.actions.action: ERROR  iptables -D INPUT -p tcp --dport ssh -j fail2ban-ssh#012iptables -F fail2ban-ssh#012iptables -X fail2ban-ssh returned 100
    Sep 20 00:55:56 server fail2ban.actions.action: ERROR  iptables -D INPUT -p tcp -m multiport --dports http,https,smtp,submission,pop3,pop3s,imap,imaps,sieve -j fail2ban-roundcube#012iptables -F fail2ban-roundcube#012iptables -X fail2ban-roundcube returned 100
    Sep 20 00:55:56 server fail2ban.actions.action: ERROR  iptables -D INPUT -p tcp -m multiport --dports http,https,smtp,submission,pop3,pop3s,imap,imaps,sieve -j fail2ban-postfix#012iptables -F fail2ban-postfix#012iptables -X fail2ban-postfix returned 100
    Sep 20 00:55:57 server fail2ban.actions.action: ERROR  iptables -D INPUT -p tcp -m multiport --dports http,https,smtp,submission,pop3,pop3s,imap,imaps,sieve -j fail2ban-dovecot#012iptables -F fail2ban-dovecot#012iptables -X fail2ban-dovecot returned 100
    Ho quindi verificato subito se il problema si presenta anche su debian e l'estratto del log sopra riportato lo conferma. Per risolvere questo problema, è stato applicato un fix trovato in rete che inserisce un 'attesa tra un inserimento e l'altro: Il fix consiste nell’editare il file in python “/usr/bin/fail2ban-client” e modificata la sezione che parte dalla riga 142 come segue:
    codice:
    def __processCmd(self, cmd, showRet = True):
                    beautifier = Beautifier()
                    for c in cmd:
                            time.sleep(0.1)
                            beautifier.setInputCmd(c)
    Il caricamento delle jail risulta ora molto più lento ma avviene senza errori. Altri fix per lo stesso motivo, non hanno portato i risultati sperati quindi questo mi sembra essere il più efficace.


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

Pagina 2 di 4
prima
1 2 3 4 ultimo

Informazioni Thread

Users Browsing this Thread

Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)

Tags

Regole d'invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
nexthardware.com - © 2002-2018

Search Engine Optimization by vBSEO 3.6.1