Linux Box Security part 1 :: Introduction

Aj napriek tomu, ze GNU/Linux je sam o sebe relativne bezpecny OS, nic nie je na tolko bezpecne, aby sa to nedalo obist. Preto si povieme o zabezpecovani tohto operacneho systemu hlavne po softwarovej stranke, ale v principe si ukazeme aj ako narusit bezpecnost tohto systemu, ako sa pohybovat po hacknutom systeme a z pohladu admina ako postupovat pri naruseni bezpecnosti. Venovat sa budem distribucii Debian GNU/Linux, ale jednotlive navody mozu byt podobne aj pre ine systemy, hlavne zalozene na Debiane. Do uplnych detajlov zachadzat nebudem, pretoze sa ocakava od citatela aspon zakladna znalost prostredia GNU/linux.

1 ..:: Bezpecnostna politka ::..
Skor ako sa mozme pustit do zabezpecovania systemu, je dolezite si uvedomit na ake ucely bude system pouzivany, ci ako server, alebo ako desktop? A podla toho musime navrhnut bezpecnostnu politiku. V tomto seriali sa budeme zaoberat bezpecnostou linuxu v serverovom prostredi, na kolko desktopy nie su pre utocnika az tak zaujimave, ale samozrejme vylucit sa to neda.

1.1 Navrh bezpecnostnej politky
Vytvorit bezpecnostnu politiku nie je pre system jednoduche a este tazsie je podla nej sa riadit. Ak ju samotni uzivatelia nedodrziavaju, bezpecnost takehoto systemu je prakticky nulova. Preto by takato politika mala byt vynutena zo strany operacneho systemu a specialnych aplikacii (firewall, tcp wrapper, IDS atd) a hlavne zo strany admina (zrusenie accountu pri jej nedodrziavani a pod.).

Asi najzakladnejsia politika spociva v tomto pravidle: To co nie je explicitne povolene, je zakazane., t.j. zakazeme vsetko a povolime len to, co potrebujeme.

Tu je par otazok, ktore by mali byt zodpovedane, predtym ako sa pustime do vytvarania bezpecnostnej politiky:

• Aky stupen bezpecnosti ocakavaju vasi uzivatelia?
• Ake dolezite data su na serveri a aka silna ma byt ochrana pred ich zneuzitim?
• Na kolko doverujete svojim uzivatelom?
• Maju byt vytvorene rozne stupne bezpecnosti pre rozne skupiny uzivatelov?
• Mozte si dovolit downtime pri naruseni bezpecnosti a pri naslednom rieseni a odstranovani problemu?

No a samotna bezpecnostna politika moze vyzerat napriklad aj takto:

1. To co nie je explicitne povolene, je zakazane
2. Pouzivanie hesiel obsahujucich minimalne velke, male pismena a cislice
3. Zmenu vsetkych hesiel aspon raz za 3-6 mesiacov
4. Nepridelovanie uzivatelom a aplikaciam vacsie prava ako potrebuju pre svoju cinnost
5. Prenastavenie sluzieb z defaultnych hodnot na nami zvolene (toto moze zmiast utocnika)
6. Pravidelna zaloha dat a aktualizacia softwaru ako aj celeho systemu

Platia este aj dalsie pravidla, ktorymi by sme sa v ulohe admina mali riadit, a jedno z najdolezitejsich je, byt dobre chraneni pred vlastnymi uzivatelmi z vnutornej siete, kedze taketo utoky byvaju najcastejsie, pretoze su aj lahsie zrealizovatelne.

Samozrejme bezpecnost systemu nezalezi len od bezpecnostnej politiky a jej dodrziavanim zo strany usera, ale zalezi aj od admina a tychto siestich krokov, ktore musia byt splnene pre dosiahnutie co najvyssej moznej bezpecnosti:

1. Prevencia - ochrana pred roznymi hrozbami
2. Kontrola systemu - pravidelne zistovanie ci doslo k naruseniu bezpecnosti
3. Detekcia - odhalenie slabiny systemu, alebo samotneho narusenia bezpecnosti
4. Analyza - zistit akym sposobom doslo k naruseniu bezpecnosti
5. Naprava - odstranovanie skod sposobenych narusenim bezpecnosti
6. Protiopatrenia - zistit co bolo pricinou narusenia bezpecnosti

1.1.1 Prevencia
Spociva hlavne v opatreniach, ktore bole prijate na zvysenie bezpecnosti. V prvom rade to je vypracovanie dobrej bezpecnostnej politiky, samozrejme zalezi to aj od HW a SW zabezpecenia siete, od skusenosti admina a podobne.

1.1.2 Kontrola
Tu je nutne nezaspat na vavrinoch a nemysliet si, ze ked raz nieco zabezpecime uz sa o to netreba starat. Po opatreniach, ktore sme prijali je nutna denno-denna kontrola systemu, a hladanie naznakov utoku. Tu patri hlavne prezeranie logov, kontrola zmenenych a novovytvorenych aplikacii/scriptov, monitorovanie online uzivatelov atd.. Ak sa samozrejme nic podozrive nedeje, neznamena to ze sa naozaj nic nedeje!

1.1.3 Detekcia
Ak sme pri kontrole systemu narazili na nieco podozrive, teda uz je jasne ze mame "votrelca" v systeme, hlavne netreba spanikarit, pretoze mozme narobit este vacsiu skodu ako utocnik. Dolezite je podozrenia si este raz overit a potom prijat konkretne opatrenia.

1.1.4 Analyza
Ako som povedal v predchadzajucom bode, panika nam nijako nepomoze. V klude treba odpojit kable zo sietovky, nevypinat ziadne sluzby a pustit sa do analyzi. Analyza je zvycajne komplexna cinnost, ktora zabere vela casu, ale je nevyhnutna, predsa chceme vediet, co alebo kto narusil bezpecnost systemu. Zase nam tu pomozu vypisy z logov.

1.1.5 Naprava
Ak uz sme zistili, kde sa vyskytol problem mozme sa pustit do opravy systemu. Ako prve je treba odstranit alebo aktualizovat vsetky chybne, alebo utocnikom zmenene aplikacie. To ake aplikacie boli zmenene zistime checksum-om. Na toto nam sluzi napriklad tripwire, alebo aide o ktorych si povieme viac v dalsich clankoch. Ak je jedina moznost aktualizacie systemu cez internet, cize sme stale vystaveny nebezpecenstvu, mali by sme sa prepnut do jednopouzivatelskeho rezimu, runlevel 2.

1.1.6 Protiopatrenia
Ak sme odstranili chyby, ktore viedli k naruseniu bezpecnosti, musime zabezpecit aby sa rovnake chyby uz nevyskytli. Takze reorganizacia bezpecnostnej politiky a zavedenie novych opatreni su na mieste.

Tento cyklus sa pravidelne opakuje, pretoze povedat si, ze nas system je maximalne bezpecny je pri najmensom nezmysel. Neskor si povieme o tychto bodoch este raz, ale v praktickych prikladoch s pouzitim rozneho softwaru a roznych metod.

2 ..:: Bezpecnostne vrstvy ::..

2.1 Uzivatelska uroven
Do tejto kategorie patri koncovy uzivatel, ktory pouziva system za istym ucelom. A od toho aky je ten ucel, zavisi cela bezpecnost systemu, kedze uzivatel je najslabsi clanok bezpecnostnej vrstvy systemu. Hlavnym dovod mozu byt najma skusenost s pouzivanim systemu a nevedomost. Preto je najdolezitejsie poznat svojich uzivatelov delit ich do skupin a kazdej skupine priradovat ine prava.

2.2 Aplikacna uroven
Aplikacia na to, aby bola bezpecna potrebuje splnat 2 hlavne kriteria:

1. Vonkajsie spravanie - toto spravanie by malo zodpovedat spravaniu podla manualu (uzivatelska prirucka)
2. Vnutorne spravanie - vlastna implementacia

Najcastejsou chybou pri programovani co sa tyka bezpecnosti je zle alebo dokonca ziadne osetrenie uzivatelskeho vstupu. Tato chyba moze viest k zapisu mimo pridelenu pamat, co moze sposobit spustenie externeho kodu, alebo dokonca aj pad systemu.

2.2.1 Prava v UNIX like systemoch
Kedze su unixy teda aj linux, multi uzivatelske operacne systemy, je nutne zabezpecit pre kazdeho uzivatela prava, aby nedoslo k situacii, kedy by jeden user mohol citat/prepisovat/spustat programy a dokumenty ineho usera, ku ktorym by za normalnych okolnosti nemal mat pristup. Tieto prava sa prideluju aplikaciam a priecinkom, s ktorymi potom user moze pracovat podla toho pre koho boli prava nastavene. Prava sa nastavuju pre uzivatela, skupinu uzivatelov alebo pre vsetkych a maju priznaky pre citanie, zapisovanie a spustanie.

Z bezpecnostneho hladiska je velmi dolezite, ze ak ma subor nastaveny priznak pre spustanie, spusta sa s takymi pravami ake ma nastavene uzivatel. Teda ak uzivatel tommyhot spusti /bin/bash ten sa nespusti s pravami root-a, ale spusti sa s pravami tommyhot.

Nanestastie existuju vynimky, kde ak normalny uzivatel spusti aplikaciu, ktora potrebuje prava root-a, automaticky sa tato aplikacia spusti prave s pravami uzivatela root, alebo skupiny ktora je vlastnikom aplikacie. Taketo aplikacie maju nastavene priznaky setuid alebo/a setgid a typickym prikladom je /usr/bin/passwd ktory zapisuje do suboru /etc/passwd.

Na jednej strane je taketo riesenie velmi pohodlne, lebo nemusime otravovat root-a aby vykonal danu cinnost za nas, na strane druhej je velmi nebezpecne, pretoze ak je aplikacia zle napisana, resp nie je pisana "with security in mind" moze to viest k naruseniu bezpecnosti systemu, napr. obycajny uzivatel moze ziskat prava root-a.
Setuid a setgid programy by nemali dovolit uzivatelovi vykonat viac ako je nutne, v opacnom pripade mozu nastat problemy (spominane prebratie prava root-a).

2.3 Kernel uroven
Kedze ma kernel vacsie prava ako samotny super user root, bezpecnost na tejto urovni teda priamo suvisi so stabilitou celeho systemu. Inak povedane, ak je chyba na strane kernelu, moze to viest k najzavaznejsim problemom ako pad spustenych procesov a z toho odvijajucim sa poskodenim systemoveho suboru a pod.

3 ..:: Najrozsirenejsie druhy utokov ::..
V dnesnej dobe existuje velmi vela moznosti utokov. Najrozsirenejsie su asi utoky na webove aplikacie, ale tymi sa budeme zaoberat len okrajovo, pretoze samotnemu systemu vacsinou nijak neuskodia. Pre nas dolezitejsie su utoky, pri ktorych je postihnuta bud nejaka sluzba, operacny system, alebo cela siet:

• local/remote exploity
• zneuzitie fyzickeho pristupu k serveru
• DoS a DDoS
• spoofing
• social engeneering a pod.

Tieto a dalsie metody podrobnejsie prebereme neskor, ked sa budeme venovat bezpecnosti systemu z pohladu utocnika.

4 ..:: Zaver ::..
Na dnes by suchej teorie aj stacilo, v buducom clanku sa pozrieme na zebezpecovanie systemu po technickej stranke veci (software) a ukazeme si to vsetko aj na prikladoch s konkretnymi aplikaciami.