Príručka systémového administrátora, 1.9.4

5. Bezpečnosť servera v sieti

Posledná zmena: 21/3/2007

5.1 Prečo nás zaujíma bezpečnosť

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").

5.2 Bezpečnostná politika

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:

  1. to, čo nie je explicitne povolené, musí byť zakázané!!!
  2. nedávajte používateľom a aplikáciám väčšie práva, ako potrebujú pre svoju činnosť
  3. nikdy sa nespoliehajte na jediný ochranný prostriedok. Napríklad na obmedzenie prístupu môžete používať TCP wrapper, ale skombinujte ho aj s firewallom.
  4. pravidelne aktualizujte softvér a zálohujte dáta!!!

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ý!

5.2.1 Bezpečnostné slabiny

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.

5.2.2 "Princíp najľahšieho prieniku"

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".

5.2.3 Fyzická bezpečnosť

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:

5.2.4 Bezpečnosť operačného systému

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:

5.2.5 Bezpečnosť služieb a aplikácií

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:

5.2.6 Bezpečnosť lokálnej siete

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 | ...
        +------------+  +-------------+  +--------------+

5.2.6 Kontrola používateľov

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:

  1. je používateľ skutočne ten, za koho sa vydáva? (autentifikácia)
  2. aké práva má mať používateľ po prihlásení? (autorizácia)

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:

5.3 "Životný cyklus bezpečnostného problému"

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

5.3.1 Prevencia: predchádzame útoku

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ť.

5.3.2 Kontrola systému: zisťujeme, či došlo k útoku

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 :).

5.3.3 Detekcia útoku: vieme, že došlo k útoku

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.

5.3.4 Analýza útoku: ako došlo k útoku?

Ak ste našli neklamné známky "cudzej aktivity", je predovšetkým potrebné:

  1. nespanikáriť: nevykonajte nič nevratné, nereštartujte server, nepodnikajte recipročné útoky proti serverom, z ktorých podľa Vás prišiel útok
  2. nezahladiť stopy: nevypínajte server, ale zabráňte znehodnoteniu stôp. Odpojte káble zo sieťových kariet a pracujte s konzolou. Treba prezrieť, či v zozname procesov nie je proces, ktorý tam nepatrí, či nie je prihlásený používateľ, ktorý prihlásený byť nemá, resp. je prihlásený z nejakej neznámej adresy.
  3. zálohovať stopy: pre neskoršiu analýzu alebo pre analýzu na inom počítači si skopírujte logy z adresára "/var/log" na disketu alebo aspoň do iného adresára.
  4. analyzovať spôsob preniknutia na server: analýza útoku nie je ani trochu jednoduchá a myslím si, že neexistuje "používateľská príručka" na tento proces. Odporúčania však existujú a sú publikované a linky na ne sem neskôr určite zaradím. Zatiaľ budete musiet použiť:

5.3.5 Odstránenie dier(y)

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:

  1. distribúcie založené na RPM (Red Hat, Mandrake, ...): "rpm -qf /cesta/k/suboru"
  2. Debian: "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!

5.3.6 Vypracovanie protiopatrení: prečo došlo k útoku?

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ší.

5.4 Niektoré druhy útokov

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.

5.4.1 Zneužitie fyzického prístupu ku konzole

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:

  1. útok typu DoS (vypnutie, reštartovanie servera): či už pomocou kombinácie CTRL+ALT+DEL alebo použitím tlačidla RESET (či dokonca vypínača alebo poistiek) možno reštartovať či vypnúť server. Ak ide o školský server, možno sa tak veľa sa nestane; prinajhoršom sa stratí pár mailov alebo práve sťahovaných MP3-jok v dôsledku nesprávneho vypnutia. Ak však ide o server, ktorý musí bežať stále, pretože poskytuje dôležité údaje (banky, vojenské servery atď.), je to problém ako vyšitý
  2. získanie rootovského shellu: ak počítač pri štarte nevyžaduje heslo (BIOS), stačí nabootovať server s parametrom: 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...

5.4.1.1 Detekcia

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) (gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk)) #7 Wed Dec 11 00:00:17 CET 2002

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)

5.4.1.2 Ochrana

Vhodné opatrenia:

  1. znemožnite fyzický prístup k počítaču (zamknutá miestnosť, kontrola prístupu do miestnosti, alarm, ...)
  2. vyžadujte heslo pri bootovaní počítača (najjednoduchšie v BIOSE)
  3. pripojte server na záložný zdroj napätia a prepojte ich pomocou špeciálneho kábla. V prípade úmyselného či náhodného výpadku napätia bude server bežať ďalej. Ak zdroju poklesne napätie, bude signalizovať serveru káblom problém a server sa korektne vypne (a zapne pri obnovení napätia)

5.4.2 Skenovanie portov (portscan)

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.

5.4.2.1 Detekcia skenovania portov

5.4.2.2 Ochrana proti skenovaniu portov

  1. všeobecná: zrušte nepotrebné služby, použite TCP wrapper a firewall na kontrolu prístupu k nim. Pomôcť Vám tiež môžu programy na kontrolu logov, ako napr. "logcheck".
  2. aktívna: program "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!

5.4.3 Zastavenie prevádzky služieb (Denial of Service, DoS)

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.

5.4.3.1 Denial of service: útok zo siete

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).

5.4.3.1.1 SYN flood

Jeden z najnepríjemnejších DoS útokov je tzv. "SYN flood" (http://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:

  1. zdrojový počítač vyšle TCP paket s nastaveným príznakom "SYN" (žiadosť o komunikáciu)
  2. cieľový počítač odpovedá paketom s nastavenými príznakmi "SYN" a "ACK" (pripravený na komunikáciu)
  3. zdrojový počítač odpovedá paketom s nastaveným príznakom "ACK" (začíname komunikovať)

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.

5.4.3.1.2 UDP flood

Ú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.

5.4.3.1.3 Využitie Vašich vlastných prostriedkov na DoS

Zaujímavý útok je opísaný na adrese http://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.

5.4.3.1.4 Zahltenie linky (flood)

Ú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.

5.4.3.1.5 Útoky "Ping of death", "Tear drop" a "Bonk"

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.

5.4.3.1.6 Ochrana proti sieťovému DoS útoku
  1. vypnite služby, ktoré nepoužívate, neposkytnete tak potenciálnym útočníkom potenciálne ciele útoku
  2. zapnite v kerneli overovanie zdrojovej cesty pomocou príkazu
    for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f; done
    v š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
  3. firewall:
    1. paketový filter (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 siete
    2. limit na počet spojení (iptables): 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, ...)
  4. pre útoky založené na ICMP zapnite defragmentáciu paketov vo Vašom kerneli (IP always defragment) - pozor, iba v prípade, že je Váš Linuxový server jedinou cestou pre pakety!
  5. zapnite možnosť TCP_SYNCOOKIES vo Vašom kerneli (2.2.x, 2.4.x) a potom (a pri každom štarte servera) vykonajte:
    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ž: http://www.cert.org/tech_tips/denial_of_service.html CERT/CC

5.4.3.2 Denial of service: zaplnenie disku

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.

5.4.3.2.1 Ochrana proti zaplneniu disku
  1. používanie oddelených súborových systémov pre:
  2. používanie súborových kvôt.

5.4.3.3 Denial of service: zneužitie prostriedkov servera používateľmi

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.

5.4.3.3.1 Ochrana proti zneužitiu prostriedkov servera

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.

5.4.4 Získanie používateľského hesla a zneužitie používateľského konta

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é:

5.4.4.1 Ochrana proti zneužitiu používateľského konta

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:

  1. zákaz používania jednoduchých hesiel: knižnica "pam_cracklib", priebežná kontrola programom "John the Ripper"
  2. ak používateľ nepotrebuje konto, netreba mu ho vytvoriť
  3. ak vytvoríte konto používateľovi, zdôraznite potrebu vytvorenia dobrého hesla. Najlepšie sa zdôrazňuje podpísaním papiera o tom, že si je používateľ vedomý následkov zneužitia svojho konta.
  4. ak používateľ potrebuje konto iba na prístup do siete a prácu so súbormi na serveri ("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.
  5. ak používateľ tvrdí, že potrebuje shell kvôli kopírovaniu súborov na server, "prinúťte ho" používať programy, ktoré podporujú "sftp" (služba SSH) a nainštalujte špeciálny shell "rssh" (Restricted Secure Shell), ktorý umožňuje iba prácu so súbormi. (fixnutá linka)
  6. prístup pomocou SSH zvonku netreba používateľom povoľovať a keď už, tak len z vopred určených pevných adries!
  7. osveta medzi používateľmi: vysvetlite im, prečo je dôležité mať zložité heslo
  8. šifrovanie: nahraďte nešifrované protokoly šifrovanými (telnet, ftp: ssh; pop3, imap: stunnel+pop3, stunnel+imap ...)
5.4.4.1.1 Kontrola jednoduchých hesiel

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:

  1. pri "hádaní" takýmto spôsobom sa zaťažuje sieť, ale najmä:
  2. hádanie "je vidieť". Zbadá ho každý administrátor, ktorý sleduje logovacie súbory, pretože pokus o neúspešnú autentifikáciu je jeden z najčastejších príznakov problémov s heslom (od zabudnutia po hádanie). Niektoré servery možno nakonfigurovať tak, že po určitom počte pokusov o prihlásenie sa ďalšie pokusy buď znemožnia alebo spomalia (toto sa vám už určite stalo), ba dokonca túto informáciu možno využiť na zablokovanie prístupu z adresy, odkiaľ prichádzajú požiadavky na prihlásenie

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:

  1. používateľské heslá sú uložené v zakódovanom tvare v súbore "/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.
  2. prístup používateľským heslám (k tomuto súboru) má iba root

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.

5.4.4.1.2 Knižnica "pam_cracklib.so"[UPDATE]

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)

TODO: viac o PAM

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:

  1. upravte "/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
    
  2. hore uvedený archív rozbaľte v adresári "/usr/local/share/dict/cracklib/"
  3. spustite skript "/etc/cron.daily/cracklib", aby sa vytvorili indexové súbory pre slovník.
  4. oproti staršej verzii Debianu nie je nutné robiť žiadne ďalšie zmeny, pretože slovníkové súbory sa automaticky hľadajú v adresároch "/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).

5.4.4.1.3 Ako si vytvoriť dobré heslo[UPDATE]

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:

  1. má mať najmenej 8 znakov
  2. má obsahovať okrem malých písmen aj iné znaky, t.j. číslice, veľké písmená, špeciálne znaky (.,!? a pod.)
  3. nemá obsahovať mäkčene a dĺžne (keď už pre nič iné, tak pre prípad, že nebudete mať slovenskú klávesnicu)
  4. nesmie byť založené na slove zo slovníka (akékoľvek zmysluplné slovo v akomkoľvek jazyku, vrátane mien)
  5. nesmie byť "jednoduché" v zmysle "qwerty" a pod.
  6. musí byť jednoduché na zapmätanie, ale ťažké na uhádnutie
  7. by ste nemali používať na viac ako jeden server

Ako si vytvoriť dobré heslo - to je tá otázka za milión dolárov :) Existuje niekoľko spôsobov:

  1. vymyslite si ľubovoľnú vetu a v hesle použite začiatočné písmená slov vety. Niektoré z nich napíšte veľkými písmenami a niekde v hesle použite aj číslice
  2. použite slovo, v ktorom nahradíte niektoré znaky číslami a/alebo špeciálnymi znakmi
  3. použite dobrý generátor hesiel (pozor, niektoré môžu generovať uhádnuteľné heslá!). Ja občas používam program "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äť ;-)

5.4.4.1.4 Obmedzenie prístupu používateľov

Okrem vyššie uvedených bodov sa treba postarať o:

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é.

5.4.5 Získanie rootovského hesla

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.

5.4.5.1 Detekcia zneužitia rootovského konta

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".

5.4.5.2 Ochrana proti zneužitiu rootovského konta

  1. proti získaniu rootovského hesla sa možno brániť tými istými prostriedkami, ktoré sme si opísali vyššie pri bežných používateľských heslách.
  2. súbor "/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.
  3. v konfiguračnom súbore démona "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".
  4. v súbore "/etc/ftpusers" vymenujte používateľov, ktorí sa nebudú môcť prihlásiť cez ftp (na každom riadku jeden).

3 x NIKDY

  1. nikdy nepíšte rootovské heslo do mailu
  2. nikdy sa neprihlasujte bez šifrovania
  3. nikdy nedávajte rootovské heslo ľudom, ktorým nedôverujete a/alebo ktorí nemajú potrebné znalosti o správe systému.

5.4.6 Využitie známej/zverejnenej chyby

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.

5.4.6.1 Zneužitie chybnej (defaultnej) konfigurácie

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!

5.4.6.1.1 Ochrana proti zneužitiu chybnej (defaultnej) konfigurácie

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.

5.4.6.2 Buffer overflow (preplnenie zásobníka programu)

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.

TODO: obrázok a ďalšie informácie!

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.

5.4.6.3 Odporúčania a prevencia

  1. používanie programov, ktoré patria k tým bezpečnejším (a u ktorých to dosvedčuje prax!). Napríklad používanie mailového servera "Postfix" namiesto "sendmailu"
  2. používanie kernelových patchov, ktoré obmedzujú využitie útokov "buffer overflow", napr. "Grsecurity" (je zakázané spúšťanie kódu z pamäťových stránok, ktoré obsahujú zásobník)
  3. používanie programov, ktoré umožňujú bežať s čo najmenšími privilégiami (najlepšie používateľ vytvorený na tento účel) a nie s právami roota
  4. vytvorenie vlastných vyhradených adresárov pre démonov (chroot) - využitie chyby bude veľmi obmedzené na rozsah vyhradeného adresára
  5. pravidelné (najmenej raz týždenne, ale odporúčam aspoň raz za dva dni!) zisťovanie informácií o bezpečnostných rizikách pre Vašu distribúciu a/alebo programy, ktoré používate. Existujú v zásade tri dobré zdroje týchto informácií:
  6. pravidelná aktualizácia programov bežiacich na serveri, najmä po odhalení závažnej chyby!
  7. pre programátorov: ak používate pamäť pevnej veľkosti (nie dynamicky alokovanú) nespoliehať sa na to, že údaje získané od používateľa (vstup, vstupné parametre, hodnoty v konfiguračných súboroch) alebo zo siete nepresiahnu pevne zadanú veľkosť a vždy kontrolovať ich veľkost pred uložením, a/alebo uložiť iba toľko údajov, koľko sa zmestí do vyhradenej pamäte! To platí pre programovacie jazyky, ktoré za Vás nerobia automatickú dynamickú alokáciu pamäte, napr. C. V Perle sa s podobnými vecami nemusíte vôbec zaťažovať.
Pozri aj: Linux Security-HOWTO (linka bola opravená)!
Späť (Nástroje na sledovanie systému) Obsah Ďalej (Služby mailového servera)

© Ivan "VIX" Noris, 2002-2007
mail: vix (zavinac) deja-vix bodka sk