Warden 1.0¶

• Table of contents
• Warden 1.0
  • Funkce
  • Uživatelé
  • Provozní prostředí
  • Designová a implementační omezení
  • Uživatelská dokumentace
  • Funkcionalita
    • Registrace klienta na serveru
    • Rušení registrace klienta na serveru
    • Výpis registrovaných klientů
    • Odeslání (uložení) nové události na server
    • Získání nových událostí zaslaných na server
    • Výpis stavu serveru
  • Rozhraní
    • Komunikační rozhraní klient/server
    • Softwarové rozhraní klientských modulů
  • Nefunkční požadavky
    • Požadavky na výkon
    • Požadavky na bezpečnost
  • Ostatní požadavky
  • Slovník pojmů
    • Událost
  • Připomínky

Prototyp centralizovaného systému, který jednoduše a efektivně umožní organizacím sdílet a využívat informace o detekovaných anomáliích v provozu sítě a služeb.

Systém se skládá ze serveru a přijímajících a odesílajících klientů. Na žádost přijímajících klientů jim server distribuuje nové (dosud nezaslané) události, které serveru zaslali odesílající klienti.

Schéma: Komponenty systému Warden (Suki, update 2011-10-20)

Funkce¶

• Správa klientů - registrace a rušení registrace odesílajících a přijímajících klientů na serveru, výpis registrovaných klientů
• Odeslání (uložení) nové události na server pro další distribuci
• Získání nových událostí zaslaných na server
• Výpis stavu serveru

Uživatelé¶

• Zapojená organizace odesílající události - prostřednictvím jednoho či více klientů poskytuje události centru
• Zapojená organizace přijímající události - prostřednictvím jednoho či více klientů dostává na žádost nové události od centra
• Správce systému - registruje a ruší registrace klientů, sleduje stav systému

Provozní prostředí¶

Server i klienti poběží na stroji připojeném k internetu s veřejnou IP adresou z rozsahu přiděleného zapojené organizaci/provozovatelem serveru. Operačním systém serveru bude Debian, klienti poběží na OS typu GNU/Linux (nejčastěji z rodiny Debian či Red Hat). Log běhu serveru bude ukládán prostřednictvím Syslogu. Klienti budou spolupracovat s automatizovanými systémy detekce a prevence průniků a anomálií, ale i s ticketovacími systémy typu OTRS či RT. Předpokládáme, že server bude dohlížen systémem Nagios. Pro usnadnění zapojení do monitoringu bude připraven dohlížecí skript či popis nastavení.

Designová a implementační omezení¶

Komunikace mezi klientem a serverem bude probíhat výhradně pomocí protokolu z rodiny TCP/IP. Server poběží jako démon poslouchající na portu TCP/443 (předpokládáme, že tento síťový port není v sítích obecně blokován).

Vzhledem k omezenému rozpočtu využijeme:

• volně dostupné (ideálně i open-source) komponenty,
• pro implementaci skriptovací jazyk Perl a rozšiřující moduly,
• jednotného DB rozhraní Perl DBI pro přístup k relační databázi,
• SQLite3 jako relační databázi, která je v případě vyšších nároků na funkcionalitu i výkon nahraditelná PostreSQL.

Z hlediska výkonu musí server stabilně běžet na běžném serveru v cenové relaci do 100 000 Kč vč. DPH, klienti na běžném desktopu.

Po ukončení implementace prototypu a jeho nasazení musí systém běžet pouze s minimálními zásahy vývojářů.

Výsledný systém bude šířen pod BSD licencí, příp. použité zdrojové kódy třetích stran musí být šířeny pod BSD-kompatibilní licencí (tedy ne zejména pouze pod GPL).

Uživatelská dokumentace¶

README a CHANGELOG (prostý text) v distribučním balíčku serveru a klientů (anglicky).

Funkcionalita¶

Registrace klienta na serveru¶

Registraci klienta provádí provozovatel systému Wardenu na žádost CSIRT/abuse týmu zapojené organizace. Žádost bude provozovateli systému zaslána jiným kanálem (TODO provozovatel: jak? podepsaným mailem?). Při registraci přijímajícího klienta je možno uvést typ událostí, které má klient od serveru výhradně přijímat (takovému klientovi bude pak centrum zasílat událostí pouze tohoto typu). Implicitně bude centrum poskytovat klientům přijaté události všech typů. Lze nastavit potlačení příjmu událostí generovaných zdrojem ze stejné sítě (tzv. vlastních událostí).

1. Provozovatel zavolá vzdálenou proceduru serveru sloužící pro registraci nového odesílajícího nebo přijímajícího klienta.
   • V případě registrace odesílajícího klienta je povinným údajem název stroje (doménové jméno), na kterém klient běží, název služby (identifikátor takového stroje), štítky popisující typ služby (příklad v Typy_udalosti - Podle třídy/typu zdroje) a IP adresní rozsah, ze kterého bude přistupovat k serveru.
   • V případě registrace přijímajícího klienta je povinným údajem název stroje (doménové jméno), na kterém klient běží, a IP adresní rozsah, ze kterého bude přistupovat k serveru; volitelným údajem typ požadovaných událostí, které bude klient od serveru výhradně dostávat a nastavení příjmu tzv. vlastních událostí (viz výše).
2. Server zkontroluje, zda je procedura volána ze stroje, který je k tomu autorizován (např. localhost).
3. Server si uloží předané detaily o klientu a vrátí informaci, zda byla registrace úspěšná.

Rušení registrace klienta na serveru¶

Rušení registrace klienta provádí provozovatel systému Wardenu, typicky na žádost CSIRT/abuse týmu zapojené organizace. Žádost bude provozovateli systému zaslána jiným kanálem (TODO provozovatel: jak? podepsaným mailem?).

1. Provozovatel zavolá vzdálenou proceduru serveru sloužící pro zrušení registrace stávajícího klienta.
2. Server zkontroluje, zda je procedura volána ze stroje, který je k tomu autorizován (např. localhost).
3. Server zruší registraci a vrátí informaci, zda bylo zrušení registrace úspěšné.

(Provozovatel systému může zrušit registraci klienta i "sám od sebe" v případě porušení pravidel pro zapojené klienty.)

Výpis registrovaných klientů¶

Provozovateli systému je umožněno vypsat seznam registrovaných klientů včetně detailů.

1. Provozovatel zavolá vzdálenou proceduru serveru sloužící pro výpis registrovaných klientů.
2. Server zkontroluje, zda je procedura volána ze stroje, který je k tomu autorizován (např. localhost).
3. Server vrátí seznam registrovaných klientů včetně detailů, příp. chybové hlášení v případě neúspěchu.

Odeslání (uložení) nové události na server¶

Zapojená organizace zasílá serveru jednu událost prostřednictvím předem registrovaných odesílajících klientů, kteří reprezentují (různé) datové zdroje uvnitř organizace.

1. Klient zavolá vzdálenou proceduru serveru sloužící pro uložení nové události.
2. Server zkontroluje, zda je klient registrován a zda se autentizoval (viz požadavky na bezpečnost).
3. Server přijme a uloží událost. Dále vygeneruje pro každou novou událost její číselný identifikátor a uloží informaci o odesílateli události. Zapíše informaci o prováděné akci prostřednictvím Syslogu.
4. Server klientovi odpoví, zda událost přijal či nikoliv.

Množství uložených událostí v centru se odvíjí od kapacity databázového úložiště centra. Zejména tedy není zaručena žádná minimální doba, po kterou budou zaslané události uchovávány v centru.

Získání nových událostí zaslaných na server¶

Server poskytuje zapojeným organizacím přijaté události včetně identifikátoru události, zdroje a doménového jména stroje, ze kterého byla událost přijata na žádost prostřednictvím dříve registrovaného přijímajícího klienta.

1. Klient zavolá vzdálenou proceduru serveru sloužící pro příjem událostí uložených na serveru.
2. Server zkontroluje, zda je klient registrován a zda se autentizoval (viz požadavky na bezpečnost).
3. Server vyhledá všechny události, které má klient dostat na základě předchozí registrace. Jedná-li se o nového klienta, začíná odběrem následující události uložené (přijaté) serverem.
4. Server pošle klientovi dosud nezaslané události (jednu nebo více), příp. informaci, že na serveru není žádná nová (dosud nepředaná) událost.

Výpis stavu serveru¶

Výpis informací o stavu serveru systému je umožněn pouze provozovateli systému Wardenu.

1. Provozovatel zavolá vzdálenou proceduru serveru sloužící pro výpis stavu serveru.
2. Server zkontroluje, zda je procedura volána ze stroje, který je k tomu autorizován (např. localhost).
3. Server vrátí následující stavové informace, příp. chybové hlášení v případě neúspěchu: velikost databaze, pocet udalostí na serveru, identifikátor poslední uložené události, časovou známku poslední uložené události, počet událostí uložených jednotlivými klienty, počet zaregistrovaných přijímajících a odesílacích klientů

Rozhraní¶

Komunikační rozhraní klient/server¶

Komunikačním protokolem mezi klienty a serverem byl na základě prvotního průzkumu zvolen SOAP (viz srovnání Xml-rpc_vs_soap, ukázka IDMEF).

Softwarové rozhraní klientských modulů¶

Jelikož IDS a jiné systémy nasazené v zapojených organizacích obvykle nepodporují SOAP a události ukládají v proprietárních formátech, formátu Syslog či IDMEF (RFC 4765), pro usnadnění zapojení do systému Warden budou připraveny moduly jazyka Perl, které budou obalovat volání vzdálených procedur SOAP a ukázkové klientské aplikace využívající tento modul.

Nefunkční požadavky¶

Požadavky na výkon¶

Server by měl být schopen zpracovat a distribuovat alespoň 100 událostí za sekundu. TODO Kuba: zátěžový test

Požadavky na bezpečnost¶

Volání vzdálených procedur a předávání výstupů je zabezpečeno pomocí SSL. Server má platný certifikát, který klient ověřuje při každém volání. Server ověřuje identitu klienta za základě klientského certifikátu. Každá zapojená organizace a její zdroje dat jsou identifikovány certifikátem stroje, na kterém běží klient (např. nfsen.ics.muni.cz) a adresním IPv4 rozsahem, který bude použit jako dodatečný prvek autentizace (server bude přijímat pouze události zaslané z adresního rozsahu, který byl zadán při registraci klienta; obdobně pak v případě rozesílání událostí přijímajícím klientům).

Server tedy při každém volání vzdálené procedury přes SOAP :

1. ověří platnost SSL certifikátu klienta (zda je platný a podepsán důvěryhodnou certifikační autoritou),
2. zkontroluje, zda je klient zaregistrován,
3. ověří, zda klient přistupuje z adresního rozsahu zadaného při registraci klienta.

Ostatní požadavky¶

• Veškeré údaje o času budou předávány mezi klienty a serverem ve formátu ISO 8601
• Předpokladem pro správnou funkci celého systému je synchronizovaný čas strojů, na kterých Warden běží (klientů i centrálního serveru)
• Kompatibilita s evropskou legislativou, viz Incidenty_a_ochrana_dat
• Systém bude šířen pod licencí BSD
• Lokalizace: zdrojové kódy (vč. komentářů), API a příp. komunikace s uživatelem bude anglicky; README a CHANGELOG v distribučním balíčku serveru i klienta taktéž.

Slovník pojmů¶

Událost¶

Událostí se rozumí bezestavová informace o zdroji útoku/hrozby obsahující následující položky:

• číselný identifikátor události generovaný serverem
• doménové jméno stroje zasílající událost serveru
• název systému/služby produkující událost
• časová známka vzniku (= detekce) události v GMT/UTC
• časová známka přijetí události serverem v GMT/UTC
• typ nahlášené události (útoku/hrozby)- viz seznam typů
• typ adresy zdroje útoku/hrozby
• adresa zdroje útoku/hrozby
• protokol cíle útoku/hrozby
• číslo portu cíle útoku/hrozby
• (mohutnost útoku)
• (poznámka/nestrukturovaný text)
• (priorita)
• (timeout - navrhovaná délka reakce udávaná v minutách, např. blokování)

Volitelné položky jsou uvedeny v závorce.

Připomínky¶

Sem pište vaše postřehy. Díky, Honza

RO:
Registrace a ruseni klienta na serveru:
- kdo smi zasilat danou zadost? Bude seznam poverenych osob za jednotlive organizace? HV: procesni zalezitost, zatim neni treba resit, pozdeji vyresi CESNET
- ve specifikaci neni reseni uprava/zmena/modifikace klienta HV: upravu/zmenu/modifikaci resime pomoci zruseni a opetovnou registraci klienta

Ruseni klienta:
- jak presne dojde ke zruseni klienta? Zrusenim zaznamu v databazi nebo priznakem? Co se stane s ulozenymi udalostmi, ktere byly na server nahrany pres ruseneho klienta. HV: viz poznamka ve schuzkach

Vypis registrovanych klientu:
- je planovano mit soucasti vypisu i cas posledni nahlasene udalosti? Podle me uzitecny udaj v teto funkci. Vsiml jsem si vypsani tohoto udaje az ve vypisu stavu serveru (časovou známku poslední uložené události). Bude-li vsak nekdo chtit projet seznam registrovanych klientu a ocima zkontrolovat ty "nefunkcni", pak se to muze hodit. HV: dobra pripominka, zatim ale bude mit k vypisu pristup jen provozovatel

Odeslani (ulozeni) nove udalosti na server:
- soucasti specifikace neni krok, ktery by zajistil autorizaci (viz registrace klientu - volitelným údajem typ požadovaných událostí, které bude klient od serveru výhradně dostávat a nastavení příjmu tzv. vlastních událostí (viz výše).)volitelným údajem typ požadovaných událostí, které bude klient od serveru výhradně dostávat a nastavení příjmu tzv. vlastních událostí (viz výše). HV: ???
- Kdo/co/jak bude informovan o neuspechu autentizace/autorizace (kontaktni osoba za klienta)? (viz. Server zkontroluje, zda je klient registrován a zda se autentizoval (viz požadavky na bezpečnost).) HV: server zapise do Syslogu, ze se autentizace/autorizace nezdarila, klientovi se vrati chybova hlaska
- Co klient udela s neprijatou udalosti? (Server klientovi odpoví, zda událost přijal či nikoliv.) HV: zalezi na autorech klienta
- Pres to by mel byt stanoven plan toho, co se bude dit v pripade potreby ruseni/archivace udalosti z duvodu kapacity uloziste ci stari dat. (Množství uložených událostí v centru se odvíjí od kapacity databázového úložiště centra. Zejména tedy není zaručena žádná minimální doba, po kterou budou zaslané události uchovávány v centru.) HV: neni treba resit ted, domluvime se osobne

Ziskani novych udalosti na server:
- soucasti specifikace neni krok, ktery by zajistil autorizaci. - HV: je to tam, dostacuje popis?
- Kdo/co/jak bude informovan o neuspechu autentizace/autorizace (kontaktni osoba za klienta)? (viz. Server zkontroluje, zda je klient registrován a zda se autentizoval (viz požadavky na bezpečnost).) HV: server zapise do Syslogu, ze se autentizace/autorizace nezdarila, klientovi se vrati chybova hlaska

Kuba

• Ve specifikaci jsem nenasel, jak ma vypadat tabulka klientu. HV: implementacni detail, objevi se v navrhovem dokumentu
• Pri vypisu stavu serveru by bylo dobre vracet i timestamp prvni udalosti, at vime od kdy jsou data dostupna. HV: pridame
• Pripopisu udalosti je zminen timeout v minutach. Dle meho by by byly lepsi sec. pro lepsi pocitani s unix. casem. HV: jiz drive jsme se dohodli na minutach

ph Jak tedy řešíme nadbytek údajů pro phishing?
HV: problematika phishingu je komplexni, zatim se k tomu postavime tak, ze v pripade potreby vygenerujeme pro phishing vic nez jednu warden udalost