Bezpečná počítačová síť - People(dot)tuke(dot)sk
Transkript
Bezpečná počítačová síť - People(dot)tuke(dot)sk
BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, str. 1 díl 3, Bezpečnost v Linuxu 9/3 BEZPEČNOST V LINUXU 9/3.1 9/3.2 9/3.3 9/3.4 9/3.5 9/3.6 9/3.7 9/3.8 9/3.9 9/3.10 9/3.11 Linuxové jádro, instalace Linuxu Záplatování systému Uživatelské účty Bezpečnost na úrovni souborového systému Vzdálená správa systému 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 IDS Nessus Tripwire Omezování síťového provozu 9/3.10.1 Úvod 9/3.10.2 Omezování provozu na úrovni protokolu TCP/IP 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ÍŤ díl 3, Bezpečnost v Linuxu 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 dı́l 3, Bezpečnost v Linuxu 9/3.1 LINUXOVÉ JÁDRO, INSTALACE LINUXU Linuxové jádro je to, co se stará o př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. Linuxové jádro Při konfiguraci dřı́ve nebo později narazı́me na verzi jádra. Jádro je vyvı́jeno v několika větvı́ch, kde kaž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á se o řadu vývojovou. Ta sloužı́ vývojářům jádra k přidávánı́ nových vlastnostı́ a jejich testovánı́. Nová vlastnost může být v pozdějšı́ vývojové verzi bez náhrady odstraněna. Z vývojové větvě se časem stane větev stabilnı́. prosinec 2003 část 9, dı́l 3, kapitola 1, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu 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 pokud nová 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 Instalace Linuxu se v mnohém lišı́ od světa proprietárnı́ho softwaru. V prvé řadě lze instalovat několika způsoby, nejen obvyklým pomocı́ 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 k sı́ti, kde se daný 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 dı́l 3, Bezpečnost v Linuxu 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. V adresář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ým uživatelům a v adresář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, se můž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 a v adresář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 zapisovat do 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ı́l umı́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ÍŤ dı́l 3, Bezpečnost v Linuxu 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ému soubor /etc/passwd. Hesla k jednotlivým účtům však umožňuje uložit v odděleném souboru /etc/shadow, který je navı́c čitelný pouze pro uživatele root, což je uživatel s administrátorským oprávněnı́m. Dále je doporučeno uklá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 dı́l 3, Bezpečnost v Linuxu Při instalaci systému je vhodné vybrat jen ty balı́ky, které budeme skuteč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řı́tomnost př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 dı́l 3, Bezpečnost v Linuxu prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 2, str. 1 dı́l 3, Bezpečnost v Linuxu 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ÍŤ dı́l 3, Bezpečnost v Linuxu něj nepředstavuje problém. Zjištěnı́ přı́tomnosti nových opravných balı́ků můžeme provést pomocı́ 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 pozornost je 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 v přı́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ěla napravit přı́štı́ verze Debianu (Sarge). Automatické záplatovánı́ v RedHatu prosinec 2003 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ě. BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 2, str. 3 dı́l 3, Bezpečnost v Linuxu Firma RedHat nynı́ do své testovacı́ distribuce zahrnula nástroj yum a zdá 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 dı́l 3, Bezpečnost v Linuxu prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 3, str. 1 dı́l 3, Bezpečnost v Linuxu 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šinou nastaven 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ánit uživatelům majı́cı́m na serveru poštovnı́ účet v přihlášenı́. prosinec 2003 část 9, dı́l 3, kapitola 3, str. 2 dı́l 3, Bezpečnost v Linuxu prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 4, str. 1 dı́l 3, Bezpečnost v Linuxu 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ÍŤ dı́l 3, Bezpečnost v Linuxu 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áme je jako souč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ých pı́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ı́k pronikne do systé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. ACL práva prosinec 2003 V ně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 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 4, str. 3 dı́l 3, Bezpečnost v Linuxu ř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 dı́l 3, Bezpečnost v Linuxu prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 5, str. 1 dı́l 3, Bezpečnost v Linuxu 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ı́ na stroje dřı́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ÍŤ dı́l 3, Bezpečnost v Linuxu 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ı́če uživatele podepı́še identifikátor aktuá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ů. Bezpečná konfigurace sshd prosinec 2003 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 objeveno ně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. BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 5, str. 3 dı́l 3, Bezpečnost v Linuxu Poměrně osvědčenou metodou zabezpečenı́ je změna portu, na kterém sshd poslouchá. Volı́ se ná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 216 ), 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. Použitı́ autentizace pomocı́ páru RSA/DSA klı́čů v OpenSSH 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 prosinec 2003 část 9, dı́l 3, kapitola 5, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu pomocı́ volby AuthorizedKeysFile) a zkusı́me se přihlásit. V přı́padě, že nebudete automaticky přihlášeni, zkontrolujte přı́stupová práva k 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. Standard IPsec IPsec je standard rozšiřujı́cı́ IP protokol o autentizaci a šifrovánı́. Sestává se z ně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ůže fungovat ve dvou rež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ým podobný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 dı́l 3, Bezpečnost v Linuxu 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. Implementace IPsec v Linuxu 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). prosinec 2003 část 9, dı́l 3, kapitola 5, str. 6 dı́l 3, Bezpečnost v Linuxu prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 6, str. 1 dı́l 3, Bezpečnost v Linuxu 9/3.6 FIREWALL Firewall je služba, která na úrovni paketových spojenı́ 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ému konkrétnı́mu spojenı́. 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. Firewall 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 prosinec 2003 část 9, dı́l 3, kapitola 6, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu 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’ skok do 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 prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 6, str. 3 dı́l 3, Bezpečnost v Linuxu 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á se má 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ı́ s QoS na označ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 Definice pravidel firewallu 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 do daného řetězce pravidel. Lišı́ se umı́stěnı́m nového pravidla. -A přidává pravidlo vždy na konec řetězce, kdežto -I umožňuje urč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. Základnı́ volby pro kategorizaci paketů -p protokol prosinec 2003 část 9, dı́l 3, kapitola 6, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu 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žı́ na dané 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 PREROUTING. -o iface Sı́t’ové rozhranı́, na které bude paket poslán. Volba je platná jen v řetězcı́ch OUTPUT, FORWARD a POSTROUTING. Tı́m nejsou možnosti iptables pro kategorizaci paketu samozřejmě zdaleka vyčerpány. Dalšı́ volby jsou 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. Volby pro protokol TCP --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. prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 6, str. 5 dı́l 3, Bezpečnost v Linuxu --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ý SYN přı́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 Volby pro protokol UDP Platı́, pokud se zdrojový port nacházı́ v intervalu port1–port2. Popř. můžeme specifikovat pouze jeden port. --destination-port port1:port2 Totéž pro cı́lový UDP port. Velké množstvı́ dalšı́ch voleb pro kategorizaci paketů je př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 se může spojenı́ asociované s aktuálně zpracovaným paketem nacházet. Možné stavy jsou: Stavový firewall INVALID – paket nenı́ asociován s žá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ı́. prosinec 2003 část 9, dı́l 3, kapitola 6, str. 6 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu 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). Akce prováděné s pakety 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 Bezpečná konfigurace firewallu 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á z něj nebude použı́vána. Popřı́padě je vhodné některé služby povolit jen z IP, z který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 dı́l 3, Bezpečnost v Linuxu 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ÍŤ dı́l 3, Bezpečnost v Linuxu 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 na náš server měla přı́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áš server měla přı́stup na službu ftp tatáž firma a 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 bude stač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 dı́l 3, Bezpečnost v Linuxu Je to praktické z ně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 bychom jej 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á by se mě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ÍŤ dı́l 3, Bezpečnost v Linuxu 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 z našı́ 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ě to bude 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 dı́l 3, Bezpečnost v Linuxu systém v podstatě pro své vnitřnı́ potřeby. Jeho adresa je obvykle 127.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 pak máme na řádku 31 akci, která způsobı́ zalogovánı́ informacı́ o takovémto paketu, a na řá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á nebo cı́lová adresa je právě 127.0.0.1. srpen 2004 část 9, dı́l 3, kapitola 6.1, str. 6 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu 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 pouze kontrolu 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 pokud př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éhat se na takovéto chovánı́ a raději v konfiguračnı́m skriptu uvést jako poslednı́ pravidlo s akcı́ RETURN a tı́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 dı́l 3, Bezpečnost v Linuxu 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 řádek 76. 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ž s ně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ı́ s ná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ı́ši později. srpen 2004 část 9, dı́l 3, kapitola 6.1, str. 8 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu Řá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řı́ ke služ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ı́že př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ých nervů 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 dı́l 3, Bezpečnost v Linuxu 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ž bylo na řá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ÍŤ dı́l 3, Bezpečnost v Linuxu z řádku 80, 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. FORWARD 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řı́stup uživatelů na internet je zprostředkován vý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. Řetězec OUTPUT srpen 2004 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. BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 6.1, str. 11 dı́l 3, Bezpečnost v Linuxu Na řádku 92 si zalogujeme všechny pakety, které zajišt’ujı́ navazovánı́ nějakého spojenı́. 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ı́ tuto služ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řı́stup na tuto službu budeme obsluhovat akcı́ DROP, tazatel se nedozvı́, že služba auth nenı́ dostupná, a pokusı́ se o znovunavázánı́ na službu auth. Opět mu paket zahodı́me bez oznámenı́. Za nějakou dobu pokus o navázánı́ na službu auth vzdá 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ı́ na službu smtp, a tak takovéto pakety již nebudou splňovat podmı́nky pravidla 76. A př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ÍŤ dı́l 3, Bezpečnost v Linuxu 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. Nataženı́ modulů srpen 2004 Zbývá dodat, ze pro správnou funkci stavovosti firewallu (volba -m state) je nutné mı́t natažené BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 6.1, str. 13 dı́l 3, Bezpečnost v Linuxu 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ý je nı́že uvedený, je nutno dodat, že jeho obsahem by nebyly mezery před čı́sly řádků, samotná čı́sla řádků, dvojtečka za čı́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 část 9, dı́l 3, kapitola 6.1, str. 14 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu 19: 20: 21: 22: 23: ## Tabulka filter # Zruseni a vynulovani stavicich pravidel iptables -t filter -F iptables -t filter -X iptables -t filter -Z 24: 25: 26: 27: 28: # nastaveni iptables -t iptables -t iptables -t POLICY filter -P INPUT DROP filter -P FORWARD DROP filter -P OUTPUT ACCEPT 29: 30: 31: 32: iptables -N spoofdrop iptables -A spoofdrop -j LOG --log-prefix "${fw_prefix} [Spoofdrop]: " iptables -A spoofdrop -j DROP 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: # Anti-spoofing iptables -N spoof iptables -A spoof -i iptables -A spoof -s iptables -A spoof -s iptables -A spoof -s iptables -A spoof -s iptables -A spoof -s iptables -A spoof -s iptables -A spoof -d iptables -A spoof -i iptables -A spoof -s --dport bootps iptables -A spoof -j lo -j ACCEPT "${int_net0_0}" -i "${int_dev0}" -j RETURN "${int_net0_0}" -j spoofdrop 192.168.0.0/16 -j spoofdrop 172.16.0.0/12 -j spoofdrop 10.0.0.0/8 -j spoofdrop 127.0.0.0/8 -j spoofdrop 127.0.0.0/8 -j spoofdrop "${ext_dev}" -j RETURN 0.0.0.0 -d 255.255.255.255 -p udp --sport bootpc -j RETURN spoofdrop 47: 48: 49: 50: 51: iptables iptables iptables iptables -N -A -A -A int-fw int-fw -s "${pc1}" -p tcp --dport squid -j REJECT int-fw -p tcp --dport ssh -j REJECT int-fw -j ACCEPT iptables iptables iptables iptables -N -A -A -A ssh-me ssh-me -s "${ogebenec}" ssh-me -s "${sauvignon}" ssh-me -j RETURN 52: 53: 54: 55: 56: 57: srpen 2004 -j ACCEPT -j ACCEPT BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 6.1, str. 15 dı́l 3, Bezpečnost v Linuxu 58: 59: 60: iptables -N ftp-me iptables -A ftp-me -s "${sauvignon}" -j ACCEPT iptables -A ftp-me -j RETURN 61: 62: 63: 64: 65: 66: 67: 68: 69: 70: 71: 72: 73: iptables iptables iptables iptables iptables iptables iptables iptables iptables iptables iptables iptables -N -A -A -A -A -A -A -A -A -A -A -A bad-fw bad-fw bad-fw bad-fw bad-fw bad-fw bad-fw bad-fw bad-fw bad-fw bad-fw bad-fw -p -p -p -p -p -p -p -p -p -j -j tcp --dport smtp -j ACCEPT tcp --dport http -j ACCEPT tcp --dport https -j ACCEPT tcp --dport ssh -j ssh-me tcp --dport pop3s -j ACCEPT tcp --dport domain -j ACCEPT udp --dport domain -j ACCEPT tcp --dport auth -j REJECT tcp --dport ftp -j ftp-me LOG --log-prefix "${fw_prefix} [bad-fw]: " DROP 74: 75: 76: 77: 78: 79: 80: 81: 82: 83: iptables -A INPUT -j spoof iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p tcp --syn -m state --state NEW -j LOG --log-prefix "${fw_prefix} [SYN bit]: " iptables -A INPUT -p icmp -j ACCEPT iptables -A INPUT -s "${int_net0_0}" -j int-fw iptables -A INPUT -i "${ext_dev}" -j bad-fw iptables -A INPUT -i "${int_dev0}" -s 0.0.0.0 -d 255.255.255.255 -p udp --sport bootpc --dport bootps -j ACCEPT iptables -A INPUT -j LOG --log-prefix "${fw_prefix} [INPUT]: " iptables -A INPUT -j DROP 84: 85: 86: 87: 88: 89: # Forwardovaci pravidla iptables -A FORWARD -p tcp --syn -m state --state NEW -j LOG --log-prefix "${fw_prefix} [SYN bit]: " iptables -A FORWARD -s "${int_net0_0}" -o "${ext_dev}" -j REJECT iptables -A FORWARD -j LOG --log-prefix "${fw_prefix} [FORWARD]: " iptables -A FORWARD -j DROP 90: 91: 92: 93: # Vystupni pravidla iptables -A OUTPUT -p tcp --syn -m state --state NEW -j LOG --log-prefix "${fw_prefix} [SYN bit ]: iptables -A OUTPUT -j ACCEPT srpen 2004 část 9, dı́l 3, kapitola 6.1, str. 16 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu 94: 95: 96: 97: 98: 99: 100: iptables iptables iptables iptables iptables iptables -t -t -t -t -t -t nat nat nat nat nat nat -F -X -Z -P PREROUTING ACCEPT -P POSTROUTING ACCEPT -P OUTPUT ACCEPT iptables iptables iptables iptables iptables iptables iptables iptables -t -t -t -t -t -t -t -t mangle mangle mangle mangle mangle mangle mangle mangle 101: 102: 103: 104: 105: 106: 107: 108: 109: -F -X -Z -P -P -P -P -P PREROUTING ACCEPT INPUT ACCEPT FORWARD ACCEPT OUTPUT ACCEPT POSTROUTING ACCEPT 110: 111: echo "Done." 112: ;; 113: 114: stop) 115: 116: 117: 118: 119: 120: 121: 122: 123: 124: 125: 126: 127: 128: 129: 130: 131: 132: 133: echo -n "Resetting iptables -t filter iptables -t filter iptables -t filter iptables -t filter iptables -t filter iptables -t filter iptables -t nat -F iptables -t nat -X iptables -t nat -Z iptables -t nat -P iptables -t nat -P iptables -t nat -P iptables -t mangle iptables -t mangle iptables -t mangle iptables -t mangle iptables -t mangle srpen 2004 built-in chains to the default ACCEPT policy:" -F && \ -X && \ -Z && \ -P INPUT ACCEPT && \ -P OUTPUT ACCEPT && \ -P FORWARD ACCEPT && \ && \ && \ && \ PREROUTING ACCEPT && \ POSTROUTING ACCEPT && \ OUTPUT ACCEPT && \ -F && \ -X && \ -Z && \ -P PREROUTING ACCEPT && \ -P INPUT ACCEPT && \ BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 6.1, str. 17 dı́l 3, Bezpečnost v Linuxu 134: 135: 136: 137: 138: iptables -t mangle -P FORWARD ACCEPT && \ iptables -t mangle -P OUTPUT ACCEPT && \ iptables -t mangle -P POSTROUTING ACCEPT && \ echo "Resetting built-in chains to the default ACCEPT policy: OK" || \ echo "Resetting built-in chains to the default ACCEPT policy Failed" 139: 140: ;; 141: 142: *) 143: 144: echo "Usage: $0 exit 1 [start | stop]" 145: ;; 146: 147: esac 148: exit 0 srpen 2004 část 9, dı́l 3, kapitola 6.1, str. 18 dı́l 3, Bezpečnost v Linuxu srpen 2004 BEZPEČNÁ POČÍTAČOVÁ SÍŤ BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 6.2, str. 1 dı́l 3, Bezpečnost v Linuxu 9/3.6.2 PŘÍKLAD POUŽITÍ TABULKY NAT NA FIREMNÍM FIREWALLU Ukázkový skript se opět 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č. Tedy jako v přechozı́m přı́padě. Na ten se ostatně budu často odkazovat, a tak jeho pochopenı́ je vcelku podstatné pro správné pochopenı́ tohoto přı́kladu. Představme si, že máme firemnı́ router, který je opět jednı́m sı́t’ovým rozhranı́m připojen do Inetrnetu a má od poskytovatele přidělenou 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.1.0/24 a náš router má adresu 192.168.1.1. Dále máme na veřejném sı́t’ovém rozhranı́ ještě jednu adresu, a to 164.218.1.11. Tato adresa je sekundárnı́ na onom veřejném rozhranı́ eth0. Předpoklady srpen 2004 část 9, dı́l 3, kapitola 6.2, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu Zadánı́ Na našem routeru pak provozujeme pro účely počı́tačů z vnitřnı́ sı́tě i pro počı́tače z internetu poštovnı́ server, doménový server, webový server. Dále pak pro vybrané zákaznı́ky ssh server pro vzdálený přı́stup, VPN server (realizovaný nad protokolem IPSec) a ftp server. Nakonec pro počı́tače ve vnitřnı́ sı́ti provozujeme proxy server. Požadujeme, aby uživatelé mohli na internetu 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ý. Dále chceme umožnit uživatelům ve vnitřnı́ sı́ti protokol icmp, konkrétně umožnit ověřenı́, zda server na internetu žije. Žádný jiný přı́stup uživatelé do internetu mı́t nebudou. Na serveru pak mohou použı́vat všechny běžı́cı́ služby kromě služby ssh, která umožňuje přı́stup na server. Dále požadujeme, aby měla na službu ssh přı́stup externı́ firma z adres 123.45.67.8 a 123.45.67.9 (napřı́klad nám spravuje nějakou běžı́cı́ aplikaci) a dále aby na náš server měla přı́stup na službu ftp tatáž firma a dále jiná firma z adres 223.45.67.10 a 223.45.67.11 (napřı́klad za účelem správy obsahu webových stránek). Konečně chceme, abychom propojili naše pobočky technologiı́ VPN. Samotné propojenı́ realizuje jiná služba (běžı́cı́ na našem routeru než náš firewall). My však v našem firewallu musı́me povolit pohyb paketů v rámci oné VPN. Veřejné adresy těchto poboček jsou zaznamenány v ukázkovém skriptu zřejmým způsobem. Požadujeme, aby provoz mezi počı́tači v jednotlivých vnitřnı́ch sı́tı́ch poboček byl bez jakéhokoliv omezenı́. srpen 2004 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 6.2, str. 3 dı́l 3, Bezpečnost v Linuxu Výše uvedené požadavky jsou obdobné požadavkům v předchozı́m přı́kladě a opět by nám stačila pouze tabulka filter. My však ještě požadujeme následujı́cı́. Pokud budou uživatelé přistupovat pomocı́ webového prohlı́žeče na adresu https://164.218.1.11/, tak chceme, aby tyto požadavky byly přesměrovány na server ve vnitřnı́ sı́ti, jehož adresa je 192.168.1.7. Totéž přesměrovánı́ požadujeme, pokud přistoupı́ opět na adresu 164.218.1.11 protokolem tcp na porty 1443 a 8002. Představme si, že ve vnitřnı́ sı́ti na serveru na těchto portech poslouchá napřı́klad databázový server. Ono přesměrovánı́ sloužı́ k tomu, že dané služby jsou dostupné z internetu, přestože servery, na nichž běžı́, majı́ privátnı́, a tudı́ž z internetu nedostupné, adresy. Také požadujeme, aby se na server 164.218.1.11 dalo pingnout. Musı́me tedy ještě přesměrovat protokol icmp. Dalšı́m a poslednı́m požadavkem je pak přesměrovánı́ požadavků na externı́ adresu routeru 164.218.1.10 a služby na portu tcp/3050 na server ve vnitřnı́ sı́ti s adresou 192.168.1.6. Nynı́ se pustı́me směle do konfigurace firewallu. Konfigurace Na řádcı́ch 3 až 40 (skript s čı́slovanými řádky je na konci této kapitoly) si nastavı́me některé proměnné, mezi nimi i veřejné adresy oněch poboček, které se budou připojovat do VPNky. Je vhodné si všimnout, že všechny vnitřnı́ sı́tě jsou podmnožinou sı́tě 192.168.0.0/16 a takto si ji označı́me proměnnou firemni vpn. srpen 2004 část 9, dı́l 3, kapitola 6.2, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu Na řádcı́ch 121 až 129 v pravidlech INPUT již nám známým způsobem ověřı́me, zda pakety přicházejı́cı́ z jednotlivých sı́t’ových zařı́zenı́ majı́ správnou zdrojovou adresu. Za zmı́nku stojı́ virtuálnı́ sı́t’ové zařı́zenı́ ipsec0, ze kterého k nám budou přicházet pakety ze sı́tı́, které jsou začleněny do našı́ VPNky. Dále povolı́me všechna navázaná spojenı́ na náš router (ř. 121), povolı́me všechna již navázaná spojenı́ (ř. 122), zalogujeme (ř. 123) a zahodı́me (ř. 124) neplatné pakety, jež nemajı́ nastaven SYN bit ale tvářı́ se jako pakety, které navazujı́ spojenı́. Pak zalogujeme (ř. 125) všechny pakety, které patřı́ nějakému právě zahajovanému spojenı́. Pravidlo na řádku 126 nám pak řı́ká, že všechny pakety z našich vnitřnı́ch sı́tı́ obsloužı́me v pravidlech řetězce int-fw, který jsme si zadefinovali na řádcı́ch 83, 84 a 85. Zakazujeme tam přı́stup počı́tačům na službu ssh a jinak vše povolujeme. Přestože sı́t’ 192.168.0.0/16 obsahuje mnohem vı́ce podsı́tı́ a my použı́váme jen 6 (int net0 0, radotin net, rubena net, frydlant net, boleslav net a hradec net), můžeme si takto dovolit zobecňovat, protože jsme to ošetřili v řetězci spoof (řádky 66 až 70). Všechny pakety ostatnı́ch podsı́tı́ ze sı́tě 192.168.0.0/16 totiž zahodı́me (ř. 74). Pravidlo na řádku 127 nám řı́ká, jak se budeme chovat k paketům, které přijdou z internetu našı́m externı́m rozhranı́m eth0. Dále jde o to, že budeme cı́lové a zdrojové adresy u některých paketů přepisovat v tabulce nat. Proto na tomto mı́stě zdůrazňuji, že jsme v tabulce filter. Dále již tuto znalost předpokládám a odkazuji se na srpen 2004 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 6.2, str. 5 dı́l 3, Bezpečnost v Linuxu předchozı́ přı́klad a znalosti z něj a nebudu se tudı́ž vždy zmiňovat, ve které tabulce se nacházı́me. Na řádku 128 a 129 pak zalogujeme a zahodı́me všechny pakety, které nevyhověly žádnému pravidlu v řetězci INPUT. Upozorňuji, že žádný takový přı́pad by neměl nastat. Na řádcı́ch 107 až 119 definujeme řetězec bad-fw, kde je nastaven přı́stup podle výše uvedených požadavků. Přı́stup na poštovnı́, webový a doménový server všem počı́tačům z internetu. Na služby ftp, ssh a VPN serveru pak přı́stup omezujeme v řetězcı́ch ftp-me (řádky 87 až 92), ssh-me (řádky 94 až 97) a to ipsec (řádky 99 až 105). V pravidlech řetězce OUTPUT jen logujeme všechna odchozı́ navazujı́cı́ spojenı́ z našeho serveru. Provoz neomezujeme nijak. V pravidlech řetězce FORWARD provádı́me vše známé již z dřı́vějška. Pravidlo na řádku 154 pak řı́ká, že provoz mezi počı́tači ve VPNce je neomezovaný. Pravidlo na řádku 155 se odkazuje na pravidla v řetězci int-ext, kde povolı́me počı́tačům ve vnitřnı́ sı́ti pouze ping na počı́tače v internetu a vše ostatnı́ zakážeme. Pravidla na řádcı́ch 156 a 157 pak definujı́ přı́stup na přı́slušné počı́tače v našı́ vnitřnı́ sı́ti. Dı́ky řádku 154 těmto dvěma pravidlům mohou vyhovovat pakety, jejichž zdrojová adresa nenı́ ani z našı́ vnitřnı́ sı́tě, ani ze sı́tı́ z nějaké našı́ pobočky, ale je pouze adresou z internetu. Zajı́mavé to ovšem v tomto přı́kladě začı́ná být až v tabulce nat. Nebudeme ji procházet pravidlo po pravidle, nýbrž se podı́váme, jaké podmı́nky musı́ splňovat srpen 2004 část 9, dı́l 3, kapitola 6.2, str. 6 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu pakety s těmi omezenı́mi, která jsme si stanovili na začátku. Začneme poslednı́m požadavkem, a to přesměrovánı́ paketů z internetu určených našemu routeru (externı́ adresa 164.218.1.10) a služby na portu tcp/3050 na server ve vnitřnı́ sı́ti s adresou 192.168.1.6. Než přı́chozı́ paket dorazı́ do tabulky filter, procházı́ tabulkou nat. Pravidlem na řádku 188 řı́káme, že všechny pakety určené našı́ externı́ adrese (a je v tuto chvı́li jedno, zda přišel z rozhranı́ eth0, eth1 nebo ipsec0) na port tcp/3050 zpracujeme v řetezci to-ext ip (jsme v tabulce nat). V pravidle na řádku 178 pak původnı́ cı́lovou adresu 164.218.1.10 přepı́šeme na novou cı́lovou adresu, a to 192.168.1.6. Když pak paket procházı́ tabulkou filter v řetězci FORWARD, zpracujeme jej právě pravidlem 157 a následně řetězcem to-amonit. Pak již paket dále nenı́ v tabulce filter zpracováván a v tabulce nat také nevyhovuje žádnému pravidlu POSTROUTING (avšak akceptuje jej námi nastavená politika) a je odeslán sı́t’ovým rozhranı́m eth1 právě na server s adresou 192.168.1.6. Zdůrazňuji, že jsme takovému paketu přepsali jen cı́lovou adresu. Zdrojová zůstává stále stejná. Když tento server odpovı́dá tazateli podle zdrojové adresy došlého paketu, tak takováto odpověd (resp. paket) nevyhovuje žádnému pravidlu v tabulce nat v řetězci PREROUTING. Paket je předán do tabulky filter, kde jej zpracuje pravidlo na řádku 150 řetězce FORWARD. Dále paket putuje opět do tabulky nat, kde vyhovı́ pravidlu 208 řetězce POSTROUTING, a akcı́ MASQUERADE je zdrojová adresa přepsána na naši externı́ adresu 164.218.1.10. Takovýto paket pak srpen 2004 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 6.2, str. 7 dı́l 3, Bezpečnost v Linuxu zdroj zpracuje, protože bude patřit spojenı́, které navázal. Totiž spojenı́, jehož jednı́m koncem je tazatel a druhým konecm náš router. Že jsme paket přesměrovali do vnitřnı́ sı́tě, tazatel nepozná. Pro zopakovánı́ uvedu, že akce MASQUERADE kromě jiného přepisuje zdrojovou adresu na primárnı́ adresu takového sı́t’ového rozhranı́, jı́mž bude paket odeslán. To si mechanismus obsluhujı́cı́ tuto akci zjistı́ z routovacı́ tabulky. Dále mechanismus přepı́še zdrojový port na nějakou hodnotu a charakteristiku takového spojenı́ si zapı́še do tabulky. Až k němu dorazı́ odpověd’, tak než paket pustı́ do tabulky nat, přepı́še cı́lovou adresu (a cı́lový port) v odpovědi na adresu (port), kterou tato akce „zamaškarádovala“. Nynı́ nám již zbývá zpracovat požadavek na přesměrovánı́ provozu určeného na služby tcp/1443, tcp/8002 a tcp/443 (https) z původnı́ adresy 164.218.1.11 na adresu 192.168.1.7, a to ve všech přı́padech. Tedy z počı́tačů z našı́ vnitřnı́ sı́tě a z počı́tačů z internetu. Na prvnı́ pohled je situace podobná jako v předchozı́m požadavku v tom, že přesměrováváme provoz na adresu ve vnitřnı́ sı́ti. Avšak musı́me dát pozor na několik věcı́. Ukáže se, že ta podobnost je jen zdánlivá. Pokud přijde na náš server požadavek na adresu 164.218.1.11 a napřı́klad na službu tcp/8002 (a je opět jedno, jestli ze zařı́zenı́ eth0, eth1 či ipsec0), pak jej zpracujeme v tabulce nat v řetězci PREROUTING pravidlem na řádku 189 a následně v řetězci to-terminalPC pravidlem na řádce 202. Paket pak již putuje do tabulky filter, kde jej zpracujeme v řetězci FORWARD v pravidle 156 a následně v řetězci to-terminalPC pravidlem na řádku 139. srpen 2004 část 9, dı́l 3, kapitola 6.2, str. 8 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu Pak paket opět putuje do tabulky nat, avšak nevyhovuje žádnému pravidlu v řetězci POSTROUTING. Vyhovuje však nastavené politice (přı́kaz na řádku 147), a tak opustı́ tabulku nat již beze změny. Tı́m jsme tedy přepsali cı́lovou adresu z 164.218.1.11 na 192.168.1.7. Zdůrazňuji, že je nutné si při tomto výkladu dát pozor, zda se pohybujeme v tabulce nat nebo filter. Řetězec se jménem to-terminalPC máme v obou dvou. Tento paket dorazı́ tedy na server s adresou 192.168.1.7. Předpokládáme, že má v routovacı́ tabulce záznam, že sı́t’ 192.168.1.0/24 routuje přı́mo do svého sı́t’ového rozhranı́ (je přece v našı́ vnitřnı́ sı́ti) a jako svou bránu (default gateway) má uvedenu vnitřnı́ adresu našeho routeru 192.168.1.1. Server 192.168.1.7 nynı́ odešle odpověd’ s cı́lovou adresou, která je stejná jako zdrojová adresa v právě došlém paketu. Mohou nastat dvě situace. Tou prvnı́ je, že tazatel je ze sı́tě 192.168.1.0/24, čili našı́ vnitřnı́ sı́tě. V tom přı́padě jej odešle přı́mo jemu a taková odpověd vůbec nepůjde přes náš router. Tazateli však dorazı́ paket, který se tvářı́, jakože patřı́ nějakému spojenı́, které tazatel sice navazuje, avšak navazuje jej na adresu 164.218.1.11 a z nı́ také očekává odpověd’. Jemu však dorazila odpověd’ z 192.168.1.7. O té si pochopitelně bude myslet, že je to podvrh nebo chyba a takový paket prostě zahodı́. Spojenı́ pak časem vypršı́ a nikdy se nenaváže. Našı́m úkolem je tedy zajistit, aby odpověd šla přes náš router. Toho dosáhneme tak, že než původnı́ paket vypustı́me do sı́t’ového rozhranı́, přepı́šeme mu v tabulce nat v pravidle POSTROUTING zdrojovou adresu. srpen 2004 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 6.2, str. 9 dı́l 3, Bezpečnost v Linuxu Pravidlem na řádku 207 tedy zajistı́me, že všem paketům, které přeposı́láme v tabulce nat serveru 192.168.1.7 a jejichž zdrojová adresa patřı́ někomu z našı́ vnitřnı́ sı́tě, přepı́šeme zdrojovou adresu na našı́ vnitřnı́ adresu 192.168.1.1. Server 192.168.1.7 pak posı́lá odpovědi nám, my takovéto pakety „odmaškarádujeme“, čili cı́lovou adresu přepı́šeme na původnı́ zdrojovou, v tabulce nat se pak v řetězci PREROUTING nic neodehraje, paket putuje do tabulky filter a tam je zpracován v pravidle 150 řetězce FORWARD. Když opouštı́ tabulku nat, tak dı́ky pravidlu v řetězci POSTROUTING na řádku 206 jej zpracujeme v řetězci from-terminalPC pravidlem na řádku 195 a odešleme do sı́tě. K tazateli v našı́ vnitřnı́ sı́t’i pak dorazı́ paket, který má správnou zdrojovou adresu. Druhá situace je taková, že tazatel nepocházı́ z našı́ vnitřnı́ sı́tě. Protože server 192.168.1.7 má v routovacı́ tabulce jako bránu uvedený náš server, tak takováto odpověd’ již půjde přes náš router. Protože jsme nepřepisovali odesı́latelovu zdrojovou adresu, server 192.168.1.7 odpovı́dá tomu, komu má. Našı́m úkolem je tedy jen zajistit přepis zdrojové adresy v odpovědi, aby si tazatel myslel, že komunikuje se serverem s adresou 164.218.1.11 (a správným portem). To zajistı́me pravidlem na řádku 206, kde pošleme paket na zpracovánı́ do řetezce from-terminalPC a pravidlem na řádku 195 zdrojovou adresu a port přepı́šeme. Toto jsme provedli pro spojenı́ na portu tcp/8002, a obdobně to zbývá provést pro služby tcp/443, tcp/1443 a icmp. Pravidlo na řádku 190 pak má usnadnit život uživatelům ve vnitřnı́ sı́ti. Pokud by si ve svém prohlı́žeči srpen 2004 část 9, dı́l 3, kapitola 6.2, str. 10 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu nenastavili jako proxy server náš router, tak by veškeré požadavky na webové stránky skončily v řetězci int-ext. My tı́mto pravidlem takovéto pakety přesměrujeme na náš router na port 3128, kde poslouchá daemon, který službu proxy serveru zajišt’uje. Zbývá probrat pravidlo na řádku 179. Jde o to, že provoz, který je určen našemu routeru, procházı́ také tabulkou nat (jako ostatně všechny pakety). Pravidlo na řádku 178 přesměrovává pouze jeden port, kdežto pravidlo na řádku 179 pak zbývajı́cı́ pakety s našı́ primárnı́ externı́ adresou jakou cı́lovou akceptuje. Tı́m zajistı́me, že bude paket do tabulky filter předán se správnou cı́lovou adresou. Za domácı́ cvičenı́ si můžete zdůvodnit, proč je toto pravidlo v této konfiguraci zbytečné a můžeme jej úplně vypustit :-) Tı́m máme probranou tabulku nat, ve které jsme se právě seznámili s použı́tı́m akcı́ DNAT, SNAT a MASQUERADE. Zbytek přı́kladu je již stejný jako předchozı́ přı́klad. Tı́m je dokončená konfigurace firewallu, jenž splňuje tu politiku, kterou jsme si na začátku stanovili. Možná se vám v tuto chvı́li zdá význam tabulky nat zmatený či přı́liš složitý. Věřte ale, že s přepisovánı́m hlaviček v paketu lze dosáhnout velmi zajı́mavých výsledků a možných řešenı́. K samotnému skriptu, který je nı́že uvedený, je nutno opět dodat, že jeho obsahem by nebyly mezery před čı́sly řádků, samotná čı́sla řádků, dvojtečka za čı́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ý srpen 2004 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 6.2, str. 11 dı́l 3, Bezpečnost v Linuxu 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="164.218.1.10" 5: ext_net0_0="164.218.1.0/48" 6: int_dev0="eth1" 7: int_net0_0="192.168.1.0/24" 8: 9: cal="164.218.1.11" 10: 11: firemni_vpn="192.168.0.0/16" 12: vpn_dev0="ipsec0" 13: 14: ### site zapojene do VPN ### 15: radotin="194.228.230.98" 16: radotin_net="192.168.2.0/24" 17: 18: rubena="80.188.34.34" 19: rubena_net="192.168.3.0/24" 20: 21: frydlant="80.188.42.122" 22: frydlant_net="192.168.4.0/24" 23: 24: boleslav="194.228.230.218" 25: boleslav_net="192.168.5.0/24" 26: 27: hradec="80.188.37.2" 28: hradec_net="192.168.6.0/24" 29: ############################ 30: 31: bystrc="62.245.113.22" 32: ogebenec="212.67.79.70" 33: 34: mitas="193.179.216.60" 35: kontik="213.69.169.146" srpen 2004 část 9, dı́l 3, kapitola 6.2, str. 12 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu 36: 37: amonit="192.168.1.6" 38: terminal="192.168.1.7" 39: 40: fw_prefix="Netfilter" 41: 42: case "$1" in 43: start) 44: echo -n "Starting up IP Firewall: " 45: 46: 47: 48: 49: 50: ## Tabulka filter # Zruseni a vynulovani stavicich pravidel iptables -t filter -F iptables -t filter -X iptables -t filter -Z 51: 52: 53: 54: 55: # nastaveni iptables -t iptables -t iptables -t POLICY filter -P INPUT DROP filter -P FORWARD DROP filter -P OUTPUT ACCEPT 56: 57: 58: 59: 60: # Logovaci retezce iptables -N spoofdrop iptables -A spoofdrop -j LOG iptables -A spoofdrop -j DROP 61: 62: 63: 64: 65: 66: 67: 68: 69: 70: 71: 72: 73: 74: 75: # Anti-spoofing, ktery castecne dela jadro iptables -N spoof iptables -A spoof -i lo -j ACCEPT iptables -A spoof -s "${int_net0_0}" -i "${int_dev0}" iptables -A spoof -s "${radotin_net}" -i "${vpn_dev0}" iptables -A spoof -s "${rubena_net}" -i "${vpn_dev0}" iptables -A spoof -s "${frydlant_net}" -i "${vpn_dev0}" iptables -A spoof -s "${boleslav_net}" -i "${vpn_dev0}" iptables -A spoof -s "${hradec_net}" -i "${vpn_dev0}" iptables -A spoof -s "${ext_net0_0}" -i "${ext_dev}" iptables -A spoof -s "${firemni_vpn}" -j spoofdrop iptables -A spoof -s "${ext_net0_0}" -j spoofdrop iptables -A spoof -s 192.168.0.0/16 -j spoofdrop iptables -A spoof -s 172.16.0.0/12 -j spoofdrop srpen 2004 -j -j -j -j -j -j -j RETURN RETURN RETURN RETURN RETURN RETURN RETURN část 9, dı́l 3, kapitola 6.2, str. 13 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu 76: 77: 78: 79: 80: iptables iptables iptables iptables iptables -A -A -A -A -A spoof spoof spoof spoof spoof -s -s -d -i -j 10.0.0.0/8 -j spoofdrop 127.0.0.0/8 -j spoofdrop 127.0.0.0/8 -j spoofdrop "${ext_dev}" -j RETURN spoofdrop 81: 82: 83: 84: 85: # Pravidla pro skok z INPUTu iptables -N int-fw iptables -A int-fw -p tcp --dport ssh -j REJECT iptables -A int-fw -j ACCEPT 86: 87: 88: 89: 90: 91: 92: iptables iptables iptables iptables iptables iptables -N -A -A -A -A -A ftp-me ftp-me ftp-me ftp-me ftp-me ftp-me iptables iptables iptables iptables -N -A -A -A ssh-me ssh-me -s "${ogebenec}" -j ACCEPT ssh-me -s "${bystrc}" -j ACCEPT ssh-me -j DROP iptables iptables iptables iptables iptables iptables iptables -N -A -A -A -A -A -A to_ipsec to_ipsec to_ipsec to_ipsec to_ipsec to_ipsec to_ipsec iptables iptables iptables iptables iptables iptables iptables iptables iptables -N -A -A -A -A -A -A -A -A bad-fw bad-fw bad-fw bad-fw bad-fw bad-fw bad-fw bad-fw bad-fw -s -s -s -s -j "${mitas}" "${kontik}" "${ogebenec}" "${bystrc}" DROP -j -j -j -j ACCEPT ACCEPT ACCEPT ACCEPT 93: 94: 95: 96: 97: 98: 99: 100: 101: 102: 103: 104: 105: -s -s -s -s -s -j "${radotin}" "${rubena}" "${frydlant}" "${boleslav}" "${hradec}" DROP -j -j -j -j -j ACCEPT ACCEPT ACCEPT ACCEPT ACCEPT 106: 107: 108: 109: 110: 111: 112: 113: 114: 115: -p -p -p -p -p -p -p -p tcp tcp tcp tcp tcp udp tcp 50 --dport --dport --dport --dport --dport --dport --dport smtp https ssh ftp domain domain auth -j -j -j -j -j -j -j -j ACCEPT ACCEPT ssh-me ftp-me ACCEPT ACCEPT REJECT to_ipsec srpen 2004 část 9, dı́l 3, kapitola 6.2, str. 14 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu 116: 117: 118: 119: iptables iptables iptables iptables -A -A -A -A bad-fw bad-fw bad-fw bad-fw iptables iptables iptables iptables iptables iptables iptables iptables iptables -A -A -A -A -A -A -A -A -A INPUT INPUT INPUT INPUT INPUT INPUT INPUT INPUT INPUT -p -p -j -j 51 -j to_ipsec udp --sport 500 --dport 500 -j to_ipsec LOG DROP 120: 121: 122: 123: 124: 125: 126: 127: 128: 129: -j -m -p -p -p -s -i -j -j spoof state --state ESTABLISHED,RELATED tcp \! --syn -m state --state NEW tcp \! --syn -m state --state NEW tcp --syn -m state --state NEW -j "${firemni_vpn}" -j int-fw "${ext_dev}" -j bad-fw LOG DROP -j ACCEPT -j LOG -j DROP LOG 130: 131: 132: 133: 134: # Forwardovaci pravidla iptables -N int-ext iptables -A int-ext -p icmp -j ACCEPT iptables -A int-ext -j REJECT 135: 136: 137: 138: 139: 140: 141: 142: iptables iptables iptables iptables iptables iptables iptables -N -A -A -A -A -A -A to-terminalPC to-terminalPC to-terminalPC to-terminalPC to-terminalPC to-terminalPC to-terminalPC iptables iptables iptables iptables -N -A -A -A to-amonit to-amonit -p tcp -s "${mitas}" --dport 3050 -j ACCEPT to-amonit -p tcp -s "${kontik}" --dport 3050 -j ACCEPT to-amonit -j DROP iptables iptables iptables iptables iptables iptables iptables -A -A -A -A -A -A -A FORWARD FORWARD FORWARD FORWARD FORWARD FORWARD FORWARD -p -p -p -p -p -j tcp --dport https tcp --dport 1443 tcp --dport 8002 tcp --dport auth icmp -j ACCEPT DROP -j -j -j -j ACCEPT ACCEPT ACCEPT REJECT 143: 144: 145: 146: 147: 148: 149: 150: 151: 152: 153: 154: 155: srpen 2004 -j -m -p -p -p -s -s spoof state --state ESTABLISHED,RELATED -j ACCEPT tcp \! --syn -m state --state NEW -j LOG tcp \! --syn -m state --state NEW -j DROP tcp --syn -m state --state NEW -j LOG "${firemni_vpn}" -d "${firemni_vpn}" -j ACCEPT "${int_net0_0}" -o "${ext_dev}" -j int-ext část 9, dı́l 3, kapitola 6.2, str. 15 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu 156: 157: 158: 159: iptables iptables iptables iptables -A -A -A -A FORWARD FORWARD FORWARD FORWARD -d -d -j -j "${terminal}" "${amonit}" LOG DROP -j to-terminalPC -j to-amonit 160: 161: 162: 163: # Vystupni pravidla iptables -A OUTPUT -p tcp --syn -m state --state NEW -j LOG iptables -A OUTPUT -j ACCEPT 164: 165: 166: 167: 168: 169: 170: ## Tabulka nat # zruseni a nulovani stavajicich pravidel iptables -t nat -F iptables -t nat -X iptables -t nat -Z 171: 172: 173: 174: 175: # nastaveni iptables -t iptables -t iptables -t POLICY nat -P PREROUTING ACCEPT nat -P POSTROUTING ACCEPT nat -P OUTPUT ACCEPT 176: 177: 178: 179: iptables -t nat -N to-ext_ip iptables -t nat -A to-ext_ip -p tcp --dport 3050 -j DNAT --to "${amonit}":3050 iptables -t nat -A to-ext_ip -j ACCEPT 180: 181: 182: 183: 184: 185: 186: iptables -t nat -N to-terminalPC iptables -t nat -A to-terminalPC "${terminal}":443 iptables -t nat -A to-terminalPC "${terminal}":1443 iptables -t nat -A to-terminalPC "${terminal}":8002 iptables -t nat -A to-terminalPC iptables -t nat -A to-terminalPC -p tcp --dport https -j DNAT --to -p tcp --dport 1443 -j DNAT --to -p tcp --dport 8002 -j DNAT --to -p icmp -j DNAT --to "${terminal}" -j ACCEPT 187: 188: 189: 190: iptables -t nat -A PREROUTING -d "${ext_ip}" -j to-ext_ip iptables -t nat -A PREROUTING -d "${cal}" -j to-terminalPC iptables -t nat -A PREROUTING -s "${int_net0_0}" -p tcp --dport 80 -j REDIRECT --to-port 3128 srpen 2004 část 9, dı́l 3, kapitola 6.2, str. 16 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu 191: 192: 193: 194: 195: 196: 197: iptables -t nat -N iptables -t nat -A "${cal}":443 iptables -t nat -A "${cal}":1443 iptables -t nat -A "${cal}":8002 iptables -t nat -A "${cal}" iptables -t nat -A from-terminalPC from-terminalPC -p tcp --sport https -j SNAT --to from-terminalPC -p tcp --sport 1443 -j SNAT --to from-terminalPC -p tcp --sport 8002 -j SNAT --to from-terminalPC -p icmp -j SNAT --to from-terminalPC -j RETURN 198: 199: 200: 201: 202: 203: 204: iptables -t nat iptables -t nat MASQUERADE iptables -t nat MASQUERADE iptables -t nat MASQUERADE iptables -t nat MASQUERADE iptables -t nat -N firemni_to_terminalPC -A firemni_to_terminalPC -p tcp --sport https -j -A firemni_to_terminalPC -p tcp --sport 1443 -j -A firemni_to_terminalPC -p tcp --sport 8002 -j -A firemni_to_terminalPC -p icmp -j -A firemni_to_terminalPC -j RETURN 205: 206: 207: 208: iptables -t nat -A POSTROUTING -s "${terminal}" -j from-terminalPC iptables -t nat -A POSTROUTING -s "${int_net0_0}" -d "${terminal}" -j firemni_to_terminalPC iptables -t nat -A POSTROUTING -s "${int_net0_0}" -o "${ext_dev}" -j MASQUERADE 209: 210: 211: 212: 213: 214: 215: 216: 217: 218: 219: ## Tabulka mangle iptables -t mangle iptables -t mangle iptables -t mangle iptables -t mangle iptables -t mangle iptables -t mangle iptables -t mangle iptables -t mangle 220: srpen 2004 -F -X -Z -P -P -P -P -P PREROUTING ACCEPT INPUT ACCEPT FORWARD ACCEPT OUTPUT ACCEPT POSTROUTING ACCEPT část 9, dı́l 3, kapitola 6.2, str. 17 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu 221: 222: 223: touch /var/lock/subsys/firewall echo "Done." ;; 224: 225: stop) 226: 227: 228: 229: 230: 231: 232: 233: 234: 235: 236: 237: 238: 239: 240: 241: 242: 243: 244: 245: 246: 247: 248: 249: echo -n $"Resetting built-in chains to the default ACCEPT policy:" iptables -t filter -F && \ iptables -t filter -X && \ iptables -t filter -Z && \ iptables -t filter -P INPUT ACCEPT && \ iptables -t filter -P OUTPUT ACCEPT && \ iptables -t filter -P FORWARD ACCEPT && \ iptables -t nat -F && \ iptables -t nat -X && \ iptables -t nat -Z && \ iptables -t nat -P PREROUTING ACCEPT && \ iptables -t nat -P POSTROUTING ACCEPT && \ iptables -t nat -P OUTPUT ACCEPT && \ iptables -t mangle -F && \ iptables -t mangle -X && \ iptables -t mangle -Z && \ iptables -t mangle -P PREROUTING ACCEPT && \ iptables -t mangle -P INPUT ACCEPT && \ iptables -t mangle -P FORWARD ACCEPT && \ iptables -t mangle -P OUTPUT ACCEPT && \ iptables -t mangle -P POSTROUTING ACCEPT && \ echo $"Resetting built-in chains to the default ACCEPT policy" || \ echo $"Resetting built-in chains to the default ACCEPT policy" 250: 251: ;; 252: 253: *) 254: 255: echo $"Usage: $0 exit 1 [start | stop]" 256: ;; 257: 258: esac 259: exit 0 srpen 2004 část 9, dı́l 3, kapitola 6.2, str. 18 dı́l 3, Bezpečnost v Linuxu srpen 2004 BEZPEČNÁ POČÍTAČOVÁ SÍŤ BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 6.3, str. 1 dı́l 3, Bezpečnost v Linuxu 9/3.6.3 PŘÍKLAD POUŽITÍ TABULKY MANGLE Celý tento přı́klad svou koncepcı́ zapadá do kapitoly o omezovánı́ sı́t’ového provozu na úrovni protokolu IP. Zde tedy uvedu jen přı́klad, na který se budu odkazovat právě z oné kapitoly o omezovánı́ sı́t’ového provozu. Tabulka mangle se v linuxovém firewallu netfilter použı́vá zřı́dka. Je vhodná zejména ke značkovánı́ paketů. Takové značkovánı́ se hodı́ zejména v přı́padě, že pakety dále zpracováváme (at’ už na počı́tači, kde značkujeme, nebo nějakém dalšı́m počı́tači, kudy musı́ sı́t’ový provoz procházet). V linuxových jádrech do verze 2.4.17 včetně měla tabulka mangle pouze dva vestavěné řetězce. PREROUTING pro zpracovánı́ přı́chozı́ch paketů před routovánı́m a OUTPUT pro zpracovánı́ paketů vygenerovaných lokálně a zpracovaných opět před routovánı́m. Od jádra 2.4.18 pak přibyly řetězce INPUT pro pakety přicházejı́cı́ dovnitř počı́tače, únor 2005 část 9, dı́l 3, kapitola 6.3, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu FORWARD pro pakety procházejı́cı́ routovacı́m procesem počı́tače a POSTROUTING pro pakety, které z počı́tače odcházejı́. K označenı́ paketu přı́slušnou značkou sloužı́ u přı́kazu iptables akce MARK. Pokud paket vyhovı́ danému pravidlu, je označen. Jeho průchod firewallem však nekončı́ (napřı́klad na rozdı́l od akcı́ ACCEPT či DROP), ale pokračuje dalšı́m pravidlem. Proto je nutné při vytvářenı́ posloupnosti pravidel postupovat od obecných podmı́nek ke konkrétnějšı́m. Zadánı́ únor 2005 Definice zadánı́ v kapitole o omezovánı́ sı́t’ového provozu je pak následujı́cı́. Jsme většı́ firmou přistupujı́cı́ do Internetu přes jedinou veřejnou adresu, kterou jsme dostali od poskytovatele připojenı́. V budově, kde sı́dlı́ naše firma, však sı́dlı́ ještě jiná firma, která je připojena do našı́ vnitřnı́ sı́t’ě a která také přes naši veřejnou adresu přistupuje do Internetu. Řekněme, že naše firma použı́vá sı́t’192.168.0.0 s maskou 255.255.255.0 a ona druhá firma použı́vá 192.168.1.0 s maskou 255.255.255.0. Rychlost našı́ linky při uploadu je 512/768 kbps (download/upload). Rádi bychom přidělené pásmo rozdělili tak, že naše firma bude použı́vat 300/500 kbps kapacity linky a sousednı́ firma 212/268 kbps kapacity. V patřičném poměru se takto dělı́ i o cenu fakturovanou poskytovatelem. A dále bychom chtěli, aby počı́tač 192.168.0.30, který je v našı́ vnitřnı́ sı́ti, měl alespoň garantovanou rychlost 128 kbps. Je to totiž počı́tač našeho ředitele, který má připojenou IP telefonii a občas telefonuje přes Internet, a je nutné mu garantovat tuto rychlost. Dále si přejeme, aby vzájemný provoz mezi našı́ firmou a sousednı́ firmou nebyl nijak omezován. Nakonec jen dodám, že veřejná adresa našeho routeru je 123.45.67.8, adresa do našı́ vnitřnı́ sı́tě je 192.168.0.1 a adresa do BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 6.3, str. 3 dı́l 3, Bezpečnost v Linuxu vnitřnı́ sı́tě sousednı́ firmy je 192.168.1.1. Skutečnost, zdali jsou segmenty firemnı́ch sı́tı́ fyzicky odděleny (a náš router má v tomto přı́padě tři ethernetové karty) nebo jsou na jednom segmentu (a náš router má v tomto přı́padě pravděpodobně dvě ethernetové karty), je v tuto chvı́li nepodstatná. Uvedu zde jen část firewallovacı́ch pravidel, a to těch, které se týkajı́ tabulky mangle. Samozřejmě bude nutné správně nakonfigurovat i pravidla v tabulkách filter a nat, ovšem to dostatečně popisujı́ předchozı́ přı́klady použitı́ firewallu. Pro náš přı́klad je vhodné označkovávat pakety, které nejsou v principu určené našemu počı́tači, v řetězci FORWARD, protože zde jsou pakety z vnitřnı́ch sı́tı́ před maškarádou (a tudı́ž nemajı́ zkreslenou zdrojovou adresu) a pakety z Internetu jsou již po odmaškarádovánı́, tudı́ž konečná správná cı́lová adresa je také známa. Pakety, které generuje náš router, označkujeme v pravidlech řetězce OUTPUT. Jediné, co neznačkujeme, jsou pakety, které jsou určeny našemu počı́tači. Na řádcı́ch 1 až 6 definujeme proměnné, které dále použijeme v přı́kladu našeho firewallu. Na řádcı́ch 9 až 16 definujeme defaultnı́ politiku pravidel v jednotlivých řetězcı́ch. Na řádku 18 označı́me všechen provoz, který generujı́ počı́tače z našı́ vnitřnı́ sı́tě a který nenı́ určený pro náš router. Jsme totiž v pravidle FORWARD. Bude sem patřit provoz, jenž směřuje do Internetu (neznáme cı́lovou adresu), a dále provoz, který směřuje do vnitřnı́ sı́tě sousednı́ firmy. Na řádku 19 je pak provoz, který generuje počı́tač pana ředitele. únor 2005 část 9, dı́l 3, kapitola 6.3, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu Na řádku 20 je obdobně totéž pro pakety směřujı́cı́ do našı́ vnitřnı́ sı́tě. Na řádku 21 pak označı́me provoz, který směřuje do počı́tače pana ředitele. Dále na řádcı́ch 22 a 23 označı́me provoz, který směřuje z a do vnitřnı́ sı́tě sousednı́ firmy. My však potřebujeme jinou značkou označit provoz, který je mezi vnitřnı́mi sı́těmi našı́ a sousednı́ firmy. Učinı́me tak na řádcı́ch 24 a 25. Pak je ještě nutno označit provoz, který generuje náš router. To provedeme na řádku 26, 27 a 28. Označili jsme tak veškerý provoz, který odcházı́ z našeho routeru, a máme neoznačen jen ten provoz, který směřuje z vnitřnı́ch sı́tı́ a z Internetu na náš router. Proč takový provoz neoznačı́me, je vysvětleno v kapitole o omezovánı́. únor 2005 část 9, dı́l 3, kapitola 6.3, str. 5 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu T Tabulka značek pro veškerý provoz adresa zdrojová cı́lová značka 192.168.0.0/24 192.168.0.1 nenı́ 192.168.0.0/24 Internet 20 192.168.0.30 Internet 22 192.168.0.0/24 192.168.1.0/24 40 192.168.1.0/24 192.168.1.1 nenı́ 192.168.1.0/24 192.168.0.0/24 40 192.168.1.0/24 Internet 30 123.45.67.8 Internet 50 192.168.0.1 192.168.0.0/24 40 192.168.1.1 192.168.1.0/24 40 Internet 192.168.0.0/24 21 Internet 192.168.0.30 24 Internet 192.168.1.0/24 31 Internet 123.45.67.8 nenı́ 1: nase_verejna_ip="123.45.67.8" 2: vnitrni_ip_0="192.168.0.1" 3: vnitrni_ip_1="192.168.1.1" 4: net_nase_firma="192.168.0.0/24" 5: pc_nas_reditel="192.168.0.30" 6: net_sousedni_firma="192.168.1.0/24" 7: 8: 9: 10: 11: 12: 13: 14: # Tabulka mangle iptables -t mangle iptables -t mangle iptables -t mangle iptables -t mangle iptables -t mangle iptables -t mangle -F -X -Z -P PREROUTING ACCEPT -P INPUT ACCEPT -P FORWARD ACCEPT únor 2005 část 9, dı́l 3, kapitola 6.3, str. 6 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu 15: 16: iptables -t mangle -P OUTPUT ACCEPT iptables -t mangle -P POSTROUTING ACCEPT 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: iptables -t mangle -A FORWARD -j iptables -t mangle -A FORWARD -j iptables -t mangle -A FORWARD -j iptables -t mangle -A FORWARD -j iptables -t mangle -A FORWARD -j "${net_sousedni_firma}" iptables -t mangle -A FORWARD -j "${net_sousedni_firma}" iptables -t mangle -A FORWARD -j -d ${net_sousedni_firma}" iptables -t mangle -A FORWARD -j -s ${net_sousedni_firma}" iptables -t mangle -A OUTPUT -j iptables -t mangle -A OUTPUT -j iptables -t mangle -A OUTPUT -j únor 2005 MARK MARK MARK MARK MARK --mark --mark --mark --mark --mark 20 22 21 24 30 -s -s -d -d -s "${net_nase_firma}" "${pc_nas_reditel}" "${net_nase_firma}" "${pc_nas_reditel}" MARK --mark 31 -d MARK --mark 40 -s "${net_nase_firma} MARK --mark 40 -d "${net_nase_firma} MARK --mark 40 -s "${vnitrni_ip_0}" MARK --mark 40 -s "${vnitrni_ip_1}" MARK --mark 50 -s "${nase_verejna_ip}" BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 7, str. 1 dı́l 3, Bezpečnost v Linuxu 9/3.7 IDS IDS (Intrusial Detection System) jsou aplikace určené pro automatickou detekci nejrůznějšı́ch forem útoků cı́lených na daný server. Sami o sobě nezvyšujı́ bezpečnost daného systému, ale jejich použitı́ umožňuje administrátorovi sledovat potenciálně nebezpečné akce na sı́ti/systému. IDS IDS systémy můžeme rozdělit do třı́ kategoriı́: • klasické (offline) IDS, • sı́t’ové (realtime) IDS, • IDS spolupracujı́cı́ s TCP/IP zásobnı́kem operačnı́ho systému. Poslednı́ typ IDS systému nenı́ v současné době přı́liš běžný. Na rozdı́l od předchozı́ch typů analyzuje pakety ještě před tı́m, než jsou dále zpracovány v operačnı́m systému a aplikacı́ch, což umožňuje IDS potenciálně prosinec 2003 část 9, dı́l 3, kapitola 7, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu nebezpečné pakety zahazovat a zvyšovat tı́m bezpečnost stroje či celé sı́tě. Offline IDS jsou zvláštnı́ skupinou mezi IDS řešenı́mi, nemonitorujı́ sı́t’ový provoz, ale logy systému/programů. V některých ohledech jsou lepšı́ než sı́t’ové IDS (pro sı́t’ová IDS je např. obtı́žně určitelné, zda byl pokus o průnik úspěšný). Naproti tomu sı́t’ové IDS systémy fungujı́ tak, že monitorujı́ veškerý sı́t’ový provoz a analyzujı́ ho. Jednotlivé schopnosti a možnosti IDS se lišı́. Nicméně nejčastějšı́m cı́lem pozornosti IDS jsou pokusy o průnik pomocı́ známějšı́ch nástrojů využı́vajı́cı́ch známých bezpečnostnı́ch chyb, pokusy o skenovánı́ portů a taktéž neplatné pakety, které jsou často použı́vány pro identifikaci použı́vaného operačnı́ho systému či obcházenı́ jednoduššı́ch firewallů. IDS systémy nemusı́ být omezeny pro detekci nebezpečného provozu z venkovnı́ch sı́tı́, stejně tak dobře může být monitorován provoz na lokálnı́ sı́ti. To může administrátoru posloužit na detekci přı́padných problémů na lokálnı́ sı́ti – jako např. šı́řenı́ nejrůznějšı́ch červů. Možné je i použitı́ jako nástroje pro monitorovánı́ aktivity uživatelů – modernı́ IDS systémy obsahujı́ např. pravidla pro detekci sı́t’ového provozu generovaného různými P2P systémy. IDS tedy obecně kontrolujı́ obsah paketů a vlastnosti spojenı́. Jsou tedy o úroveň výše než paketový filtr zmı́něný v předchozı́ kapitole. IDS řešenı́ na Linuxu prosinec 2003 Jednı́m z nejznámějšı́ch open source IDS systémů pro Linux je bezpochyby SNORT. Jedná se o sı́t’ové IDS řešenı́. Podporuje detekci velkého množstvı́ sı́t’ového BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 7, str. 3 dı́l 3, Bezpečnost v Linuxu provozu pomocı́ předdefinovaných pravidel. SNORT je navržen natolik otevřeně, že nenı́ problém si do něj přidat dalšı́ pravidla a tı́m si SNORT přizpůsobit. Samozřejmostı́ je též obrana proti pokusům o skrytı́ nebezpečného sı́t’ového provozu před IDS (např. silné fragmentovánı́, zahlcovánı́ IDS pakety se změněnými zdrojovými IP adresami obsahujı́cı́mi data, která způsobı́ logovánı́ nepovoleného sı́t’ového provozu u IDS atd.) Dalšı́m velice dobrým IDS na Linuxu je projekt LIDS. Jedná se o úplně jiný druh IDS než SNORT, LIDS je z většiny umı́stěn v jádře a měnı́ standardnı́ bezpečnostnı́ model v Linuxu. LIDS umožňuje administrátorovi velmi podrobně nastavit pro každou aplikaci ACL práva pro přı́stup k souborovému systému, omezit jejı́ použı́vánı́ sı́tě atd. Kromě toho poskytuje některé základnı́ služby sı́t’ového IDS, jako např. detekci skenovánı́ portů. Nutno poznamenat, že ačkoliv LIDS velmi výrazně zvětšuje bezpečnost celého systému, jeho konfigurace je netriviálnı́ a nenı́ doporučována začı́najı́cı́m administrátorům. Kromě standardnı́ch možnostı́ zabezpečenı́ existuje ještě několik patchů jádra, které měnı́ standardnı́ bezpečnostnı́ systém. Tyto patche nahrazujı́ standardnı́ bezpečnostnı́ model vlastnı́m, vı́ce konfigurovatelným. Jednı́m z nejznámějšı́ch podobných patchů je grsecurity. Ten zavádı́ možnost ACL práv na úrovni procesu, každému procesu jsou přiřazena zvláštnı́ práva k souborovému systému. Dále pak u každého procesu můžeme nastavit, jaká práva (capabilities) bude mı́t daný proces v jádře. Pomocı́ tohoto patche a jeho vhodného nakonfigurovánı́ je možné výrazně zvýšit bezpečnost systému. Na většině serverů je spuštěno většı́ či menšı́ množstvı́ daemonů (serverů). Vyššı́ metody zabezpečenı́ systému prosinec 2003 část 9, dı́l 3, kapitola 7, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu Některé z nich musejı́ pracovat pod účtem superuživatele, protože jinak by neměly přı́stup k určitým funkcionalitám operačnı́ho systému (přı́kladem takového serveru je např. SSHD) grsecurity a podobné patche řešı́ problémy s možnou děravostı́ takovýchto kritických serverů – i když se útočnı́kovi podařı́ zı́skat dı́ky bezpečnostı́ chybě v takovémto serveru účet root (či jiný lokálnı́ účet), dı́ky grsecurity budou jeho možnosti hodně omezené. Při správné konfiguraci ACL práv nebude mı́t možnost zapsat do adresářů s programy, nebude mı́t přı́stup k některým funkcı́m jádra (jako např. natahovánı́ modulů, přı́stup k firewallu atd.). Je tudı́ž i po kompromitaci jednoho daemonu slušná šance, že útočnı́k nebude moci kompromitovat celý systém. Grsecurity patch též poskytuje velmi rozsáhlé možnosti auditu, nenı́ u něj problém např. logovat veškeré aktivity některých uživatelů či aktivit na systému. Součástı́ grsecurity je též patch PaX, který se stará o ochranu paměti a ztěžuje pokusy o zneužitı́ chyb práce s pamětı́ (což jsou na UNIXech jedny z nejčastějšı́ch) pomocı́ několika technik (nespustitelné stránky, randomizace adresnı́ho prostoru aplikace, . . . ). Nicméně grsecurity je poměrně složitý patch, jeho konfigurace netriviálnı́ a časově náročná, tudı́ž by ji měli provádět jen zkušenějšı́ administrátoři. Navı́c platı́, že samotná instalace grsecurity nestačı́, předevšı́m ACL práva a omezenı́ práv (capabilities) musı́ být vhodně nastavena, jinak grsecurity žádné zvýšenı́ bezpečnosti nepřinese (či naopak způsobı́ problémy s během některých aplikacı́). prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 8, str. 1 dı́l 3, Bezpečnost v Linuxu 9/3.8 NESSUS Zabezpečenı́ linuxového serveru může být poměrně náročná záležitost. Na typickém linuxovém serveru běžı́ poměrně značná sbı́rka různých programů, v nichž se čas od času mohou objevit bezpečnostnı́ chyby. Ale samotné pravidelné záplatovánı́ nestačı́, systém musı́ být nějakým rozumným způsobem nakonfigurován, aby byl bezpečný. Při zabezpečovánı́ serveru je poměrně snadné něco opomenout. Proto existujı́ různé nástroje, které mohou administrátorovi tuto úlohu ulehčit. Prvnı́ nástroj podobného typu se objevil v polovině devadesátých let a nesl poetické označenı́ SATAN (Security Administrator Tool for Analyzing Networks), umožňoval hledat několik druhů běžných bezpečnostnı́ch chyb na specifikovaných strojı́ch. Nessus Od začátku bylo jasné, že takovýto nástroj na jednu stranu sice představuje způsob ulehčenı́ administrace, ale na druhou stranu poskytuje útočnı́kovi velmi prosinec 2003 část 9, dı́l 3, kapitola 8, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu jednoduchou možnost, jak otestovat stroj, o jehož kompromitaci se pokoušı́, na přı́tomnost několika běžných bezpečnostnı́ch chyb. Nicméně na nástroj SATAN postupem času navázaly dalšı́ podobné nástroje. Jednı́m z nich je Nessus, který taktéž představuje určitý druh penetračnı́ho testu. Nessus je bezpečnostnı́ scanner. Umožňuje administrátorovi jednoduše otestovat bezpečnost sı́t’ových služeb spuštěných na serveru. Nessus zjišt’uje, jaké služby jsou na daném počı́tači spuštěné a pak se pokoušı́ o zjištěnı́ (přesněji většinou se pokoušı́ o jejich zneužitı́) některých známých bezpečnostnı́ch chyb v nich. Kromě toho je schopen detekovat např. přı́tomnost některých backdoorů (samozřejmě jen těch, které lze detekovat přes sı́t’) a provádět dalšı́ bezpečnostnı́ audit. Na závěr administrátorovi sestavı́ podrobný report, kde jsou popsána jednotlivá zjištěná bezpečnostnı́ rizika. Často též doplnı́ instrukce, jak zneužitı́ této chyby zabránit, popř. i odkaz na podrobnějšı́ informace (např. konference bugtraq, databáze bezpečnostnı́ch chyb CVE či CERT). To administrátorovi umožňuje poměrně rychle a jednoduše otestovat bezpečnostnı́ stav svých serverů. Nicméně je nutno poznamenat, že Nessus zdaleka nenı́ nástrojem neomylným a všeodhalujı́cı́m. Spı́še se jedná o pomůcku, která může administrátorovi usnadnit zabezpečovánı́ serverů. Co činı́ Nessus zajı́mavým oproti ostatnı́m podobným produktům? Předevšı́m se jedná o velice ucelený produkt schopný detekovat velmi širokou škálu bezpečnostnı́ch problémů. Je postaven na architektuře klient-server, ze serveru probı́há ono scannovánı́, jeho průběh je nicméně řı́zen klientem. Server je provozuschopný na velkém množstvı́ UNIXových operačnı́ch systémů, tudı́ž samozřejmě i na Linuxu. Stejně tak i prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 8, str. 3 dı́l 3, Bezpečnost v Linuxu klient je k dispozici pro mnoho platforem, dokonce existuje i klient pro platformu Microsoft Windows. Dalšı́ nespornou výhodou scanneru Nessus je jeho snadná rozšiřitelnost. Umožňuje snadné přidánı́ dalšı́ch testů pomocı́ zásuvných modulů napsaných v jazyce C. Dále pak umožňuje implementaci dalšı́ch testů v jazyce NASL (Nessus Attack Scripting Language). Nessus se při scannovánı́ snažı́ být co nejvı́ce důsledný – nepředpokládá přı́tomnost určitých služeb na pevně daných portech (např. http server na portu 80), taktéž nehledı́ na zjištěné verze softwaru. Nessus se automaticky snažı́ zjistit, jaká služba běžı́ na daném portu a podle toho volı́ přı́slušné testy. Instalaci produktu Nessus musı́me provádět pod uživatelem root. Instalace Existujı́ v podstatě tři možnosti, jak nainstalovat Nessus. Prvnı́ a nejjednoduššı́ je instalace balı́ku vytvořeného pro danou distribuci. Takový balı́k je např. k dispozici pro Debian. Dalšı́ možnostı́ je kompilace. Ta může být provedena bud’ automaticky pomocı́ skriptu nebo manuálně. Onen skript i samostatné zdrojové soubory klientské i serverové části můžeme stáhnout z www.nessus.org. Pro kompilaci pomocı́ skriptu stáhneme z těchto stránek skript nessus-installer.sh, který následně spustı́me. Skript se zeptá na několik informacı́, např. kam chceme Nessus nainstalovat, a automaticky spustı́ kompilaci. Nicméně je možné, že skript nahlásı́ nepřı́tomnost některých knihoven (např. GTK), v takovém přı́padě musı́me doinstalovat přı́slušné balı́čky. Je nutné nainstalovat jak balı́ky obsahujı́cı́ ony knihovny, tak přı́slušné vývojové (devel) balı́ky k nim. prosinec 2003 část 9, dı́l 3, kapitola 8, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu Po úspěšné kompilaci spustı́me na stroji, kde budeme chtı́t provozovat serverovou část, program nessus-mkcert. Tento skript sloužı́ k vygenerovánı́ X.509 certifikátu serveru. Certifikát se použı́vá k autentizaci serveru při připojenı́ z klienta (ochrana proti man-in-the-middle útokům). Veškerá komunikace mezi klientem a serverem probı́há šifrovaně pomocı́ protokolu SSL. Pro přı́stup k serverové části Nessus je nutno vytvořit uživatelské účty v jeho databázi (tito uživatelé nepotřebujı́ normálnı́ účet na daném stroji). Oprávněnı́ jednotlivých uživatelů se mohou lišit, stejně tak je možno omezit stroje, u nichž mohou provádět bezpečnostnı́ audit pomocı́ tohoto nástroje. K vytvořenı́ uživatelů sloužı́ program nessus-adduser. Opět se jedná o interaktivnı́ program, který se zeptá na všechny potřebné údaje. Podrobnějšı́ informace naleznete v části „Správa uživatelů“. Použitı́ Jak již bylo řečeno, Nessus funguje na architektuře klient-server. Pro jeho použitı́ tudı́ž musı́me nejprve na nějakém stroji pustit serverovou část – program nessusd. Tento program musı́ být spuštěný pod uživatelem root. Klientskou část spustı́me pomocı́ přı́kazu nessus. Po spuštěnı́ se nám objevı́ základnı́ obrazovka, v nı́ž můžeme specifikovat, na kterém stroji je spuštěna serverová část Nessusu a přihlašovacı́ informace. prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 8, str. 5 dı́l 3, Bezpečnost v Linuxu Obrázek: Nessus – klient: O Po přihlášenı́ nám Nessus nabı́dne možnost určit, jaké testy majı́ být provedeny. Pro přehlednost jsou rozděleny do několika kategoriı́: když klikneme na název testu, tak se zobrazı́ podrobné informace o daném testu. Na dalšı́ kartě je možné nastavit mnoho parametrů scanu. Jako prvnı́ můžeme nastavit parametry scanu prováděného nástrojem nmap. To je poměrně vyspělý nástroj sloužı́cı́ kromě jiného ke zjištěnı́ otevřených prosinec 2003 část 9, dı́l 3, kapitola 8, str. 6 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu portů (u protokolu TCP, omezeně i UDP) na daném stroji. Pro většinu situacı́ nastavı́me metodu scannovánı́ portů bud’ na connect() nebo SYN scan. Metoda connect() scan je nejběžnějšı́ typ scannovánı́ portů – nmap se při něm pokoušı́ o připojenı́ na daný port striktně podle RFC. Naproti tomu při SYN scanu nenı́ procedura otevřenı́ portu provedena striktně až do konce – čı́mž může zabránit zalogovánı́ onoho pokusu o spojenı́ u jednoduššı́ch firewallů. Operačnı́ systém vzdálenoho stroje může být též detekován pomocı́ typického chovánı́ jeho TCP/IP zásobnı́ku. To může být nežádoucı́, čı́m méně informacı́ má potenciálnı́ útočnı́k o stroji, tı́m je menšı́ šance, že se mu podařı́ provést úspěšný průnik. Nessus nám nabı́zı́ volbu „Identify the remote OS“, po jejı́m zaškrtnutı́ se prostřednictvı́m nástroje nmap pokusı́ vydedukovat operačnı́ systém daného stroje. Dále můžeme nastavit rozsah portů, které se majı́ scannovat. Krom scanu všech portů v rozsahu zadaném na dalšı́ kartě je možné scannovat pouze porty, na kterých běžně poslouchá nějaký program. Takovéto porty jsou uloženy v souboru nmap-services, spolu s popisem daemonu, jenž tento port běžně využı́vá. Dalšı́ možnostı́ je scannovánı́ všech portů v této databázi a ještě všech privilegovaných portů. Privilegované porty jsou takové, které majı́ čı́slo menšı́ než 1024. Na těchto portech může poslouchat jen daemon spuštěný s právy roota. Volba „Timing policy“ určuje rychlost scanu. Ve většině přı́padů můžeme nastavit rychlost na nejvyššı́ možné nastavenı́ – „Insane“. Výjimkou je ovšem situace, kdy máme na daném stroji nainstalovaný nějaký firewall, který má ochranu proti DoS útokům a zahazuje pakety, pokud přicházejı́ přı́liš rychle z jednoho stroje. prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 8, str. 7 dı́l 3, Bezpečnost v Linuxu Pozornost dále věnujme části Login configurations, pro některé scany je nutné nastavit platné uživatelské jméno pro dané služby. Obrázek: Nessus – nastavenı́ uživatelských jmen: O Na dalšı́ kartě nalezneme možnost nastavit rozsah portů, který se bude scannovat. Při použitı́ daemonu, který pracuje na nějakém nestandardnı́m portu, budeme muset pravděpodobně zvětšit standardně nastavený rozsah. Za zmı́nku stojı́ volba „Designate hosts by their MAC address“, která určı́, že Nessus bude identifikovat jednotlivé scannované stroje podle jejich MAC adresy mı́sto IP adresy. Tato volba je užitečná, pokud prosinec 2003 část 9, dı́l 3, kapitola 8, str. 8 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu provádı́me scannovánı́ sı́tě, v nı́ž se IP adresy přidělujı́ dynamicky pomocı́ DHCP. Nessus má dvě možnosti, jak zjistit, zda daný software obsahuje bezpečnostnı́ chybu – prvnı́ možnostı́ je pokusit se o jejı́ zneužitı́ a druhou je určenı́ možné přı́tomnosti chyby podle zjištěné verze daného softwaru. Prvnı́ metoda je o poznánı́ spolehlivějšı́, nicméně může způsobit pád dané služby, pokud skutečně danou bezpečnostnı́ chybu obsahuje. Druhá možnost je bezpečnějšı́, ale na druhou stranu nenı́ schopna poznat, že např. daný software obsahuje záplatu opravujı́cı́ danou bezpečnostı́ chybu, a tak může dojı́t k falešným poplachům. Ve většině přı́padů je lepšı́ použı́t prvnı́ možnost, je spolehlivějšı́, a pokud dojde k shozenı́ služby, tak se ve většině přı́padů nic až tak kritického nestane, když ji vlastně takto mohl shodit (nebo rovnou kompromitovat) jakýkoliv útočnı́k se sı́t’ovým přı́stupem k serveru. Ovšem záležı́ na druhu bezpečnostnı́ chyby – v ojedinělých přı́padech může dojı́t k pádu celého systému či některé životně důležité služby (např. sshd, což by administrátoru ve většině přı́padů znemožnilo vzdálený přı́stup na server). Na této kartě též můžeme nastavit maximálnı́ počet strojů, které majı́ být scannovány zároveň, a maximálnı́ počet testů, které mohou být zároveň spuštěny při scanu jednoho stroje. Přı́liš vysoké hodnoty se nedoporučujı́. Na dalšı́ kartě můžeme konečně nastavit, jaké stroje chceme scannovat. Můžeme specifikovat IP adresu jednoho stroje nebo rozsah v syntaxi počátečnı́ IP – koncová IP (např. 172.16.17.1-172.16.17.3). Pak již nic nebránı́ pustit scan. Ten většinou bude trvat mnoho minut. Po jeho úspěšném dokončenı́ Nessus prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 8, str. 9 dı́l 3, Bezpečnost v Linuxu zobrazı́ výsledky. Zobrazı́ otevřené porty na daném stroji a popř. i jména služeb na nich nalezených. Tento výsledný report můžeme exportovat do mnoha formátů, např. HTML či LaTEX. Při nalezenı́ bezpečnostnı́ho problému vypı́še přı́slušné varovánı́. Obrázek: Nessus – výsledky testu: Při vytvářenı́ nástroje Nessus byl brán zřetel i na to, že jeden server může být použı́ván vı́ce než jednı́m uživatelem. A tito uživatelé nemusejı́ mı́t stejné pravomoci. Uživatele se dělı́ na normálnı́ a administrátorské. Ti s právy administrátora majı́ předevšı́m právo nahrávat nové scannovacı́ pluginy do globálnı́ch adresářů s pluginy, jež jsou samozřejmě sdı́leny všemi uživateli. Běžný uživatel může pluginy nahrávat pouze do svého adresáře. Dále má každý uživatel nastaveno, jaké stroje smı́ či nesmı́ scannovat z tohoto serveru. O Správa uživatelů prosinec 2003 část 9, dı́l 3, kapitola 8, str. 10 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu Těmto nastavenı́m je nutné věnovat pozornost zejména v přı́padě, že nessusd je puštěný na nějaké veřejné IP a má k němu přı́stup vı́ce uživatelů. Např. pokud bychom měli nessusd puštěný na serveru, který je zároveň NAT pro lokálnı́ sı́t’, tak by bez dalšı́ch nastavenı́ všichni uživatelé s účtem na nessusd mohli oscannovat např. i celou lokálnı́ sı́t’, pro kterou dělá onen stroj NAT. Řešenı́m by tedy bylo zakázat scan adresnı́ho rozsahu lokálnı́ sı́tě. V přı́padě obav o to, že by uživatelé mohli použı́t tento nessusd na oscannovánı́ nějakého cizı́ho stroje (u kterého by se pochopitelně v logu objevila IP onoho stroje s nessusd), můžeme např. scan omezit na IP, z které se aktuálně připojujı́ nessusd. Dalšı́ věcı́, kterou můžeme u každého uživatele nastavit, je autentizačnı́ metoda. Každý uživatel se může autentizovat bud’ nastaveným heslem nebo pomocı́ certifikátu. Certifikát pochopitelně představuje bezpečnějšı́ způsob autentizace, ale v praxi se u nástroje Nessus přı́liš nepoužı́vá. Jednotlivé uživatele můžeme přidávat pomocı́ programu nessus-adduser. Jedná se o interaktivnı́ program, který se zeptá na uživatelské jméno, autentizačnı́ metodu, heslo, popř. dname (distinguished name) certifikátu. Dále nám umožnı́ omezit práva daného uživatele pomocı́ několika pravidel. Syntaxe těchto pravidel je: accept/deny IP/maska default deny/accept Jak již je jasné z názvu, direktiva accept specifikuje subsı́t’, kterou může uživatel scannovat a deny naopak zakazuje. Direktivou default můžeme určit, zda má prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 8, str. 11 dı́l 3, Bezpečnost v Linuxu uživatel právo scannovat všechny stroje kromě zakázaných (volba accept), či naopak má právo scannovat pouze explicitně povolené subsı́tě. Mı́sto IP adresy a masky můžeme použı́t volbu client ip, která bude v pravidlu značit IP adresu klienta, z které se připojuje. Přı́klad pravidel pro povolenı́ scanu vlastnı́ IP adresy a subsı́tě 172.16.17.0/24: accept 172.16.17.0/24 accept client\_ip default deny Dalšı́m nástrojem pro práci s uživatelskou databázı́ je nessus-rmuser, pomocı́ nějž můžeme zrušit existujı́cı́ho uživatele. Mějme modelovou lokálnı́ sı́t’, na které je linuxový server obstarávajı́cı́ DNS, poštu, SSH a IMAP server. Server je připojený do sı́tě Internet a funguje jako NAT (Network Address Translation) pro lokálnı́ sı́t’. Tento stroj bude mı́t IP adresu 172.16.17.1. Dále bude na našı́ modelové sı́ti stroj s IP adresou 172.16.17.3 s nainstalovaným operačnı́m systémem firmy Microsoft. Stroj je použı́ván pro běžnou administrativnı́ práci, nenı́ na něm provozována žádná služba. Poslednı́ stroj v této sı́ti bude mı́t IP 172.16.17.2, bude na něm běžet Linux a taktéž to bude stroj, z kterého budeme pouštět scan. Cı́lem scanu bude provést základnı́ bezpečnostnı́ audit strojů na lokalnı́ sı́ti. Přı́klad použitı́ nástroje Nessus Na stroji 172.16.17.2 pustı́me nmapd a vytvořı́me uživatele pomocı́ utility nessus-adduser. Spustı́me klientskou část (nessus). Na kartě „Target selection“ zadáme v poli „Target(s)“ masku sı́tě, kterou chceme prosinec 2003 část 9, dı́l 3, kapitola 8, str. 12 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu scannovat. Jelikož IP adresy strojů této sı́tě jsou v rozsahu 172.16.17.1 až v 172.16.17.3 včetně, můžeme zadat masku sı́tě jako 172.16.17.0/29. Pak se ovšem bude scannovat vı́ce IP, než kolik skutečně máme na této sı́ti strojů. Lepšı́ je tudı́ž použı́t druhého způsobu zápisu a zadat tedy rozsah 172.16.17.1-172.16.17.3. Na kartě „Scan options“ přepı́šeme rozsah scannovaných portů na 1-65535. Zvýšı́ se tı́m sice doba scanu, ale na druhou stranu tı́m můžeme odchytit služby poslouchajı́cı́ na vysokých portech. Odškrtneme volbu „Safe checks“, abychom dostávali přesnějšı́ výsledky i za cenu rizika, že může eventuálnı́ děravá služba spadnout. Dole v položkách „Port scanner“ necháme zaškrtlý pouze nástroj nmap. Na kartě „Prefs“ věnujme pozornost volbám pro nmap. Zapneme SYN scan a volbu „Identify the remote OS“, abychom viděli, zda je nmap schopen identifikovat TCP/IP zásobnı́k na daném stroji. Zapnutı́m volby „Fragment IP packets“ též protestujeme, jak si dané firewally poradı́ s fragmentovanými IP pakety (což je jedna z nejstaršı́ch technik obcházenı́ pravidel firewallu). Jelikož na strojı́ch nepoužı́váme žádné anti-DoS nastavenı́ firewallu, které by způsobovalo zahazovánı́ paketů přicházejı́cı́ch ve velkých kvantech z jednoho stroje, nastavı́me „Timing policy“ na hodnotu „Insane“, což výrazně urychlı́ celý scan. Aby mohl Nessus efektivně otestovat IMAP server, nastavı́me v části „Login configurations“ platné uživatelské jméno a heslo pro poštovnı́ účet, na kterém budeme IMAP testovat. Dalšı́ karta je pojmenovaná „Plugins“ a v nı́ odškrtneme některé pluginy, které jsou evidentně zbytečné. Je zcela zbytečné testovat např. na bezpečnostnı́ problémy platformy Netware či CISCO, když se žádný prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 8, str. 13 dı́l 3, Bezpečnost v Linuxu produkt takovýchto společnostı́ v našı́ sı́ti nevyskytuje. Nynı́ můžeme pustit scan. Průměrný scan trvá mnoho minut. Obrázek: Výsledky scanu: O Ve výsledcı́ch scanu se nám objevil pouze stroj 172.16.17.1, u ostatnı́ch strojů nevygeneroval Nessus žádné varovánı́ (což ukazuje, že konfigurace firewallů těchto dvou pracovnı́ch stanic je v pořádku). Podı́vejme se ovšem na stroj 172.16.17.1. Zde u DNS serveru (bind) Nessus vygeneroval hlášenı́ o přı́tomnosti bezpečnostnı́ chyby. Věnujme tedy pozornost oné zprávě (viz obrázek). prosinec 2003 část 9, dı́l 3, kapitola 8, str. 14 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu O Obrázek: Hlášenı́ o bezpečnostnı́ chybě v DNS serveru: Jak je patrno ze zprávy, toto zjištěnı́ provedl Nessus čistě na základě zjištěné verze Bindu. Tudı́ž nemohl zaregistrovat, že na serveru je ve skutečnosti nainstalována verze se záplatou opravujı́cı́ tuto bezpečnostnı́ chybu. Nicméně pozornost bychom měli věnovat službě sunrpc běžı́cı́ na portu 111 (tcp). Jedná se o tzv. mapovač portů pro RPC služby. Přı́kladem RPC služeb je např. NFS. Na onom modelovém serveru ale nenı́ žádná RPC služba nutná, tudı́ž mapovač portů na něm běžı́ zcela zbytečně a z bezpečnostnı́ch důvodů by měl být vypnut. Totéž platı́ i o RPC službě běžı́cı́ na UDP portu 1189. Ve značné části distribucı́ jsou po standardnı́ instalaci zapnuty a spuštěny různé sı́t’ové služby, jako je např. mapovač portů. Jejich ponechánı́ na serveru je jedna z nejčastějšı́ch chyb, kterých se dopouštějı́ začı́najı́cı́ administrátoři. Takovéto zbytečné služby snižujı́ bezpečnost celého systému, protože nenı́ možno vyloučit, prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 8, str. 15 dı́l 3, Bezpečnost v Linuxu že v nich nenı́ nějaká bezpečnostnı́ dı́ra, a tudı́ž potenciálně dávajı́ útočnı́kovi možnost průniku na server. Obecně platı́, že na každém serveru by měly být spuštěny jen ty služby, které skutečně budou využı́vány. Dále se ve varovánı́ch programu Nessus nacházı́ zpráva o tom, že je možné přes něj posı́lat rekurzivnı́ DNS dotazy, což jsou dotazy na doménová jména, které nemůže DNS server sám zodpovědět, a proto je musı́ přeložit za pomoci nadřazených jmenných serverů. Ovšem v našem přı́padě sloužı́ tento stroj jako DNS server pro lokálnı́ sı́t’(ostatnı́ stroje překládajı́ doménová jména pomocı́ něj), tudı́ž je nutné mı́t rekurzivnı́ dotazy povolené. Samozřejmě by měl být přı́stup na DNS server na tomto serveru zakázán z venku pomocı́ firewallu (či nastavenı́ onoho DNS serveru). Na závěr nutno opět poznamenat, že Nessus nenı́ nástrojem neomylným a zejména kontroly prováděné na základě zjištěné verze daného daemonu mohou být velmi nepřesné. Rozhodně nenı́ všelékem na bezpečnost a nenahrazuje administrátorův dohled nad serverem, spousta bezpečnostnı́ch rizik zůstane před jeho zrakem z principu zcela skryta – přı́kladem takových bezpečnostnı́ch rizik mohou být všechny lokálnı́ bezpečnostnı́ chyby. A nad nimi si administrátor v drtivé většině přı́padů nemůže dovolit máchnout rukou. Napřı́klad v minulosti bylo v jádře Linuxu objeveno několik kritických lokálnı́ch bezpečnostnı́ch chyb, které umožňovaly lokálnı́m uživatelům zı́skat účet uživatele root. A navı́c ani to, že na daném stroji nemajı́ žádnı́ dalšı́ uživatelé účet (popř. účet majı́ jen důvěryhodnı́), nenı́ zárukou nezneužitelnosti podobných chyb – útočnı́k může pro zı́skánı́ neprivilegovaného účtu použı́t bezpečnostnı́ch děr v jiných spuštěných daemonech (či třeba skriptech, pokud se jedná o www server). Závěrem prosinec 2003 část 9, dı́l 3, kapitola 8, str. 16 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu Navı́c je nutno si uvědomit, že Nessus a podobné dalšı́ nástroje mohou být použity útočnı́kem proti vám – stejným způsobem, jako vy testujete bezpečnost svého serveru může být „odzkoušena“ bezpečnost kteréhokoliv jiného stroje v sı́ti Internet. Nessus tedy představuje poměrně užitečný penetračnı́ test, který může administrátorovi o něco usnadnit otestovánı́ bezpečnosti serveru. prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 9, str. 1 dı́l 3, Bezpečnost v Linuxu 9/3.9 TRIPWIRE I přes všechny snahy administrátora nenı́ nikdy možné vyloučit, že bude jı́m spravovaný stroj kompromitován. Nemusı́ se přitom jednat ani o selhánı́ administrátora, v dnešnı́ době existujı́ např. tzv. black hat komunity, skupiny lidı́ s velmi vysokou znalostı́ IT bezpečnosti zabývajı́cı́ch se předevšı́m hledánı́m bezpečnostnı́ch děr v existujı́cı́m softwaru a jejich následným využı́vánı́m ve vlastnı́ prospěch (bez uveřejněnı́ zprávy o objevenı́ chyby). Často se spekuluje o tom, zda black hat komunita věděla o právě objeveném bezpečnostnı́m problému již dřı́ve. Tı́m se tato komunita zcela odlišuje od jiných skupin lidı́, kteřı́ jsou médii často označováni jako hackeři – zde se jedná o skutečné experty schopné hledat bezpečnostnı́ chyby a zneužı́vat je. Tripwire Ani velice včasné záplatovánı́ softwaru tedy nezaručuje se 100% jistotou, že stroj nemůže být kompromitován. A v praxi je situace ještě o něco horšı́. Málokterý prosinec 2003 část 9, dı́l 3, kapitola 9, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu administrátor provádı́ záplatovánı́ chvı́li poté, co je objevena bezpečnostnı́ dı́ra. V přı́padě, že se útočnı́kovi povede zneužitı́ nějaké bezpečnostnı́ chyby a zı́ská zároveň i práva uživatele root, co pravděpodobně na stroji udělá? Většina útočnı́ků si na stroj nainstaluje nějaká zadnı́ vrátka, pomocı́ kterých se v budoucnosti mohou na stroj dostat. Mnoho útočnı́ků použı́vá kompromitované stroje jako efektivnı́ anonymizéry použı́vané k provedenı́ dalšı́ch útoků. Možnostı́, jak takováto zadnı́ vrátka (backdoor, rootkit) vytvořit, je mnoho. Jednou z možnostı́ je umı́stěnı́ rootkitu do jádra. To samozřejmě vyžaduje práva uživatele root a ve většině přı́padů i podporu modulů v jádře. Ovšem vypnutı́m podpory dynamických modulů v jádře problém neodstranı́me, kernel může být modifikován i pomocı́ zařı́zenı́ /dev/kmem, který obsahuje mapovanou pamět’jádra. Takový kód v jádře může být velmi nebezpečný, může efektivně maskovat procesy útočnı́ka či soubory jı́m změněné či rovnou sloužit jako backdoor do systému. Dalšı́ možnostı́, která je poměrně často využı́vána, je instalace pozměněných programů, které obsahujı́ přı́slušný backdoor, popř. ještě výměna základnı́ch utilit jako ps či netstat za verze, které maskujı́ útočnı́kem použı́vané procesy a sokety. Kombinace obou technik se nevylučuje, ba naopak. Jak se tedy bránit? To může být obtı́žné. Jednı́m řešenı́m jsou bezpečnostnı́ patche jako LIDS či grsecurity, které výrazně omezujı́ pravomoci spuštěných programů, a tudı́ž přı́padnému úspěšnému útočnı́kovi ztěžujı́ či dokonce zcela znemožňujı́ kompromitovat celý systém. Tyto patche krom jiného daným programům prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 9, str. 3 dı́l 3, Bezpečnost v Linuxu umožňujı́ nastavit specifická přı́stupová práva k souborovému systému, změnit jejich práva (capabilities) atd. Dalšı́m druhem ochrany, který se samozřejmě nevylučuje s prvnı́ možnostı́ (ba naopak, jejich kombinace zajišt’uje velice slušnou dávku bezpečnosti), jsou nástroje na kontrolu integrity souborů. Tyto nástroje nemajı́ nic společného s nástroji na kontrolu integrity souborového systému, jako je např. fsck. Jejich úkolem je udržovat databázi souborů v určených adresářı́ch. Takováto databáze kromě jiného obsahuje velikost souboru, čas poslednı́ho přı́stupu k němu, hashovacı́ hodnotu a dalšı́ podobné údaje. Porovnánı́m hodnot z databáze oproti hodnotám souborů na souborovém systému je možno efektivně zjistit, zda soubor byl či nebyl modifikován. Nicméně tato technika má mnoho nedostatků a jednı́m z nejvýznamnějšı́ch je skutečnost, že pomineme-li možnost mı́t databázi na nějakém médiu jen pro čtenı́ (např. disk cdrom), tak útočnı́kovi nic nebránı́ databázi upravit tak, aby obsahovala hodnoty jı́m změněných souborů. Tudı́ž je nutné nějakým způsobem zajistit integritu databáze. Na částečné řešenı́ tohoto problému se užı́vá asymetrické kryptografie; databáze kontrolnı́ch součtů je digitálně podepsána. K úspěšnému podepsánı́ databáze je nutné heslo, kterým je zašifrován klı́č, který se použı́vá při podepisovánı́ a šifrovánı́ některých souborů. Stejným způsobem jsou ochráněny i dalšı́ soubory – jako např. konfiguračnı́ soubory. Nicméně i tak je doporučováno zálohovat databázi kontrolnı́ch součtů a konfiguračnı́ soubory. Když už nic jiného, tak útočnı́k, který zı́skal práva uživatele root, může databázi smazat a vypnout automatickou kontrolu integrity souborů. . . A možnosti prosinec 2003 část 9, dı́l 3, kapitola 9, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu útočnı́ka jsou mnohem širšı́ – zvláště, pokud má v jádře natažený svůj modul. . . Jednı́m z nástrojů na kontrolu integrity souborů je právě Tripwire od stejnojmenné firmy (vı́ce o licenčnı́ politice Tripwire – viz část Instalace Tripwire). V Tripwire se navı́c na účely ochrany databáze a konfiguračnı́ch souborů nepoužı́vá jeden klı́č, ale dva – sı́t’ový klı́č a lokálnı́ klı́č. Toto řešenı́ je použito z důvodů usnadněnı́ administrátorovy práce – pokud má Tripwire na vı́ce strojı́ch na sı́ti, mohou použı́vat jen jeden sı́t’ový klı́č. Ten se použı́vá např. na ochranu konfiguračnı́ho souboru. Druhý klı́č, lokálnı́, se chránı́ např. lokálnı́ databázı́ kontrolnı́ch součtů. Instalace Tripwire Tripwire existuje ve dvou verzı́ch, open source a komerčnı́. Open source verze je volně ke staženı́ na adrese http://www.tripwire.org. K dispozici jsou balı́čky pro RedHat a tgz balı́k obsahujı́cı́ snadno použitelný instalátor. Eventuálně je zde možnost stáhnutı́ zdrojových kódů a jejich následná kompilace. Nejjednoduššı́m postupem je asi instalace pomocı́ binárnı́ho tgz balı́ku. Ten obsahuje i skript install.sh, který po svém spuštěnı́ nainstaluje Tripwire, vygeneruje klı́če (při instalaci se několikrát zeptá na heslo pro sı́t’ový i lokálnı́ klı́č), konfiguraci i zásady. Konfigurace a bezpečnostnı́ zásady Soubory Tripwire najdeme standardně v adresáři /etc/tripwire. Většina souborů v tomto adresáři je přı́tomna ve dvou formách – nezašifrované textové a zašifrované binárnı́. Tripwire samo o sobě pracuje pouze s oněmi binárnı́mi soubory. Tudı́ž po aktualizovánı́ textových souborů je nutné jej zašifrovat a převést do přı́slušné formy pomocı́ přı́kazu twadmin. prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 9, str. 5 dı́l 3, Bezpečnost v Linuxu Výjimku tvořı́ klı́če. Kromě nich v adresáři najdeme textové soubory (a samozřejmě jejich zašifrované verze) obsahujı́cı́ konfiguraci a bezpečnostnı́ zásady Tripwire. Konfigurace Tripwire je standardně uložena v binárnı́ formě v souboru /etc/tripwire/tw.cfg. Jeho textový obsah můžeme vypsat opět pomocı́ programu twadmin, přı́kazem twadmin --print-cfgfile. V této konfiguraci můžeme nastavit několik věcı́, nicméně podstatná je snad pouze možnost nastavenı́ logovánı́ přes syslogd (volba SYSLOGREPORTING). Vyčerpávajı́cı́ popis konfiguračnı́ch voleb Tripwire naleznete v man 4 twconfig. Mnohem zajı́mavějšı́ jsou bezpečnostnı́ zásady Tripwire. Pomocı́ nich specifikujeme to nejdůležitějšı́ – soubory a adresáře, jejichž integritu chceme kontrolovat. Textovou verzi databáze bezpečnostnı́ch zásad můžeme zı́skat pomocı́ přı́kazu twadmin --print-polfile. Základnı́ syntaxe bezpečnostnı́ch zásad v tomto textovém souboru je následujı́cı́: objekt -> příznaky; Přitom objekt může být adresářem i souborem. Přı́znaky mohou být složeny ze skupiny znaků: prosinec 2003 část 9, dı́l 3, kapitola 9, str. 6 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu T Tabulka znaků přı́znaků: + bude kontrolovat změnu daných vlastnostı́ objektu - nebude kontrolovat změnu daných vlastnostı́ objektu a čas poslednı́ho přı́stupu b počet alokovaných bloků d ID zařı́zenı́ g GID objektu i čı́slo inodu l souboru se zvětšila délka m čas modifikace n počet referencı́ na inodu p práva s velikost t typ souboru u UID objektu C CRC32 kontrolnı́ součet H Hash hodnota alg. Haval M MD5 hash. hodnota S SHA hash. hodnota Kromě manuálnı́ho zadávánı́ všech přı́znaků ke všem objektům můžeme též využı́t možnostı́ substituce – syntaxe je $(jméno proměnné). Konstrukce je substituována na hodnotu oné zadané proměnné. Hodnotu proměnných můžeme nastavit pomocı́ zápisu identifikátor=hodnota;. Napřı́klad pokud prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 9, str. 7 dı́l 3, Bezpečnost v Linuxu budeme chtı́t u několika souborů mı́t nastavené přı́znaky kontroly na změnu souboru, můžeme si ulehčit jejich zápis pomocı́ proměnné: P_MOD=+pmin; /usr/sbin/sshd -> $(P_MOD); /usr/sbin/ipop3d -> $(P_MOD); K jednotlivým zásadám můžeme přiřadit i různé atributy. Můžeme je specifikovat dvěma způsoby – bud’ ve stylu objekt -> příznaky (atribut=hodnota); nebo (atribut=hodnota) { objekt -> příznaky; } Pokud pomocı́ druhého zápisu napı́šeme mezi složené závorky vı́ce zásad, bude mı́t každá zásada nastaveny specifikované atributy. A co za atributy můžeme u zásad nastavit? rulename – pomocı́ atributu rulename můžeme přiřadit zásadám nějaký identifikátor, který se posléze objevı́ i v reportu. Tyto identifikátory je vhodné použı́vat zejména v přı́padě, že máme nadefinováno velké množstvı́ zásad. Můžeme taktéž zásady logicky organizovat podle balı́ků či skupin programů a podle toho jim přiřazovat identifikátory (např. identifikátor OpenSSH pro zásady kontrolujı́cı́ změnu u programů /usr/sbin/sshd, /usr/bin/ssh atd.) emailto – tento atribut sloužı́ k specifikaci emailové adresy, na kterou je poslán report, v přı́padě použitı́ volby --email-report při kontrole a zjištěné změny některého z hlı́daných údajů. severity – atributem severity můžeme zásadám nastavit určitou úroveň důležitosti. Hodnotou atributu prosinec 2003 část 9, dı́l 3, kapitola 9, str. 8 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu může být čı́slo od 0 do 1 000 000. Při kontrole pak můžeme provádět filtraci na základě úrovnı́ nastavených jednotlivým zásadám (tudı́ž je možné např. specifikovat, že se majı́ kontrolovat jen zásady s úrovnı́ 50 a vyššı́). recurse – tı́mto atributem můžeme ovlivnit chovánı́ Tripwire v přı́padě, že je jako objekt zadán adresář. Určuje se jı́m maximálnı́ úroveň zanořenı́, v které bude Tripwire sledovat integritu objektů. Může nabývat hodnot od −1 do 1 000 000. −1 znamená neomezenou rekurzi, kdežto úroveň 0 určuje, že se podadresáře a soubory v daném adresáři nemajı́ kontrolovat. Standardnı́ hodnotou je −1, tedy monitorovánı́ všech podadresářů a souborů v nich. Aby Tripwire mohlo použı́vat námi nakonfigurované zásady, je nutné převést textový konfiguračnı́ soubor zpět do binárnı́ formy a podepsat ho. Pokud již máme vytvořenou databázi kontrolnı́ch součtů, použijeme na konverzi přı́kazu tripwire -m p textový_soubor Pokud ne, tak užijeme přı́kazu twadmin --create-polfile textový_soubor Inicializace databáze kontrolnı́ch součtů prosinec 2003 Pro ovládánı́ Tripwire se použı́vá předevšı́m přı́kaz tripwire. K inicializaci oné databáze použijeme přı́kaz tripwire -m i. Tripwire poté projde soubory a adresáře specifikované v zásadách a spočı́tá jejich kontrolnı́ součet/hashovacı́ hodnotu, kterou následně uložı́ do databáze spolu s dalšı́mi údaji o souboru. Po instalaci Tripwire bychom měli zazálohovat oba klı́če, databázi kontrolnı́ch součtů, konfiguraci a databázi bezpečnostnı́ch zásad na nějaké médium určené jen pro čtenı́ (cdrom). V přı́padě kompromitace stroje BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 9, str. 9 dı́l 3, Bezpečnost v Linuxu i Tripwire pak můžeme provést kontrolu změněných souborů. Po vytvořenı́ databáze kontrolnı́ch součtů bychom měli čas od času spustit kontrolu integrity souborů. Při něm Tripwire zkontroluje podle databáze bezpečnostnı́ch zásad všechny sledované soubory a některé údaje u nich. V přı́padě změny vypı́še varovánı́, které může zároveň automaticky poslat emailem. Pro kontrolu integrity souborů nám sloužı́ přı́kaz tripwire -m c. Eventuálně mu můžeme přidat několik parametrů, např. --email-report pro poslánı́ výsledků emailem, -l úroveň pro kontrolu zásad s úrovnı́ důležitosti většı́ nebo rovnu specifikovanému čı́slu. Vyčerpávajı́cı́ popis parametrů opět naleznete v man 8 tripwire. Kontrola integrity souborů Tento přı́kaz též můžeme umı́stit do cronu, aby se spouštěl v daném časovém intervalu a v přı́padě porušenı́ integrity poslal administrátorovi email. Nicméně podobné mechanismy vás ochranı́ maximálně tak před útočnı́kem, jehož vrchol schopnostı́ představovala kompilace exploitu a staženı́ backdoorovaného sshd. . . I když pustı́me kontrolu integrity manuálně, tak si nemůžeme být jisti, že skutečně žádný soubor modifikován nebyl. Útočnı́k mohl např. vyměnit klı́če, databázi a dalšı́ konfiguračnı́ soubory. . . To bychom samozřejmě poznali v přı́padě, že bychom se pokusili o operaci, která vyžaduje dešifrovánı́ klı́čů a jejich následné použitı́ na podpis nějakého souboru (heslo ke klı́čům by samozřejmě bylo jiné). Ale tı́m možnosti útočnı́ka zdaleka nekončı́, může např. vyměnit binárnı́ soubory Tripwire a nahradit je svými, které budou potichu ignorovat změnu v souborech, které útočnı́k vyměnil. Dalšı́ možnostı́ útočnı́ka je např. umı́stit na prosinec 2003 část 9, dı́l 3, kapitola 9, str. 10 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu stroj modul jádra, který v přı́padě, že se Tripwire pokusı́ o přı́stup k změněným souborům, vrátı́ hodnoty a obsah originálnı́ch souborů (skrytých někde na pevném disku). Tato technika boje proti Tripwire je z těch uvedených asi nejzákeřnějšı́, protože na rozdı́l od předešlých technik proti nı́ nenı́ obrana vůbec jednoduchá – nepomůže ani zakázánı́ podpory modulů v jádru. Jediným řešenı́m jsou bezpečnostnı́ záplaty jako grsecurity a následné zakázánı́ přı́stupu k souborům /dev/kmem, /dev/mem a práva CAP SYS MODULE, které je nutné pro nataženı́ modulu do jádra. Nutno ale řı́ci, že použitı́ podobné techniky je již poměrně značně složité a rozhodně vyžaduje poměrně značné znalosti od útočnı́ka. A pokud se obáváme podobných útoků, tak by použitı́ záplat, jako je grsecurity, mělo být samozřejmostı́. Právě z důvodu, že lokálnı́ databáze rozhodně nenı́ v absolutnı́m bezpečı́, je velmi vhodné zazálohovat si konfiguračnı́ soubory Tripwire, klı́če a databázi kontrolnı́ch součtů v době jejı́ho vytvořenı́. Pak, pokud dojde ke kompromitaci stroje, můžeme vzı́t jeho pevný disk, umı́stit ho do nějakého jiného počı́tače (to je nutné z důvodu eliminace vlivu přı́padného modulu jádra, který mohl útočnı́k na stroji umı́stit) a provést kontrolu integrity souborů. Musı́me ale počı́tat s tı́m, že pokud ona původnı́ databáze bude staršı́ho data, tak Tripwire bude hlásit i změny, které jsme provedli sami (záplatovánı́). Aktualizace databáze kontrolnı́ch součtů prosinec 2003 Ke změnám hlı́daných souborů může též dojı́t oprávněně – přı́kladem budiž záplatovánı́ či instalace nového softwaru. V takovém přı́padě je nutné aktualizovat databázi, aby se v dalšı́ch reportech již neobjevovalo BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 9, str. 11 dı́l 3, Bezpečnost v Linuxu varovánı́. Databázi můžeme aktualizovat pomocı́ přı́kazu tripwire -m u -r report. Jako report specifikujeme jméno souboru s reportem, který vygeneroval Tripwire při kontrole integrity souborů. Jméno souboru je při kontrole vždy vypsáno na jejı́m začátku. Tripwire představuje velmi dobrý nástroj na kontrolu integrity souborů. Při přı́padném průniku může administrátorovi velmi ulehčit obnovu systému a napovědět mu, co onen útočnı́k na stroji provedl. Nenı́ však samozřejmě nástrojem všemocným, schopný útočnı́k jej pochopitelně dokáže vyřadit. Závěrem prosinec 2003 část 9, dı́l 3, kapitola 9, str. 12 dı́l 3, Bezpečnost v Linuxu prosinec 2003 BEZPEČNÁ POČÍTAČOVÁ SÍŤ BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 10, str. 1 dı́l 3, Bezpečnost v Linuxu 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 únor 2005 část 9, dı́l 3, kapitola 10, str. 2 dı́l 3, Bezpečnost v Linuxu únor 2005 BEZPEČNÁ POČÍTAČOVÁ SÍŤ BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 10.1, str. 1 dı́l 3, Bezpečnost v Linuxu 9/3.10.1 ÚVOD Omezovánı́ sı́t’ového provozu je problematika, která se na každém operačnı́m systému či v každé aplikaci, chovajı́cı́ se jako aplikačnı́ proxy server, dá řešit mnoha způsoby. Všechny však majı́ jednu společnou věc. Množstvı́ dat, která k nám přicházejı́ z cizı́ch zdrojů, nemůžeme nijak ovlivnit. Napřı́klad pokud máme od poskytovatele přidělenou linku o nějaké kapacitě a rádi bychom ji rozdělili dále či omezili některé uživatele, tak samozřejmě nějakými způsoby můžeme. Pokud se však nějaký hacker nebo vir v Internetu rozhodne našı́ linku zahltit, tak se mu to podařı́, protože my nemůžeme ovlivnit data, která k nám prostě pošle. Můžeme přı́mo ovlivnit pouze ta data, která přeposı́láme dále nebo která chceme do Internetu odesı́lat. A aby toho nebylo málo, tak je nutno poznamenat, že efektivně se dá omezovat pouze protokol TCP. Na efektivnı́m omezovánı́ protokolu UDP či ICMP můžeme s klidným svědomı́m zapomenout. únor 2005 část 9, dı́l 3, kapitola 10.1, str. 2 dı́l 3, Bezpečnost v Linuxu únor 2005 BEZPEČNÁ POČÍTAČOVÁ SÍŤ BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 10.2, str. 1 dı́l 3, Bezpečnost v Linuxu 9/3.10.2 OMEZOVÁNÍ PROVOZU NA ÚROVNI PROTOKOLU TCP/IP Na úvod zopakuji, že nejsme naprosto vůbec schopni ovlivnit množstvı́ dat, která k nám dorazı́ z Internetu. To je pravidlo, na které je nutno neustále pamatovat. Naštěstı́ je protokol TCP, který použı́vá většina aplikacı́, navržen s následujı́cı́ vlastnostı́. Klient požádá server o nějaká data. Server začne tato data posı́lat co možná nejrychlejšı́m způsobem. Když klient dostává jednotlivé pakety, posı́lá potvrzenı́ o jejich přijetı́. Dává tı́m serveru na vědomı́, že je připraven přijı́mat dalšı́ data. Pokud pakety s potvrzenı́m přicházejı́ k serveru pomaleji, tak si server „začne myslet“, že se s pakety na cestě něco děje, a sám začne klientovi posı́lat data v menšı́m množstvı́. Dá tak klientovi (nebo také routerům na cestě) šanci zpracovat celý provoz bez nutnosti posı́lat většinu paketů znovu. únor 2005 část 9, dı́l 3, kapitola 10.2, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu Této vlastnosti využijeme při našem omezovánı́ protokolu TCP. Donutı́me servery v Internetu k pomalejšı́mu odesı́lánı́ dat. Je zřejmé, že je vhodné nejen regulovat pakety, které směřujı́ z Internetu ke klientům, ale také data od klientů do Internetu. Technika omezovánı́ Rád bych uvedl, že začnu celou techniku popisovat značně zjednodušeně a teprve na konci uvedu možné výjimky či nepravdy, jichž se v průběhu dopustı́m. Je to proto, abych nemátl přı́padné začátečnı́ky. Z výše uvedeného popisu jasně plyne, že jsme schopni přı́mo ovlivnit pouze provoz, který odcházı́ z počı́tače. Technika, která se k tomu použı́vá, se dá popsat následovně. Poté, co paket projde filtrovacı́m a routovacı́m procesem na routeru, je rozhodnuto, kterým sı́t’ovým rozhranı́m bude z routeru odcházet. Před toto sı́t’ové rozhranı́ pak zjednodušeně postavı́me trpaslı́ka, který bude podle nějakých pravidel řı́kat, který paket do sı́tě propustı́, který pozdržı́ či který zahodı́ (a pak je na aplikaci/protokolu, jak se s takovou ztrátou paketu vyrovná). Onen trpaslı́k je někdo, kdo bdı́ nad jakýmsi strukturovaným skladem. Jednotlivé skladovacı́ mı́stnosti majı́ přidělenu kapacitu. Tuto aktuálnı́ kapacitu může náš trpaslı́k přepočı́távat, pokud to dovoluje konfigurace toho strukturovaného skladu. Jednotlivé pakety se umist’ujı́ do jednotlivých skladovacı́ch mı́stnostı́ a trpaslı́k podle konkrétnı́ho algoritmu pro každou jednotlivou mı́stnost rozhoduje, jestli bude paket z mı́stnosti odeslán do sı́t’ového rozhranı́, nebo zda bude zahozen do propadliště dějin. únor 2005 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 10.2, str. 3 dı́l 3, Bezpečnost v Linuxu Zmı́něný algoritmus může být napřı́klad typu FIFO (first in, first out), podle kterého se z mı́stnosti vezme a odešle do sı́t’ového rozhranı́ ten paket, který je v mı́stnosti nejstaršı́. Zmı́něná skladovacı́ mı́stnost má pevnou velikost (napřı́klad 20 paketů). Pokud je plná a všechny pakety v nı́ čekajı́ na odeslánı́, tak se pakety, které do nı́ majı́ spadnout, prostě zahodı́ a ztratı́ v onom propadlišti dějin. Aplikace, která vytvořila takovýto paket, nenı́ o tomto zahozenı́ nijak informována a je jen na nı́, aby zpozorovala, že se jı́ pakety po cestě ztrácejı́. Popis ve výše uvedených dvou odstavcı́ch je možná na prvnı́ pohled zmatený, nicméně při dalšı́m čtenı́ a zhlédnutı́ několika obrázků bude vše jasnějšı́. Nynı́ však již dost teorie a pojd’me se podı́vat na nějaký konkrétnı́ přı́klad. Máme většı́ firmu, přistupujı́cı́ do Internetu přes jedinou veřejnou adresu, kterou jsme dostali od poskytovatele připojenı́. V budově, kde sı́dlı́ naše firma, však sı́dlı́ ještě jiná firma, která je připojena do našı́ vnitřnı́ sı́t’ě a která také přes naši veřejnou adresu přistupuje do Internetu. Řekněme, že naše firma použı́vá sı́t’ 192.168.0.0 s maskou 255.255.255.0 a ona druhá firma použı́vá 192.168.1.0 s maskou 255.255.255.0. Rychlost našı́ linky je 512/768 kbps (download/upload). Rádi bychom přidělené pásmo rozdělili tak, že naše firma bude použı́vat 300/500 kbps kapacity linky a sousednı́ firma 212/268 kbps kapacity. V patřičném poměru se takto dělı́ i o cenu fakturovanou poskytovatelem. Dále bychom chtěli, aby měl počı́tač 192.168.0.30, který je v našı́ vnitřnı́ sı́ti, alespoň garantovanou rychlost 128 kbps. Je to totiž počı́tač našeho ředitele, který má připojenou IP telefonii a občas telefonuje přes Internet Zadánı́ únor 2005 část 9, dı́l 3, kapitola 10.2, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu a je nutné mu garantovat tuto rychlost. A dále si přejeme, aby vzájemný provoz mezi našı́ firmou a sousednı́ firmou nebyl nijak omezován. Nakonec jen dodám, že veřejná adresa našeho routeru je 123.45.67.8 a je na sı́t’ovém rozhranı́ eth0, adresa do našı́ vnitřnı́ sı́tě je 192.168.0.1 (eth1), adresa do vnitřnı́ sı́tě sousednı́ firmy je 192.168.1.1 (eth2). Náš router tak má tři sı́t’ové karty. Možná vás napadne, že bychom rádi dosáhli, aby při malém provozu jedné firmy mohla druhá využı́vat část kapacity prvnı́ a naopak. Tento požadavek prozatı́m nevznášejme, dostaneme se k němu později a samozřejmě jej splnı́me. V kapitole 9/3.6.3 jsme pomocı́ firewallu a tabulky mangle dosáhli označkovánı́ přı́slušných paketů. Zopakuji zde znovu pro přehlednost tabulku, ze které je zřejmé, jak je který provoz paketů označkován. únor 2005 část 9, dı́l 3, kapitola 10.2, str. 5 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu T Tabulka značek pro veškerý provoz adresa zdrojová cı́lová značka 192.168.0.0/24 192.168.0.1 nenı́ 192.168.0.0/24 Internet 20 192.168.0.30 Internet 22 192.168.0.0/24 192.168.1.0/24 40 192.168.1.0/24 192.168.1.1 nenı́ 192.168.1.0/24 192.168.0.0/24 40 192.168.1.0/24 Internet 30 123.45.67.8 Internet 50 192.168.0.1 192.168.0.0/24 40 192.168.1.1 192.168.1.0/24 40 Internet 192.168.0.0/24 21 Internet 192.168.0.30 24 Internet 192.168.1.0/24 31 Internet 123.45.67.8 nenı́ Samotný skript: 1: tc qdisc del dev eth0 root 2: tc qdisc add dev eth0 root handle 1:0 htb default 10 3: tc class add dev eth0 parent 1:0 classid 1:1 4: tc class add dev eth0 parent 1:1 classid 1:2 htb rate 768kbit htb rate 500kbit ceil 500kbit 5: tc class add dev eth0 parent 1:2 classid 1:10 htb rate 372kbit ceil 500kbit 6: tc class add dev eth0 parent 1:2 classid 1:11 htb rate 128kbit ceil 500kbit 7: tc class add dev eth0 parent 1:1 classid 1:3 htb rate 268kbit ceil 268kbit 8: únor 2005 část 9, dı́l 3, kapitola 10.2, str. 6 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu 9: tc filter add dev eth0 parent 1:2 protocol ip handle 20 fw flowid 1:10 10: tc filter add dev eth0 parent 1:2 protocol ip handle 22 fw flowid 1:11 11: tc filter add dev eth0 parent 1:1 protocol ip handle 21 fw flowid 1:3 12: 13: tc qdisc del dev eth1 root 14: tc qdisc add dev eth1 root handle 1:0 htb default 10 15: tc class add dev eth1 parent 1:0 classid 1:1 16: tc class add dev eth1 parent 1:1 classid 1:2 htb rate 102400kbit htb rate 300kbit ceil 300kbit 17: tc class add dev eth1 parent 1:2 classid 1:10 htb rate 172kbit ceil 300kbit 18: tc class add dev eth1 parent 1:2 classid 1:11 htb rate 128kbit ceil 300kbit 19: tc class add dev eth1 parent 1:1 classid 1:3 htb rate 102100kbit ceil 102400kbit 20: 21: tc filter add dev eth1 parent 1:1 protocol ip handle 40 fw flowid 1:10 22: tc filter add dev eth1 parent 1:1 protocol ip handle 21 fw flowid 1:11 23: tc filter add dev eth1 parent 1:1 protocol ip handle 24 fw flowid 1:3 24: 25: tc qdisc del dev eth2 root 26: tc qdisc add dev eth2 root handle 1:0 htb default 10 27: tc class add dev eth2 parent 1:0 classid 1:1 htb rate 102400kbit 28: tc class add dev eth2 parent 1:1 classid 1:10 htb rate 102188kbit ceil 102400kbit 29: tc class add dev eth2 parent 1:1 classid 1:11 htb rate 212kbit ceil 212kbit 30: 31: tc filter add dev eth2 parent 1:1 protocol ip handle 40 fw flowid 1:10 32: tc filter add dev eth2 parent 1:1 protocol ip handle 31 fw flowid 1:11 únor 2005 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 10.2, str. 7 dı́l 3, Bezpečnost v Linuxu Na obrázku k zařı́zenı́ eth0 vidı́me strukturu, kterou jsme vytvořili přı́kazy na řádcı́ch 1 až 7. Struktura pro odchozı́ provoz na zařı́zenı́ eth0 Provoz do Internetu O Na řádku 1 smažeme přı́padně dřı́ve vytvořené struktury. Na řádku 2 vytvořı́me kořenovou disciplı́nu (qdisc) 1:0 na zařı́zenı́ eth0 a budeme na nı́ použı́vat algoritmus htb. Na tuto kořenovou disciplı́nu pověsı́me třı́du (class) 1:1 a řekneme, že jejı́ kapacita je 768 kilobitů za sekundu. To je konec konců kapacita pro upload, kterou nám přidělil náš poskytovatel Intenetu. Na řádku 4 a 7 na třı́du 1:1 pověsı́me dvě dalšı́ třı́dy, a to 1:2 s kapacitou 500 kbps a 1:3 s kapacitou 268 kbps. Tyto dvě třı́dy reprezentujı́ pásma, které rozdělujeme mezi naši firmu (třı́da 1:2) a sousednı́ firmu (1:3). Parametr ceil si vysvětlı́me na konci. Protože však v našı́ firmě chceme garantovat odchozı́ provoz na rychlosti 128 kbps pro počı́tač pana ředitele, rozčlenı́me třı́du 1:2 na dalšı́ dvě potřı́dy. To provedeme na řádcı́ch 5 a 6. Na řádku 6 vytvořı́me třı́du pro počı́tač pana ředitele a řekneme, že jejı́ kapacita únor 2005 část 9, dı́l 3, kapitola 10.2, str. 8 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu je 128 kbps. Na řádku 5 jsme pak vytvořili třı́du, jejı́ž kapacita je 372 kbps (tedy 500 minus 128). Parametr rate řı́ká, jaká má být garantovaná rychlost třı́dy, a parametr ceil řı́ká, jaká může být maximálnı́ rychlost třı́dy. Na řádku 7 tedy stanovujeme, že pokud má třı́da 1:2 (tedy třı́da pro naši firmu) volnou kapacitu, může počı́tač pana ředitele odesı́lat data rychlostı́ až 500 kbps, tedy většı́ rychlostı́ než 128 kbps. Podobně na řádku 6 řı́káme, že pokud počı́tač pana ředitele nevytěžuje linku rychlostı́ 128 kbps, mohou ostatnı́ počı́tače v našı́ firmě přistupovat na Internet většı́ rychlostı́ než 372 kbps. Nadefinovali jsme tedy, že počı́tač pana ředitele a ostatnı́ počı́tače v našı́ firmě sdı́lejı́ pásmo 500 kbps, přičemž v přı́padě potřeby má ředitelův počı́tač zajištěnu rychlost 128 kbps. Pokud se hodnoty parametrů rate a ceil rovnajı́, pak si daná třı́da nemůže od svého rodiče žádné pásmo vypůjčit. Na řádcı́ch 4 a 5 jsme to řekli o pásmu pro naši a sousednı́ firmu. Na řádcı́ch 9 až 11 pak řı́káme, do které skladovacı́ mı́stnosti pak půjde ten který paket. Všechny odchozı́ pakety jsme sami označkovali v pravidlech firewallu v kapitole 9/3.6.3. Přı́kaz tc filter add dev eth0 parent 1:2 protocol ip handle 20 fw flowid 1:10 na řádku 9 řı́ká, že pakety se značkou 20 odcházejı́cı́ zařı́zenı́m eth0 půjdou do třı́dy 1:10. Na řádku 10 pak do třı́dy 1:11 hážeme všechny pakety, které odcházejı́ zařı́zenı́m eth0 a majı́ značku 22, a do třı́dy 1:3 pak hodı́me všechny pakety, které majı́ značku 21 a opět odcházejı́ zařı́zenı́m eth0. Provoz do Internetu, který bude generovat náš počı́tač, máme označkovaný značkou 50, a protože jsme pro tuto značku nenadefinovali žádné pravidlo, které by únor 2005 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 10.2, str. 9 dı́l 3, Bezpečnost v Linuxu řı́kalo, do které třı́dy patřı́, zpracujeme jej v defaultnı́ třı́dě 1:10, jak se dozvı́me na konci přı́kladu. Podı́vejme se nynı́ na strukturu na zařı́zenı́ eth1, tedy sı́t’ové zařı́zenı́ do vnitřnı́ sı́tě našı́ firmy, kterou jsme vytvořili na řádcı́ch 13 až 22. Struktura pro odchozı́ provoz na zařı́zenı́ eth1 Provoz do vnitřnı́ sı́tě našı́ firmy O Na řádku 14 opět nejprve vytvořı́me kořenovou disciplı́nu 1:0, na kterou pověsı́me (řádek 15) kořenovou třı́du 1:1. Na tuto třı́du pověsı́me dvě podtřı́dy. Třı́da 1:2 (řádek 16) bude sloužit pro provoz z Internetu do našı́ vnitřnı́ sı́tě a třı́da 1:3 (řádek 19) bude sloužit pro provoz z vnitřnı́ sı́tě sousednı́ firmy do našı́ vnitřnı́ sı́tě. Bude mı́t kapacitu téměř 100 Mbps, což je rychlost našı́ sı́t’ové karty. Třı́du 1:2 jsme dále rozdělili na podtřı́du 1:10, kam bude směřovat provoz z Internetu do počı́tačů v našı́ vnitřnı́ sı́ti kromě počı́tače pana ředitele. Pro provoz z Internetu na počı́tač pana ředitele pak vytvořı́me třı́du 1:11 (řádek 18). únor 2005 část 9, dı́l 3, kapitola 10.2, str. 10 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu Rychlost třı́dy 1:11 jsme stanovili na 128 kbps s tı́m, že pokud nenı́ využı́váno pásmo třı́dy 1:10, tak jej využijeme a můžeme dosáhnout rychlosti až 300 kbps. Na řádku 21 pak řı́káme, že pakety označené značkou 40 (tedy provoz mezi sousednı́ firmou a našı́ firmou) půjdou do třı́dy 1:3 na zařı́zenı́ eth1. Na řádku 22 pak zařadı́me do třı́dy 1:10 ten provoz, který je z Internetu určen počı́tačům ve vnitřnı́ sı́t’i (kromě počı́tače pana ředitele) a do třı́dy 1:11 pak zařadı́me ten provoz, který je z Internetu určen na počı́tač pana ředitele. Je nutno v našem přı́padě poznamenat, že třı́da 1:2 si nikdy nesmı́ půjčit pásmo od třı́dy 1:1, protože bychom tı́m de facto přestali omezovat provoz z Internetu. Na to je nutno vždy pamatovat. Pokud bychom nechtěli sdı́let pásmo pro provoz z Internetu mezi počı́tačm pana ředitele a ostatnı́mi počı́tači v našı́ vnitřnı́ sı́ti, pak by strukutra na zařı́zenı́ eth1 mohla vypadat následovně: O Provoz z Internetu do sousednı́ firmy únor 2005 Možná struktura pro odchozı́ provoz na zařı́zenı́ eth1 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 10.2, str. 11 dı́l 3, Bezpečnost v Linuxu Struktura na sı́t’ovém zařı́zenı́ eth2 (a tedy pokrývajı́cı́ provoz do sı́tě sousednı́ firmy) vypadá již velmi jednoduše. Na řádcı́ch 25, 26 a 27 provedeme obvyklé úkony. Dále definujeme dvě podtřı́dy pro třı́du 1:1. Třı́da 1:10 (řádek 28) bude sloužit pro provoz z našı́ firmy do sousednı́ firmy a třı́da 1:11 (řádek 29) pak bude sloužit pro provoz z Internetu do sousednı́ firmy. Opět je nutno řı́ci, že třı́da 1:11 musı́ mı́t pevnou rychlost a nepůjčuje si od rodičovské třı́dy 1:1 (tj. hodnota parametru ceil se rovná hodnotě parametru rate). Zbývá vysvětlit, co znamenajı́ řádky 2, 14 a 26. Na nich se definuje třı́da pro ty pakety, které ve výsledku nespadnou do žádné třı́dy. My jsme však označkovali ve firewallu veškerý odchozı́ provoz z routeru, a tak jsou tyto definice defaultnı́ch třı́d zbytečné. Štábnı́ kultura však řı́ká, že je vhodné a slušné je definovat. Výše uvedené řešenı́ ma jeden zásadnı́ problém. Linuxové jádro nám v tomto konkrénı́m přı́padě začne v reálném provozu protestovat proti přı́liš rozdı́lným hodnotám třı́d. A má skutečně pravdu, protože vhodně rozdělovat provoz mezi cca 100 Mbit třı́dou (1:3 na eth1, 1:10 na eth2) a ostatnı́mi kapacitně výrazně menšı́mi třı́dami na přı́slušném rozhranı́ je co do výpočetnı́ho výkonu a rozhodovánı́, které pakety zahodit a které ještě ne, náročné. Problémy Řešenı́ je dvojı́. Zaprvé můžeme nedefinovat třı́dy default (na zařı́zenı́ch eth1 a eth2) a vůbec tyto kapacitně velké třı́dy. Tı́m, že nebudeme mı́t třı́du default a nebudeme pomocı́ přı́kazů tc filter... vůbec umı́st’ovat pakety mezi našı́ vnitřnı́ sı́tı́ a sı́tı́ sousednı́ firmy do třı́d, tak tyto pakety spadnou jaksi mimo a po filtrovacı́m a routovacı́m procesu půjdou rovnou únor 2005 část 9, dı́l 3, kapitola 10.2, str. 12 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu do sı́t’ového zařı́zenı́ bez jakéhokoliv omezenı́. Následujı́cı́ druhý způsob je čistšı́. Snı́žı́me hodnoty pro tyto objemné třı́dy na takovou úroveň, proti které linuxové jádro neprotestuje. Provoz mezi vnitřnı́mi sı́těmi pak nebude probı́hat na rychlosti 100 Mbps, ale napřı́klad 10 Mbps nebo 2 Mbps, podle toho, jakou hodnotu linuxové jádro zvládne. Pomalejšı́ provoz mezi vnitřnı́mi sı́těmi je danı́ za čistotu konfigurace. Sami si vyberte, co je vám bližšı́. Pokud vyberete prvnı́ způsob, doporučuji, abyste tento svuj úmysl nedefinovat default třı́dy zapsali v komentáři do skriptu, odkud budete omezovánı́ spouštět. Dalšı́m problémem je to, že omezujeme všechny protokoly. Jak TCP, u kterého to má smysl, tak např. UDP či ICMP, u kterých to žádný smysl nemá. Co s tı́m, uvidı́me dále. únor 2005 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 10.2, str. 13 dı́l 3, Bezpečnost v Linuxu Z předchozı́ho výkladu a z popisu přı́kazu tc plyne, že omezovat pásmo lze pouze na konkrétnı́m fyzickém zařı́zenı́. V našem předchozı́m přı́kladu hypotetické firmy však má náš server samostatnou sı́t’ovou kartu pro vnitřnı́ sı́t’našı́ firmy a samostatnou sı́t’ovou kartu pro vnitřnı́ sı́t’sousednı́ firmy. Sdı́lenı́ volného pásma Často se asi bude stávat, že celkový provoz obou firem nebude většı́ než kapacita linky. Pokud jsme ale pevně rozdělili tuto kapacitu v nějakém poměru mezi dvě sı́tě a provoz v jedné z nich dosáhne přidělené kapacity, linka nebude využita. Nabı́zı́ se proto řešenı́, kdy „zapůjčı́me“ část volné kapacity, kterou nevyužı́vá druhá sı́t’. Problémem však je, jak jsem před chvı́lı́ zmı́nil, nemožnost půjčit si kapacitu mezi dvěma fyzickými sı́t’ovými zařı́zenı́mi. Neklesejme na mysli, v linuxovém světě se neptáme, zdali něco lze udělat, ale ptáme se, jak se to má udělat. Odpověd’ je dvojı́. Bud’ si přı́slušný program napsat sám a nebo hledat na Internetu, zdali to již někdo neudělal za nás. Druhá varianta je obvykle pravděpodobnějšı́. IMQ je falešné sı́t’ové zařı́zenı́ a nelze s nı́m provádět nic jiného, než na něj pověsit nějakou sı́t’ovou disciplı́nu qdisc. Dřı́ve jsem se zmiňoval pouze o disciplı́nách. Ted’ jen pro pořádek zmı́nı́m, že existujı́ dva druhy: přı́chozı́ (ingress) a odchozı́ (egress). Jaký je mezi nimi rozdı́l, je v tuto chvı́li nedůležité. Zmiňuji se o tom proto, že na IMQ zařı́zenı́ lze pověsit pouze odchozı́ (egress) disciplı́nu. Přı́chozı́ (ingress) disciplı́nu na něj pověsit z důvodu vlastnostı́ linuxového firewallu Netfilter nemůžeme, nicméně přı́chozı́ provoz lze omezovat na IMQ pomocı́ odchozı́ disciplı́ny. IMQ listopad 2005 část 9, dı́l 3, kapitola 10.2, str. 14 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu O tom, jak zařı́zenı́ IMQ nainstalovat, se zmı́nı́m na konci. Změna zadánı́ V původnı́m zadánı́ ze začátku kapitoly 9.3.10.1 jsme řekli, že naše firma bude mı́t přidělenou přı́chozı́ kapacitu 268 kbps a sousednı́ firma pak 500kbps. Odchozı́ kapacitu 512 kbps jsme rozdělili tak, že naše firma dostala 212 kbps a sousednı́ firma 300 kbps. Doplňme naše zadánı́ tak, že v přı́padě, kdy jedna z firem dosáhne svého limitu, zapůjčı́ si volné pásmo od firmy druhé. Samozřejmě za takových podmı́nek, kdy se takto zapůjčené volné pásmo bude automaticky průběžně měnit tak, jak bude kolı́sat provoz druhé firmy. Té totiž musı́me garantovat rychlost 268 kbps. Neboli sdı́lı́me kapacitu linky mezi firmami s tı́m, že garantujeme nějaké minimálnı́ meze. Pro odchozı́ provoz je úprava původnı́ho skriptu velmi jednoduchá. Původnı́ řádky 3 až 7 3: tc class add dev eth0 parent 1:0 classid 1:1 htb htb 5: tc class add dev eth0 parent 1:2 classid 1:10 htb 6: tc class add dev eth0 parent 1:2 classid 1:11 htb 7: tc class add dev eth0 parent 1:1 classid 1:3 htb 4: tc class add dev eth0 parent 1:1 classid 1:2 rate rate rate rate rate 768kbit 500kbit 372kbit 128kbit 268kbit ceil ceil ceil ceil 500kbit 500kbit 500kbit 268kbit řı́kajı́, že třı́da 1:3 (naše firma) má garantovanou rychlost 268 kbps a tato rychlost je neměnná, protože parametr ceil má stejnou hodnotu jako parametr rate a nemůže si tak od nadřazené třı́dy 1:1 nic zapůjčit. Ani třı́da 1:2 (sousednı́ firma) si nemůže od nadřazené třı́dy zapůjčit pásmo. Avšak třı́dy 1:11 (počı́tač ředitele sousednı́ firmy) a 1:10 (ostatnı́ počı́tače sousednı́ firmy) majı́ sice garantovanou pevnou rychlost, avšak mohou si od nadřazené třı́dy půjčit tolik, že jejich rychlost může vzrůst na 500 kbps. listopad 2005 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 10.2, str. 15 dı́l 3, Bezpečnost v Linuxu Abychom vyhověli požadavku sdı́lenı́ pásma s garantovanými minimálnı́mi rychlostmi, upravı́me parametry ceil: 3: tc class add dev eth0 parent 1:0 classid 1:1 htb htb 5: tc class add dev eth0 parent 1:2 classid 1:10 htb 6: tc class add dev eth0 parent 1:2 classid 1:11 htb 7: tc class add dev eth0 parent 1:1 classid 1:3 htb 4: tc class add dev eth0 parent 1:1 classid 1:2 rate rate rate rate rate 768kbit 500kbit 372kbit 128kbit 268kbit ceil ceil ceil ceil 768kbit 768kbit 768kbit 768kbit Pokud tedy naše firma (třı́da 1:3) bude mı́t provoz menšı́ než 268 kbps a počı́tač ředitele sousednı́ firmy provoz většı́ než 500 kbps, celý mechanismus omezovanı́ provozu zajistı́, že volná kapacita třı́dy 1:3 bude (našı́m trpaslı́kem z odstavce Technika omezovánı́) zapůjčena třı́dě 1:2. Tato zapůjčená kapacita dále propadne do třı́dy 1:11, a ředitel sousednı́ firmy tak dosáhne vyššı́ rychlosti odchozı́ho provozu do Internetu. Zde tedy naše virtuálnı́ zařı́zenı́ IMQ nepoužijeme. U přı́chozı́ho provozu z Interntu je však situace složitějšı́. Zde provoz omezujeme na sı́t’ových zařı́zenı́ch eth1 a eth2 a kořenové třı́dy na nich pověšené si nemajı́ jak mezi sebou kapacitu půjčit. Na chvı́li odbočı́m a poznamenám, že jsme na začátku z důvodu bezpečnosti požadovali, aby byla sı́t’ našı́ firmy fyzicky oddělena od sı́tě sousednı́ firmy. To jsme realizovali použitı́m dvou sı́t’ových karet. V tuto chvı́li se nabı́zı́ myšlenka, že pokud se nám podařı́ zajistit, aby šel tok dat do těchto dvou zařı́zenı́ přes nějaké jedno virtuálnı́ mı́sto (bude jı́m virtuálnı́ sı́t’ové zařı́zenı́ IMQ) a omezovat budeme v tomto virtuálnı́m mı́stě (pověsı́me nějakou disciplı́nu na zařı́zenı́ IMQ), máme vyhráno. listopad 2005 část 9, dı́l 3, kapitola 10.2, str. 16 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu Přesměrovánı́ provozu (neboli jednotlivých paketů) přes zařı́zenı́ IMQ se provádı́ pomocı́ iptables v tabulce mangle přı́kazem iptables -t mangle -A POSTROUTING -j IMQ --todev 0. Protože můžeme mı́t v systému několik zařı́zenı́ IMQ, musı́me specifikovat parametrem --todev čı́slo tohoto zařı́zenı́. Nebot’ budeme omezovat pouze provoz, který k nám přı́cházı́ z Internetu, v pravidlech POSTROUTING přesměrujeme do IMQ zařı́zenı́ jen tento provoz. Použitı́ IMQ má v tomto přı́padě jednu nespornou výhodu oproti původnı́mu řešenı́. V odstavci, kde jsem popisoval problémy onoho řešenı́, jsem zmı́nil, že jádro bude protestovat proti velkým rozdı́lům v kapacitách jednotlivých třı́d. To nynı́ odpadne, protože máme od poskytovatele k dispozici kapacitu 512 kbps a tu budeme rozdělovat tak, že poměr jednotlivých třı́d nebude nijak velký. Protože se nám do omezovánı́ nebude plést provoz mezi vnitřnı́mi sı́těmi našı́ a sousednı́ firmy, bude moci tento provoz běžet na maximálnı́ rychlosti, která je dána rychlostmi použitých sı́t’ových prvků, což jsou v tomto přı́padě sı́t’ové karty (100 Mbps). Kdybychom měli do omezovánı́ mı́chat i tento provoz, právě kapacita od poskytovatele 512 kbps je ve velkém nepoměru s rychlostı́ na vnitřnı́ch sı́t’ových kartách a proti tomuto nepoměru jádro protestuje! Nadefinujeme tedy následujı́cı́ strukturu: listopad 2005 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 10.2, str. 17 dı́l 3, Bezpečnost v Linuxu O Zbytek upraveného skriptu pak bude vypadat takto: 9: tc qdisc del dev imq0 root 11: tc qdisc add dev imq0 root handle 1:0 htb default 4 12: tc class add dev imq0 parent 1:0 classid 1:1 13: tc class add dev imq0 parent 1:1 classid 1:2 14: tc class add dev imq0 parent 1:1 classid 1:3 15: tc class add dev imq0 parent 1:1 classid 1:4 htb htb htb htb rate rate rate rate 512kbit 212kbit ceil 512kbit 128kbit ceil 512kbit 172kbit ceil 512kbit 17: 19: tc filter add dev imq0 parent 1:1 protocol ip handle 21 fw flowid 1:3 20: tc filter add dev imq0 parent 1:1 protocol ip handle 24 fw flowid 1:4 21: tc filter add dev imq0 parent 1:1 protocol ip handle 31 fw flowid 1:2 Skript pro omezovánı́ provozu je tak dı́ky použitı́ zařı́zenı́ IMQ výrazně kratšı́. Zbývá nám doplnit firewallovacı́ skript v kapitole 9/3.6.3, a to doplněnı́m pravidel POSTROUTING v tabulce mangle. Přidáme na jeho konec tyto řádky: 29: 30: iptables -t mangle -A POSTROUTING -o lo -j ACCEPT 31: iptables -t mangle -A POSTROUTING -s "${net_nase_firma} -d "${net_sousedni_firma}" -j ACCEPT 32: iptables -t mangle -A POSTROUTING -d "${net_nase_firma} -s "${net_sousedni_firma}" -j ACCEPT listopad 2005 část 9, dı́l 3, kapitola 10.2, str. 18 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu 33: iptables -t mangle -A POSTROUTING -s "${vnitrni_ip_0}" -j ACCEPT 34: iptables -t mangle -A POSTROUTING -s "${vnitrni_ip_1}" "${net_sousedni_firma}" -j ACCEPT 35: iptables -t mangle -A POSTROUTING -j IMQ --todev 0 -s "${net_nase_firma}" -s Na řádku 35 přesměruji všechny pakety do zařı́zenı́ imq0 kromě paketů, které jsem „akceptoval“ v předchozı́ch pravidlech a které dı́ky akci ACCEPT ukončı́ průchod v tabulce mangle v řetězci POSTROUTING. Mezi tyto pakety patřı́ všechny takové, které sloužı́ pro internı́ potřebu sı́t’ového provozu na firewallu a jdou tak po virtuálnı́m zařı́zenı́ loopback (řádek 30), dále pakety, které patřı́ k provozu mezi vnitřnı́mi sı́těmi našı́ a sousednı́ firmy (řádky 31 a 32), dále pakety, které patřı́ provozu mezi našı́m firewallem a vnitřnı́ sı́tı́ našı́ firmy (řádek 33), a konečně pakety, které patřı́ provozu mezi našı́m firewallem a vnitřnı́ sı́tı́ sousednı́ firmy (řádek 34). Všechen ostatnı́ provoz je provoz z Internetu. Bohužel jej nemůžeme nijak jednoduše specifikovat pomocı́ nějakého pravidla. Proto jsou uvedena pravidla na řádcı́ch 30 až 34. Ničemu to však nevadı́, a účel je splněn. My tak budeme moci svému šéfovi oznámit splněnı́ úkolu. Něco o IMQ listopad 2005 Původnı́m autorem jaderného kódu zařı́zenı́ IMQ je Martin Devera (je mimochodem také autorem omezovacı́ disciplı́ny HTB). Původnı́ stránky projektu lze nalézt na adrese http://luxik.cdi.cz/~devik/ /qos/imq.htm. Autor se však již projektu nevěnuje a taktéž ani jeho nástupce. Protože však byla potřeba zařı́zenı́ typu IMQ natolik silná, našlo se několik nadšenců, kteřı́ se rozhodli v projektu pokračovat. Jako nejvı́ce životaschopný se jevı́ projekt na stránce BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, dı́l 3, kapitola 10.2, str. 19 dı́l 3, Bezpečnost v Linuxu http://www.linuximq.net/. Je nejčastěji aktualizovaný a použı́vá jej nejvı́ce správců (alespoň podle emailů, které chodı́ do linuxových konferencı́). IMQ se skládá ze dvou částı́. Tou prvnı́ je samotný ovladač v jádře. Ten nenı́ standardně ani ve vanilla jádře (jádro, vydané na kernel.org), ani v obvyklých distribucı́ch, jako např. RedHat. Je proto nutno stáhnout patch do jádra a opatchovat jej. Patch pro přı́slušné verze je dostupný na stránkách projektu. Instalace IMQ Druhou částı́ je modul do iptables, které také neumı́ standardně pracovat se zařı́zenı́m IMQ. Patch do iptables je opět dostupný na stránkách projektu IMQ a opět je nutno použı́t správnou verzi ke konkrétnı́ verzi iptables. Pak zbývá překompilovat iptables. Jak opatchovat jádro se dočtete v dokumentaci jádra, jak opatchovat a zkompilovat konkrétnı́ verzi iptables se dočtete na stránkách projektu IMQ a také na stránkách iptables (http://www.netfilter.org/). Po správné kompilaci jádra se po nabootovánı́ objevı́ zařı́zenı́ imq0 (a přı́padně dalšı́, pokud jsme při kompilaci zadali počet) a nebo je nutno natáhnout přı́kazem modprobe imq patričné moduly. Parametrem modulu imq je numdevs, kterým specifikujeme, kolik virtuálnı́ch zařı́zenı́ chceme použı́vat. Nám stačı́ jedno, defaultně se vytvářejı́ dvě. Po nataženı́ správného modulu je nutné toto zařı́zenı́ aktivovat, a to napřı́klad přı́kazem ip link set dev imq0 up a teprve pak s nı́m lze pracovat. Lze s nı́m pracovat i dřı́ve (přı́kazy iptables a tc), avšak IMQ nefunguje, resp. se neprojevuje konfigurace. Je nutno pamatovat na to, že pro zprovozněnı́ IMQ musı́me patchovat jádro. Při přı́liš velkém provozu Problémy s IMQ listopad 2005 část 9, dı́l 3, kapitola 10.2, str. 20 BEZPEČNÁ POČÍTAČOVÁ SÍŤ dı́l 3, Bezpečnost v Linuxu nebo přı́liš košatém stromu disciplı́n může být jádro nestabilnı́ a s nı́m i celý systém. Také se může stát, že některá staršı́ verze jádra a verze IMQ je stabilnějšı́ než novějšı́ verze jádra a IMQ. Je nutno chvı́li experimentovat. Stále se jedná o kód, který obsahuje nějaké chyby a nenı́ dostatečně odladěný, nicméně již je použitelný a také se často použı́vá. Pokud se vám tedy bude zdát, že je systém nestabilnı́, zkuste IMQ odstranit z jádra a provozovat systém chvı́li bez omezovánı́ a nebo bez omezovánı́ se sdı́lenı́m kapacity. Při problémech se také nebojte obrátit na autory projektu či do e-mailové konference, která je na stránkách projektu uvedena, protože autoři jsou velmi ochotni ke spolupráci. Obvykle je již váš problém vyřešen a vy jen použı́váte nevhodnou konfiguraci. listopad 2005 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kap. 11.1, str. 1 díl 3, Bezpečnost v Linuxu 9/3.11 LINUX - AKTUÁLNÍ TRENDY 9/3.11.1 SOUČASNÉ VERZE LINUXU A DISTRIBUCE Nástup stabilní řady jádra 2.6 znamenal další impuls pro rozšíření Linuxu i do komerční sféry, kde je zároveň se stabilitou potřeba dostatečná aktuálnost a podpora nových technologií. Původní vývojový model, kdy sudá verze jádra (2.4) byla stabilní a lichá (2.5) vývojová, vedl k tomu, že většina úsilí byla napřena k nestabilní řadě, kterou se ale linuxové firmy neodvážily nasazovat na produkční systémy, její oficiální podpora by byla příliš problematická a distributoři pak složitě udržovali v podstatě zastarávající stabilní řadu. Proto bylo odštěpení nové vývojové řady 2.7 odloženo a vývoj probíhá průběžně v jádrech řady 2.6. Stabilitu konkrétních jader pak již zaručují autoři jednotlivých distribucí ve chvíli, kdy se rozhodnou mezi aktualizace svého produktu zařadit novější jádro. Stoupl význam testovacích předběžných verzí, tzv. release-candidate, čili delší dobu před uvolněním další verze (např. 2.6.17) jsou k dispozici předběžné verze kvûten 2006 část 9, díl 3, kap. 11.1, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ díl 3, Bezpečnost v Linuxu (např. 2.6.17-rc2). Zároveň jsou již jednou vydané verze jádra v řadě 2.6 opravovány, takže se lze setkat např. s jádrem 2.6.16.10. Kromě variant spravovaných jednotlivými vývojáři (řada -ac jader od Alana Coxe či -mm od Andrewa Mortona) pak samozřejmě udržují autoři většiny distribucí své řady jader, u kterých pečlivě vybírají a testují, co do nich začlení. Není-li potřeba okamžitě opravovat nějakou chybu či nechceme-li přidat do svého jádra nějaký dosud v dodávaných jádrech nezahrnutý patch, vyplatí se většinou zůstat u jádra z používané distribuce. Linux zaznamenal velký úspěch i na moderních 64bitových procesorech, kde byl jedním z prvních dostupných systémů, který umožňuje plné využití všech možností. Nový hardware přináší i možnosti jak rozšířit bezpečnost systémů, např. podporu virtualizace, kdy na jednom stroji může běžet víc na sobě nezávislých instancí operačního systému dovolících ještě více omezit kritické části služby tak, aby nemohly ovlivňovat své okolí (podobně jako se dnes v této situaci nasazují dedikované servery - přínosem virtualizace může být ovšem přidělování zdrojů podle potřeby, což na zcela samostatném hardwaru není možné). Volně šířený virtualizační nástroj Xen je už dnes zahrnut do novějších distribucí. Red Hat a Fedora kvûten 2006 Firma Red Hat se rozhodla soustředit na svou komerční distribuci Red Hat Enterprise Linux (RHEL) a vydávání zdarma dostupných verzí svého Red Hat Linuxu ukončila verzí 9. Místo toho oživila projekt Fedora, kdy ve spolupráci s uživatelskou komunitou vydává v rychlejším sledu (zhruba jednou za půl roku až rok) zcela volnou distribuci Fedora Core. To jí mimo jiné umožňuje vyzkoušet v širokém nasazení nové technologie (např. bezpečnostní rozšíření SELi- BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kap. 11.1, str. 3 díl 3, Bezpečnost v Linuxu nux) a pak je nasadit i do své hlavní distribuce RHEL. Protože je RHEL založen na svobodném softwaru, zveřejňuje Red Hat zdrojové kódy (i aktualizací) své distribuce. Díky tomu pak mohou vzniknout klony původního RHEL, mezi nejznámější patří WhiteBox či CentOS, které se od originálu liší jen nepatrnými změnami (pochopitelně se nikde nesmí vyskytnout např. originální logo Red Hat, místo nezaplacené Red Hat Network se aktualizace řeší yumem z poskytnutých archívů apod.). Firma Novell se už delší dobu snažila také uchytit na linuxovém trhu, asi hlavním počinem (např. po pohlcení společnosti Ximian přispívající výrazně k rozvoji prostředí GNOME či obdoby platformy .NET Mono) je zakoupení původně německé firmy SUSE - tvůrce populární stejnojmenné distribuce. Po sjednocení došlo a asi ještě dojde ke změnám v uspořádání jednotlivých verzí distribucí - od SUSE Linux Enterpise Server (SLES) pro velké servery, přes Novell Desktop Linux až po nově založenou (patrně po vzoru Fedory) volnou openSUSE. Po Red Hatu je SUSE patrně nejrozšířenější komerční distribucí (např. Oracle oficiálně podporuje právě RHEL a SLES, přestože samozřejmě poběží i na jiných distribucích). SUSE a Novell Dalším důkazem čile se vyvíjejícího linuxového trhu je příběh firmy Mandrakesoft, spoluzaložené původně autorem francouzské, na běžné uživatele zaměřené distribuce Mandrake. Po překonání finančních problémů (ze kterých se dostala i díky silné podpoře od komunity) se spojila s brazilskou společností Conectiva, podporující mnoha způsoby (od přizpůsobené distribuce až třeba po vlastní časopis) Linux v Jižní Americe. Výsledkem je distribuce Mandriva Linux, která sice oproti Mandrake Linuxu změnila způsob číslo- Mandriva (dříve Mandrake a Conectiva) kvûten 2006 část 9, díl 3, kap. 11.1, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ díl 3, Bezpečnost v Linuxu vání verzí (rok v názvu), ale jinak je mu stále velmi podobná, včetně např. správce instalovaných balíčků urpmi. Na Debianu založené distribuce Nejsvobodnější distribuce GNU/Linuxu se po takřka třech letech od uvedení stabilní verze 3.0 (woody) dočkala nové stabilní verze 3.1 (sarge). Nadále si zachovává svou konzervativnost, kvůli které se do ní dostávají některé novinky pomaleji, než by si třeba uživatelé desktopových rozhraní přáli. Díky své otevřenosti se však stal Debian v průběhu času základem mnoha dalších distribucí, za zmínku stojí např. z CD provozovatelný Knoppix (využívaný hojně pro testování HW, spuštění spolehlivého systému v neznámém prostředí či záchranné práce na poškozených instalacích nejen Linuxu) nebo populární Ubuntu lišící se od Debianu právě zejména rychlostí nových verzí (každého půl roku nová). Další distribuce Je nemožné a zbytečné zmiňovat všechny distribuce (je jich několik set a stále přibývají), neměli bychom ale při případném výběru opominout podívat se i dál než jen na pár nejznámějších. Gentoo je třeba poměrně oblíbeným příkladem distribucí zaměřených na instalaci primárně nikoliv binárních balíčků, ale naopak kompilaci ze zdrojových kódů na cílovém stroji. Dá se tak prý dosáhnout zlepšení výkonu systému o jednotky až desítky procent a snadnější by mělo být i přenesení distribuce (jakožto sbírky předpřipravených programů) na další operační systémy (FreeBSD, Hurd). Další zajímavou kategorií jsou minimalistické distribuce použitelné např. pro záchranná CD (či dnes už i USB disky) nebo běh jednoúčelových firewallů. Zástupci mohou být Damn Small Linux či OpenWRT Linux nikoliv pro počítače v běžném slova smyslu, ale kvûten 2006 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kap. 11.1, str. 5 díl 3, Bezpečnost v Linuxu pro mnoho bezdrátových routerů (umožňující např. rozšířit jejich schopnosti o šifrování či VPN). Při rozšiřující se nabídce programů pro Linux a mnohdy i zvětšování jejich velikosti se musí tvůrci distribucí rozhodovat, co nabídnou na instalačních médiích. Asi nejrozsáhlejší základ má ze své povahy Debian, ale ani pro další systémy není k dispozici výrazně méně programů. Kromě možnosti doinstalovávat si jednotlivé aplikace samostatně kompilací ze zdrojových kódů či tvorbou a udržováním vlastních balíčků pro příslušného správce programů jsou tu ještě předpřipravené archivy, tzv. repository, kde autoři z řad dobrovolníků shromažďují pro danou distribuci předkompilované a mnohdy i dodatečně upravené balíčky. Při používání takového archivu pak lze těžit z podobných výhod jako při používání programového vybavení přímo z distribuce - většinou jsou balíčky testovány tak, aby spolu nekolidovaly, je zřejmé, kdo je vytvořil (bývají i digitálně podepsané), budou k nim k dispozici aktualizace, které lze automaticky instalovat, a v neposlední řadě je používá více lidí, než kdybychom si je připravovali sami. K populární distribuci Fedora jsou např. dostupné tzv. extras balíčky, spravované stejnou komunitou jako samotná distribuce, dalšími archivy jsou Dag RPM (autor Dag Wieers) nebo s ním nyní úzce spolupracující archivy FreshRPMS či Dries. Spoluprací mezi autory různých archivů by mělo být zajištěno, že balíčky z nich nebudou v konfliktu nejen se základní distribucí, ale ani mezi sebou navzájem. Bezmyšlenkovité přidávání zdrojů programů může ovšem vést nejen k problémům s dodatečně instalovanými balíčky, ale třeba i k nemožnosti aktualizací základních programů (do systému se dostanou nové, závislostmi provázané verze, naopak Doplňkové archivy programů kvûten 2006 část 9, díl 3, kap. 11.1, str. 6 BEZPEČNÁ POČÍTAČOVÁ SÍŤ díl 3, Bezpečnost v Linuxu zmizí původní, které mohly poskytovat i více vyžadovaných funkcí). Volba distribuce Při výběru konkrétní distribuce však stále platí, že nejsnáze se udržuje taková, pro kterou máme k dispozici dostatečnou podporu - ať už to bude firma, od které je distribuce zakoupena, či někdo v okolí, kdo stejnou distribuci sám používá a více se v ní vyzná. Dnes už také není problém zakoupit si nějakou distribuci včetně tištěné příručky v každém větším knihkupectví, i jen lehce poučení uživatelé pak najdou dostatečnou podporu na stále dostupnějším internetu. Některé distribuce nabízejí i své tzv. Live verze, kdy je možné spustit ukázkovou instalaci z předpřipraveného CD a celý systém si vyzkoušet, aniž by bylo nutné jakkoliv upravovat stávající obsah pevného disku. Ať už si nakonec nainstalujeme cokoliv, je nutné o instalaci pečovat - sledovat systémové protokoly (systémy jsou většinou nastavené tak, aby v pravidelných intervalech posílaly souhrnný výběr z logů správci mailem), na produkčních serverech sledovat zátěž (obsazení diskového prostoru, vytíženost procesorů a paměti) a preventivně reagovat na možné problémy a také včas aktualizovat programové vybavení. Každý řádný distributor či dostatečně velká komunita kolem konkrétní distribuce zveřejňuje varování před objevenými chybami, kromě specifických varování je ale vhodné sledovat (zejména v případě, že jsou v používaných systémech doinstalované další programy) i nějaký obecný zdroj bezpečnostních informací, ať už v emailu, na webu nebo třeba přes RSS (začít se dá třeba na webech securityfocus.com, sans.org, cve.mitre.org, cert.org nebo secunia.com). kvûten 2006 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kap. 11.2, str. 1 díl 3, Bezpečnost v Linuxu 9/3.11.2 ZABEZPEČENÍ BĚŽÍCÍCH SLUŽEB Je zřejmé, že počítač, na kterém nepoběží žádná síťová služba či který bude od sítě přímo odpojen, minimalizuje běžná bezpečnostní rizika. A přestože i taková pracoviště mají svůj význam a použití, zůstává každodenním problémem dostatečné zabezpečení potřebných síťových služeb - ať už jde o poštovní, http, ftp či třeba DNS server (je ale dobré omezovat spektrum běžících služeb na nezbytně nutné minimum, i když je třeba přístup k nim chráněn nastavením firewallu - nikdy nelze vyloučit, že některá část komplexního systému ochrany sítě selže či bude překonána). Klasickým způsobem omezení potenciálních rizik z kompromitace nějaké služby je tzv. chroot - její uzavření do „vězení“ (jail), kdy je prostředí daného procesu upraveno tak, aby jeho kořenovým adresářem nebyl kořen (root - dojde k jeho změně, change, proto chroot) celého systému, ale jiný adresář obsahující jen „Uvězněné“ služby kvûten 2006 část 9, díl 3, kap. 11.2, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ díl 3, Bezpečnost v Linuxu pro provozování služby nezbytně nutné soubory. Mechanismus chroot může být ale použit i pro jiné účely - třeba při nouzovém nastartování systému z opravného CD lze po zkontrolování instalace na disku připojit příslušný oddíl k aktuálně používanému souborovému systému, provést chroot do tohoto adresáře a nadále pracovat s původní instalací takřka stejně, jako by byl OS spuštěn z ní. Použití chrootu nemusí být vždy smysluplné - ne vždy lze omezit chod služby na rozumně malou vyhrazenou část souborů, asi jen těžko by se takto omezoval klasický poštovní server, který potřebuje mít přístup k adresářům s poštou i k domovským adresářům uživatelů s individuálními konfiguračními soubory (nicméně existují i takové úpravy). Uvězněný program by také neměl mít možnost se z vězení dostat - což se mu např. snadno podaří, pokud by měl ve svém adresáři k dispozici speciální zařízení pro přístup k hardwaru (/dev/hda, /dev/kmem...), neměl by také po přepnutí do nového adresáře zůstat běžet pod identitou administrátora či mít k dispozici nějaký s-uid program. Asi nejčastěji se lze s využitím chrootu setkat u démona named - jde o typicky zcela veřejnou službu, nelze tedy omezovat přístup k ní, ale ke svému běhu potřebuje minimum snadno vymezitelných informací (údaje o spravovaných doménách a zónách). Dalším typickým příkladem jsou ftp servery - ať už veřejné archivy, kde se omezuje přístup na souborný systém pro anonymní návštěvníky, ale i upravené ftp servery, které dokáží udržet v individuálním vyhrazeném prostoru běžné autorizované uživatele (často používané např. při hostingu). Chrootovaný program musí mít ve svém vězení k dispozici vše, co ke svému běhu bude potřebovat - od kokvûten 2006 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kap. 11.2, str. 3 díl 3, Bezpečnost v Linuxu pií (či upravených verzí) konfiguračních souborů přes vybraná speciální zařízení (např. /dev/null) až po knihovny, vůči kterým byl dynamicky linkován. Pokud použijeme předpřipravené balíčky z distribucí, je toto vše již většinou ošetřeno - při ruční instalaci či nestandardní konfiguraci je na to ale nutné pamatovat. Například zmíněný named má ve svém /var/named/chroot k dispozici nejen /dev/null, ale i /dev/zero a /dev/random. Existují i nástroje pro spuštění takřka libovolného programu v chrootovaném prostředí - program jailer, ale spíše se zdá, že tato metoda, která se snaží odstraňovat jeden z nedostatků klasického unixovému modelu práv, bude nahrazena pokročilejšími postupy. SELinux (Security Enhanced Linux) je velmi rozsáhlý projekt, jeden z mnoha způsobů, jak rozšířit bezpečnostní možnosti Linuxu (alternativami jsou např. grsecurity či RSBAC). Vývoj SELinuxu byl zahájen v americké NSA (National Security Agency), vyšel z modelu Flask použitého již v experimentálním operačním systému Flux. V nové řadě linuxového jádra 2.6 už je SELinux zahrnut (čemuž předcházela usilovná práce zejména na mechanismu pro takováto rozšíření LSM - Linux Security Modules), má ho tedy k dispozici v podstatě každý uživatel dnešního Linuxu. Nicméně jeho reálné použití vyžaduje netriviální objem práce na konfiguraci a v tom se liší jednotlivé distribuce Linuxu. Přímou podporu SELinuxu nabízejí Fedora a RHEL, existují (samozřejmě v unstable řadě) balíky pro Debian, podporu pro Gentoo dodává projekt Hardened Gentoo, dají se najít i předpřipravené balíčky pro další distribuce včetně SUSE. Nicméně firma Novell se rozhodla oficiálně podporovat své nové bezpečnostní rozšíření AppArmor a nikoliv SE- SELinux kvûten 2006 část 9, díl 3, kap. 11.2, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ díl 3, Bezpečnost v Linuxu Linux. Z části jde možná o součást konkurenčního boje s Red Hatem, z části má Novell určitě pravdu v tom, že bezpečnostní model SELinuxu je sice vhodný pro audity bezpečnostních agentur, ale jeho praktické nasazení a obsluhovatelnost běžnými uživateli je zatím problematická. AppArmor by měl být snadněji konfigurovatelný, sám využívá pro své zapojení do Linuxu rozhraní LSM a Novell ho nedávno uvolnil pod licencí GPL. Zařadil se tak po bok ostatním rozšířením (např. již zmíněnému a léty prověřenému patchi grsecurity), z nichž si každý může zcela svobodně vybrat, co mu bude vyhovat nejvíce. Řízení přístupu Klasickému řízení přístupu v unixových systémech se říká DAC - Discretionary Access Control (česky patrně volitelné řízení přístupu). Vychází z toho, že vlastník objektu může nadefinovat omezení pro přístup k němu (občas to znamená i nepřiměřeně benevolentní práva), a také z toho, že proces běžící pod identitou nějakého uživatele má veškerá jeho práva (což je nejlépe vidět na procesech uživatele root - mohou v podstatě cokoliv a jen na jejich libovůli závisí, zda toho využijí). Oproti tomu MAC - Mandatory Acces Control (povinné řízení přístupu) vyžaduje, aby měl každý subjekt (proces) explicitně definovaná práva pro přístup k objektům (souborům, socketům...). Jsou tak nejen lépe ochráněna data před nezamýšlenou kompromitací, ale nastavení práv může být i mnohem jemnější oproti hrubému dělení v běžném DAC. SELinux zavádí pro podporu MAC dvě hlavní technologie - vynucení typu (Type Enforcement, TE) a implementaci řízení přístupu podle role (Role Based Access Control, RBAC). TE znamená, že každý subjekt i objekt musí mít definovaný svůj typ. Typům subkvûten 2006 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kap. 11.2, str. 5 díl 3, Bezpečnost v Linuxu jektů (procesů) se také z historických důvodů říká domény (domains). Možné interakce mezi subjekty a objekty pak popisuje matice vytvořená z bezpečnostních pravidel - politik (policies). Sadu atributů každého subjektu či objektu popisuje tzv. bezpečnostní kontext (security context, label - nálepka), který je tvořen trojicí identita (uživatel), role a typ. Uživatel zde neznamená to samé, co běžný uživatel v OS. Kupříkladu pro většinu systémových démonů se používá identita system_u (dle konvence má označení uživatele koncovku _u, podobně role _r a typu _t). Kontext souboru s démonem pro jmenný server /usr/sbin/named pak je třeba system_u:object_r:named_exec_t (patří systémovému uživateli, jeho rolí je běžná role objektů - souborů a jeho typ je označen jako „spustitelný soubor služby named“). SELinux pak v konkrétním případě porovná bezpečnostní kontexty subjektu a objektu a rozhodne se, zda smí vydat povolení. I přesto, že si již jednou vydaná rozhodnutí ukládá do paměti (do tzv. access vector cache, avc) pro rychlejší odpověď v dalším stejném případě, udává se občas negativní vliv zapnutého SELinuxu na celkový výkon systému (ovšem i tak maximálně v jednotkách procent). Bezpečnostní kontexty existujících souborů si SElinux uchovává v rozšířených atributech (zobrazí je např. příkaz ls s parametrem -Z), je třeba na ně pamatovat např. při zálohování. Kompletní konfigurace SELinuxu pro konkrétní službu znamená popsat všechny typy využívaných objektů (konfiguračních, spustitelných, pracovních a dalších souborů, síťových spojení...) a rozepsat povolené aktivity. Z distribucí se dají získat pravidla pro několik předpřipravených služeb, ale pokud by si chtěl správce konkrétního systému zadefinovat vše, co pokvûten 2006 část 9, díl 3, kap. 11.2, str. 6 BEZPEČNÁ POČÍTAČOVÁ SÍŤ díl 3, Bezpečnost v Linuxu třebuje k běhu např. vlastnoručně připraveného hostingu, čeká ho hodně práce. I pro snadnější ladění pravidel lze SELinux provozovat nejen v režimu enforcing (je vynuceno dodržování bezpečnostních politik) či ho zcela vypnout (disabled), ale také použít volbu permissive, kdy místo zákazu přijde chybové hlášení do systémového protokolu. Takové hlášení je uvozeno „avc:“ (access vector cache) a obsahuje popis situace (subjekt, objekt a jejich bezpečnostní kontexty). Základní konfigurace SELinuxu v distribuci Fedora Core SELinux čte svou konfiguraci ze souborů v adresáři /etc/selinux. Soubor /etc/selinux/config obsahuje základní nastavení (např. výše zmíněný režim permissive), v dalších podadresářích pak jsou definice typů, pravidel či třeba maker využitýé při kompilaci textových zdrojových souborů politik do binárního používaného tvaru. /etc/selinux/config může vypadat např. takto: # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=permissive # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted Kromě určení režimu v proměnné SELINUX vidíme i nastavení konkrétní sady pravidel v proměnné SEkvûten 2006 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kap. 11.2, str. 7 díl 3, Bezpečnost v Linuxu LINUXTYPE. Kromě dvou distribučních si samozřejmě můžeme vytvořit i vlastní bezpečnostní politiku. Každé sadě pravidel přísluší vlastní (podle ní pojmenovaný) podadresář v /etc/selinux, v něm pak jsou další soubory popisující konkrétní nastavení. Asi jediným dalším, který má pro běžnou konfiguraci význam, je soubor booleans obsahující pravdivostní hodnoty upravující obecnou sadu použitých pravidel. Přímé změny v souboru by se projevily po dalším načtení (např. po rebootu stroje), preferovanou metodou, jak je měnit, je příkaz setsebool, který je změní pro již běžící instanci a případně (s parametrem -P) i natrvalo zapíše změnu do souboru. Příkaz setsebool -P httpd_enable_homedirs 0 tak například zakáže webovému serveru přístup k domovským adresářům a změnu zároveň zachová pro další spuštění systému. SELinux se dá i úplně vypnout při startu systému parametrem kernelu selinux=0, je však lepší nejdřív vyzkoušet jen vypnutí vynucovacího režimu parametrem enforcing=0, protože při zcela vypnutém SELinuxu nebudou zapisovány na souborový systém bezpečnostní kontexty. Při návratu k používání SELinuxu je pak nutné je obnovit (provést příkaz relabel je ostatně i součástí aktualizace bezpečnostní politiky). Přesto, že je dnes SELinux součástí jádra a jeho používání už je v některých distribucích implicitně zapnuto, bude patrně bezbolestný buď pro toho, kdo se spokojí s konfigurací systému tak, jak ho nainstaluje z distribuce (SELinux např. nelze provozovat nad souborovými systémy typu ReiserFS nebo JFS), nebo je naopak natolik zkušeným administrátorem, aby byl schopen odhalit případné problémy a udržovat si lokvûten 2006 část 9, díl 3, kap. 11.2, str. 8 BEZPEČNÁ POČÍTAČOVÁ SÍŤ díl 3, Bezpečnost v Linuxu kální úpravy bezpečnostních politik. V každém případě se vyplatí seznámit se s filozofií rozšířené správy oprávnění a být připraven přejít pak bez větších problémů třeba k AppArmor nebo grsecurity. kvûten 2006 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kap. 11.3, str. 1 díl 3, Bezpečnost v Linuxu 9/3.11.3 ZABEZPEČENÍ SÍŤOVÉ KOMUNIKACE Nemáme-li plnou kontrolu nad sítí (což např. bez uložení kabeláže v tlakových trubkách a kontrolních manometrů může říci málokodo) mezi uživateli a servery, nemůžeme si být nikdy zcela jisti, zda někdo nepovolaný neodposlouchává síťovou komunikaci. Nejde jen o vyzobávání jmen a hesel k freemailům, ale i o jistě mnohdy citlivé informace. Alespoň částečným řešením je šifrování dat - důsledné používání variant PGP v elektronické poště, zabezpečené varianty (SSL) síťových protokolů (https, pop3s...) nebo rovnou virtuální privátní síť (používanou zejména pro propojení částí interní sítě, kde částí může být i jeden klientský počítač, přes nedůvěryhodný internet). Na straně serveru nás bude zajímat, zda je konkrétní služba schopna komunikovat přes šifrovanou variantu svého protokolu. Poměrně snadná je situace u webového serveru - pro Apache existuje již dlouho rozšíření mod_ssl, které implementuje podporu protokolu SSL a stunnel kvûten 2006 část 9, díl 3, kap. 11.3, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ díl 3, Bezpečnost v Linuxu https. Při přechodu od http k https je ale občas nutné dořešit některé problémy - např. používal-li původní http server na jedné IP adrese virtuální servery rozlišené jménem, nebude možné v tom na https pokračovat (protože jméno serveru je obsaženo až v HTTP požadavku, nyní zašifrovaném - a už při dohadování SSL komunikace, tedy dříve, než dojde k převzetí požadavku serverem, musí být zřejmá konfigurace konkrétního virtuálního serveru). Zabezpečení přenosu hesel při přihlašování k výběru poštovní schránky lze dosáhnout používáním protokolů pop3s a imaps místo nešifrovaných pop3 a imap. To umožňuje např. server Dovecot dostupný ve většině distribucí. Podobně podporuje SSL variantu komunikace většina serverů, u kterých to má význam (OpenLDAP, databáze). Pokud by však nastala situace, kdy potřebujeme zabezpečit komunikaci, při které jedna ze stran nepodporuje SSL, lze využít program stunnel - ten se vloží mezi oba konce spojení a příslušný úsek komunikace zašifruje. Pokud jde o zabezpečení běžné lokální služby (např. pop3 démona), umí podobně jako inetd spustit příslušnou obsluhu navázaného spojení, příslušná pasáž v /etc/stunnel/stunnel.conf pak vypadá takto: [pop3d] accept = 995 exec = /usr/sbin/ipop3d execargs = ipop3d Nezabezpečená služba může ale běžet i na jiném stroji (např. proprietární zařízení s webovým konfiguračním rozhraním pouze nad běžným http) a stunnel zajistí, že klienti mohou použít pro připojení (k fiktivnímu serveru vytvořenému na nějakém volném portu stunnelem) zabezpečenou komunikaci - nezašifrovaná kvûten 2006 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kap. 11.3, str. 3 díl 3, Bezpečnost v Linuxu data pak zůstanou na úseku sítě mezi strojem s stunnelem a původním serverem. V opačném směru pak lze (při nastavení klientského režimu) stunnel použít např. při ladění komunikace se serverem dostupným pouze přes šifrované spojení (tj. poslouží i v situaci, kdy je naopak žádoucí mít možnost odposlouchat provoz): client = yes [odposlech] accept = 8080 connect = bezpecny.server.cz:443 (tj. na lokální port 8080 se může bez šifrování připojit prohlížeč, který pak bude dále připojen na https server běžící na stroji bezpecny.server.cz). Problematické v takovém uspořádání zůstává použití certifikátů a určení IP adresy spojení. Pro testování SSL spojení lze použít příkaz s_client programu openssl (openssl s_client -connect <adresa>:<port>) tak, jako se běžně používá pro testování klasické komunikace příkaz telnet <adresa> <port>. Linux podporuje poměrně široké možnosti, jak implementovat VPN, od protokolu CIPE (Crypto IP Encapsulation) vyvinutého na Linuxu přes různá zapouzdření PPP protokolu, např. do SSL (programem stunnel) až po standard IPSec. Patrně nejméně bezpečným, zato však na nejrozšířenější klientské platformě nejsnáze podporovaným protokolem je PPTP (Point-to-Point Tunneling Protocol). Jeho implementaci obsahuje server zvaný Poptop, je možné ho instalovat jak ze zdrojových kódů, tak z předpřipravených balíčků (kromě rozšířených distribucí Fedora či Debian je přímo na domovské stránce projektu podporována distribuce OpenWrt pro bezdrátové routery). Virtuální privátní síť, PPTP kvûten 2006 část 9, díl 3, kap. 11.3, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ díl 3, Bezpečnost v Linuxu Ke svému běhu potřebuje, aby kernel podporoval šifrování MPPE (Microsoft Point-to-Point Encryption), což splňují distribuční jádra od verze 2.6.15, do starších je nutné příslušný modul doinstalovat separátně. Protože PPTP závisí na standardním Point-to-Point Protocolu (PPP), je nutné, aby i on podporoval MPPE. Dostatečně nová verze (2.4.3) je například v distribucích Fedora Core 5 nebo Debian 3.1, do jiných se dá opět doplnit. Pak stačí doinstalovat vlastní server (pptpd). Pro jeho konfiguraci musíme vytvořit záznamy uživatelům VPN v souboru /etc/ppp/chapsecrets ve tvaru „jméno pptpd heslo *“ (druhá položka je označení serveru definované v /etc/ppp/options.pptpd, poslední IP adresa), do souboru /etc/pptpd.conf pak zapsat IP adresy, které bude server klientům přidělovat, např.: localip 10.0.1.1 remoteip 10.0.1.2-12 (klientům budou po řadě přidělovány adresy od 10.0.1.2 do 10.0.1.12, samotný server si na daném síťovém rozhraní nastaví adresu 10.0.1.1). V souboru /etc/ppp/options.pptpd (či jiném, na který by se odkázal zmíněný /etc/pptpd.conf) jsou pak další nastavitelné parametry pptpd serveru, na které většinou není třeba sahat, dokud vše funguje. V opačném případě lze zejména po prostudování chybových hlášení zkusit doladit např. používané šifry. Používáme-li na VPN serveru zároveň firewall, musíme zajistit, aby se k pptp serveru dostalo vše, co má. Služba běží na tcp portu 1723 a využívá také GRE protocol (číslo 47): iptables -I INPUT -i eth0 -p TCP -dport 1723 -j ACCEPT iptables -I INPUT -i eth0 -p 47 -j ACCEPT iptables -I OUTPUT -o eth0 -p 47 -j ACCEPT kvûten 2006 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kap. 11.3, str. 5 díl 3, Bezpečnost v Linuxu Podle toho, k čemu má VPN sloužit, pak doladíme pravidla pro provoz z a na klienty. Základem asi může být povolení provozu dál do sítě ze všech ppp rozhraní: iptables -A FORWARD -i ppp+ -j ACCEPT Kromě možnosti provozovat na Linuxu VPN server samozřejmě existuje i PPTP klient pro připojení linuxového systému ke vzdálenému VPN serveru. Při budování VPN si musíme uvědomit, co si pouštíme do vnitřní sítě - pokud je například běžné, aby si uživatelé sami spravovali své stanice i v lokální síti a počítáme s tím při nastavování ochrany služeb v ní, nebude asi přístup přes VPN výrazným zhoršením možných rizik. Pokud však spoléháme na bezpečnost všech strojů v lokální síti a důvěřujeme jim, mohlo by povolení VPN přípojek bez dodatečných omezení znamenat značné potenciální riziko. kvûten 2006 část 9, díl 3, kap. 11.3, str. 6 díl 3, Bezpečnost v Linuxu kvûten 2006 BEZPEČNÁ POČÍTAČOVÁ SÍŤ BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kap. 11.4, str. 1 díl 3, Bezpečnost v Linuxu 9/3.11.4 ZABEZPEČENÍ ELEKTRONICKÉ POŠTY Elektronická pošta představuje svými důsledky pro počítačovou síť sice méně závažné nebezpečí, ale o to je pravděpodobnější a hůře podchytitelné. Máte-li poštovní server na Linuxu, neohrozí ho asi vir pro Windows, který přes něj prošel - ovšem uživatel, který si ho stáhl a možná i spustil, tak může přijít nejen o čas strávený při odvirovávání své stanice, ale mnohdy i o data. Kromě nebezpečných programů se dnes elektronickou poštou šíří i záplava nevyžádaných mailů (spam), která uživatelům znepříjemňuje a leckdy i znemožňuje práci. Rozesílání podvržených mailů je i jednou z metod tzv. phishingu (český termín rhybaření se zatím příliš neujal), kdy se útočník snaží mailem či webovou stránkou navodit v uživateli dojem, že komunikuje např. se svou bankou, a získat tak od něj citlivé údaje (přístupová hesla, čísla kreditních karet...) Ochrana elektronické pošty před spamem a viry většinou znamená nějakou formu filtrování došlých maikvûten 2006 část 9, díl 3, kap. 11.4, str. 2 BEZPEČNÁ POČÍTAČOVÁ SÍŤ díl 3, Bezpečnost v Linuxu lů. Je tedy nutné mít za prvé program, který rozpozná, co je konkrétní mail zač (antivir, detektor spamu) a za druhé napojit tento program co nejvýhodněji na poštovní subsystém. To lze udělat mnoha způsoby triviálním využitím souboru .forward v domovském adresáři, vlastním (fiktivním) SMTP serverem přeposílajícím poštu skutečnému mailserveru nebo u některých poštovních programů i napojením se na jejich k tomuto účelu poskytované rozhraní. Antiviry Clam AntiVirus Pro úspěšný boj s viry samozřejmě nestačí mít třeba i velmi kvalitní program, ale je nutné neustále obnovovat databázi virů. I proto je obtížné mít klasický opensource antivirus podporovaný pouze komunitou, přesto však existuje GPL antivirus ClamaAV. Poskytuje časté (nejméně denní) aktualizace a drží krok s komerčními systémy (alespoň co se rychlosti reakce na dostatečně známé viry týká). Jeho primárním účelem bylo právě začlenění do poštovních serverů, kromě řádkové utility na prozkoumání souborů a aktualizačního programu nabízí i démona pro rychlou kontrolu zadaných dat (není nutné startovat na každý testovaný soubor či mail nový proces). Komerční antiviry Mnohé firmy dodávající antiviry dnes nabízejí i linuxové verze svých produktů. Bývá dobrým zvykem poskytovat zdarma verze pro osobní použití (kontrola veškeré pošty je však již mimo jejich rozsah), pokročilé edice pak jsou kromě kontroly souborových systémů (kdy linuxový server často slouží jako úložiště dat pro stanice s Windows) zaměřeny právě na kontrolu pošty. Podporují nejen běžné poštovní servery (sendmail, postfix, exim...) ale i komerční řešení (Lotus Notes). Lze si vybrat mezi F-Protem, NOD32, kvûten 2006 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kap. 11.4, str. 3 díl 3, Bezpečnost v Linuxu BitDefenderem či mnoha dalšími včetně u nás populárních antivirů Avast! a AVG. Taková řešení mají většinou již sama vyřešeno začlenění do poštovního serveru a občas v sobě mají i kontrolu spamu. Komplexní ochrana elektronické pošty před viry by se neměla omezovat jen na detekci konkrétních virů ve zprávách, ale i na specifické charakteristiky mailů, jako jsou například přílohy nebezpečných typů s nesouhlasícími názvy (příponami) či potenciálně nebezpečné prvky v HTML zprávách. Odhlédneme-li od boje se spamem přímo na úrovni MTA (zajímavou, i když ne vždy pozitivně vnímanou, technikou je třeba tzv. grey-listing: poštovní server se neřídí žádným striktním seznamem adres, ze kterých poštu nepřijímá - blacklistem, ale při prvním mailu z nějakého stroje mu zahlásí dočasnou chybu při doručování a čeká; normální poštovní server zkusí zprávu po chvíli doručit znovu, zatímco hromadný rozesílatel spamů už se tím většinou nezabývá), je zásadním problémem určení, co je a co není spam, z hlaviček a obsahu zpráv. Konkrétní techniky jsou většinou směsí mnoha pravidel, jejichž váhy se stanovují experimentálně pro každé konkrétní prostředí (na poštovním serveru firmy Pfizer by asi těžko bylo únosné zahazovat každý mail zmiňující viagru). Vzhledem k tomu, že pošta má sloužit uživatelům, musí se správce vždy snažit o rozumnou míru nasazení restrikcí. Pošta by měla být jen značkována či přesouvána do speciálních složek a ne rovnou zahazována, uživatelé by také měli mít možnost vyjmenovat např. konkrétní adresy, ze kterých chtějí poštu vždy dostávat či jinak individuálně ovlivnit, jak jim bude pošta filtrována. Detekce spamu kvûten 2006 část 9, díl 3, kap. 11.4, str. 4 BEZPEČNÁ POČÍTAČOVÁ SÍŤ díl 3, Bezpečnost v Linuxu Je určitě slušné nejen v případě, že sami proti spamu bojujeme, konfigurovat svůj vlastní poštovní server tak, aby přes něj nebylo možné spam rozesílat. Vyhneme se tak potenciálnímu zařazení na černé listiny nedůvěryhodných serverů. Naštěstí už je dnes takové nastavení většinou zajištěno přímo po nainstalování z distribuce, ale různé blacklisty kontrolují nejen samotné chování serveru, ale např. i korektní konfiguraci DNS (základem je určitě existující záznam doménového jména pro danou IP adresu). Pokud se tedy stane, že pošta z našeho serveru začne být někde odmítána, nezbude než dohledat důvod (většina filtrů bývá natolik slušných, že důvod zamítnutí sdělí, ale z hlášky o přítomnosti na konkrétním blacklistu nemusí být hned patrné, proč tam byl server zařazen pak je nutné hledat na příslušných stránkách nebo si nechat svůj server otestovat a prozkoumat výsledek). Bohužel se občas může i stát, že pravidla pro daný blacklist jsou natolik podivná, že není možné či rozumné jim vyhovět. Záleží-li nám i nadále na úspěšném doručení zpráv na server, který onen příliš striktní blacklist používá, je možné kontaktovat jeho správce (nejlépe z jiné adresy) a pokusit se ho přesvědčit, aby změnil svá pravidla. V podobné situaci se můžeme ocitnout ovšem i sami. SpamAssassin kvûten 2006 Patrně nejrozšířenějším programem pro detekci spamu je perlový filtr SpamAssassin. Jeho výhodou je kombinace mnoha různých přístupů pro rozlišení, zda konkrétní mail je spam (česky doslovně sekaná či lančmít nebo prejt) nebo ham (doslovně šunka - termín označující to, co není spam). Analyzuje tělo zprávy i její hlavičku, využívá informace z blacklistů (seznamů nedůvěryhodných serverů) a distribuovaných databází spamů (porovnání kontrolních součtů zpráv BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kap. 11.4, str. 5 díl 3, Bezpečnost v Linuxu z mnoha různých serverů odhalí často se vyskytující spamy) a používá i další techniky, doplnitelné navíc mechanismem dodatečných pluginů. Pro efektivní kontrolu je opět (obdobně jako u antivirů) k dispozici démon, který může neustále běžet v dané konfiguraci a testovat poskytnuté maily, aniž by byl na každý spouštěn nový proces. Přesto se může stát detailní kontrola došlé pošty na vytíženějších serverech natolik náročnou, že se do úvah kromě zjednodušení vlastních testů dostane např. i distribuované testování jako síťová služba. Existují i další detektory spamu (např. bogofilter Erica S. Raymonda), většinou však implementují nějakou novou rozpoznávací metodu. Pokud se osvědčí, dostanou se časem určitě v nějaké formě do SpamAssassinu. Samozřejmě i v této oblasti lze najít komerční řešení, např. CanIt od RoaringPenguin Software, tvůrců populárního volně šířeného mailového filtru MIMEDefang. Poštovní filtry Nejsnazším způsobem, jak zapojit do zpracování pošty další programy, je obecný program Procmail používaný tradičně např. pro třídění či přeposílání pošty. Je většinou dostupný i běžnému uživateli a nevyžaduje administrátorská práva a změny v konfiguraci celého serveru. SpamAssassin přímo v základní distribuci obsahuje krátký, leč dostatečný popis jak přes konfigurační soubor .procmailrc začít používat kontrolu došlé pošty na spam. Pro nasazení na celém serveru však takové řešení není příliš vhodné a vyplatí se nainstalovat specializovaný filtr. Značně rozšířeným filtrem je MailScanner - vyšla o něm kniha, dostupná je i komerční podpora. Je schopen běžet (není-li podporován efektivnější způsob in- MailScanner kvûten 2006 část 9, díl 3, kap. 11.4, str. 6 BEZPEČNÁ POČÍTAČOVÁ SÍŤ díl 3, Bezpečnost v Linuxu tegrace s MTA) i jako brána mezi vnějším internetem a libovolným vnitřním poštovním serverem, podporuje mnoho antivirů (může maily testovat i více než jedním pro lepší kontrolu) a samozřejmě SpamAssassin pro detekci spamu. Poměrně snadno se konfiguruje. Kromě testování došlé pošty na viry a spamy nabízí i základní pokus o detekci phishingu (v HTML zprávách se snaží najít odkazy, které neodpovídají svým popisům a nejspíš jsou tak určené k oklamání adresáta), sadu pravidel pro určení nebezpečných příloh a několik možností jak na podezřelé e-maily reagovat a co s nimi dělat. Amavisd-new Ze staršího programu AMaViS (A Mail Virus Scanner) vzešlo několik vývojových větví, dnes asi nejúspěšnějí je amavisd-new, plně srovnatelný s MailScannerem. Doporučován je zejména pro použití s mailovým serverem Postfix, existuje k němu ale i rozhraní pro milter sendmailu (byť s určitými omezeními) a je samozřejmě schopen napojit se na libovolný poštovní server. MIMEDefang a rozhraní sendmailu milter MIMEDefang je filtr určený pouze pro poštovní server sendmail, jejž API milter, vytvořený právě pro zapojení dalších programů přímo do procesu zpracování příchozí pošty (už rovnou v době komunikace s odesilatelem), využívá. Kromě možnosti začlenit antivirovou či antispamovou kontrolu umožňuje například pokročilé manipulace s přílohami. Existují i samostatná rozšíření programů SpamAssassin či ClamAV pro napojení k sendmailu přes rozhraní milter. Při volbě vhodné konfigurace je asi nutné se nejdřív zamyslet, jaké nároky budou na poštovní server kladeny, ať už půjde o výkon (kolik mailů bude nutné zpracovávat) či o možnosti (podpora více různých an- kvûten 2006 BEZPEČNÁ POČÍTAČOVÁ SÍŤ část 9, díl 3, kap. 11.4, str. 7 díl 3, Bezpečnost v Linuxu tivirů, různé manipulace se zprávami). Je také dobré, pokud se kontrola dostane co nejníže při zpracování pošty, kdy není například nutné čekat na přijetí celého mailu a dodatečně ho případně dalším mailem zamítnout, ale rovnou při komunikaci s odesilatelem využít chybová hlášení SMTP protokolu. Poměrně oblíbenou konfigurací (zejména na Debianu) je postfix+amavisd-new (+clamav a spamassassin), rozhodneme-li se pro sendmail, lze si třeba na Fedoře snadno stáhnout rozšíření clamav-milter a spamassmilter (pro bohatší manipulaci s poštou je však určitě lepší sáhnout rovnou po obecnějším filteru). kvûten 2006 část 9, díl 3, kap. 11.4, str. 8 díl 3, Bezpečnost v Linuxu kvûten 2006 BEZPEČNÁ POČÍTAČOVÁ SÍŤ