© Ivan "VIX" Noris, 2002-2007, 2021, deja-vix.sk, mail: vix (zavinac) deja-vix bodka sk
Posledná zmena: 28/11/2022
Kým začneme, musíte si uvedomiť jednu vec: od okamihu, kedy pripojíte počítač do siete, je tento počítač vystavený potenciálnym útokom. Keďže počítač môže byť nielen bránou do Vašej siete, ale aj bránou do Vášho súkromia, iste budete súhlasiť s tým, že útokom na počítače treba predchádzať a ak sa to dá, úplne im zabrániť.
Bohužiaľ, stopercentná ochrana proti útočníkom neexistuje. Ak nechcete svoj server odstrihnúť od Internetu a zaliať ho do betónu, musíte sa uspokojiť s "reálnejšími" metódami ochrany. Tieto metódy si kladú za cieľ čo najviac minimalizovať riziko útoku na Váš server, jeho rýchlu detekciu v prípade, že bol úspešný a najmä - rýchle a bezpečné zotavenie sa z jeho následkov.
Kľúčové slovo tejto kapitoly je: "bezpečnosť". A bezpečnosť sa zavádza a riadi pomocou bezpečnostnej politiky ("security policy").
Bezpečnostná politika je súbor pravidiel, ktorých dodržiavanie má zaručiť počítačovú bezpečnosť. Keďže bezpečnosť je príliš dôležitá na to, aby bola dobrovoľná, musí byť vynucovaná ("enforced") operačným systémom alebo špeciálnymi aplikáciami a zariadeniami, ktoré musia byť navrhnuté tak, aby sa nedali obísť (proxy servery, firewally, ...)
K tomuto si dovolím poznamenať len toľko: každý informačný systém by mal mať stanovenú jasnú a kompletnú bezpečnostnú politiku, ktorá určuje, kto má aké práva. Počítače na Internete (alebo akejkoľvek inej sieti) sú tiež informačné systémy, ktorých hodnota môže byť oveľa väčšia ako len hodnota "železa"! Preto ak sa pripojíte na Internet, musíte si vypracovať aj bezpečnostnú politiku. Inak sú Vaše údaje v ohrození.
Základné poučky pre tvorbu bezpečnostnej politiky:
Pri tvorbe bezpečnostnej politiky nezabudnite zohľadniť aj to, že absolútna väčšina (80% a viac) útokov pochádza z vnútornej siete, teda zo siete, ktorú obyčajne chránime proti útokom zvonku. Ak je ochrana založená iba na ochrane "hranice" medzi sieťami, ktorú obyčajne zabezpečuje firewall, a neberiete do úvahy chyby v aplikáciách na serveroch (neaktualizujete ich), v skutočnosti sú servery rovnako zraniteľné - z vnútornej strany (a my o tom nevieme, a čo je horšie, ani nás to nenapadne).
Pravdepodobne Vás napadlo "najjednoduchšie riešenie" - vypnúť všetky služby z vonkajšej i vnútornej siete, s výnimkou DNS, WWW a mailu a zakázať používateľom robiť takmer čokoľvek. Správca si mädlí ruky, akú má zabezpečenú mašinu a používatelia nadávajú, pretože nemôžú používať napr. irc, ICQ alebo talk. Správca sa vykašle na správu "svojho zabezpečeného servera", pretože si myslí, že je chránený proti útokom. Karta sa obráti v okamihu, keď niekto server hackne práve pomocou tých troch bežiacich služieb (napríklad vďaka prehnanému sebavedomiu už zmieneného správcu), ktoré svojím počtom môžu poskytovať falošný pocit bezpečia, ak sa nedodržujú ďalšie bezpečnostné opatrenia.
Navyše, proti niektorým útokom sa ťažko bráni práve preto, že ide o služby, ktoré majú byť (musia) prístupné všetkým, napr. už zmienené WWW, DNS a mail.
My sa budeme snažiť o niečo iné. Základný princíp, ktorý v administrácii serverov vyznávam ja, je: obmedziť deštrukčný potenciál používateľov bez súčasného drastického obmedzenia možností využívania služieb. Pokúsime sa obmedziť to, čo je (resp. potenciálne môže byť) naozaj nebezpečné. Pretože sa nikdy nedá dosiahnuť stopercentná bezpečnosť, pri zabezpečovaní systémov sa snažíme o to, aby sme prípadnému útočníkovi čo najviac sťažili prácu (...aby sa na to vykašľal a išiel radšej na pivo).
Keďže na Slovensku sme zvyknutí, že nikto nerobí niečo, čo nemusí, mal by byť určený človek, ktorý bude zodpovedný za nasadenie bezpečnostnej politiky v praxi a za jej dodržiavanie.
A keďže sme na Slovensku, nedá mi nepoznamenať, že tento človek by mal byť za svoju prácu aj dobre platený!
Rozlišujeme nasledujúce pojmy (doc. Hudec, FEI STU, predmet "Bezpečnosť výpočtových systémov"):
Ešte raz pripomínam, že jedným z princípov na dodržanie bezpečnosti akéhokoľvek počítačového systému je: nedať aplikácii alebo používateľovi väčšie práva, ako nevyhnutne potrebuje.
Existuje jedna veľmi reálna hrozba pre každého, kto už nejakú bezpečnostnú politiku na svojom serveri nasadil a teraz naivne dúfa, že je a zostane "navždy nepriestrelná".
"Princip najľahšieho prieniku" hovorí:
Aby sme konečne uviedli aj nejaký príklad, ktorý by názorne vysvetlil tento princíp: majme web server, na ktorom sú firewallované všetky porty okrem "http" a "telnet". Ak na vzdialenú administráciu používate "telnet", ktokoľvek môže získať Vaše heslo odpočúvaním siete (spojenie nie je šifrované). Firewall je v tomto prípade absolútne nedostatočný.
Alebo, menej exotický príklad: firewall filtrujúci porty Vás nijako neochráni pred útokmi prostredníctvom verejných služieb (napr. mail, DNS, web...), ktoré musia byť prístupné z celého Internetu.
Oba príklady zaváňajúce divokými prériami Vás majú upozorniť na to, že pravdepodobne budete mať na svojom serveri aj služby, ktorých bezpečnosť budete musieť riešiť inak ako pomocou firewallu, čo v minulosti (akože) bol a ešte stále (akože) je "univerzálny nástroj proti útokom".
Táto zložka bezpečnosti je striedavo považovaná za primitívnu i podceňovanú. Ak má útočník prístup ku konzole servera, možno jeho situáciu väčšinou prirovnať k zlodejovi, ktorý cez otvorené okno vykráda prízemný byt s pancierovými dverami. Všetky ochrany na úrovni TCP wrappera či firewallu sú irelevantné, rootovské heslo nie je dôležité, pretože rootovský prístup z konzoly možno získať aj bez znalosti hesla.
Kľúčové otázky:
Do tejto kategórie bezpečnosti môžeme zahrnúť ochranu na úrovni jadra operačného systému a kontrolu s použitím systémových aplikácií.
Na začiatok si treba uvedomiť, že Linux, ako každý iný operačný systém, obsahuje chyby a tieto chyby sa skôr či neskôr objavia. Linux sa vyvíja veľmi rýchlo, takže takmer zároveň so zverejnením chyby sa objavuje aj "patch" (na slovo "záplata" si nejako neviem zvyknúť :)).
Každá chyba v jadre môže mať katastrofálne následky: jadro totiž beží v privilegovanom režime a nič na počítači nemá také neobmedzené práva ako práve jadro. V prípade kritickej chyby sa lokálny (a niekedy aj vzdialený) používateľ môže stať rootom. Našťastie, tieto chyby sa už dnes nevyskytujú tak často.
Kľúčové otázky:
Do tejto kategórie by som rád zahrnul všetky procesy, ktoré sa spúšťajú po štarte servera ako démony a obhospodarujú (najmä) sieťové služby. Tieto sa spúšťajú s právami roota a mnohé s právami roota aj bežia, preto sú tiež veľmi citlivé pri plánovaní bezpečnostnej politiky.
Kľúčové otázky:
V prípade, že Váš server funguje ako firewall/brána medzi Internetom a Vašou sieťou, alebo ak plánujete nasadiť samostatný počítač ako firewall (doporučované), rozrastá sa bezpečnostná politika o ďalší rozmer: neochraňujete totiž iba jeden počítač, ale viac počítačov, s rôznymi operačnými systémami (najčastejšie Windows) a Vašou úlohou je zaručiť bezpečnosť pre lokálnu sieť.
Kľúčové otázky:
Obrázok DMZ: (TODO: vysvetliť)
+--------+ +---+
|Internet| -----------> firewall/router -----------> |LAN|
+--------+ | +---+
|
+---------------|----------------+
| | |
v v v
+------------+ +-------------+ +--------------+
| WWW server | | Mail server | | Proxy server | ...
+------------+ +-------------+ +--------------+
Používatelia sú z hľadiska bezpečnosti osobitne dôležité subjekty, pretože ich prístup k aplikáciám a aj samotnému operačnému systému je interaktívny a do veľkej miery neodhadnuteľný.
Už vstup používateľa do systému je veľmi dôležitý. Systém musí vyriešiť dva základné problémy:
Problém autentifikácie sa už tradične rieši pomocou používateľského mena a hesla, nie je to však jediná možnosť. V súčasnosti všetky distribúcie Linuxu (a aj Unixy) používajú koncept PAM ("Pluggable Authentication Modules"), ktorý umožňuje autentifikáciu prakticky pomocou čohokoľvek. V praxi sa používajú napríklad "smart cards" - čipové karty chránené heslom/PINom, alebo autentifikácia pomocou verejného a privátneho kľúča.
Autorizácia používateľa určuje jeho oprávnenia. V Linuxe sa štandardne rieši pomocou používateľského identifikátora (0: root, iné číslo: bežný používateľ) a príslušnosťou používateľa do skupín. Na základe týchto autorizácií je používateľovi umožnený prístup k súborom.
Ak útočník nejakým spôsobom obíde autentifikačné mechanizmy, alebo získa heslo používateľa alebo dokonca roota, získava automaticky oprávnenia tohto používateľa. Ochrana hesla pred zneužitím je preto mimoriadne dôležitá!
Iné operačné systémy (napr. Solaris) využívajú aj koncept rolí. Rola je v podstate skupina používateľov, ktorá môže mať vyššie oprávnenia ako samotní používatelia. Princíp je v tom, že môžeme práva všemocného roota rozdeliť na niekoľko skupín a tiež v tom, že prístup k rolám je kontrolovaný (používateľ sa musí normálne prihlásiť a až potom sa môže prihlásiť na rolu).
Kľúčové otázky:
Každý útok na server je dôsledkom zlej bezpečnostnej politiky. Problém začína oveľa skôr, ako dôjde k samotnému útoku, viditeľný je však až vtedy, keď je vlastne už neskoro. Na vznik bezpečnostného problému sa treba pozerať ako na postupný proces
Prvou (nie poslednou!) etapou "životného cyklu" bezpečnostného problému je prevencia pred útokmi. Spočíva vo vypracovaní a následnom dodržiavaní bezpečnostnej politiky. Môžeme sem zahrnúť aj získavanie nových znalostí správcu alebo bezpečnostného administrátora. Existujú školenia, knihy, ale aj internetové zdroje - sú bohaté, treba ich len správne použiť.
Ak sa Vám podarilo vypracovať bezpečnostnú politiku, v tejto etape sa pravidelne (denne!) snažíte zistiť, či je všetko v poriadku. Hľadáte náznaky útoku: podozrivé hlásenia v logoch, zmenené alebo novovytvorené súbory na disku, podozrivú aktivitu na sieti a podobne. Ak pri kontrole systému nič nenájdete, je to dobre, ale neznamená to, že je všetko v poriadku. Naopak, ak niečo nájdete, máte síce problém, ale - prinajmenšom viete, že ho máte!
Snom každého administrátora je, aby toto obdobie bolo čo najdlhšie :).
Ak ste pri kontrole systému našli čokoľvek podozrivé, treba si výsledky overiť a podozrenia potvrdiť. Vo všeobecnosti platí princíp zdravej dávky paranoje, takže ak nájdete niekoľko podozrivých údajov súčasne, pravdepodobnosť, že útočník prenikol na Váš server, je vyššia.
Ak ste našli neklamné známky "cudzej aktivity", je predovšetkým potrebné:
/var/log" na
disketu alebo aspoň do iného adresára.Ak boli zmenené systémové programy, treba ich nahradiť "čistými" variantmi. Získate ich buď z inštalačných médií alebo z Internetu.
Na zistenie, aký balíček treba nahradiť, Vám poslúži príkaz:
rpm -qf
/cesta/k/suboru"dpkg -S /cesta/k/suboru" (FIXME!)Ak musíte na získanie balíčkov použiť Internet, naďalej sa vystavujete hrozbe ďalšieho útoku počas sťahovania. Výsledkom tohto kroku má byť náhrada alebo vymazanie trójských koňov z disku. Ideálne je robiť všetky operácie v jednopoužívateľskom režime (samozrejme, až po prípadnom skopírovaní súborov z Internetu), kedy nebežia nijaké procesy, nijaké služby a so serverom nemôžu pracovať nijakí používatelia.
V prípade, že ide o chybu v jadre operačného systému, treba toto nahradiť opravenou verziou. Je možné, že ho budete musieť prekompilovať.
V každom prípade treba po obnovení správnych súborov na disku uskutočniť
aktualizáciu na najnovšie verzie balíčkov (Debian: "apt-get update; apt-get
upgrade").
Ak sa Vám podarilo zistiť, cez ktorú sieťovú službu sa útočník dostal na server, a pre túto službu zatiaľ neexistuje aktualizácia, najbezpečnejšie je nespustiť ju až kým nebude k dispozícii aktualizovaná verzia balíčka. Pri moderných distribúciách trvá vydanie opravených balíčkov maximálne niekoľko dní.
Ak prienik súvisel so zneužitím príliš "voľného prístupu" na Váš server, je načase obmedziť prístup pomocou TCP wrappera a/alebo firewallu.
Ak bol prienik spôsobený odchyteným alebo uhádnutým heslom používateľa, intenzívne začnite uvažovať o šifrovaní všetkých služieb, ktoré používajú heslá. Nezabudnite prinútiť používateľa zmeniť si heslo; ak neviete, ktoré heslo útočník zneužil, budete ich musieť zmeniť všetky! (Samozrejme až po tom, ako zavediete šifrovanie - v praxi by ste obe veci mali urobiť prakticky súčasne.)
V prípade, že boli útokom poškodené dáta (súbory), je potrebné ich obnoviť zo zálohy (ktorú určite pravidelne vytvárate!).
A napokon, v prípade, že ani len netušíte, ako sa útočník dostal na server,
ale ste si tým stopercentne istí (napr. zmazané súbory, WWW stránka Vášho
servera hlása "hacked by [insert_some_L4m4nAMe_here]", alebo niekto zmenil
rootovské heslo), zostáva Vám posledná a veľmi nepríjemná možnosť:
preinštalovanie celého systému. Ak sa rozhodnete pre tento variant,
zazálohujte si pred tým obsah minimálne adresárov "/etc",
"/usr/local", "/opt", "/home"
a "/var", najlepšie však kompletný súborový systém. Obnovením
konfiguračných súborov a údajov po preinštalovaní (samozrejme, nesmiete
obnoviť programy! ibá dáta) po preinštalovaní servera si ušetríte ohromné
množstvo práce!
Každý útok má jednu pozitívnu vlastnosť: administrátor sa na ňom nechtiac naučí veci, ktoré sa naučiť chcel, oveľa rýchlejšie. Pri odstraňovaní následkov útoku sa treba zamyslieť aj nad tým, ako zariadiť, aby k rovnakým útokom už nedochádzalo. Ak je problém v démonovi, pouvažujte nad jeho náhradou iným, bezpečnejším variantom.
V tomto okamihu sa celý "životný cyklus" opakuje od začiatku, pretože snaha o bezpečnosť naozaj nikdy nekončí. Kdesi som čítal, že bezpečnosť nie je hodnota typu "0" alebo "1", ale veličina, ktorá vyjadruje mieru bezpečnosti. A tak nemôžete nikdy povedať, že Váš systém je "absolútne bezpečný", mal by však byť stále bezpečnejší.
Na prenikanie do systémov slúži veľa spôsobov, viac či menej čistých. Niektoré si tu teraz opíšeme, spolu s možnými protiopatreniami, alebo aspoň myšlienkami, ktoré Vám pomôžu pri vypracovaní plánu ochrany servera.
Útoky podľa cieľa útočníka môžeme rozdeliť na:
Zlaté pravidlo: pri akomkoľvek útoku zostaňte pokojní a ROZMÝŠĽAJTE. Nerobte unáhlené závery. Za nijakých okolností sa nesnažte útočiť na servery, z ktorých prišiel útok, je totiž takmer celkom isté, že boli hacknuté. Nijaký hacker neútočí na servery z vlastného počítača. Protiopatreniami tohto druhu môžete narobiť viac škody ako osohu.
Tento útok je priamym dôsledkom zlej fyzickej bezpečnosti servera a je najnebezpečnejší v tom, že sa môže ľahko podceniť a ešte ľahšie zneužiť. Jeho následky sú v podstate ľubovoľné.
Pri zneužití prístupu ku konzole môže v zásade dôjsť k dvom útokom:
linux init=/bin/bash, kde "linux" je meno jadra, ktoré sa
má spustiť. Namiesto programu "init" sa spustí
"/bin/bash", čiže interpreter príkazov, a samozrejme,
s rootovskými právami. A ďalej...
Ak bol Váš server vyradený z prevádzky, môžete to jednoducho zistiť tým, že
nebeží :). Čas posledného bootovania servera vypisuje príkaz
"uptime" (ale informácie o ukončení prevádzky a štarte služieb
pri bootovaní sú neprehliadnuteľné aj v logoch):
uptime
9:34pm up 20 min, 1 user, load average: 0.08, 0.11, 0.12
Ukážka informácií v súbore "/var/log/syslog" - všimnite si časy a zodpovedajúce hlásenia. Ide o ukážku z môjho domáceho počítača, ktorý som vypínal o 01:34 a zapínal o 14:30 nasledujúceho dňa:
Mar 23 01:34:40 hudson init: Switching to runlevel: 0 Mar 23 01:34:42 hudson devfsd: devfsd shutdown succeeded Mar 23 01:34:42 hudson devfsd: Stopping devfsd daemon: succeeded Mar 23 01:34:44 hudson httpd: httpd shutdown succeeded Mar 23 01:34:44 hudson postfix: Shutting down postfix: Mar 23 01:34:44 hudson postfix/postfix-script: stopping the Postfix mail system Mar 23 01:34:44 hudson postfix/master[1151]: terminating on signal 15 Mar 23 01:34:44 hudson rc: Stopping postfix: succeeded Mar 23 01:34:44 hudson named[986]: shutting down Mar 23 01:34:44 hudson named[986]: stopping command channel on 127.0.0.1#953 Mar 23 01:34:44 hudson named[986]: no longer listening on 127.0.0.1#53 Mar 23 01:34:44 hudson named[986]: no longer listening on 10.0.0.1#53 Mar 23 01:34:44 hudson named[977]: exiting Mar 23 01:34:44 hudson named: named shutdown succeeded Mar 23 01:34:44 hudson xinetd[1002]: Exiting... Mar 23 01:34:44 hudson xinetd: xinetd shutdown succeeded Mar 23 01:34:45 hudson crond: crond shutdown succeeded Mar 23 01:34:45 hudson sound: Saving mixer settings succeeded Mar 23 01:34:45 hudson dd: 1+0 records in Mar 23 01:34:45 hudson dd: 1+0 records out Mar 23 01:34:45 hudson random: Saving random seed: succeeded Mar 23 01:34:45 hudson kernel: Kernel logging (proc) stopped. Mar 23 01:34:45 hudson kernel: Kernel log daemon terminating. Mar 23 01:34:46 hudson exiting on signal 15 Mar 23 14:30:08 hudson syslogd 1.4.1: restart. Mar 23 14:30:08 hudson kernel: klogd 1.4.1, log source = /proc/kmsg started. Mar 23 14:30:08 hudson kernel: Inspecting /boot/System.map Mar 23 14:30:08 hudson partmon: Checking if partitions have enough free diskspace: Mar 23 14:30:08 hudson kernel: Loaded 15768 symbols from /boot/System.map. Mar 23 14:30:08 hudson kernel: Symbols match kernel version 2.4.20. Mar 23 14:30:08 hudson kernel: Loaded 206 symbols from 10 modules. Mar 23 14:30:08 hudson kernel: Linux version 2.4.20 (root@hudson.marine.sk) . . .
Poznámka: v prípade, že ide o korektné vypnutie servera napr. v prípade výpadku napájania, ktoré ohlásil záložný zdroj, nájdete o tom informáciu v logu.
Ak došlo k zmene nejakých súborov na disku, zachráni Vás iba program, ktorý kontroluje ich integritu. (FIXME: odkaz)
Vhodné opatrenia:
Skenovanie portov nie je vlastne útokom v pravom zmysle slova, ale často
ho predznamenáva, alebo presnejšie - je to indikátor záujmu útočníka o Váš
server. Skenovanie portov, ako názov naznačuje, je operácia, pri ktorej sa
pomocou špecializovaných programov (ja som skúšal "nmap") útočník
pripája na vzdialený (v tomto prípade Váš) počítač s cieľom zistiť, ktoré
sieťové služby na počítači bežia, aké programy ich poskytujú a aké sú ich
čísla verzií (programy na zneužitie chýb programov sú špecifické pre konkrétny
program a jeho verziu, prípadne aj verziu Linuxu). Keďže jednotlivé sieťové
služby počúvajú na štandarných portoch, portscanner sa postupne pripája na
všetky alebo vopred určené porty.
Každé pripojenie na port treba chápať ako požiadavku. Ak démon na počítači prijme požiadavku, zareaguje na ňu - buď odpovie, alebo ju odmietne (TCP wrapper). Každopádne, portscanner si to všimne a okrem informácie o tom, či služba beží alebo nie a či sa mu podarilo vytvoriť spojenie môže vypísať aj ďalšie informácie o démonovi, ktorý službu poskytuje, jeho verzii atď. Nie je na tom nič nezvyčajné, pretože démony sa obyčajne pri pripojení klienta ohlasujú menom a číslom verzie.
Typický príklad: zadajte
telnet localhost 25 [vix@hudson ~]$ telnet localhost 25 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. 220 hudson.marine.sk ESMTP Postfix (1.1.11) (Mandrake Linux)
Ukončite spojenie zadaním "quit" alebo stlačním klasickej telnetovskej
sekvencie "CTRL+]".
Pripojili sme sa na mailový server (port 25) a ako vidíte, dozvedeli sme sa
viac, než by sme čakali. Všimnite si, ako sa Vám predstaví SMTP server
- získali sme informáciu o distribúcii, programe a aj jeho verzii.
V logoch sa objaví približne toto (tu používam výpisy"postfixu"):
Jul 14 13:32:30 hudson postfix/smtpd[1932]: connect from localhost[127.0.0.1] Jul 14 13:32:35 hudson postfix/smtpd[1932]: disconnect from localhost[127.0.0.1]
Ukážka logov ("/var/log/syslog") počas jednoduchého TCP portscanu:
(všimnite si, v akom časovom intervale prichádzajú požiadavky)
Jul 14 13:32:30 hudson xinetd[1754]: warning: can't get client address: Connection reset by peer Jul 14 13:32:30 hudson ipop3d[1754]: pop3 service init from UNKNOWN Jul 14 13:32:30 hudson imapsd[1753]: Unable to accept SSL connection, host=UNKNOWN Jul 14 13:32:30 hudson imapd[1755]: imap service init from 127.0.0.1 Jul 14 13:32:30 hudson imapd[1755]: Connection reset by peer, while reading line user=??? host=UNKNOWN Jul 14 13:32:30 hudson ipop3sd[1756]: Unable to accept SSL connection, host=UNKNOWN
Ukážka logov ("/var/log/syslog") počas jednoduchého UDP portscanu:
Jul 14 13:35:20 hudson talkd[1819]: hudson.marine.sk (127.0.0.1): unintelligible packet Jul 14 13:35:20 hudson talkd[1819]: hudson.marine.sk (127.0.0.1): unintelligible packet Jul 14 13:35:22 hudson talkd[1820]: hudson.marine.sk (127.0.0.1): unintelligible packet Jul 14 13:35:22 hudson talkd[1820]: hudson.marine.sk (127.0.0.1): unintelligible packet Jul 14 13:35:23 hudson talkd[1819]: hudson.marine.sk (127.0.0.1): unintelligible packet Jul 14 13:35:23 hudson talkd[1820]: hudson.marine.sk (127.0.0.1): unintelligible packet Jul 14 13:35:24 hudson talkd[1819]: hudson.marine.sk (127.0.0.1): unintelligible packet Jul 14 13:35:24 hudson talkd[1820]: hudson.marine.sk (127.0.0.1): unintelligible packet
Poznámka: toto sú skutočne iba tie najjednoduchšie portscany, aké si
môžete predstaviť. Keď som testoval program "nmap" s tými
zložitejšími (stealth TCP port scan...), v logoch sa neobjavilo vôbec
nič!
Keď útočník pomocou portscanu zistí, ktoré služby na vzdialenom počítači bežia, prípadne aké démony ich obsluhujú, môže sa rozhodnúť vyskúšať na serveri "svoje nádobíčko", najmä ak používate démony, ktoré majú chyby. Keďže okrem portscannerov existujú aj kompletné súpravy programov na využitie chýb (väčšinou sa nazývajú "rootkit" - nástroje na získanie roota), obyčajne po zaujímavých výsledkoch portscanu nasleduje aj pokus o útok.
scanlogd". Je to špeciálny démon na
detekciu portscanov. Jeho jediným prejavom je zápis do logu v momente, keď sa
niekto pokúša pripojiť na niekoľko portov v krátkom časovom intervale
(bohužiaľ, bez úpravy zdrojových textov programu nemožno definovať ani tento
interval ani porty)logcheck".portsentry". Podobne ako
"scanlogd" detekuje portscan, ale je celkom pekne
konfigurovateľný a dokáže robiť aj protiopatrenia. Najzaujímavejšie z nich je
definovanie pravidla do firewallu, ktoré zabezpečí ignorovanie nasledujúcich
paketov z adresy, z ktorej prišiel portscan. Nepríjemnou vlastnosťou
protiopatrení tohto druhu je, že ak niekto falšuje svoju IP adresu (čo nie je
problém), dokáže prinútiť Váš server, aby ignoroval všetky pakety z tejto
adresy. TODO: pridať manuál k portsentry?
Poznámka: skenovanie portov nemožno chápať výlučne ako nástroj na
hackovanie. Ak sa dobre použije, je to pre systémového administrátora
neoceniteľná pomôcka, ktorá Vám umožní zistiť, ktoré služby máte prístupné.
"nmap" (man nmap) je rýchly a tak Vám odhalí
pravdu o Vašom serveri v priebehu niekoľkých sekúnd (pri jednoduchých
skenoch). Samozrejme, musíte svoj počitač skenovať aj z vonkajšej siete!
Pri tomto type útoku sa útočník snaží zabrániť ďalšiemu poskytovaniu služieb Vaším serverom. Úspešne sa využíva fakt, že niektoré prostriedky Vášho servera sú obmedzené a cieľom útoku je teda ich vyčerpanie. Prejavom DoS útoku je zastavenie prevádzky niektorej služby (napr. server prestane prijímať poštu, nefunguje WWW stránka a pod.) alebo zastavenie širokého spektra služieb (či už ako cieľ útoku alebo jeho vedľajší efekt).
DoS útoky môžu pochádzať zo siete alebo z Vášho vlastného servera. Môžu byť založené na zahltení siete, zaplnení disku, pamäte alebo tabuľky procesov.
Všeobecný postup je taký, že preťazením obslužného démona niektorej služby rýchlym sledom požiadaviek (pripojení) dôjde k obmedzeniu alebo úplnému zastaveniu poskytovania služby. Pri jednoduchých útokoch prichádzajú zahlcujúce požiadavky iba z jednej adresy, pri tých inteligentnejších z viacerých adries súčasne (DDoS - Distributed Denial of Service), čo sťažuje neskoršie pátranie po útočníkovi. Pátranie je ťažké aj z toho dôvodu, že pri útoku sa spravidla používajú falošné adresy odosielateľa paketov.
Názorný príklad: ak používate "inetd", pri pokuse
o nadmerné spúšťanie obslužných démonov nad určitý limit (Debian/potato: 40 za
minútu) začne "inetd" ďalšie požiadavky na určitý čas
(Debian/potato: 10 minút) ignorovať. To je na jednej strane výhodné proti
enormnému zaťaženiu servera, ktoré by znemožnilo prácu používateľov, ale na
druhej strane je úžasne jednoduché zastaviť prevádzku služby, ktorá sa spúšťa
z "inetd" - stačí poslať 40 a viac požiadaviek na danú službu
každých 10 minút.
Útoky majú aj vedľajšie efekty, ktoré sú niekedy nebezpečnejšie, ako samotné pokusy o pripojenie na službu: môže dôjsť aj k odstaveniu celého servera (preplnenie tabuľky procesov, zaplnenie diskov pri logovaní pokusov, znemožnenie prijímania pošty kvôli plným diskom a iné nepredvídané následky).
Jeden z najnepríjemnejších DoS útokov je tzv. "SYN flood" (www.cert.org/advisories/CA-1996-21.html). SYN je príznak v hlavičke TCP paketu, ktorý znamená, že sa bude vytvárať spojenie. Predtým, ako prejdeme k jadru problému, treba si uvedomiť, ako má vyzerať normálna komunikácia dvoch počítačov pomocou protokolu TCP.
Normálna TCP komunikácia sa skladá z troch krokov:
Po tejto výmene je spojenie nadviazané a potvrdené a nasleduje normálna dátová komunikácia.
Princíp útoku "SYN flood" je založený na poznatku, že v druhej fáze iniciovania TCP spojenia sa na cieľovom počítači vyhradí nejaká pamäť pre adresu zdrojového počítača a ďalšie informácie, aby bolo možné identifikovať "ACK"-paket v tretej fáze. "SYN flood" sa tento poznatok snaží zneužiť.
Ak útočník inicializuje spojenie "SYN" paketom s falošnou a nedostupnou zdrojovou adresou, cieľový počítač sa snaží odpovedať na túto nedostupnú adresu. Bude sa o to pokúšať niekoľko krát, až kým vyprší čas na nadviazanie komunikácie, pričom údaje o tomto (zatiaľ neexistujúcom) spojení si musí udržiavať v pamäti. Adresa odosielateľa musí byť sfalšovaná a nesmie na nej byť dostupný nijaký počítač - akonáhle by totiž prijal od cieľového počítača paket s príznakmi "SYN+ACK", zistil by, že nikdy neinicioval takéto spojenie a zaslal by cieľovému počítaču žiadosť o zrušenie spojenia "RST". Cieľový počítač by v tom okamihu uvoľnil zodpovedajúce údaje z pamäte.
Ak útočník zašle veľa falošných "SYN" paketov, na cieľovom počítači sa vyčerpá pamäť určená pre TCP spojenia a všetky ďalšie pokusy o spojenia budú preto ignorované. Útočník teda znemožnil normálnu prevádzku služieb - DoS ako vyšitý, krížikovým stehom.
Útok je založený na zasielaní UDP paketov s falošnou adresou odosielateľa. Keďže UDP je protokol bez nadväzovania spojenia, útočník zasiela UDP pakety na náhodné porty cieľového počítača. Ak počítač prijme UDP paket adresovaný na port, ktorý nevyužíva nijaká aplikácia, zašle odosielateľovi ICMP paket s hlásením o chybe. Ak útočník použíje dostatočne veľa UDP paketov, na sieti vznikne veľká (dvojnásobná) prevádzka a počítač zamrzne.
Zaujímavý útok je opísaný na adrese www.cert.org/advisories/CA-1996-01.html. Útočník používa falošné UDP pakety na prepojenie dvoch počítačov pomocou služieb "chargen" (generovanie náhodných znakov) a "echo" (vypíše to, čo dostane na vstup) - zašle na prvý cieľový počítač UDP paket pre službu "chargen" so zdrojovou adresou druhého cieľového počítača a portu pre službu "echo". Druhý cieľový počítač bude pomocou služby "chargen" generovať pakety a zasielať ich službe "echo" na prvý cieľový počítač. Tieto dve služby zahltia celé dostupné pásmo medzi počítačmi. Útočník vystupuje "iba" v úlohe iniciátora.
Ochrana proti tomuto konkrétnemu útoku je vypnutie (v skutočnosti málo
využívaných) služieb "echo" a "chargen", napríklad na úrovni
"inetd" démona, ktorý ich zväčša obsluhuje. Samozrejme, pomôže aj
filtrovanie týchto služieb na firewalli.
Útočník začne posielať veľké množstvo paketov (napr. ICMP ECHO) na cieľový server. Pakety zvyknú mať falošnú IP adresu odosielateľa a často sú zasielané z niekoľkých serverov súčasne. Cieľový server začne zasielať odpovede a dôjde k zahlteniu linky.
Tieto útoky využívajú ICMP pakety. "Ping of Death" spočíva v zasielaní príliš veľkých ICMP ECHO paketov, ktoré preplnia vyhradenú pamäť pre paket na cieľovom počítači. Útoky "Tear drop" a "Bonk" sú založené na prekrývajúcich sa fragmentoch ICMP paketov (zlý offset) a slúžia najmä na odstavenie počítačov s operačným systémom Windows.
Protiopatrením je zavedenie povinnej defragmentácie na routeroch alebo vo Vašom kerneli (voľba "IP always defragment"), ak funguje Váš Linuxový server ako brána do Internetu. Ďalšou možnosťou je blokovanie fragmentov ICMP paketov na firewalli.
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f; donev štartovacích skriptoch, alebo si naštudujte spôsob, ako to robí Vaša distribúcia. Táto možnosť v kerneli zabezpečí, že cez sieťový interface neprejdú pakety s adresou odosielateľa, ktorá na tejto strane siete nemá čo hľadať - napr. neprepustí pakety s privátnymi adresami prichádzajúce z vonkajšej siete
ipchains, iptables):
umožňuje predchádzať mnohým DoS útokom tým, že neprepustí pakety definované
na základe adries a portov. Paketový filter zahadzuje pakety ešte skôr, ako
sa k nim dostane obslužný démon, takže odpadajú problémy so zvýšeným
logovaním alebo zaťažením procesora. Ja zvyknem filtrovať všetky pakety,
ktoré smerujú na neobsadené porty alebo filtrujem pripojenie na služby,
ktoré majú byť prístupné iba z vnútornej sieteiptables): umožňuje
nastaviť pravidlá s limitmi pre počet spojení za jednotku času. Pomocou
týchto pravidiel sa vyhnete mnohým DoS útokom a to aj pre služby, ktoré
musia byť prístupné aj z verejnej siete (WWW, mail, DNS, ...)echo 1 > /proc/sys/net/ipv4/tcp_syncookies(Debian má na toto konfiguračný skript myslím v "
/etc/network/options", ak sa mýlim, napíšte mi). Podľa
dokumentácie v kerneli budete lepšie chránení proti SYN floodu - resp. server
bude fungovať aj počas syn floodu.Pozri tiež: www.cert.org/tech_tips/denial_of_service.html
Okrem sieťových DoS útokov existujú aj ich varianty, ktoré používajú iné prostriedky, ktorých množstvo je obmedzené, najmä diskovú kapacitu. Útočník môže začať generovať také pokusy o pripojenie alebo vyvinie inú aktivitu, ktorá má za následok zvýšené logovanie. Ak logy zaplnia všetok dostupný priestor, môže dôjsť k zastaveniu niektorých služieb, napr. mail servera (ak server nemá kam prijímať poštu).
Iným variantom tohto útoku je zasielanie veľkého množstva mailov, ktoré zaplnia disk. Následkom zaplnenia disku môžu prestať fungovať aj iné služby, ktoré potrebujú na disk zapisovať.
Nemusíme však chodiť až tak ďaleko - server dokáže znefunkčniť aj bežný používateľ. Pri útoku sa využíva fakt, že používateľ nemá obmedzené miesto na disku a môže jeho zaplnením obmedziť činnosť ostatných používateľov alebo - čo je ešte horšie - činnosť celého systému. To sa môže stať v prípade, že sa používateľské údaje (domáce adresáre) alebo dočasné súbory (do ktorých má právo zapisovať každý) nachádzajú na tom istom súborovom systéme, ako systémové údaje, ktoré server počas svojej prevádzky mení (logy, databázy, dočasné súbory, ...). Ak server nemá kam zapísať údaje do systémového logu, neexistuje možnosť monitorovania servera. Ak niektorá služba netestuje možnosť, že nemá kam zapísať údaje, môžu nastať nepredvídateľné okolnosti, ktoré s najväčšou pravdepodobnosťou vedú k strate dát a k zastaveniu prevádzky služby.
Na záver si spomenieme ďalší spôsob zastavenia služieb, ktorým je zneužitie prostriedkov servera lokálnymi používateľmi. Do tejto kategórie patrí zaplnenie pamäte, enormné zaťaženie procesora, zaplnenie tabuľky procesov a podobne. Štandardne systém neobmedzuje počet používateľských procesov a ich veľkosť v pamäti. Veľkosť pamäte je však obmedzená a ak používateľský program zaplní všetku dostupnú pamäť, server "umrie". To isté sa stane v prípade, že používateľ zaplní tabuľku procesov (počet súčasne bežiacich procesov je obmedzený). Ak používateľ bude vykonávať zložité operácie, jeho procesy zaťažia server natoľko, že môže prestať odpovedať na požiadavky.
Pred chvíľou sme spomenuli súborové kvóty. Bolo by dobré, keby niečo podobné existovalo aj pre procesy, pamäť atď. No, a niečo podobné, prirodzene, existuje.
Ak Váš server podporuje PAM, pomocou modulu "pam_limits.so"
môžete zabrániť mnohým lokálnym DOS útokom. Stačí, ak v konfiguračnom súbore
"/etc/pam.d/ssh" (predpokladám, že sa na server prihlasujete len
pomocou SSH a to je aj jediný spôsob, ktorý Vám odporúčam,
okrem administrátorskej práce s konzolou) doplníte tieto riadky:
session required /lib/security/pam_limits.so session required /lib/security/pam_unix.so
Potom upravte konfiguračný súbor "/etc/security/limits.conf".
Jednotlivé riadky majú tvar:
kto typ čo hodnota
Príklad: obmedzíme skupinu "students" nasledovne: nulová veľkosť súboru
"core" (pri páde niektorej aplikácie by sa zbytočne zapĺňal
diskový priestor), proces môže zaberať v pamäti maximálne 16 MB (16384 KB)
a používateľ môže spustiť maximálne 10 procesov súčasne.
@students hard core 0 @students hard rss 16384 @students hard nproc 10
Podobne môžete vytvoriť obmedzenia aj pre ďalšie skupiny používateľov. Inšpirujte sa konfiguračným súborom, v ktorom sú potrebné komentáre a dokonca aj príklady.
Tento druh útoku môže byť ten najjednoduchší v prípade, že Vaši používatelia nie sú dostatočne poučení o heslách a pravidlách prístupu. Každý by totiž mal vedieť (a ak to nevie, je za to zodpovedný správca), že heslo slúži na jednoznačnú identifikáciu v systéme a že pomocou neho možno potenciálne zastaviť prevádzku celého servera.
Cieľom získania čierneho konta je jeho používanie na ďalšie prieniky na iné servery, prípadne na preniknutie do Vášho vlastného servera. Je oveľa jednoduchšie prenikať na server zvnútra, pretože útočník nie je obmedzovaný firewallom, TCP wrapperom a podobnými záležitosťami. Okrem návodov na prenikanie na server zo siete existuje totiž aj celá kopa lokálnych prienikov.
Získavanie používateľského hesla je v zásade možné:
Jedným zo základných pravidiel správy servera je "nedávať používateľom väčšie práva, ako nevyhnutne potrebujú". V rozsahu, ktorý nás teraz zaujíma, môžeme povedať, že:
pam_cracklib", priebežná kontrola programom "John the Ripper"samba"), nepotrebuje prístup na server a heslo do
Linuxu mu môžete zablokovať (passwd -l username. Sambu
nakonfigurujte tak, aby používala vlastný súbor hesiel. ak používateľ bude
používať server iba na prácu s mailom (webmail) a/alebo súbormi prostredníctvom
"samby", potrebuje heslo do Linuxu, ale nepotrebuje shell.
Zakážte mu ho (chsh -s /bin/false username - možno budete
musieť upraviť súbor "/etc/shells", ktorý obsahuje zoznam
platných shellov tak, že do neho doplníte riadok s "/bin/false").
Ak má byť väčšina Vašich používateľov bez shellu, na Debiane môžete použiť
konfiguračný súbor "/etc/adduser.conf", v ktorom nastavíte
direktívu DSHELL=/bin/false. Používateľom, ktorí potrebujú
shell, ho potom nastavíte ručne.rssh" (Restricted Secure
Shell), ktorý umožňuje iba prácu so súbormi. (fixnutá linka)Veľmi často používaným trikom je uhádnutie príliš jednoduchého hesla používateľa. V zásade musíte predpokladať, že pri akomkoľvek počte poučených používateľov existuje minimálne jeden (a to som optimista), ktorého heslo sa dá uhádnuť s minimálnou námahou.
Možno vás napadla myšlienka, že vytvoríte program, ktorý bude postupne skúšať "nejaké heslá" tak, že sa bude pripájať na služby typu "telnet", "ssh", "ftp" alebo ďalšie (také, ktoré používajú prihlasovanie pomocou hesla) a bude sa pokúšať o uhádnutie hesla dovtedy, kým sa mu to nepodarí. Takýto útok má však niekoľko "vedľajších" účinkov a preto sa už nepoužíva:
Pri hádaní a zisťovaní hesiel sa preto vždy využívajú informácie uložené priamo na serveri (a teda vzniká nebezpečenstvo najmä zo strany už prihlásených používateľov). Ak sa používateľ dostane k súboru s heslami, jeho pokusy o hádanie hesiel nebudú nikde zaznamenávané! Bude si so súborom môcť robiť čokoľvek.
Pri hádaní (crackovaní) hesla sa vychádza z dvoch predpokladov:
/etc/shadow". Kódovanie je jednosmerné, zo zakódovaného hesla
nie je možné získať pôvodné heslo. Pri autentifikácii používateľa sa zadané
heslo zakóduje rovnakým kódom ako heslá v "/etc/shadow"
a zakódované heslá sa porovnajú. Ak sú rovnaké, používateľ zadal správne
heslo.Z prvého predpokladu vyplýva, že na uhádnutie hesla treba použiť tzv. "slovníkovú metódu". Hacker vezme priemerne veľký slovník, obsahujúci najčastejšie používané heslá v danom jazyku a postupne jedno za druhým zakóduje, pričom ich porovnáva so zakódovanými heslami. Rovnako ako pri autentifikovaní používateľa, ak sú zakódované heslá rovnaké, hacker zadal správne heslo, ktoré tým pádom pozná.
S dostatočne veľkým slovníkom a na rýchlom počítači nie je problém hacknúť
hneď niekoľko hesiel, pretože používatelia sú nepoučiteľní a používajú heslá
typu "zuzana" alebo "beavis". Ak program vyčerpá
všetky slová zo slovníka, môže pracovať s ich obmenami (malé/VEĽKÉ písmená,
zrkadlovo obrátené slová pod.) alebo použiť "útok hrubou silou", teda všetky
možnosti kombinácie písmen, číslic a špeciálnych znakov. Heslá, ktoré obsahujú
napr. iba písmená, hádanie touto metódou iba uľahčujú. Metóda hrubej sily síce
môže trvať dlho, ale pri dostatočne veľkom výkone počítača (počítačov) je
výsledok zaručený v relatívne blízkom čase. A čo je najhoršie, programy na hádanie hesiel spolu so
slovníkmi sú prístupné na Internete, môže ich použiť ktokoľvek.
Z druhého predpokladu vyplýva, že hacker musí najprv získať prístup k heslám,
k súboru "/etc/shadow". Jedno z riešení je využiť chybu
niektorého programu, ktorý sa spúšťa s právami roota. Potom stačí súbor
"/etc/shadow" skopírovať na iný počítač a tam spustiť
crackovanie. Prirodzene, zmysel celej takejto akcie je len v tom, že cracker
získa platné používateľské kontá. Aby ich mohol získať, nevyhnutne sa musí
stať rootom, a teda potenciálne si môže nejaké kontá vytvoriť aj sám. To už
však nie je také nenápadné, ako používanie skutočných a legálnych kont.
pam_cracklib.so"
Knižnica "pam_cracklib.so" Vám umožňuje (ak používate PAM
- Pluggable Authentication Modules) pridať kontrolu hesla používateľa priamo
pri jeho zmene. Po zadaní nového hesla sa vykonajú kontroly, s cieľom
zamietnuť heslo, ktoré:
Prvé pravidlá zabránia použitiu príliš podobných hesiel, posledné je najelegantnejšie :)
Ak chcete zistiť, či Váš počítač podporuje PAM (moderné distribúcie ho
podporujú už niekoľko rokov), skontrolujte, či existuje adresár
"/etc/pam.d" (alebo súbor /etc/pam.conf - napr. na
Solarise). Adresár by mal obsahovať niekoľko súborov pomenovaných podľa
služby (príkazu), ktorej autentifikáciu zabezpečujú. Typicky obsahuje súbory
"login", "passwd", "su",
"telnet", "ssh" a ďalšie. V novších distribúciách
(napr. Debian Sarge) obsahuje tiež súbory "common-auth", "common-password",
"common-account" a "common-session" - zmeny
v týchto "common-" konfiguračných súboroch sú automaticky zahrnuté do ostatných.
Ak chcete zistiť, či je Váš počítač nakonfigurovaný s PAM, vypíšte si napr. súbor:
less /etc/pam.d/common-password
Mali by ste vidieť niečo takéto (konfigurácia závisí aj od distribúcie):
Na Debiane Sarge (3.1):
password required pam_cracklib.so retry=3 minlen=6 difok=3
password required pam_unix.so use_authtok nullok md5
Riadok zobrazený zeleným písmom určuje, že pre triedu operácie "password"
(zmena hesla) sa použije knižnica "pam_cracklib.so" a iba
v prípade, že heslo bolo "schválené" ako dostatočne zložité ("required"), sa
uskutoční samotná zmena hesla (knižnica "pam_pwdb" - na Debiane
"pam_unix"). Princípom PAM je práve možnosť takéhoto
"spájania" modulov pre rôzne operácie, napr. zmenu hesla.
Ak chcete zistiť, či nejaký program podporuje PAM, treba zistiť, či je
linkovaný s knižnicou "libpam.so"
[vix@hudson ~]$ ldd /bin/login
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4001d000)
libpam.so.0 => /lib/libpam.so.0 (0x4004a000)
libdl.so.2 => /lib/libdl.so.2 (0x40052000)
libpam_misc.so.0 => /lib/libpam_misc.so.0 (0x40055000)
libc.so.6 => /lib/i686/libc.so.6 (0x40058000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Knižnica "cracklib" používa pri kontrole hesla vlastný slovník,
pre Debian sa nachádza v adresári
"/var/cache/cracklib/cracklib_dist.*"). Nič Vám však nebráni,
aby ste ho doplnili o nové slová.
Čím väčší je slovník, tým menšia je šanca, že používatelia použijú jednoduché
heslo. Ja som sa rozhodol použiť slovník z programu "John the
Ripper" spolu s menami zo slovenského kalendára, slovníka slovenskej
verzie programu "ispell" (kontrola pravopisu) a každú noc do
slovníka pridávam aj zoznam prihlasovacích mien používateľov. Tento slovník si
môžete stiahnuť tu (ZIP).
Ak máte Mandrake: použite utilitu "create_cracklib_dict":
/usr/sbin/create_cracklib_dict súbor1 súbor2 ...
kde parametre sú textové súbory so slovami (slovník). Predpokladá sa, že každé
slovo sa nachádza na samostatnom riadku. Po spustení sa vytvoria súbory pre
knižnicu "cracklib" (už zmienené súbory
"cracklib_dict.*") - pozor, existujúce budú prepísané!
Preto je lepšie postupne si pridávať slová do jedného veľkého súboru, v ktorom
sa na začiatku nachádza napr. obsah súboru "/usr/dict/words"
("/usr/share/dict/words").
Ak spustíte program "create_cracklib_dict" bez parametrov,
zobrazí sa stručný help a cesta k súborom slovníka.
Ak máte Debian, môžete použiť tento postup:
/etc/cron.daily.cracklib" nasledovne:
Pred prvým príkazom (riadok, ktorý nezačína znakom "#") dopíšte:
# generates user list from /etc/passwd
# right before the cracklib dictionaries are updated
# VIX, 21/3/2007
cat /etc/passwd | awk -F : '{ print $1 }' > /usr/local/share/dict/cracklib/users.txt
# end of VIX
/usr/local/share/dict/cracklib/"/etc/cron.daily/cracklib", aby sa
vytvorili indexové súbory pre slovník./usr/share/dict" "/usr/dict"
"/usr/local/share/dict" "/usr/local/dict"Takto máte zabezpečenú automatickú kontrolu novovytváraného hesla voči vyššie zmieneným slovníkom. Je načase si overiť, či si bežný používateľ môže nastaviť heslo zo slovníka (ak ste postupovali správne, nemôže).
Existuje niekoľko pravidiel na vytvorenie skutočne silného hesla. Tieto pravidlá si musia vštepiť do pamäti administrátori a následne používatelia. Administrátori by mali byť schopní ľudsky im vysvetliť, že pri používaní jednoduchého hesla hrozí nebezpečenstvo celému serveru.
Dobré heslo:
Ako si vytvoriť dobré heslo - to je tá otázka za milión dolárov :) Existuje niekoľko spôsobov:
pwgen".Príklad 1 (začiatočné písmena slov vo vete):
Veta:
Anna má rada všetky zvieratá okrem hada.
Heslo zo začiatočných písmen:
amrvzoh
Heslo zo začiatočných písmen obsahujúce aj veľké písmená:
AmrvzoH
Pridáme číslice a špeciálne znaky (pomôcka: "okrem hada" znamená "nie had". V symbolike programovacieho jazyka C a mnohých podobných sa "nie" označuje znakom "!" a tak nahradíme znak "o" znakom "!":
32Amrvz!H
alebo
Amr/vz!H
Výsledné heslo je dostatočne dlhé (8 znakov), komplikované na uhádnutie a nenachádza sa v nijakom slovníku. Ale ak viete, ako ste ho vytvorili, spomeniete si naň kedykoľvek.
Príklad 2 (generátor hesiel "pwgen"):
Použitie programu je veľmi jednoduché a nemá veľa možností. Prvým parametrom je požadovaná dĺžka hesla (odporúčam najmenej 8 znakov) a druhým počet vygenerovaných hesiel. Ak chcete komplikovanejšie heslo, môžete použiť parameter "-n" (v hesle bude najmenej jedna číslica).
Môžete si pozrieť manuálovú stránku, program má aj ďalšie možnosti na komplikovanejšie heslá.
vix@twin ~$ pwgen -n 8 5 Quiegh0v bef2Raid Kooy0shu Kup3wahm Xei7tohx
Môžete si pozrieť manuálovú stránku, program má aj ďalšie možnosti na Výsledné heslá nie sú v nijakom slovníku, ale zapamätajú sa trochu ťažšie. Výhodou je, že pri letmom pohľade na takúto masu písmen si ju nezapamätá ani ten, kto by sa Vám pozeral cez plece pri výbere hesla. Jedine, že by mal fotografickú pamäť ;-)
Okrem vyššie uvedených bodov sa treba postarať o:
telnetd",
pomôže Vám len TCP wrapper; ak používate SSH, môžete použiť buď direktívy v konfiguračnom súbore
"/etc/ssh/sshd_config" alebo tiež súbory TCP wrappera (ak je
"sshd" skompilovaný s knižnicou "libwrap"). /etc/securetty" vymenujte virtuálne terminály (konzoly),
z ktorých sa môže prihlásiť root. Každý terminál sa zapisuje na jeden riadok
a implicitne súbor obsahuje "tty1" - "tty6". Po tejto zmene sa root neprihlási
z iného terminálu (ani pomocou programu "telnet"). Ak používate SSH, použite direktívu "PermitRootLogin no", aby sa root
nemohol prihlásiť pomocou "ssh" (na prihlásenie použijete svoje konto a potom
príkaz "su").Týmto máte určenú pomerne slušnú prístupovú politiku pre používateľov servera. Prípadné prieniky pomocou získaných hesiel používateľov Vás ohrozia v podstate iba vtedy, keď majú shell, v ktorom môžu pracovať so serverom. Ak majú vytvorené heslo, ale nie shell, môže dôjsť maximálne k zneužitiu ich pošty.
V praxi som tento postup zaviedol na škole aj ja. Bol som však trochu
pritlačený k múru požiadavkou, aby sa študenti mohli učiť používať aj programy
"talk" a "irc". Takže som shelly priebežne zakazoval
a povoľoval. Paranoidné, ale funkčné.
Tento druh útoku je takmer totožný so získaním hesla bežného používateľa, umožňuje však útočníkovi prevziať kontrolu nad serverom okamžite po prihlásení. Okrem získavania údajov (mailov, hesiel, ...) zo servera si útočník veľmi často vytvorí zadné vrátka na nejakom bežne nepoužívanom porte, prípadne si pripraví rootovský suid shell, aby sa mohol bez problémov v budúcnosti opäť stať rootom bez ohľadu na to, či si zmeníte heslo. Heslo správcu servera by ste preto nie iba mali, ale MUSÍTE uchovávať v tajnosti.
Cieľom útočníka, ktorému sa podarí získať rootovský shell je väčšinou zabezpečiť, aby sa na server dostal aj v budúcnosti a to čo najjednoduchším spôsobom. A nie je nič jednoduchšie, ako si vytvoriť setuid shell a používateľské konto. Na toto konto sa prihlási a spustí si shell, ktorý mu umožní okamžite sa stať rootom.
Na detekciu treba preto vedieť objaviť nové používateľské kontá a zmenené alebo novovytvorené súbory. Na toto slúžia rôzne programy na testovanie systémovej integrity, ako napr. "Tripwire" alebo "Nabou".
/etc/securetty" obsahuje zoznam virtuálnych
terminálov, z ktorých sa používateľ "root" môže prihlásiť (na každom riadku
jeden). Na mojom Mandraku sú to terminály "tty1",
"tty2", "tty3", "tty4",
"tty5" a "tty6", čiže prvých 6 virtuálnych konzol.sshd"
- "/etc/ssh/sshd_config" použite riadok: "PermitRootLogin
no" a reštartujte "sshd". Používateľ "root"
sa nebude môcť prihlásiť pomocou "ssh". Ak budete potrebovať
rootovské privilégiá, prihlásite sa cez "ssh" pod svojím
používateľským menom a potom použijete príkaz "su"./etc/ftpusers" vymenujte používateľov, ktorí sa nebudú môcť
prihlásiť cez ftp (na každom riadku jeden).3 x NIKDY
Je iba málo programov, ktoré sú bez chyby, dokonca je pravdepodobné (ak nie nevyhnutné), že každý program obsahuje minimálne jednu chybu. To je tiež jedna z príčin, pre ktorú stále vznikajú nové verzie programov (druhou príčinou je implementácia nových vlastností).
Keďže Linux je otvorený systém založený na voľne prístupných zdrojových kódoch programov, každý, kto objaví v nejakom programe chybu, môže o tom informovať ostatných, prípadne priamo uviesť kód na "otestovanie" chyby (väčšinou ide o kód na získanie shellu s právami používateľa, pod ktorým sa spúšťa daný program, "exploit"). To na jednej strane znamená, že sa o chybe dozvie každý, kto program používa a chce ho aktualizovať, ale tiež to, že sa o danom bezpečnostnom probléme dozvie každý, kto ho bude chcieť zneužiť. A presne tu je problém: o chybách sa dozvie každý.
To je samozrejme celkom v poriadku. Pre správcu to však znamená byť neustále v strehu a aktualizovať chybný softvér čo najskôr po zverejnení chyby a prípadného exploitu. To najhoršie, čo môžete urobiť, je nainštalovať akúkoľvek distribúciu Linuxu (alebo iného operačného systému) a prestať sa o ňu zaujímať. Ak necháte systém žiť svojím vlastným životom, veľmi skoro Vám prerastie cez hlavu, celkom ako deti v puberte :)
Niektoré chyby sú nebezpečnejšie ako iné a často sa zneužívajú na prienik do
systému. Mnoho programov je neslávne známych kvôli častým bezpečnostným
problémom (napr. "sendmail"). Ak nepoužívate operačný systém,
ktorý je sám osebe chránený voči zlyhaniu programov (napr. oddeľovaním
privilégií tak, že používateľ "root" nemá neobmedzené práva; každopádne, bežný
Linux sem nepatrí, ale môžete sa pozrieť na Projekt Medusa, ktorý sa zaoberá zvýšením
bezpečnosti na úrovni jadra na podobnom princípe), musíte všetky dôležité
programy na serveri pravidelne aktualizovať. Týka sa to najmä démonov, ktoré
obsluhujú sieťové požiadavky a ktoré (spravidla) bežia pod rootom. O tom, že
niektoré démony pod rootom bežať nemusia, sme hovorili v kapitole Root versus bežný používateľ.
Teraz si napíšeme niečo o niektorých chybách, ktoré sa využívajú na prienik do systému alebo jeho zneužitie.
Tento spôsob prieniku je veľmi zábavný, často totiž nepotrebuje nič iné, ako lenivého alebo nepozorného správcu.
Oveľa horšie je, ak nainštalujete program, ktorý je v štandardnej konfigurácii
nesprávne nastavený. Jeden z prípadov, na ktorý si teraz spomínam, sa týkal
démona "tftpd" (trivial ftp daemon) a je to už skutočne veľmi
stará záležitosť. O čo išlo?
"tftpd" je jednoduchý ftp démon, ktorý umožňuje bezdiskovým
staniciam (alebo aj iným zariadeniam, napr. switchom, routerom a pod.)
stiahnuť si do svojej pamäte jadro a potrebné programy, ktoré potom používajú
na normálnu prácu. Pri pripájaní na "tftpd" neprebieha nijaká
autentifikácia, klient sa proste pripojí a určí meno súboru s jadrom alebo
časťou operačného systému. V časoch, o ktorých hovorím, umožňoval tento démon
ľubovoľnému klientovi stiahnuť ľubovoľný súbor zo servera a to bez
akejkoľvek autentifikácie! Iste si dokážete predstaviť, čo by to mohlo
znamenať, keby ste tohto démona nechali pristupného zo siete. Ak by bežal
s rootovskými privilégiami, umožnil by komukoľvek skopírovať si napríklad
súbor s heslami.
"tftpd" má kvôli bezpečnosti parameter, ktorý určuje adresár,
v ktorom sa nachádzajú súbory, ktoré môže poskytovať klientom. Vďaka tomu je
teda táto chyba už nepodstatná. Nehľadiac na to, že väčšina z Vás nebude
bezdiskových klientov ani používať, a ak, tak určite nie z vonkajšej siete!
Ďalším nepríjemným prípadom bola kedysi chybná konfigurácia
"sendmailu", ktorá defaultne urobila z Vášho mail servera
otvorený relay server (mail server, cez ktorý mohol ktokoľvek posielať poštu,
pričom sa zdalo, že bola odoslaná z Vášho servera). Toto síce nie je
bezpečnostný prienik, ale veľmi pravdepodobne sa Váš stroj stal prostriedkom
na šírenie SPAMu.
Dajte si tiež pozor na používanie defaultných hesiel (najmä správcu systému!) V niektorých prípadoch (napr. aj projekt Infovek) sa napríklad dodáva už nainštalovaný server s nastavenými aplikáciami. K aplikáciám a samozrejme ku kontu správcu servera by ste mali dostať heslo. Tieto heslá a v prvom rade rootovské treba ihneď zmeniť. Paranoja je celkom na mieste!
Všeobecná ochrana proti chybám programov je uvedená na konci kapitoly, ale napriek tomu mám jednu priateľskú radu: vždy si preštudujte dokumentáciu k programu, ktorý inštalujete. Hoci autori dnešných distribúcií Linuxu dávajú na podobné veci pozor, budete mať vždy aspoň viac informácií o tom, čo daný program dokáže.
Veľmi nepríjemnou chybou, ktorou často trpí veľa programov súčasne, je tzv. "buffer overflow", čiže preplnenie pamäte programu na uloženie nejakých údajov. Táto chyba je nebezpečná preto, že existuje skutočne veľmi veľa programov, ktoré nikto na podobné chyby nekontroloval a potenciálne sú nebezpečné takmer všetky. Z hľadiska cieľovej skupiny programov ide najmä o démony, ktoré sú prístupné zo siete, pretože na ne môže zaútočiť každý, kto sa dostane cez Váš firewall, a tiež programy, ktoré sa nachádzajú na Vašom serveri a majú nastavený príznak setuid. O zneužitie týchto programov sa môže pokúsiť každý používateľ Vášho servera, ktorý má shellovský prístup.
Princípom využitia chyby je toto: každý program si potrebuje ukladať do pamäte nejaké údaje, napríklad získané z príkazového riadku alebo zo siete. Problém je v tom, že veľa programov si na tento účel vyhradí nejakú pamäť, ale pri ukladaní údajov do nej nekontrolujú ich veľkosť! Ak do pevne definovanej oblasti pamäte nakopírujete vhodné údaje s väčšou dĺžkou, ako je pre ne vyhradené miesto, môžete donútiť program urobiť prakticky čokoľvek. Najviac sa využíva to, že v procedúrach a funkciách sa ako pamäť na údaje používa zásobník, na ktorom je hneď za údajmi uložená aj návratová adresa, na ktorú sa program vráti po ukončení funkcie. Ak túto adresu prepíšete vhodne zvolenými údajmi, môžete program prinútiť napríklad spustiť shell s právami, ktoré má daný program (presne toto sa aj bežne robí). Zmyslom prieniku je preplniť zásobník programu, ktorý beží pod rootom, aby útočník získal rootovské práva.
Typickým démonom, ktorý sa na tieto účely využíval, bol program
"sendmail", pretože beží pod rootom a jeho kód je tak obrovský,
že je veľmi ťažké nájsť a odstrániť všetky problémové časti.
Postfix" namiesto "sendmailu"Pozri aj: Linux Security-HOWTO (linka bola opravená)!