OSI:Netmon/Instalace Graylog

Z HelpDesk

Instalace

Repozitář s konfigurací

Užitečné nastavení

  • Zvýšení paměti pro Javu jak pro Graylog tak pro Elasticsearch na 5 GB (pro případ složitějších dotazů a plynulejší běh)
/etc/default/elasticsearch - ES_JAVA_OPTS="-Xms5g -Xmx5g"
/etc/default/graylog-server - GRAYLOG_SERVER_JAVA_OPTS="-Xms5g -Xmx5g ..."
  • Přidat možnost wildcard full-text vyhledávání *text* (pozor nepřidávat dotazy s těmito znaky do dashboardů - výkon)
/etc/graylog/server/server.conf - allow_leading_wildcard_searches = true

Správa uživatelů

  • Uživatelé nejsou automaticky generováni po přihlášení přes shibolet. Je třeba je nejdříve vytvořit - System -> Users and Teams. Username se nastavuje na orion jméno, dobré je vyplnit i email a time zoónu nastaviut na Europe/Prague pro správný čas logů. Heslo uživatelům je možné nastavit libovolně (ideálně nějaký hash), přes to se stejně neprovádí autentizace. Graylog má offline admina, kterému se generuje heslo při instalaci. Členové KPS mají normálně nastavenou roli Admin.

Přidání read-only uživatele

  • Stejný postup jako přidání nového uživatele, ale je mu nastavena pouze role Reader (výchozí nastavení). Tomuto uživateli se pak musí nasdílet potřebné streamy - Streams -> Share -> Viewer -> Add. Pak může tento uživatel používat Search funkcionalitu s konkrétním streamem. Pokud mu předvytvoříme dashboard, tak i ten je nutné uživateli nasdílet - Dashboards -> Share -> Viewer -> Add. Uvnitř dashboardů lze vytvářet záložky a může se tak manipulovat s více dashboardy najednou např. pro účely KPS a jiné pro bezpečáky.

Zálohování Graylog konfigurace

  • Samotná konfigurace se ukládá do MongoDB - ta samotná lze zálohovat a je pravidelně zálohovaná. Celá instance graylogu však lze "modulárně" zálohovat pomocí funkcionality Content packů. System -> Content Packs -> Create Content Packs vede na klikací výběr položek, které jsou exportovány jako JSON. Tyto konfigurace pak lze přenášet mezi různými Graylog instancemi např. přenést nastavení inpůtů, streamů, pipelineů a dashboardů pro TACACS. Content pack lze také průběžně verzovat uvnitř Graylogu a také se po větších změnách musí manuálně umístit do repozitáře netmon-conf.

Vytváření vlastních lookup tables

  • Graylog umožňuje přiřazovat k logům vlastní fields, které lze definovat při vstupu. Ve složce /etc/graylog/lookup_tables se nachází skriptama generované .csv soubory ve tvatu "klíč","hodnota","hodnota". Tento soubor se pak musí nechat Graylogem zpracovávat a načítat při změnách System -> Lookup Tables -> Data Adapters. Lookup tables nemusí být pouze záležitostí .csv souborů, ale používá se i DNS pro zpětný překlad PTR záznamů. Kvůli výkonu je potřeba nastavit Cache s dostatečnou velikostí. Pro DNS bylo nastavena velikost na 10 tisíc položek s expirací 30 minut - při nasazení se pak velikost pohybuje kolem 7500 položek s hit-ratem 93%.

Vytváření email alertů

  • Každý uživatel by měl mít vyplnění email. Vytvoření je pak v Alerts -> Evend Definitions -> Create Event Definition. Údaje pro událost, která notifikuje o špatném přihlašování:
Condition Type: Filter & Aggregation
Search Query: type: (AUTHC-FAILNOUSER OR AUTHCFAIL)
Streams (Optional): tacacs
Search within the last: 10 min
Execute search every: 1 min
Create Events for Definition if: Aggregation of results reaches a threshold
Condition: count(NAC) > 10 # lze stáhnout na jakoukoli položku v logu,
                             jde nám pouze o počet logů co se pokouší o přihlášení
Grace Period: 10 min # omezí čas k zaslání další notifikace
Message Backlog: 100 # vloží do emailu obsah 100 logů
  • K definice události se musí zavěsit notifikace, která lze doplnit o výpis backlog zpráv (v tomhle případě seznam jmen co se zkouší přihlašovat a kam):
--- [Backlog] ------------------------------------
Last messages accounting for this alert:
${foreach backlog message}
${message.fields.NAC_PTR}(${message.fields.NAC}) "${message.fields.user}" 
-> ${message.fields.NAS_PTR}(${message.fields.NAS})
${end}

Informace k Inputům

  • V System -> Inputs se definují inputy. Všude používáme typ "Syslog UDP". Ke každému inputu se přidává statická položka (static field) input:nazev kvůli pozdějšímu zpracování příslušným streamem. Inputy mají extraktory, které zavisejí na pořadí (Manage extractors -> Sort extractors). Vytvářením extractorů lze nastavovat pomocné položky, které ale nejsou potřeba v konečném vyhledávání a zpracovávání - tyto položky můžeme skrýt v System -> Pipelines:
rule "tacacs hiding"
when
   has_field("tac_meta") AND
   has_field("tac_msg")
then
   remove_field("tac_meta");
   remove_field("tac_msg");
end
  • Obsah extractorů lze nalézt na Graylog Marketplacu: https://marketplace.graylog.org/addons?tag=Extractor. Nicméně jsou to jen takové záchytné body a celý marketplace se potýka s problémý s kompatibilitou - extraktory někdo definoval pro archaické verze Graylogu apod. často je nutné extraktory přiohnout nebo upravit ke svým potřebám.
  • Nejvýhodnější pro extrakci jsou regulární výrazy viz následující příklad s extrakcí názvu rozhraní:
((Fa|Gi|Tw|Fi|Te|Twe|Fo|Hu|Eth|Ethernet)(|.*Ethernet|.*E)\d+\/\d+\/*\d*)


Informace ke Streamům

  • Streamy propojují inputy ke zpracování a k ukládání. V našem případě jsou streamy mapovány 1:1 na inputy a to je provedeno definovanými pravidly pro konkrétní stream - podle statické položky (input="tacacs"), zprávy jsou pak směrovány do konkrétního streamu. Nechceme-li zprávy ve streamu All messages (výchozí stream) zaškrtneme položku "Remove matches from ‘All messages’".

Indexové sady

  • Při definici streamů jsou vybrány indexy (místa na disku) do kterých se zapisuje dle různých časových nebo velikostních pravidel. Indexové sady jsou definovány v System -> Indices -> Create index set. Ve výchozím nastavení ukládá Graylog vše do "Default index set", který se dá upravit co se týče retence a množství. Pro různé streamy lze vytvořit jiné sady např. pro kolejní logy byla vytvořena indexová sada "koleje" jako 24 indexů pro 24 měsíců. Po vybrání sady jsou zobrazeny jednotlivé indexy s ukazatelem na aktivní - write index. Zde lze indexy manuálně mazat a na rychlosti zaplňování pak lze určovat parametry pro sady do budoucna vzhledem k místu na disku a časové politice pro uchovávání dat.

Pipeliny

  • Pipeliny jsou většinou místo, kde se pomocí pravidel a řetězového zpracování řeší složitější operace nad přijmutými logy v rámci streamů např. přepočet jednotek, aritmetické operace a logické operace. Sytaxe jazyku je "Java-like", ale možnosti jsou hlavně kvůli výkonu dost omezené. Všechna pravidla jsou ve tvaru:
rule "název"
when
    // podmínka
then
    // činnost
end
  • Aby Pipeliny fungovaly je třeba zajistit v System -> Configurations -> Message Processors Configuration -> Pipeline Processor (musí být poslední v pořadí)
  • Nelze používat další podmínky uvnitř hlavní podmínky a stejně tak nelze používat cykly. To je z důvodů extrémní paralelizace s kterou se Pipeliny provádí - jde o výkon. Zřetězení uvnitř pipeline je uřčeno jednotlivými fázemi zpracování, pokud zpráva vyhovuje podmínce when může se po provedení činnosti ocitnou v další fázi a aplikuje se další pravidlo.
  • Pokud chceme jednoduše prostě aplikovat např. tři různá pravidla na všechny zprávy ze streamu je nutné je nutné tyto pravidla umístit hned do první fáze (Stage 0). Dále je výpis pravidla pro rozdělení jedné položky na dvě nové podle '@':
rule "wlc existing realm"
when
  has_field("user") && to_string($message.user) != "unknown"
  && contains(to_string($message.user), "@", false)
then
  let m = split("@", to_string($message.user));
  set_field("realm", to_string(m[1]));
  set_field("user", to_string(m[0]));
end