Mantenere una copia offline dei log non solo offre una maggiore visibilità da una prospettiva di gestione dei sistemi, ma può rivelarsi anche prezioso dopo un incidente di sicurezza nel caso in cui le copie locali dei file di log siano state danneggiate.
Come saprete, il modulo LogManager di NetEye offre una soluzione completa per la gestione dei log in linea con le richieste del Garante della Privacy e ne permette la gestione centralizzata (vedi anche i nostri articoli “Archiviazione dei log e poi?“ e “NetEye Log Management sul blog ufficiale di Elastic”).
Architettura del modulo LogManager:
- sistema di log auditing e data collection basato su rsyslog;
- agent (Safed) per l’invio dei log tramite protocollo syslog (RFC 3164 – di default configurato per l’invio via TCP su porta 514 a garanzia della corretta ricezione dei log inviati);
Il requisito principale da rispettare in questa architettura è garantire la comunicazione tra gli agenti Safed e NetEye sulla porta 514 TCP.
Durante una recente consulenza presso un nostro cliente ci è stata richiesta la possibilità di raccogliere i log da alcuni sistemi remoti in cloud su cui era disponibile solo un accesso remoto via SSH.
In questo articolo, vedremo come è possibile risolvere questo problema con una soluzione basata su reverse tunnel SSH e Safed su macchine Linux/Unix.
Premesse e limitazioni
- Nella soluzione implementata sia i server in cloud che il server NetEye hanno un loro indirizzamento dedicato e sono collegati dietro un NAT.
- L’accesso remoto ai server in cloud via SSH è stato permesso dal server NetEye attraverso alcuni firewall.
- Sia su NetEye che nei server in cloud sono state create utenze specifiche non amministrative per implementare il tunnel SSH (rsyslog-remote).
- La configurazione centralizzata del modulo LogManager non è utilizzabile per gli agenti Safed gestiti con questa configurazione (poiché non è possibile raggiungere l’agente sulla porta 6161 via http).
Implementazione
Un reverse tunnel SSH permette di collegarsi ad un server remoto (dotato di servizio ssh) e inoltrare tutte le connessioni TCP ricevute su una porta, ad un altro host in rete.
Per consentire l’accesso al servizio rsyslog che è in esecuzione sul server Neteye da parte dei server in cloud possiamo creare un reverse tunnel tramite SSH con la seguente riga di comando:
ssh -Nn –f -R *:50514:neteye.mydomain.local:514 rsyslog-remote@mycloud.server
In questo modo viene creata una connessione SSH da NetEye al server in cloud (senza un accesso ad una shell) ed un tunnel che permette di inoltrare tutte le connessioni in ingresso sulla porta TCP 50514 del server in cloud verso la porta 514 del server NetEye.
La comunicazione tra il server in cloud e NetEye è cifrata mediante SSH e quindi sicura.
La opzioni utilizzate del comando SSH sono:
- “-Nn -f”: limita la connessione SSH in background ad un inoltro senza aprire una shell
- “-R”: specifica che si desidera effettuare un reverse tunneling
- “*:50514:neteye.mydomain.local:514”: specifica come deve essere applicato il tunneling, ovvero che tutte le connessioni in ingresso a qualunque degli indirizzi IP del server NetEye sulla porta TCP 50514 dovranno essere redirezionate a neteye.mydomain.local sulla porta TCP 514
- “rsyslog-remote@mycloud.server”: specifica che la connessione al server “mycloud.server” via SSH viene eseguita come utente “rsyslog-remote”
Verifica del reverse tunnel SSH
È possibile verificare se il reverse tunnel è stato creato correttamente con i comandi ncat e netstat.
NetEye
Per non fermare il servizio rsyslog su NetEye possiamo sfruttare una porta diversa dalla 514, per esempio la 515, e creare il reverse tunnel SSH in questo modo:
ssh -Nn –f -R *:50514:neteye.mydomain.local:515 rsyslog-remote@remote.server
Per testare la comunicazione con il server in cloud possiamo utilizzare il comando ncat e creare un server fittizio in ascolto sulla porta 515 con le opzioni -l -p 515:
[rsyslog-remote@neteye ~]$ ncat -l -p 515
Server in cloud
Sul server in cloud, per verificare che la connessione SSH da NetEye sia stata effettuata correttamente, dobbiamo controllare che esista una connessione di rete in listening sull’ip 127.0.0.1 e porta TCP 50514 con il comando netstat:
rsyslog-remote@mycloudserver ~]$ netstat -na | grep 50514
tcp 0 0 127.0.0.1:50514 0.0.0.0:* LISTEN
Ora possiamo testare la connessione col server NetEye utilizzando il comando ncat indicando:
- l’host con cui vogliamo comunicare: 127.0.0.1
- la porta di destinazione: 50514
- un messaggio: “Hello, this is a test from mycloudserver”
[rsyslog-remote@mycloudserver ~]$ ncat 127.0.0.1 50514
Hello, this is a test from mycloudserver
NetEye
Se tutto ha funzionato correttamente, sul server Neteye vedremo apparire il seguente messaggio proveniente dal server in cloud:
[rsyslog-remote@neteye ~]$ ncat -l -p 515
Hello, this is a test from mycloudserver
Configurazione di Safed
Come indicato nelle premesse, la configurazione di Safed deve essere fatta manualmente. Non potremo quindi sfruttare la configurazione centralizzata del modulo LogManager perché non è possibile raggiungere l’agente safed sulla porta 6161 via http.
Nel file di configurazione /etc/safed/safed.conf è importante indicare 127.0.0.1, come indirizzo ip del server, e 50514, come porta di destinazione.
Esempio:
[Output]
network=127.0.0.1:50514:tcp
syslog=13
days=30
maxmsgsize=2048
waittime=10000000
Dopo questa configurazione occorre riavviare il servizio safed e verificare che i log arrivino correttamente su NetEye.
Configurazione di LogManager
Conclusi i test e la configurazione dell’agent Safed, non resta che configurare il modulo LogManager opportunamente.
In Configuration – Main Settings – General Settings è importante configurare a “No” la direttiva “Determine a hostname from Host configuration” come da immagine seguente:
Infine, occorre creare un nuovo host facendo attenzione ad utilizzare l’ip interno di NetEye.
A tutto il resto penserà rsyslog, creando opportunamente i file di log associato a ciascun host remoto.
Conclusioni
Con questa soluzione il nostro cliente è riuscito a raccogliere i log di sistemi remoti raggiungibili solo via SSH velocemente e senza alcuna modifica sull’architettura utilizzata da NetEye, garantendo il funzionamento di svariati altri agenti Safed distribuiti localmente su sistemi operativi eterogenei.
Inoltre, grazie all’accesso SSH da NetEye, è stato possibile implementare un monitoraggio attivo degli dei server in cloud tramite il plugin check_by_ssh.
Giuseppe Di Garbo
Author
