9/3 BEZPEČNOST V LINUXU

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, str. 1 9/3 BEZPEČNOST V LINUXU 9/3.1 Linuxové jádro, instalace Linuxu 9/3.2 Záplatování systému 9/3.3 Uživatelské účty 9/3.4 Bezpečnost na úrovni souborového systému 9/3.5 Vzdálená správa systému 9/3.6 Firewall 9/3.6.1 Příklad skriptu konfigurace firewallu pro jednoduché firemní použití 9/3.6.2 Příklad použití tabulky NAT na firemním firewallu 9/3.6.3 Příklad použití tabulky Mangle 9/3.7 IDS 9/3.8 Nessus 9/3.9 Tripwire 9/3.10 Omezování síťového provozu 9/3.10.1 Úvod 9/3.10.2 Omezování provozu na úrovni protokolu TCP/IP 9/3.11 Linux - aktuální trendy 9/3.11.1 Současné verze Linuxu a distribuce kvûten 2006

část 9, díl 3, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ 9/3.11.2 Zabezpečení běžících služeb 9/3.11.3 Zabezpečení síťové komunikace 9/3.11.4 Zabezpečení elektronické pošty kvûten 2006

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 1, str. 1 9/3.1 LINUXOVÉ JÁDRO, INSTALACE LINUXU Linuxové jádro je to, co se stará opřidělování hardwarových prostředků jednotlivým programům, řídí správu paměti, řídí procesy atp. Je to skutečné jádro systému. Při konfiguraci dříve nebo později narazíme na verzi jádra. Jádro je vyvíjenovněkolikavětvích, kdekaždá větev má svého správce. Jednotlivé řady se od sebe odlišují číslem verze, a to ve formátu X.Y.Z, kde X je major verze jádra, Y je minor verze jádra a Z je pak aktuální vydání jádra v řadě X.Y. Je-li číslo Y sudé, pak se jedná o stabilní řadu, což znamená, že v jádře nejsou žádné známé chyby a použití tohoto jádra by nemělo způsobitžádné problémy, například ztrátu dat na disku. Je-li Y liché, jedná seořadu vývojovou. Ta slouží vývojářům jádra k přidávání nových vlastností a jejich testování. Novávlastnostmůže býtv pozdější vývojové verzi bez náhrady odstraněna. Z vývojové větvě sečasem stane větev stabilní. Linuxové jádro prosinec 2003

část 9, díl 3, kapitola 1, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ Instalace Současnou stabilní větvíjádra je 2.4 a vývojovou větví je 2.5. Kromě těchto standardních větví ještě existují další, spravované různými vývojáři. Poměrně známá je tzv. ac větev spravovaná jedním z vývojářů jádra Alanem Coxem. Tyto větve vznikly proto, že do stabilní řady nepronikly některé vlastnosti z různých důvodů a autor tak vytvořil svou větev s tím, že onu vlastnost přidal. Krom toho existuje velké množstvípatchů (záplat) do jádra. Při jejich aplikaci je nutná nejvyšší opatrnost, špatně napsanýpatch může ohrozit bezpečnost a stabilitu celého systému z důvodů nekompatibility přidávané vlastnosti se stávajícími. Většina distribucí používá jádra opatchovaná. Je to proto, že přidávají některé bezpečnostní prvky, rozšiřují počet ovladačů, atp. Takovéto jádro bývá prověřeno na různém množství hardwaru, který vlastní vývojáři nemusí mít k dispozici. Obecně platí, že pokudnovájádra neopravují nějakou bezpečnostní chybu či pokud nemáme problémy se starým, není důvod opouštět jádro, které nám nabízí distributor. Instalace Linuxu se v mnohém liší od světa proprietárního softwaru. V prvé řadě lze instalovat několika způsoby,nejenobvyklýmpomocícdrom disku. Lze použít taktéž instalaci z disku, kdy potřebný software na disk před instalací nakopírujeme, lze použít instalaci z FTP serveru, pokud máme k dispozici připojení k Internetu (či ksíti, kdesedanýftp server nachází), lze použít instalaci přes HTTP atp. Před instalací je nutné si rozvrhnout rozdělení disku. UNIXové systémy mají charakteristickou adresářovou strukturu a Linux se jí drží. Kořenem celého prosinec 2003

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 1, str. 3 adresářového systému je adresář /. V něm se nachází další adresáře, z nich nejvýznamnější jsou /etc, /bin, /tmp, /var, /home a /usr. Vadresáři /etc se nachází většina konfiguračních souborů, /bin je adresář určený základním utilitám systému, /tmp pak slouží k dočasnému vytváření souborů, /var je adresář, kam programy umist ují logovací soubory, /home je adresář určenýjednotlivýmuživatelům a vadresáři /usr je pak umístěn zbytek programového vybavení systému. Na serverových systémech je z hlediska bezpečnosti vhodné, aby nebyly všechny adresáře umístěny na jednom diskovém oddílu. Do adresáře /var se neustále zapisuje a například při náhlém výpadku proudu se může poškodit struktura diskového oddílu, na který se právě zapisovalo. Bude-li adresář /var na zvláštním diskovém oddílu, pravděpodobnost, že se poškodí struktura diskového oddílu, na kterém jsou ostatní adresáře, je nízká. Další situace: diskový oddíl, na kterém je adresář /var, semůže zaplnit například proto, že některý program vytvoří příliš velký logovací soubor. Pokud bude na stejném diskovém oddíle adresář /var a /home avadresáři /home/ftp bude moci anonymní uživatel pro FTP přístup ukládat soubory a takový uživatel uloží příliš velký soubor a diskový oddíl zaplní, ostatní programy pak nebudou moci zapisovatdo svých logovacích souborů v adresáři /var. Podobných situací nastává při běhu systému více. Jak tedy rozdělit disk například pro firemní server, který přijímá poštu pro 200 uživatelů, je proxy serverem pro přístup na Internet a zároveň firewallem? Pro adresář / vyhradíme minimálně 700 MB volného místa. Na další diskový oddílumístíme adresář /var, kde se budou vytvářet logovací soubory a ostatní věci kromě prosinec 2003

část 9, díl 3, kapitola 1, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ adresářů /var/spool/squid a /var/spool/mail. Na další diskový oddíl umístíme /var/spool/mail, kam se budou ukládat emaily uživatelů. Pokud bude mít každý uživatel průměrně 15 MB velkou emailovou schránku a máme 200 uživatelů, budeme potřebovat diskový oddíl velký téměř 3 GB. Na další diskový oddíl (a nejlépe na další disk) umístíme adresář /var/spool/squid, kde proxy server vytváří svou cache. Čím větší cache, tím více tento server ulehčuje kapacitě linky. Volba 1 GB je dostačující. Poslední adresář, který si zaslouží vlastní diskový oddíl, je adresář /home, kam mohou uživatelé ukládat svá data. Tuto velikost volte podle konkrétní situace. Při samotném rozdělování bychom měli vzít v úvahu swapování. Linuxové jádro umožňuje swapovat jak do souboru, tak přímo do diskového oddílu. Platí, že swapování do diskového oddílu je rychlejší, a proto pro swap vyhradíme další diskový oddíl. Chceme-li navíc zvýšit rychlost systému, je vhodné oddíly swap a ostatní mít na zvláštních discích. Jak se však ukazuje, praxe firem je taková, že celý systém běží na jednom disku. Pak je rozdělujme na /, /var, swap a /home. Distribuce, at už během instalace či po prvním restartu počítače, umožňujínastavit formu uložení hesel v systému. Linux používá jako každý UNIXový systém pro informace o účtech na systémusoubor /etc/passwd. Hesla k jednotlivým účtům však umožňuje uložit v odděleném souboru /etc/shadow, který jenavíc čitelný pouze pro uživatele root, což jeuživatel s administrátorským oprávněním. Dále je doporučenoukládat tato hesla v zašifrovaném tvaru, dnes typicky pomocí algoritmu MD5. prosinec 2003

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 1, str. 5 Při instalaci systému je vhodné vybrat jen ty balíky, které budemeskutečněpoužívat. Například na serveru se vůbec nemusí nacházet překladač systému či FTP klient. Virus z roku 2002, který napadal chybu v implementaci OpenSSL a do systému pronikal přes protokol https, tak zapsal do adresáře, kam mohl zapisovat, i daemon https (byl to obvykle adresář /tmp), zkompiloval (čili byla nutná přítomnostpřekladače) příslušný program a jím potom zahltil linku do Internetu. Kdyby na systému nebyl překladač, tak by sice systém byl kompromitován, ale útočník by pomocí tohoto viru nedokázal zahltit linku. Administrátor navíc v tomto případě neprováděl okamžitou aktualizaci, avšak jednotýdenní. Kdyby tedy na systému nebyl překladač, při nejbližšíaktualizaci by se problém odstranil. Platí, že čím méně zbytečného softwaru, tím méně potenciálních zbytečných chyb. prosinec 2003

část 9, díl 3, kapitola 1, str. 6 BEZPEČNÁ POČÍTAČOVÁ SÍŤ prosinec 2003

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 2, str. 1 9/3.2 ZÁPLATOVÁNÍ SYSTÉMU Po instalaci serveru musíme vzít v úvahu jednu důležitou věc. Instalační média distribuce (at již obsah CDROM, či obsah FTP serveru) se obvykle neaktualizuje. Případnévydanézáplaty k distribuci se zveřejňují na stránkách distributora a jsou obvykle dostupné přes FTP server. Proto je po čisté instalaci systému nutné zkontrolovat, zdali již nejsou vydány záplaty, a pokud ano, je nutné je nainstalovat. Většina distribucí má nějaký mechanismus pro automatickou instalaci bezpečnostních záplat. Je nutné se tedy obrátit na dokumentaci k příslušné distribuci. Pro bezpečnost systému je pravidelné záplatování klíčové, žádný software není 100% bezpečně napsaný a dříve nebo později se nějaká bezpečnostní chyba vyskytne. Systém správy balíků Debianu patří rozhodně k těm nejlepším a tudíž ani automatické záplatování pro Automatické záplatování systému v Debianu prosinec 2003

část 9, díl 3, kapitola 2, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ Automatické záplatování v RedHatu něj nepředstavuje problém. Zjištění přítomnosti nových opravných balíků můžemeprovéstpomocí příkazu apt-get update, stáhnutí a nainstalování balíků se provede pomocí příkazu apt-get upgrade. Tyto dva příkazy je vhodné umístit do nějakého skriptu a ten nechat v pravidelných intervalech spouštět z crond (program pro automatické spouštění programů v daných intervalech). Tím zajistíme automatickou aplikaci záplat do systému. Ovšem pozornostje nutnévěnovat serverům, z kterých balíky stahujeme (viz soubor /etc/apt/sources.list), Debian standardně nepodporuje digitální podpisy u balíků, tudíž se vpřípadě kompromitace stroje, z kterého stahujeme balíčky, může do systému zcela nepozorovaně dostat backdoor! V posledníverzi Debianu již nástroje na ověřováníintegrity existují, nicméně většina balíků nenípodepsána. To by mělanapravitpříští verze Debianu (Sarge). K automatickému záplatování v této distribuci slouží nástroj up2date. Pro jeho používání je nutná registrace v RedHat Network na webovských stránkách společnosti nebo přímo po instalaci systému. V konfiguraci nástroje up2date pak lze nastavit, zda nás má upozornit na nové záplaty, nebo je má i stáhnout a nebo je dokonce i nainstalovat. Samotná automatická instalace může být ošidná, protože se může stát, že se změní volby v konfiguračním souboru. Pak záleží na tom, zda systém zazálohuje starý konfigurační soubor a restartuje službu s novým (a defaultním) konfiguračním souborem nebo nový konfigurační soubor uloží pod jiným jménem a pak na to upozorní například emailem. Je vhodné nechat si záplatu stáhnout a o jejím updatu rozhodnout ručně. prosinec 2003

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 2, str. 3 Firma RedHat nyní do své testovací distribuce zahrnula nástroj yum azdáse, ze balík up2date bude z distribuce tímto nástrojem vytlačen. Je tedy obecně vždy nutné podívat se do aktuální dokumentace k systému a zjistit, jaký mechanismus aplikace záplat je používán. prosinec 2003

část 9, díl 3, kapitola 2, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ prosinec 2003

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 3, str. 1 9/3.3 UŽIVATELSKÉ ÚČTY Databáze uživatelských účtů se na Linuxu nachází v souboru /etc/passwd. Tento soubor je čitelný všemi uživateli a obsahuje základní informace o uživatelském účtu jako např. unikátní IDúčtu (UID user ID), číslo skupiny (GID), umístění domovského adresáře a použitý shell (interpretr příkazového řádku). Shell bývávětšinounastaven na /bin/sh či jiný interpretr příkazového řádku, ale pokud chceme zabránit danému uživateli v přihlášení na stroj, nastavíme mu shell na program typu /bin/false, který se okamžitě ukončí. To je efektnivní např. v případě, kdy chceme zabránituživatelům majícím na serveru poštovníúčet vpřihlášení. prosinec 2003

část 9, díl 3, kapitola 3, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ prosinec 2003

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 4, str. 1 9/3.4 BEZPEČNOST NA ÚROVNI SOUBOROVÉHO SYSTÉMU Linux standardně nepodporuje ACL (Access Control List), tudíž jsou možnosti nastavení práv u jednotlivých souborů/adresářů omezenější. Každý soubor má svého vlastníka a skupinu vlastníků. Můžeme definovat oddělená práva pro vlastníka, skupinu a pro ostatní uživatele. Můžeme pro něnastavit právo čtení, zápisu a spouštění daného souboru. U adresářů je nutné povolit provádění, jinak není možné do adresáře přejít. Pokud má uživatel právo provádění u daného adresáře, ale nikoliv právo čtení, nemůže si vypsat seznam souborů v tomto adresáři. Dále pak můžeme programům přiřadit příznak setuid či setgid, což způsobí, že program bude spouštěn s efektivním UID vlastníka, popř. s EGID vlastnické skupiny. Nastavování těchto příznaků je nutno provádět velmi obezřetně, zvlášt u programů, jejichž vlastníkem je root. Nevhodné nastavení SETUID příznaku u programu vlastněného uživatelem root může velmi poškodit bezpečnost prosinec 2003

část 9, díl 3, kapitola 4, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ ACL práva celého systému. Pro změnu práv používáme především utilitu chmod práva soubor/adresář. Práva můžeme zadat bud jako čtyři čísla, kde první číslo je součet čísel 1 (příznak sticky), 2 (setgid), 4 (setuid). Zbylá tři čísla určují práva pro uživatele, skupinu a ostatní uživatele. Získámejejakosoučet těchto čísel: 1 (provádění), 2 (zápis) a 4 (čtení). Druhou možností nastavení práv je použití textového zápisu se syntaxí: [ugoa][+-=][rwxst]. První část určuje, komu chceme daná práva nastavit (u uživatel, g skupina, o ostatní, a všichni), následující část specifikuje operátor (+ práva přidá, - práva odstraní, = práva nastaví). A konečně poslední část specifikuje jednotlivá práva.význam jednotlivýchpísmen je následující: r čtení, w zápis, x provádění, s setuid/setgid, t sticky. Nastavení práv je typicky podstatné u konfiguračních souborů.představme si, že útočníkproniknedosystému pod identitou uživatele apache. Protože však uživatel apache nebude mít nějaká další práva, bude mít útočník omezené možnosti. Pokud ale bude mít přístup ke konfiguračním souborům jiných programů, které na serveru běží, může se pokusit do systému proniknout přes tyto jiné programy, bude-li znát jejich konfiguraci či například nainstalovanou verzi. Je tedy vhodné dodržovat zásadu, že přístup ke konfiguračním souborům k http serveru nesmí mít uživatel, pod jehož identitou je spuštěn FTP server a naopak. Vněkterých případech není možné práva nastavit pomocí klasických UNIXových práv a je nutné použít ACL. Bohužel ACL práva nejsou součástí současné stabilní řady jádra 2.4.x, a tudíž se administrátor musí uchýlit k aplikaci záplat do zdrojových souborů jádra a následně jádro rekompilovat. Naštěstí nová jádra prosinec 2003

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 4, str. 3 řady 2.6.x již ACL práva podporujínativně. Nicméně v současné době ještě neexistuje stabilní jádro z této řady, tudíž jejich použití na produkčních serverech není doporučováno. prosinec 2003

část 9, díl 3, kapitola 4, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ prosinec 2003

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 5, str. 1 9/3.5 VZDÁLENÁ SPRÁVA SYSTÉMU Stejně jako ostatní UNIXové operační systémy je i Linux kompletně spravovatelný přes sít. K vzdálenému přihlášení nastrojedříve sloužil protokol telnet, dnes není použití tohoto protokolu doporučováno. Telnet neobsahuje žádné autentizační ani šifrovací mechanismy, kdokoliv na síti může odposlechnout komunikaci mezi klientem a serverem a dostat se tím k heslům. Řešením je použití SSH (Secure shell). SSH je protokol, který zcela nahrazuje telnet, na rozdíl od něj však využívá kryptografie, veškerá komunikace mezi klientem a serverem je šifrována. SSH zajišt uje též ověřováníidentity stroje, na který se přihlašujeme. Při prvním přihlášení si SSH uloží veřejný klíč serveru, a pokud dojde ke změně veřejného klíče druhé strany, SSH okamžitě ukončíspojení, protože důvodem změny veřejného klíče může být např. pokus o útok man-in-the-middle. Dále pak SSH podporuje několik možností autentizace uživatele. Kromě prosinec 2003

část 9, díl 3, kapitola 5, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ Bezpečná konfigurace sshd tradniční možnosti zadání hesla (které je samozřejmě posíláno šifrovaně) může být klient v protokolu SSH 2 autentizován pomocí RSA/DSA klíče, popř. pomocí hostbased autentizace, kdy server nejprve ověří klíč druhého stroje a poté prohledá soubory jako /etc/hosts.equiv, ~/.rhosts, ~/.shosts, zda je v nich povoleno přihlášení tohoto uživatele z daného stroje (viz man 5 hosts.equiv). Pokud tomu tak je, SSH přihlásí uživatele bez nutnosti, aby zadával heslo. Tato metoda autentizace je používána velmi zřídka a místo ní se používá autentizace pomocí páru RSA/DSA klíčů. Ta funguje tak, že klient pomocí privátního klíčeuživatele podepíše identifikátoraktuálního spojení se serverem a pošle ho serveru. Server prohledá databázi uživatelových klíčů použitelných pro tuto autentizaci, a pokud se mu podaří pomocí některého z nich ověřit podpis, tak klienta přihlásí. Pro Linux existuje vícero implementací protokolu. Nejznámější je implementace OpenSSH, kterou najdeme ve většině distribucí. Obsahuje jak SSH klient, tak server. Podporuje obě existující verze protokolu (SSH 1 a SSH 2). OpenSSH bylo vyvinuto v rámci projektu OpenBSD, ale je k dispozici pro značné množství dalších operačních systémů. Konfiguraci sshd (SSH daemon, server implementující SSH protokol) bychom měli věnovat při zabezpečování serveru zvýšenou pozornost, jelikož sshd běží zčásti pod uživatelem root a pro většinu serverů je jeho přítomnost nutností málokteré servery jsou dnes spravovány pouze lokálně.navíc bylo v minulosti v sshd objevenoněkolik kritických bezpečnostních chyb, některé z nich mohl útočník dokonce využít pro získání práv uživatele root na daném stroji. prosinec 2003

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 5, str. 3 Poměrně osvědčenou metodou zabezpečení je změna portu, na kterém sshd poslouchá. Volí senáhodný neprivilegovaný port (tzn. vyšší než 1024). Tím se velice zvýší šance, že případný útočník neobjeví na daném stroji spuštěné sshd. Pro jeho objevení by případný hacker musel oscannovat všechny porty na daném stroji (kterých je 2 16 ), což by pravděpodobně bylo zachyceno IDS. Další často prováděnou technikou je omezení přístupu na sshd pomocífirewallu. Typické je povolenípřístupu jen z některých (důvěryhodných) serverů. Pozornost věnujme též volbě UsePrivilegeSeparation v sshd config, ta by vždy měla být nastavena na hodnotu yes, což způsobí, že po přihlášení uživatele sshd zahodí rootovská práva a proces dále pracuje pod uid přihlášeného uživatele. Toto nastavení výrazně zvyšuje bezpečnost celého sshd. Tato forma autentizace je vhodná zejména v případě, že nechceme zadávat při každém přihlášeníheslo, což je užitečné zejména při použití ssh ve skriptech, které potom nemusejí být interaktivní. Prvním krokem je vygenerování páru klíčů. Slouží k tomu program ssh-keygen -t algoritmus. Algoritmem může být bud rsa nebo dsa, eventuálně můžeme ještě specifikovat hodnotu rsa, cožzpůsobí vygenerování klíče pro SSH1 RSA autentizaci. Vygenerovaný veřejný klíč pro SSH 2 se uloží do souboru ~/.ssh/id (rsa dsa).pub, privátní klíč pak do ~/.ssh/id (rsa dsa).pub. Veřejný klíč poté nakopírujeme na cílový stroj do souboru ~/.ssh/authorized keys (či jiného souboru, pokud je standardní jméno změněno v sshd config Použití autentizace pomocí páru RSA/DSA klíčů v OpenSSH prosinec 2003

část 9, díl 3, kapitola 5, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ Standard IPsec pomocí volby AuthorizedKeysFile) a zkusíme se přihlásit. Vpřípadě, že nebudete automaticky přihlášeni, zkontrolujte přístupováprávak svému domovskému adresáři. Z bezpečnostních důvodů funguje tato autentizace jen v případě, že do něj můžete zapisovat jen vy. IPsec je standard rozšiřující IP protokol o autentizaciašifrování. Sestává sezněkolika protokolů implementovaných nad protokolem IP. V praxi se nejčastěji používá protokol ESP (Encapsulating Security Payload) používaný kšifrování dat i zajištění integrity přenášených dat. Méně používaný je protokol AH (Authentication Header), který zajišt uje pouze autentizaci přenášených paketů. IPsec můžefungovatvedvourežimech transportním a tunelovacím. Transportní mód se používá při komunikaci dvou strojů, naproti tomu v tunelovacím módu se přenáší jako data ESP/AH paketu celý zdrojový IP paket včetně hlaviček. Pomocí tunelovacího módu je možné vytvořit bezpečnou VPN mezi dvěma sítěmi přes Internet. Použití IPsec je pro aplikace transparentní, vše je implementováno na úrovni vrstvy IP v jádře operačního systému. V tunelovacím módu je IPsec též zcela transparentní pro počítače na subsítích, mezi nimiž je tunel vytvořen. Další nespornou výhodou IPsec je jeho rozšířenost oproti jinýmpodobnýmřešením je IPsec standardizován a je k dispozici na většině používaných platforem. Kromě těchto dvou protokolů se používá ještě protokol IKE, jehož úkolem je autentizace obou stran a prosinec 2003

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 5, str. 5 následné vytvoření bezpečnostních asociací. Bezpečnostní asociace (SA, Security Associations) popisují jednosměrnou relaci mezi dvěma stroji. Jednotlivé asociace jsou definovány zdrojovou a cílovou IP adresou, unikátním ID nazývaným SPI a bezpečnostním protokolem (AH nebo ESP). Úkolem IKE je též autentizace obou stran. Autentizaci je možné provést několika způsoby, nejjednodušší je tzv. PSK (pre-shared key) autentizace, při níž obě strany sdílí určený klíč, který se použije spolu s daty paketu na spočítání hashovací hodnoty, kterou stejným způsobem druhá strana ověří. Častější je však autentizace pomocí párů certifikátů, která využívá možnosti asymetrické kryptografie. IPsec není v Linuxu standardně k dispozici. Pro jeho instalaci se musíme uchýlit k aplikování záplat do jádra. Nejrozšířenější implementací IPsec pro jádra 2.4.x a starší 2.2.x je FreeS/WAN. Krom FreeS/WAN existuje ještě tzv. SuperFreeS/WAN, který se liší přítomnosti několika záplat, které nebyly přidány do oficiální vývojové větve FreeS/WAN. Asi nejdůležitější záplatou, kterou Super FreeS/WAN obsahuje je podpora X.509 certifikátů při autentizaci v IKE. V jádrech 2.5.x a 2.6.x již nalezneme nativní implementaci, která používá konfigurační nástroje(a IKE daemon racoon) z projektu KAME. Konfigurace IPsec na strojích s těmito jádry je tudíž hodně podobná té v Open/FreeBSD (či dalších operačních systémech, pro něž existují KAME patche). Implementace IPsec v Linuxu prosinec 2003

část 9, díl 3, kapitola 5, str. 6 BEZPEČNÁ POČÍTAČOVÁ SÍŤ prosinec 2003

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 6, str. 1 9/3.6 FIREWALL Firewall je služba, která naúrovnipaketovýchspojení filtruje provoz na sít ových rozhraních (kartách) počítače. Jeho úkolem je definovat přístup k jednotlivým počítačům a službám na nich běžících. Firewall tedy nekontroluje obsah jednotlivých paketů, ale vlastnosti paketu jako zdrojová adresa, cílová adresa, zdrojový port, cílový port atp. Firewall může být dále stavový, což znamená, že pozná, které pakety patří ke kterémukonkrétnímuspojení. Firewall tak například může ukončit či zařídit zpomalení spojení, které trvánapříklad déle než 5 minut nebo kterým proteklo více než určité množství dat. Obecně platí, že bychom měli povolovat jen služby, které fungovat mají, a ostatní služby zakázat. Například pokud se za firewallem nachází SMTP server, tak bychom měli povolit jen SMTP spojení na onen server a dále SMTP spojení, která onen server sám zahajuje. Obvyklou chybou administrátorůbývá,že směr ze Firewall prosinec 2003

část 9, díl 3, kapitola 6, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ prosinec 2003 SMTP serveru neomezují, protože věří zabezpečení serveru. To je chyba. Pokud útočník server napadne, tak bude moci při málo restriktivním nastavení firewallu navazovat spojení s ostatními svými servery na jiném než SMTP portu. Pokud však bude firewall restriktivní, bude muset útočník komunikovat po portech určených pro SMTP protokol. To však poznáme, protože nám přestane chodit pošta, nebo se alespoň začne projevovat nestandardně. A tak zjistíme, že se nám na SMTP serveru něco děje. Správná konfigurace firewallu je pro zabezpečení systému poměrně důležitá. V novějších jádrech (řady 2.4.x a vyšší) nalezneme velmi propracovaný stavový firewall zvaný netfilter. Firewall nastavujeme pomocí utility iptables. V netfilteru existuje několik tabulek, každá tabulka obsahuje seznamy (řetězce) jednotlivých pravidel. Seznam tabulek, jež budou k dispozici, je závislý na konfiguraci jádra (zda byly zakompilovány, popř. zkompilovány jako moduly). Při zpracování paketu se procházejí jednotlivá pravidla v daném řetězci pravidel, pokud dané pravidlo platí, provede se u něj specifikovaná akce, což může být bud skokdo jinéhořetězce nebo předání paketu příslušnému modulu netfilteru (pro úplnost, některé z akcí jsou zpracovávány přímo v netfilteru). Nejběžnější používanou tabulkou je filter. Tato tabulka se použije, pokud explicitně nespecifikujeme jinou tabulku parametrem -t u iptables. Tabulka slouží především k filtrování paketů. V této tabulce jsou definovány následující standardní řetězce pravidel: INPUT příchozí pakety OUTPUT lokálně generované pakety

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 6, str. 3 FORWARD pakety routované přes tento stroj. Další řetězce si můžeme definovat pomocí volby -N u iptables, pakety do nich budou zařazovány v případě, že jejich identifikátor specifikujeme jako akci, která semáprovést při platnosti právě zpracovaného pravidla. Krom standardní tabulky filter existují další tabulky první z nich, tabulka mangle, se používá především ve spojení sqosnaoznačování a pozdější klasifikaci paketů pomocí filtrů v QoS. Do poslední tabulky, nat, se zařazují pakety vytvářející nové spojení. Jak již název napovídá,tabulka se používá pro NAT, tedy pro překlad adres. Syntaxe pro přidání pravidla je iptables [-t tabulka] -A/-I řetězec volby -j akce Pokud nespecifikujeme tabulku parametrem -t, použije se tabulka filter. Jak -A, tak -I přidávají pravidlo dodanéhořetězce pravidel. Lišíseumístěnímnového pravidla. -A přidává pravidlo vždy na konec řetězce, kdežto -I umožňujeurčit pozici, na kterou se pravidlo vloží, dalším parametrem. Pokud za -I nenásleduje číslo, je pravidlo vloženo na první pozici v řetězci. Akcí může být bud identifikátor řetězce pravidla nebo některá z akcí implementována v netfilteru (popř. implementovaná jako modul). Uvedeme si některé nejdůležitější volby pro kategorizaci paketu. Pokud všechny uvedenévolby odpovídají právě zpracovanému paketu, je provedena příslušná akce. -p protokol Definice pravidel firewallu Základní volby pro kategorizaci paketů prosinec 2003

část 9, díl 3, kapitola 6, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ Volby pro protokol TCP prosinec 2003 IP paket má v hlavičce protokol nastavený na hodnotu protokol. Můžeme specifikovat bud číselné vyjádření nebo identifikátor protokolu (např. tcp, udp, icmp,...). -s adresa/maska IP paket má nastavenou zdrojovou IP na adresa,nebo leží nadanésubsíti. -d adresa/maska Totéž, jen pro cílovou IP adresu -i iface Sít ové rozhraní, z kterého byl paket přijat. Volba je platná jen v řetězcích INPUT, FORWARD a PRE- ROUTING. -o iface Sít ové rozhraní, na které bude paket poslán. Volba je platná jen v řetězcích OUTPUT, FORWARD a POST- ROUTING. Tím nejsou možnosti iptables pro kategorizaci paketu samozřejmě zdaleka vyčerpány. Další volbyjsou přístupné pomocí modulů. Modul může být natažen bud implicitně uvedením protokolu pomocí volby -p nebo explicitně použitím volby -m modul. --source-port [!] port1:port2 TCP paket má zdrojový port v intervalu port1 až port2.místo intervalu můžeme specifikovat jen jeden port. Vykřičník před specifikací portu způsobí negaci tohoto pravidla. --destination-port [!] port1:port2 Totéž, jen pro cílový TCP port.

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 6, str. 5 --tcp-flags [!] flag1,flag2,... f1,f2,... První parametr určuje, které TCP příznaky analyzovat a druhý parametr určuje, které příznaky musí být nastaveny. [!] --syn TCP paket má nastavený SYNpříznak a nenastavený ACK a RST příznak. Pakety s takovými příznaky se používají v první fázi navázání TCP spojení. --source-port port1:port2 Platí, pokud se zdrojový port nachází v intervalu port1 port2. Popř. můžeme specifikovat pouze jeden port. --destination-port port1:port2 Totéž procílový UDP port. Velké množství dalších voleb pro kategorizaci paketů jepřidáváno jednotlivými moduly. Popis standardních voleb naleznete v man 8 iptables, popř. na www.netfilter.org. Netfilter není jen jednoduchý paketový filtr, ale plnohodnotný stavový firewall. Pokud chceme paket klasifikovat v širším kontextu, využijeme extenzi state z netfilteru. Ta nám přidá volbu --state, které můžeme jako první parametr specifikovat všechny stavy, v kterých semůže spojeníasociovanés aktuálnězpracovaným paketem nacházet. Možné stavy jsou: INVALID paket není asociováns žádným spojením. NEW paket se snaží o navázání nového spojení. ESTABLISHED paket je součástí již vytvořeného spojení. Volby pro protokol UDP Stavový firewall prosinec 2003

část 9, díl 3, kapitola 6, str. 6 BEZPEČNÁ POČÍTAČOVÁ SÍŤ Akce prováděné s pakety Bezpečná konfigurace firewallu RELATED paket se snaží o navázání nového spojení, které je vázané na nějaké existující (např. poslání ICMP paketu). V netfilteru jsou definovány tyto základní akce s pakety: ACCEPT paket bude akceptován. DROP paket bude zahozen. RETURN ukončí zpracování tohoto řetězce pravidel. Další akce jsou definovány moduly, viz man 8 iptables Obecně platí, že na každém serveru by neměla být puštěna žádná nepoužívaná služba. Podobné pravidlo lze přenést i do kontextu firewallu, z Internetu by neměla být přístupná žádná služba, která zněj nebude používána. Popřípadě je vhodné některé služby povolit jen zip,zkterých budou využívány. Pokud chceme zakázat nějakou službu, měli bychom na to použít akci DROP, která paket kompletně zahodí. Lepším řešením u protokolu TCP může být použití extenze REJECT doplněné parametrem --reject-with tcp-reset. To způsobí, že při připojení na daný port se vrátí RST paket, tudíž z pohledu z venku je chování analogické se situací, kdy by žádný firewall nainstalovaný nebyl, ale na daném portu žádný daemon neposlouchal. Doporučuje se též využívat extenze STATE (zvláště u protokolu TCP), při skenování TCP portů (a vzdálené identifikaci TCP/IP implementace) se často používají pakety s abnormálními příznaky, tudíž neníod věci TCP pakety ve stavu INVALID zahazovat. prosinec 2003

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 6.1, str. 1 9/3.6.1 PŘÍKLAD SKRIPTU KONFIGURACE FIREWALLU PRO JEDNODUCHÉ FIREMNÍ POUŽITÍ Ukázkový skript se spouští s parametrem start pro nastavení firewallu. Pokud skript spustíme parametrem stop, filtrovací služby jádra se nastaví na hodnoty, které žádným způsobem neomezují průchod paketů přes daný počítač. Představme si, že máme firemní router, který je jedním sít ovým rozhraním připojen do Inetrnetu (má například od poskytovatele přidělenu veřejnou adresu 164.218.1.10) a druhým sít ovým rozhraním je připojen do vnitřní firemní sítě. Tato sít má neveřejnou adresu 192.168.0.0/24 a náš router má adresu 192.168.0.1. Na našem routeru pak provozujeme pro účely počítačů z vnitřní sítě i z internetu poštovní server, doménový server, webový server, pop3 server. Dále pak pro vybrané zákazníky ssh server pro vzdálený přístup a ftp srpen 2004

část 9, díl 3, kapitola 6.1, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ server. Nakonec pouze pro počítače ve vnitřní síti provozujeme proxy server a dhcp server. Požadujeme, aby uživatelé mohli na Interentu používat webové služby a ftp služby, avšak pouze přes proxy server, který máme za tímto účelem na routeru nakonfigurovaný. Žádný jiný přístup uživatelé do internetu mít nebudou. Pořadujeme navíc, aby z vnitřní firemní sítě neměl na internet, a tudíž na službu proxy serveru, přístup uživatel s počítačem 192.168.0.28. Dále požadujeme, aby nanáš server mělapřístup službou ssh externí firma z adresy 123.45.67.8 (například nám spravuje nějakou běžící aplikaci) a dále aby na náš serverměla přístup na službu ftp tatáž firmaa dále jiná firma ze serveru 123.45.67.9 (například za účelem správy obsahu webových stránek), a to službou ftp. Výše uvedené požadavky jsou skutečně jednoduché a na jejich splněnínám budestačit konfigurace pravidel v tabulce filter. Na řádcích 3 až 13 (viz ukázku skriptu s číslovanými řádky na konci kapitoly) si nastavíme některé proměnné: ext_dev="eth1" ext_ip="164.218.1.10" int_dev0="eth1" int_ip0="192.168.0.1" int_net0_0="192.168.0.0/24" pc1="192.168.0.28" sauvignon="123.45.67.8" ogebenec="123.45.67.9" fw_prefix=" Netfilter" srpen 2004

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 6.1, str. 3 Je to praktické zněkolika důvodů. Například pokud bychom změnili adresaci vnitřní sítě, tak tuto změnu stačí provést pouze v definici oné proměnné a nikoliv na všech místech ve skriptu. Také jméno sauvignon nám a nebo někomu, kdo bude skript upravovat, řekně zcela jistě více, než jen ip adresa 123.45.67.8... Na řádcích 21, 22 a 23 smažeme všechna pravidla a všechny řetězce v tabulce filter, vynulujeme počítadla, která počítají, kolik daným pravidlem prošlo paketů a kolik dat. Je to z toho důvodu, že na routeru mohla být konfigurace předchozího firewallu. V podstatě nám tato tři pravidla zajistí, že začneme v tabulce filter od zeleného stolu. Na řádcích 26, 27 a 28 pak nastavíme politiku pro řetězce INPUT, FORWARD a OUTPUT na DROP, cožznamená, že pokud příslušný paket nevyhoví svému příslušnému pravidlu (nebo pravidlům), zahodíme jej a zdroji tohoto paketu to nijak neoznámíme. Zopakuji, že neuvedení parametru -t filter u příkazu iptables znamená totéž, jako bychomjej uvedli. Tedy že pracujeme s tabulkou filter. Dále tedy pracujeme pouze s tabulkou filter a parametr -t neuvádíme. Místa, na která byseměl podívat každý, kdo studuje konfiguraci firewallu, jsou právě ta, kde začíná řetězec INPUT (řádek 75), řetězec FORWARD (řádek 86) a řetězec OUTPUT (řádek 92). Jsou to totiž řetezce, kde začíná průchod paketu firewallem. Pro zopakováníuvedu, že pravidly řetězce INPUT v tabulce filter prochází takové pakety, jejichž cílová adresa je adresou některého ze sít ových rozhraní samotného routeru. Je nutné zdůraznit, že paket může Řetězec INPUT srpen 2004

část 9, díl 3, kapitola 6.1, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ mít v tabulce filter jinou cílovou (ale také zdrojovou) adresu, než jakou ji může mít v tabulkách mangle či nat. Přestože v naší konfiguraci použijeme jen tabulku filter, je nutné na to pamatovat, a proto to budu vždy zdůraňovat. V dalších příkladech jednotlivých konfigurací to bude zřejmé. Na řádku 75 máme definici, které vyhoví všechny pakety, jež budou procházet tímto pravidlem. Akce tohoto pravidla nám nařizuje procházet řetezec spoof. Protože Netfilter zná implicitně jen řetězce INPUT, FORWARD a OUTPUT (stále hovoříme pouze o tabulce filter), musí být v definici firewallu někde dříve řetězec spoof nadefinován. Tím místem je řádek 35 a tam se nyní přesunuje naše pozornost. Na řádku 31 zadefinujeme řetezec spoof a na řádcích 37 až 46 pak definujeme pravidla v tomto řetězci. Tato sada pravidel nám má zajistit korektnost paketů, které k nám přicházejí z jednotlivých sít ových rozhraní. Potenciální útočník nám například může podstrčit paket z internetu, jehož zdrojová adresa ale bude znaší vnitřní sítě. Nebudu se v tuto chvíli pozastavovat nad tím, proč by takto jednal, ale budu popisovat způsob, jak se proti takovémuto chování zabezpečit. Dalším smyslem pravidel v řetězci spoof je zakázat obecně routování adres z neveřejných sítí. Tyto sítě jsou trojího druhu: 10.0.0.0/8, 172.16.0.0/12 a 192.168.0.0/16. Úkolem pravidel v řetězci spoof je všechny korektní pakety vrátit zpět ke zpracování na další pravidlo v řetězci, ze kterého sem skočily. V našem případě tobude zpět dořetězce INPUT. eth1. Nyní popíšeme samotná pravidla v řetězci spoof. Na řádku 36 povolíme veškerý provoz na zařízení loopback. Je to virtuální rozhraní, které používá operační srpen 2004

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 6.1, str. 5 systém v podstatě pro své vnitřní potřeby. Jeho adresa je obvykle127.0.0.1. Omezování na tomto rozhraní má někdy smysl, nicméně v našem případě jej omezovat nepotřebujeme. Na řádku 37 pak vidíme definici, které vyhoví všechny pakety, jež přišly na router z jeho vnitřního sít ového rozhraní (v předcházejích definicích je to sít ové rozhraní označené jako eth1) a jejichž zdrojová adresa je z rozsahu adres pro vnitřní sít. Takovéto pakety již nejsou dále zpracovávány v řetězci spoof a jsou vráceny pro zpracování vřetězci INPUT. Na řádku 38 pak uvedené definici vyhoví všechny pakety, jejichž zdrojová adresa je z rozsahu vnitřní sítě. Budou to právě ty pakety, které k nám dorazily z jiného než vnitřního rozhraní. Tyto pakety jsou pro nás potenciálně nebezpečné. Akce v tomto pravidle říká, že máme skočit do řetezce spoofdrop. Spoofdrop je opět řetězec, který není implicitně definován. Měli bychom tudíž hledat jeho definici ve firewallu, a to opět před tímto použitím. Definici pravidla spoofdrop najdeme na řádku 30. Vřetězci spoofdrop pakmámenařádku31 akci, která způsobí zalogování informací o takovémto paketu, anařádku 32 pak takový paket zahodíme. Vrátíme se zpět do řetězce spoof a na řádcích 39 až 41 pak vidíme zpracování paketů, které jsou z neveřejného rozsahu. Na řádcích 42 a 43 pak zpracováváme pakety, které by měly přijít z virtuálního rozhraní loopback, nicméně dostaly se k nám odjinud, protože nevyhověly pravidlu na řádku 36. Ze zařízení loopback nám v obvyklých případech chodí pakety, jejichž zdrojová nebocílová adresajeprávě 127.0.0.1. srpen 2004

část 9, díl 3, kapitola 6.1, str. 6 BEZPEČNÁ POČÍTAČOVÁ SÍŤ Na řádku 44 pak vracíme do řetězce INPUT zpracování všech paketů, které přicházejí z vnějšího sít ového rozhraní (tedy z internetu) a nezahodili jsme je v předcházejících pravidlech. V definici používáme pouzekontrolu z vnějšícho rozhraní, protože nemůžeme specifikovat, jakou zdrojovou adresu mají takovéto pakety. Na řádku 45 pak pravidlo charakterizuje pakety, které souvisí se službou DHCP. Takovýto paket má zdrojovou adresu 0.0.0.0 a cílovou adresu 255.255.255.255. Navíc z předchozího je zřejmé, že pokud se paket ve vyhodnocování dostal až sem, mohl přijít jedině z vnitřního sít ového rozhraní. Vrátíme jej tedy ke zpracování vřetězci INPUT. Vlastnosti Netfilteru jsou takové, že pokudpři zpracování paketu v aktuálním řetězci nevyhoví žádné pravidlo, vrací se paket ke zpracování dořetězce, ze kterého skočil do právě zpracovávaného. V tuto chvíli je tedy aktuálním zpracovávaným řetězcem spoof a nadřazený řetězec je INPUT. Pokud je však aktuálním řetězcem INPUT, FORWARD nebo OUTPUT, použije se pro zpracovánípaketu nastavená politika v pravidlech 26, 27 či 28. Dobrým zvykem je nespoléhatse na takovéto chování a raději v konfiguračním skriptu uvést jako poslední pravidlo s akcí RETURN atím říci, že chceme skutečně paket dále zpracovávat nebo takovýpaket zahodit akcí DROP a nebo jej vrátit akcí REJECT.Případně ještě před těmito akcemi paket zalogovat. To v podstatě děláme nařádku 46. Skočíme do řetězce spoofdrop,na řádku 31 jej zalogujeme a na řádku 32 zahodíme. Rád bych znova zdůraznil, že tím dáváme zcela jasně najevo, že jsme na nic nezapomněli a že jsme v řetězci srpen 2004

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 6.1, str. 7 skutečně mysleli na všechny pakety, které jím mohou procházet. Máme tedy za sebou úspěšně řetězec spoof a vracíme se dořetězce INPUT na řádek76.na něm akceptujeme všechny pakety, které již souvisejí s existujícími spojeními patřícími našemu routeru, nebo takové pakety, které sice patří k novému spojení, avšak to souvisí již snějakým navázaným. U volby ESTABLISHED se typicky jedná například o odpovědi na dotazy, které vnesl náš DNS server. U volby RELATED pak těch, které se mohou týkat našeho ftp serveru. Zejména u druhé skupiny paketů je tato volba podstatná, protože po navázání spojení na porty, které máme níže povoleny, může komunikace probíhat po jiných portech, na kterých se domluví jednotlivé aplikace, a my bychom pak museli v konfiguraci firewallu tyto porty ručně povolovat. Protože je nemusíme znát dopředu, museli bychom povolovat určitý rozsah a to může být nebezpečné. Tím, že můžeme uvést volbu --state, necháme celou režii na jádře systému. To je také důvod, proč je Netfilter tzv. stavovým firewallem. Na řádku 77 pak zalogujeme všechny pakety, které navazují nějaká spojení na protokolu TCP. Pak můžeme dohledat, kdo z vnitřní sítě či vnějšího rozhraní snámi navazoval nějaké spojení. Na řádku 78 povolujeme ICMP protokol. Řádku 79 pak vyhoví všechny pakety, které patří do rozsahu adres vnitřní sítě (a díky předcházejícímu průchodu řetězcem spoof jsme si tím jisti) a budeme je dále zpracovávat vřetězci int-fw. Ten popíšipozději. srpen 2004

část 9, díl 3, kapitola 6.1, str. 8 BEZPEČNÁ POČÍTAČOVÁ SÍŤ Řádku 80 pak vyhovívšechny pakety, které přicházejí z vnějšího sít ového rozhraní, a budeme je zpracovávat vřetězci bad-fw. Opět je popíši později. Řádek 81 je pak určen paketům, které patří keslužbě DHCP a které jdou z vnitřního sít ového rozhraní. Takové pakety akceptujeme (a tím pádem klienti ve vnitřní síti mohou používat DHCP), nicméně mohli bychom pro větší bezpečnost založit další řetězec, jenž by například kontroloval vybrané MAC adresy. Také bychom mohli tyto pakety akceptovat s upravenými podmínkami již na řádku 45, nicméně tato optimalizace (paket by neprocházel 6 pravidel navíc) není nijak výrazná. My tak můžeme zachovat filozofii řetězce spoof, kde se pouze kontrolují vlastnosti paketů v souvislosti se sít ovým rozhraním, ze kterého dorazily na náš router. Tím máme zpracováno vše, co potřebujeme (jak uvidíme nížepři popisu řetězců int-fw a bad-fw), a protože se nespoléháme na implicitní politiku stanovenou na řádcích 26 až 28,nařádku 82 zalogujeme všechny případné nezpracované pakety v řetězci INPUT a na řádku 83 jej pak zahodíme. Obecně je vhodnépři vytváření konfigurace před každou akcí DROP či REJECT provést zalogování. Je to z toho důvodu, že pak snadno, například ve výpisu příkazu dmesg, vidíme, na které pakety jsme zapomněli. Lépe tak najdeme chybu v konfiguraci firewallu a můžeme ji rychleji a bez zbytečnýchnervů a chvilek nad klávesnicí odstranit. Věřte, že to bývá nejčastěnší příčina dlouhého odstraňování chyby v konfiguraci firewallu. Proto ještě jednou doporučuji, aby si před každým REJECT nebo DROP začátečníci uváděli pravidlo s akcí LOG. Také je vhodné formátovat začátek srpen 2004

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 6.1, str. 9 logovacího řetězce volbou --log-prefix pro snadnější přehled a srozumitelnější výpis. Zbývá nám zpracovat řetezce bad-fw a int-fw. Na řádku 62 a tudíž dříve, než jsme se poprvé odkázali nařetězec int-fw vřetězci INPUT (což bylonařádku 79), definujeme samotný řetězec int-fw. Na řádku 49 pak vybranému počítači odepřeme přístup na službu proxy serveru a tím mu v podstatě zabraňujeme používat internetové služby. Mohli bychom použít akci DROP, nicméně toto pravidlo by pak pakety zahazovalo a uživatel by se tak nedozvěděl, proč se nemůže na službu připojit. A protože se jedná o uživatele ve vnitřní síti, je vhodnější použít akci REJECT. Pravidlo DROP je obecně dobré používat tam, kde je množství zahozených paketů velké, a tím snižujeme jak zatížení sítě (neposíláme icmp odpověd), tak zatížení našeho firewallu (nebot nemusí takovou icmp odpověd sestavovat a odesílat). Na řádku 50 pak zakážeme uživatelům z vnitřní sítě přístup na službu ssh. V pravidle na řádku 51 pak povolíme všechna spojení na náš router a tím i dostupnost všech ostatních běžících služeb všem uživatelům vnitřní sítě. Řetězec bad-fw je definován pravidlem na řádku 62. Na řádcích 63, 64, 65, 67, 68 a 69 pak všem povolujeme přístup na definované služby. Na řádcích 66 a 71 pak přístup na službu ssh budeme zpracovávat v řetězcích ssh-me, definovaných na řádcích 53 až 56. Přístup na službu ftp pak definujeme v řetězci ftp-me na řádcích 58 až 60. A protože se na tyto řetezce dá skočit jen z řetězce bad-fw a tomu vyhovují jen pakety srpen 2004

část 9, díl 3, kapitola 6.1, str. 10 BEZPEČNÁ POČÍTAČOVÁ SÍŤ FORWARD Řetězec OUTPUT z řádku80, omezujeme tak příchozípakety z vnějšího sít ového rozhraní (a tudíž z internetu). Smysl pravidla na řádku 70 objasním na konci. Tím máme popsanou část INPUT a tudíž pakety, které byly určeny (v tabulce filter) našemu routeru. Pravidla v řetězci FORWARD popisují zacházení s pakety, které v tabulce filter měly jinou zdrojovou a jinou cílovou adresu, než jakou má náš router na všech svých sít ových rozhraních, tj. na zařízení eth0, eth1 a looopback. Typicky se jedná o pakety, které míří z naší vnitřní sítě do internetu. Například když si chce uživatel pomocí protokolu icmp ověřit, zda je dostupný některý server, například webový server www.seznam.cz. Na začátku příkladu jsme stanovili politiku, že přístupuživatelů na internet je zprostředkovánvýhradně přes proxy server. Tudíž řetězec FORWARD by mohl obsahovat jediné pravidlo, a to pravidlo na řádku 89. My si však na řádku 86 zalogujeme všechny pokusy o navázání spojení po protokolu tcp, dále pravidlem na řádku 87 všem uživatelům z vnitřní sítě oznámíme, že přímý přístup do internetu není možný, dále zalogujeme všechny pokusy o přeposílání paketů (tedy i možné pokusy utočníka z venku dostat se do naší vnitřní sítě) a nakonec na řádku 89 všechny takové pakety zahodíme. Zbývá nám vyřešit řetězec OUTPUT. Pro zopakování uvedu, že řetězcem OUTPUT v tabulce filter zpracováváme všechny pakety, které mají jako zdrojovou adresu v tabulce filter uvedenou adresu některého ze sít ových rozhraní našeho routeru. Typicky se jedná o pakety generované naším routerem. srpen 2004

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 6.1, str. 11 Na řádku 92 si zalogujeme všechny pakety, které zajišt ujínavazovánínějakéhospojení. Tak můžeme sledovat aktivity těch uživatelů, kteří mají přístup na náš server přes ssh službu. Či aktivity našich serverových služeb. Na řádku 93 pak povolíme veškerý odchozí provoz. Na řádcích 95 až 109 pak smažeme veškerá pravidla v tabulkách nat a mangle, které podle naší politiky musí být prázdné. Jediné pravidlo, které zbývá popsat, je pravidlo na řádku 70. Říká nám, že máme vrátit odesílateli icmp oznámení, že služba není dostupná. Proč používáme REJECT místo DROP (či prostého vynechání takového pravidla)? Takový paket přece vyhovuje pravidlu řádku 83. Náš server ale navazuje spojení do internetu, například odesílá poštu. Obecně platí, že pokud je například na službu smtp navazováno spojení, server obsluhující tutoslužbu se může před sestavením takového spojení zeptat odesílatele na jeho identitu. Tuto službu pak obvykle poskytuje server na portu auth na protokolu tcp. Pokud přístupnatutoslužbu budeme obsluhovat akcí DROP, tazatel se nedozví, že služba auth není dostupná, a pokusí se o znovunavázání naslužbu auth. Opět mu paket zahodíme bez oznámení. Za nějakou dobu pokus o navázání naslužbuauthvzdáa bude pokračovat v sestavování spojení služby smtp, kvůli kterému se na službu auth pokoušel připojit. Jenže mezitím jsme my, jako původní tazatel, vzdali pokus o navázání spojení naslužbu smtp, a tak takovéto pakety již nebudou splňovat podmínky pravidla 76. Apřestože by tyto pakety mohly splňovat pravidlo 63, tak původní tazatel již tyto pakety zahodí jako bezpředmětné, srpen 2004

část 9, díl 3, kapitola 6.1, str. 12 BEZPEČNÁ POČÍTAČOVÁ SÍŤ Natažení modulů protože vzdal pokus o spojení. Důsledkem je, že se nikdy nebudeme moci připojit na takový smtp server. Proto je velmi důležité zacházet s pakety směřujícími na službu auth obezřetným způsobem. V souvislosti s logováním paketů je dobré dát pozor na množství takovýchto paketů.náš router nemusí mít dostatečně velký výkon CPU, a tak nebude bez problému stíhat logování paketů. Tím se i zpomalí průchod ostatních paketů a může dojít k tomu, že nebudeme pakety vůbec příjímat či odesílat. Dále se nám také může stát, že velice rychle zaplníme diskovou kapacitu, protože logy budou narůstat neúměrně rychle. Vhodnou volbou je pak použití parametru -m limit s patřičnými volbami. Je zřejmé, že bychom si vystačili pouze s řetězci INPUT, FORWARD a OUTPUT. Je však dobré zvolit definici vlastních řetězců z několika důvodů. Pokud si je dobře pojmenujeme, konfigurace firewallu se stává výrazně čitelnější, než kdybychom měli velkou sadu pravidel v jednotlivých řetězcích. Modifikace takových pravidel je pak výrazně jednodušší. Druhý dobrý důvod je rychlost procházení firewallu. Pokud máme několik málo pravidel, je pravděpodobně jedno, jestli je procházíme v nejhorším případě všechna a sekvenčně. Pokud však máme pravidel více a pokud máme velký provoz, vyplatí se vybudovat si pomocí vlastních řetězců jakousi stromovou strukturu a tím pádem zrychlit průchod paketu firewallem a i nezpomalovat tak příliš provoz na síti. Tím máme probranou konfiguraci firewallu, jež splňuje tu politiku, kterou jsme si na začátku stanovili. Zbývá dodat, ze pro správnou funkci stavovosti firewallu (volba -m state) je nutné mít natažené srpen 2004

BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kapitola 6.1, str. 13 moduly ip conntrack a ip conntrack ftp. Ten druhý zejména proto, že uživatelům umožňujeme přistupovat na ftp služby prostřednictvím našeho proxy serveru. Tyto moduly natáhneme příkazem modprobe ip conntrack a modprobe ip conntrack ftp. Můžeme to udělat v našem skriptu a nebo někde jinde. Jde to také udělat mnoha dalšími způsoby, ovšem to je mimo téma této kapitoly. K samotnému skriptu, který jeníže uvedený, je nutno dodat, že jeho obsahem by nebyly mezery před čísly řádků, samotnáčísla řádků, dvojtečkaza číslem řádku a mezera za touto dvojtečkou. Některé řádky jsou ve skriptu delší, než se vejde do této příručky. V takovém případě je zde vytištěn pokračovací řádek, který už nemá číslo a je odsazen. Takto upravený pokračovací řádek by ale ve skutečném skriptu nefungoval, protože na konci předchozího řádku chybí znak\. Samotný skript: 1: #!/bin/sh 2: 3: ext_dev="eth0" 4: ext_ip="192.0.34.166" 5: 6: int_dev0="eth1" 7: int_ip0="192.168.0.1" 8: int_net0_0="192.168.0.0/24" 9: pc1="192.168.0.28" 10: sauvignon="123.45.67.8" 11: ogebenec="123.45.67.9" 12: 13: fw_prefix=" Netfilter" 14: 15: case "$1" in 16: start) 17: echo -n "Starting up IP Firewall: " 18: srpen 2004