Warden

OK, me osobne by se urcite libilo mit validacni hashe nastavovanou pres warden-server.conf, jelikoz nekdo jiny muze pouzivat uplne jine nazvy typu udalosti, atd. a bylo by pro nej velice nekonfortni to hledat nekde ve zdrojacich a prepisovat to tam. Souhlas?

Naprostý souhlas, přesně tak jsem to myslel.

Do serveru jsem doplnil validaci typu prichozich udalosti. Spolecne s touto zmenou jsem upravil i warden-server.conf a install.sh. Vse je nakomitovano do GITu, revize ac58da12. Zmenu je potreba doplnit do CHANGELOGu a README.

Kontrola validity nastaveneho typu udalosti predelana na

my $match = grep /$type/, @{$VALID_STRINGS{'type'}};

Jinak co se tyce Kostejovi poznamky:

Zkouseli jste funkcionalitu prijimace, pokud je prijimaci klient registrovany
jako _any_? Co kdyz bude chtit jen nejaky typ zpravy, projde procesem autorizace,
na prvni pohled se mi zda, ze ne. Pletu se?

V aktualnim stavu je to tak, ze klient by musel mit dve registrace, jednu pro any a druhou pro zvoleny 'type'. Neni problem udelat drobnou upravu tak, aby klient, ktery ma zaregistrovany typ any a prijde pouze s konkretnim typem aby jej take dostal, jelikoz pro any to vlastne znamena, ze ma pristup ke vsem typum udalosti.

Cast o Kostejove poznace patri k ticketu #523, takze jsem ji tam i vlozil, pardon.

Souvisí to blízce s validací - 58f4dd70 přidal typ "probe".

Pavel Kácha wrote:

Mít ve %VALID_STRINGS{"type"} i "_all_" není dobrý nápad. To je hodnota, která se smí vyskytnout jen v clients.type, určitě ne v events.type.

Ano to mas naprostou pravdu. Vyhozeno z hashe.

Tak, dival jsem se na dalsi polozky, ktere jsou ukladany do DB a je potreba je validovat. Moje napady na moznost validace jsou nasledujici:

$id - neni potreba validovat, sekvence generovana v DB
$hostname - neni potreba validovat, server si jej zjistuje z certifikatu, anebo je mozne pomoci modulu Data::Validate::Domain, nebo regexp
$service - neni potreba validovat, server nezna nazvy vsech klientskych sluzeb, ktere posilaji data
$detected - muzeme validovat jestli neni nastaven cas z budoucnosti nebo format data
$received - neni potreba validovat, nastaveno serverem
$type - validace hotova
$source_type - muzeme validovat, jesli je nastavena [IP, URL, Reply-To:, null] (viz README); musi se validovat spolecne s $source
$source - muzeme validovat IPv4/IPv6 adresu, korektni URL, korektni mailovou adresu; musi se validovat spolecne s $source_type
$target_proto - muzeme validovat, ale bylo by to 256 protokolu pro L3 a 1024 pro L4 (pokud to omezime pouze na rezervovane porty) (viz README)
$target_port - muzeme validovat, na hodnotu mezi 0-65535
$attack_scale - muzeme validovat, na unsigned int
$note - neni potreba validovat, melo by stacit ze je escapovana DB handlerem
$priority - muzeme validovat, na unsigned int
$timeout - muzeme validovat, na unsigned int
$valid - neni potreba validovat, nastaveno serverem

Pavel Kácha wrote:

Co jsem umazal, s tím souhlasím a není třeba řešit.

$hostname - neni potreba validovat, server si jej zjistuje z certifikatu, anebo je mozne pomoci modulu Data::Validate::Domain, nebo regexp

Předpokládám správně, že pokud uvede špatné hostname, dostane peška při autentizaci?

Ano, to souhlasi.

$detected - muzeme validovat jestli neni nastaven cas z budoucnosti nebo format data

Co se stane, pokud přijde špatný formát? V db je typ timestamp, takže někde musí dojít ke konverzi a chybě nebo výjimce, pletu se?

Zde by to ale asi chtelo regexpem kontrolovat format YYYY-MM-DDTHH:MM:SS, jelikoz kdyz jsem jako 'detected' nastavit treba 2012-09-10TT09:05:03, tak db z toho udelala 2012-09-10 00:00:00.

$source_type - muzeme validovat, jesli je nastavena [IP, URL, Reply-To:, null] (viz README); musi se validovat spolecne s $source

Byl bych pro rudimentární validaci pomocí %VALID_STRINGS, když už je máme. V jaké podobě může být 'null'? Jako string?

OK, takze do %VALID_STRINGS se nastavi [IP, URL, Reply-To:, null]. null muzeme but dat jako string a na serveru z nej udelat databazovy null, nebo pouzit undef a opet z nej na serveru udelat DB null, at zbytecne nezabere misto.

$source - muzeme validovat IPv4/IPv6 adresu, korektni URL, korektni mailovou adresu; musi se validovat spolecne s $source_type

Veďme obojí v patrnosti, pokud analytici (Honza, Bodík, Dan) přijdou s tím, že jsou někde nesmysly, budeme řešit.

Dobre, pockame co casem kluci.

$target_proto - muzeme validovat, ale bylo by to 256 protokolu pro L3 a 1024 pro L4 (pokud to omezime pouze na rezervovane porty) (viz README)

To by byl overkill, nechme bez validace.

Dobre, naprosty souhlas.

$target_port - muzeme validovat, na hodnotu mezi 0-65535
$attack_scale - muzeme validovat, na unsigned int
$priority - muzeme validovat, na unsigned int
$timeout - muzeme validovat, na unsigned int

V db je jako int(2) nebo int(4), takže by při snaze zapsat jinou hodnotu měla někde vzniknout chyba už teď, jako u $detected, nebo ne?

Presne je to:

`target_port` int(2) default NULL,
`attack_scale` int(4) default NULL,
`priority` int(1) default NULL,
`timeout` int(2) default NULL,

Zkousel jsem ted ale do DB ulozit jako $target_port hodnotu -11 a proslo to a DB je -11.

Jinak tu snižuju prioritu, $type nás bolel nejvíc, pokud další nestihneme do vydání, nevadí.

Dobre, pokusim se tam ale dostat co nejvice veci.

Tomáš Plesník wrote:

$source_type - muzeme validovat, jesli je nastavena [IP, URL, Reply-To:, null] (viz README); musi se validovat spolecne s $source

Byl bych pro rudimentární validaci pomocí %VALID_STRINGS, když už je máme. V jaké podobě může být 'null'? Jako string?

OK, takze do %VALID_STRINGS se nastavi [IP, URL, Reply-To:, null]. null muzeme but dat jako string a na serveru z nej udelat databazovy null, nebo pouzit undef a opet z nej na serveru udelat DB null, at zbytecne nezabere misto.

Hodnotu 'null' vyhodime z validacni hashe a dokumentace, nikdo jej totiz zatim nepouzil. Pokud nekdo bude potrebovat, tak pridame.

Tomáš Plesník wrote:

$target_port - muzeme validovat, na hodnotu mezi 0-65535
$attack_scale - muzeme validovat, na unsigned int
$priority - muzeme validovat, na unsigned int
$timeout - muzeme validovat, na unsigned int

V db je jako int(2) nebo int(4), takže by při snaze zapsat jinou hodnotu měla někde vzniknout chyba už teď, jako u $detected, nebo ne?

Presne je to:

`target_port` int(2) default NULL,
`attack_scale` int(4) default NULL,
`priority` int(1) default NULL,
`timeout` int(2) default NULL,

Zkousel jsem ted ale do DB ulozit jako $target_port hodnotu -11 a proslo to a DB je -11.

Ochranu provedeme pomoci zmeny typu sloupcu v DB na unsigned int a nechame tudiz rozhodovani na DB. Overime, zdali je mozne zaporne cislo do DB ulozit. Pri presunu na produkcni server zkontrolovat jiz ulozena data.

Hodnoty validacni hashe se zmeni na regexpy (ze seznamu s vyctem), podle kterych se budou kontorolovat uzivatelska data pred ulozenim do DB.

Premyslim nad temi regexpy a rikam si jestli by nebylo opravdu lepsi nechat parametry:

$target_port
$attack_scale
$priority
$timeout

interne validovat serverem (vyhodit je z validovaci hashe), jelikoz je stejne zadny spravce zmenit nemuze - to by musel predelat cenou databazi. A to same i u

$detected

Ostatni dva parametry $type a $source_type bych dal jako vycet moznosti pomoci pole. Pro spravce mi to opravdu prijde stravitelnejsi.

Myslím si, že než se server dostane k někomu, kdo si s ním bude mít zájem hrát, bude už dost pravděpodobně vypadat výrazně jinak. Ale máš pravdu, že tyhle parametry správce definovat v současné době prakticky nijak nemůže. Ok, beru argument, zkus to tak, vyhneme se prozatím regexpům - ještě je otázka, zda dokážeš dát dohromady spolehlivý parsovací strptime řetězec.

Server ma hotovu validaci jednotlivych polozek udalosti, vse je ulozeno v GITu, 697a22dd. Jen pro prehlednost udelam rekapitulaci:

$id - neni potreba validovat, sekvence generovana v DB
$hostname - neni potreba validovat, server si jej zjistuje z SSL certifikatu
$service - neni potreba validovat, zavisi na registraci klienta
$detected - validace pomoci interniho regexpu
$received - neni potreba validovat, nastaveno serverem
$type - validace pomoci validacni hashe
$source_type - validace pomoci validacni hashe
$source - neni potreba validovat
$target_proto - neni potreba validovat
$target_port - validace pomoci interniho regexpu
$attack_scale - validace pomoci interniho regexpu
$note - neni potreba validovat
$priority - validace pomoci interniho regexpu
$timeout - validace pomoci interniho regexpu
$valid - neni potreba validovat, nastaveno serverem

Pokud proti tomu nikdo nic nema, tak muzeme ticket uzavrit.

Pavel Kácha wrote:

$detected: strptime neklaplo?

No tak nejak. Nasel jsem funkcni regexp a tak jsem to vsechno dal do regexpu ale kontrola se provadi interne na serveru a funguje to .