Slediti njihovim korakom
Poznajte Svojega Sovražnika: II
Lance Spitnzner
Zadnjic spremenjeno: 18.06.1999
Ta članek je drugi del serije Poznajte Svojega Sovražnika. V prvem članku, Poznajte Svojega Sovražnika: I, smo
obrazložili orodja in metodologijo, ki jo uporablja script kiddie. Če smo natančni, kako iščejo varnostne luknje in kako napadejo.
Tretji del opisuje kaj script kiddie-i počnejo, ko enkrat dobijo koreninski (root) dostop do računalnika.
Natančneje, kako zakrijejo svoje sledi in kaj naredijo nato. V tem, drugem delu, pa bomo opisali kako izslediti njihova dejanja, ter kako
jih spremljati. Prav tako kot v vojski, tudi tukaj hočemo slediti nepridipravu, da izvemo kaj pravzaprav počne. Opisali bomo kaj lahko
in česa ne morete ugotoviti z vašimi sistemskimi dnevniki. Lahko odkrijete, če ste bili žrtev poskusa vdora, za kakšen poskus vdora je šlo,
katera orodja je vdiralec uporabljal in če je bil uspešen v svojih dejanjih. Tukajšnji primeri se osredotočajo na Linux operacijski sistem,
vendar nasploh veljajo za vse Unix operacijske sisteme. Vedite, da ni nacina, s katerim bi sledili vsaki vdiralčevi potezi.
Zaščita dnevnikov
Ta članek ne opisuje Sistemov za zaznavanje vdorov (Intrusion Detection System), saj obstaja veliko kvalitetnih dokumentov na to temo.
Če vas zanimajo sistemi za zaznavanje vdorov, vam priporočam, da si ogledate aplikacije kot sta Network
Flight Recorder ali snort. Ta članek obravnava učenje načinov, ki jih
vdiralci uporabljajo za vdiranje v sisteme. Natančneje, spremljanje kaj počne vdiralec, z opazovanjem sistemskih dnevnikov. Presenečeni
boste, koliko informacij lahko najdete v vaših lastnih sistemskih dnevnikih. Preden pa začnemo govoriti o pregledovanju sistemskih
dnevnikov, najprej povejmo par besed o zaščiti le-teh. Dnevniki so brez vrednosti, če se ne morete zanesti na njihovo integriteto.
Prva stvar, ki jo večina vdiralcev naredi je, da spremenijo dnevnike na računalniku, kamor so vdrli. Obstaja vrsta programov (rootkits),
ki očistijo dnevnike tako, da izbrišejo njihove sledi v njih ali pa spremenijo celotno logiranje (pisanje dnevnikov) tako, da syslogd
(System Logging Daemon) sploh ne zapisuje njihovih dejanj (kot je recimo prirejen syslogd program, ki mu rečemo tudi trojanski konj).
Torej, najprej je potrebno zaščiti dnevnike.
To pomeni, da potrebujete poseben dnevniški strežnik, ki je ločen od strežnika, na katerem bi se lahko vršili napadi. Brezobzirni na to,
kako je vaš sistem zavarovan, se ne morete zanesti na vaše sistemske dnevnike na računalniku, ki je bil tarča napadov. Če ne drugega,
lahko vdiralec preprosto izvede rm -Rf /* in vam popolnoma očisti sistem. To naredi obnovo dnevnikov težko izvedljivo.
Da bi se zaščitili proti temu, logirajte celoten promet na lokalni računalnik ter na drugi, dnevniški strežnik. Priporočam, da za dnevniški
strežnik postavite strežnik samo za ta namen, to pomeni da bo edina stvar, ki jo bo ta strežnik počel, beleženje vsega prometa iz vseh
drugih računalnikov. Če je težava v denarju, lahko enostavno postavite majhen Linux strežnik, ki bi skrbel samo za to funkcijo. Ta strežnik
mora biti zelo dobro zavarovan, imeti mora vse servise zaprte in omogočati samo dostop preko konzole (glej
Oboroževanje Linuxa, na primer). Prav tako poskrbite, da bodo vrata (port) 514 UDP blokirana ali za požarnim zidom. Tako je dnevniški
strežnik zavarovan pred prejemanjem kakršnihkoli drugih, neavtoriziranih dnevniških informacij iz Interneta.
Za tiste, ki ste radi potuhnjeni: jaz rad ponovno prevedem syslogd, da namesto datoteke /etc/syslog.conf, bere datoteko /var/tmp/.conf za
svojo konfiguracijsko datoteko. Tako vdiralec ne ve, kje je pravi dnevnik. To preprosto naredimo z zamenjanjavo niza "/etc/syslog.conf"
v izvorni kodi programa syslogd s katerokoli drugo datoteko. Nato nastavimo konfiguracijsko datoteko tako, da piše lokalni dnevnik in
tudi tistega na dnevniškem strežniku (glej primer). Prepričajte se, da je standardna verzija konfiguracijske
datoteke /etc/syslog.conf vseeno prisotna in piše lokalni dnevnik. Čeprav je ta konfiguracijska datoteka neuporabna, bo zavedla vdiralca,
saj ne bo vedel da se vse njegove poteze beležijo tudi na dnevniški strežnik. Ena izmed možnosti je tudi varnejši način logiranja. Ena
varjanta je, da zamenjate syslogd program z drugim, ki ima večje sposobnosti in več možnosti. Tak program je tudi syslog-ng, ki ga lahko
najdete na http://www.balabit.hu/products/syslog-ng.html.
Večina dnevnikov, ki jih bomo tukaj uporabili, so iz dnevniškega strežnika. Kot sem že omenil, se lahko popolnoma zanesemo na integriteto
teh dnevnikov, saj so na zavarovanem dnevniškem strežniku. Poleg tega, je veliko lažje odkriti vzorce vdora, če vsi sistemi logirajo na
enoten dnevniški strežnik. Hitro lahko pregledamo kaj se dogaja na vseh sistemih iz samo enega vira. Dnevnike, ki se pišejo na lokalnem
računalniku boste želeli pregledati edino takrat, ko jih boste hoteli primerjati z dnevniki na dnevniškem strežniku. Tako lahko enostavno
ugotovite spremembe, ki so bile narejene na lokalnem dnevniku.
Ujemanje vzorcev
S pregledovanjem dnevnikov lahko navadno ugotovite, če ste bili skenirani. Večina script kiddie-v skenira celotna omrežja za določeno
varnostno luknjo. Če v vaših dnevnikih zasledite, da se je na večino računalnikov v omrežju povezal nekdo z enakim naslovom na enaka vrata,
je to verjetno skeniranje za določen exploit. Po navadi ima sovražnik exploit za samo eno ranljivost in pregleduje celotno omrežje zanjo.
Če jo najdejo, jo izkoristijo. Za večino Linux sistemov je TCP Wrapper nameščen privzeto. Torej bi našli večino teh povezav v
/var/log/secure datoteki. Na drugih Unix-ih lahko logiramo vse inetd povezave z zastavico "-t". Tipično skeniranje za določen exploit
izgleda nekako takole. Tukaj nekdo skenira za wu-ftpd ranljivost.
/var/log/secure
Apr 10 13:43:48 mozart in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:51 bach in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:54 hadyen in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:57 vivaldi in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:58 brahms in.ftpd[6613]: connect from 192.168.11.200
Tukaj vidimo, da nekdo z naslovom 192.168.11.200 skenira naše omrežje. Bodite pozorni na zaporedje vsake povezave na strežnik (ni vedno
nujno tako). To je prednost dnevniškega strežnika, saj lahko enostavneje opazujete vzorce dogajanja v vašem omrežju, ker so vsi dnevniki
združeni. Ponavljajoče povezave na vrata 21, ftp, kažejo na to, da je nekdo iskal ranljivost v wu-ftpd strežniku. Pravkar smo ugotovili,
kaj vdiralec išče. Pogosto se skeniranja vršijo tudi v fazah. Nekdo izda IMAPD exploit in takoj boste opazili ogromno IMAPD skeniranj
v vaših dnevnikih. Naslednji mesec boste skenirani na vratih 21, to je ftp. Izvrsten vir informacij o trenutnih exploitih je
http://www.cert.org/advisories. Včasih orodje za skeniranje išče tudi več vrst exploitov
hkrati, tako boste v dnevnikih videli povezave enakega izvora na različna vrata.
Vedite: če ne logirate servisa, ne boste vedeli če ste bili skenirani. Na primer, večina rpc povezav ni logiranih. Vseeno se lahko veliko
servisov enostavno doda v /etc/inetd.conf za logiranje s TCP Wrapperjem. Recimo, lahko dodate vnos v /etc/inetd.conf za NetBus. Lahko
nastavite TCP Wrappers, da varno zavrnejo ter beležijo povezave (glejte Zaznavanje Vdora za več informacij).
Katero orodje?
Včasih lahko brez težav ugotovite, katera orodja so bila uporabljena za skeniranje vašega omrežja. Nekatera osnovna orodja skenirajo za
določen exploit. Eno takih je ftp-scan.c. Če opazite povazeve na enaka vrata na vse računalnike v omrežju, potem
gre verjetno za eno teh orodij. Vendar obstajajo tudi orodja, ki imajo možnosti skeniranja več ranljivosti in šibkosti. Zelo popularni sta
sscan od jsbach-a in Fyodorjev nmap. Izbral
sem ti dve orodji, ker predstavljata dve "kategoriji" skenirnih orodij. Toplo priporočam, da jih uporabite na lastnih omrežjih, morda boste
presenečeni nad rezultati. :)
sscan predstavlja "vsenamensko" script kiddie-vsko skenirno orodje in je verjetno eno najboljših kar jih je. Hitro skenira nework za vrsto
ranljivosti (vključno s cgi-bin). Je zelo prilagodljiv, omogoča tudi dodajanje lastnih navodil za skeniranje novih exploitov. Vi orodju
samo podate naslov omrežja ter masko le-tega, ostalo opravi program sam. Za poganjanje potrebuje privilegije koreninskega uporabnika.
Rezultat skeniranja je zelo lahko berljiv (to ga dela tako popularnega): poda nam jedrnato poročilo o številnih ranljivih servisih. Vse
kar morate storiti je, da poženete sscan na določeno omrežje, uporabite grep, da poiščete besedo "VULN" v rezultatu in nato poženete
exploit. Tukaj je primer sscana, naperjenega proti sistemu mozart (172.17.6.30).
otto #./sscan -o 172.17.6.30
--------------------------<[ * report for host mozart *
<[ tcp port: 80 (http) ]> <[ tcp port: 23 (telnet) ]>
<[ tcp port: 143 (imap) ]> <[ tcp port: 110 (pop-3) ]>
<[ tcp port: 111 (sunrpc) ]> <[ tcp port: 79 (finger) ]>
<[ tcp port: 53 (domain) ]> <[ tcp port: 25 (smtp) ]>
<[ tcp port: 21 (ftp) ]>
--<[ *OS*: mozart: os detected: redhat linux 5.1
mozart: VULN: linux box vulnerable to named overflow.
-<[ *CGI*: 172.17.6.30: tried to redirect a /cgi-bin/phf request.
-<[ *FINGER*: mozart: root: account exists.
--<[ *VULN*: mozart: sendmail will 'expn' accounts for us
--<[ *VULN*: mozart: linux bind/iquery remote buffer overflow
--<[ *VULN*: mozart: linux mountd remote buffer overflow
---------------------------<[ * scan of mozart completed *
Nmap predstavlja orodje "neobdelanih podatkov". Ne pove vam katere ranljivosti so prisotne, temveč vam pove katera vrata so odprta. Nmap
je hitro postal najboljši portscanner z dobrim razlogom. Združuje veliko opcij iz različnih skenerjev v enotno orodje: prepoznava
operacijskega sistema, različna sestava paketkov, UDP in TCP skeniranje, naključno skeniranje itd. Če hočete razbrati rezultate skeniranja
potrebujete vsaj nekaj izkušenj z omrežji. Spodaj je primer uporabe nmapa na istem sistemu kot prej:
otto #nmap -sS -O 172.17.6.30
Starting nmap V. 2.08 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on mozart (172.17.6.30):
Port State Protocol Service
21 open tcp ftp
23 open tcp telnet
25 open tcp smtp
37 open tcp time
53 open tcp domain
70 open tcp gopher
79 open tcp finger
80 open tcp http
109 open tcp pop-2
110 open tcp pop-3
111 open tcp sunrpc
143 open tcp imap2
513 open tcp login
514 open tcp shell
635 open tcp unknown
2049 open tcp nfs
TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)
Remote operating system guess: Linux 2.0.35-36
Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds
S pregledovanjem dnevnikov, lahko ugotovite, kater od teh orodij je bilo uporabljeno proti vam. Najprej pa morate razumeti, kako orodja
delujejo. Skeniranje s sscanom bi bilo zabeleženo takole (to je privzeto skeniranje brez sprememb konfiguracijskih datotek):
/var/log/secure
Apr 14 19:18:56 mozart in.telnetd[11634]: connect from 192.168.11.200
Apr 14 19:18:56 mozart imapd[11635]: connect from 192.168.11.200
Apr 14 19:18:56 mozart in.fingerd[11637]: connect from 192.168.11.200
Apr 14 19:18:56 mozart ipop3d[11638]: connect from 192.168.11.200
Apr 14 19:18:56 mozart in.telnetd[11639]: connect from 192.168.11.200
Apr 14 19:18:56 mozart in.ftpd[11640]: connect from 192.168.11.200
Apr 14 19:19:03 mozart ipop3d[11642]: connect from 192.168.11.200
Apr 14 19:19:03 mozart imapd[11643]: connect from 192.168.11.200
Apr 14 19:19:04 mozart in.fingerd[11646]: connect from 192.168.11.200
Apr 14 19:19:05 mozart in.fingerd[11648]: connect from 192.168.11.200
/var/log/maillog
Apr 14 21:01:58 mozart imapd[11667]: command stream end of file, while reading line user=??? host=[192.168.11.200]
Apr 14 21:01:58 mozart ipop3d[11668]: No such file or directory while reading line user=??? host=[192.168.11.200]
Apr 14 21:02:05 mozart sendmail[11675]: NOQUEUE: [192.168.11.200]: expn root
/var/log/messages
Apr 14 21:03:09 mozart telnetd[11682]: ttloop: peer died: Invalid or incomplete multibyte or wide character
Apr 14 21:03:12 mozart ftpd[11688]: FTP session closed
sscan prav tako išče cgi-bin ranljivosti. Te aktivnosti ne bodo logirane s syslogd-om ampak jih boste našli v datoteki access_log. Odločil
sem se da jih prav tako vključim v ta dokument, za vašo boljšo izobrazbo. :)
/var/log/httpd/access_log
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/phf HTTP/1.0" 302 192
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/Count.cgi HTTP/1.0" 404 170
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/test-cgi HTTP/1.0" 404 169
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/php.cgi HTTP/1.0" 404 168
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/handler HTTP/1.0" 404 168
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/webgais HTTP/1.0" 404 168
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/websendmail HTTP/1.0" 404 172
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/webdist.cgi HTTP/1.0" 404 172
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/faxsurvey HTTP/1.0" 404 170
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/htmlscript HTTP/1.0" 404 171
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/pfdisplay.cgi HTTP/1.0" 404 174
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/perl.exe HTTP/1.0" 404 169
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/wwwboard.pl HTTP/1.0" 404 172
192.168.11.200 - - [14/Apr/1999:16:44:50 -0500] "GET /cgi-bin/ews/ews/architext_query.pl HTTP/1.0" 404 187
192.168.11.200 - - [14/Apr/1999:16:44:50 -0500] "GET /cgi-bin/jj HTTP/1.0" 404 163
Vidite lahko, da je bila na vsa vrata opravljena celotna povezava (SYN, SYN-ACK, ACK), potem pa prekinjena. To je zato, ker sscan uporablja
aplikacijsko plast mrežne strukture za ugotavljanje odprtih servisov. Sscan ne preveri samo če FTP servis JE odprt temveč KATERI FTP daemon
(strežnik) je odprt. Enako velja za servise IMAP, POP itd. To je lepo vidno v sledovih snifferja (vohljača), recimo sniffit-a - orodja, ki
je pogosto uporabljan za sniffanje gesel.
mozart $ cat 172.17.6.30.21-192.168.11.200.7238
220 mozart.example.net FTP server (Version wu-2.4.2-academ[BETA-17](1) Tue Jun 9 10:43:14 EDT 1998) ready.
Kot lahko vidite zgoraj, je bila izvedena celotna povezava na strežnik, da bi ugotovili katera različica strežnika wu-ftpd je odprta. Če
vidite celotne povezave na strežnik v vašem dnevniku imate verjetno opravka z orodjem za iskanje exploitov. Ta orodja izvajajo celotne
povezave, saj je njihov cilj ugotoviti različico strežnika, ki poganja določen servis.
Nmap pa, kot večina skenerjev, preveri ČE je servis odprt, ne pa KATERI strežnik poganja servis. Za ta namen ima nmap poseben nabor opcij,
ki omogočajo izbiro načina izvajanja povezav na strežnik, recimo SYN, FIN, Xmas, Null, itd. Za natančnejši opis naštetih opcij si oglejte
http://www.insecure.org/nmap/nmap_doc.html. Zaradi teh opcij bodo dnevniki na
skeniranem sistemu drugačni od tistih kot pri sscanovem skeniranju. Povezava narejena z "-sT" zastavico naredi celotno povezavo, zato bi
dnevnik izgledal podobno kot pri sscanu. Po privzetih nastavitvah npam skenira več vrat.
/var/log/secure
Apr 14 21:20:50 mozart in.rlogind[11706]: connect from 192.168.11.200
Apr 14 21:20:51 mozart in.fingerd[11708]: connect from 192.168.11.200
Apr 14 21:20:51 mozart ipop2d[11709]: connect from 192.168.11.200
Apr 14 21:20:51 mozart in.rshd[11710]: connect from 192.168.11.200
Apr 14 21:20:51 mozart gn[11711]: connect from 192.168.11.200
Apr 14 21:20:51 mozart gn[11711]: error: cannot execute /usr/sbin/gn: No such file or directory
Apr 14 21:20:52 mozart in.timed[11712]: connect from 192.168.11.200
Apr 14 21:20:52 mozart imapd[11713]: connect from 192.168.11.200
Apr 14 21:20:52 mozart ipop3d[11714]: connect from 192.168.11.200
Apr 14 21:20:52 mozart in.telnetd[11715]: connect from 192.168.11.200
Apr 14 21:20:52 mozart in.ftpd[11716]: connect from 192.168.11.200
Dobro je poznati "-D" (decoy) opcijo. Ta omogoča nmap uporabniku prevarati (spoof) izvorni naslov. Tako lahko v dnevnikih opazite 15 povezav
ki so se zgodile ob istem času, vsaka pa ima drugačen izvorni naslov. Le en naslov je pravi, zelo težko pa je ugotoviti kateri. Zelo pogosto
bodo nmap uporabniki uporabili "-sS" zastavico za skeniranje. To je opcija prikritega (stealth) skeniranja, saj je na ciljni računalnik
poslan samo SYN paket. Če sem oddaljeni računalnik odzove na SYN paket, nmap takoj zapre povezavo z IP zastavico RST. Dnevniki pri takem
skeniranju izgledajo nekako takole (OPOMBA: Samo prvih 5 vnosov je prikazanih).
/var/log/secure
Apr 14 21:25:08 mozart in.rshd[11717]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:08 mozart in.rshd[11717]: connect from unknown
Apr 14 21:25:09 mozart in.timed[11718]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:09 mozart in.timed[11718]: connect from unknown
Apr 14 21:25:09 mozart imapd[11719]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:09 mozart imapd[11719]: connect from unknown
Apr 14 21:25:09 mozart ipop3d[11720]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:09 mozart ipop3d[11720]: connect from unknown
Apr 14 21:25:09 mozart in.rlogind[11722]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:09 mozart in.rlogind[11722]: connect from unknown
Kot vidite, je v dnevniku veliko napak pri povezavah. Ker je SYN-ACK postopek pretrgan pred popolno povezavo, strežnik ne more ugotoviti
izvornega naslova. Dnevniki pokažejo, da ste bili skenirani, žal pa ne veste od koga in kje. Kar je še bolj vznemirljivo je to, da na večini
drugih sistemov (tudi novejša Linux jedra) te povezave in napake niso zabeležene. Citiram Fyodor-ja "... bazirano na vseh 'connection reset
by peer' sporočilih. To je Linux 2.0.XX posebnost -- vsi drugi sistemi bi navidezno ne pokazali ničesar. Ta hrošč (accept() funkcija vrne
vrednost pred zaključkom 3-smernega rokovanja) je bil popravljen."
Nmap vključuje tudi druge nevidne (stealth) opcije, kot recimo "-sF", "-sX", "-sN", kjer so uporabljene druge IP zastavice. Tako izgleda
dnevnik teh skeniranj:
/var/log/secure
Ni dnevnika! Strašno, kaj? Skenirani ste bili, pa sploh niste vedeli. Vsi trije načini skeniranja dajo enak rezultat, tako lahko
popolnoma beležite le "-sT" (popolna povezava) način. Da bi odkrili ta "nevidna" skeniranja, potrebujete druge dnevniške aplikacije, kot
sta tcplogd in ippl. Nekatera komercialna
požarna vrata bi tudi ugotovila in beležila tovrstna skeniranja.
So dobili dostop?
Ko ste enkrat ugotovili, da ste bili skenirani in kaj so iskali, se postavlja naslednje veliko vprašanje: "So prišli noter?". Večina
današnjih remote (na daljavo) exploitov temelji na buffer overflow-ih (znan tudi kot "smashing the stack"). Enostavno rečeno, buffer
overflow je, ko program (običajno strežnik) sprejme več podatkov kot jih pričakuje in zato prepiše kritična območja v spominu. Določena
program se izvrši, običajno dodeli uporabniku koreninski dostop. Za več informacij o buffer overflow-ih si oglejte Aleph1-jev izvrsten
dokument na ftp://ftp.technotronic.com/rfc/phrack49-14.txt.
Normalno lahko identificirate buffer overflow napade v /var/log/messages dnevniku (ali /var/adm/messages za ostale Unix-e), recimo kot je
napad na mountd (Mount Daemon). Podobne stvari boste videli v dnevniku maillog, če je bil napaden IMAPD. Buffer overflow napad bi izgledal
nekako takole:
Apr 14 04:20:51 mozart mountd[6688]: Unauthorized access by NFS client 192.168.11.200.
Apr 14 04:20:51 mozart syslogd: Cannot glue message parts together
Apr 14 04:20:51 mozart mountd[6688]: Blocked attempt of 192.168.11.200 to mount
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P3U3A°^[Í~@3O3A~KÚ°^FÍ~@?Âuô1A°^BÍ~@~EAubëb^V¬fýt^F?At^Këo°0?E~HFyëi^°^B~
I^F?E~IF^D°^F~IF^H°f1U?A~InÍ~@~I^F°^Bf~IF^L°*f~IF^N~MF^L~IF^D1A~IF^P°^P~IF^H°
f?AÍ~@°^A~IF^D°f3^DÍ~@ë^DëLëR1A~IF^D~IF^H°f?AÍ~@~HA°?1ÉÍ~@°??ÁÍ~@°??ÁÍ~@¸.bin@~
I^F¸.sh!@~IF^D1A~HF^G~Iv^H~IF^L°^K~Ió~MN^H~MV^LÍ~@1A°^A1UÍ~@eEyyyyýyPrivet
ADMcrew~P(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(Apr 14 04:20:51
mozart ^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^
E^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E
^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^ H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E
^H(-^E^H(-^E
Ko vidite kaj takega v vašem dnevniku, je verjetno poskusil vdreti v sistem. Težko je ugotoviti, če je bil exploit uspešen. En način kako
to storiti je, da pogledate, če se je zgodila kakšna povezava iz oddaljenega strežnika na vaš sistem. Če so se uspešno prijavili iz
oddaljenega sistema, potem imajo gotovo dostop. Drug način je, da preverite vašo /etc/passwd datoteko za uporabniška imena kot so: "moof",
"rewt", "crak0" ali "w0rm". Ta uporabniška imena imajo UID (User Identification) število 0 (koreninski uporabnik) in so navadno dodana
z pogostimi exploiti. Ko enkrat vdiralec dobi dostop, navadno najprej počistijo dnevnike in nadomestijo syslogd in ostale programe s
trojanskimi konji. Za več informacij si oglejte članek Poznajte Svojega Sovražnika: III. Od te točke dogajanje,
ne boste več dobivali dnevnikov iz vašega sistema, saj je bil zavzet. Kaj storiti nato, je tematika naslednjega članka. :) Do takrat pa
priporočam, da si ogledate http://www.cert.org/nav/recovering.html.
Da bi lažje odkril nepravilnosti v svojih dnevnikih sem napisal skript, ki preiskuje dnevnike namesto mene. Za več informacij o grepping-u
in sortiranju dnevnikov, si oglejte članek Marcusa Ranuma.
Bourne shell skript
Korn shell skript
Povzetek
Dnevniki vam lahko povedo veliko stvari o sovražniku. Vseeno pa morate najprej poskrbeti, da so dnevniki verodostojni. Najlaže to storite
z dnevniškim strežnikom, ki beleži dnevnike iz vseh sistemov. Ko ste enkrat zavarovani, potem lahko ugotavljate lastnosti vzorcev v vaših
dnevnikih. S temi vzorci in vnosi lahko ugotovite kaj vdiralec išče in katera orodja uporablja. Oboroženi s tem znanjem boste znali bolje
zaščititi vaše sisteme.