🥇2. Elastic stack: analyse av sikkerhetslogger. Logstash

2. Elastic Stack: analyse av security-loggar. Logstash

Tidligere artikkelen ble vi kjent med ELK-stacken, hvilke programvareprodukter den består av. Den første oppgaven en ingeniør står overfor når man arbeider med ELK-stacken er å sende logger for lagring i Elasticsearch for videre analyse. Men dette er bare ord, Elasticsearch lagrer logger som dokumenter med bestemte felt og verdier, noe som betyr at ingeniøren må bruke forskjellige verktøy for å parse meldingen som sendes fra slutt-systemene. Dette kan gjøres på flere måter — ved å skrive et program som via API legger til dokumenter i databasen, eller ved å bruke eksisterende løsninger. I dette kurset vil vi vurdere løsningen Logstash, som er en del av ELK-stacken. Vi vil se på hvordan vi kan sende logger fra slutt-systemer til Logstash, og deretter bør vi konfigurere konfigurasjonsfilen for parsing og omdirigering til databasen Elasticsearch. Til dette tar vi logger fra brannmuren Check Point som inngangssystem.

I løpet av kurset vil vi ikke vurdere installasjonen av ELK-stacken, ettersom det finnes et stort antall artikler om dette emnet, og vi vil se på den konfigurasjonsmessige delen.

Vi lager en handlingsplan for konfigureringen av Logstash:

Sjekker at Elasticsearch vil motta logger (sjekker funksjonalitet og portens åpenhet).
Vi ser på hvordan vi kan sende hendelser til Logstash, velger metode og implementerer den.
Konfigurerer Input i konfigurasjonsfilen for Logstash.
Konfigurerer Output i konfigurasjonsfilen for Logstash i debug-modus, for å forstå hvordan loggmeldingen ser ut.
Konfigurerer Filter.
Konfigurerer korrekt Output i Elasticsearch.
Starter Logstash.
Sjekker logger i Kibana.

Vi vil se nærmere på hver enkelt punkt:

Sjekker at Elasticsearch vil motta logger

For dette kan du sjekke tilgjengeligheten av Elasticsearch fra systemet der Logstash er installert ved å bruke kommandoen curl. Hvis du har konfigurert autentisering, send også brukernavn/passord gjennom curl, og spesifiser port 9200 hvis du ikke har endret den. Hvis du får et svar som er likt det som er angitt nedenfor, er alt i orden.

[elastic@elasticsearch ~]$ curl -u <> : <> -sS -XGET "<>:9200"
{
  "name" : "elastic-1",
  "cluster_name" : "project",
  "cluster_uuid" : "sQzjTTuCR8q4ZO6DrEis0A",
  "version" : {
    "number" : "7.4.1",
    "build_flavor" : "default",
    "build_type" : "rpm",
    "build_hash" : "fc0eeb6e2c25915d63d871d344e3d0b45ea0ea1e",
    "build_date" : "2019-10-22T17:16:35.176724Z",
    "build_snapshot" : false,
    "lucene_version" : "8.2.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}
[elastic@elasticsearch ~]$

Hvis svaret ikke kom, kan der være flere former for fejl: elasticsearch-processen fungerer ikke, den forkerte port er angivet, eller porten er blokeret af en firewall på serveren, hvor elasticsearch kører.

Lad os overveje, hvordan man kan sende logs til Logstash fra en firewall check point

Fra Check Point management server kan man sende logs til Logstash via syslog ved hjælp af værktøjet log_exporter, som du kan læse mere om i denne artikkelen, her lader vi kun kommandoen, der opretter strømmen:

cp_log_export add name check_point_syslog target-server <> target-port 5555 protocol tcp format generic read-mode semi-unified

<> — adressen på serveren, hvor Logstash kører, target-port 5555 — porten, som vi sender logs til; sending af logs over tcp kan overbelaste serveren, så i nogle tilfælde er det bedre at bruge udp.

Vi konfigurerer INPUT i konfigurationsfilen Logstash

2. Elastic Stack: analyse av security-loggar. Logstash

Som standard ligger konfigurationsfilen i mappen /etc/logstash/conf.d/. Konfigurationsfilen består af 3 meningsfulde dele: INPUT, FILTER, OUTPUT. I INPUT angiver vi, hvor systemet skal hente logs, i FILTER parser vi loggen — vi konfigurerer, hvordan vi deler meddelelsen op i felter og værdier, i OUTPUT konfigurerer vi output-strømmen — hvor de parsede logs skal sendes hen.

Lad os først konfigurere INPUT, og overveje nogle typer, der kan være — file, tcp og exe.

Tcp:

input {
tcp {
    port => 5555
    host => “10.10.1.205”
    type => "checkpoint"
    mode => "server"
}
}

mode => «server»
betegner, at Logstash accepterer forbindelser.

port => 5555
host => “10.10.1.205”
Vi accepterer forbindelser via IP-adressen 10.10.1.205 (Logstash), port 5555 — porten skal være tilladt af firewallens politik.

type => «checkpoint»
Mærker dokumentet, hvilket er meget nyttigt, hvis du har flere indkommende forbindelser. Senere kan der skrives et filter for hver forbindelse ved hjælp af den logiske konstruktion if.

File:

input {
  file {
    path => "\/var\/log\/openvas_report\/*"
    type => "openvas"
    start_position => "beginning"
    }
}

Beskrivelse af indstillinger:
path => «\/var\/log\/openvas_report\/*»
Angir directoryen der filene skal leses.

type => «openvas»
Type av hendelse.

start_position => «beginning»
Ved endring av filen leses hele filen, hvis «end» settes, venter systemet på nye oppføringer på slutten av filen.

Exec:

input {
  exec {
    command => "ls -alh"
    interval => 30
  }
}

Med denne inputen kjøres (bare!) et shell-kommando, og dens utdata pakkes inn i en loggmelding.

command => «ls -alh»
Kommandoen hvis utdata vi er interessert i.

interval => 30
Intervall for å kalle kommandoen i sekunder.

For å motta logger fra brannmuren setter vi opp filteret tcp eller udp, avhengig av hvordan loggene sendes til Logstash.

Vi konfigurerer Output i konfigurasjonsfilen for Logstash i debug-modus, for å forstå hvordan loggmeldingen ser ut.

Etter at vi har konfigurert INPUT, må vi forstå hvordan loggmeldingen vil se ut, hvilke metoder som må brukes for å konfigurere filteret (parseren) for loggene.

For dette vil vi bruke et filter som gir resultatet i stdout for å kunne se den originale meldingen, den fullstendige konfigurasjonsfilen vil se slik ut for øyeblikket:

input 
{
         tcp 
         {
                port => 5555
   	  	type => "checkpoint"
    		mode => "server"
                host => “10.10.1.205”
   	 }
}

output 
{
	if [type] == "checkpoint" 
       {
		stdout { codec=> json }
	}
}

Kjør kommandoen for å sjekke:
sudo /usr/share/logstash/bin//logstash -f /etc/logstash/conf.d/checkpoint.conf
Vi ser resultatet, bildet er klikkbart:

Hvis vi kopierer dette vil det se slik ut:

action="Accept" conn_direction="Internal" contextnum="1" ifdir="outbound" ifname="bond1.101" logid="0" loguid="{0x5dfb8c13,0x5,0xfe0a0a0a,0xc0000000}" origin="10.10.10.254" originsicname="CN=ts-spb-cpgw-01,O=cp-spb-mgmt-01.tssolution.local.kncafb" sequencenum="8" time="1576766483" version="5" context_num="1" dst="10.10.10.10" dst_machine_name="ts-spb-dc-01@tssolution.local" layer_name="TSS-Standard Security" layer_name="TSS-Standard Application" layer_uuid="dae7f01c-4c98-4c3a-a643-bfbb8fcf40f0" layer_uuid="dbee3718-cf2f-4de0-8681-529cb75be9a6" match_id="8" match_id="33554431" parent_rule="0" parent_rule="0" rule_action="Accept" rule_action="Accept" rule_name="Implicit Cleanup" rule_uid="6dc2396f-9644-4546-8f32-95d98a3344e6" product="VPN-1 & FireWall-1" proto="17" s_port="37317" service="53" service_id="domain-udp" src="10.10.1.180" ","type":"qqqqq","host":"10.10.10.250","@version":"1","port":50620}{"@timestamp":"2019-12-19T14:50:12.153Z","message":"time="1576766483" action="Accept" conn_direction="Internal" contextnum="1" ifdir="outbound" ifname="bond1.101" logid="0" loguid="{0x5dfb8c13,

Ser vi på disse meldingene, forstår vi at loggene har formatet: felt = verdi eller key = value, og derfor er det en filtreringsmetode kalt kv. For å velge riktig filter for hver spesifikke situasjon, ville det vært lurt å gjøre seg kjent med dem i den tekniske dokumentasjonen, eller spørre en venn.

Konfigurerer Filter

I forrige steg valgte vi kv, nedenfor er konfigureringen for dette filteret:

filter {
if [type] == "checkpoint"{
	kv {
		value_split => "="
		allow_duplicate_values => false
	}
}
}

Vi velger symbolet som vil dele feltet og verdien — “=”. Hvis vi har like oppføringer i loggen, lagrer vi kun én instans i databasen, ellers vil det bli en matrise av identiske verdier, det vil si hvis vi har meldingen “foo = some foo=some” lagrer vi kun foo = some.

Konfigurerer korrekt Output i ElasticSearch

Når Filteret er konfigurert kan loggene eksporteres til databasen elasticsearch:

output 
{
if [type] == "checkpoint"
{
 	elasticsearch 
        {
		hosts => ["10.10.1.200:9200"]
		index => "checkpoint-%{+YYYY.MM.dd}"
    		user => "tssolution"
    		password => "cool"
  	}
}
}

Hvis dokumentet er signert med typen checkpoint, lagrer vi hendelsen i Elasticsearch-databasen, som tar imot tilkoblinger på 10.10.1.200 på port 9200 som standard. Hver dokument lagres i et bestemt indeks, i dette tilfellet lagrer vi i indeksen «checkpoint-» + gjeldende dato. Hver indeks kan ha et bestemt sett med felt, eller opprettes automatisk ved fremkomsten av et nytt felt i meldingen, innstillingene for feltene og deres type kan ses i mappings.

Hvis du har konfigurert autentisering (som vi vil diskutere senere), må du absolutt oppgi legitimasjon for å kunne skrive til et bestemt indeks, i dette eksempelet «tssolution» med passordet «cool». Du kan begrense brukerrettigheter til å skrive logger kun til et spesifikt indeks og ingen andre.

Starter Logstash.

Konfigurasjonsfilen for Logstash:

input 
{
         tcp 
         {
                port => 5555
  	  	type => "checkpoint"
    		mode => "server"
                host => “10.10.1.205”
   	 }
}

filter {
        if [type] == "checkpoint"{
	kv {
		value_split => "="
		allow_duplicate_values => false
	}
        }
}

output 
{
if [type] == "checkpoint"
{
 	elasticsearch 
        {
		hosts => ["10.10.1.200:9200"]
		index => "checkpoint-%{+YYYY.MM.dd}"
    		user => "tssolution"
    		password => "cool"
  	}
}
}

Vi kontrollerer konfigurasjonsfilen for korrekt opprettelse:
/usr/share/logstash/bin//logstash -f checkpoint.conf
2. Elastic Stack: analyse av security-loggar. Logstash

Vi starter Logstash-prosessen:
sudo systemctl start logstash

Vi sjekker om prosessen har startet:
sudo systemctl status logstash

2. Elastic Stack: analyse av security-loggar. Logstash

Vi sjekker om sokkelen er oppe:
netstat -nat |grep 5555

Sjekker logger i Kibana.

Når alt er oppe og køre, går vi ind i Kibana - Discover, og sørger for at alt er sat op korrekt, bildet er klikbart!

Alle loggene er på plass, og vi kan se alle felt og deres verdier!

Konklusjon

Vi har sett på hvordan man skriver en konfigurasjonsfil for Logstash, og vi fikk en parser for alle felt og verdier. Nå kan vi jobbe med søk og lage grafer basert på bestemte felt. I løpet av kurset vil vi se på visualisering i Kibana og lage et enkelt dashboard. Det er verdt å nevne at konfigurasjonsfilen for Logstash må skrives omskrevet i bestemte situasjoner, for eksempel når vi ønsker å erstatte et feltverdi fra tall til ord. I de kommende artiklene vil vi gjøre dette jevnlig.

Så følg med på oppdateringene (Telegram, Facebook, VK, TS Solution Blog), Yandex.Zen.

Kilde: habr.com