Dolje nevedeni programski paketi uglavnom dolaze "po defaultu", ali je svakako poželjno provjeriti jesu li instalirani i ispravno konfigurirani.
Za kompajliranje SMS robota nužna je neka (bilo koja) od inačica gcc C kompajlera. Precizna verzija gcc kompajlera nije bitna. Mi smo koristili gcc... koji je došao sa instalacijskim CD-ROMom Debiana.
Ukoliko Robotu želimo pristupati putem elektroničke pošte, treba mu omogućiti primanje e-maila, dakle instalirati programe za primanje i slanje e-maila.
Konfiguriranje korisničkog imena i lozinke administratora robota može se izvršiti putem konfiguracijskog programa "Setup" ili "ručno". Taj je postupak opisan u odjeljku
Konfiguriranje SMS robota .
Nakon unosa korisničkog imena i lozinke otvara se stranica za kreiranje korisnika, zapravo glavna stranica tzv. "konfiguracijske konzole", koja izgleda ovako:
Prvo polje je korisničko ime korisnika - ono mora biti jedinstveno pri čemu se velika slova razlkuju od malih, npr. "Mario" i "mario" nisu identična korisnička imena.
Tajna (secret) je za niz alfanumeričkih znakova (trenutno 40 slovčanih znakova) koji predstavljaju tajni individualni ključ korisnika.
Tajni niz generira se i unosi u bazu automatski prilikom dodavanja novog korisnika.
Interpretacija tajnog niza ovisi o tome da li se za autentikaciju koriste jednokratne lozinke (tzv. TAN-ovi) ili token. Ono što je bitno napomenuti jest da se tajni niz nalazi samo u bazi i nigdje drugdje. Postupak autentikcije korisnika je takav da se taj ključ treba jedino nalaziti u bazi Robota.
U polje "Expires" unosi se datum nakon kojeg automatski presatve vrijediti korisnički račun. U verziji 1.00 unešeni se datum ignorira.
Kad korisnik pošalje neki zahtjev Robotu, rezultati obrade zahtjeva (ako ih ima) šalju se nazad korisniku koji je poslao zahtjev.
Slijedeća dva polja sadrže podathe o SMS i e-mail adresama putem kojih korisnik želi primiti povratnu informaciju u slučaju da nije drugačije zadano u samom zahtjevu ili da se koristi skraćeni format povratne adrese (vidi odjeljak o sistemskom modulu reply).
Jedna od gore navedenih adresa može se izabrati kao "defaultna" (polje Default). Ona se koristi u slučaju da je zahtjev došao od poznatog korisnika (navedenog u bazi) te da u zahtjevu nema odjeljka koji se odnosi na modul reply.
Završno polje sadrži informaciju o tome koristi li korisnik za autentikaciju sistem unaprijed izračunatih jednokratnih lozinki (TAN-ova) ili sistem dinamičkih jednokratnih lozinki za čiju je proizvodnju potreban specijalni uređaj, takozvani token. U verziji 1.00 ovo se polje ignorira i jedini mogući način autentikacije je putem liste TAN-ova.
Dvije tipke dolje desno na slici 3 odnose se na TAN-ove.
Klikom na tipku "Generiraj TAN" pokreće se generiranje liste od 100 TAN-ova za korisnika.
Tipičan rezultat takve akcije prikazan je na slici 3a.
Kao što je rečeno u uvodu, Robot sam po sebi ne može vršiti nikakav koristan zadatak. Korisne zadaće obavljaju tzv. aplikacijski moduli
(vidi odjeljak Aplikacijski moduli).
To su u stvari programi koji primaju zadatke od Robota (preciznije "masterbota") i koji znaju pisane rezultate predati Robotu (točnije sistemskom modulu "reply").
Da bismo dodali naredbu, potrebno se je vratiti korak unazad klikom na link "Application modules managenent". Time ćemo se vratiti na tablicu svih modula (koji su popisani u bazi). Tipična tablica prikazana je na slici 5.
Klikom na tipku "Unos" vršimo unos podataka u bazu i vraćamo se na tablicu modula (slika 6).
Iteracijom može se unijeti proizvoljan broj naredbi za dani modul.
Klikom na tipku "Odustani" vraćamo se na tablicu modula, pri čemu nema promjena u bazi.
Popis naredbi koje su unešene za pojedini modul možemo dobiti tako da u tablici modula (slika 6) kliknemo na polje "EDIT" za odgovarajući modul. Na tom formularu možemo izvršiti unos parametara za sva
Klikom na polje "RIGHTS" otvara se formular (slika 9) na kojem se svakom korisniku može dodijeliti ili uskratiti pravo na izvršavanje dotične komande.
Pri dnu stranice je izbornik za upravljanje sustavom. Ako je natpis upisan bijelom bojom onda taj tekst označava trenutno otvoreni prozor. Tako je na slici 1. označena tipka s natpisom Korisnik što znači da se na toj stranici korisnik autentificira.
Ako tipka ima podebljani rub, onda se na nju može kliknuti i otići na odgovarajuću stranicu. Na slici 1. su tako označene tipke s natpisima:
Zahtjev za odlazak na stranicu za izradu zahtjeva pomoću izbornika i
Utipkaj zahtjev za odlazak na stranice za ručno upisivanje zahtjeva
Klikanjem na tipke koje su označene s tankim rubom ne će se dogoditi ništa. Takav primjer je tipka s natpisom Pošalji koja inače služi za slanje zahtjeva. Kako se na prvoj stranici korisnici samo autentificiraju i kako još nije napravljen zahtjev, onda se on ne može ni poslati.
Na svakoj stranici se nalazi i tipka s natpisom Izlaz. Ona služi za brisanje cijelog zahtjeva i prekid rada sa sustavom. Ona vraća korisnika na početnu stranicu.
Pritiskom na tipku Zahtjev odlazi se na stranicu na kojoj se radi zahtjev SMS-robotu. Slika 2. prikazuje tu stranicu s primjerom zahtjeva. Unutar crnog okvira se u padajućem izborniku odabire modul kojemu se treba poslati neka naredba. U tom padajućem izborniku se nalaze samo oni moduli s naredbama za koje korisnik ima pravo pokretanja.
Kada korisnik odabere modul, u plavom okviru u padajućem izborniku odabire naredbu koju želi izvršiti.
Ako ta naredba ima parametre, korisnik može i njih odabrati u sivom okviru. Odabere li parametar koji može imati neku vrijednost, uključuje mu se tekstni okvir za upis te vrijednosti. Pritiskom na tipku Dodaj parametar, taj parametar se sprema u popis parametara za tu naredbu. To je nužno zato što jedna naredba može imati više parametara.
Korisnik može dodati naredbu i njezine parametre u popis naredbi pritiskom na tipku Dodaj naredbu. Isto tako može dodati i cijeli modul s odabranim naredbama i njihovim parametrima u popis modula pritiskom na tipku Dodaj modul.
Sa svakog popisa se može i ukloniti zapis. To se radi tako da se označi zapis ili više zapisa i pritisne se odgovarajuća tipka za brisanje (Izbriši parametar, Izbriši naredbu ili Izbriši modul).
Kada se u popis doda modul, onda se pri dnu stranice ispiše cijeli zahtjev SMS-robotu s ispravnom sintaksom. Riječi u sintaksi su označene različitom bojom tako da ih je lakše razlikovati. Tako su moduli označeni crnom, naredbe plavom, a parametri sivom, sve u skladu s okvirima u kojima se zadaju. Crvenom bojom je označen znak za odvajanje modulâ u zahtjevu ($), znak za odvajanje naredbi jednog modula (;) i znak za odvajanje korisničkog imena od ostatka zahtjeva (*). Korisničko ime je označeno tamno plavom bojom.
Kada se u popisu modula nađe neki modul s naredbom (dakle određen je zahtjev), tipka Pošalji se uključuje. Pritiskom na tu tipku zahtjev se šalje SMS-robotu. Nakon što je zahtjev uspješno poslan, otvara se stranica koja korisnika obavještava o tome (slika 3.).
Nakon toga se može napraviti novi zahtjev SMS-robotu pritiskom na tipku Novi zahtjev te se opet otvara stranica za izradu zahtjeva (slika 2.).
Ako se na prvoj stranici pritisne tipka Utipkaj zahtjev ili na stranici na kojoj se korisnik obavještava da je zahtjev poslan SMS-robotu pritisne tipka Utipkaj novi zahtjev, otvara se stranica za ručni upis zahtjeva (slika 4.). Na toj stranici korisnik može u tekstni okvir utipkati zahtjev. Korisnik ne mora na karaju zahtjeva upisati svoje korisničko ime jer se ono automatski dodaje pošto sustav zna tko je korisnik koji upisuje zahtjev.
Pritiskom na tipku Pošalji otvara se stranica na kojoj korisnik može još jednom prevjeriti svoj zahtjev (slika 5.) pa ako ga je dobro upisao treba još jednom pritisnuti tipku Pošalji.
Tada se otvara stranica na kojoj se korisnika obavještava da je zahtjev poslan SMS-robotu. Na toj stranici riječi u zahtjevu nisu sintaksno obojene (slika 6.) zato što sustav nema ugrađeni parser koji bi provjeravao sintaksu ručno upisanog zahtjeva.
Sistem autentikacije korisnika putem liste TAN-ova
SMS robot koristi slijedeći sistem autorizacije TAN-ovima.
SISTEM AUTORIZACIJE TAN-OVIMA
TAN-ovi su 4 slovčani i generiraju se na slučajan način između
njih 26^4=457000. Generira se batch od 100 TAN-ova i zajedno
s njim slučajni 40-slovčani
tajni ključ skey korisnika i tablica sjena. Za svaki TAN postoji jedna
sjena koja se računa ovako: sha(i)=Hash8(skey|TAN(i)), gdje je Hash
neka univerzalna hash funkcija koja hashira bilo kaj u 8 slova
(npr. srezani MD5), a znak | označava konkatenaciju nizova.
TAN-ovi i ključ se koriste jednom. Nakon toga generiraju se novi TAN-ovi
i novi tajni ključ.
Tajni ključ korisnika i sjene poznati su samo Robotu, a TAN-ovi
samo korisniku.
User se autenticira tako da se predstavi svojim korisničkim imenom (koje
je javno i nepromjenjivo) koje ga povezuje s trenutnim tajnim nizom
i jednim TAN brojem. Autentičnost se provjerava tako da se izračuna
Hash8(skey|TAN) i usporedi sa sjenom koja je trenutno na redu.
Nakon svake uspješne autentikacije korisnik odbacuje ispkorišteni TAN
a Robot odbacuje iskorištenu sjenu ili pomiče pointer na slijedeću.
Za slijedeću autentikaciju se koristi slijedeći TAN u nizu.
Ako je autentikacija neuspješna korisnik ima ukupno N pokušaja nakon
čega
mu se račun blokira te mora kontaktirati administratora.
DISKUSIJA METODE
Sjena je duga 8 slova a TAN 4. Sjena je uzeta dulja radi toga
da bi vjerojatnost da dva različita TAN-a imaju istu sjenu bila mala
kako se ne bi povećala osjetljivost na napad pogađanja TAN-a.
Ta vjerojatnost (uz zadržavanje relativno malog batcha) mogla bi ostati
zanemarljivo mala i u slučaju kada bi sjena bila kraća od TAN-a
(što bi
bilo povoljno ze neke tipove napada) ako bi i TAN i sjena bili dugi.
No radi praktičnih razloga želimo kratke TAN-ove.
ANALIZA SIGURNOSTI
NAPAD 1
Pretpostavka. Napadač generira slučajni TAN.
Postoji vjerojatnost N/457000 da
se uspješno autenticira. Uspjeh slijedećeg napada je jednak (ne
povećava se) bez obzira na ishod prvog napada.
(Za superkorisnika (administratora) mogu se zahtijevati 2 uzastopna TAN-a iz M pokušaja
pri čemu je vjerojatnost uspješnog napada M/2E11. Ta mogućnost međutim
nije implementirana u verziji 1.00.)
NAPAD 2
Pretpostavka. Napadač zna redni broj "i" slijedećeg TAN-a u nizu i zna
njegovu sjenu sha(i).
Napadač bi morao invertirati funkciju Hash(8) što je nemoguće
jer sa samo
8 izlaznih slova nije moguće jednoznačno odrediti 48 ulaznih slova,
odnosno trebalo bi pogađati 26^(48-8)=4E56 kombinacija.
NAPAD 3
Pretpostavka. Napadač zna redni broj "i" slijedećeg TAN-a u nizu, zna njegovu sjenu sha(i) i zna tajni ključ korisnika.
Napadač bi morao invertirati funkciju Hash(8) što je moguće učiniti
jednoznačno s velikom vjerojatnošću budući da je sjena dosta dulja od
TAN-a. Mala je dakle vjerojatnost da postoje dva TAN-a koji daju istu sjenu.
Problem je međutim što se funkcija Hash8 ne da invertirati brže nego da
se pogađa njen ulaz pa je to dakle zadatak reda isprobavanja svih
TAN-ova ili 26^4=457000. To je relativno mali zadatak no da bi se došlo dotle
potrebno je razvaliti i bazu i doći u posjed datoteke sa sjenama.
Posao kojeg napadač ima cak i u tom za njega vrlo povoljnom
slučaju raste eksponencijalno s duljinom TAN brojeva, pa bi se odabirom
nesto duljih tanova i tu dao napadaču zagorčati život samo je pitanje
ima li to smisla kad je vec očigledno ušao na sistem.
Općenito, kad bi sjena duljine s bila kraća od TAN-a duljine t
zadatak bi bio pogađanje reda približno 26^(s+t).
Npr. kad bi TAN bio duljine 8, a sjena duljine 4, zadatak napada 3
bi bio solidnih 10^17 (?).
Aplikacijski moduli
ŠTO JE APPMOD (APLIKACIJSKI MODUL)
Aplikacijski modul je programski paket koji omogućuje izvršavanje nekog
zadatka putem SMS robota. Robot aplikacijskom modulu osigurava dolaznu
i odlaznu komunikacijsku infrastrukturu (koja osigurava kripto sigurnost,
management korisnika itd), no aplikacijski modul je zadužen za
izvršavanje specifičnog zadatka. Robot bez aplikacijskih modula ne
baš i ne može učiniti neku korisnu akciju.
Robot može "opsluživati" neograničen
broj aplikacijskih modula.
Kao primjer aplikacijskog modula možemo zamisliti "imenik". Bitni dio
tog modula je egzekutabla koja može primiti (od Robota) neki zahtjev,
na primjer, "telefonski broj Pere Perića" procesirati ga i odgovor
poslati Robotu. Robot se brine o primanju zahtjeva, autentikaciji
korisnika koji je poslao zahtjev, njegovom autoriziranju,
formatiranju u standardni format i isporuičivanju odgovarajućem
aplikacijskom modulu (u ovom slučaju imeniku) te o slanju odgovora na traženu povratnu adresu/kanal.
OSNOVNI POJMOVI
SMS robot sastoji se od većeg broja jedinica (vidi odjeljak o organizaciji
SMS robota). Za funkcioniranje aplikacijskig modula (appmod) važni su samo
ovi sistemski moduli i sistemske egzekutable:
- masterbot
- reply-SysMod
- parser
- newreq.
Robotov home direktorij sadrži oveći broj direktorija od kojih su neki značajni za spomenuti ovdje, to su:
Kad Robot zaprimi zahtjev on ga procesira (autentikacija, autorizacija,
formatiranje...) te na kraju masterbot predaje zahtjev odgovarajućem
appmodu. Komunikacija između masterbota i appmoda je jednosmjerna i ide
samo u smjeru masterbot -> aplikacijski modul.
Proslijeđeni zahtjev stiže u jednoj liniji i punom normalnom formatu:
Za parsiranje zahtjeva appmod može koristiti vlastitu rutinu, rutinu u
QB2C-u ili C-u koja dolazi s robotskim paketom (ParseModuleForCommandsAndTheirParlists(.c)(.bas)) ili sistemsku egzekutablu
parser koja parsira zahtjev i izbacuje ga na stdout. Sintaksa parsera je:
pri čemu parser izbacuje parsirani zahtjev na stdout.
(Detaljnije o parseru vidi u odjeljku Parser .)
Nakon što appmod obavi svoje, on može predati odgovor sistemskom modulu
koji se zove reply-SysMod. Odgovor mora imati striktnu robotsku sintaksu
(vidi Sintaksa zahtjeva Robotu ):
Prije nego se krene na pisanje aplikacijskog modula (appmoda)
potrebno se je odlučiti
za jedan od 4 podržana načina komunikacije između masterbota i appmoda.
Za modul imena "mymodule" treba u direktoriju ${APPBIN} postojati
egzekutabla imena "mymodule-AppMod" (može biti symlink).
Modul kod pokretanja može čitati nekakve datoteke kojima se konfigurira
bez rekompajliranja. Primjer ~${BOT}/.mymodulerc. Takve datoteke smjestiti u
direktorij ${APPMOD}/conf/ . One u pravilu trebaju pocinjati znakom "."
i zavrsavati slogom "rc", iako je to samo obicaj.
Logovi neka se pišu u direktorij ${APPMOD}/log/ i nek imaju ime koje
podsjeća na ime modula, npr mymodule.log . Za sada, format log datoteke je
autoru modula na volju.
Prvo pokretanje aplikacijskih modula koji su daemoni za sada nije rijeseno.
Za sada se pokrecu rucno (npr: mymodule-AppMod 2>&1 /dev/null &).
Kod tipa 3, masterbot izvrsava modul (tj. egzekutablu
${APPMOD}/bin/mymodule-AppMod) jednom i pri tome joj predaje zahtjev
putem standardnog ulaza. Dolje opisani modul je vrlo jednostavan: on
primljenu naredbu samo prosljedjuje primatelju konstantne e-mail adrese.
Datoteku koja sadrzi gornje dvije linije nazvati npr. "mymodule" i staviti u
direktorij ${APPMOD}/bin .
Postoji 5 načina na koje masterbot može predati zahtjev nekom appmodu
(samo su 4 netrivijalna). Da bi masterbot znao koji tip valja upotrijebiti
za koji appmod, taj podatak (broj "tipa" komunikacije) treba unijeti u
robotovu bazu podataka putem administratorskog sučelja kako je opisano
u odjeljku
Administracija modula .
Pretpostavimo da se appmod zove "mymodule", te da smo vršni direktorij
za aplikacijskke module označili s ${APPMOD}. U tom slučaju aplikacijski
modul (egzekutbla) nosi puni naziv ${APPMOD}/bin/mymodule-AppMod.
Nadalje označimo direktorij sa javnim egzekutablama s ${BOTPUB}/bin/.
Tipovi komunikacije su slijedeći:
Prvo trebamo definirati neke pojmove. U jednom zahtjevu SMS robotu može biti sadržano više jednostavnih "zadataka". Na primjer u zahtjevu:
sadržana su dva zadatka: od modula ng se zahtijeva report, a od modula imenik se zahtijevaju imenički podaci o svim osobama čije je ime Pero. Kao što ' emo vidjeti kasnije, scheduler je također modul (naziva sched) kojem se mogu slati zahtjevi koji su vrlo jednostavni u zapisu ali se sastoje od mnoštva zadataka.
Za sada, u verziji 1.00, postoji samo ljuska schedulera s minimalnom (ali ipak u velikom postotku slučajeva dovoljnom) operativnošću odnosno podržanom sintaksom. Predviđa se da bi se u kasnijim verzijama SMS robota sintaksa proširila.
Osnovna strategija rada schedulera treba dati (i u verziji 1.00 već daje) odgovore na slijedeća pitanja:
Odgovor na prvo pitanje mora biti u skladu s načelnim pravilom da "masterbot nista ne zna", on samo prosljedjuje zahtjeve modulima. Zbog toga je izgradjen sistemski modul sched (sched-SysMod) koji od masterbota prima zahtjeve na uobičajeni način (preko stdin-a).
Ljuska se dakle sastoji od dva programa u međuigri. Oni međusobno izmijenjuju podatke robustnim kanalima i djelatnom brzinom dobro ispod sekunde, a koji se kanali mogu u budućnosti mijenjati/unaprijedjivati bez ikakva utjecaja na sintaksu uporabe ljuske.
gdje su:
timelist | =
| razmakom separirana lista (space separated list) vremena
time format | =
| [DD[-MM[-[YY]YY]]/]hh[:mm[:ss]]
list | =
| razmakom separirana (space separated) lista rednih brojeva zahtjeva kako su označeni u odgovoru naredbe query.
req | =
| kompletni zahtjev kojeg treba izvršiti u naznačena vremena
| | | |
Ako neki dijelovi vremena nisu navedeni, default se uzima iz trenutka
kad je schedd primio zahtjev (datumski dio) odnosno 0 (vremenski dio).
Npr. ako je zahtjev stigao SMS robotu dana 17.07.2003 onda:
Korisnikov unos | Značenje
|
8
|
17-07-2003/08:00:00
08:05
|
17-07-2003/08:05:00
08:05:13
|
17-07-2003/08:05:13
08:5:13
|
17-07-2003/08:05:13
8:5:13
|
17-07-2003/08:05:13
22.05.03
|
22-05-2003/00:00:00
22-5-03
|
22-05-2003/00:00:00
15.04
|
15-04-2003/00:00:00
15.4
|
15-04-2003/00:00:00
22.5.2003/8:00
|
22-05-2003/08:00:00
22.5.2003./8:00
|
22-05-2003/08:00:00
| | | | | | | | | | |
Modul sched razaznaje slijedeće naredbe:
Naredba
| Značenje
add
| dodaj spomenuti zahtjev za spomenutog korisnika
set
| postavi spomenuti zahtjev kao jedini za spomenutog korisnika (eventualne ostale pobriši).
query
| izlistaj sve zahtjeve za spomenutog korisnika. Zahtjevi dobivaju redni broj.
del
| obriši zahtjev(e) specificiran(e) rednim broje(vi)m(a)
| | | | |
Primjer:
sched add time=07:15 14:10 19:25,req="ng report"
ovo ce slati svaki dan u naznacene sate rezultat requesta "ng report" bas kao
da ga je korisnik poslao taj cas. Cijeli zahtjev dakako mora biti i autoriziran:
sched add tim=07:15 14:10 19:25,req="ng report" * dok qewt
Primijetimo da ce user "dok" biti efektivno pridodan zathjevima koje
salje scheduler:
ng report * dok (authenticated)
Primijetimo da je jednokratna autentikacija korisnika dovoljna no scheduler
će još provjeravati autoriziranost korisnika za svaku trazenu naredbu
navedenu u parametru req.
Složeniji primjer:
sched add times=07:15 14:10 19:25,req="ng report $ reply sms n=098126538" * dok qewt
NAPOMENA.
Vrijednosti parametara 'times' i 'req' mogu i ne moraju biti u navodnicima.
No u posljednjem primjeru zbog znaka dolar u zahtjevu vrijednost
parametra 'req' mora biti u navodnicima !
Parser
Parser je program koji može zahtjev u punoj standardnoj sintaksi
(vidi Sintaksa zahtjeva Robotu )
rastaviti na sastavne dijelove:
module, naredbe, parametre i vrijednosti parametara.
Parser prima ulazni string preko standardnog inputa (stdin) te vraća
parsirane elemente putem standardnog izlaza (stdout).
Sintaksa je:
${BOTPUB}/parser [-debug] < requestfile > outfile
ili
echo ' ...zahtjev... ' | ${BOTPUB}/parser > outfile
Svaki parsirani element je u jednom redu i u formatu: ime_elementa=vrijednost.
Evo kako to izgleda na primjeru:
echo ' imenik search pattern="Pero Peric" $ reply email address=mario@softhome.net $ auth login user=mario,pass=asdf ' | parser
Kao izlaz dobije se:
User=mario
Pass=axcv
Replyinfo=reply email address=mario@softhome.net
Modul=imenik
Cmd=search
Par=pattern
Value="Pero Peric"
Modul=reply
Cmd=email
Par=address
Value=mario@softhome.net
Modul=auth
Cmd=login
Par=user
Value=mario
Par=pass
Value=axcv
Parser je zamišljen da bude od koristi pri programiranju appmodova. Stoga osim što rastavlja zahtjev na sastavne elemente koji mogu biti od interesa
u aplikacijskom modulu, u odgovoru se nalazi
i polje "Replyinfo" čija se vrijednost jednostavno prenosi/predaje sistemskom modulu reply u svrhu slanja odgovora korisniku
(vidi Pisanje aplikacijskih modula ).
Dodatak: definicija nekih pojmova
autentikacija, autorizacija, modul, naredba, parametar, vrijednost