2. Elastisk stack: analys av säkerhetsloggar. Logstash

2. Elastisk stack: analys av säkerhetsloggar. Logstash

Förr artikeln vi träffades ELK stack, vilka mjukvaruprodukter den består av. Och den första uppgiften en ingenjör står inför när han arbetar med ELK-stacken är att skicka loggar för lagring i elasticsearch för efterföljande analys. Detta är dock bara läpparnas bekännelse, elasticsearch lagrar loggar i form av dokument med vissa fält och värden, vilket innebär att ingenjören måste använda olika verktyg för att analysera meddelandet som skickas från slutsystemen. Detta kan göras på flera sätt - skriv ett program själv som lägger till dokument i databasen med hjälp av API:t, eller använd färdiga lösningar. I den här kursen kommer vi att överväga lösningen Logstash, som är en del av ELK-stacken. Vi ska titta på hur vi kan skicka loggar från slutpunktssystem till Logstash, och sedan konfigurerar vi en konfigurationsfil för att analysera och omdirigera till Elasticsearch-databasen. För att göra detta tar vi loggar från Check Points brandvägg som inkommande system.

Kursen täcker inte installationen av ELK stack, eftersom det finns ett stort antal artiklar om detta ämne; vi kommer att överväga konfigurationskomponenten.

Låt oss göra upp en handlingsplan för Logstash-konfiguration:

  1. Kontrollera att elasticsearch accepterar loggar (kontrollerar portens funktion och öppenhet).
  2. Vi överväger hur vi kan skicka händelser till Logstash, välja en metod och implementera den.
  3. Vi konfigurerar Input i Logstash-konfigurationsfilen.
  4. Vi konfigurerar Output i Logstash-konfigurationsfilen i felsökningsläge för att förstå hur loggmeddelandet ser ut.
  5. Ställa in filter.
  6. Ställa in rätt utdata i ElasticSearch.
  7. Logstash lanseras.
  8. Kollar loggarna i Kibana.

Låt oss titta på varje punkt mer i detalj:

Kontrollera att elasticsearch accepterar loggar

För att göra detta kan du använda curl-kommandot för att kontrollera åtkomst till Elasticsearch från systemet där Logstash är utplacerat. Om du har konfigurerat autentisering så överför vi även användaren/lösenordet via curl, med angivande av port 9200 om du inte har ändrat det. Om du får ett svar som liknar det nedan är allt i sin ordning.

[elastic@elasticsearch ~]$ curl -u <<user_name>> : <<password>> -sS -XGET "<<ip_address_elasticsearch>>: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 ~]$

Om svaret inte tas emot kan det finnas flera typer av fel: elasticsearch-processen körs inte, fel port är specificerad eller porten blockeras av en brandvägg på servern där elasticsearch är installerad.

Låt oss titta på hur du kan skicka loggar till Logstash från en kontrollpunktsbrandvägg

Från Check Point hanteringsserver kan du skicka loggar till Logstash via syslog med hjälp av log_exporter-verktyget, du kan läsa mer om det här artikeln, här lämnar vi bara kommandot som skapar strömmen:

cp_log_export lägg till namn check_point_syslog målserver < > target-port 5555 protokoll tcp format generiskt läsläge semi-unified

< > - adress till servern som Logstash körs på, target-port 5555 - port som vi ska skicka loggar till, att skicka loggar via tcp kan ladda servern, så i vissa fall är det mer korrekt att använda udp.

Ställa in INPUT i Logstash-konfigurationsfilen

2. Elastisk stack: analys av säkerhetsloggar. Logstash

Som standard finns konfigurationsfilen i katalogen /etc/logstash/conf.d/. Konfigurationsfilen består av 3 meningsfulla delar: INPUT, FILTER, OUTPUT. I INPUT vi anger var systemet kommer att ta loggar ifrån, in FILTER analysera loggen - ställ in hur du delar upp meddelandet i fält och värden, i PRODUKTION vi konfigurerar utgångsströmmen - dit de analyserade loggarna kommer att skickas.

Låt oss först konfigurera INPUT, överväg några av de typer som kan vara - fil, tcp och exe.

TCP:

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

läge => "server"
Indikerar att Logstash accepterar anslutningar.

port => 5555
värd => "10.10.1.205"
Vi accepterar anslutningar via IP-adress 10.10.1.205 (Logstash), port 5555 - porten måste tillåtas av brandväggspolicyn.

typ => "kontrollpunkt"
Vi markerar dokumentet, mycket bekvämt om du har flera inkommande anslutningar. Därefter kan du för varje anslutning skriva ditt eget filter med den logiska if-konstruktionen.

Fil:

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

Beskrivning av inställningar:
sökväg => "/var/log/openvas_report/*"
Vi anger i vilken katalog filerna ska läsas.

typ => "openvas"
Event typ.

start_position => "början"
När du ändrar en fil läser den hela filen; om du ställer in "slut" väntar systemet på att nya poster ska dyka upp i slutet av filen.

Exec:

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

Med denna ingång startas ett (endast!) skalkommando och dess utdata omvandlas till ett loggmeddelande.

kommando => "ls -alh"
Kommandot vars utdata vi är intresserade av.

intervall => 30
Kommandoanropsintervall i sekunder.

För att ta emot loggar från brandväggen registrerar vi ett filter tcp eller udp, beroende på hur loggarna skickas till Logstash.

Vi konfigurerar Output i Logstash-konfigurationsfilen i felsökningsläge för att förstå hur loggmeddelandet ser ut

Efter att vi har konfigurerat INPUT måste vi förstå hur loggmeddelandet kommer att se ut och vilka metoder som behöver användas för att konfigurera loggfiltret (parser).

För att göra detta kommer vi att använda ett filter som matar ut resultatet till stdout för att se det ursprungliga meddelandet; den fullständiga konfigurationsfilen för tillfället kommer att se ut så här:

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

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

Kör kommandot för att kontrollera:
sudo /usr/share/logstash/bin//logstash -f /etc/logstash/conf.d/checkpoint.conf
Vi ser resultatet, bilden är klickbar:

2. Elastisk stack: analys av säkerhetsloggar. Logstash

Om du kopierar det kommer det att se ut så här:

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="[email protected]" 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,

När vi tittar på dessa meddelanden förstår vi att loggarna ser ut som: fält = värde eller nyckel = värde, vilket betyder att ett filter som heter kv är lämpligt. För att välja rätt filter för varje specifikt fall skulle det vara en bra idé att bekanta dig med dem i den tekniska dokumentationen, eller fråga en vän.

Ställa in filter

I det sista steget valde vi kv, konfigurationen av detta filter presenteras nedan:

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

Vi väljer symbolen med vilken vi ska dividera fältet och värdet - "=". Om vi ​​har identiska poster i loggen sparar vi bara en instans i databasen, annars kommer du att få en rad identiska värden, det vill säga om vi har meddelandet "foo = some foo=some" skriver vi bara foo = några.

Ställa in rätt utdata i ElasticSearch

När filter är konfigurerat kan du ladda upp loggar till databasen elastisk sökning:

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

Om dokumentet är signerat med kontrollpunktstypen sparar vi händelsen i elasticsearch-databasen, som accepterar anslutningar 10.10.1.200 på port 9200 som standard. Varje dokument sparas till ett specifikt index, i detta fall sparar vi till indexet "checkpoint-" + aktuellt tidsdatum. Varje index kan ha en specifik uppsättning fält, eller skapas automatiskt när ett nytt fält dyker upp i ett meddelande; fältinställningar och deras typ kan ses i mappningar.

Om du har autentisering konfigurerad (vi ska titta på det senare), måste autentiseringsuppgifterna för att skriva till ett specifikt index anges, i det här exemplet är det "tssolution" med lösenordet "cool". Du kan särskilja användarrättigheter för att bara skriva loggar till ett specifikt index och inte mer.

Starta Logstash.

Logstash konfigurationsfil:

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 kontrollerar konfigurationsfilen för korrekthet:
/usr/share/logstash/bin//logstash -f checkpoint.conf
2. Elastisk stack: analys av säkerhetsloggar. Logstash

Starta Logstash-processen:
sudo systemctl start logstash

Vi kontrollerar att processen har startat:
sudo systemctl status logstash

2. Elastisk stack: analys av säkerhetsloggar. Logstash

Låt oss kontrollera om uttaget är uppe:
netstat -nat |grep 5555

2. Elastisk stack: analys av säkerhetsloggar. Logstash

Kollar loggarna i Kibana.

Efter att allt är igång, gå till Kibana - Upptäck, se till att allt är rätt konfigurerat, bilden är klickbar!

2. Elastisk stack: analys av säkerhetsloggar. Logstash

Alla loggar är på plats och vi kan se alla fält och deras värden!

Slutsats

Vi tittade på hur man skriver en Logstash-konfigurationsfil, och som ett resultat fick vi en parser av alla fält och värden. Nu kan vi arbeta med att söka och plotta för specifika fält. Nästa i kursen kommer vi att titta på visualisering i Kibana och skapa en enkel instrumentpanel. Det är värt att nämna att Logstash-konfigurationsfilen ständigt behöver uppdateras i vissa situationer, till exempel när vi vill byta ut värdet på ett fält från ett tal till ett ord. I efterföljande artiklar kommer vi att göra detta ständigt.

Så håll utkik (Telegram, Facebook, VK, TS Lösningsblogg), Yandex.Zen.

Källa: will.com

Lägg en kommentar