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

[pgfiore]

Bel lavoro!

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

[frakka]

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.

[frakka]

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".

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).

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:

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.

[frakka]

Il file fail2ban.conf ha il seguente contenuto:

# Fail2Ban configuration file
#
# Author: Cyril Jaquier
#
# $Revision: 629 $
#

[Definition]

# Option:  loglevel
# Notes.:  Set the log level output.
#          1 = ERROR
#          2 = WARN
#          3 = INFO
#          4 = DEBUG
# Values:  NUM  Default:  3
#
loglevel = 3

# Option:  logtarget
# Notes.:  Set the log target. This could be a file, SYSLOG, STDERR or STDOUT.
#          Only one log target can be specified.
# Values:  STDOUT STDERR SYSLOG file  Default:  /var/log/fail2ban.log
#
logtarget = SYSLOG

# Option: socket
# Notes.: Set the socket file. This is used to communicate with the daemon. Do
#         not remove this file when Fail2ban runs. It will not be possible to
#         communicate with the server afterwards.
# Values: FILE  Default:  /var/run/fail2ban/fail2ban.sock
#
socket = /var/run/fail2ban/fail2ban.sock

Nulla di complesso. Livello di dettaglio dei log, destinazione del log e socket del processo.
Il livello di dettaglio per ora va bene, voglio però cambiare la destinazione del log: Ora finisce tutto nel "/var/log/daemon.log" ma preferisco dedicargli un proprio log. Copio quindi il file, anche così com'è, in un file omonimo con estensione ".local" e sostituisco la riga "logtarget = SYSLOG" con "logtarget = /var/log/fail2ban.log".

Per integrare il tool con lo strumento di rotazione automatica dei log, è necessario creare il file "/etc/logrotate.d/fail2ban" con il seguente contenuto, in accordo con le istruzioni contenute del wiki linkato in precedenza (ovviamente con le opportune modifiche, se il file di log indicato non è quello riportato):

/var/log/fail2ban.log {
    weekly
    rotate 7
    missingok
    compress
    postrotate
      /usr/local/bin/fail2ban-client reload 1>/dev/null || true
    endscript
}

Io lo avevo già anche se con un contenuto leggermente diverso:

/var/log/fail2ban.log {
    weekly
    rotate 4
    compress
    delaycompress
    missingok
    postrotate
    fail2ban-client set logtarget /var/log/fail2ban.log >/dev/null
    endscript
    create 640 root adm
}

[lucatek]

Salve Sig. Frakka posso farle una domanda?

[pgfiore]

Necroposting
Ci penserei mille volte prima di mettermi un server mail in casa nel 2017; offerte gratuite online come Google e Microsoft oppure Office365 con fee hanno cambiato le regole del gioco...

[frakka]

Necroposting
Ci penserei mille volte prima di mettermi un server mail in casa nel 2017; offerte gratuite online come Google e Microsoft oppure Office365 con fee hanno cambiato le regole del gioco...

Abbastanza d'accordo, anche io ho dismesso questo server circa un anno e mezzo fa.
Mi pare che qualcuno di questi provider adesso permetta di usare il proprio dominio anche con la loro infrastruttura ma probabilmente solo per i contratti Business.
Io ho il dominio su Aruba, quindi ho spostato tutto sui loro server e mi trovo abbastanza bene.

[lucatek]

Grazie Frakka per la tua disponibilità spero che mi puoi aiutare non so piu cosa fare...Sto impazzendo! Le ho provate tutte!!!
Premetto che da poco mi sono avvicinato a linux e quindi non sono un esperto , ma ne sono rimasto affascinato e per il mio server di prova ho scelto cent os 7 come già uso sulle mie vps. Ma adesso vi espongo il problema:
Installato os
Installato vesta cp
Configurato dominio che punta al mio server con ip statico.
Tutto funziona ma non la zona dns che anche se da vesta modifico parametri mi risulta sempre irraggiungibile. Ovviamente con ip tutto funziona correttamente. Mi potete dire dove sbaglio ? Probabilmente non riesco a creare la zona interna al server visibile da esterno...
Grazie mille in anticipo 😉

[Matty90]

Ciao Lucatek,
si tratta di problemi assai diversi e differenti rispetto alla discussione. Anche per rendere maggiormente leggibile e fruibile il forum, ti chiedo se puoi cortesemente aprire una discussione qui: https://www.nexthardware.com/forum/g...i-alternativi/

In questo modo sarà molto più semplice per tutti aiutarti e in futuro essere aiutati dal tuo topic semplicemente cercando le info necessarie.

Buona permanenza!

[frakka]

Salve Sig. Frakka posso farle una domanda?

Sì, certo.
Se posso rispondere, volentieri...