Průvodce nasazením LogMan.io pro partnery

Předimplementační analýza

Každá dodávka by měla začít předimplementační analýzou, která obsahuje seznam všech zdrojů logů, které by měly být připojeny k LogMan.io. Výstupem analýzyje tabulka, kde každý pruh popisuje jeden zdroj logů, způsob, jakým jsou logy shromažďovány (čtení souborů, předávání logů na cílový port atd.), kdo je za zdroj logů z pohledu zákazníka zodpovědný a odhad, kdy by měl být zdroj logů připojen. Viz následující obrázek:

Na obrázku jsou další dva sloupce, které nejsou součástí předimplementační analýzy a které se vyplní později, až dojde k implementaci (kafka topic & dataset). Předem více informací naleznete v části Pásma událostí níže.

MUSÍ BÝT definováno, která doména (URL) bude použita pro hostování LogMan.io. Zákazník nebo partner si MUSÍ sám zajistit příslušné HTTPS SSL certifikáty (viz nginx níže), např. pomocí Let's Encrypt nebo jiné certifikační autority.

LogMan.io cluster a sběrné servery

Servery

Na konci předimplementační analýzy by mělo být jasné, jak velký by měl být objem shromažďovaných protokolů (v událostech nebo zprávách protokolu za sekundu, zkráceně EPS). Protokoly se vždy sbírají z infrastruktury zákazníka, kde je alespoň jeden server vyhrazený pro sběr protokolů (tzv. log collector).

Pokud jde o cluster LogMan.io, existují tři způsoby:

LogMan.io cluster je nasazen v infrastruktuře zákazníka na fyzických a/nebo virtuálních strojích (on-premise).
cluster LogMan.io je nasazen v infrastruktuře partnera a je k dispozici pro více zákazníků, přičemž každému zákazníkovi je přidělen jeden nájemce (SoC, SaaS atd.).

Další informace o konfiguraci fyzických serverů naleznete v části Hardwarová specifikace.

Architektura clusteru

V obou způsobech clusteru MUSÍ být pro cluster LogMan.io k dispozici alespoň jeden server (pro PoC) nebo alespoň tři servery (pro nasazení). Pokud je cluster nasazen v infrastruktuře zákazníka, mohou servery fungovat také jako sběrné servery, takže v tomto případě není třeba mít vyhrazený sběrný server. Architektura tří serverů se může skládat ze tří podobných fyzických serverů nebo ze dvou fyzických serverů a jednoho malého libovolného virtuálního počítače.

Menší nebo nekritická nasazení jsou možná v konfiguraci s jedním strojem.

Další informace o organizaci clusteru LogMan.io naleznete v části Architektura clusteru.

Ukládání dat

Každý fyzický nebo nearbitrační server v clusteru LogMan.io by měl mít k dispozici dostatečné diskové úložiště, aby mohl uchovávat data za požadované časové období z předimplementační analýzy. Mělo by existovat alespoň jedno rychlé (pro aktuální nebo jednodenní zprávy protokolů a témata Kafka) a jedno pomalejší (pro starší data, metadata a konfigurace) datové úložiště namapované na /data/ssd a /data/hdd. Protože všechny služby LogMan.io běží jako kontejnery Docker, složka /var/lib/docker by měla být také namapována na jedno z těchto úložišť.

Podrobné informace o organizaci diskových úložišť, připojování atd. naleznete v části Úložiště dat.

Instalace

DOPORUČENÝM operačním systémem je Linux Ubuntu 22.04 LTS nebo novější. Alternativy jsou Linux RedHat 8 a 7, CentOS 7.

Názvy hostitelů serverů LogMan.io v clusteru LogMan.io by měly mít zápis lm01, lm11 atd. Pokud jsou použity samostatné sběrné servery (viz výše), není požadavek na pojmenování jejich hostitelských jmen. Pokud je součástí dodávky TeskaLabs, měl by být vytvořen uživatel tladmin s právy sudoer.

Na každém serveru (clusteru LogMan.io i kolektoru) by měly být nainstalovány git, docker a docker-compose.

Podrobný návod naleznete v části Manuální instalace.

Všechny služby se pak vytvoří a spustí pomocí příkazu docker-compose up -d ze složky, do které je naklonován repozitář webu (viz následující část):

$ cd /opt/site-tenant-siterepository/lm11
$ docker-compose up -d

Přihlašovací údaje dockeru poskytne partnerovi tým TeskaLabs.

Úložiště a konfigurace webu

Každý partner získá přístup do úložiště GitLab společnosti TeskaLabs, aby zde mohl spravovat konfigurace pro nasazení, což je doporučený způsob ukládání konfigurací pro budoucí konzultace se společností TeskaLabs. Každý partner však může používat i vlastní úložiště GitLab nebo jakékoli jiné úložiště Git a poskytnout týmu TeskaLabs příslušné přístupy (alespoň pro čtení).

Každé nasazení u každého zákazníka by mělo mít samostatný site repository, bez ohledu na to, zda je nainstalován celý cluster LogMan.io, nebo jsou nasazeny pouze sběrné servery. Struktura úložiště site by měla vypadat následovně:

Každý serverový uzel (server) by měl mít samostatnou podsložku v horní části úložiště GitLab. Dále by zde měla být složka s LogMan.io library, která obsahuje deklarace pro parsování, korelaci atd. skupin, config, která obsahuje konfiguraci obrazovky Discover v uživatelském rozhraní a ovládacích panelech, a složka ecs se šablonami indexů pro ElasticSearch.

Každý partner získá přístup k úložišti referenčních stránek, kde jsou připraveny všechny konfigurace včetně parserů a nastavení Discover.

ElasticSearch

Každý uzel v clusteru LogMan.io by měl obsahovat alespoň jeden uzel ElasticSearch master, jeden uzel ElasticSearch data_hot, jeden uzel ElasticSearch data_warm a jeden uzel ElasticSearch data_cold. Všechny uzly ElasticSearch jsou nasazeny prostřednictvím nástroje Docker Compose a jsou součástí úložiště webu/konfigurace. Libovolné uzly v clusteru obsahují pouze jeden hlavní uzel ElasticSearch.

Pokud je použita architektura jednoho serveru, měly by být repliky v ElasticSearch nastaveny na nulu (to bude také poskytnuto po konzultaci s TeskaLabs). Pro ilustraci viz následující úryvek ze souboru Docker Compose, kde je vidět, jak je nasazen horký uzel ElasticSearch:

  lm21-es-hot01:
    network_mode: host
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.2
    depends_on:
      - lm21-es-master
    environment:
      - network.host=lm21
      - node.attr.rack_id=lm21 # Nebo název datového centra. To je určeno pro ES, aby mohlo efektivně a bezpečně spravovat repliky
                                # Pro menší instalace -&gt; název hostitele je v pořádku
      - node.attr.data=hot
      - node.name=lm21-es-hot01
      - node.roles=data_hot,data_content,ingest
      - cluster.name=lmio-es # V podstatě "název databáze"
      - cluster.initial_master_nodes=lm01-es-master,lm11-es-master,lm21-es-master
      - discovery.seed_hosts=lm01:9300,lm11:9300,lm21:9300
      - http.port=9201
      - transport.port=9301 # Interní komunikace mezi uzly
      - "ES_JAVA_OPTS=-Xms16g -Xmx16g -Dlog4j2.formatMsgNoLookups=true"
      # - path.repo=/usr/share/elasticsearch/repo # Tato volba je povolena na vyžádání po instalaci! Není součástí počátečního nastavení (ale máme ji zde, protože je to dílna).
      - ELASTIC_PASSWORD=$ELASTIC_PASSWORD
      - xpack.security.enabled=true
      - xpack.security.transport.ssl.enabled=true
 ...

Další informace o službě ElasticSearch včetně vysvětlení horkých (nejnovějších, jednodenních dat na SSD), teplých (starších) a studených uzlů naleznete v části Nastavení služby ElasticSearch.

ZooKeeper a Kafka

Každý uzel serveru v clusteru LogMan.io by měl obsahovat alespoň jeden uzel ZooKeeper a jeden uzel Kafka. ZooKeeper je úložiště metadat dostupné v celém clusteru, kam Kafka ukládá informace o konzumentech témat, názvech témat atd. a kam LogMan.io ukládá aktuální soubory library a config (viz níže). Nastavení Kafky a ZooKeeperu lze zkopírovat z úložiště referenčního webu a konzultovat s vývojáři TeskaLabs.

Služby

Následující služby by měly být dostupné alespoň na jednom z uzlů LogMan.io a patří mezi ně:

(webový server s certifikátem HTTPS, viz úložiště referenčních stránek).
influxdb (úložiště metrik, viz InfluxDB Setting).
mongo (databáze pro přihlašovací údaje uživatelů, relace atd.)
telegraf (shromažďuje telemetrické metriky z infrastruktury, nory a ElasticSearch a odesílá je do InfluxDB, měl by být nainstalován na každém serveru)
burrow (shromažďuje telemetrické metriky z Kafky a odesílá je do InfluxDB)
seacat- auth (TeskaLabs SeaCat Auth je služba OAuth, která ukládá svá data do mongo)
asab-library (spravuje knihovnu library s deklaracemi)
asab-config (spravuje sekci config)
lmio-remote-control (monitoruje další mikroslužby jako asab-config)
lmio-commander (nahrává knihovnu do ZooKeeper)
lmio-dispatcher (odesílá data z témat lmio-events a lmio-others Kafka do ElasticSearch, měl by běžet alespoň ve třech instancích na každém serveru)

Další informace o SeaCat Auth a jeho části pro správu v uživatelském rozhraní LogMan.io naleznete v dokumentaci TeskaLabs SeaCat Auth.

Informace o tom, jak nahrát knihovnu z úložiště webu do ZooKeeper, najdete v příručce LogMan.io Commander.

UŽIVATELSKÉ ROZHRANÍ

Následující uživatelská rozhraní by měla být nasazena a zpřístupněna prostřednictvím nginx. První implementace by měla být vždy projednána s vývojáři společnosti TeskaLabs.

LogMan.io UI (viz LogMan.io User Interface)
Kibana (zjišťovací obrazovka, vizualizace, ovládací panely a monitorování nad ElasticSearch).
Grafana (ovládací panely telemetrie nad daty z InfluxDB)
ZooKeeper UI (správa dat uložených v ZooKeeper)

Následující obrázek ukazuje Parsery z knihovny importované do ZooKeeper v ZooKeeper UI:

Nasazení rozhraní LogMan.io UI

Nasazení uživatelského rozhraní LogMan.io je při správném nastavení částečně poloautomatický proces. Existuje tedy několik kroků k zajištění bezpečného nasazení uživatelského rozhraní:

Artefakt nasazení uživatelského rozhraní by měl být stažen prostřednictvím úložiště azure, které partnerovi poskytli vývojáři společnosti TeskaLabs. Informace o tom, kde je konkrétní aplikace uživatelského rozhraní uložena, lze získat z CI/CD obrazu úložiště aplikace.
Doporučuje se používat verze tagged, ale mohou nastat situace, kdy je žádoucí použít verzi master. Informace, jak ji nastavit, najdete v souboru docker-compose.yaml úložiště referenčního webu.
Aplikace uživatelského rozhraní musí být sladěna se službami, aby byl zajištěn nejlepší výkon (obvykle nejnovější tag verze). Pokud si nejste jisti, kontaktujte vývojáře společnosti TeskaLabs.

Vytvoření nájemce

Každému zákazníkovi je přiřazen jeden nebo více tenantů. Nájemci jsou malá jména ASCII, která označují data/logy patřící uživateli a ukládají data každého nájemce do samostatného indexu ElasticSearch. Všechny pruhy událostí (viz níže) jsou také specifické pro jednotlivé nájemce.

Vytvoření tenanta v SeaCat Auth pomocí uživatelského rozhraní LogMan.io

Chcete-li vytvořit nájemce, přihlaste se do uživatelského rozhraní LogMan.io s rolí superuživatele, což lze provést prostřednictvím provisioningu. Další informace o provisioningu naleznete v části Provisioning mode dokumentace SeaCat Auth.

V uživatelském rozhraní LogMan.io přejděte v levém menu do sekce Auth a vyberte možnost Tenants. Jakmile se tam dostanete, klikněte na možnost Vytvořit nájemce a napište tam název nájemce. Poté klikněte na modré tlačítko a nájemce by měl být vytvořen:

Poté přejděte do části Pověřovací údaje a přiřaďte nově vytvořeného tenanta všem příslušným uživatelům.

Indexy ElasticSearch

V systému Kibana by měl mít každý nájemce šablony indexů lmio-tenant-events a lmio-tenant-others, kde tenant je název nájemce (viz úložiště referenčních stránek poskytnuté společností TeskaLabs). Šablony indexů lze vložit prostřednictvím nástroje Dev Tools v levém menu aplikace Kibaba.

Po vložení šablon indexů by měla být ručně vytvořena politika ILM (správa životního cyklu indexů) a první indexy, přesně podle pokynů v příručce Nastavení ElasticSearch.

Kafka

V systému Kafka neexistuje žádné specifické nastavení pro vytváření nájemců, kromě níže uvedených pruhů událostí. Vždy se však ujistěte, že témata lmio-events a lmio-others jsou vytvořena správně. Následující příkazy by měly být spuštěny v kontejneru Kafka (např.: docker exec -it lm11_kafka_1 bash):

# # LogMan.io
/usr/bin/kafka-topics --zookeeper lm11:2181 --create --topic lmio-events --replication-factor 1 --partitions 6
/usr/bin/kafka-topics --zookeeper lm11:2181 --create --topic lmio-others --replication-factor 1 --partitions 6
/usr/bin/kafka-topics --zookeeper lm11:2181 --alter --topic lmio-events --config retention.ms=86400000
/usr/bin/kafka-topics --zookeeper lm11:2181 --alter --topic lmio-others --config retention.ms=86400000

# LogMan.io+ &amp; SIEM
/usr/bin/kafka-topics --zookeeper lm11:2181 --create --topic lmio-events-complex --replication-factor 1 --partitions 6
/usr/bin/kafka-topics --zookeeper lm11:2181 --create --topic lmio-lookups --replication-factor 1 --partitions 6

Každé téma Kafky by mělo mít alespoň 6 oddílů (které lze automaticky použít pro paralelní spotřebu), což je vhodný počet pro většinu nasazení.

Důležitá poznámka

Následující část popisuje připojení pruhů událostí k LogMan.io. Znalost architektury LogMan.io z dokumentace je povinná.

Pruhy událostí

Pásma událostí v LogMan.io definují způsob odesílání protokolů do clusteru. Každý pruh událostí je specifický pro shromážděný zdroj, proto by jeden řádek v tabulce předimplementační analýzy měl odpovídat jednomu pruhu událostí. Každý pruh událostí se skládá z jedné služby lmio-collector, jedné služby lmio-ingestor a jedné nebo více instancí služby lmio-parser.

Collector

LogMan.io Collector by měl běžet na sběrném serveru nebo na jednom či více serverech LogMan.io, pokud jsou součástí stejné vnitřní sítě. Ukázka konfigurace je součástí úložiště referenčního webu.

LogMan.io Collector dokáže prostřednictvím konfigurace YAML otevřít port TCP/UDP, ze kterého bude získávat protokoly, číst soubory, otevřít server WEC, číst z témat Kafka, účtů Azure atd. Obsáhlá dokumentace je k dispozici zde: LogMan.io Collector

Následující ukázka konfigurace otevírá port 12009/UDP na serveru, na který je kolektor nainstalován, a přesměrovává shromážděná data prostřednictvím WebSocket na server lm11 na port 8600, kde by měl být spuštěn lmio-ingestor:

input:Datagram:UDPInput:
  adresa: 0.0.0.0:12009
  output: WebSocketOutput

output:WebSocket:WebSocketOutput:
  url: http://lm11:8600/ws
  tenant: mytenant
  debug: false
  prepend_meta: false

url je buď název hostitele serveru a port Ingestoru, pokud jsou Collector a Ingestor nasazeny na stejném serveru, nebo URL s https://, pokud je použit server Collector mimo vnitřní síť. Pak je nutné zadat certifikáty HTTPS, více informací naleznete v části output:WebSocket v příručce LogMan.io Collector Outputs.

Parametr tenant je název tenanta, ke kterému protokoly patří. Název tenantu se pak automaticky propaguje do Ingestoru a Parseru.

Ingestor

LogMan.io Ingestor přebírá zprávy logů z Collectoru spolu s metadaty a ukládá je do Kafky do tématu, které začíná předponou collected-tenant-, kde tenant je název tenantu, ke kterému logy patří, a technology je název technologie, ze které jsou data shromažďována, například microsoft-windows.

Následující sekce v souborech CONF je nutné nastavit vždy jinak pro každý pruh událostí:

# Výstup
[pipeline:WSPipeline:KafkaSink]
topic=sběrný-tenant-technologie

# Web API
[Web]
listen=0.0.0.0 8600

Port v sekci listen by měl odpovídat portu v konfiguraci YAML kolektoru (pokud je kolektor nasazen na stejném serveru) nebo nastavení v nginx (pokud jsou data sbírána ze serveru kolektoru mimo vnitřní síť). Viz úložiště referenčních stránek poskytnuté vývojáři společnosti TeskaLabs.

Parser

Parser by měl být nasazen ve více instancích, aby bylo možné škálovat výkon. Parsuje data z původních bajtů nebo řetězců do slovníku v zadaném schématu, jako je ECS (ElasticSearch Schema) nebo CEF (Common Event Format), přičemž používá parsovací skupinu z knihovny načtené v ZooKeeper. Je důležité zadat téma Kafka, ze kterého se má číst, což je stejné téma, jaké je zadáno v konfiguraci Ingestoru:

[deklarace]
library=zk://lm11:2181/lmio/library.lib
groups=Parsers/parsing-group
raw_event=log.original

# Pipeline
[pipeline:ParsersPipeline:KafkaSource]
topic=sběrný-tenant-technologie
group_id=lmio_parser_collected
auto.offset.reset=nejmenší

Parsers/parsing-group je umístění skupiny parsování z knihovny načtené do ZooKeeperu prostřednictvím LogMan.io Commander. Při prvním pokusu nemusí existovat, protože všechna data jsou pak automaticky odesílána do indexu lmio-tenant-others. Jakmile je parsovací skupina připravena, proběhne parsování a data lze zobrazit ve formátu dokumentu v indexu lmio-tenant-events.

Kafka topics

Před spuštěním všech tří služeb pomocí příkazu docker-compose up -d je důležité zkontrolovat stav konkrétního tématu Kafka collected-tenant-technology (kde tenant je název nájemce a technology je název připojené technologie/typu zařízení). V kontejneru Kafka (např.: docker exec -it lm11_kafka_1 bash) je třeba spustit následující příkazy:

/usr/bin/kafka-topics --zookeeper lm11:2181 --create --topic collected-tenant-technology --replication-factor 1 --partitions 6
/usr/bin/kafka-topics --zookeeper lm11:2181 --alter --topic collected-tenant-technology --config retention.ms=86400000

Parsování skupin

Pro většinu běžných technologií již TeskaLabs připravila parsovací skupiny podle schématu ECS. Obraťte se prosím na vývojáře společnosti TeskaLabs. Vzhledem k tomu, že všechny parsery jsou napsány v deklarativním jazyce, lze všechny parsovací skupiny v knihovně snadno upravit. Název skupiny by měl být stejný jako název atributu dataset zapsaný v deklaraci skupin parserů.

Další informace o našem deklarativním jazyce naleznete v oficiální dokumentaci: SP-Lang

Po nasazení skupiny parserů prostřednictvím nástroje LogMan.io Commander by měl být příslušný parser (příslušné parsery) restartován (restartovány).

Nasazení

Na serverech LogMan.io stačí spustit následující příkaz ve složce, do které je naklonován repozitář site-:

docker-compose up -d

Kolekci protokolů lze poté zkontrolovat v kontejneru Docker Kafka prostřednictvím konzolového konzumenta Kafka:

/usr/bin/kafka-console-consumer --bootstrap-server lm11:9092 --topic collected-tenant-technology --from-beginning

Data jsou čerpána v Parseru z tématu collected-tenant-technology do tématu lmio-events nebo lmio-others a poté v Dispatcheru (lmio-dispatcher, viz výše) do indexu lmio-tenant-events nebo lmio-tenant-others v ElasticSearch.

SIEM

Část SIEM by nyní měla být vždy projednána s vývojáři TeskaLabs, kteří zajistí první korelační pravidla a záznamy do konfiguračních souborů a Docker Compose. Část SIEM se skládá především z různých instancí lmio-correlators a lmio-watcher.

Další informace naleznete v části LogMan.io Correlator.