Linux Box Security part 2 :: Administration

V prvom clanku sme si povedali nejaky uvod do Linux bezpecnosti, napriklad co je to bezpecnostna politika a ako ju vytvorit, preco je dolezite ju dodrziavat, ake su bezpecnostne vrstvy a nejake zakladne utoky, o ktorych si este povieme v dalsom pokracovani serialu.

Tento clanok bude podrobnejsie rozoberat, ako zabezpecit nas system po softwarovej stranke, ukazeme si, ako sa branit pred roznymi utokmi a napriklad aj ako oklamat potencionalneho utocnika tym, ze prenastavime niektore systemove configy.

1.1 Fyzicky Pristup
1.2 Pristup ku Konzole
1.3 Oddelene Particie
1.4 Syslogd
1.5 Logcheck
1.6 Netfilter - Iptables
1.7 Intrusion Detection
1.8 IPPL - IP Protocol Logger

1 ..:: Prevencia ::..

:: 1.1 Fyzicky Pristup
Asi najmenej bezny, ale za to technicky najlahsie vykonatelny utok. Utocnikovi staci len prist k masine a bud ju hodit na chrbat a ujst s nou domov, vytiahnut baterku a resetnut tak BIOS, alebo "nainstalovat" HW keylogger a pod.

Hovoril som, ze HW stranke veci sa venovat nebudem, preto sa tu rozpisovat o nejakom fyzickom zamedzeni pristupu nechcem, nakolko sa tomu ani nerozumiem.

:: 1.2 Pristup ku Konzole
Ak uz ma utocnik fyzicky pristup k masine, ale na jej HW zabezpecenie je jednoducho prikratky (nejake trezory, alebo nieco podobne), staci mu jednoducho nabootovat system s kernel parametrom init=/bin/bash a tym ziskat rootovky shell. Proti tomuto sa da branit dvoma sposobmi.

1. Ak je masina dostatocne fyzicky zabezpecena a nie je mozne resetovat BIOS vytiahnutim baterky, alebo prehodenim jumpera na doske, pomoze tu nastavenie BIOS hesla. Takto sa utocnikovi nepodari ani len nabootovat OS, ak nepozna BIOS heslo, alebo ak neexistuje univerzalne heslo.
2. Ak nie su moznosti na poriadne fyzicke zabezpecenie stroja, budeme si musiet vystacit s boot loader heslom, v nasom pripade Grub heslom.

1.2.1 BIOS
Tu sa rozpisovat nema vyznam. Na kazdej doske sa do biosu ide inym klavesom, ale v principe sa heslo nastavuje rovnako.

1.2.2 Grub heslo
Nastavit heslo pre grub je velmi jednoduche. Otvorime konzolu, napiseme ako root grub-md5-crypt a zadame heslo, ktore chceme nastavit. Vyhodi nam md5 hash, ktory si skopirujeme (staci ho oznacit mysou a neskor pouzit "middle" button na vlozenie), ako root otvorime vo svojom oblubenom editore (v mojom pripade vim) subor /boot/grub/menu.lst a najdeme v nom tuto cast:

riadok password --md5 $1$gLhU0/$aW78kHK1QfV3P2b2znUoe/, zmenime za nas md5 hash, samozrejme dany riadok musime odkomentovat a potom uz nam staci len pridat slovo lock za polozku initrd pri kazdom kerneli, ktory chceme ochranit heslom. Priklad:

Ulozime file a pri dalsom boote linux kernelu, by malo od nas vypytat heslo. Samozrejme takato ochrana sa da lahko obist, takze ak chceme, aby bola este ucinnejsia, musime ju zkombinovat s BIOS heslom a este k tomu v BIOS-e zakazat bootovanie z inych jednotiek, ako je HDD (CD-ROM, floppy, USB..).

:: 1.3 Oddelene Particie
Jednou z najdolezitejsich veci je vytvorenie viacerych particii. Predideme tak 100%-nemu zaplneniu disku a naslednemu znefunkcneniu nejakych sluzieb, prinajhorsom pade systemu, alebo tak dokazeme znemoznit utocnikovi spustat programy na particii, na ktorej ma write pristup, udanim roznych atributov pre jednotlive particie, alebo mame jednoducho len poriadok v systeme.

!! UPOZORNENIE: pred rozdelovanim disku si zalohujte minimalne tie najdolezitejsie data. !!

1.3.1 Atributy pre pripojenie particie
Tu su "security" mount atributy pre particie:

• nodev - zabezpecime nim, ze na danej particii, kde to nepotrebujeme, nebude mozne vytvarat specialne zariadenia. Vhodne je ho pouzit na /home a /var particii.
• noexec - tak ako predchadzajuci priklad, akurat by bolo dost neprakticke to nastavit pre /home particiu, kedze by sme tak na nej znemoznili spustanie scriptov. Tento parameter je vhodny udat napriklad pre /tmp, samozrejme pokial nepotrebuju mat uzivatelia v svojich home adresaroch spustitelne scripty, lepsie je tento atribut povolit.
• nosuid - znemozni spustat setuid a sedgid subory na particii s tymto atributom. Dobre je pouzit ho na /home, /tmp a /var particie, pripadne dalsie, kde ma user write access.
• user - tento atribut umozni pripajat suborove systemy aj obycajnemu uzivatelovi. Na jednej strane automaticky "povoluje" nodev, noexec a nosuid atributy, na strane druhej dava uzivatelovi prilis velke prava, kde to nie je vhodne.. Predstavte si, ze by umountol napriklad /var particiu, kde sa nachadza www root.
• usrquota - povoluje quotu na uzivatelske subory na danom file systeme. Tymto zamedzime zaplnenie particie jednym uzivatelom. Viac o nastaveni quoty si povieme neskor.

Tieto atributy sa uvadzaju v subore /etc/fstab, cize ako root si ho otvorime a dopiseme podla potreby. /etc/fstab s tymito atributmi moze vyzerat nasledovne:

:: 1.4 Syslogd
Je to daemon (sluzba), ktory sa stara o logovanie aplikacii na systeme. Zvycajne je jeho defaultna configuracia plne postacujuca, ale pre nas paranoikov extra security nikdy nie je na skodu.

1.4.1 Typ spravy a Priorita

Facility
Je to podsystem, ktory produkuje danu spravu. Pozname tieto zakladne typy sprav:

• auth, security: sluzi na logovanie autorizacii, tieto spravy sa vacsinou tykaju prihlasovania a odhlasovania.
• authpriv: podobne ako predchadzajuci typ sprav, s tym rozdielom, ze by mali byt z bezpecnostnych dovodov prezeratelne len pre adminisratorov
• cron: spravy z cronu
• daemon: spravy niektorych daemonov
• kern: spravy z kernelu
• lpr: spravy tykajuce sa tlacoveho systemu
• mail: loguje dorucovanie a posielanie posty
• news: logovanie NNTP serveru
• syslog: spravy tykajuce sa samotneho syslog daemona
• user: spravy z uzivatelskych aplikacii
• local0 - local7: spravy definovane samotnym uzivatelom

Existuju este dalsie typy sprav ako: ftp, mark, uucp s ktorymi som sa ale osobne este nestretol.

Priority
Priorita udava dolezitost spravy. Je ich 9 typov a s klesajucou prioritou, syslogd produkuje vacsie mnozstvo sprav.

• debug
• info
• notice
• warn, warning
• err, error
• crit
• alert
• emerg, panic

1.4.2 Konfigurujeme syslog.conf

Tu je priklad fajlu /etc/syslog.conf, v ktorom je ulozena konfiguracia syslog daemonu. V komentaroch je vsetko potrebne info, preto ak treba pozorne si to prestudujte ;)

Este dodam, ze pomlcka pred cestou k log suboru (-/var/log/debug) zaisti, ze sa nebudu vyprazdnovat buffre po kazdom zapise. Tym sa da relativne zvysit vykon servera pri velmi velkych logoch, ale na druhej strane, ak nastane napr vypadok prudu, alebo "padne" system, posledne udalosti sa nemusia zalogovat.

1.4.3 Konfigurujeme syslog.conf - finty fň

Samozrejme defaultne nastaveny syslog je to, s cim moze pocitat pripadny utocnik. Predstavme si situaciu. Utocnik sa dostane na server, ziska root-a, automaticky pomaze, alebo zmeni vsetky udaje v logoch a admin (aspon ten slabsi) ma smolu. Ked ale utocnikovy trosku ztazi pracu, je vacsia sanca, ze ten na nieco zabudne a takto ho admin moze lahsie odhalit.

Cize zakladne pravidlo, a nie len pri configuracii syslogu je, zmenit defaultne nastavenia.

Takze tu je cast configu, ktoru vysvetlim o chvilu.

DISCLAIMER: autor nenesie zodpovednost za zvysenie tlaku pri uvazovani nad jeho nasledujucimi nezmyselnimi riadkami a naslednom pouziti slov z kratkeho slovnika vulgarizmov, na jeho adresu ;)

Teraz si mozno pomyslite, ci to mam v hlave po kope (aneb WTF), ale pokusim sa to objasnit.
Vytvorime si novu zlozku niekde, kde je relativne dost adresarov. Ja som si zvolil umiestnenie v /usr/share, kedze tam je tych adresarov hodne a vytvoril som si tam zlozku I0q. Preco takyto dementny nazov? Pretoze ak niekto da vyhladavat subory a priecinky ktore v nazve obsahuju "log", logicky mu tento priecinok (I0q) nezobrazi. Dalej si tam vytvorime dane fajly, ako to vidime v configuraku. Zase ten isty dovod, pre "dementne" nazvy. No a nakoniec, cely tento "blok" vlozime do /etc/syslog.conf, ale nie hned za jeho posledny riadok, ale nahadzeme medzi ne, aspon 30 - 40 prazdnych riadkov (kludne moze byt aj viac).

Zase sa mozte pytat preco (aneb WTF po druhe)? Je to koli tomu, ze ak chce niekto listovat vacsie fajly, pravdepodobne pouziva more, miesto cat. Teda dame vypisat obsah suboru cez more, prideme na "koniec" suboru a uvidime len prazdne riadky, tak si pomyslime ze snad sa niekto sekol a zavrieme fajl a tympadom mame aspon minimalny backup logov, ktory si utocnik v /etc/syslog.conf nevsimol. Na tych menej skusenych wannabes, ktori sa na server dostali za pomoci nejakeho public exploitu, to moze byt velmi ucinna metoda. Ak aj nie, prinajmensom, tym o nieco zdrzime utocnika :)

Dalsia metoda, ktoru mozme vyuzit, je logovanie na remotnu masinu. Ak nas aj niekto "vyháčkuje", logy su ulozene aj na dalsej masine a tympadom sa bud utocnik zmieri s tym, ze je v prdeli, alebo "uštrikuje" aj tento pocitac.
Tu je dobre logovat na hociaku staru 386ku, ktora je niekde v prdeli zahadzana bordelom, ktora komunikuje s vonkajsim svetom LEN na jednom otvorenom porte, ktory je samozrejme vyuzivany syslog daemonom. Tento port z pravidla byva UDP 514, takze povolime firewall prave na nom a najlepsie bude, ak bude moct komunikovat na danom porte len s jednou konkretnou IP adresou.
Pre paranoikov odporucam hodit do crona script, ktory este dodatocne tieto logy posle na par emailovych adries.

Aby taketo remotne logovanie fungovalo, treba do /etc/services, pridat zaznam o danom porte, samozrejme ak tam este neexistuje (vacsinou existuje).

echo >> "syslog 514/udp"

A este netreba zabudnut na /etc/syslog.conf, kde mozme napisat nieco taketo:

*.* @server.com

:: 1.5 Logcheck

Ak sa logy neprezeraju, je zbytocne mat perfektne naconfigurovany syslogd, pretoze podozrive akcie v logoch si aj tak nevsimneme. Na druhej strane manualne kontrolovanie /var/log je samovrazda, preto pouzijeme tento program, ktory nas upozorni na podozrive udalosti v logoch.

1.5.1 Ako to funguje?

Logcheck pri kazdom spusteni (najlepsie z cronu) analyzuje logy, na zakladne "pravidiel", ktore su definovane v:

Existuju 3 vrstvy pravidiel:

1. ATTACK ALERTS - detekuje pokusy o prienik.
2. SECURITY EVENTS - detekuje zavazne chyby a systemove hlasenia
3. SYSTEM EVENTS - detekuje systemove hlasenia

1.5.1.1 ATTACK ALERTS
V priecinku /etc/logcheck/cracking.d/, su definovane slova a regularne vyrazy, ktore maju za ulohu najst v logoch vsetky pokusy o prienik. Vacsinou sa tam nachadzaju vyrazy, ktore maju nieco spolocne so sietovou aktivitou a s daemonmi, ktore poskytuju nejake internetove sluzby.

/etc/logcheck/cracking.ignore.d/ obsahuje (resp by mal obsahovat, ale defaultne je prazdny) vyrazy, ktore filtruju "falosne spravy" v logoch a tympadom taketo hlasenia ignoruju a my nie sme o nich informovani.

1.5.1.2 SECURITY EVENTS
/etc/logcheck/violations.d/ filtruje logy, ktore obsahuju relativne zavazne chybove a systemove hlasenia, ako je napriklad chybna autorizacia uzivatela vyzadovana nejakym programom, shut down systemu a niektorych daemonov (mysql..), vstup do promiscuitneho rezimu na nejakom sietovom rozhrani a podobne.

Filtruje sa aj chybna autorizacia cez sudo, ktora ma vyhradenu samotnu cast v mail reportoch: Security Events for sudo.

/etc/logcheck/violations.ignore.d/ ma podobnu ulohu ako /etc/logcheck/cracking.ignore.d/, cize tiez vyhodnocuje logy ako neskodna a nezaujimave, ktore su ignorovane

1.5.1.3 SYSTEM EVENTS
Vsetko ostatne co bolo odfiltrovane spominanymi dvoma vrstvami, sa vyhodnocuje v /etc/logcheck/ignore.d.*/ a ak vyhovuje regularnemu vyrazu v tomto priecinku, tak je taketo hlasenie ignorovane a nie sme nan upozorneni mailom.

1.5.2 Instalujeme a configurujeme Logcheck

Instalacia na debiane je jednoducha, staci nam nainstalovat balik logcheck a ak chceme mat aj hotove "filtre", tak budeme potrebovat tiez balik logcheck-database

apt-get install logcheck logcheck-database

Ak vsetko prebehlo v poriadku je potrebne logcheck prisposobit danemu systemu a to mozme spravit vo fajli /etc/logcheck/logcheck.conf. Popiseme si nejake dolezite nastavenia, ale nakoniec je to tam vsetko pekne okomentovane, cize by sa nemal vyskytnut ziaden problem s configuraciou.

REPORTLEVEL="<stupen filtrovania>" - Nastavuje rozne stupne filtrovania, v zavislosti od pouzitia masiny. Moznosti su workstation, server a paranoid. V nasom pripade je vhodne dat server, co je aj defaultna hodnota, ak nie je nic nastavene.

SENDMAILTO="<user alebo emailova adresa>" - Myslim si, ze je to kazdemu jasne. Tu sa nastavuje bud lokalny uzivatel, alebo emailova adresa, kde budu reporty zasielane. Dobre je udat emailovu adresu, ktora sa nenachadza na nasom serveri. Kazdy si dokaze domysliet preco ;)

SUPPORT_CRACKING_IGNORE=<boolean> - Ak nastavime 1, zarucime tym, ze sa budu vykonavat regularne vyrazy oproti logom a tympadom filtrovat vsetky plane poplachy pre vrstvu ATTACK ALERTS.

Dalsi nemenej dolezity fajl je /etc/logcheck/logcheck.logfiles, kde je potrebne pripisat vsetky log subory z /var/log, ktore chceme aby boli kontrolovane. Defaultne obsahuje len /var/log/syslog a /var/log/auth.log, co je plne dostacujuce, kedze /var/log/syslog loguje vsetko okrem auth a authpriv, no samozrejme ak mame nejake extra logovacie fajly ako napriklad /var/log/apache2/{access.log,error.log} a ine, je potrebne ich tam pridat, no netreba potom zabudnut pridat regularne vyrazy do /etc/logcheck/ignore.d.*/apache.

Aby sme docielili, ze nas logcheck bude pravidelne informovat emailom o logoch, je potrebne pridat zaznam do cronu, ak este nie je vytvoreny. Cize do zlozky /etc/cron.d pridame subor logcheck, ktory bude obsahovat:

Tymto zabezpecime, ze sa logcheck spusti, vzdy po reboote systemu a potom kazdu pol hodinu. (defaultne byva nastavene 2 minuty, aj ked nechapem preco).

1.5.3 Vytvarame si vlastne Filtre

Filtre sa vytvaraju za pomoci regularnych vyrazov, ktorym som sice este stale neprisiel na chut, ale tieto su v celku jednoduche.
Dolezite je par dni sledovat email reporty a podla toho zistit, ktore logy tam byt nemusia. Povedzme, ze nam na email pravidelne chodia ako SECURITY EVENTS, taketo riadky, ktore su pre nas nezaujimave:

Oct 28 10:44:04 hackingmachine kernel: ehci_hcd 0000:00:02.1: debug port 1

Takze regularny vyraz by mohol vyzerat takto nejako:

^\w{3} [ :0-9]{11} hackingmachine kernel: ehci_hcd [0-9:.]{13} debug port [0-9]{1}

Poznamka: hackingmachine je nazov mojho hostnamu :)

Tento string potom uz len vlozime do /etc/logcheck/ignore.d.*/kenel a novy filter je na svete. Myslim si, ze jeden priklad bohate staci, nie je to ziadna veda, pokial vie clovek regularne vyrazy. :)

:: 1.6 Netfilter - Iptables

Netfilter framework je vlastne firewall s podporou priamo v jadre (2.4 a vyssie). Okrem zakladneho packetoveho filtru podporuje aj stavove filtrovanie a NAT (network address translation). Na manipulaciu s nim sluzi nastroj iptables.

1.6.1 Iptables a Pravidla

Pakety, ktore prechadzaju cez iptables, su "riadene" sadou pravidiel, ktore urcuju ako nakladat s komunikaciou medzi nami a ostatnym svetom. Tieto pravidla musia obsahovat podmienku, na zakladke ktorej sa vykona urcita akcia. Existuju tri zakladne tabulky, ktore definuju ako spracovat packet:

1. Filter - Filtrovanie packetov
2. NAT - Preklad sietovych adries
3. Mangle - Modifikacia TCP hlaviciek

1.6.1.1 Filter

Je to tabulka, ktora filtruje packety, ktore prechadzaju danym sietovym rozhranim. Obsahuje retaze INPUT, OUTPUT a FORWARD.

• INPUT - Filtruje packety, ktore smeruju na firewall.
• OUTPUT - Filtruje packety, ktore smeruju od firewallu.
• FORWARD - Filtruje packety, ktore len prechadzaju firewallom a smeruju na iny pocitac.

1.6.1.2 NAT

Tato tabulka sa pouziva na preklad vnutornich privatnych adries na verejne adresy.

• PREROUTING - Preklada adresy, ktorych novo vytvorene prichadzajuce packety este nepresli smerovanim.
• POSTROUTING - Preklada adresy, ktorych packety presli smerovanim a opustaju firewall.
• OUTPUT - Preklada adresy, ktorych novo vytvorene odchadzajuce packety este nepresli smerovanim.

1.6.1.3 Mangle

V tejto tabulke sa menia hodnoty TCP QoS (quality of service) packetov, cize modifikuju sa hlavicky typu TOS, TTL a podobne. Mangle pracuje so vsetkymi piatimi definovanymi retazami (PREROUTING, POSTROUTING, OUTPUT, INPUT, FORWARD).

=============

Pre kazde pravidlo je potrebne udat tabulku a retaz. Pokial nie je pre pravidlo udana tabulka, je zvolena defaultna tabulka filter, kedze vacsina pravidiel aj tak suvisi s filtrovanim.

Aby bola problematika firewallovania a pohybu packetu jasnejsia, pozrite si tento diagram:

1.6.2 Iptables a Akcie

Ak packet vyhovuje podmienke, vykona sa nejaka akcia. Niektore akcie "pustaju" packety dalej po retazi, ine ich zastavuju (napr. DROP). Ak packet podmienke nevyhovuje, vykonava sa dalsia podmienka v retazi.

Zakladne akcie su:

• ACCEPT - Packet je povoleny a pokracuje dalej v ceste.
• DROP - Packet je dropnuty a source host nedostane spat reply.
• REJECT - Packet je nepovoleny, a narozdiel od DROP, posle source hostovi IMCP spravu (napriklad ICMP-PORT-UNREACHABLE).
• RETURN - Vrati sa do predchadzajucej retaze a pokracuje podla nasledujuceho pravidla, alebo ak sa nema kam vrati, skoci na koniec retaze.
• QUEUE - Posle packet uzivatelskemu procesu.
• DNAT (Destionation NAT) - Upravuje cielovu adresu, alebo port packetu, este pred smerovanim.
• SNAT (Source NAT) - Upravuje zdrojovu adresu, alebo port packetu, az po dokonceni smerovania.
• MASQUERADE - Upravuje zdrojovu adresu, alebo port packetu, s tym ze zdrojova adresa je rovnaka ako adresa rozhrania firewallu.
• REDIRECT - Zmeni cielovu adresu, alebo cielovy port.
• TARPIT - Otvori TCP spojenie a zvysi dobu odozvy. Pokusy zo zdrojoveho hostu na ukoncenie spojena su ignorovane.
• LOG - Loguje packety.

1.6.3 Konfiguracia Iptables

1.6.3.1 Zakladne parametre pre podmienky

• iptables -p - Urcuje protokol pre pravidlo, alebo packety, ktore maju byt skontrolovane. Napriklad: TCP, UDP, ICMP.
• iptables -s - Urcuje zdroje packetu, ako su napriklad zdrojova adresa/maska, hostname.
• iptables -d - Urcuje ciele packetu: cielova adresa/maska, hostname.
• iptables -i - Nazov zariadenia, cez ktore bol prijaty packet.
• iptables -j - Specifikuje akciu, ktora sa ma vykonat, ak plati podmienka.

1.6.3.2 Zakladne parametre pre manipulaciu s retazami

• iptables -N - Vytvori novu retaz.
• iptables -X - Zmaze prazdnu retaz.
• iptables -P - Nastavi pravidlo.
• iptables -L - Zobrazi vsetky pravidla v retazi.
• iptables -F - vymazat pravidla z řetězu.

1.6.3.3 Zakladne parametre pre manipulaciu s pravidlami

• iptables -A - Prida nove pravidlo na koniec retaze.
• iptables -I - Vlozi nove pravidlo na zadane miesto v retazi.
• iptables -R - Nahradi pravidlo na danej pozicii v retazi.
• iptables -D - Odstrani pravidlo z retaze. Je udane bud poziciou pravidla, alebo jeho vypisanim.

1.6.4 Priklady

1.6.4.1 Zakladne Filtrovanie

Ako prvu vec co by mal nas firewall obsahovat, je standardna politika, ktora by sa mala niest v zmysle: To, co nie je explicitne povolene, je zakazane. Takato politika moze byt, bud zakladna (nic lepsie ma nenapadlo :) ), alebo paranoidna. Zakladna bude robit asi tolko, ze zahodi vsetky prichadzajuce packety:

No a paranoidna, ako si vsetci urcite domysleli, zahodi vsetky aj vstupne aj vystupne packety:

Takato standardna politika, ale moze byt definovana len pre retaze INPUT, FORWARD, OUTPUT, tabulky Filter.

Povolenie niektorych prichadzajucich zakladnych ICMP sprav, by mohlo vyzerat takto:

1. echo-reply
2. destination-unreachable
3. source-quench
4. time-exceeded
5. parameter-problem

Tymto zarucime, ze nam pojde aspon ping a traceroute. Dalej povolime loopback a rozhrania, ktorymi je pocitac pripojeny do doveryhodnej zony. Da sa to dvoma sposobmi:

iptables -A INPUT -i ! eth0 -j ACCEPT

Povoli vstupne packety na rozhrania, ktore nie su eth0 (cize eth1, lo a podobne), alebo mozme definovat pre ktore rozhrania mame povolit vstupne packety, co je lepsie, pretoze prvy priklad povoli VSETKY rozhrania (aj take ktore nechceme mat povolene):

Jedna z najdolezitejsich veci na serveri, je povolenie urcitych sluzieb. Predpokladajme, ze nam bezi mail, FTP, DNS a web server. Ukazeme si povolenie tychto sluzieb dvoma sposobmi:

alebo si mozme definovat vlastnu retaz:

Pri jednoduchych firewallovych pravidlach si vystacime s prvym sposobom, ale pri komplexnejsich pravidlach, je definovanie vlastnych retazi, da sa povedat nevyhnutnost.

1.6.4.2 Stavove Filtrovanie

Netfilter dokaze pri pravidlach zohladnovat aj stavove informacie.

• ESTABLISHED - V tomto spojeni uz prebehli packety oboma smermi, teda pripojenie je aktivne.
• NEW - Prvy packet ktory vytvori pripojenie.
• RELATED - Tento packet suvisi s nejakym existujucim pripojenim, ale nie je jeho sucastou. To mozu byt hlavne ICMP spravy.
• INVALID - Definuje packet, ktory nie je priradeny k ziadnemu aktivnemu spojeniu.

Ukazeme si zopar prikladov, ako vyuzit stavove filtrovanie. Akceptujeme len existujuce spojenie na danom rozhrani:

iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Povolime neobmedzene forwardovanie packetov z vnutornej siete, ale zvonku k nam povolime len existujuce spojenie:

1.6.4.3 NAT

Najcastejsie sa tento sposob pouziva pri vytvoreni maskarady, cize na preposielanie packetov z privatnych adries, von do internetu. MASQUERADE pouzivame hlavne, ak nepozname zdrojovu adresu packetu, v tom pripade sa packety posielaju na rozhranie, cez ktore packety opustaju firewall. Ak zdrojovu adresu pozname, mozme pouzit SNAT.

MASQUERADE - napr preklad konkretnych adries vnutornej siete 10.0.0.0/8, ktore odchadzaju cez rozhranie eth0:

iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE

ak chceme aby boli prelozene vsetky adresy vnutornej siete, cast "-s 10.0.0.0/8" neudavame.

SNAT - prelozime adresy vnutornej siete 10.0.0.0/8, ktore odchadzaju cez rozhranie eth0, ale zdrojova adresa je udana - 192.168.0.1 :

iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j SNAT --to 192.168.0.1

DNAT - toto presmeruje vsetky poziadavky do vnutornej siete na web server, ktory bezi na porte 8080:

iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j DNAT --to 192.168.0.2:8080

:: 1.7 Intrusion Detection

1.7.1 Host Intrusion Detection System

V tejto kapitole si povieme nieco o programoch, ktore kontroluju integritu suborov. Detajlnejsie sa pozrieme na tripwire, vysvetlime si ako funguje a pokusime sa ho aj rozbehat :)

1.7.1.1 Tripwire

Aplikacii, ktore kontroluju, ci boli subory na systeme zmenene je velmi vela, ale v podstate funguju rovnako. Najprv si vytvoria databazu v ktorej su ulozene hlavne hash-e (vacsinou md5) suborov, ale aj ine info ako cas a pod. a po jej vytvoreni, "prebehnu" fajly vo vopred zadefinovanych adresaroch s tym, ze spravia hash daneho fajlu a porovnaju ho s hashom ulozenim v databaze. Nizsie mozme vidiet, ako funguje tripwire, o ktorom si teraz povieme nieco viac:

1.7.1.2 Uvod

Je to jeden z najpouzivanejsich file integrity checker programov, ktore odhaluju ci a kedy boli vykonane zmeny na file systeme. Takto vieme velmi lahko zistit, ci mame votrelca v systeme, alebo ak mame viac adminov na serveri, ci niekto z nich nieco nedomrdal. Ak sa na systeme dialo nieco podozrive tripwire nas vie emailom upozornit na tuto skutocnost a my sa tak mozme pustit do analyzy.

1.7.1.3 Instalacia

Vacsina binarnych distribucii ma v oficialnych repozitaroch uz skompilovany balik tripwire, cize jeho instalacia je otazkou jedneho prikazu. Ak nie, budeme si ho musiet skompilovat. Myslim si, ze instalaciu zvladne kazdy sam :)

Neviem ako je to v inych distrach, ale v debian testing pri instalacii tripwire na vas vyskoci tabulka, kde bude od vas pytat:

• site key
• local key

Zadame teda tieto kluce a niekde si ich ulozime, najlepsie do hlavy.

Ak nam vyhovuju defaultne nastavenia, configuraciu mozme preskocit, ale predsa je dobre do nej aspon nakuknut. Otvorime si teda /etc/tripwire/twcfg.txt a pozrieme ci sme s nastaveniami spokojni. Jedina vec, ktora nas moze zaujimat je DBFILE a MAILNOVIOLATIONS.
V DBFILE je ulozena cesta k databaze, ktora ak je to mozne, mala by byt ulozena na nejakom inom mediu, ako je lokalny disk. Dovody su asi kazdemu jasne :)
MAILNOVIOLATIONS zabezpecuje, ze nam tripwire posle email vzdy, ako sa vykona kontrola systemu. Toto moze byt niekedy dost otravne, preto je mozne tuto moznost vypnut nastavenim hodnoty false.

S configuraciou sme spokojni, mozme sa pustit do vytvarania pravidiel. Nebojte sa experimentovat, aj tak sa k vytvaraniu pravidiel vratite este vela krat, kym s nimi budete uplne spokojni. Subor s pravidlami sa nachadza v /etc/tripwire/twpol.txt

Pravidlo pre tripwire vyzera takto nejako:

Prehlad spominanych premennych:

• SEC_CRIT = $(IgnoreNone)-SHa ; - Kriticke subory, ktore sa nemozu menit
• SEC_BIN = $(ReadOnly) ; - Binarky, ktore by sa nemali menit
• SEC_CONFIG = $(Dynamic) ; - Konfiguracne subory, ktore sa moc nemenia, ale casto sa k nim pristupuje
• SEC_LOG = $(Growing) ; - Subory, do ktorych sa zapisuje velmi vela, ale nemeni sa im vlastnik
• SEC_INVARIANT = +tpug ; - Priecinky, u ktorych by sa nikdy nemal menit vlastnik
• SIG_LOW = 33 ; - Nezaujimave subory, ktore nepotrebuju byt zabezpecene
• SIG_MED = 66 ; - Subory, ktore nepotrebuju az taku velku mieru zabezpecenia
• SIG_HI = 100 ; - Kriticke subory

Na zaciatok je dobre nechat defaultne pravidla (ak teda su vytvorene), alebo ich zmenit len minimalne a az po nejakom case, ked uz vieme kedy a na co nas upozornuje, je dobre ako som vyssie spominal, s nimi experimentovat. Presny navod, ako co nastavit, nema vyznam pisat, pretoze kazdy system je iny. Takze happy pravidlovanie ;)

1.7.1.4 Inicializacia Databazy

Databaza sa vytvara podla pravidiel, ktore sme si zadefinovali vyssie a vytvorime ju nasledovnym prikazom:

# tripwire --init

Po zadani tohto prikazu od nas vypita nas LOKALNY kluc, ktory sme si vytvorili pri instalacii, po jeho zadani sa vytvori databaza. Tento proces moze byt dost zdlhavy, tak je dobre posilnit svoju mysel dobre vychladenym piveckom.

Ak sme zregenerovali mysel, mozme sa pustit do samotnej kontroly, ktoru vykoname nasledovne:

# tripwire --check

Toto tiez moze chvilku trvat, preto je cas na druhu varku piva.
Ak vsetko prebehlo v poriadku, malo by nam vyplut Integrity check complete + vysledok kontroly.

Prezrieme si report nasledovnym prikazom, ak sa jeho nazov uklada v nasledujucom formate ($hostname-rokmesiacden-hodinaminutasekunda.twr):

# twprint -m r --twrfile /var/lib/tripwire/report/$HOSTNAME-`date +%Y%m%d`-*.twr

resp lepsie je vypisat cely nazov, aby sme si nahodou nepozreli subor, ktory sice bol robeny v ten den ako sme checkovali system, ale nebude to prave ten, co potrebujeme.

Ak sme zbadali nieco podozrive, treba podniknut patricne opatrenia, ci uz vyhodit pocitac von oknom, alebo nahradit/preinstalovat dany program.

1.7.1.5 Update Databazy
Aby nam po odstraneni chyb tripwire nevyhadzoval stale tie iste report hlasky, je potrebne po kazdej pripadnej naprave systemu, updatovat databazu.

# tripwire --update --twrfile /var/lib/tripwire/report/<nazov>.twr

Tu nam otvori subor v nejakom textovom editore, ci uz defaultnom (vi), alebo nami zadefinovanom. V tomto subore sa daju "excludovat" subory vymazanim pismena x (priklad: [x] "/etc/nejaky file") a tympadom uz pri dalsej kontrole systemu ich tripwire bude ignorovat. Ak sme dokoncili tuto editaciu, zavrieme textovy editor a znova od nas vypyta lokalny kluc a updatuje databazu.

1.7.1.6 Update Pravidiel

Zmeny pravidiel sa robia v spominanom /etc/tripwire/twpol.txt. Tento subor si po par kontrolach systemu, nejak rozumne upravime, tak aby nas to neotravovalo s kazdou blbostou. Po zapisani do tohto suboru, musime vygenerovat novy /etc/tripwire/tw.pol a nasledne updatovat databazu. Spravime tak nasledovne:

# twadmin --create-polfile -S /etc/tripwire/site.key /etc/tripwire/twpol.txt

Tentokrat od nas vypyta SITE kluc, po jeho zadani updatujeme databazu. Vraj je najlepsie vymazat povodnu a znova ju zinicializovat, takze:

1.7.1.7 Podpisanie Konfiguracie
Textovy subor s konfiguraciou /etc/tripwire/twcfg.txt, musi byt podpisany, aby ho vedel tripwire pri kontrole systemu pouzit. Takze vzdy, ked dany file zmenite, treba spustit:

# twadmin --create-cfgfile -S /etc/profile/site.key /etc/tripwire/twcfg.txt

1.7.1.6 Automaticke Spustanie

Aby sme nemuseli, ako blbi, manualne spustat tripwire a popri tom popijat kopu piva (nie ze by mi to vadilo), je dobre hodit si ho do crona, aby sa spustal kazdy den. V debiane sa tam prida automaticky, v inych distrach mozme do priecinku /etc/cron.daily pridat script tripwire, ktory bude obsahovat toto:

1.7.1.8 Ostatne programy

Tu len spomeniem par dalsich programov, ktore su v principe podobne tripwiru.

AIDE
AFICK
Secure On-the-Fly File Integrity Checker
Nabou

1.7.2 Network Intrusion Detection System

Je to system, ktory dokaze odhalit prienik na zaklade sietovej aktivity, ktora sa vyhodnocuje a potom sa vykona specificka cinnost. To aka cinnost sa ma vykonat, je definovane v pravidlach takychto systemov. Najznamejsi a asi najlepsie configurovatelny je snort, ale nakolko ho nepouzivam, nebudem sa tvarit, ze ho poznam a prikladam len link na manual, ktory sa zaobera jeho instalaciou a configuraciou.

1.7.2.1 Ostatne NIDS programy

PortSentry
Scanlogd

:: 1.8 IPPL - IP Protocol Logger

Sice IPPL svojim sposobom patri medzi NIDS, pisem o nom zvlast, pretoze jeho configuracia si vyzaduje trosku viac priestoru.

Tento program (IP protocols logger), sluzi na logovanie portscanov, teda mozme povedat, ze loguje pokusy (ci uz chybne, alebo uspesne. Zalezi len od configuracie) o pripojenie na porty serveru. Pri pokuse o vytvorenie spojenia zaloguje zdrojovu a cielovu adresu, tak isto ako aj zdrojovy a cielovy port a co je najlepsie, ze dokaze logovat aj pripojenia, ktore nepresli cez iptables.

1.8.1 Konfiguracia

Nasledujuce "parametre" hovoria o tom, ako sa ma IPPL spravat a ktore packety ma logovat/nelogovat.

• runas Debian-ippl - nastavuje pod akym userom (z /etc/passwd) ma byt IPPL spusteny. Standardne je to Debian-ippl, ktory je aj automaticky vytvoreny.
• resolve all [tcp/udp/icmp/all] - chceme povolit DNS lookup?
• ident - overuje spojenia za pomoci ident daemona, cize mozme vediet mena usera, ktory vytvoril spojenie.
• logclosing - loguje ukoncenie TCP spojenia.
• expire 3600 - kedy maju prestat platit DNS data?
• log-in all /var/log/ippl/all [tcp/udp/icmp/all] - loguje protokoly do nami zvoleneho fajlu.
• run icmp tcp [tcp/udp/icmp/all] - udava, ktore protokoly sa budu lugovat.
• portresolve icmp tcp udp [tcp/udp/icmp/all] - zmeni cislo portu daneho protokolu na jeho nazov.
• logformat detailed all [short/normal/detailed] [tcp/udp/icmp/all] - format logovania pre dane protokoly.

Nejake priklady na samotne pravidla, ktore piseme do /etc/ippl.conf:

Teraz si uz len staci podla iptables premysliet, ktore sluzby budu pre ake rozhranie ci IPcky povolene, a podla toho vytvorit pravidla. Samozrejme ako inak, aj tu je dolezite pravidelne kontrolovat logy, aby sme vedeli na com sme.

:: 1.9 Zaver

Ukazali sme si, ako zabezpecit nas system po softwarovej stranke, no kedze proces zabezpecovania je naozaj rozsiahly, buduci clanok bude zamerany na to iste. Budem sa snazit popisat jednotlive sposoby zabezpecenia roznych sluzieb (web, mail, dns, ftp, ssh..) a doplnim informacie, na ktore som zabudol, alebo sa sem uz nezmestili.