Qualche tempo fa pubblicai un articolo sull’utilizzo del NetEye Log Management per la visualizzazione delle notifiche SMS. Ora, in base all’esperienza acquisita, ho scoperto che ciò che scrissi non era totalmente corretto. Infatti le funzioni di time/date per i filtri Logstash sono leggermente più complicate di ciò che possono sembrare inizialmente. In particolare, la data era scritta nel protocollo SMS nel seguente modo:
June 29th 2016, 10:30:22 CEST 2016
E avevamo utilizzato questo filtro per convertirla:
date {
locale = "en"
match = [ "sms_timestamp_text", "EEE MMM dd HH:mm:ss" ]
}
Col passare del tempo (alcuni giorni dopo l’inizio del mese successivo) abbiamo scoperto però che la data nei primi giorni del mese veniva visualizzata nel seguente modo:
July 1th 2016, 10:30:22 CEST 2016
Poiché utilizziamo un timezone testuale, abbiamo infatti constatato che i filtri applicati sulla data non lo supportano. Nel primo draft abbiamo utilizzato questa regola per riuscire ad eseguire il parse dell’sms_timestamp_text:
match =>[ "message", "%{SMS_TIMESTAMP_SHORT:sms_timestamp_text}
%{WORD:timezone} %{YEAR}:%{INT:sms_phonenumber}:%{GREEDYDATA:sms_text}"
Questi sono i pattern che abbiamo quindi pensato di utilizzare:
In questo modo tutto sembra funzionare correttamente, ma non è così…
Infatti abbiamo scoperto che il nostro filtro non funziona ancora correttamente poiché abbiamo inserito due cifre per il giorno “gg”. Come possiamo quindi risolvere questo problema dato che la data non può essere definita né con una sola cifra “g” né con due “gg”? Dopo aver approfondito tale problematica abbiamo trovato la soluzione più appropriata. È infatti possibile avere “or” come regola all’interno della data e in questo modo poterla far combaciare con il formato della data. Per cui abbiamo modificato il filtro in questo modo:
date {
locale = "en"
match => [ "sms_timestamp_text", "EEE MMM dd HH:mm:ss Z yyyy", "EEE MMM d HH:mm:ss Z yyyy" ]
}
Potete vedere la nuova Z e i parametri yyyy perché se non facciamo combaciare la data completa non può funzionare correttamente. Per essere in grado di analizzare questo correttamente, ho scoperto che il modello utilizzato doveva essere cambiato nel seguente modo:
match => [ "message", "%{SMS_TIMESTAMP:sms_timestamp_text}:%{INT:sms_phonenumber}:%{GREEDYDATA:sms_text}" ]
Come anticipato prima, Logstash non può analizzare i fusi orari testuali (textual time zone). E allora perché lo abbiamo inserito e come dobbiamo comportarci? Sappiamo che la nostra data coincide con il fuso orario dell’Europa occidentale, perciò la soluzione consiste nel mutare il tag nel seguente modo:
I have over 20 years of experience in the IT branch. After first experiences in the field of software development for public transport companies, I finally decided to join the young and growing team of Würth Phoenix. Initially, I was responsible for the internal Linux/Unix infrastructure and the management of CVS software. Afterwards, my main challenge was to establish the meanwhile well-known IT System Management Solution WÜRTHPHOENIX NetEye. As a Product Manager I started building NetEye from scratch, analyzing existing open source models, extending and finally joining them into one single powerful solution. After that, my job turned into a passion: Constant developments, customer installations and support became a matter of personal. Today I use my knowledge as a NetEye Senior Consultant as well as NetEye Solution Architect at Würth Phoenix.
Author
Juergen Vigna
I have over 20 years of experience in the IT branch. After first experiences in the field of software development for public transport companies, I finally decided to join the young and growing team of Würth Phoenix. Initially, I was responsible for the internal Linux/Unix infrastructure and the management of CVS software. Afterwards, my main challenge was to establish the meanwhile well-known IT System Management Solution WÜRTHPHOENIX NetEye. As a Product Manager I started building NetEye from scratch, analyzing existing open source models, extending and finally joining them into one single powerful solution. After that, my job turned into a passion: Constant developments, customer installations and support became a matter of personal. Today I use my knowledge as a NetEye Senior Consultant as well as NetEye Solution Architect at Würth Phoenix.
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
Hello everyone! Today, I’d like to share an exciting improvement we’ve made to the installation and upgrade procedures in NetEye, introducing a faster and more efficient parallel architecture! Why Modernize the Installation and Upgrade Processes? At Würth Phoenix, we strive Read More
Note: This description of a security analyst's daily routine is fictitious. However, the osquery examples have been tested and can therefore be used as a template for your own research. 1. Alarm Detection Today started with a high-severity alarm from our Read More
Scenario NetEye 4 provides a graphical engine to represent time series monitoring data stored in an Influx database: the Grafana engine accessible through the ITOA menu on the left hand side. Grafana is very powerful: it consists of a dashboard Read More