Testování Warden serveru a klientů¶
- Table of contents
- Testování Warden serveru a klientů
1 Systémové a akceptační testy¶
1.1 Server¶
- Test dokumentace - Dokumentace musí být pochopitelná a musí dobře popisovat jednotlivé funkce serveru.
- Test cmd rozhraní Warden serveru - Rozhraní musí být uživatelsky použitelné. Musí korektně volat všechny SOAP funkce. Nesmí obsahovat chybu v přepínačích.
- Registrace vysílajícího klienta
- Test autorizace
- Uživatel nesmí zaregistrovat klienta, pokud k tomu není oprávněn.
- Uživatel musí zaregistrovat klienta, pokud k tomu je oprávněn.
- Test správnosti dat. Data v DB v tabulce klientů musí odpovídat datům zadaným uživatelem.
- Test autorizace
- Registrace přijímajícího klienta
- Test autorizace
- Uživatel nesmí zaregistrovat klienta, pokud k tomu není oprávněn.
- Uživatel musí zaregistrovat klienta, pokud k tomu je oprávněn.
- Test správnosti dat. Data v DB v tabulce klientů musí odpovídat datům zadaným uživatelem.
- Test autorizace
- Odebrání klienta
- Test autorizace
- Uživatel nesmí odebrat klienta, pokud k tomu není oprávněn.
- Uživatel musí odebrat klienta, pokud k tomu je oprávněn.
- Test dat - v případě odebrání klienta musí být všechna jeho data označena jako nepřístupná.
- Test autorizace
- Výpis stavu serveru
- Test autorizace
- Uživatel nesmí vypsat stav serveru, pokud k tomu není oprávněn.
- Uživatel musí vypsat stav serveru, pokud k tomu je oprávněn.
- Test správnosti dat. Data v DB musí odpovídat vypsaným datům
- Test autorizace
- Výpis klientů
- Test autorizace
- Uživatel nesmí vypsat klienty, pokud k tomu není oprávněn.
- Uživatel musí vypsat klienty, pokud k tomu je oprávněn.
- Test správnosti dat - data v DB musí odpovídat vypsaným datům.
- Test autorizace
| Test # | Popis testu | Proběhl korektně? Ano/Ne | Poznámky |
|---|---|---|---|
| 1 | Pročtení dokumentace k serveru | - | Dokumentace dosud nebyla vytvořena. |
| 2 | Test cmd rozhraní Warden serveru | Ano. | Vše proběhlo korektně. Jen by bylo vhodné při spuštnění skriptu bez parametrů vypsat nápovědu. |
| 3.1.1 | Snaha zaregistrovat klienta bez oprávnění k práci se serverem | Ano. | Klienta se nepodařilo zaregistrovat. |
| 3.1.2 | Registrace klienta oprávněným uživatelem | Ano. | |
| 3.2 | Kontrola zda data v DB odpovídají zadaným datům při registraci | Ano. | |
| 4.1.1 | Registrace klienta bez oprávnění k práci se serverem | Ano. | Klienta se nepodařilo zaregistrovat. |
| 4.1.2 | Registrace klienta oprávněným uživatelem | Ano. | |
| 4.2 | Kontrola zda data v DB odpovídají zadaným datům při registraci | Ano. | |
| 5.1.1 | Smazání klienta bez oprávnění k práci se serverem | Ano. | Klienta se nepodařilo smazat. |
| 5.1.2 | Smazání klienta oprávněným uživatelem | Ano. | Smazání proběhlo korektně. Data patřící mazanému klientovi byla zneplatněna. |
| 5.2 | Kontrola zda data v DB odpovídají zadaným datům při registraci | Ano. |
1.2 Vysílající klient¶
- Test dokumentace. Dokumentace musí být pochopitelná a musí dobře popisovat jednotlivé funkce serveru.
- Interní test použitelnosti. Uživatel musí být schopen dle dokumentace a pokynů přiložených u knihovny úspěšně zapojit svůj nástroj do systému Warden jako vysílajícího klienta. Výstupem bude soupis doporučení k úpravě knihovny.
- Externí test použitelnosti. Uživatel nezapojený do vývoje systému musí být schopen dle dokumentace a pokynů přiložených u knihovny úspěšně zapojit svůj nástroj do systému Warden jako vysílajícího klienta. Výstupem bude vyplněný dotazník.
- Odeslání události
- Test autentizace
- Klient se musí přihlásit, pokud má správný certifikát a ostatní identifikační údaje.
- Klient se nesmí přihlásit, pokud má špatný certifikát nebo ostatní identifikační údaje.
- Test přenosu. Data odeslaná klientem musí být stejná v databázi i na straně klienta.
- Test potvrzení. Server musí klienta správně informovat o přijetí/nepřijetí dat.
- Test autentizace
| Test # | Popis testu | Proběhl korektně? Ano/Ne | Poznámky |
|---|---|---|---|
| 1 | Test dokumentace | Ano. | Dokumentace je v pořádku. |
| 2 | Test instalace | Ano. | Instalace probělha bez problémů. |
| 3 | Test použitelnosti | Ano. | Uživatelské dotazníky jsou využity při tvorbě FAQ. |
| 4.1.1 | Test autentizace - nezaregistrován | Ano. | Data nejsou v DB serveru. Bohužel klient o tom nemá žádnou informaci. |
| 4.1.2 | Test autentizace - zaregistrován | Ano. | |
| 4.2 | Test přenosu dat | Ano. | |
| 4.3 | Test potvrzení | - | Nepodařilo se dohledat jakým způsobem server vrací informaci. |
1.3 Přijímající klient¶
- Test dokumentace. Dokumentace musí být pochopitelná a musí dobře popisovat jednotlivé funkce serveru.
- Interní test použitelnosti. Uživatel musí být schopen dle dokumentace a pokynů přiložených u knihovny úspěšně zapojit svůj nástroj do systému Warden jako přijímajícího klienta. Výstupem bude soupis doporučení k úpravě knihovny.
- Externí test použitelnosti. Uživatel nezapojený do vývoje systému musí být schopen dle dokumentace a pokynů přiložených u knihovny úspěšně zapojit svůj nástroj do systému Warden jako přijímajícího klienta. Výstupem bude vyplněný dotazník.
- Stáhnutí události
- Test autentizace
- Klient se musí přihlásit, pokud má správný certifikát a ostatní identifikační údaje.
- Klient se nesmí přihlásit, pokud má špatný certifikát nebo ostatní identifikační údaje.
- Test přenosu - Data přijatá klientem musí být stejná v databázi i na straně klienta.
- Test událostí
- Klient musí obdržet pouze data zaregistrované události
- Klient nesmí obdržet žádná data z nezaregistrované události
- Test vlastnictví
- Klient musí obdržet pouze cizí události, pokud má nastaven příjem pouze cizích událostí.
- Klient musí obdržet cizí i vlastní události, pokud má nastaven příjem všech událostí.
- Test autentizace
| Test # | Popis testu | Proběhl korektně? Ano/Ne | Poznámky |
|---|---|---|---|
| 1 | Test dokumentace | Ano. | Dokumentace je v pořádku. |
| 2 | Test instalace | Ano. | Klienta se podařilo rychle a správně nainstalovat. |
| 3 | Test použitelnosti | Ano. | Uživatelské dotazníky jsou využity při tvorbě FAQ. |
| 4.1.1 | Test autentizace - nezaregistrován | Ano. | Server nedovolí příjmat události. |
| 4.1.2 | Test autentizace - zaregistrován | Ano. | Události přijaty. |
| 4.2 | Test přenosu dat | Ano. | Data odpovídají. |
| 4.3.1 | Test zaregistrované události | Ano. | |
| 4.3.2 | Test neregistrované události | Ano. | Nebyly obdrženy žádné neregistrované události. |
| 4.4.1 | Test cizích událostí | Ano. | |
| 4.4.2 | Test vlastních událostí | Ne. | Odhalen bug #314 |
2 Výkonové testy¶
2.1 Proběhlé výkonové testy¶
| Test č. | Počet klientů na stroji | Počet strojů | Počet událostí/klient | Doba běhu | Využití swap | RAM po dobu běhu testu | CPU po dobu běhu testu | Doba běhu klientů | Odkazy na testy |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 5 | 1 | 1 000 000 | 20.12.2011-3.1.2012 | 0 | 0,3% po 100% | 4% po 95.5% 0% po 3.4% 1-4% po 0.5% nad 4% po 0.6% |
||
| 2 | 2 | 3 | 10 000 | 25.1.2012; 19:30-22:50 (200 min) |
0 | 0.1% po 5% 0.2% po 95% |
0% po 6% 4% po 19% 5% po 75% |
nftest dokončil za 170 min. | |
| 3 | 2 | 3 | 100 000 | 2012-01-26,13:53:08 - 2012-01-27,23:05:54 | 0 | 0.2% po 3% 0.3% po 97% |
pod 4% po 2.5% 4% po 27% 5% po 65% 6% po 5% nad 6% po 0.5% |
stroj1 1992 min. stroj2 1985 min. stroj3 1678 min. a 1656 min. |
Samostatná stránka testu č.3 |
| 4 | 2 | plánováno 11 funčních 9 |
100 000 | 2012-02-09T13:30:00 - 2012-02-12T19:46:45 (4 697 minut) |
0 po 100% času | 0,3% po 98% času ------------ Aritm. průměr: 0,3% Směrodatná odch.: 0,01% |
4% po 63% času 5% po 34% času ------------ Aritm průměr: 4,4% Směrodatná odch.: 1,06% |
enta3: 4 370 minut nfsen-devel: 4 444 minut buldog: 2 570 minut (ir: 4 697 minut) (office2: 4 697 minut) |
Stránka distribuovaného testu č.1 |
2.2 Load testing¶
Ověření chování produktu při zátěži na kterou je produkt navržen a při které bude využíván. Tato zátěž byla stanovena ve specifikaci na 100 událostí/sec.
| Test # | Počet klientů | Počet událostí/klient | Počet událostí celkem | Doba běhu | Sledované údaje | Poznámky |
|---|---|---|---|---|---|---|
| test 1 | 1 | 100 | 100 | 10 hodin | vytížení procesoru a paměti, rychlost odezvy server-klient | |
| test 2 | 10 | 10 | 100 | 10 hodin | vytížení procesoru a paměti, rychlost odezvy server-klient | |
| test 3 | 100 | 1 | 100 | 10 hodin | vytížení procesoru a paměti, rychlost odezvy server-klient |
2.3 Stress testing¶
Ověření chování robustnosti produktu při extrémní zátěži. Ta bude postupně přidávána až do okamžiku, kdy přestane produkt odpovídat, případně se zhroutí.
| Test # | Počet klientů, událostí/klient | Růst zátěže | Sledované údaje | Poznámky |
|---|---|---|---|---|
| test 1 | 10,10 | + 2 kl., +2ud./kl | vytížení procesoru a paměti, rychlost odezvy server-klient, počet klientů a událostí |
2.4 Endurance testing¶
Produkt poběží dlouhodobě (14 dní) pod zátěží stanovenou ve specifikaci (100 událostí/sec.). Bude tak otestováno, zda je produkt schopný ostrého provozu a nedochází k degradaci výkonu, nebo vyčerpávání prostředků.
| Test # | Počet klientů | Počet událostí/klient | Počet událostí celkem | Doba běhu | Sledované údaje | Poznámky |
|---|---|---|---|---|---|---|
| test 1 | 10 | 10 | 100 | 14 dní | vytížení procesoru a paměti, rychlost odezvy server-klient, velikost DB |
Odpovědi na dotazník k instalaci klientů¶
| 1) Byl instalován odesílající nebo přijímající klient? | 2) Jak dlouho zhruba instalace trvala (v minutách)? | 3) Bylo potřeba provést významější úkony nepopsané v pokynech k instalaci? Jaké? | 4) Proběhla instalace bez komplikací? Pokud ne, co se zkomplikovalo? | 5) Proběhla integrace klienta v pořádku? Pokud ne, co se zkomplikovalo? | 6) Dle čeho byla v odesílajícím klientu nastavena konkrétní hodnota timeout? Byla nastavena dle nějakého postupu/logiky, nebo byla zvolena odhadem/dle tutoriálu? | 7) Co znamená v klientské aplikaci čas detekce? Jedná se o čas, kdy událost nastala, nebo je to okamžik, kdy byla událost zachycena? Nebo se jedná o časové okno, případně jiná možnost? | 8) Jak náročné byly zásahy do kódu, aby klientská aplikace produkovala časové známky pro Warden v UTC? Jaký formát časové známky je použit v klientské aplikaci? | 9) Bylo třeba vyhledat pomoc někoho z vývojového týmu? | 10) V případě že jste si dělal poznámky v průběhu instalace a integrace, budete ochotný je poskytnout pro sdílení postupu? | |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Odesilajici klient. | Instalaci jsem nedelal, viz nize. Integrace do pluginu dict trvala cca hodinu - nejvice casu mi zabrala konverze casu do UTC ve formatu ISO 8601 a stejne neni detected presne. | Zjistit, zda a jake ma WardenClientSend::saveNewEvent navratove hodnoty. | Neprovadel jsem, klient uz byl na stroji (nfsen) nainstalovan. | Do Syslogu bych chtel zapisovat, zda se podarilo odeslat udalost na Warden server. Proto me zajimala navratova hodnota WardenClientSend::saveNewEvent, o ktere jsem se ani v README ani v prikladu example-sender.pl.txt nic nedozvedel. | Odhadem jsem nastavil 1 den. To mi prijde jako dostatecny cas pro odvraceni utoku na SSH typu "1 IP utoci na vice IP z nasi site". | Ve stavajici implementaci to je kvuli snadnejsi implementaci casova znamka odeslani na Warden server. V praxi by to melo byt velmi blizke casu, kdy hlasena udalost nastala. | Vzhledem k me neznalosti moznosti prevodu casove znamky do UTC a do casove zony GMT v Perlu to byla casove nejnarocnejsi cast integrace (cca 30-45 minut vcetne instalaci nejruznejsich balicku a pokusu na testovacim kodu). Klientska aplikace pracuje s casovou znamkou ve formatu TIMESTAMP v PostgreSQL a formatu nfdumpu (flow start). | Krome registrace ne. | Poznamky jsem si nedelal, jsem ale ochoten sdilet zkusenosti s prevodem casu v Perlu. |
| 2 | Odesilajici | 20 - 30 minut | ne | Instalace bez problemu | Drobne problemy s certifikaty. ALe to nebyl problem instalacnich/integracnich instrukci. | Zkopirovana podle tutorialu | Pocatek casoveho okna ve kterem byl incident detekovan | Jeden radek kodu navic. Klientska aplikace pouziva casove pasmo 'Europe/Prague' | V principu ne. Pomahal mi/sledoval me Tom, ale spis v pozici administratora nfsenu a ne vyvojare aplikace. | Zadne jsem si nedelal |
| 3 | odesílající | snad půl hodiny (ovšem za přítomnosti vývojářů, s tvorbou poznámek, atd.), bez registrace | ne | proces registrace byl popsán až na konci pokynů, ale klíče jsem potřeboval už při instalaci | váhal jsem, co vyplnit v položce $attack_scale, jinak v pořádku (vyskytla se chyba, ale ta nesouvisela s integrací) | nenapadla mě vhodná hodnota, tak jsem nastavil null | čas, kdy incident nastal | zásahy náročné nebyly, ale dlouho jsem hledal vhodný postup konverze do UTC v perlu, klientská aplikace pracuje s formátem "YYYY-MM-DD hh:mm:ss.fff" | ano, potřeboval jsem poradit ohledně klíčů během instalace (neprováděl jsem registraci, ani jsem neznal její průběh) | ano, pokud v poznámkách najdu něco zajímavého, zajímalo by mě, jak ostatní řešili konverzi do UTC |
| 4 | Oba. | Bez mailove registrace do 10ti minut. Pokud bych nenarazil na zadne problemy, tak i ta prvotni instalace (vcetne jednoduche modifikace skriptu) cca 20 minut. Nejvice casu podle me zabere generovani SSL certifikatu a jeho nasledneho potvrzeni spol. Comodo. | Nejsem si zadnych takovych vedom. | Komplikaci jsem mel s chybou, ktera je uz ale nyni opravena. Cili bez komplikaci. | Zkomplikovalo mi celou vec certifikat, ktery byl vygenerovan pro vice alternativnich jmen. Klienta jsem registroval prave s alternativnim jmenem, ktere mi Warden server odmitnul. | Zkusenost s tim, jak dlouho byva (napr. u phishingu) IP adresa zneuzivana k rozesilani. | Cas detekce beru okamzik, kdy byla udalost poprve detekovana. | Bez problemu. Nenarocne. | Ano, viz jiz zminka o odstranenem problemu, pripadne zminka o neakceptaci alternativniho DNS jmena v certifikatu. | Ano. |
| 5 | Zatim jen odesilajici. | Cca 5 min. | Ne. | Zadne komplikace. | Byl nutny zasah do klienta: Die misto exit ve funkci errMsg(). | Pouzito 20 dle tutorialu. | Cas prvniho z reportovane serie <attack_scale> incidentu. | Zdrojova aplikace pouziva format "YYYY-MM-DD-hh:mm:ss.dddd". Prevod do pozadovaneho tvaru v UTC je v podstate trivialni s pouzitim modulu Time::Local. Popravde receno, puvodne jsem predpokladal, ze o prevod do UTC se postara funkce WardenClientSend::saveNewEvent. | Ne. | Zadne poznamky. |
| 6 | Vysílací. | Samotná instalace byla krátká; mnohem delší byly přípravné práce získání certifikátů pro použité servery, problém s hledáním modulu FindBin). | Ne. | V seznamu závislostí v souboru README je mj. uveden i modul FindBin, který není samostatně dostupný v distribuci OpenSUSE ani v CPANu. Až potom, co jsem se zeptal na radu správců WARDENu, jsem pochopil, že FindBin je součástí PERLu. | Proběhla dobře. | Byla nastavena tak, aby bylo jisté, že data budou platit i v době, kdy je vysílací strana přenese na server Warden (i s reservou). | Je to čas, kdy aplikace detekovala pokus o přístup do sledovaného adresového prostoru (s přesností na 1 sekundu). Hlásí se u každého jednotlivého útoku. Pokud je v rámci integračního časového intervalu detekováno několik útoků ze stejné zdrojové adresy na stejný koncový TCP port, hlásí se čas počátku a konce těchto útoků opět se vteřinovou přesností; v poznámce je uvedeno `START' a `END'. | Nenáročné. Aplikační program používá Unixový Epoch Time. | Zeptal jsem se na radu v souvislosti s modulem FindBin. | Poznámky jsem si nedělal, ale pokud by o to někdo stál, rád mu pomohu. |
| 7 | Odesilajici klient | 5-20min (druha instalace probehla hladce) | NE | Moduly SOAP jsem nejdrive instaloval pres CPAN, ktery neinstaloval Lite verzi a pomerne dlouho instaloval ostatni zavislosti. Osvedcilo se instalovat vsechny chybejici moduly pres apt-get. Nezvyklou veci je pro me format casu v ISO 8601, proc nepozivate klasicky epoch timestamp? | V poradku. | Posilam null | Cas detekce znamena cas, kdy byla udalost zachycena + posilam hodnotu attack_scale, tj, pocet hodnot agregovanych za interval testovani | Pouzivam klasicky UNIX_TIMESTAMP, musel jsem instalovat Perl moduly a konvertovat cas. use DateTime; my $dt = DateTime->from_epoch(epoch => $epoch); | NE | Poznamky nemam. |