Provvedimento del garante e log dei Firewall Checkpoint
Come sapete il provvedimento del garante richiede di monitorare gli accessi ai sistemi informatici, tra questi uno dei piu’ critici e’ sicuramente il vostro firewall, come fare a monitorare gli accessi in presenza di un firewall Checkpoint ? Vediamolo insieme:
In questo caso abbiamo un cluster di firewall Checkpoint basati su Sistema operativo IPSO che e’ un derivato da FreeBSD. Essendo un OS Unix like, abbiamo il processo syslogd che opportunamente configurato puo’ redirigere i messaggi di autenticazione verso NetEye.
Prima cosa da fare e’ modificare /etc/syslog.conf , che di norma si presenta in questo modo
#This file was AUTOMATICALLY GENERATED
#Generated by /bin/syslog_xlate on Mon Jan 12 19:11:49 2004
#
#DO NOT EDIT – EDITED TO SEND MESSAGES BASED ON FACILITY
#
*.err;auth.debugadmin
*.notice;cron.*;auth.info;kern.debug/var/log/messages
*.emerg*
*.err;auth.notice;kern.debug/dev/console
aggiungiamo in fondo la riga
auth.* @10.10.1.120
dove 10.10.1.120 e’ l’ indirizzo del NetEye, ricordatevi che tra auth.* e @10.10.1.120 devono essere separati da almeno un TAB.
A questo punto e’ sufficiente riavviare il syslogd e tutto dovrebbe funzionare.
Per essere sicuri che la modifica sia valida anche al prossimo riavvio del Firewall ( IPSO tende a sovrascrivere i file modificati manualmente), e’ necessario salvarsi il file modificato e ricopiarlo ad ogni avvio del firewall.
Un sistema puo’ essere il seguente; copiate il file originale in un posto sicuro
cp /etc/syslog.conf /var/admin/syslog.bak
modificate il file /var/etc/rc.local (che viene eseguito durante la procedura di reboot) ed inserite le seguenti righe:
questa procedura si occupa di ricopiare il file che avete salvato nella sua posizione originale e riavviare il demone del syslog.
Se avete fatto tutto correttamente il firewall inviera’ le informazioni relative agli accessi al NetEye; ricordatevi che se avete un cluster dovete ripetere l’ operazione su ogni nodo.
Hi everybody, I’m Andrea and my contribution to this blog is to give hints of the monitoring issue from an IT manager point of view. I was born in Bolzano in 1965 and my professional path started 25 years ago operating on the technical field as programmer, system/database administrator, network engineer, consultancy and so on. I’ve been living in Milan for 10 years working for multinational IT companies and I decided to return to Bolzano after my marriage and the birth of my daughter.
I love sailing and diving in the summer, skiing in the winter and travelling off-road with my Landcruiser anytime
Author
Andrea di Lernia
Hi everybody, I’m Andrea and my contribution to this blog is to give hints of the monitoring issue from an IT manager point of view. I was born in Bolzano in 1965 and my professional path started 25 years ago operating on the technical field as programmer, system/database administrator, network engineer, consultancy and so on. I’ve been living in Milan for 10 years working for multinational IT companies and I decided to return to Bolzano after my marriage and the birth of my daughter.
I love sailing and diving in the summer, skiing in the winter and travelling off-road with my Landcruiser anytime
When using Kibana in environments that require a proxy to reach external services, you might encounter issues with unrecognized SSL certificates. Specifically, if the proxy is exposed with its own certificate and acts as an SSL terminator, requests made by Read More
In a previous post we went through the configuration of the Elastic Universal Profiling in NetEye, we saw how we can profile applications written in programming languages that do not compile to native code (for example python, php, perl, etc.). Read More
Elastic 8.16, which comes with NetEye 4.39, made Elastic Universal Profiling generally available for self-hosted installations. This means that NetEye SIEM installations will now be able to take advantage of the continuous profiling solution by Elastic. In this blogpost we'll Read More
In the first part of this series, we explored how Jira Service Management (JSM) helps streamline Incident Management, aligning with ITIL v4 best practices. Incident Management aims to restore normal service operation as quickly as possible after a disruption, ensuring Read More
Hello everyone! Today, I'd like to briefly discuss an improvement to the update and upgrade procedures that we've started to adopt with NetEye 4.39! What we wanted to improve One aspect that made quite an impact was that whenever the Read More