LE ENKRAT IN NIKOLI VEČ

Vrnimo se k primerom, ki smo jih spoznali v pretekli številki. Največja nevarnost je uporaba majhnega števila uporabniških imen oziroma gesel, ki jih uporabljamo za vse vrste storitev (na primer enako uporabniško ime in geslo za dostop do forumov, socialnih omrežij, dostop do elektronske pošte in bančno poslovanje ...). Vdor v sistem enega od ponudnikov ali razbitje gesla ob poznavanju uporabniškega imena pomeni možnost zlorabe vseh storitev, ki jih s pomočjo teh podatkov uporabljate. Podobno nevarnost pomeni razbitje gesla (možnost dostopa) za paket v vlogi upravljavca gesel, saj poznavanje glavnega gesla pomeni dostop do vseh uporabniških računov za vse shranjene storitve. Nekoliko boljše so tablice, a poznavanje tablice (možnost reproduciranja) in algoritma branja še vedno pomeni potencialno možnost vdora. Vse skupaj pa je popolnoma brezpredmetno, če uporabniško ime in geslo vpišemo v računalnik, ki ga nimamo popolnoma pod nadzorom, saj je lahko na njem nameščena programska oprema, ki beleži vse vnose tipkovnice (tako imenovani keyloggerji). Enega od tovrstnih paketov - Family Keylogger lahko najdemo na spletni strani http://www.kmint21.com/keylogger/. Namestitev paketa je zelo preprosta, delovanje pa je mogoče skriti pred očmi žrtve (možnost hide icon). Rezultat delovanja tovrstnega paketa je zajem oziroma zapis vseh znakov, ki smo jih vnesli prek tipkovnice ter rezultatov določenih operacij (na primer prijava na oddaljenem strežniku, ukazi, ki so bili izvedeni skupaj z rezultati/izpisom) - vse v obliki prosto berljivega besedila, shranjenega v tekstovni datoteki. In kakšna je v tem primeru rešitev?

V sistemih, pri katerih potrebujemo višjo raven varnosti, so že dolgo uveljavljene različne rešitve, do katerih je omogočen dostop prek mehanizma enkratnih gesel (One Time Password - OTP). Glavna značilnost tovrstnih sistemov je, da je ustrezno geslo pri vsaki prijavi drugačno. Poznavanje ali kraja že uporabljenega in zato »pretečenega« gesla ni problematična, saj je geslo veljavno le za eno »transakcijo«. Mehanizem je lahko nadgrajen še s časovno omejitvijo gesla - če gesla ne vnesemo v predpisanem časovnem okviru, to ni več veljavno in se ustvari/zahteva novo geslo.

ZA DOMAČE MOJSTRE

Funkcionalnost preprostega, a uporabnega strežnika OTP lahko vzpostavimo z nekaj znanja in vloženega časa tudi sami. Uporabili bomo starega znanca z imenom OPIE (http://www.inner.net/opie), ki je na voljo za različne sisteme »*NIX like«, uporabnikom najbližja pa bo verjetno kakšna distribucija Linuxa (OpenSuse, Ubuntu ...). Ime OPIE naj bi prišlo iz stavka »One Time Passwords In Everything«, namestimo pa ga s pomočjo dveh paketov (opie-client, opie-server). V primeru distribucije Ubuntu lahko to storimo kot korenski uporabnik s pomočjo ukaza apt-get install ime_paketa oziroma sudo apt-get install opie-client opie-server. Ko je strežnik nameščen, na njem naredimo tako imenovano seme in določimo sekvenčno številko, s pomočjo katere bomo izračunavali gesla. Ko bomo v nadaljevanju strežnik OTP povezali s strežnikom SSH, bo ta posredoval ustrezno informacijo, s pomočjo katere lahko izračunamo pravo geslo. Enkratno geslo sestavlja vedno paket šestih angleških besed.

Za lažje razumevanje si oglejmo konkreten primer. V našem primeru smo uporabili kar virtualizacijski strežnik (na starejši brezplačni različici VMware Server), na katerega smo namestili že pripravljeno okolje (appliance) - Linux Ubuntu (strežnik 11.04), ki smo ga prenesli s spletne strani http://linhost.info/downloads/. Po namestitvi in zagonu smo se na virtualni strežnik prijavili s privzetim uporabniškim imenom user in geslom ubuntu, ki smo ga takoj spremenili. Dostop do korenskega uporabnika smo si zagotovili s pomočjo ukaznega niza sudo su, ki mu je sledil ukaz passwd. S pomočjo tega smo spremenili še privzeto geslo za korenski dostop. Na našem virtualiziranem strežniku smo najprej prek spleta namestili oba potrebna paketa (apt-get install opie-client opie-server), za lažje delo pa smo namestili še Midnight Commander (apt-get install mc), ki ga zaženemo s pomočjo ukaza mc. Ker smo se odločili, da želimo sistem enkratnih gesel (OPIE) preizkusiti v kombinaciji s strežnikom SSH, smo namestili še potrebni strežnik (apt-get install openssh-server). Uspešnost namestitve strežnika SSH lahko preverimo kot korenski uporabnik z ukazom ssh localhost. Privzeto temelji kot kontrola prijave na mehanizmu PAM (Pluggable Authentication Module), ki kot kontrolni mehanizem uporablja »lokalno« shranjeno uporabniško ime in geslo. Potrebne nastavitve za posamezne storitve najdemo v konfiguracijskih datotekah imenika /etc/pam.d, a o tem nekoliko pozneje.

Izvedimo zdaj lokalno prijavo kot uporabnik »user« in si povečajmo pravice na sistemu s prijavo kot korenski/root uporabnik (ukaz su). Vnesimo ukaz opiepasswd -c, s pomočjo katerega trenutno prijavljenega uporabnika »dodamo« v sistem prijave z enkratnimi gesli. Sistem nas opozori, da naj ta ukaz vedno zaganjamo le lokalno (prek konzole) in naj vnesemo skrivni niz za generiranje gesel (v našem primeru smo vnesli m0jm1kr0). Na zaslonu smo dobili sporočilo:

ID root OTP key is 499 u16433
PEN REIN SHIM LA TOG OFF

Ponovno vnesimo ukaz opiepasswd, a tokrat brez parametra -c. Na zaslonu dobimo sporočilo:

You need the response from an OTP generator
New secret pass phrase:
otp-md5 499 u16434

ki nas poziva na vnos pravilnega gesla. Če poskusimo z vnosom naključnih znakov, ugotovimo, da nas pri tretjem napačnem vnosu program »odslovi«. Pozornejši bralec bo opazil, da je prišlo do povečanja vrednosti u16433 za vrednost ena na u16434.

Na prvi pogled je zapis morda nekoliko nejasen. ID-ju sledi ime uporabnika (v našem primeru root), sledi mu zaporedna številka (499), na koncu pa tako imenovano seme (u16433). Pod njimi je zapis šestih besed (v našem primeru PEN REIN SHIM LA TOG OFF), ki pomenijo unikatno in pripadajoče enkratno geslo. Kot smo videli v nadaljevanju, so navedeni podatki pomembni zato, ker nam jih bo strežnik ob prijavi navedel, mi pa jih bomo vnesli v ustrezen kalkulator. Poskusimo lahko kar z že nameščenim na strežniku. Če vnesemo ukaz opiekey 499 u16433 in vnesemo geslo m0jM1kr0, dobimo kot rezultat PEN REIN SHIM LA TOG OFF. Skratka, za ustrezno geslo smo potrebovali informacijo o zaporedju in ustreznem semenu, ki jih je določil in sporočil strežnik, ter skrivnostnem nizu, ki ga pozna uporabnik. Uporabljeni kalkulator pa je v opisanem primeru precej neuporaben, saj ga lahko uporabimo šele po uspešno opravljeni prijavi (lahko pa bi imeli nameščenega na drugem računalniku). Namesto njega lahko uporabimo kalkulator OTP na pametnem telefonu. V našem primeru smo na telefonu z operacijskim sistemom Android namestili program Opiekey, ki ga lahko prenesemo s spletne strani http://android.f00d.nl/opiekey/ ali Android Marketa. Če po zagonu Opiekeya vnesemo v polje Passpharese naš skrivni niz m0jM1kr0 ter v polje Challenge md5 499 u16433 in pritisnemo na gumb Calculate, dobimo v polju Response viden pričakovani niz PEN REIN SHIM LA TOG OFF. Našemu »pametnemu« telefonu smo tako dodali še eno funkcionalnost - pripomoček za avtentikacijo, ki ga imamo skoraj vedno pri sebi. Če nimate telefona s sistemom Android, lahko najdete precej koristnih informacij za druge tipe mobilnih naprav na strani http://motp.sourceforge.net/ oziroma http://tanso.net/j2me-otp/.

Namestitev ustreznega kalkulatorja OTP na pametnem telefonu se pri pogostejši uporabi lahko izkaže kot manj primerna. Prikazani niz (zahteva za geslo) moramo najprej vpisati v telefonski aparat, izračunano geslo, izpisano na zaslonu telefona, pa prepisovati prek tipkovnice računalnika v prijavno okno. Opravilo je nekoliko nerodno, saj lahko pri obeh prepisovanjih pride do neljube napake in je postopek treba ponoviti. Če za dostop uporabljamo svoj računalnik (za katerega vemo, da nima nameščene zlonamerne programske opreme), lahko ustrezen OTP-kalkulator namestimo kar nanj. Uporabniki okolja Windows lahko namestijo brezplačni winkey (ftp://ftp.irisa.fr/pub/OTP/), na voljo pa so podobni paketi tudi za druge operacijske sisteme. Oglejmo si le še javanska jotp (http://www.cs.umd.edu/users/harry/jotp/) ali jsotp (http://www.ocf.berkeley.edu/~jjlin/jsotp/), ki ju lahko zaganjamo prek spletne strani ali lokalno - v tem primeru preuredimo datoteko jotp.html tako, da bo vrstica applet codebase kazala na lokalni imenik (npr. < applet codebase=E:\jotp code=jotp.class width=500 height=200> ).

Za konec smo pustili še zadnjo možnost - izpis bodočih enkratnih gesel v datoteko. Ukaz opiekey -n 10 499 u16433 nam izpiše deset (-n 10) gesel od 490 do 499 in je videti takole:

490: HEY MARY JIM NET WARM FOOL
491: HICK OF MASK ROWS CAW HEAT
492: SLAM FLY BIT BARR JAVA AMID
493: RED PIE MEET RITE SOAR SELF
494: SWAN BORN HIGH SIGH STAB BULL
495: SLAM BALL SON REIN MIKE SLAM
496: HI DING BRIM SITE SUN EDGE
497: RAFT IOWA JAIL BOB RUNT ALP
498: RASH MEAD RIB DAM BERT CARR
499: PEN REIN SHIM LA TOG OFF

S pomočjo dodatnega »parametra« > gesla lahko pošljemo vsebino v datoteko gesla. V tem primeru (ali celo v primeru morebitnega izpisa na papir) moramo ravnati tako, da ta ne pride v neprave roke.

NAVEZA

Poskusimo vzpostaviti varno povezavo SSH na naš strežnik. Ob prijavi lahko vidimo, da nam ta ponudi prijavo, kot smo je vajeni. Razlog je, da smo na strežniku vzpostavili sistem enkratnih gesel, za zdaj pa ga še nismo povezali z nobeno storitvijo oziroma strežnikom. V našem primeru bomo sistem enkratnih gesel vpeljali za strežnik SSH. V imeniku /etc/pam.d/ lahko najdemo potrebne datoteke, s pomočjo katerih izvaja sistem kontrolo prijave za posamezno storitev - vsebina tega imenika je odvisna od nameščenih servisov. Ker želimo povezati OPIE in strežnik SSH, poiščemo datoteko sshd in jo odpremo z urejevalnikom besedil (vi) ali s pomočjo Midnight Commanderja (F4). Vrstico @include common-auth (Standard Un*x authentication) nadomestimo z vrsticami:

auth sufficient pam_unix.so (lahko izpustimo, če želimo le OTP)
auth sufficient pam_opie.so
auth required pam_deny.so

S tem smo omogočili uporabo opie na strežniku SSH. Omogočiti moramo še prikaz poziva oziroma odziv s pomočjo spremembe v datoteki /etc/sshd, v kateri moramo spremeniti vrednost ChallengeResponseAuthentication na yes. Zaradi sprememb nastavitev SSH strežnika izvedemo ponovni zagon strežnika /etc/init.d/ssh restart.

Ker smo OPIE že ustrezno pripravili, druge nastavitve niso potrebne, uporabnike (trenutno prijavljene) pa dodajamo s pomočjo že znanega ukaza opiepasswd -c. Koristne namige o uporabi orodja opiepasswd lahko najdete na strani http://www.gsp.com/cgi-bin/man.cgi?section=1&topic=opiepasswd#4.

V CENTRU MOČI

Število naprav in uporabnikov je vse večje. Zato si upravljavci pogosto olajšajo delo s centraliziranim upravljanjem. V praksi to pomeni, da je dostop (na primer do naprave) omogočen šele takrat, ko se ta naprava s centralnim strežnikom dogovori, da je ta dostop dovoljen. Če želi uporabnik z uporabniškim imenom »x« in geslom »y« uporabiti določeno storitev na napravi »z«, mora naprava »z« najprej preveriti, ali ima ta uporabnik sploh pravico dostopa do naprave »z« in kako bo izveden postopek preverjanja. Če je ta dovoljen, naprava »z« na strežnik »w« pošlje poizvedbo, ali geslo »y« ustreza uporabniku »x«. Strežnik načelno pošlje v grobem odgovor DA/NE (natančnejše informacije dajejo posamezne kode), naprava »z« pa se odloči, kako naprej (recimo če geslo ni pravilno, poskusi z morebitno lokalno bazo ali zavrne uporabnika). Tak koncept je primeren zaradi več razlogov. Če želimo določenemu uporabniku začasno onemogočiti dostop do vseh naprav, dostop onemogočimo le na centralnem »w« strežniku. Zaradi različnih varnostnih politik moramo tako uporabniki kot administratorji sistemov periodično menjati gesla. Namesto da bi gesla menjali na vseh napravah, lahko geslo spremenimo le na centralnem strežniku. Centralizacija omogoča tudi dodajanje različnih pravic istemu uporabniškemu imenu, kar pomeni, da lahko isti »identifikacijski« vnos uporabljamo za različne namene (na primer prijava na delovno postajo, VPN dostop …).

V tokratnem besedilu si bomo kot primer ogledali RADIUS (Remote Authentication Dial In User Service). Uporabljamo ga lahko tudi za potrebe tako imenovanih treh A-jev - AAA (Authentication, Authorization in Accounting). Sam RADIUS ni novost, saj njegovi začetki segajo v začetek devetdesetih let. V tem času smo bili priča različnim implementacijam in je zato še vedno aktualen, saj ga lahko uporabljamo za najrazličnejše namene (več na strani http://en.wikipedia.org/wiki/RADIUS).

Funkcionalnost strežnika RADIUS lahko na našem testnem strežniku zagotovimo s pomočjo že pripravljenega FreeRADIUS-a (http://wiki.freeradius.org/FAQ), ki ga namestimo prek spleta z ukazom apt-get install freeradius. Na spletnih straneh pa lahko najdemo tudi različne pakete za druge operacijske sisteme. Za uporabnike Windows je lahko zanimiv Radl (http://www.loriotpro.com/Products/RadiusServer/FreeRadiusServer_EN.php), ki je zelo preprost za konfiguracijo. Če se boste odločili za namestitev FreeRADIUS-a, morate narediti določene ročne spremembe v nastavitvenih datotekah. Ker namestitev in nastavitve strežnika RADIUS presegata obseg tega besedila, opozorimo le na najosnovnejše spremembe, ki jih moramo storiti. Uporabnike, ki so vpisani kot »lokalni« uporabniki na sistemu, najdemo v datoteki users (v imeniku /etc/raddb). Primer vpisa za uporabnika xxx in z geslom callme.123 je videti takole:

xxx Auth-Type := Local, User-Password == »callme.123«
Reply-Message = »Hello, %u«

Posamezne naprave (oziroma programska oprema), ki na našem strežniku RADIUS nastopajo v vlogi poizvedovanja, so odjemalci in jih najdemo v datoteki clients.conf. Če želimo omogočiti odjemalcu z IP-naslovom 192.168.200.2 dostop do strežnika, mora ta vnesti geslo 123456, definiramo pa ga z vrsticami

client 192.168.200.2 {
secret = 123456
shortname = logtest
}

Glede na potrebe je treba spremeniti še določene parametre v datoteki radiusd.conf, saj lahko kot bazo uporabnikov uporabimo zunanji strežnik. V primeru strežnika LDAP bi bil ustrezen vnos videti nekaj podobnega kot naslednje vrstice:

server = »192.168.200.17«
identity = »cn=Manager,dc=mojmikro,dc=si«
password = demo123
basedn = »dc=mojmikro,dc=si«

Vnos uporabniških parametrov na strežnik je seveda le del potrebne konfiguracije. Na napravi, ki bo za preverjanje uporabnika uporabljala strežnik RADIUS, moramo pokazati, da naj za določen uporabniški račun uporablja zunanji strežnik. V našem primeru je datoteka passwd (imenik /etc) videti takole:

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/bin/false
daemon:x:2:2:daemon:/sbin:/bin/false
ftp:x:14:50:FTP User:/var/ftp:/bin/false
nobody:x:99:99:Nobody:/:/bin/false
httpd:x:48:102:Apache:/var/www:/bin/false
ppp:x:100:11::/tmp:/usr/netadm/sh/ppp.sh
….
marko:x:1004:100:Marko Koblar:/home/marko:/bin/bash
…
xxx:x:2011:1002:RADIUS_xxx:/home/xxx:/bin/bash

V zadnji vrstici lahko vidimo, da uporabnika xxx preverjamo prek zunanjega strežnika RADIUS.

MI, LENI ...

Končajmo še z eno možnostjo, ki nam lahko olajša vsakdanje življenje. Če ste naveličani, da n+1-krat na dan vpisujete geslo za prijavo na strežnik prek povezave SSH, lahko »zamuden« postopek skrajšate. Večina uporabnikov okolja Windows uporablja za dostop prek povezave SSH brezplačni Putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/). Putty omogoča tvorjenje profilov, ki jih uporabljamo za posamezne povezave. V našem primeru se želimo prijaviti na strežnik Linux z IP-naslovom 192.168.200.1 kot uporabnik root (v praksi tega raje ne počnite!). Obstoječ profil, v katerem imamo vpisan IP-naslov (Host Name) ter izbran protokol (SSH), izberemo v zavihku »Data« in v polje Auto-login username vpišemo uporabniško ime - root. Putty ima nekoliko nerodno izvedeno shranjevanje, zato se po vnosu uporabniškega imena vrnemo na zavihek Session in izvedemo shranjevanje. Spremenili bomo profil za obstoječo povezavo, zato ob naslednji vzpostavitvi povezave ne bomo dobili opozorila, ki ga sicer dobimo ob vsaki prvi povezavi na strežnik SSH.

Za prijavo na strežnik SSH ne bomo uporabili vpisa gesla (ki se čez čas spremeni in nam lahko zablokira povezavo). Kot varnostni mehanizem bomo uporabili ustrezen ključ, ki ga bomo ustvarili s pomočjo programa Putty key generator. Privzete vrednosti pustimo nespremenjene (SSH-2 RSA) in pritisnemo gumb Generate. Ko izvedemo zahtevano številko naključnih gibov miške, ustvarimo par ključev - zasebnega in javnega. V polje comment lahko vpišemo poljuben komentar, v polji Key passphrase in Confirm pa geslo (na primer m0jm1kr0), s pomočjo katerega bomo izvedli prijavo z novim ključem. Nato shranimo oba ključa (zasebnega s končnico txt, javnega s končnico ppk).

Tako kot običajno se prijavimo na strežnik in izberimo imenik /.ssh ter poiščimo datoteko authorized_keys. Za zadnjo vrstico vpišemo/prekopiramo vsebino datoteke našega javnega ključa (pazite, da je vse v eni vrsti!). V Puttyjevem profilu, ki smo ga ustvarili za povezavo, izberemo zavihek (SSH -Auth) in pokažemo (Browse) na datoteko z zasebnim ključem ter se poskusimo ponovno prijaviti. Namesto običajne prijave kot uporabnik root uporabimo za prijavo ključ in geslo, ki smo ga vnesli pri generiranju ključa. Na prvi pogled je videti, da smo le eno geslo zamenjali z drugim, a to ne drži. Kot dodatni varnostni mehanizem uporabljamo ključ, brez katerega prijava ni mogoča (še vredno pa je nespremenjena prijava za ostala uporabniška imena). V datoteki /etc/ssh/sshd_config spremenimo parameter PasswordAthentication na vrednost »on« in parameter UsePAM na »no«. Po ponovnem zagonu strežnika prijava na strežnik brez ključa ne bo več mogoča (sporočilo Permission denied (publickey …)). A včasih lenoba »prevlada« nad varnostjo, zato lahko podoben mehanizem uporabimo tudi za samodejno prijavo - zagon profila seje in že ste prijavljeni na strežnik, no, vprašanje varnosti pa je že druga pesem ...