Systém Mentat byl navržen jako distribuovaný systém s důrazem na co možná nejjednodušší rozšiřitelnost a škálovatelnost. Při návrhu jsme se inspirovali architekturou MTA systému Postfix. Celý systém se skládá z mnoha jednoduchých jednoúčelových modulů - daemonů, které provádějí vždy jeden jednoduchý úkon. Tento přístup umožňuje velmi jednoduchou paralelizovatelnost. Všechny moduly interně používají jednotnou kostru a framework, což znamená, že je velmi jednoduché přidávat další a rozšiřovat tak funkčnost celého systému.

V první fázi návrhu a vývoje se počítalo, že systém Mentat bude obsahovat i vlastnosti a nástroje pro sběr a výměnu bezpečnostních informací. Tuto funkci však později převzal sesterský projekt Warden, jehož ambice byly trochu skromnější, návrh jednodušší a ve výsledku se ukázalo, že k tomuto účelu i lepší. V tuto chvíli se tedy systém Warden profiluje jako jednotný komunikační kanál pro sdílení bezpečnostních informací a systém Mentat jako nástroj pro jednotné zpracování bezpečnostních informací.

Následujíci obrázek popisuje aktuální stav architektury systému Mentat.

Implementačním jazykem je striktně Python3 bez jakýchkoliv pokusů o kompatibilitu se stárnoucím Pythonem verze 2. Systém používá PostgreSQL databázi jak perzistentní úložiště událostí. Systém používá IDEA jako datový model pro popis událostí, který je postavený na JSON a který byl speciálně navržen pro popis a ukládání zpráv popisujících široké spektrum bezpečnsotních událostí a myšlenkou možného budoucího rozšiřování.

Systém Mentat se skládá z nástrojů umožnujících zpracování zpráv jak v reálném čase, tak zpětně za určité časové období. V tuto chvíli jsou k dispozici následující nějdůležitější moduly pro zpracování v zpráv v reálném čase:

• mentat-inspector.py
  Tento modul umožňuje zpracování IDEA zpráv na základě výsledku dané filtrační podmínky. K dispozici je řada akcí, které lze podniknout v případě, že podmínka bude vyhodnocena jako pravdivá. Nejčastějšími a nejužitečnějšími případy užití tohoto modulu jsou klasifikace a verifikace zpráv, filtrace nebo podmíněné zpracování. (více informací)
• mentat-enricher.py
  Tento modul umožňuje obohacování příchozích IDEA zpráv o další informace, jako je např. získání cílového abuse kontaktu (pro účely reportování), IP geolokace and získání cílového čísla ASN. Implementace dalších obohacovacích submodulů je plánována (hostname/ip resolving, passive DNS, …) a systém je připraven na vytvoření a použití vlastních obohacovacích pluginů. (více informací)
• mentat-storage.py
  Tento modul umožňuje uložení příchozích IDEA zpráv do databáze (PostgreSQL). (více informací)

Většina modulů umožňujících zpětné zpracování zpráv je založená na pravidelně spouštěných skriptech (tzv. cronech). V tuto chvíli jsou k dispozici následující moduly umožňující zpětné zpracování za určitý časový interval:

• mentat-statistician.py
  Tento modul umožňuje statistická zpracování událostí obdržené za definovaný časový interval. V tuto chvíli je nakonfigurován na 5 minutový iterval, za který získá počty událostí podle typu detektory, typu události, klasifikace události, IP adres atd. Tyto statistické reporty jsou ukládány do separátní databáze a pak dále slouží pro rychlé generování souhrnných statistických výpisů za daná časová období. (více informací)
• mentat-reporter.py
  Tento modul umožňuje distribuovat periodické agregované reporty přímo správcům v příslušných koncových sítích. Více informací o reportéru jakožto službě poskytované sdružením CESNET, a.l.e lze nalézt na oficiální stránce služby Mentat. (více informací)
• mentat-informant.py
  Tento modul je kombinací výše popsaného statisticianu a reportéru. Jeho úkolem je posílat pravidelné statistické souhrny o provozu systému a zpracování zpráv. Je určen zejména správcům systému Mentat, ale užitečný může být i pro správce v koncových sítích, kterým poskytne např. měsíční statistické souhrny. (více informací)

Poněkud stranou je poměrně velká kolekce nástrojů a skriptů pro správu, jejichž úkolem je zjednodušení jednotvárných a opakujících se administrativních úkonů. Některé z nejužitečnějších jsou následující:

• mentat-controller.py
  Skript umožňující ovládání nakonfigurované sady démonů/modulů na daném serveru. (více informací)
• mentat-backup.py
  Konfigurovatelný modul umožňující periodické zálohování databáze. V tuto chvíli se pravidelně provádí plná záloha všech systémových tabulek (uživatelé, skupiny …) každý den, zatímco záhoha tabulky IDEA zpráv se z důvodů obrovského množství dat dělá pouze inkrementálně. (více informací)
• mentat-cleanup.py
  Konfiguraovatelný modul umožňující periodické číštění/výmaz databáze a souborů na filesystému. (více informací)

Konečně poslední důležitou kmponentou systému je webové uživatelské rozhraní:

• Hawat
  Konfigurovatelné a jednoduše rozšiřitelné webové uživatelské rozhraní založené na mikroframeworku Flask. (více informací)

Jak již bylo zmíněno výše, všechny systémové moduly včetně neustále běžících démonů i pravidelně spouštěných skriptů používají společný framework nazvaný PyZenKit, který zajišťuje všechny společné vlastnosti:

• Životní cyklus aplikace.
• Načítání, slučování a validace konfigurace.
• Démonizace.
• Nastavení logování.
• Databázová abstrakční vrstva.
• Abstrakční vrstva pro práci s IDEA zprávami.
• Statistické zpracování dat.
• WHOIS dotazy, IP geolokace.

Všechny stále běžící moduly fungují na principu *trubky*, kdy zpráva na jedné straně do modulu vstoupí, ten provede relevantní zpracování a zpráva na druhém konci opět vystoupí. K jednoduché výměně zpráv mezi jednotlivými moduly slouží podobně jako v MTA Postfix fronty založené na souborech a adresářích na filesystému.

Interně používají všechny daemon moduly design založený na zpracování událostí. V každém démonu existuje interní nekonečná smyčka a fronta událostí. Události jsou emitovány v různých komponentách daného démona a řazeny do fronty událostí. Interní plánovač pak vybírá ve správném pořadí události z fronty a volá příslušný řetězec zpracovacích metod.

Za účelem zvýšení znovupoužitelnosti kódu se každý démon skládá z jedné nebo více *komponent*, ve kterých se teprve skutečně ukrývá aplikační logika a obalující démon slouží v podstatě pouze jako kontejner. V tuto chvíli již existují komponenty zajišťující nejruznější dílčí úkony jako načtení zprávy ze souboru, parsování zprávy do objektu, filtrování zprávy dle definovancýh pravidel atd. Tyto komponenty mohou být následně řazeny za sebe a jejich správnou kombinací je pak dosaženo požadovaného výsledného efektu.

Následující obrázek popisuje interní architekturu démon modulů s důrazem na znázornění zpracování vnitřních událostí a komponent:

V případě implementace nového démon modulu je tedy většinou nutné navrhnout a implementovat komponentu pro dané vlastní zpracování; vše ostatní je již zajištěno automaticky včetně načítání zpráv z fronty na disku a jejich následného vložení do fronty následujícímu démonu v řetězu.

Pro umožnění výměny zpráv mezi jednotlivými démon moduly byl navržen a implementován protokol pro výměnu zpráv založený na filesystému (aka. *filer protocol*). Inspirací byl opět již zmiňovaný Postfix MTA.

Protokol používá pro výměnu zpráv označené adresáře na filesystému s definovanou nasledující strukturou se speciálním významem:

• incoming: vstupní fronta, pouze úplné zprávy
• pending: pracovní adresář modulu, *uzamčené zprávy* v průběhu zpracování
• tmp: pracovní adresář pro ostatní procesy
• errors: zprávy, které způsobily problém při zpracování

Klíčovým požadavkem pro správnou funkci protokolu je atomická operace přesunu na úrovni filesystému. Tento požadavek je na Linuxových systémech uspokojen v případě, že zdrojový a cílový adresář se nacházejí na stejné partition. Z toho vyplývá požadavek nikdy nedávat podadresáře fronty na různé oddíly disku. Následující procedura popisuje bezpečné vložení nové zprávy do fronty démona ke zpracování:

1. vytvořit nový soubor v podadresáři tmp a vepsat/uložit jeho obsah
2. název souboru může být libovolný, ale rozumný z hlediska použitých znaků a unikátní v rámci celé fronty
3. přesunout/přejmenovat soubor do podadresáře incoming
4. operace přesunu musí být atomická, takže všechny podadresáře fronty musí být na stejné partition

Následující obrázek popisuje zmiňovaný proces vložení nové zprávy do fronty démonu:

Modré šipky jsou filesystémové operace prováděné externím procesem, který vkládá novou zprávu do fronty. Dle výše popsané prcedury je zpráva nejprve vložena do podadresáře tmp a poté atomicky přesunuta do incoming. Červené šipky jsou filesystémové operace prováděné samotným démonem. Atomickým přesunutím zprávy z incoming do pending dojde k jejímu označení jakožto *in progress* a démon může zahájit zpracování. Když je hotov, zpráva je přesunuta do fronty následujícího dému v řadě, přesunuta do errors v případe nějaké chyby při zpracování nebo zcela smazána (v případě, že démon je posledním ve zpracovacím řetězu).

Operace atomického přesunu z incoming do pending má i další účel a tím je zamykání. Ve chvíli, kdy více instancí démonu pracuje nad stejnou frontou atomicita přesunu zajišťuje, že každá zpráva je a bude zpracována právě jednou. Všechny démony jsou na tuto eventualitu připraveny a umí se vyrovnat s tím, že se nějaká zpráva nepodaří přesunout nebo záhadně zmizí z fronty.

Webového rozhraní systému Mentat má jméno Hawat a je postaveno na vynikajícím microframeworku Flask microframework. Slovo *micro* v názvu frameworku však znamená, že ro zjednodušení imlementace některých opakujících se dílších celků jsou k dispozici ještě vlastní nástroje odvozené od nástrojů samotného Flasku, které umožňují i lepší vzájemnou provázanost jednotlivých komponent v rámci celého rohraní.

Flask již v základní instalaci poskytuje nástroj pro rozdělení velkých aplikací do menších logických celků v rámci svého mechanismu tzv. blueprintů. Tato vlastnost je velmi využívána, pouze velmi malá část kódu rozhraní je neměnná a zbytek jsou zásuvné blueprinty/submoduly.