Per chi volesse un server sicuro esistono migliaia di guide e opinioni su come proteggerlo al meglio. Una cosa che il sistema deve di certo fare è quella di registrare tutte
le operazioni che vengono svolte; questo per avere da un lato informazioni utili per risolvere eventuali malfunzionamenti e dall’altro canto per avere uno strumento di controllo contro attacchi o tentativi di intrusione.
Syslog-ng monitorerà i nostri server in locale e con una corretta configurazione duplicherà i log su un server centrale in remoto.
Quindi qualora uno sconsiderato nullafacente decidesse di condurre un attacco verso uno dei nostri server potrà di certo nascondere al meglio le proprie tracce, cancellando i segni del proprio operato dai file di log ma dovrà fare altrettanto su un secondo server! È difficile scampare ad un attacco ben congegnato, ma almeno rendiamogli la vita difficile!
Abbiamo già anticipato la nostra scelta per quanto riguarda il log-server che utilizzeremo per il nostro scopo, vale a dire syslog-ng sia per l’ottima granularita’ nella definizione delle regole di filtraggio, che per la disponibilita’ di maggiore documentazione.
Installiamo su ogni macchina il nostro pacchetto:
apt-get install syslog-ng
questo rimuoverà rsyslog. Fate attenzione quindi!!!
Syslog-ng lavora secondo un semplice schema: il log di una determinata sorgente viene filtrato e inviato ad una destinazione. Se questo non vi appare complicato leggere il file di configurazione non sarà assolutamente difficile.
Cosa ho fatto quindi: sul quello che sarà il server centrale di raccolta dei log degli altri server ho aggiunto una sorgente che arriva dalla rete, ho usato gli stessi filtri del sistema locale e ho indirizzato il tutto verso dei file posti in cartelle separate per ogni client-server.
Chiamiamo il server remoto di salvataggio dei log “central.example.com” e diamo ai vari server i nomi “client1.example.com”, “client2.example.com” … “client4.example.com” e così di seguito.
Apriamo il file di configurazione posto nella cartella /etc/syslog-ng/ sul server “central” e aggiungete del righe evidenziate. Non ci dovrebbe esseri grossi problemi a capirle:
...
# First, set some global options.
options { chain_hostnames(off); flush_lines(0); use_dns(no); use_fqdn(no);
owner("root"); group("adm"); perm(0640); stats_freq(0);
bad_hostname("^gconfd$");
keep_hostname(yes);
chain_hostnames(on);
create_dirs(yes);
};
...
source s_net { tcp( ip(192.168.1.50) port(1000) keep-alive (yes)); };
...
destination net_auth { file("/var/log/$HOST/$YEAR/$MONTH/$DAY/auth.log"); };
destination net_cron { file("/var/log/$HOST/$YEAR/$MONTH/$DAY/cron.log"); };
destination net_daemon { file("/var/log/$HOST/$YEAR/$MONTH/$DAY/daemon.log"); };
destination net_kern { file("/var/log/$HOST/$YEAR/$MONTH/$DAY/kern.log"); };
destination net_lpr { file("/var/log/$HOST/$YEAR/$MONTH/$DAY/lpr.log"); };
destination net_mail { file("/var/log/$HOST/$YEAR/$MONTH/$DAY/mail.log"); };
destination net_syslog { file("/var/log/$HOST/$YEAR/$MONTH/$DAY/syslog"); };
destination net_user { file("/var/log/$HOST/$YEAR/$MONTH/$DAY/user.log"); };
destination net_uucp { file("/var/log/$HOST/$YEAR/$MONTH/$DAY/uucp.log"); };
destination net_mailinfo { file("/var/log/$HOST/$YEAR/$MONTH/$DAY/mail.info"); };
destination net_mailwarn { file("/var/log/$HOST/$YEAR/$MONTH/$DAY/mail.warn"); };
destination net_mailerr { file("/var/log/$HOST/$YEAR/$MONTH/$DAY/mail.err"); };
destination net_newscrit { file("/var/log/$HOST/$YEAR/$MONTH/$DAY/news/news.crit"); };
destination net_newserr { file("/var/log/$HOST/$YEAR/$MONTH/$DAY/news/news.err"); };
destination net_newsnotice { file("/var/log/$HOST/$YEAR/$MONTH/$DAY/news/news.notice"); };
destination net_debug { file("/var/log/$HOST/$YEAR/$MONTH/$DAY/debug"); };
destination net_error { file("/var/log/$HOST/$YEAR/$MONTH/$DAY/error"); };
destination net_messages { file("/var/log/$HOST/$YEAR/$MONTH/$DAY/messages"); };
destination net_ppp { file("/var/log$HOST/$YEAR/$MONTH/$DAY/ppp.log"); };
...
log { source(s_net); filter(f_auth); destination(net_auth); };
log { source(s_net); filter(f_cron); destination(net_cron); };
log { source(s_net); filter(f_daemon); destination(net_daemon); };
log { source(s_net); filter(f_kern); destination(net_kern); };
log { source(s_net); filter(f_lpr); destination(net_lpr); };
log { source(s_net); filter(f_syslog3); destination(net_syslog); };
log { source(s_net); filter(f_user); destination(net_user); };
log { source(s_net); filter(f_uucp); destination(net_uucp); };
log { source(s_net); filter(f_mail); destination(net_mail); };
log { source(s_net); filter(f_news); filter(f_crit); destination(net_newscrit); };
log { source(s_net); filter(f_news); filter(f_err); destination(net_newserr); };
log { source(s_net); filter(f_news); filter(f_notice); destination(net_newsnotice); };
log { source(s_net); filter(f_debug); destination(net_debug); };
log { source(s_net); filter(f_error); destination(net_error); };
log { source(s_net); filter(f_messages); destination(net_messages); };
log { source(s_net); filter(f_console); destination(d_console_all); destination(d_xconsole); };
log { source(s_net); filter(f_crit); destination(d_console); };
...
Nelle prime righe di opzione generale è importante il create_dirs!
Non ho aggiunto filtri particolari, ho fatto riferimento a quelli già presenti. Inoltre ho utilizzato le macro proprie di syslog-ng per categorizzare in sotto cartelle i file di log ($HOST $YEAR $MONTH $DAY). Date uno sguardo anche a qualche destinazione particolare e cioè: destination(d_console_all); destination(d_xconsole) con l’uso di questi parametri si indirizzano i messaggi in console dei client sulla console del server in tempo reale!
Fatto riavviate il demone perché si possa mettere in ascolto sulla porta 1000 in attesa dei log dei client.
/etc/init.d/syslog-ng restart
Passiamo ai “clients”. In linea geniale questi non dovranno fare altro che destinare i log verso il server remoto. Quindi aggiungeremo al file di configurazione dei client una direttiva “log” che indirizzi gli stessi messaggi delle sorgenti in locale verso una destinazione remota.
Aggiungete al file di configurazione di ogni server-client due righe simili:
...
destination d_net { tcp( "192.168.1.50" port(1000) log_fifo_size(1000) ); };
# All messages send to a remote site
#
log { source(s_src); destination(d_net); };
...
Riavviate tutti i demoni dei client perché aprano la connessione verso il nostro server di log centralizzato:
/etc/init.d/syslog-ng restart
Se tutto è andato a buon fine potrete notare che nella cartella /var/log sul server “central.example.com” si è create un altero di directory simili a questa
# tree /var/log/client1
/var/log/client1
└── 2013
└── 12
├── 03
│ ├── auth.log
│ ├── cron.log
│ ├── daemon.log
│ ├── debug
│ ├── error
│ ├── kern.log
│ ├── mail.log
│ ├── messages
│ ├── syslog
│ └── user.log
├── 04
│ ├── auth.log
│ ├── cron.log
│ ├── daemon.log
│ ├── debug
│ ├── error
│ ├── kern.log
│ ├── mail.log
│ ├── messages
│ ├── syslog
│ └── user.log
└── 05
├── auth.log
├── cron.log
├── daemon.log
├── debug
├── error
├── kern.log
├── mail.log
├── messages
├── syslog
└── user.log
5 directories, 30 files
NOTA: tutte le macchine sono poste sotto una VPN per questo non mi sono preoccupato di criptare nuovamente lo scambio dei log. Diversamente avremmo dovuto non solo pensare ad utilizzare un protocollo TLS di cifratura del messaggio ma anche un sistema di mutua autenticazione fra client-server basato su certificati x509.
ATTENZIONE: la macchina “central.example.com” deve essere particolarmente protetta contro un eventuale attacco. Mi spiego: non è che tante volte la password di root dei server-client è uguale a quella del server-central? Tutto questo lavoro sarebbe assolutamente vanificato da errori così grossolani!!!
