Sì, tutto bene, sono molto soddisfatto.
Ho iniziato a riprendere a mano la parte di server di posta. Ci vorrà un pò ma arriverà anche quella.
Printable View
Sì, tutto bene, sono molto soddisfatto.
Ho iniziato a riprendere a mano la parte di server di posta. Ci vorrà un pò ma arriverà anche quella.
Aggiunto il punto "11", riguardante l'inserimento nella rete di un AccessPoint con SSID multipli per l'integrazione nella rete locale di una rete wireless "sicura" e la gestione contemporanea di una rete wireless "open" separata dalle altre reti.
Aspetto importante e che avevo invece completamente trascurato, è una gestione controllata dei log del server.
Tutti i servizi in esecuzione registrano informazioni in merito alla propria attività, informazioni che sono fondamentali per verificare il corretto funzionamento dei servizi in esecuzione o per individuare e risolvere eventuali problemi.
Inoltre, l'analisi di questi log è fondamentale per individuare o prevenire/ostacolare tentativi di intrusione nel server, frequentissimi nei server raggiungibili da internet, per quanto piccoli ed anonimi essi siano.
E' possibile utilizzare degli strumenti automatici configurati opportunamente per verificare ad intervalli regolari i log del server ed riportare eventuali anomalie rilevate oppure altri strumenti che, partendo dall'analisi degli stessi log, proteggano l'integrità del server intraprendendo automaticamente azioni di contrasto (ad esempio) nei confronti di uno specifico indirizzo IP.
I log di un server possono crescere a dismisura se non vengono gestiti, col risultato di diluire le informazioni utili in mezzo al classico pagliaio o impegnando per molto più tempo del dovuto i tools di analisi che effettuano le verifiche.
Praticamente tutte le distribuzioni linux implementano un sistema di controllo e gestione dei log di sistema che si chiama "logrotate". Il tool non fà altro che andare a leggere una serie di script depositati in apposite directory e "troncare" i log delle applicazioni indicate, gestendo anche l'aging dei vecchi files ed eventualmente spedendoli via mail ad un indirizzo specificato.
Per Debian, una semplice spiegazione di come funziona il tool è consultabile qui.
Il tool esamina il contenuto del file "/etc/logrotate.conf":
e gli script contenuti nella directory "/etc/logrotate.d" :codice:# see "man logrotate" for details
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# uncomment this if you want your log files compressed
#compress
# packages drop log rotation information into this directory
include /etc/logrotate.d
# no packages own wtmp, or btmp -- we'll rotate them here
/var/log/wtmp {
missingok
monthly
create 0664 root utmp
rotate 1
}
/var/log/btmp {
missingok
monthly
create 0660 root utmp
rotate 1
}
# system-specific logs may be configured here
per determinare le azioni da intraprendere ed i files interessati. Praticamente tutti i daemons che vengono installati dai gestori di pacchetti delle varie distribuzioni prevedono già uno script preconfigurato per la gestione dei log quindi è necessario intervenire solo se si personalizza il percorso o il nome dei log o per modificare l'aging dei log o gestire la rotazione dei log di applicazioni per cui non è disponibile una preconfigurazione.codice:root@server:/home/matteo# ls /etc/logrotate.d
apache2 aptitude clamav-freshclam dpkg exim4-paniclog iredapd openldap samba vsftpd
apt clamav-daemon dovecot exim4-base fail2ban mysql-server rsyslog sieve winbind
La configurazione del tool è veramente semplice ed auto-esplicativa. Fortunatamente, anche gli script da creare per gestire la rotazione dei log sono molto semplici e la spiegazione delle varie opzioni è disponibile nella manpage del tool, consultabile con il comando
(si chiude premendo la "q").codice:man logrotate
il contenuto della mia "logrotate.d" è il seguente:
ed il contenuto della mia /var/log è il seguente:codice:root@server:/home/matteo# ls /etc/logrotate.d
apache2 aptitude clamav-freshclam dpkg exim4-paniclog iredapd openldap samba vsftpd
apt clamav-daemon dovecot exim4-base fail2ban mysql-server rsyslog sieve winbind
Insomma: Ho cambiato nome al log del server ftp e mi sono dimenticato di aggiornare il relativo script (pre-esistente). Dato che ho due log per il servizio ftp, posso creare due script separati o usare lo stesso script per entrambi i log. Nel mio caso, uso lo stesso script per gestire il rotate sia del file .log che del file .xferlog ed aggiungo le opzioni " compress" e "delaycompress" non presenti nello script predefinito:codice:root@server:/home/matteo# ls /var/log/
alternatives.log boot dovecot.log.1.bz2 fail2ban.log.4.gz mail.info mysql.log syslog
alternatives.log.1 btmp dovecot.log.2.bz2 faillog mail.info.1 mysql.log.1.gz syslog.1
alternatives.log.10.gz btmp.1 dovecot.log.3.bz2 fontconfig.log mail.info.2.gz mysql.log.2.gz syslog.2.gz
alternatives.log.2.gz clamav dovecot.log.4.bz2 fsck mail.info.3.gz mysql.log.3.gz syslog.3.gz
alternatives.log.3.gz daemon.log dpkg.log installer mail.info.4.gz mysql.log.4.gz syslog.4.gz
alternatives.log.4.gz daemon.log.1 dpkg.log.1 iredapd.log mail.log mysql.log.5.gz syslog.5.gz
alternatives.log.5.gz daemon.log.2.gz dpkg.log.10.gz iredapd.log.1.bz2 mail.log.1 mysql.log.6.gz syslog.6.gz
alternatives.log.6.gz daemon.log.3.gz dpkg.log.11.gz iredapd.log.2.bz2 mail.log.2.gz mysql.log.7.gz syslog.7.gz
alternatives.log.7.gz daemon.log.4.gz dpkg.log.12.gz iredapd.log.3.bz2 mail.log.3.gz news user.log
alternatives.log.8.gz dbconfig-common dpkg.log.2.gz iredapd.log.4.bz2 mail.log.4.gz ntpstats user.log.1
alternatives.log.9.gz debug dpkg.log.3.gz kern.log mail.warn openldap.log user.log.2.gz
apache2 debug.1 dpkg.log.4.gz kern.log.1 mail.warn.1 openldap.log.1.bz2 user.log.3.gz
apt debug.2.gz dpkg.log.5.gz kern.log.2.gz mail.warn.2.gz openldap.log.2.bz2 user.log.4.gz
aptitude debug.3.gz dpkg.log.6.gz kern.log.3.gz mail.warn.3.gz openldap.log.3.bz2 vsftpd_pubblico.log
aptitude.1.gz debug.4.gz dpkg.log.7.gz kern.log.4.gz mail.warn.4.gz openldap.log.4.bz2 vsftpd_pubblico.xferlog
aptitude.2.gz dmesg dpkg.log.8.gz lastlog messages pycentral.log wtmp
aptitude.3.gz dmesg.0 dpkg.log.9.gz lpr.log messages.1 samba wtmp.1
auth.log dmesg.1.gz exim4 mail.err messages.2.gz sieve.log
auth.log.1 dmesg.2.gz fail2ban.log mail.err.1 messages.3.gz sieve.log.1.gz
auth.log.2.gz dmesg.3.gz fail2ban.log.1 mail.err.2.gz messages.4.gz sieve.log.2.gz
auth.log.3.gz dmesg.4.gz fail2ban.log.2.gz mail.err.3.gz mysql sieve.log.3.gz
auth.log.4.gz dovecot.log fail2ban.log.3.gz mail.err.4.gz mysql.err sieve.log.4.gz
Verifico che funzioni, forzando la rotazione:codice:root@server:/home/matteo# nano /etc/logrotate.d/vsftpd
#/var/log/vsftpd.log
/var/log/vsftpd_pubblico.log
/var/log/vsftpd_pubblico.xferlog
{
create 640 root adm
# ftpd doesn't handle SIGHUP properly
missingok
compress
delaycompress
notifempty
rotate 4
weekly
}
Fatto!codice:root@server:/home/matteo# logrotate -f /etc/logrotate.d/vsftpd
root@server:/home/matteo# ls -ll /var/log/vsftpd_pubblico.*
-rw-r----- 1 root adm 0 Sep 23 02:56 /var/log/vsftpd_pubblico.log
-rw------- 1 root root 1852004 Sep 19 15:40 /var/log/vsftpd_pubblico.log.1
-rw-r----- 1 root adm 0 Sep 23 02:57 /var/log/vsftpd_pubblico.xferlog
-rw------- 1 root root 244509 Aug 19 22:54 /var/log/vsftpd_pubblico.xferlog.1
Questo pomeriggio ho ricevuto una sgradevole sorpresa: Hotmail ha iniziato a rimbalzarmi la posta in uscita:
Dopo una breve indagine mi sono accorto che il mio IP è finito nella dnsrbl di spamhaus, probabilmente a causa dell'attività di qualche malware su un pc della rete locale (risultavo come parte di una botnet...).codice HTML:This is the mail system at host posta.fracassetti.it.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<email-della-morosa@hotmail.it>: host mx2.hotmail.com[65.54.188.126] said: 550 OU-001
(BAY0-MC4-F15) Unfortunately, messages from <mio-ip> weren't sent.
Please contact your Internet service provider since part of their network
is on our block list. You can also refer your provider to
http://mail.live.com/mail/troubleshooting.aspx#errors. (in reply to MAIL
FROM command)
[...]
Dopo le bestemmie di rito e l'avvio di scansioni di massa sui vari pc con i tool appositi, tra i suggerimenti sul sito di spamhaus ne ho trovato uno tanto semplice quanto geniale: Dato che il serverino è anche gateway e firewall per la rete locale, la cosa più semplice per impedire il ripetersi in futuro di problemi analoghi ed individuare subito il pc infetto è aggiungere poche righe nel firewall che impediscano il traffico in uscita dalla rete locale sulle porte utilizzate dal protocollo SMTP.
Il mailserver è sul server stesso, quindi è sufficiente bloccare il traffico agendo sulla chain "FORWARD", in modo da bloccare solo l'attività SMTP in uscita non originata dal server stesso. Questa modifica ha effetto per tutte le reti (private ed ospiti) che attraversano il serverino per uscire su internet.
L'effetto collaterale è che questa regola, così com'è, impedisce l'uso dei normali client di posta per spedire mail tramite un server SMTP che non si trovi sulla rete locale. Nel mio caso è poco male, non abbiamo pc configurati in questo modo perchè tutte le mailbox che usiamo non appoggiate sul mio serverino sono accessibili solo via webmail.
Individuo quindi questa sezione nel mio script di impostazione del firewall:
e subito sotto gli aggiungo queste:codice HTML:echo "Process FORWARD chain ..."
# Used if forwarding for a private network
# Drop bad packets
$IPT -A FORWARD -p ALL -j bad_packets
E questo è quello che è possibile riscontrare nei log del server se un client tenta una connessione sulle porte indicate:codice HTML:# Logga tutti i tentativi di connessione in uscita dalla rete locale sulle
# porte 25,465 e 587 e le droppa, per prevenire ban dovuti alla presenza di
# malware/botnet:
for X in $INSIDE_IFACE; do $IPT -A FORWARD -p TCP -i $X --destination-port 25 -j LOG --log-prefix "Attivita' SMTP sospetta: "; done;
for X in $INSIDE_IFACE; do $IPT -A FORWARD -p TCP -i $X --destination-port 25 -j DROP; done;
for X in $INSIDE_IFACE; do $IPT -A FORWARD -p TCP -i $X --destination-port 465 -j LOG --log-prefix "Attivita' SMTP sospetta: "; done;
for X in $INSIDE_IFACE; do $IPT -A FORWARD -p TCP -i $X --destination-port 465 -j DROP; done;
for X in $INSIDE_IFACE; do $IPT -A FORWARD -p TCP -i $X --destination-port 587 -j LOG --log-prefix "Attivita' SMTP sospetta: "; done;
for X in $INSIDE_IFACE; do $IPT -A FORWARD -p TCP -i $X --destination-port 587 -j DROP; done;
codice:Nov 25 01:33:36 server kernel: [1651815.335901] Attivita' SMTP sospetta: IN=eth1 OUT=eth0 SRC=192.168.200.212 DST=2.228.5.7 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=22295 DF PROTO=TCP SPT=51176 DPT=25 WINDOW=8192 RES=0x00 SYN URGP=0
Nov 25 01:33:39 server kernel: [1651818.340128] Attivita' SMTP sospetta: IN=eth1 OUT=eth0 SRC=192.168.200.212 DST=2.228.5.7 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=22297 DF PROTO=TCP SPT=51176 DPT=25 WINDOW=8192 RES=0x00 SYN URGP=0
Nov 25 01:33:45 server kernel: [1651824.343578] Attivita' SMTP sospetta: IN=eth1 OUT=eth0 SRC=192.168.200.212 DST=2.228.5.7 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=22298 DF PROTO=TCP SPT=51176 DPT=25 WINDOW=8192 RES=0x00 SYN URGP=0
Nov 25 01:33:48 server kernel: [1651827.376494] Attivita' SMTP sospetta: IN=eth1 OUT=eth0 SRC=192.168.200.212 DST=2.228.5.16 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=22300 DF PROTO=TCP SPT=51177 DPT=25 WINDOW=8192 RES=0x00 SYN URGP=0
Nov 25 01:33:51 server kernel: [1651830.380685] Attivita' SMTP sospetta: IN=eth1 OUT=eth0 SRC=192.168.200.212 DST=2.228.5.16 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=22301 DF PROTO=TCP SPT=51177 DPT=25 WINDOW=8192 RES=0x00 SYN URGP=0