a voila, vsetky logy sa ukladaju aj na masinu "loghost".
cize ak niekto hackne vas stroj a zmaze
logy, vy si mozete pozriet logy na tom druhom (dufajme ze nehacknutom) stroji.
pokial je vo vasej lokalite viacej unixovych serverov, ako to byva bezne trebars u
inet providerov, je dobre spravit osve masinu iba na ukladanie systemovych logov.
tato masinka moze byt trebars nejaka vyradena 386ka a mala by byt totalne
zabezpecena - trebars vobec na nu neumiestnit ziadne daemony, proste ziaden
dialkovy pristup, ziadna posta, vobec nic okrem pristupu cez konzolu.
takyto jednoduchy system je nielen dokonale bezpecny, ale navyse je to aj
vcelku prakticke mat vsetky logy pokope, ked sa treba vramci beznych administratorskych
povinnosti hrabat v logoch viacerych masin.

logovanie na konzolu

zmazat subor dokaze hocijaky luzer, moze vas vsak zachranit
vypis na obrazovke, nehovoriac o tom ze je to tiez super prakticke mat vypis na obrazovke.
na linuze sa to docieli trebars riadkom :

*.*		/dev/ttyp12

je pravda ze to nie je tazke odrbat - staci po hacknuti stroja editnut logy,
vymazat stopy a potom spravit nieco ako 'tail -100 messages > /dev/ttyp12'
a root si nic nevsimne. ale povedzme si, v dnesnej dobe ked je inet plny
lamerskych wannabe hackerov ktori sa nekukaju do /etc/syslogd.conf, je dost
pravdepodobne ze si logovanie na konzolu podpriemerny hacker ani nevsimne. bezny luser ktory
vie iba spustit exploit z rootshellu sa da dokonca oklamat aj tak, ze proste
zmenite syslogd.conf tak, aby logoval do nejakeho neobvykleho adresara.
da sa vlastne vo vseobecnosti povedat ze pokial si svoj server prekonfigurujete
na nepoznanie od defaultnych nastaveni, hackera to dokaze riadne zmiast a
dokazete ho okabatit. treba predvidat utok a dopredu sa takto prichystat.
pre hackerov zase plati ze okamzite po hacknuti masiny sa treba popozerat
po /etc adresari a precitat si vsetky dolezite konfiguraky, aby sa ziskala
predstava o danom stroji. predpokladat defaultne konfiguracie sa moze stat
osudnou chybou.

uprava kernelu

na linuxe je moznost upravit kernel tak, aby sa nastavili niektore subory,
ktore nie je mozne mazat ani editovat, je mozne iba appendovat do nich.
tato vecicka je vo forme kernel patchu popisana v poslednom phracku (www.phrack.com)
v daemon9ovom clanku.

syslogd s podporou sifrovania ?

uz dlhsi cas uvazujem nad verziou syslogd, ktory by kryptoval logy
a ukladal ich zasifrovane. nie je to tazke spravit, staci pouzit nejake
bezne DES kniznice trebars.. neverim ze som jediny koho to napadlo, zatial
vsak aspon ja osobne neviem o tom ze by existovala takato verzia syslogd. ludia z cZertu
o tom viac krat premyslali, ale nepodarilo sa mi nazhromazdit take mnozstvo
piva aby som presvedcil dvorneho C-eckara cZertu dusheena aby to spravil
(heh a tymto ho zase k tomu verejne vyzyvam a provokujem).

cistenie

ok, teraz par slov o mazani stop v logoch vyprodukovanych syslogd. pre
hackera je najjednoduchsie otvorit si textovy log v editore a vymazat
"svoje" riadky. avsak castokrat su logy na masine obrovske subory a
ked ich otvorite v nejakom editore typu pico, moze nastat katastrofa.
bol som svedkom takehoto dosraneho utoku na masinu - chalan hackoj stroj,
hned sa vrhol do /var/log aby zmazal stopy, a otvoril messages v picu.
ten subor vsak mal okolo 200Mb a chudak linuxik so 16Mb RAM cely
zamrzol a uz to nevykryl. rano prisiel k nemu root, rebootol ho a zvedavy
sa mrkol do syslogd, kde samozrejme nasiel stopy po tom hackerovi. buum.

na editovanie takychto velkych suborov pouzite grep, sed, awk, take cosi.
cize trebars grep -v evil.hacker.sk messages > temp ; mv temp messages.
pozor, neprepisujte stary subor pomocou 'cp', totiz potom syslogd prestane
do toho suboru zapisovat a musi sa restartnut.

samozrejme nie je problem cely
tento proces zautomatizovat scriptom,
ja som svoj primitivny scriptik zverejnil na arxive (hysteria.sk/arxiv).
cistenie logov je strasna otrava, nastastie na linuxy existuje "patchnuta"
verzia syslogd, ktory sa nachadza tiez na arxive, a ktory sa da tak
nakonfigurovat, aby nelogoval riadky s vopred zadefinovanym stringom.

jedna vec je logy zapisovat, druha vec je samozrejme ich sledovat a citat.
ked mate syslogd nakonfigurovany tak paranoidne ako ja, nie je problem aj na malej
masine mat 1Mb logov denne. obcas ma ukludnuje ked si rano ku kave pustim
pred ocami vypis z logov a pol hodinu na ne meravo civim. pokial vsak
nepatrite k alkoholikom co si rano po opici potrebuju pol hodinu pri kave meravo
civiet na unix logy, mate problem. riesenim je potom nejaky program, ktory
vam z logov povybera "zaujimave" riadky. existuje na to kopu programov,
par som si aj nainstaloval, ale kedze neznasam citanie manualov a trpim
nervozitou, po desiatich minutach bezradneho tapania v tme som ich
hystericky vymazal. napisal som si vlastny scriptik, ktory vy-grep-uje
z logov zaujimave riadky na zaklade stringov ako je trebars "fail", "root",
"changed" a podobne, takyto vycuc za predosly den si davam vzdy o polnoci posielat
e-mailom na pop server.

este jedna vec, trochu o inom. ja mam syslogd nakonfigurovany tak, ze mi
loguje vsetko a este k tomu viacnasobne, avsak absolutne nikam nelogujem
prichodziu a odchodziu postu. podla mna roota nic nie je do toho kam si
uzivatelia posielaju postu a odkial ju dostavaju. protiargument je sice
"ochrana" pred spam mejlami, ale ja na take blbosti kaslem.


tolko k syslogd.

binarne logy

druha kapitola su binarne logy, cize utmp, wtmp, lastlog a acc. utmp
(vacsinou /var/run/utmp) obsahuje informacie o momentalne pripojenych
uzivateloch. wtmp (vacsinou /var/log/wtmp) obsahuje info o tom kto bol
odkial a ako dlho v minulosti pripojeny. lastlog (/var/log/lastlog) obsahuje
zaznam o poslednom pripojeni kazdeho usera. acc (/var/log/acc) obsahuje
zaznam o vsetkych spustenych programoch. subory su binarne, strukturu si
mozete nastudovat v manuali ku kazdemu suboru (t.j. man utmp), na takmer
vsetky platformy vsak uz existuju cistice. este stale dost administratorov
dost veri na tieto binarne logy, vela z nich dokonca ani nevie ze su
editovatelne. preto ked sa vymazete z tychto binarnych logov, oblafne
to nejedneho roota.

falosne stopy

co sa tyka psychologie administratorov, je podla mna ovela lepsie naraficit
falosne stopy, ako kompletne ich zmazat. na to je genialny napriklad
bebetov wtkil, ktory umoznuje pridavat zaznamy do wtmp. zoberte si totiz
takyto pripad - hacknete stroj a zmenite WWW stranku. root pribehne zhrozeny
k serveru a zacne sa vrtat v stroji. pokial ste po sebe dokonale zahladili
vsetky stopy, neda mu to spat a proste bude hladat a hladat a hladat az
kym nebodaj nieco nenajde. preto je z psychologickeho hladiska omnoho lepsie
"spravit" falosne logy do /var/log/wtmp, messages, .bash_history, atd.. vsetko
samozrejme musi krasne spolu sediet. pri takomto hacku kludne nechajte na
serveri svoje "nastroje", pomocne subory, atd. root najde stopy a uspokoji sa,
alebo zacne hladat tym smerom ktorym ho nasmerujete. idealne je napriklad
spravit falosne stopy veduce niekam na opacnu stranu krajiny na nejaku
univerzitu na PCko umiestnene niekde v pocitacovom labaku do ktoreho
maju studenti verejny pristup. root si vymeni zopat e-mailov s bezmocnym
spravcom daneho labaku a mate to v suchu. tiez je dobre nasmerovat
stopy niekam uplne do paze, trebars na nejaku dial-up-ovu adresu k nejakemu
gigantickemu americkemu Inet providerovi (AT&T, america online a pod.)
pokial sa totiz root hacknuteho stroja rozhodne silou mocou vypatrat vynnika a
kontaktovat spomenute spolocnosti, narazi na neprekonatelny mur americkej
podnikovej byrokracie. pokial sa rozhodnete nechat na hacknutej masine
falosny .bash_history log, doporucujem spravit ho tak, aby ste vyzerali ako
totalny lamer :) dajte tam primitivne opakujuce sa prikazy, ktore vas vykreslia
ako totalneho dementa ktory nasiel niekde na webe exploit a chcel ho vyskusat.
totiz je to obrovska vyhoda ked vas protivnik podcenuje.

shell history

ale to uz som sa zamotal do vselijakych ideologii hackerskych metodik, podme
naspat k suchym technickym veciam :) z hladiska bezpecnosti je dobre pre admina
nastavit uzivatelom defaultne logovanie aspon 500 riadkov history. history
totiz moze admin pouzit ako zdroj informacii v pripade utoku. totiz nie kazdy
hacker vie ako vypnut logovanie history. robi sa to najelegantejsie tak, ze
okamzite po lognuti na hacknutu masinu zmenite hodnoty shellovych premennych
tak aby nelogovali history - napriklad v bashi prikazom

export HISTFILE=/dev/null

po pripade zmenou premennych HISTSIZE, alebo HISTFILESIZE. pre blizsie info
sa mrknite do "man bash" alebo "man tcsh".

snooping

celkom zabavny sposob logovania je snooping, cize monitorovat v realnom
case telnetove pristupy na vas server. na linuxe je na to daemon
telnetsnoopd, ktory treba nahradit za klasicky telnetd daemon, tento
genialny program je dokonca standardnou vybavou slackware distribucie, ale
trebars do redhatu ho mozete dohodit jednym rpm-kom. existuje tiez aj
kernelovy modul ktory umoznuje snoopovanie, da sa najst na arxive.

pre hackera predstavuju tieto programy na snoopovanie obrovsky zdroj
srandy. totiz vacsina beznych uzivatelov a kopu adminov ani nevie ze taketo
nastroje existuju. preto ked pocas telnetoveho pristupu nejakeho bezneho
uzivatela mu "skocite" do terminalu a zacnete mu pisat na obrazovku priamo
do jeho shellu, bude vas pokladat za ultra-genialneho hackera a klesne
mu sanka o pol metra od prekvapenia. existuje nespocetne mnozstvo humornych
prihod ktore sa viazu na snoopovanie, moja najoblubenejsia je ked som
skocil do telnetu svojmu priatelovi ktory prave irc-ckoval z unixoveho okna
a chvilu som iba sledoval jeho konverzaciu s jeho byvalou priatelkou. po chvilke
moj kamos oznamil na irc ze si ide na pol hodinku odskocit od pocitaca. vtedy som
sa ujal klavesnice a stihol som sa ukrutne romanticky dat naspat dokopy s tou
jeho byvalou kamoskou tak, aby nevedela o tom ze to pisem ja. vecer ked chudak
nic netusiaci prisiel na internatnu izbu, cakala ho tam cela zhava a nedockava
a privitala velkou pusou, on bol z toho totalka mimo.

ine logy

sakra, slubil som suche technicke informacie, co ? ok, ok. okrem syslogd
a binarnych logov existuje nespocetne dalsich programov ktore zabezpecia
sledovanie unixoveho systemu. osobne oblubujem napriklad cZert sniffer
"czniff", ktory sniffuje traffic na ethernete. da sa nastavit tak, aby
logoval vsetky pripojenia na masinu a sifroval data do suboru. da sa to
pouzit ako super logger, DES zasifrovany a schovany subor vam totiz
ziadny hacker needitne.

za vsetky dalsie programy spomeniem iba program real secure 4.2 od
firmy Internet Security Systems. je to sice komercny a velmi drahy soft,
da sa vsak stiahnut na warez serveroch, alebo prinajhorsom jemne limitovanu
demo verziu z ich domacej stranky (www.iss.net). real secure 4.2 je
komplexny sniffer, ktory analyzuje traffic na sieti a ktory by sa mal
umiestnit hned za routerom (firewallom). real secure dokaze rozpoznat
bezny traffic od hackerskeho utoku. ked napriklad spusti clovek bezny telnet,
je to v pohode. ked ale real secure detekuje 50 telnetovych pripojeni
za minutu, okamzite dokaze spoznat ze sa jedna o utok. takisto dokaze spoznat
vsetky bezne typy externych exploitov, scannovanie hesiel cez verejne sluzby,
desiatky typov denial of service utokov, floodovanie, atd. tieto data
zobrazuje na konzolu a zapisuje do suborov. kedze by mal byt na osve masine,
je nehacknutelny a neviditelny. je genialne konfigurovatelny. a dokaze
nielen hackersky utok detekovat, ale aj nan upozornit (e-mailom, vytocenim
telefonneho cisla napriklad na operator (pager), alebo zaslanim SMS-ky na
GSM teflon), ale dokonca aj dokaze na utok restriktivne reagovat. napriklad
dokaze okamzite po detekcii utoku zakazat vsetky pripojenia z utocnikovej
masine. fakt genialna vec.

real secure dalej umoznuje mat jednu spracovavatelsku stanicu, kam chodia
data a logy z viacerych snifferov. osobne tu vidim do buducnosti moznu
komercnu aktivitu na internetovskom trhu - a to jest internetovsku obdobu civilnej
bezpecnostnej sluzby. predstavujem si to tak, ze by mohla existovat firma ktora
by zamestnavala 24 hodin "straznika", ktory by sedel za pocitacom s real secure,
ktory by tahal logy zo sieti viacerych klientov (banky, vladny sektor, armada..)
a ktory by dokazal okamzite zareagovat na hackersky utok, tak isto ako normalny
straznik v banke sedi a cumi na monitory napojene na bezpecnostne kamery.

no dobre, dobre, to mozno bude v buducnosti, ked bude nevyhnutne pripojit
aj banky a vladny sektor kompletne na internet a ked "hackeri" nebudu
iba unudeni studenti prechlastani z irc sessionov s balikom stiahnutych exploitov.. vratme sa do reality k
nasim amaterskym internet providerom. v kazdom pripade je podla mna aj
v dnesnej dobe potrebny mat system, ktory nastavi pasce pre hackerov, stacia
na to male upravy a drobne scriptiky. klasickym pripadom je spravit si
napriklad falosny phf script (viz arxiv), ktory je castym tercom utokov hackerov, a ktory
dost vela hackerov otestuje pri pokuse o prienik.

access time atributy suborov

bezpecnost internetovskych serverov ide milovymi krokmi do predu, v dnesnej
dobe uz aj na slovensku a v cechach existuju institucie ktore zamestnavaju
odbornikov na bezpecnost a ktorych neodrbete len tak lahko zmazanim stop z
/var/log/wtmp a /var/log/messsages. pri mazani stop treba mysliet na
kazdy sebamensi detajl. prikladom su access time atributy suborov. po utoku
je treba nastavit (viz "man touch") access time atributy vsetkych suborov, ktore
ste precitali alebo prekopirovali. plati to zvlast pokial
utocite na masinu za cielom ziskat informacie ulozene na danom serveri.
administrator sa moze po vasom utoku presvedcit o tom ci ste informacie
ziskali tak, ze si pozrie access time atribut danych suborov (ls -lau) a
takto dokazete zakryt fakt, ze ste si precitali dane informacie.

pre administratora zase access time atributy suborov predstavuju dolezity
zdroj informacii po utoku. pokial ako administrator mate podozrenie ze
bolo hacknute konto nejakeho uzivatela, ale vobec to nevidiet v syslogd alebo
wtmp logoch, skuste sa pozriet na access time suborov v jeho domacom adresari
(trebars .cshrc, .bash_login a pod). pokial wtmp ukazuje ze uzivatel sa naposledy
logol pred tyzdnom, ale jeho .cshrc bol citany vcera v noci, je jasne ze nieco
nie je v poriadku.

outro

pokial si hacker-zaciatocnik, vedz ze vycistenie /var/log/wtmp a /var/log/messages
vobec nie je dokonale zmazanie logov. uvedom si ze na internete uz davno nefunguje
anarchia divokeho zapadu, kde je mozne beztrestne robit bordel. pokial hacknes nejaky stroj, je
mozne ze pouziva nejaku z vyssie popisanych logovacich metod a ze ta admini odhalia a roznosia na kopytach.
pokial si admin, islo mi o to naznacit
ze nie vzdy treba slepo verit logom, a ze pokial potrebujes vieryhodny a stabilny zdroj
informacii o diani na tvojom serveri, v ziadnom pripade nestaci mat defaultne
nastaveny syslogd a binarne logy.

pajka, pajka(at)hysteria.sk