Warden

• kontrola dle nachystanych dotazu (mrtvi klienti, udalosti z budoucnosti, atd.) ... toto je hotovo
• kontrola validity (tento tiket)

Budou se vzdy posilat adminum serveru (nam), nebo se v budoucnu predpoklada prime odesilani spravcum?

Pozn. Nema byt target version spise 2.2?

V zásadě ano, hotové dotazy předpokládáme dlouhodobě, tedy že na ostrém serveru zůstanou a v budoucnu se budou rozesílat přímo správcům.
Offline kontrola validity je dočasná, poběží jen do okamžiku, kdy dokončíme zapnutí online validace, měla by hlásit jen adminům. Znamená to také, že dotazy nemusí být extra krásné a vyladěné na výkon.

Moje představa byla taková, že na kontrolu validity se watchdog pouze spustí s parametrem jiného konfiguračního souboru, ručně, nebo v jiný čas než stálé kontroly z cronu.

Target nastav jak myslíš, v zásadě na něm nezáleží, jde jen o dočasný specifický úkol, nastavil jsem 2.1, protože bych to rád rozběhl na ostrém wardenu se současnou verzí (kde chceme nasadit validaci).

Zatim jsem nachystal potrebne dotazy, ktere pouziji. Krome dotazu s ip/url/email jsou hotove. Pokud se nestane nic necekaneho, tak configurak bude hotovy a otestovany do konce tydne.

• detected - data pred sputenim nebo po spusteni wardenu
  

  SELECT * FROM events WHERE (detected > NOW() OR detected < '2013-02-05 00:00:00');
  

• type, source_type, target_proto - slovník
  

  SELECT * FROM events WHERE NOT FIND_IN_SET(type, 'portscan,bruteforce,probe,spam,phishing,botnet_c_c,dos,malware,copyright,webattack,test,other');
  
  SELECT * FROM events WHERE NOT FIND_IN_SET(source_type, 'IP,URL,Reply-To:');
  
  SELECT * FROM events WHERE NOT FIND_IN_SET(target_proto, 'IP,HTTP,TCP,UDP');
  

• source - formát ip/url/mailové adresy (najit vhodne regexy na IP, URL, email)
  

  SELECT * FROM events WHERE source NOT REGEXP ('???') AND source NOT REGEXP ('???') AND source NOT REGEXP ('???');
  

• target_port, attack_scale, priority, timeout - formát čísla nebo null
  

  SELECT * FROM events WHERE target_port NOT REGEXP ('[0-9]+') AND target_port IS NOT NULL;
  
  SELECT * FROM events WHERE attack_scale NOT REGEXP ('[0-9]+') AND attack_scale IS NOT NULL;
  
  SELECT * FROM events WHERE priority NOT REGEXP ('[0-9]+') AND priority IS NOT NULL;
  
  SELECT * FROM events WHERE timeout NOT REGEXP ('[0-9]+') AND timeout IS NOT NULL;
  

• attack_scale navíc NULL nebo >1
  

  SELECT * FROM events WHERE attack_scale IS NOT NULL AND attack_scale < 1;
  

• source - formát ip/url/mailové adresy (najit vhodne regexy na IP, URL, email)
  

   SELECT * FROM events WHERE source NOT REGEXP ('???') AND source NOT REGEXP ('???') AND source NOT REGEXP ('???'); 

V registerSender.pm použil Tom regexp na čtyřkovou IP adresu.

Dodelan posledni dotaz a config je nahran v gitu. Samotny watchdog s configem zatim bezi na warden-dev v mem cronu.

Podivam se na to. Na ostrem devu bezel config z gitu bez uprav? Nekde se muselo neco rozsypat, protoze to bezelo do pulky minuleho tydne v poradku na devu a ted pada se stejnou chybou.

Úpravy byly jen v $server_conf, $domain_name a v contact v hashi, jinak nic.

Měl jsi pravdu, ta délka dotazů je opravdu zoufalá.
Pokud bys použil sql konstrukce s JOINem (ne s vnořeným dotazem)

SELECT clients.* FROM clients JOIN events ON clients.service=events.service WHERE events.detected > '\$date' AND NOT FIND_IN_SET(events.type, 'portscan,bruteforce,probe,spam,phishing,botnet_c_c,dos,malware,copyright,webattack,test,other') AND events.valid = 't' GROUP BY requestor;

S vnořeným dotazem MySQL generuje novou dočasnou tabuli s výsledky a ta zaindexovat nejde.

  eval{
    my $dt = DateTime->now(time_zone => 'local')->subtract(days => $period);
    $date = $dt->strftime("%Y-%m-%d %H:%M:%S");
    print $date, "\n";
  } or do {
    #print "Warden watchdog - can't work with date\n";
    syslog("Warden watchdog - can't work with date\n");
  };

• Bez time_zone=>'local' DateTime přepočítává do UTC, takže při dotazu do db se porovnává s dvě hodiny starým časem.
• $dt->date() vrací jen den bez času (obdoba find -daystart), strftime počítá dny skutečně od současného okamžiku.

Ad dotazy do DB: jako docasne reseni by to melo fungovat pomerne dobre. Navrh na trvale indexovani (od nove verze) jsem poslal Tomovi. Snad se k tomu brzo vyjadri. Myslim, ze by bylo dobre tuto indexaci nadhodit v konferenci. Pokud nebude nikdo proti, ohlasime, ze bude tehdy a tehdy probihat par minut vypadek kvuli uprave db a odpalime to.

Ad generovani casu: s pridanim vetsi presnosti (strftime) nemam problem. Jen jsem myslel, ze nebude potreba. U casovych zon to bude ale jeste trosicku jinak. Kod by mel dle meho vypadat nejak takto:

...
 eval{
    my $dt = DateTime->now(time_zone => 'UTC')->subtract(days => $period);
    $dt->set_time_zone('local');
    $date = $dt->strftime("%Y-%m-%d %H:%M:%S");
  } or do {
...

Duvodem je problem s letnim casem pri matematice nad daty, ktery mi nedavno udelal pekne peklo ve skriptech.

Ok, souhlas s obojím.

Opravil jsem dve chyby, ktere jsme resili. Jmenovite jsou uvede nize. Momentalne to testuji na warden-dev. Pokud se neobjevi zadne dalsi problemy, tak vysledek do poloviny tydne commitnu do Gitu.

Problem s chybou pri praci s DB, kdy skript haze nasleduji hlasku je snad opraven:

./wardenWatchdog.pl -c ./WardenWatchdogOfflinecheck.conf -i 1
DBD::mysql::st execute failed: Operand should contain 1 column(s) at /root/wardenWatchdog/WardenWatchdog.pm line 145.
WardenWatchdog error: Warden watchdog - Couldn't get data from my database: DBI::st=HASH(0x18452b0)->errstr

Take je predelana prace s casem nasledujicim zpusobem:

...
 eval{
    my $dt = DateTime->now(time_zone => 'UTC')->subtract(days => $period);
    $dt->set_time_zone('local');
    $date = $dt->strftime("%Y-%m-%d %H:%M:%S");
  } or do {
...

Využil jsem dnešní neplánovaný velký výpadek a indexy na service nahodil. Upravíš-li dotazy, můžeme to vyzkoušet.

Pristi tyden se na to podivam. Mam commitnout dle dohody vyse uvedene opravy, nebo pockas na upravu dotazu pro indexy?

Počkám.

Ještě poznámka: nebylo by vhodnější používat na omezení časového okna (ve kterém se zprávy zkoumají) received, místo detected? Čas detected dodává senzor a může být chybný (proto ho kontrolujeme), received dodává server a je vcelku důvěryhodný. Dal by se pak také první test upravit na:

SELECT * FROM events WHERE received > '\$date' AND (detected > NOW() OR detected < '2013-02-05 00:00:00') AND valid = 't' GROUP BY service;

Takže by pracoval také jen nad oknem, zvoleným v konfiguraci.

• S upravou dotazu dle navrhu souhlasim. Uz jsem ji zapracoval.
• Jak jsi asi poznal z unikleho emailu dnes odpoledne, testuji upravene dotazy. Pokud se nevyskytne nejaky problem, tak vsechny zmeny nejpozdeji v Pa commitnu.