incidenti neovlašćenog pristupa

15
Univerzitet Singidunum Fakultet za poslovnu informatiku Seminarski rad Tema:Incidenti neovlašćenog pristupa Mr.Gojko Grubor Dalibor Radovanović II-2/2005

Upload: marija-starcevic

Post on 22-Nov-2014

84 views

Category:

Education


2 download

DESCRIPTION

Incidenti neovlašćenog pristupa

TRANSCRIPT

Page 1: Incidenti neovlašćenog pristupa

Univerzitet Singidunum

Fakultet za poslovnu informatiku

Seminarski rad

Tema:Incidenti neovlašćenog pristupa

Mr.Gojko Grubor Dalibor Radovanović

II-2/2005

Page 2: Incidenti neovlašćenog pristupa

2

Definicija incidenata

Neovlašćen pristup se javlja kada korisnik dobije pristup resursima koji nisu namenjeni

tom korisniku. Neovlašćeni pristup se tipično dobija korišćenjem operativnog sistema ili

usled ranjivosti aplikacije, pribavljanjem korisničkih imena i lozinki, ili društvenog

inžinjeringa. Napadači mogu da dobiju ograničeni pristup kroz jednu ranjivu tačku i da

upotrebe taj pristup da bi napadali druge ranjive tačke, da bi na kraju dobili pristup na

višim nivoima.

Primeri incidenata neovlašćenog pristupa uključuju sledeće:

vršenje daljiskog ugrožavanja root-a nekog servera E-pošte

oštećenje/brisanje Web-servera

nagaĎanje i provaljivanje lozinki

kopiranje baze podataka koja sadrži brojeve kreditnih kartica

pregledanje osetljivih podataka, uključujući i evidencije platnih spiskova i

medicinske informacije, bez ovlašćenja

izvršavanje sniffer programa na radnoj stanici, da bi se uhvatila korisnička

imena i lozinke

korišćenje greške u pogledu dozvole na nekom anonimnom FTP serveru za

distribuciju piratskog sotvera i muzičkih datoteka

biranje brojeva u neosiguranom modemu i dobijanje pristupa internoj mreži

glumljenje nekog rukovodioca, pozivanje službe za pomoć, resetovanje lozinke

E-pošte tog rukovodioca i saznavanje nove lozinke

korišćenje, bez dozvole, prijavljene radne stanice na kojoj nema operatera (ili

automatizovane rande stanice).

Da bi rešavali incidente neovlašćenog pristupa, potrebno je obaviti sledeće postupke:

Konfigurisati IDS softver u mreži i glavnom računaru da bi smo identifikovali i dobili upozorenje o pokušajima da se dobije neovlašćeni pristup. Svaki tip softvera za otkrivanje uljeza može da otkrije napade koje drugi tipovi nisu u stanju da otkriju.

Potrebno je da koristiti centralizovane servere dnevnika rada (log server), tako da se bitne informacije od glavnih računara širom organizacije memorišu na jednoj jedinoj osiguranoj lokaciji.

Potrebno je da ustanoviti procedure po kojima treba postupati kada svi korisnici neke aplikacije, sistema, sigurnosnog domena ili organizacije treba da promene svoje lozinke zato što su lozinke ugrožene. Te procedure treba da se pridržavaju politike u pogledu lozinki date organizacije.

Sa administratorima sistema potrebno je razgovarati o incidentima neovlašćenog pristupa, kako bi oni shvatili svoje uloge u procesu rešavanja incidenata.

Page 3: Incidenti neovlašćenog pristupa

3

Sprečavanje incidenata

Ako se primenjuju opšte smernice o sprečavanju incidenata, broj incidenata neovlašćenog pristupa bi trebalo uspešno da se smanji. Preporučena praksa za smanjenje incidenata jeste korišćenje jake slojevite strategije odbrane, sa nekoliko bezbednosnih slojeva izmeĎu neovlašćenih korisnika i resursa koje oni pokušavaju da eksploatišu.

Postupci za sprečavanje incidenata neovlašćenog pristupa za odreĎene kategorije su:

1. Bezbednost mreže

- Potrebno je da konfigurišemo perimetar mreže, kako bismo odbili sav

dolazni saobraćaj koji nije izričito dozvoljen.

- Potrebno je valjano osigurati sve metode daljinskog pristupa,

uključujući i modeme i VPN-ove. Jedan neosiguran modem može da

omogući neovlašćeni pristup internim sistemima i mrežama. Kada

osiguravamo udaljeni pristup, potrebno je da pažljivo razmotrimo

kredibilnost klijenata; ako su oni izvan kontrole organizacije, onda im

treba dati što je moguće manje pristupa resursima, a njihove postupke

treba pomno pratiti.

- Postaviti sve javno dostupne usluge na osigurane demilitarizovane zone

(DMZ) segmenata mreže. Perimetar mreže onda može da se konfiguriše

tako da spoljašnji glavni računari mogu da uspostave veze samo sa

glavnim računarima na DMZ-i, a ne u internim segmentima mreže.

- Koristiti privatne IP adrese za sve glavne računare na internim

mrežama. Ovo će jako ograničiti mogućnost napadača da uspostave

direktne veze sa internim glavnim računarima.

2. Bezbednost glavnog računara - Potrebno je obavljati redovne procene ranjivosti kako bismo

identifikovali ozbiljne rizike i smanjili rizike do prihvatljivog nivoa.

- Takodje treba da onesposobimo sve nepotrebne usluge na glavnim

računarima. Potrebno je odvojiti kritične usluge, tako da se one

izvršavaju na različitim glavnim računarima. Ako posle toga neki

napadač ugrozi neki glavni računar, neposredni pristup bi trebalo da se

dobije samo do jedne jedine usluge.

- Izvršavati usluge sa najmanje moguće privilegija, kako bismo smanjili

neposredni udar uspešnih exploita..

- Koristiti firewall sa glavnog računara da biste ograničili izloženost

pojedinačnih glavnih računara napadima.

- Ograničiti neovlašćeni fizički pristup prijavljenim sistemima, tako što

će se zahtevati od glavnih računara da automatski blokiraju ekrane koji

miruju i zahtevajte od korisnika da se odjave pre nego što napuste

kancelarije.

- Redovno verifikovati podešenost dozvola za kritične resurse,

uključujući i datoteke sa lozinkama, osetljive baze podataka i javne

Web stranice. Ovaj proces može lako da se automatizuje, tako da

redovno izveštava o promenama u pogledu dozvola.

Page 4: Incidenti neovlašćenog pristupa

4

3. Provera autentičnosti i ovlašćenje

- Potrebno je kreirati politiku u pogledu lozinki koja zahteva da se koriste

složene lozinke koje je teško pogoditi, koja zabranjuje zajedničko

korišćenje/razmenu lozinki i koja upućuje korisnike da koriste različite

lozinke na različitim sistemima, naročito na spoljašnjim glavnim

računarima i aplikacijama.

- Zahtevati dovoljno jaku proveru autentičnosti, naročito za pristup

kritičnim resursima.

- Kreirati standarde provere autentičnosti i ovlašćenja kojih će se

zaposleni i ugovarači pridržavati kada ocenjuju ili razvijaju softver

- Ustanoviti procedure za otvaranje korisničkih naloga. One bi trebalo da

obuhvataju proces odobrenja zahteva za novi nalog, i proces za

periodično onesposobljavanje ili brisanje naloga koji više nisu potrebni.

4. Fizička bezbednost

- Primenite fizičke bezbednosne mere koje ograničavaju pristup kritičnim

resursima.

Page 5: Incidenti neovlašćenog pristupa

5

Detekcija i analiza

Pošto incidenti neovlašćenog pristupa mogu da se javljaju u mnogim oblicima, oni mogu da se detektuju kroz desetine tipova vesnika (prekursora) i indikacija. U Tabeli 6-2, Vesnici neovlašćenog pristupa, data je lista mogućih vesnika napada radi neovlašćenog pristupa, dato je objašnjenje razloga zbog koga bi svaki postupak mogao da se obavi i date su Indikacije neovlašćenog pristupa, lista zlonamernih postupaka, kao što su ugrožavanje root-a, izmena podataka i neovlašćeno korišćenje računa. Za svaki takav postupak, u tabeli je data lista mogućih indikacija tih postupaka. Ove tabele data organizacija može lako da automatizuje tako da one obuhvate vesnike i indikacije koje su specifične za dato okruženje, što bi trebalo da olakša jedan efikasniji i delotvorniji proces rešavanja tih incidenata.

Tabela 6-2. Vesnici neovlašćenog pristupa

Vesnik Odgovor Incidentima neovlašćenog pristupa često

prethodi izviĎačka aktivnost radi mapiranja

glavnih računara i usluga i radi

identifikovanja ranjivih tačaka. Ta

aktivnost može da obuhvata skeniranje

portova, skeniranja glavnih računara,

skeniranja ranjivih tačaka, pingove,

programe za praćenje putanje, transfere

DNS zona, traženje „otisaka prstiju" OS-a i

hvatanje transparenata. Takva aktivnost se

primarno otkriva kroz IDS softver, a

sekundarno - kroz analizu dnevnika rada.

Lica koja rešavaju incidente treba da traže

značajne promene u oblicima izviĎanja - na

primer, iznenadni interes za neki konkretan

broj porta ili glavni računar. Ako ova

aktivnost ukazuje na ranjivu tačku koja bi

mogla da se iskoristi, data organizacija

možda ima vremena da blokira buduće

napade, tako što će smanjiti ranjivost (npr.

krpljenjem glavnog računara,

onesposobljavanjem usluge koja se ne

koristi, menjanjem pravila mrežne barijere).

Javno se objavljuje novi poduhvat

dobijanja neovlašćenog pristupa, a to

predstavlja značajnu opasnost za datu

organizaciju.

Data organizacija treba da ispita taj novi

poduhvat i, ukoliko je moguće, izmeni

bezbednosne kontrole, kako bi svela na

minimum potencijalni udar tog poduhvata na

organizaciju.

Korisnici izveštavaju o mogućim

pokušajima društvenog inžinjeringa -

napadači pokušavaju da ih nadmudre kako

bi otkrili osetljive informacije, kao što su

lozinke, ili ih podstiču da daljinski

preuzimaju ili izvršavaju programe i

priloge datoteka.

Tim koji rešava incidente treba da

korisnicima pošalje bilten sa smernicama o

tome kako da postupaju sa pokušajima

društvenog inžinjeringa. Taj tim bi trebalo

da utvrdi za koje je resurse napadač bio

zainteresovan i da potraži odgovarajuće

vesnike (prekursore) u dnevniku rada zato

što je moguće da je društveni inžinjering

samo deo izviĎanja.

Page 6: Incidenti neovlašćenog pristupa

6

Neko lice ili sistem mogu da uoče neuspeli

pokušaj fizičkog pristupa (npr. neko

autsajder pokušava da otvori zaključana

vrata kablovskog ormana, nepoznati

pojedinac koristi nevažeću značku za

identifikaciju).

Ako je moguće, služba bezbednosti bi

trebalo da pritvori to lice. Trebalo bi da se

utvrdi svrha te aktivnosti, te treba

verifikovati da su fizičke i računarske

bezbednosne kontrole dovoljno jake da

blokiraju očiglednu opasnost. (Napadač, koji

ne može da dobije fizički pristup, može

umesto toga da vrši daljinske napade sa

računara.) Ako je potrebno, trebalo bi ojačati

fizičke i računarske bezbednosne kontrole.

Page 7: Incidenti neovlašćenog pristupa

7

Indikacije neovlašćenog pristupa

Ugrožavanje root-a glavnog računara

Moguće indikacije:

- Postojanje neodobrenih alata vezanih za bezbednost ili exploita

- Neuobičajeni saobraćaj ka i od glavnog (host) računara (npr. napadač

može da koristi glavni računar da napada druge sisteme)

- Menja se konfiguracija sistema, uključujući i

o izmene ili dodavanja procesa/usluga

o neočekivano otvorene portove

o izmene statusa sistema (ponovna pokretanja, zatvaranja)

o izmene politika i podataka vezano za prijavljivanje i ispitivanje

o mrežna kartica je podešena na neselektivni režim (sniffing)

o novi korisnički nalog ili grupa na administrativnom nivou

- Izmene kritičnih datoteka, privilegija, uključujući i izvršne programe,

kernele OS-a, biblioteke sistema i datoteke konfiguracije i podataka

- Neobjašnjeno korišćenje naloga (npr. mrtav nalog koji se koristi, nalog

se koristi sa višestrukih lokacija u isto vreme, neočekivane komande od

nekog konkretnog korisnika, veliki broj blokiranih naloga)

- Značajne promene u očekivanom korišćenju resursa (npr. CPU,

aktivnost mreže, pune log datoteke ili sistemi datoteka)

- Korisnik izveštava o nedostupnosti sistema

- Upozorenja na otkrivanje upada u mrežu i glavni računar

- Nove datoteke i direktorijumi sa neobičnim imenima (npr. binami

znakovi, proredi, razmaci sa tačkama)

- Vrlo neobične log poruke operativnog sistema i aplikacija

- Napadač konktaktira datu organizaciju da kaže da je ugrožen neki glavni

računar

Neovlašćeno menjanje p o d a t a k a ( n p r . oštećenje/brisanje Web

servera)

Moguće indikacije:

- Upozorenja na otkriven upad u mrežu

- Povećano korišćenje resursa

- Korisnik izveštava o izmeni podataka (npr. oštećena/obrisana Web

lokacija)

- Izmene kritičnih datoteka (npr. Web stranica)

- Nove datoteke i direktorijumi sa neobičnim imenima (npr. binarni

znakovi, proredi, razmaci sa tačkama)

- Značajne promene u očekivanom korišćenju resursa (npr. CPU,

aktivnosti mreže, puni dnevnici rada ili sistemi datoteka)

Page 8: Incidenti neovlašćenog pristupa

8

Neovlašćeno korišćenje standardnog korisničkog računa

Moguće indikacije:

- Pokušaji pristupa kritičnim datotekama (npr. datotekama sa lozinkama)

- Neobjašnjivo korišćenje računa (npr. mrtav nalog u upotrebi, nalog se

koristi sa višestrukih lokacija u isto vreme, komande koje su

neočekivane od nekog konkretnog korisnika, veliki broj blokiranih

naloga)

- Stavke u log fajlu web proxy servera pokazuju da su preuzeti hakkerski

alati

Fizički uljez

Moguće indikacije:

- Korisnik izveštava o nedostupnosti sistema

- Menja se status sistema (ponovna pokretanja, zatvaranja)

- Hardver kompletno ili delimično nedostaje (tj. sistem je otvoren i neka

konkretna komponenta je uklonjena)

- Neodobreni novi hardver (npr. napadač povezuje laptop računar za

sniffing paketa na neku mrežu ili modem nekog glavnog računara)

Neovlašćen pristup podacima (npr. bazi podataka sa informacijama o

klijentima, datotekama sa lozinkama

Moguće indikacije:

- Upozorenja na otkrivanje upada vezano za pokušaje da se dobije pristup

podacima preko FTP-a, HTTP-a i drugih protokola

- Pokušaji pristupa kritičnim datotekama otkriveni od strane glavnog

računara

Incidenti neovlašćenog pristupa se razlikuju od ostalih tipova incidenata po tome što se oni često javljaju u nekoliko koraka. Tipično je da će napadači izvesti višestruke izviĎačke aktivnosti da bi mapirali mreže, identifikovali host računare, utvrdili koje operativne sisteme, servise i aplikacije svaki glavni računar izvršava, i našli ranjive tačke. IzviĎanje je postalo toliko trivijalno da organizacije to često ignorišu zbog ograničenja i vremenu i resursima. Medutim, važno je da organizacije preispituju aktivnost izviĎanja, barem minimalno, kako bi stekli osećaj rizika sa kojima se trenutno suočavaju.

Nakon što su završili sa koracima izviĎanja, napadači počinju da preduzimaju mere da bi dobili neovlašćeni pristup sistemima. Mnoge ranjive tačke dopuštaju da se dobije privilegovan pristup u samo jednom koraku, dok druge ranjive tačke omogućavaju samo pristup na korisničkom nivou. Većina napadača traži pristup do sistema na administrativnom nivou, tako da generalno prvo traže ranjive tačke koje mogu da im daju privilegovan pristup. Ako takva ranjiva tačka ne može da se naĎe ili da se uspešno iskoristi, napadači mogu da pokušaju da naĎu i iskoriste ranjive tačke koje mogu da obezbede pristup na korisničkom nivou, a potom da izvrše dodatne napade kako bi podigli nivo pristupa. Pošto za ovaj proces može da bude potreban značajan period vremena, napad može da se otkrije u nekom srednjem koraku, kada je dopušten neki pristup, ali se traži dodatni pristup. Tim za rešavanje incidenata treba da nastoji da

Page 9: Incidenti neovlašćenog pristupa

9

otkrije, vrednuje i zaustavi takve incidente pre nego što se dobije potpuni pristup na administrativnom nivou. Ako napadač dobije pristup na administrativnom nivou, taj napadač će verovatno ugraditi rootkit-ove i ustanoviti „mala vrata" (backdoor) kako bi mogao daljinski da pristupi sistemu sa administrativnim privilegijama u budućnosti.

U toku incidenata neovlašćenog pristupa, često je teško razlikovati nezlonamernu aktivnost od zlonamerne aktivnosti. Indikacije, kao što su zatvaranja, izmene konfiguracije kontrole i izvršne modifikacije su verovatno prouzrokovane rutinskom administracijom sistema, a ne napadima. Ključ za utvrĎivanje izvora aktivnosti je proces upravljanja izmenama u datoj organizaciji. Ako se sistem planira za održavanje, kao što je nadgradnja operativnog sistema, ovu informaciju bi trebalo dati osoblju koje prati i analizira vesnike i indikacije. Kada se otkriju sumnjive indikacije, analitičar može brzo da verifikuje da li su one prouzrokovane planiranom aktivnošću održavanja. Ako proces upravljanja promenama ne uhvati precizno te potrebne informacije, onda će eventualno biti potrebno da lica koja rešavaju incidente kontaktiraju administratore sistema kako bi potvrdili da li su oni obavili tu aktivnost. Zlonamerna aktivnost može da eskalira do kompletnog ugrožavanja root-a do trenutka kada lice koje rešava incidente može da doĎe do administratora sistema.

Kada se odreĎuju prioriteti incidenata neovlašćenog pristupa, može da bude vrlo teško da se utvrdi trenutni i verovatni budući udar datog incidenta. Pošto napadači nastoje da podignu privilegije pristupa na korisničkom nivou do pristupa na administrativnom nivou, tekući incidenti bi potencijalno mogli da rezultiraju pristupom na nivou root-a. Može biti teško da se oceni trenutni udar datog incidenta sve dok se ne obavi detaljna analiza, a može se desiti da je potrebno da se prioritet datog incidenta odredi pre nego što se ta analiza završi. Zbog toga je najbolje utvrditi prioritete incidenata neovlašćenog pristupa na osnovu procene trenutnog udara, uz pretpostavku da će taj udar postati jači bez intervencije. Potom mogu da se odrede vremenski rokovi za svaku kategoriju uticaja na osnovu kritičnosti resursa kojima se pristupilo bez ovlašćenja.

Page 10: Incidenti neovlašćenog pristupa

10

Biranje strategija izolacije od ostatka sistema

Vreme odziva je kritično kada se pokušava da se izoluje neki incident neovlašćenog pristupa. Može biti potrebna detaljna analiza da bi se utvrdilo šta se tačno dogodilo, a u slučaju nekog aktivnog napada, stanje stvari može brzo da se menja. U većini slučajeva, poželjno je da se uradi jedna početna analiza datog incidenta, da se utvrdi prioritet datog incidenta, primene inicijalne mere izolacije, a potom da se obavi dalja analiza kako bi se utvrdilo da li su mere izolacije bile dovoljne. Na primer, možda neće odmah biti očigledno da li je napadač kopirao neku datoteku sistema sa lozinkama. Isključivanje sistema sa mreže dok lica koja rešavaju incidente utvrde da li je datoteka sa lozinkama ugrožena trebalo bi da spreči napadača da koristi te lozinke - pod pretpostavkom da su te lozinke jedinstvene za taj sistem. MeĎutim, to nije slučaj u većini okruženja. Zbog odnosa poverenja izmeĎu sistema i korisnika koji daju iste ili slične lozinke za mnoge sisteme, ukradene lozike se često koriste za pristup drugim sistemima u odnosu na onaj sa koga su one ukradene. Jedan incident može brzo da se proširi sa jednog glavnog računara na desetine glavnih računara za nekoliko minuta.

Lica koja rešavaju incidente hodaju po tankoj žici kada biraju strategije izolacije od ostatka sistema zato što bi, ako pretpostave najgore, ta strategija izolacije mogla da bude da se ugase sve mreže i sistem. Lica koja rešavaju incidente treba da razmatraju umerenija rešenja koja se koncentrišu na smanjenje rizika do stepena koji je izvodljiv, a ne da danima drže ugašeno kompletno okruženje u takvoj situaciji, osim kada je obim zlonamerne aktivnosti toliko velik da je kompletno gašenje osnovano. Trebalo bi da odgovarajuća kombinacija postupaka bude delotvorna u početnoj ili konačnoj izolaciji jednog incidenta neovlašćenog pristupa od ostatka sistema:

Izolovasti ugrožene sisteme. Ovo je najjednostavnija tehnika za izolaciju

jednog incidenta neovlašćenog pristupa – potrebno isključite svaki ugroženi

sistem sa mreže. Ovo sprečava da se ugroženi sistemi dalje ugrožava. MeĎutim,

može biti komplikovano da se identifikuju svi ugroženi sistemi. Napadači često

koriste jedan ugroženi sistem kao izvor napada na druge interne sisteme. Lica

koja rešavaju incidente treba da ispitaju druge sisteme kako bi proverila da li

ima znakova uspešnih napada i da bi i te komponente izolovala od datog

incidenta. Ako je potrebno da se proveri mnogo sistema, mogle bi da se koriste

automatizovane metode, kao što je obavljanje skeniranja portova da se vidi da li

na njima ima backdoors.

Onesposobiti pogođen servis. Ako neki napadač koristi neki konkretni servis da bi dobio neovlašćeni pristup, izolovanje tog incidenta može da uključuje privremeno ili trajno onesposobljavanje tog servisa. Na primer, ako napadač eksploatiše neku FTP ranjivu tačku i neovlašćeni pristup je ograničen na FTP datoteke sa podacima, dati incident bi mogao da se izoluje tako što će se privremeno onesposobiti FTP servis. Ako taj server nenamerno izvršava FTP, onda FTP treba trajno da se onesposobi.

Eliminisati rutu napadača koja dolazi u okruženje. Ako je moguće, sprečiti napadača da pristupi obližnjim resursima koji bi mogli da budu sledeće mete, a da se pritom minimalno poremete usluge ovlašćenim korisnicima.

Page 11: Incidenti neovlašćenog pristupa

11

Onesposobiti korisničke naloge koji su možda korišćeni u napadu. Isti nalozi i lozinke, koji su dobijeni sa jednog sistema, mogu da funkcionišu na drugim sistemima; zbog toga, može biti potrebno da se nalozi onesposobe u celom preduzeću. Lica koja rešavaju incidente treba takoĎe da potraže nove korisničke naloge koje je eventualno napadač kreirao. Naloge treba onesposobiti, a ne samo promeniti lozinke, sve dok lica koja rešavaju incidente ne utvrde koje je postupke napadač izvršio.

Pojačati fizičke mere bezbednosti. Ako neki incident neovlašćenog pristupa obuhvata i povredu fizičke bezbednosti, potrebno je slediti i dodatne strategije izolacije od ostatka sistema. Na primer, ako se sumnja da je neki autsajder dobio pristup prostoriji sa serverom, ne samo da bi prostorija sa serverom trebalo jače da se obezbedi, nego bi i osoblje zaduženo za fizičko obezbeĎenje ili policija trebalo eventualno da pretrese objekat kako bi proverilo da li je uljez još uvek prisutan. Mogu biti osnovane i druge izmene u pogledu obezbeĎenja, ako napadač može da povredi bezbednost u jednom trenutku, mogu da se pojave i druge šanse.

Prikupljanje i postupanje sa dokazima

Kada lica koja rešavaju incidente sumnjaju da je neko dobio neovlašćeni pristup nekom sistemu, trebalo bi da naprave kompletnu rezervnu kopiju tog sistema. Drugi relevantni podaci, uključujući i dnevnike rada glavnih računara i aplikacija, upozorenja na otkrivene upade i dnevnike rada mrežnih barijera, mogu da pruže meĎusobno povezane dokaze o neovlašćenom pristupu. Ako je u toku incidenta došlo do povrede bezbednosti, dodatni dokazi mogu da se dobiju kroz dnevnike rada fizičkog bezbednosnog sistema, sa filmova iz sigurnosnih kamera i iz svedočenja očevidaca. Incidenti neovlašćenog pristupa, za razliku od svih drugih incidenata, najčešće vode do suĎenja, tako da je važno da se postupa po utvrĎenoj proceduri prikupljanja dokaza i postupanja sa njima i da se kontaktira policija ako data situacija pruža osnove za njihovo angažovanje.

Iskorenjavanje i oporavak

Uspešni napadači često ugraĎuju rootkit-ove, koji modifikuju ili zamenjuju desetine ili stotine datoteka. Rootkit-ovi kriju mnogo toga od onoga što oni rade, čime komplikuju identifikaciju u smislu šta je izmenjeno. Zato, ako se čini da je neki napadač dobio pristup root-u nekog sistema, lica koja rešavaju incidente ne mogu da veruju operativnom sistemu. Tipično je najbolje rešenje da se sistem restaurira sa poznate dobre rezervne kopije ili da se ponovo ispočetka instaliraju operativni sistem i aplikacije, a da se potom sistem propisno osigura. TakoĎe se naročito preporučuje menjanje svih lozinki na datom sistemu, a eventualno i na svim sistemima koji imaju odnose poverenja sa sistemom-žrtvom. Neki incidenti neovlašćenog pristupa obuhvataju eksploataciju višestrukih ranjivih tačaka, tako da je važno da lica koja rešavaju incidente identifikuju sve ranjive tačke koje su iskorišćene i da utvrde strategije za korigovanje i smanjenje svake ranjive tačke. Ostale ranjive tačke koje su prisutne takoĎe treba smanjiti, inače se može desiti da ih napadač iskoristi.

Ako napadač dobije samo neki niži novi pristupa u odnosu na administrativni nivo, postupci iskorenjavanja i oporavka bi trebalo da se baziraju na stepenu do koga je napadač dobio pristup. Ranjive tačke koje su iskorišćene da bi se dobio pristup treba

Page 12: Incidenti neovlašćenog pristupa

12

adekvatno da se umanje. Treba obaviti dodatne postupke ako su osnovani, da bi se slabosti sistematično identifikovale i rešavale. Na primer, ako je napadač dobio pristup na nivou korisnika pogodivši neku slabu lozinku, onda da bi trebalo da se izmeni lozinka tog naloga nekom jačom lozinkom, nego i administrator sistema i vlasnik sistema treba da razmotre primenu zahteva za jačim lozinkama. Ako je sistem bio u skladu sa politikama u pogledu lozinki u datoj organizaciji, date organizacija bi trebalo da razmotri revidiranje tih politika vezanih za lozinke.

Page 13: Incidenti neovlašćenog pristupa

13

Obrazac za proveru za rešavanje incidenata neovlašćenog pristupa

Obrazac za proveru prestavlja glavne korake koje treba izvršiti kod rešavanja nekog incidenta neovlašćenog pristupa. Tačan redosled ovih koraka može da varira zavisno od prirode pojedinih incidenata i strategija koje data organizacija odabere za izolovanje incidenata.

Obrazac za proveru za rešavanje incidenata neovlašćenog pristupa1

Postupak Obavljen

Otkrivanje i analiza

1. Utvrditi prioritet rešavanja incidenata na osnovu njihovog

udara na poslovanje

1.1 Identifikovati koji resursi su pogoĎeni i predvideti koji resursi

će biti pogoĎeni

1.2 Proceniti trenutnu tehničku posledicu datog indicenta

1.3 Naći odgovarajuću(e) rubriku(e) u matrici za utvrĎivanje

prioriteta, na osnovu tehničke posledice i pogoĎenih resursa

2. Izvestiti o datom incidentu odgovarajuće interno osoblje i

spoljne organizacije

Izolovanje od ostatka sistema, iskorenjavanje i oporavak

3. Izvršiti inicijalnu izolaciju datog incidenta 4. Prikupiti, sačuvati, osigurati i dokumentovati dokaze 5. Potvrditi izolaciju datog indicenta

5.1 Dalje analizirati dati incident i utvrditi da li je ta izolacija

dovoljna (uključujući i proveru ostalih sistema da se vidi da li

ima znakova upada)

5.2 Primeniti dodatne mere izolacije od ostatka sistema ukoliko je

potrebno

6. Iskoreniti dati incident 6.1 Identifikovati i umanjiti sve ranjive tačke koje su

eksploatisane

6.2 Ukloniti komponente datog incidenta sa sistema 7. Oporaviti sisteme od datog incidenta 7.1 Vratiti pogoĎene sisteme u operativno spremno stanje 7.2 Potvrditi da pogoĎeni sistemi normalno fiinkcionišu

7.3 Ukoliko je potrebno, primeniti dodatno praćenje kako bi se

potražila buduća srodna aktivnost

Aktivnost nakon incidenta

8. Kreirati nastavak izveštaja 9. Održati sastanak o vezi sa naučenim lekcijama

1

Page 14: Incidenti neovlašćenog pristupa

14

Preporuke

Ključne preporuke u vezi sa rešavanjem incidenata neovlašćenog pristupa.

Konfigurisati softver za otkrivanje upada tako da upozorava na pokušaje dobijanja neovlašćenog pristupa.

- Softver za otkrivanje upada baziran u mreži i glavnim računarima (uključujući i softver za proveru integriteta datoteka) je koristan za otkrivanje pokušaja da se dobije neovlašćeni pristup. Svaki tip softvera može da otkrije incidente koje drugi tipovi softvera ne mogu, tako da se naročito preporučuje korišćenje višestrukih tipova softvera za bezbednost računara.

Konfigurisati sve glavne računare za korišćenje centralizovanog logovanja.

- Incidenti se lakše otkrivaju ako se podaci sa svih glavnih računara širom organizacije memorišu u centralizovanoj, bezbednoj lokaciji.

Utvrditi procedure da svi korisnici moraju da menjaju svoje lozinke.

- Ugrožavanje lozinke može da natera datu organizaciju da zahteva od svih

korisnika jedne aplikacije, sistema, ili sigurnosnog domena - ili možda u

celoj datoj organizaciji - da promene svoje lozinke.

Konfigurisati perimetar mreže kako bi odbili sav dolazni saobraćaj koji

nije izričito dozvoljen.

- Time što se tipovi dolaznog saobraćaja ograničavaju, napadači bi trebalo da stignu do manjeg broja meta i trebalo bi da mogu da doĎu do meta koristeći samo označene protokole. Ovo bi trebalo da smanji broj incidenata neovlašćenog pristupa.

Osigurati sve metode daljinskog pristupa, uključujući i modeme i

VPN-ove.

- Neosigurani modemi omogućavaju lako dostupan neovlašćeni pristup internim sistemima i mrežama. Klijenti sa daljinskim pristupom su često izvan kontrole date organizacije, tako da se rizik povećava kada se njima odobrava pristup resursima.

Staviti sve javno dostupne servise na osigurane segmente mreže DMZ.

- Ovo omogućava datoj organizaciji da dozvoli spoljnim glavnim

računarima da započnu povezivanje samo sa glavnim računarima na

DMZ segmentima, a ne sa glavnim računarima na internim segmentima

mreže. Ovo bi trebalo da smanji broj incidenata neovlašćenog pristupa.

Page 15: Incidenti neovlašćenog pristupa

15

Onemogućiti sve nepotrebne servise na glavnim računarima i odvojite kritične usluge.

- Svaki servis koji se izvršava predstavlja još jednu potencijalnu šansu za ugrožavanje sistema. Odvajanje kritičnih servisa je važno zato što, ako napadač ugrozi neki glavni računar koji izvršava neki kritični servis, neposredni pristup bi trebalo da dobije samo do tog jednog servisa.

Koristiti firewall baziran u glavnom računaru kako bi ograničili izlaganje pojedinačnih glavnih računara napadima.

- Rasporedivanje firewall softvera smeštenog u glavnom računaru na glavne računare i njegova konfiguracija tako da se onemogući svaka aktivnost koja nije izričito dozvoljena treba još više da smanji verovatnoću da doĎe do incidenata neovlašćenog pristupa.

Kreirati i primeniti politiku u pogledu lozinki.

- Politika u pogledu lozinki treba da zahteva korišćenje složenih lozinki koje je teško pogoditi i da osigura da metode provere autentičnosti budu dovoljno jake za pristup kritičnim resursima. Verovatnoća je da će se slabe lozinke i lozinke koje se podrazumevaju lako pogoditi ili provaliti, što dovodi do neovlašćenog pristupa.

Pružiti informacije o upravljanju promenama timu za rešavanje

incidenata.

- Indikacije, kao što su gašenja sistema, promene konfiguracije kontrole

i izvršne modifikacije su verovatno prouzrokovane rutinskom

administracijom sistema, a ne napadima. Kada se otkriju takve

indikacije, tim bi trebalo da bude u stanju da koristi informacije o

upravljanju promenama kako bi verifikovao da su te indikacije

prouzrokovane odobrenom aktivnošću.

Odabrati strategiju izolacije od ostatka sistema koje balansiraju smanjenje rizika i održavanje usluga.

- Lica koja rešavaju incidente treba da razmotre umerena rešenja izolacije koja su usmerena na smanjenje rizika onoliko koliko je to izvodljivo, a da se pritom usluge održavaju neugrožene.

Restaurirati ili ponovo instalirati sisteme za koje sumnjate da su pretrpeli

ugrožavanje root-a.

- Često je teško kompletno identifikovati posledice ugrožavanja root-a. Sistem treba da se restaurira sa poznate dobre rezervne kopije ili bi ispočetka trebalo ponovo instalirati operativni sistem i aplikacije. Onda bi trebalo propisno osigurati sistem tako da ne može ponovo da doĎe do incidenta.