3 BEZPEČNOST V LINUXU

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


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

ˇ NA ˇ ÍTAC ˇ OVA ´ POC ´ SI´Tˇ BEZPEC

cˇa´st 9, dı´l 3, kapitola 1, str. 1

dı´l 3, Bezpecˇnost v Linuxu

9/3.1 ´ DRO, INSTALACE LINUXOVE´ JA LINUXU

Linuxove´ ja´dro je to, co se stara´ o prˇideˇlovańı´ hardwarovyćh prostrˇedku˚ jednotlivy´m programu˚m, ˇr´ıdı´ spra´vu pameˇti, ˇr´ıdı´ procesy atp. Je to skutecˇne´ ja´dro syste´mu.

Linuxove´ ja´dro

Prˇi konfiguraci drˇ´ıve nebo pozdeˇji narazı´me na verzi ja´dra. Ja´dro je vyvı´jeno v neˇkolika veˇtvıćh, kde kazˇda´ veˇtev ma´ sve´ho spra´vce. Jednotlive´ ˇrady se od sebe odlisˇujı´ cˇ´ıslem verze, a to ve forma´tu X.Y.Z, kde X je major verze ja´dra, Y je minor verze ja´dra a Z je pak aktua´lnı´ vydańı´ ja´dra v ˇradeˇ X.Y. Je-li cˇ´ıslo Y sude´, pak se jedna´ o stabilnı´ ˇradu, cozˇ znamena´, zˇe v ja´drˇe nejsou zˇa´dne´ zna´me´ chyby a pouzˇitı´ tohoto ja´dra by nemeˇlo zpu˚sobit zˇa´dne´ proble´my, naprˇ´ıklad ztra´tu dat na disku. Je-li Y liche´, jedna´ se o ˇradu vy´vojovou. Ta slouzˇ´ı vy´voja´ˇru˚m ja´dra k prˇida´vańı´ novyćh vlastnostı´ a jejich testovańı´. Nova´ vlastnost mu˚zˇe by´t v pozdeˇjsˇ´ı vy´vojove´ verzi bez na´hrady odstraneˇna. Z vy´vojove´ veˇtveˇ se cˇasem stane veˇtev stabilnı´. prosinec 2003




Soucˇasnou stabilnı´ veˇtvı´ ja´dra je 2.4 a vy´vojovou veˇtvı´ je 2.5. Kromeˇ teˇchto standardnıćh veˇtvı´ jesˇteˇ existujı´ dalsˇ´ı, spravovane´ ru˚zny´mi vy´voja´ˇri. Pomeˇrneˇ zna´ma´ je tzv. ac veˇtev spravovana´ jednı´m z vy´voja´ˇru˚ ja´dra – Alanem Coxem. Tyto veˇtve vznikly proto, zˇe do stabilnı´ ˇrady nepronikly neˇktere´ vlastnosti z ru˚znyćh du˚vodu˚ a autor tak vytvorˇil svou veˇtev s tı´m, zˇe onu vlastnost prˇidal. Krom toho existuje velke´ mnozˇstvı´ patchu˚ (za´plat) do ja´dra. Prˇi jejich aplikaci je nutna´ nejvysˇsˇ´ı opatrnost, sˇpatneˇ napsany´ patch mu˚zˇe ohrozit bezpecˇnost a stabilitu cele´ho syste´mu z du˚vodu˚ nekompatibility prˇida´vane´ vlastnosti se sta´vajıćı´mi. Veˇtsˇina distribucı´ pouzˇ´ıva´ ja´dra opatchovana´. Je to proto, zˇe prˇida´vajı´ neˇktere´ bezpecˇnostnı´ prvky, rozsˇirˇujı´ pocˇet ovladacˇu˚, atp. Takove´to ja´dro by´va´ proveˇˇreno na ru˚zne´m mnozˇstvı´ hardwaru, ktery´ vlastnı´ vy´voja´ˇri nemusı´ mı´t k dispozici. Obecneˇ platı´, zˇe pokud nova´ ja´dra neopravujı´ neˇjakou bezpecˇnostnı´ chybu cˇi pokud nema´me proble´my se stary´m, nenı´ du˚vod opousˇteˇt ja´dro, ktere´ na´m nabı´zı´ distributor. Instalace

Instalace Linuxu se v mnohe´m lisˇ´ı od sveˇta proprieta´rnı´ho softwaru. V prve´ ˇradeˇ lze instalovat neˇkolika zpu˚soby, nejen obvykly´m pomocı´ CDROM disku. Lze pouzˇ´ıt takte´zˇ instalaci z disku, kdy potrˇebny´ software na disk prˇed instalacı´ nakopı´rujeme, lze pouzˇ´ıt instalaci z FTP serveru, pokud ma´me k dispozici prˇipojenı´ k Internetu (cˇi k sı´ti, kde se dany´ FTP server nacha´zı´), lze pouzˇ´ıt instalaci prˇes HTTP atp. Prˇed instalacı´ je nutne´ si rozvrhnout rozdeˇlenı´ disku. UNIXove´ syste´my majı´ charakteristickou adresa´ˇrovou strukturu a Linux se jı´ drzˇ´ı. Korˇenem cele´ho

prosinec 2003




adresa´ˇrove´ho syste´mu je adresa´ˇr /. V neˇm se nacha´zı´ dalsˇ´ı adresa´ˇre, z nich nejvy´znamneˇjsˇ´ı jsou /etc, /bin, /tmp, /var, /home a /usr. V adresa´ˇri /etc se nacha´zı´ veˇtsˇina konfiguracˇnıćh souboru˚, /bin je adresa´ˇr urcˇeny´ za´kladnı´m utilita´m syste´mu, /tmp pak slouzˇ´ı k docˇasne´mu vytva´ˇrenı´ souboru˚, /var je adresa´ˇr, kam programy umist’ujı´ logovacı´ soubory, /home je adresa´ˇr urcˇeny´ jednotlivy´m uzˇivatelu˚m a v adresa´ˇri /usr je pak umı´steˇn zbytek programove´ho vybavenı´ syste´mu. Na serverovyćh syste´mech je z hlediska bezpecˇnosti vhodne´, aby nebyly vsˇechny adresa´ˇre umı´steˇny na jednom diskove´m oddı´lu. Do adresa´ˇre /var se neusta´le zapisuje a naprˇ´ıklad prˇi na´hle´m vy´padku proudu se mu˚zˇe posˇkodit struktura diskove´ho oddı´lu, na ktery´ se pra´veˇ zapisovalo. Bude-li adresa´ˇr /var na zvla´sˇtnı´m diskove´m oddı´lu, pravdeˇpodobnost, zˇe se posˇkodı´ struktura diskove´ho oddı´lu, na ktere´m jsou ostatnı´ adresa´ˇre, je nı´zka´. Dalsˇ´ı situace: diskovy´ oddı´l, na ktere´m je adresa´ˇr /var, se mu˚zˇe zaplnit naprˇ´ıklad proto, zˇe neˇktery´ program vytvorˇ´ı prˇ´ılisˇ velky´ logovacı´ soubor. Pokud bude na stejne´m diskove´m oddı´le adresa´ˇr /var a /home a v adresa´ˇri /home/ftp bude moci anonymnı´ uzˇivatel pro FTP prˇ´ıstup ukla´dat soubory a takovy´ uzˇivatel ulozˇ´ı prˇ´ılisˇ velky´ soubor a diskovy´ oddı´l zaplnı´, ostatnı´ programy pak nebudou moci zapisovat do svyćh logovacıćh souboru˚ v adresa´ˇri /var. Podobnyćh situacı´ nasta´va´ prˇi beˇhu syste´mu vıće. Jak tedy rozdeˇlit disk naprˇ´ıklad pro firemnı´ server, ktery´ prˇijı´ma´ posˇtu pro 200 uzˇivatelu˚, je proxy serverem pro prˇ´ıstup na Internet a za´rovenˇ firewallem? Pro adresa´ˇr / vyhradı´me minima´lneˇ 700 MB volne´ho mı´sta. Na dalsˇ´ı diskovy´ oddı´l umı´stı´me adresa´ˇr /var, kde se budou vytva´ˇret logovacı´ soubory a ostatnı´ veˇci kromeˇ prosinec 2003




adresa´ˇru˚ /var/spool/squid a /var/spool/mail. Na dalsˇ´ı diskovy´ oddı´l umı´stı´me /var/spool/mail, kam se budou ukla´dat emaily uzˇivatelu˚. Pokud bude mı´t kazˇdy´ uzˇivatel pru˚meˇrneˇ 15 MB velkou emailovou schrańku a ma´me 200 uzˇivatelu˚, budeme potrˇebovat diskovy´ oddı´l velky´ te´meˇˇr 3 GB. Na dalsˇ´ı diskovy´ oddı´l (a nejle´pe na dalsˇ´ı disk) umı´stı´me adresa´ˇr /var/spool/squid, kde proxy server vytva´ˇr´ı svou cache. Cˇ´ım veˇtsˇ´ı cache, tı´m vıće tento server ulehcˇuje kapaciteˇ linky. Volba 1 GB je dostacˇujıćı´. Poslednı´ adresa´ˇr, ktery´ si zaslouzˇ´ı vlastnı´ diskovy´ oddı´l, je adresa´ˇr /home, kam mohou uzˇivatele´ ukla´dat sva´ data. Tuto velikost volte podle konkre´tnı´ situace. Prˇi samotne´m rozdeˇlovańı´ bychom meˇli vzı´t v u´vahu swapovańı´. Linuxove´ ja´dro umozˇnˇuje swapovat jak do souboru, tak prˇ´ımo do diskove´ho oddı´lu. Platı´, zˇe swapovańı´ do diskove´ho oddı´lu je rychlejsˇ´ı, a proto pro swap vyhradı´me dalsˇ´ı diskovy´ oddı´l. Chceme-li navıć zvy´sˇit rychlost syste´mu, je vhodne´ oddı´ly swap a ostatnı´ mı´t na zvla´sˇtnıćh discıćh. Jak se vsˇak ukazuje, praxe firem je takova´, zˇe cely´ syste´m beˇzˇ´ı na jednom disku. Pak je rozdeˇlujme na /, /var, swap a /home. Distribuce, at’uzˇ beˇhem instalace cˇi po prvnı´m restartu pocˇ´ıtacˇe, umozˇnˇujı´ nastavit formu ulozˇenı´ hesel v syste´mu. Linux pouzˇ´ıva´ jako kazˇdy´ UNIXovy´ syste´m pro informace o ućˇtech na syste´mu soubor /etc/passwd. Hesla k jednotlivy´m ućˇtu˚m vsˇak umozˇnˇuje ulozˇit v oddeˇlene´m souboru /etc/shadow, ktery´ je navıć cˇitelny´ pouze pro uzˇivatele root, cozˇ je uzˇivatel s administra´torsky´m opra´vneˇnı´m. Da´le je doporucˇeno ukla´dat tato hesla v zasˇifrovane´m tvaru, dnes typicky pomocı´ algoritmu MD5. prosinec 2003




Prˇi instalaci syste´mu je vhodne´ vybrat jen ty balı´ky, ktere´ budeme skutecˇneˇ pouzˇ´ıvat. Naprˇ´ıklad na serveru se vu˚bec nemusı´ nacha´zet prˇekladacˇ syste´mu cˇi FTP klient. Virus z roku 2002, ktery´ napadal chybu v implementaci OpenSSL a do syste´mu pronikal prˇes protokol https, tak zapsal do adresa´ˇre, kam mohl zapisovat, i daemon https (byl to obvykle adresa´ˇr /tmp), zkompiloval (cˇili byla nutna´ prˇ´ıtomnost prˇekladacˇe) prˇ´ıslusˇny´ program a jı´m potom zahltil linku do Internetu. Kdyby na syste´mu nebyl prˇekladacˇ, tak by sice syste´m byl kompromitovań, ale u´tocˇnı´k by pomocı´ tohoto viru nedoka´zal zahltit linku. Administra´tor navıć v tomto prˇ´ıpadeˇ neprova´deˇl okamzˇitou aktualizaci, avsˇak jednoty´dennı´. Kdyby tedy na syste´mu nebyl prˇekladacˇ, prˇi nejblizˇsˇ´ı aktualizaci by se proble´m odstranil. Platı´, zˇe cˇ´ım meńeˇ zbytecˇne´ho softwaru, tı´m meńeˇ potencia´lnıćh zbytecˇnyćh chyb.

prosinec 2003



prosinec 2003





9/3.2 ´ PLATOVA ´ NI´ SYSTE´MU ZA

Po instalaci serveru musı´me vzı´t v u´vahu jednu du˚lezˇitou veˇc. Instalacˇnı´ me´dia distribuce (at’ jizˇ obsah CDROM, cˇi obsah FTP serveru) se obvykle neaktualizuje. Prˇ´ıpadne´ vydane´ za´platy k distribuci se zverˇejnˇujı´ na strańkaćh distributora a jsou obvykle dostupne´ prˇes FTP server. Proto je po cˇiste´ instalaci syste´mu nutne´ zkontrolovat, zdali jizˇ nejsou vydańy za´platy, a pokud ano, je nutne´ je nainstalovat. Veˇtsˇina distribucı´ ma´ neˇjaky´ mechanismus pro automatickou instalaci bezpecˇnostnıćh za´plat. Je nutne´ se tedy obra´tit na dokumentaci k prˇ´ıslusˇne´ distribuci. Pro bezpecˇnost syste´mu je pravidelne´ za´platovańı´ klıćˇove´, zˇa´dny´ software nenı´ 100% bezpecˇneˇ napsany´ a drˇ´ıve nebo pozdeˇji se neˇjaka´ bezpecˇnostnı´ chyba vyskytne. Syste´m spra´vy balı´ku˚ Debianu patrˇ´ı rozhodneˇ k teˇm nejlepsˇ´ım a tudı´zˇ ani automaticke´ za´platovańı´ pro

Automaticke´ za´platovańı´ syste´mu v Debianu prosinec 2003




neˇj neprˇedstavuje proble´m. Zjisˇteˇnı´ prˇ´ıtomnosti novyćh opravnyćh balı´ku˚ mu˚zˇeme prove´st pomocı´ prˇ´ıkazu apt-get update, sta´hnutı´ a nainstalovańı´ balı´ku˚ se provede pomocı´ prˇ´ıkazu apt-get upgrade. Tyto dva prˇ´ıkazy je vhodne´ umı´stit do neˇjake´ho skriptu a ten nechat v pravidelnyćh intervalech spousˇteˇt z crond (program pro automaticke´ spousˇteˇnı´ programu˚ v danyćh intervalech). Tı´m zajistı´me automatickou aplikaci za´plat do syste´mu. Ovsˇem pozornost je nutne´ veˇnovat serveru˚m, z kteryćh balı´ky stahujeme (viz soubor /etc/apt/sources.list), Debian standardneˇ nepodporuje digita´lnı´ podpisy u balı´ku˚, tudı´zˇ se v prˇ´ıpadeˇ kompromitace stroje, z ktere´ho stahujeme balıćˇky, mu˚zˇe do syste´mu zcela nepozorovaneˇ dostat backdoor! V poslednı´ verzi Debianu jizˇ na´stroje na oveˇˇrovańı´ integrity existujı´, nicmeńeˇ veˇtsˇina balı´ku˚ nenı´ podepsańa. To by meˇla napravit prˇ´ısˇtı´ verze Debianu (Sarge). Automaticke´ za´platovańı´ v RedHatu

prosinec 2003

K automaticke´mu za´platovańı´ v te´to distribuci slouzˇ´ı na´stroj up2date. Pro jeho pouzˇ´ıvańı´ je nutna´ registrace v RedHat Network na webovskyćh strańkaćh spolecˇnosti nebo prˇ´ımo po instalaci syste´mu. V konfiguraci na´stroje up2date pak lze nastavit, zda na´s ma´ upozornit na nove´ za´platy, nebo je ma´ i sta´hnout a nebo je dokonce i nainstalovat. Samotna´ automaticka´ instalace mu˚zˇe by´t osˇidna´, protozˇe se mu˚zˇe sta´t, zˇe se zmeˇnı´ volby v konfiguracˇnı´m souboru. Pak za´lezˇ´ı na tom, zda syste´m zaza´lohuje stary´ konfiguracˇnı´ soubor a restartuje sluzˇbu s novy´m (a defaultnı´m) konfiguracˇnı´m souborem nebo novy´ konfiguracˇnı´ soubor ulozˇ´ı pod jiny´m jmeńem a pak na to upozornı´ naprˇ´ıklad emailem. Je vhodne´ nechat si za´platu sta´hnout a o jejı´m updatu rozhodnout rucˇneˇ.




Firma RedHat nynı´ do sve´ testovacı´ distribuce zahrnula na´stroj yum a zda´ se, ze balı´k up2date bude z distribuce tı´mto na´strojem vytlacˇen. Je tedy obecneˇ vzˇdy nutne´ podı´vat se do aktua´lnı´ dokumentace k syste´mu a zjistit, jaky´ mechanismus aplikace za´plat je pouzˇ´ıvań.

prosinec 2003



prosinec 2003





9/3.3 ˇ TY Ć UZˇIVATELSKE´ U

Databa´ze uzˇivatelskyćh ućˇtu˚ se na Linuxu nacha´zı´ v souboru /etc/passwd. Tento soubor je cˇitelny´ vsˇemi uzˇivateli a obsahuje za´kladnı´ informace o uzˇivatelske´m ućˇtu – jako naprˇ. unika´tnı´ ID ućˇtu (UID – user ID), cˇ´ıslo skupiny (GID), umı´steˇnı´ domovske´ho adresa´ˇre a pouzˇity´ shell (interpretr prˇ´ıkazove´ho ˇra´dku). Shell by´va´ veˇtsˇinou nastaven na /bin/sh cˇi jiny´ interpretr prˇ´ıkazove´ho ˇra´dku, ale pokud chceme zabrańit dane´mu uzˇivateli v prˇihla´sˇenı´ na stroj, nastavı´me mu shell na program typu /bin/false, ktery´ se okamzˇiteˇ ukoncˇ´ı. To je efektnivnı´ naprˇ. v prˇ´ıpadeˇ, kdy chceme zabrańit uzˇivatelu˚m majıćı´m na serveru posˇtovnı´ ućˇet v prˇihla´sˇenı´.

prosinec 2003



prosinec 2003





9/3.4 ˇ NOST NA U ´ ROVNI BEZPEC SOUBOROVE´HO SYSTE´MU

Linux standardneˇ nepodporuje ACL (Access Control List), tudı´zˇ jsou mozˇnosti nastavenı´ pra´v u jednotlivyćh souboru˚/adresa´ˇru˚ omezeneˇjsˇ´ı. Kazˇdy´ soubor ma´ sve´ho vlastnı´ka a skupinu vlastnı´ku˚. Mu˚zˇeme definovat oddeˇlena´ pra´va pro vlastnı´ka, skupinu a pro ostatnı´ uzˇivatele. Mu˚zˇeme pro neˇ nastavit pra´vo cˇtenı´, za´pisu a spousˇteˇnı´ dane´ho souboru. U adresa´ˇru˚ je nutne´ povolit prova´deˇnı´, jinak nenı´ mozˇne´ do adresa´ˇre prˇejı´t. Pokud ma´ uzˇivatel pra´vo prova´deˇnı´ u dane´ho adresa´ˇre, ale nikoliv pra´vo cˇtenı´, nemu˚zˇe si vypsat seznam souboru˚ v tomto adresa´ˇri. Da´le pak mu˚zˇeme programu˚m prˇirˇadit prˇ´ıznak setuid cˇi setgid, cozˇ zpu˚sobı´, zˇe program bude spousˇteˇn s efektivnı´m UID vlastnı´ka, poprˇ. s EGID vlastnicke´ skupiny. Nastavovańı´ teˇchto prˇ´ıznaku˚ je nutno prova´deˇt velmi obezrˇetneˇ, zvla´sˇt’u programu˚, jejichzˇ vlastnı´kem je root. Nevhodne´ nastavenı´ SETUID prˇ´ıznaku u programu vlastneˇne´ho uzˇivatelem root mu˚zˇe velmi posˇkodit bezpecˇnost prosinec 2003




cele´ho syste´mu. Pro zmeˇnu pra´v pouzˇ´ıva´me prˇedevsˇ´ım utilitu chmod práva soubor/adresář. Pra´va mu˚zˇeme zadat bud’ jako cˇtyrˇi cˇ´ısla, kde prvnı´ cˇ´ıslo je soucˇet cˇ´ısel 1 (prˇ´ıznak sticky), 2 (setgid), 4 (setuid). Zbyla´ trˇi cˇ´ısla urcˇujı´ pra´va pro uzˇivatele, skupinu a ostatnı´ uzˇivatele. Zı´ska´me je jako soucˇet teˇchto cˇ´ısel: 1 (prova´deˇnı´), 2 (za´pis) a 4 (cˇtenı´). Druhou mozˇnostı´ nastavenı´ pra´v je pouzˇitı´ textove´ho za´pisu se syntaxı´: [ugoa][+-=][rwxst]. Prvnı´ cˇa´st urcˇuje, komu chceme dana´ pra´va nastavit (u – uzˇivatel, g – skupina, o – ostatnı´, a – vsˇichni), na´sledujıćı´ cˇa´st specifikuje opera´tor (+ pra´va prˇida´, - pra´va odstranı´, = pra´va nastavı´). A konecˇneˇ poslednı´ cˇa´st specifikuje jednotliva´ pra´va. Vy´znam jednotlivyćh pı´smen je na´sledujıćı´: r – cˇtenı´, w – za´pis, x – prova´deˇnı´, s – setuid/setgid, t – sticky. Nastavenı´ pra´v je typicky podstatne´ u konfiguracˇnıćh souboru˚. Prˇedstavme si, zˇe u´tocˇnı´k pronikne do syste´mu pod identitou uzˇivatele apache. Protozˇe vsˇak uzˇivatel apache nebude mı´t neˇjaka´ dalsˇ´ı pra´va, bude mı´t u´tocˇnı´k omezene´ mozˇnosti. Pokud ale bude mı´t prˇ´ıstup ke konfiguracˇnı´m souboru˚m jinyćh programu˚, ktere´ na serveru beˇzˇ´ı, mu˚zˇe se pokusit do syste´mu proniknout prˇes tyto jine´ programy, bude-li zna´t jejich konfiguraci cˇi naprˇ´ıklad nainstalovanou verzi. Je tedy vhodne´ dodrzˇovat za´sadu, zˇe prˇ´ıstup ke konfiguracˇnı´m souboru˚m k http serveru nesmı´ mı´t uzˇivatel, pod jehozˇ identitou je spusˇteˇn FTP server a naopak. ACL pra´va

prosinec 2003

V neˇkteryćh prˇ´ıpadech nenı´ mozˇne´ pra´va nastavit pomocı´ klasickyćh UNIXovyćh pra´v a je nutne´ pouzˇ´ıt ACL. Bohuzˇel ACL pra´va nejsou soucˇa´stı´ soucˇasne´ stabilnı´ ˇrady ja´dra 2.4.x, a tudı´zˇ se administra´tor musı´ uchy´lit k aplikaci za´plat do zdrojovyćh souboru˚ ja´dra a na´sledneˇ ja´dro rekompilovat. Nasˇteˇstı´ nova´ ja´dra




ˇrady 2.6.x jizˇ ACL pra´va podporujı´ nativneˇ. Nicmeńeˇ v soucˇasne´ dobeˇ jesˇteˇ neexistuje stabilnı´ ja´dro z te´to ˇrady, tudı´zˇ jejich pouzˇitı´ na produkcˇnıćh serverech nenı´ doporucˇovańo.

prosinec 2003



prosinec 2003





9/3.5 ´ LENA ´ SPRA ´ VA SYSTE´MU VZDA

Stejneˇ jako ostatnı´ UNIXove´ operacˇnı´ syste´my je i Linux kompletneˇ spravovatelny´ prˇes sı´t’. K vzda´lene´mu prˇihla´sˇenı´ na stroje drˇ´ıve slouzˇil protokol telnet, dnes nenı´ pouzˇitı´ tohoto protokolu doporucˇovańo. Telnet neobsahuje zˇa´dne´ autentizacˇnı´ ani sˇifrovacı´ mechanismy, kdokoliv na sı´ti mu˚zˇe odposlechnout komunikaci mezi klientem a serverem a dostat se tı´m k heslu˚m. Rˇesˇenı´m je pouzˇitı´ SSH (Secure shell). SSH je protokol, ktery´ zcela nahrazuje telnet, na rozdı´l od neˇj vsˇak vyuzˇ´ıva´ kryptografie, vesˇkera´ komunikace mezi klientem a serverem je sˇifrovańa. SSH zajisˇt’uje te´zˇ oveˇˇrovańı´ identity stroje, na ktery´ se prˇihlasˇujeme. Prˇi prvnı´m prˇihla´sˇenı´ si SSH ulozˇ´ı veˇrejny´ klıćˇ serveru, a pokud dojde ke zmeˇneˇ verˇejne´ho klıćˇe druhe´ strany, SSH okamzˇiteˇ ukoncˇ´ı spojenı´, protozˇe du˚vodem zmeˇny verˇejne´ho klıćˇe mu˚zˇe by´t naprˇ. pokus o u´tok man-in-the-middle. Da´le pak SSH podporuje neˇkolik mozˇnostı´ autentizace uzˇivatele. Kromeˇ prosinec 2003




tradnicˇnı´ mozˇnosti zadańı´ hesla (ktere´ je samozrˇejmeˇ posı´lańo sˇifrovaneˇ) mu˚zˇe by´t klient v protokolu SSH 2 autentizovań pomocı´ RSA/DSA klıćˇe, poprˇ. pomocı´ hostbased autentizace, kdy server nejprve oveˇˇr´ı klıćˇ druhe´ho stroje a pote´ prohleda´ soubory jako /etc/hosts.equiv, ~/.rhosts, ~/.shosts, zda je v nich povoleno prˇihla´sˇenı´ tohoto uzˇivatele z dane´ho stroje (viz man 5 hosts.equiv). Pokud tomu tak je, SSH prˇihla´sı´ uzˇivatele bez nutnosti, aby zada´val heslo. Tato metoda autentizace je pouzˇ´ıvańa velmi zrˇ´ıdka a mı´sto nı´ se pouzˇ´ıva´ autentizace pomocı´ pa´ru RSA/DSA klıćˇu˚. Ta funguje tak, zˇe klient pomocı´ priva´tnı´ho klıćˇe uzˇivatele podepı´sˇe identifika´tor aktua´lnı´ho spojenı´ se serverem a posˇle ho serveru. Server prohleda´ databa´zi uzˇivatelovyćh klıćˇu˚ pouzˇitelnyćh pro tuto autentizaci, a pokud se mu podarˇ´ı pomocı´ neˇktere´ho z nich oveˇˇrit podpis, tak klienta prˇihla´sı´. Pro Linux existuje vıćero implementacı´ protokolu. Nejzna´meˇjsˇ´ı je implementace OpenSSH, kterou najdeme ve veˇtsˇineˇ distribucı´. Obsahuje jak SSH klient, tak server. Podporuje obeˇ existujıćı´ verze protokolu (SSH 1 a SSH 2). OpenSSH bylo vyvinuto v ra´mci projektu OpenBSD, ale je k dispozici pro znacˇne´ mnozˇstvı´ dalsˇ´ıch operacˇnıćh syste´mu˚. Bezpecˇna´ konfigurace sshd

prosinec 2003

Konfiguraci sshd (SSH daemon, server implementujıćı´ SSH protokol) bychom meˇli veˇnovat prˇi zabezpecˇovańı´ serveru zvy´sˇenou pozornost, jelikozˇ sshd beˇzˇ´ı z cˇa´sti pod uzˇivatelem root a pro veˇtsˇinu serveru˚ je jeho prˇ´ıtomnost nutnostı´ – ma´loktere´ servery jsou dnes spravovańy pouze loka´lneˇ. Navıć bylo v minulosti v sshd objeveno neˇkolik kritickyćh bezpecˇnostnıćh chyb, neˇktere´ z nich mohl u´tocˇnı´k dokonce vyuzˇ´ıt pro zı´skańı´ pra´v uzˇivatele root na dane´m stroji.




Pomeˇrneˇ osveˇdcˇenou metodou zabezpecˇenı´ je zmeˇna portu, na ktere´m sshd posloucha´. Volı´ se na´hodny´ neprivilegovany´ port (tzn. vysˇsˇ´ı nezˇ 1024). Tı´m se velice zvy´sˇ´ı sˇance, zˇe prˇ´ıpadny´ u´tocˇnı´k neobjevı´ na dane´m stroji spusˇteˇne´ sshd. Pro jeho objevenı´ by prˇ´ıpadny´ hacker musel oscannovat vsˇechny porty na dane´m stroji (kteryćh je 216 ), cozˇ by pravdeˇpodobneˇ bylo zachyceno IDS. Dalsˇ´ı cˇasto prova´deˇnou technikou je omezenı´ prˇ´ıstupu na sshd pomocı´ firewallu. Typicke´ je povolenı´ prˇ´ıstupu jen z neˇkteryćh (du˚veˇryhodnyćh) serveru˚. Pozornost veˇnujme te´zˇ volbeˇ UsePrivilegeSeparation v sshd config, ta by vzˇdy meˇla by´t nastavena na hodnotu yes, cozˇ zpu˚sobı´, zˇe po prˇihla´sˇenı´ uzˇivatele sshd zahodı´ rootovska´ pra´va a proces da´le pracuje pod uid prˇihla´sˇene´ho uzˇivatele. Toto nastavenı´ vy´razneˇ zvysˇuje bezpecˇnost cele´ho sshd. Tato forma autentizace je vhodna´ zejmeńa v prˇ´ıpadeˇ, zˇe nechceme zada´vat prˇi kazˇde´m prˇihla´sˇenı´ heslo, cozˇ je uzˇitecˇne´ zejmeńa prˇi pouzˇitı´ ssh ve skriptech, ktere´ potom nemusejı´ by´t interaktivnı´. Prvnı´m krokem je vygenerovańı´ pa´ru klıćˇu˚. Slouzˇ´ı k tomu program ssh-keygen -t algoritmus. Algoritmem mu˚zˇe by´t bud’ rsa nebo dsa, eventua´lneˇ mu˚zˇeme jesˇteˇ specifikovat hodnotu rsa, cozˇ zpu˚sobı´ vygenerovańı´ klıćˇe pro SSH1 RSA autentizaci.

Pouzˇitı´ autentizace pomocı´ pa´ru RSA/DSA klıćˇu˚ v OpenSSH

Vygenerovany´ verˇejny´ klıćˇ pro SSH 2 se ulozˇ´ı do souboru ~/.ssh/id (rsa|dsa).pub, priva´tnı´ klıćˇ pak do ~/.ssh/id (rsa|dsa).pub. Verˇejny´ klıćˇ pote´ nakopı´rujeme na cı´lovy´ stroj do souboru ~/.ssh/authorized keys (cˇi jine´ho souboru, pokud je standardnı´ jmeńo zmeˇneˇno v sshd config

prosinec 2003




pomocı´ volby AuthorizedKeysFile) a zkusı´me se prˇihla´sit. V prˇ´ıpadeˇ, zˇe nebudete automaticky prˇihla´sˇeni, zkontrolujte prˇ´ıstupova´ pra´va k sve´mu domovske´mu adresa´ˇri. Z bezpecˇnostnıćh du˚vodu˚ funguje tato autentizace jen v prˇ´ıpadeˇ, zˇe do neˇj mu˚zˇete zapisovat jen vy. Standard IPsec

IPsec je standard rozsˇirˇujıćı´ IP protokol o autentizaci a sˇifrovańı´. Sesta´va´ se z neˇkolika protokolu˚ implementovanyćh nad protokolem IP. V praxi se nejcˇasteˇji pouzˇ´ıva´ protokol ESP (Encapsulating Security Payload) pouzˇ´ıvany´ k sˇifrovańı´ dat i zajisˇteˇnı´ integrity prˇena´sˇenyćh dat. Meńeˇ pouzˇ´ıvany´ je protokol AH (Authentication Header), ktery´ zajisˇt’uje pouze autentizaci prˇena´sˇenyćh paketu˚. IPsec mu˚zˇe fungovat ve dvou rezˇimech – transportnı´m a tunelovacı´m. Transportnı´ mo´d se pouzˇ´ıva´ prˇi komunikaci dvou stroju˚, naproti tomu v tunelovacı´m mo´du se prˇena´sˇ´ı jako data ESP/AH paketu cely´ zdrojovy´ IP paket vcˇetneˇ hlavicˇek. Pomocı´ tunelovacı´ho mo´du je mozˇne´ vytvorˇit bezpecˇnou VPN mezi dveˇma sı´teˇmi prˇes Internet. Pouzˇitı´ IPsec je pro aplikace transparentnı´, vsˇe je implementovańo na u´rovni vrstvy IP v ja´drˇe operacˇnı´ho syste´mu. V tunelovacı´m mo´du je IPsec te´zˇ zcela transparentnı´ pro pocˇ´ıtacˇe na subsı´tıćh, mezi nimizˇ je tunel vytvorˇen. Dalsˇ´ı nespornou vy´hodou IPsec je jeho rozsˇ´ıˇrenost – oproti jiny´m podobny´m ˇresˇenı´m je IPsec standardizovań a je k dispozici na veˇtsˇineˇ pouzˇ´ıvanyćh platforem. Kromeˇ teˇchto dvou protokolu˚ se pouzˇ´ıva´ jesˇteˇ protokol IKE, jehozˇ u´kolem je autentizace obou stran a

prosinec 2003




na´sledne´ vytvorˇenı´ bezpecˇnostnıćh asociacı´. Bezpecˇnostnı´ asociace (SA, Security Associations) popisujı´ jednosmeˇrnou relaci mezi dveˇma stroji. Jednotlive´ asociace jsou definovańy zdrojovou a cı´lovou IP adresou, unika´tnı´m ID nazy´vany´m SPI a bezpecˇnostnı´m protokolem (AH nebo ESP). ´ kolem IKE je te´zˇ autentizace obou stran. AutentizaU ci je mozˇne´ prove´st neˇkolika zpu˚soby, nejjednodusˇsˇ´ı je tzv. PSK (pre-shared key) autentizace, prˇi nı´zˇ obeˇ strany sdı´lı´ urcˇeny´ klıćˇ, ktery´ se pouzˇije spolu s daty paketu na spocˇ´ıtańı´ hashovacı´ hodnoty, kterou stejny´m zpu˚sobem druha´ strana oveˇˇr´ı. Cˇasteˇjsˇ´ı je vsˇak autentizace pomocı´ pa´ru˚ certifika´tu˚, ktera´ vyuzˇ´ıva´ mozˇnosti asymetricke´ kryptografie. IPsec nenı´ v Linuxu standardneˇ k dispozici. Pro jeho instalaci se musı´me uchy´lit k aplikovańı´ za´plat do ja´dra. Nejrozsˇ´ıˇreneˇjsˇ´ı implementacı´ IPsec pro ja´dra 2.4.x a starsˇ´ı 2.2.x je FreeS/WAN. Krom FreeS/WAN existuje jesˇteˇ tzv. SuperFreeS/WAN, ktery´ se lisˇ´ı prˇ´ıtomnosti neˇkolika za´plat, ktere´ nebyly prˇidańy do oficia´lnı´ vy´vojove´ veˇtve FreeS/WAN. Asi nejdu˚lezˇiteˇjsˇ´ı za´platou, kterou Super FreeS/WAN obsahuje je podpora X.509 certifika´tu˚ prˇi autentizaci v IKE.

Implementace IPsec v Linuxu

V ja´drech 2.5.x a 2.6.x jizˇ nalezneme nativnı´ implementaci, ktera´ pouzˇ´ıva´ konfiguracˇnı´ na´stroje (a IKE daemon racoon) z projektu KAME. Konfigurace IPsec na strojıćh s teˇmito ja´dry je tudı´zˇ hodneˇ podobna´ te´ v Open/FreeBSD (cˇi dalsˇ´ıch operacˇnıćh syste´mech, pro neˇzˇ existujı´ KAME patche).

prosinec 2003



prosinec 2003





9/3.6 FIREWALL

Firewall je sluzˇba, ktera´ na u´rovni paketovyćh spojenı´ filtruje provoz na sı´t’ovyćh rozhranıćh (kartaćh) pocˇ´ıtacˇe. Jeho u´kolem je definovat prˇ´ıstup k jednotlivy´m pocˇ´ıtacˇu˚m a sluzˇba´m na nich beˇzˇ´ıcıćh. Firewall tedy nekontroluje obsah jednotlivyćh paketu˚, ale vlastnosti paketu jako zdrojova´ adresa, cı´lova´ adresa, zdrojovy´ port, cı´lovy´ port atp. Firewall mu˚zˇe by´t da´le stavovy´, cozˇ znamena´, zˇe pozna´, ktere´ pakety patrˇ´ı ke ktere´mu konkre´tnı´mu spojenı´. Firewall tak naprˇ´ıklad mu˚zˇe ukoncˇit cˇi zarˇ´ıdit zpomalenı´ spojenı´, ktere´ trva´ naprˇ´ıklad de´le nezˇ 5 minut nebo ktery´m proteklo vıće nezˇ urcˇite´ mnozˇstvı´ dat.

Firewall

Obecneˇ platı´, zˇe bychom meˇli povolovat jen sluzˇby, ktere´ fungovat majı´, a ostatnı´ sluzˇby zaka´zat. Naprˇ´ıklad pokud se za firewallem nacha´zı´ SMTP server, tak bychom meˇli povolit jen SMTP spojenı´ na onen server a da´le SMTP spojenı´, ktera´ onen server sa´m zahajuje. Obvyklou chybou administra´toru˚ by´va´, zˇe smeˇr ze prosinec 2003




SMTP serveru neomezujı´, protozˇe veˇˇr´ı zabezpecˇenı´ serveru. To je chyba. Pokud u´tocˇnı´k server napadne, tak bude moci prˇi ma´lo restriktivnı´m nastavenı´ firewallu navazovat spojenı´ s ostatnı´mi svy´mi servery na jine´m nezˇ SMTP portu. Pokud vsˇak bude firewall restriktivnı´, bude muset u´tocˇnı´k komunikovat po portech urcˇenyćh pro SMTP protokol. To vsˇak pozna´me, protozˇe na´m prˇestane chodit posˇta, nebo se alesponˇ zacˇne projevovat nestandardneˇ. A tak zjistı´me, zˇe se na´m na SMTP serveru neˇco deˇje. Spra´vna´ konfigurace firewallu je pro zabezpecˇenı´ syste´mu pomeˇrneˇ du˚lezˇita´. V noveˇjsˇ´ıch ja´drech (rˇady 2.4.x a vysˇsˇ´ı) nalezneme velmi propracovany´ stavovy´ firewall zvany´ netfilter. Firewall nastavujeme pomocı´ utility iptables. V netfilteru existuje neˇkolik tabulek, kazˇda´ tabulka obsahuje seznamy (rˇeteˇzce) jednotlivyćh pravidel. Seznam tabulek, jezˇ budou k dispozici, je za´visly´ na konfiguraci ja´dra (zda byly zakompilovańy, poprˇ. zkompilovańy jako moduly). Prˇi zpracovańı´ paketu se procha´zejı´ jednotliva´ pravidla v dane´m ˇreteˇzci pravidel, pokud dane´ pravidlo platı´, provede se u neˇj specifikovana´ akce, cozˇ mu˚zˇe by´t bud’ skok do jine´ho ˇreteˇzce nebo prˇedańı´ paketu prˇ´ıslusˇne´mu modulu netfilteru (pro u´plnost, neˇktere´ z akcı´ jsou zpracova´vańy prˇ´ımo v netfilteru). Nejbeˇzˇneˇjsˇ´ı pouzˇ´ıvanou tabulkou je filter. Tato tabulka se pouzˇije, pokud explicitneˇ nespecifikujeme jinou tabulku parametrem -t u iptables. Tabulka slouzˇ´ı prˇedevsˇ´ım k filtrovańı´ paketu˚. V te´to tabulce jsou definovańy na´sledujıćı´ standardnı´ ˇreteˇzce pravidel: INPUT příchozí pakety OUTPUT lokálně generované pakety prosinec 2003




FORWARD pakety routované přes tento stroj. Dalsˇ´ı ˇreteˇzce si mu˚zˇeme definovat pomocı´ volby -N u iptables, pakety do nich budou zarˇazovańy v prˇ´ıpadeˇ, zˇe jejich identifika´tor specifikujeme jako akci, ktera´ se ma´ prove´st prˇi platnosti pra´veˇ zpracovane´ho pravidla. Krom standardnı´ tabulky filter existujı´ dalsˇ´ı tabulky – prvnı´ z nich, tabulka mangle, se pouzˇ´ıva´ prˇedevsˇ´ım ve spojenı´ s QoS na oznacˇovańı´ a pozdeˇjsˇ´ı klasifikaci paketu˚ pomocı´ filtru˚ v QoS. Do poslednı´ tabulky, nat, se zarˇazujı´ pakety vytva´ˇrejıćı´ nove´ spojenı´. Jak jizˇ na´zev napovı´da´, tabulka se pouzˇ´ıva´ pro NAT, tedy pro prˇeklad adres. Syntaxe pro prˇidańı´ pravidla je

Definice pravidel firewallu

iptables [-t tabulka] -A/-I řetězec volby -j akce Pokud nespecifikujeme tabulku parametrem -t, pouzˇije se tabulka filter. Jak -A, tak -I prˇida´vajı´ pravidlo do dane´ho ˇreteˇzce pravidel. Lisˇ´ı se umı´steˇnı´m nove´ho pravidla. -A prˇida´va´ pravidlo vzˇdy na konec rˇeteˇzce, kdezˇto -I umozˇnˇuje urcˇit pozici, na kterou se pravidlo vlozˇ´ı, dalsˇ´ım parametrem. Pokud za -I nena´sleduje cˇ´ıslo, je pravidlo vlozˇeno na prvnı´ pozici v rˇeteˇzci. Akcı´ mu˚zˇe by´t bud’ identifika´tor ˇreteˇzce pravidla nebo neˇktera´ z akcı´ implementovańa v netfilteru (poprˇ. implementovana´ jako modul). Uvedeme si neˇktere´ nejdu˚lezˇiteˇjsˇ´ı volby pro kategorizaci paketu. Pokud vsˇechny uvedene´ volby odpovı´dajı´ pra´veˇ zpracovane´mu paketu, je provedena prˇ´ıslusˇna´ akce.

Za´kladnı´ volby pro kategorizaci paketu˚

-p protokol prosinec 2003




IP paket ma´ v hlavicˇce protokol nastaveny´ na hodnotu protokol. Mu˚zˇeme specifikovat bud’ cˇ´ıselne´ vyja´drˇenı´ nebo identifika´tor protokolu (naprˇ. tcp, udp, icmp, . . . ). -s adresa/maska IP paket ma´ nastavenou zdrojovou IP na adresa, nebo lezˇ´ı na dane´ subsı´ti. -d adresa/maska Tote´zˇ, jen pro cı´lovou IP adresu -i iface Sı´t’ove´ rozhranı´, z ktere´ho byl paket prˇijat. Volba je platna´ jen v ˇreteˇzcıćh INPUT, FORWARD a PREROUTING. -o iface Sı´t’ove´ rozhranı´, na ktere´ bude paket poslań. Volba je platna´ jen v ˇreteˇzcıćh OUTPUT, FORWARD a POSTROUTING. Tı´m nejsou mozˇnosti iptables pro kategorizaci paketu samozrˇejmeˇ zdaleka vycˇerpańy. Dalsˇ´ı volby jsou prˇ´ıstupne´ pomocı´ modulu˚. Modul mu˚zˇe by´t natazˇen bud’ implicitneˇ uvedenı´m protokolu pomocı´ volby -p nebo explicitneˇ pouzˇitı´m volby -m modul. Volby pro protokol TCP

--source-port [!] port1:port2 TCP paket ma´ zdrojovy´ port v intervalu port1 azˇ port2. Mı´sto intervalu mu˚zˇeme specifikovat jen jeden port. Vykrˇicˇnı´k prˇed specifikacı´ portu zpu˚sobı´ negaci tohoto pravidla. --destination-port [!] port1:port2 Tote´zˇ, jen pro cı´lovy´ TCP port.

prosinec 2003




--tcp-flags [!] flag1,flag2,... f1,f2,... Prvnı´ parametr urcˇuje, ktere´ TCP prˇ´ıznaky analyzovat a druhy´ parametr urcˇuje, ktere´ prˇ´ıznaky musı´ by´t nastaveny. [!] --syn TCP paket ma´ nastaveny´ SYN prˇ´ıznak a nenastaveny´ ACK a RST prˇ´ıznak. Pakety s takovy´mi prˇ´ıznaky se pouzˇ´ıvajı´ v prvnı´ fa´zi nava´zańı´ TCP spojenı´. --source-port port1:port2

Volby pro protokol UDP

Platı´, pokud se zdrojovy´ port nacha´zı´ v intervalu port1–port2. Poprˇ. mu˚zˇeme specifikovat pouze jeden port. --destination-port port1:port2 Tote´zˇ pro cı´lovy´ UDP port. Velke´ mnozˇstvı´ dalsˇ´ıch voleb pro kategorizaci paketu˚ je prˇida´vańo jednotlivy´mi moduly. Popis standardnıćh voleb naleznete v man 8 iptables, poprˇ. na www.netfilter.org. Netfilter nenı´ jen jednoduchy´ paketovy´ filtr, ale plnohodnotny´ stavovy´ firewall. Pokud chceme paket klasifikovat v sˇirsˇ´ım kontextu, vyuzˇijeme extenzi state z netfilteru. Ta na´m prˇida´ volbu --state, ktere´ mu˚zˇeme jako prvnı´ parametr specifikovat vsˇechny stavy, v kteryćh se mu˚zˇe spojenı´ asociovane´ s aktua´lneˇ zpracovany´m paketem nacha´zet. Mozˇne´ stavy jsou:

Stavovy´ firewall

INVALID – paket nenı´ asociovań s zˇa´dny´m spojenı´m. NEW – paket se snazˇ´ı o nava´zańı´ nove´ho spojenı´. ESTABLISHED – paket je soucˇa´stı´ jizˇ vytvorˇene´ho spojenı´. prosinec 2003




RELATED – paket se snazˇ´ı o nava´zańı´ nove´ho spojenı´, ktere´ je va´zane´ na neˇjake´ existujıćı´ (naprˇ. poslańı´ ICMP paketu). Akce prova´deˇne´ s pakety

V netfilteru jsou definovańy tyto za´kladnı´ akce s pakety: ACCEPT – paket bude akceptovań. DROP – paket bude zahozen. RETURN – ukoncˇ´ı zpracovańı´ tohoto ˇreteˇzce pravidel. Dalsˇ´ı akce jsou definovańy moduly, viz man 8 iptables

Bezpecˇna´ konfigurace firewallu

Obecneˇ platı´, zˇe na kazˇde´m serveru by nemeˇla by´t pusˇteˇna zˇa´dna´ nepouzˇ´ıvana´ sluzˇba. Podobne´ pravidlo lze prˇene´st i do kontextu firewallu, z Internetu by nemeˇla by´t prˇ´ıstupna´ zˇa´dna´ sluzˇba, ktera´ z neˇj nebude pouzˇ´ıvańa. Poprˇ´ıpadeˇ je vhodne´ neˇktere´ sluzˇby povolit jen z IP, z kteryćh budou vyuzˇ´ıvańy. Pokud chceme zaka´zat neˇjakou sluzˇbu, meˇli bychom na to pouzˇ´ıt akci DROP, ktera´ paket kompletneˇ zahodı´. Lepsˇ´ım ˇresˇenı´m u protokolu TCP mu˚zˇe by´t pouzˇitı´ extenze REJECT doplneˇne´ parametrem --reject-with tcp-reset. To zpu˚sobı´, zˇe prˇi prˇipojenı´ na dany´ port se vra´tı´ RST paket, tudı´zˇ z pohledu z venku je chovańı´ analogicke´ se situacı´, kdy by zˇa´dny´ firewall nainstalovany´ nebyl, ale na dane´m portu zˇa´dny´ daemon neposlouchal. Doporucˇuje se te´zˇ vyuzˇ´ıvat extenze STATE (zvla´sˇteˇ u protokolu TCP), prˇi skenovańı´ TCP portu˚ (a vzda´lene´ identifikaci TCP/IP implementace) se cˇasto pouzˇ´ıvajı´ pakety s abnorma´lnı´mi prˇ´ıznaky, tudı´zˇ nenı´ od veˇci TCP pakety ve stavu INVALID zahazovat.

prosinec 2003


cˇa´st 9, dı´l 3, kapitola 6.1, str. 1


9/3.6.1 ˇ ÍKLAD SKRIPTU KONFIGURACE PR FIREWALLU PRO JEDNODUCHE´ FIREMNI´ POUZˇITI´ Uka´zkovy´ skript se spousˇtı´ s parametrem start pro nastavenı´ firewallu. Pokud skript spustı´me parametrem stop, filtrovacı´ sluzˇby ja´dra se nastavı´ na hodnoty, ktere´ zˇa´dny´m zpu˚sobem neomezujı´ pru˚chod paketu˚ prˇes dany´ pocˇ´ıtacˇ. Prˇedstavme si, zˇe ma´me firemnı´ router, ktery´ je jednı´m sı´t’ovy´m rozhranı´m prˇipojen do Inetrnetu (ma´ naprˇ´ıklad od poskytovatele prˇideˇlenu verˇejnou adresu 164.218.1.10) a druhy´m sı´t’ovy´m rozhranı´m je prˇipojen do vnitrˇnı´ firemnı´ sı´teˇ. Tato sı´t’ ma´ neverˇejnou adresu 192.168.0.0/24 a na´sˇ router ma´ adresu 192.168.0.1. Na nasˇem routeru pak provozujeme pro ućˇely pocˇ´ıtacˇu˚ z vnitrˇnı´ sı´teˇ i z internetu posˇtovnı´ server, domeńovy´ server, webovy´ server, pop3 server. Da´le pak pro vybrane´ za´kaznı´ky ssh server pro vzda´leny´ prˇ´ıstup a ftp

srpen 2004




server. Nakonec pouze pro pocˇ´ıtacˇe ve vnitrˇnı´ sı´ti provozujeme proxy server a dhcp server. Pozˇadujeme, aby uzˇivatele´ mohli na Interentu pouzˇ´ıvat webove´ sluzˇby a ftp sluzˇby, avsˇak pouze prˇes proxy server, ktery´ ma´me za tı´mto ućˇelem na routeru nakonfigurovany´. Zˇa´dny´ jiny´ prˇ´ıstup uzˇivatele´ do internetu mı´t nebudou. Porˇadujeme navıć, aby z vnitrˇnı´ firemnı´ sı´teˇ nemeˇl na internet, a tudı´zˇ na sluzˇbu proxy serveru, prˇ´ıstup uzˇivatel s pocˇ´ıtacˇem 192.168.0.28. Da´le pozˇadujeme, aby na na´sˇ server meˇla prˇ´ıstup sluzˇbou ssh externı´ firma z adresy 123.45.67.8 (naprˇ´ıklad na´m spravuje neˇjakou beˇzˇ´ıcı´ aplikaci) a da´le aby na na´sˇ server meˇla prˇ´ıstup na sluzˇbu ftp tata´zˇ firma a da´le jina´ firma ze serveru 123.45.67.9 (naprˇ´ıklad za ućˇelem spra´vy obsahu webovyćh strańek), a to sluzˇbou ftp. Vy´sˇe uvedene´ pozˇadavky jsou skutecˇneˇ jednoduche´ a na jejich splneˇnı´ na´m bude stacˇit konfigurace pravidel v tabulce filter. Na ˇra´dcıćh 3 azˇ 13 (viz uka´zku skriptu s cˇ´ıslovany´mi ˇra´dky na konci kapitoly) si nastavı´me neˇktere´ promeˇnne´: 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




Je to prakticke´ z neˇkolika du˚vodu˚. Naprˇ´ıklad pokud bychom zmeˇnili adresaci vnitrˇnı´ sı´teˇ, tak tuto zmeˇnu stacˇ´ı prove´st pouze v definici one´ promeˇnne´ a nikoliv na vsˇech mı´stech ve skriptu. Take´ jmeńo sauvignon na´m a nebo neˇkomu, kdo bude skript upravovat, ˇrekneˇ zcela jisteˇ vıće, nezˇ jen ip adresa 123.45.67.8. . . Na ˇra´dcıćh 21, 22 a 23 smazˇeme vsˇechna pravidla a vsˇechny ˇreteˇzce v tabulce filter, vynulujeme pocˇ´ıtadla, ktera´ pocˇ´ıtajı´, kolik dany´m pravidlem prosˇlo paketu˚ a kolik dat. Je to z toho du˚vodu, zˇe na routeru mohla by´t konfigurace prˇedchozı´ho firewallu. V podstateˇ na´m tato trˇi pravidla zajistı´, zˇe zacˇneme v tabulce filter „od zelene´ho stolu“. Na ˇra´dcıćh 26, 27 a 28 pak nastavı´me politiku pro ˇreteˇzce INPUT, FORWARD a OUTPUT na DROP, cozˇ znamena´, zˇe pokud prˇ´ıslusˇny´ paket nevyhovı´ sve´mu prˇ´ıslusˇne´mu pravidlu (nebo pravidlu˚m), zahodı´me jej a zdroji tohoto paketu to nijak neozna´mı´me. Zopakuji, zˇe neuvedenı´ parametru -t filter u prˇ´ıkazu iptables znamena´ tote´zˇ, jako bychom jej uvedli. Tedy zˇe pracujeme s tabulkou filter. Da´le tedy pracujeme pouze s tabulkou filter a parametr -t neuva´dı´me. Mı´sta, na ktera´ by se meˇl podı´vat kazˇdy´, kdo studuje konfiguraci firewallu, jsou pra´veˇ ta, kde zacˇ´ına´ ˇreteˇzec INPUT (rˇa´dek 75), ˇreteˇzec FORWARD (rˇa´dek 86) a ˇreteˇzec OUTPUT (rˇa´dek 92). Jsou to totizˇ ˇretezce, kde zacˇ´ına´ pru˚chod paketu firewallem. Pro zopakovańı´ uvedu, zˇe pravidly rˇeteˇzce INPUT v tabulce filter procha´zı´ takove´ pakety, jejichzˇ cı´lova´ adresa je adresou neˇktere´ho ze sı´t’ovyćh rozhranı´ samotne´ho routeru. Je nutne´ zdu˚raznit, zˇe paket mu˚zˇe

ˇ eteˇzec INPUT R

srpen 2004




mı´t v tabulce filter jinou cı´lovou (ale take´ zdrojovou) adresu, nezˇ jakou ji mu˚zˇe mı´t v tabulkaćh mangle cˇi nat. Prˇestozˇe v nasˇ´ı konfiguraci pouzˇijeme jen tabulku filter, je nutne´ na to pamatovat, a proto to budu vzˇdy zdu˚ranˇovat. V dalsˇ´ıch prˇ´ıkladech jednotlivyćh konfiguracı´ to bude zrˇejme´. Na ˇra´dku 75 ma´me definici, ktere´ vyhovı´ vsˇechny pakety, jezˇ budou procha´zet tı´mto pravidlem. Akce tohoto pravidla na´m narˇizuje procha´zet ˇretezec spoof. Protozˇe Netfilter zna´ implicitneˇ jen ˇreteˇzce INPUT, FORWARD a OUTPUT (sta´le hovorˇ´ıme pouze o tabulce filter), musı´ by´t v definici firewallu neˇkde drˇ´ıve ˇreteˇzec spoof nadefinovań. Tı´m mı´stem je ˇra´dek 35 a tam se nynı´ prˇesunuje nasˇe pozornost. Na ˇra´dku 31 zadefinujeme ˇretezec spoof a na ˇra´dcıćh 37 azˇ 46 pak definujeme pravidla v tomto rˇeteˇzci. Tato sada pravidel na´m ma´ zajistit korektnost paketu˚, ktere´ k na´m prˇicha´zejı´ z jednotlivyćh sı´t’ovyćh rozhranı´. Potencia´lnı´ u´tocˇnı´k na´m naprˇ´ıklad mu˚zˇe podstrcˇit paket z internetu, jehozˇ zdrojova´ adresa ale bude z nasˇ´ı vnitrˇnı´ sı´teˇ. Nebudu se v tuto chvı´li pozastavovat nad tı´m, procˇ by takto jednal, ale budu popisovat zpu˚sob, jak se proti takove´muto chovańı´ zabezpecˇit. Dalsˇ´ım smyslem pravidel v rˇeteˇzci spoof je zaka´zat obecneˇ routovańı´ adres z neverˇejnyćh sı´tı´. Tyto sı´teˇ jsou trojı´ho druhu: 10.0.0.0/8, 172.16.0.0/12 a ´ kolem pravidel v ˇreteˇzci spoof 192.168.0.0/16. U je vsˇechny korektnı´ pakety vra´tit zpeˇt ke zpracovańı´ na dalsˇ´ı pravidlo v ˇreteˇzci, ze ktere´ho sem skocˇily. V nasˇem prˇ´ıpadeˇ to bude zpeˇt do ˇreteˇzce INPUT. eth1. Nynı´ popı´sˇeme samotna´ pravidla v ˇreteˇzci spoof. Na ˇra´dku 36 povolı´me vesˇkery´ provoz na zarˇ´ızenı´ loopback. Je to virtua´lnı´ rozhranı´, ktere´ pouzˇ´ıva´ operacˇnı´ srpen 2004




syste´m v podstateˇ pro sve´ vnitrˇnı´ potrˇeby. Jeho adresa je obvykle 127.0.0.1. Omezovańı´ na tomto rozhranı´ ma´ neˇkdy smysl, nicmeńeˇ v nasˇem prˇ´ıpadeˇ jej omezovat nepotrˇebujeme. Na ˇra´dku 37 pak vidı´me definici, ktere´ vyhovı´ vsˇechny pakety, jezˇ prˇisˇly na router z jeho vnitrˇnı´ho sı´t’ove´ho rozhranı´ (v prˇedcha´zejıćh definicıćh je to sı´t’ove´ rozhranı´ oznacˇene´ jako eth1) a jejichzˇ zdrojova´ adresa je z rozsahu adres pro vnitrˇnı´ sı´t’. Takove´to pakety jizˇ nejsou da´le zpracova´vańy v ˇreteˇzci spoof a jsou vraćeny pro zpracovańı´ v ˇreteˇzci INPUT. Na ˇra´dku 38 pak uvedene´ definici vyhovı´ vsˇechny pakety, jejichzˇ zdrojova´ adresa je z rozsahu vnitrˇnı´ sı´teˇ. Budou to pra´veˇ ty pakety, ktere´ k na´m dorazily z jine´ho nezˇ vnitrˇnı´ho rozhranı´. Tyto pakety jsou pro na´s potencia´lneˇ nebezpecˇne´. Akce v tomto pravidle ˇr´ıka´, zˇe ma´me skocˇit do ˇretezce spoofdrop. Spoofdrop je opeˇt ˇreteˇzec, ktery´ nenı´ implicitneˇ definovań. Meˇli bychom tudı´zˇ hledat jeho definici ve firewallu, a to opeˇt prˇed tı´mto pouzˇitı´m. Definici pravidla spoofdrop najdeme na ˇra´dku 30. V ˇreteˇzci spoofdrop pak ma´me na ˇra´dku 31 akci, ktera´ zpu˚sobı´ zalogovańı´ informacı´ o takove´mto paketu, a na ˇra´dku 32 pak takovy´ paket zahodı´me. Vra´tı´me se zpeˇt do ˇreteˇzce spoof a na ˇra´dcıćh 39 azˇ 41 pak vidı´me zpracovańı´ paketu˚, ktere´ jsou z neverˇejne´ho rozsahu. Na rˇa´dcıćh 42 a 43 pak zpracova´va´me pakety, ktere´ by meˇly prˇijı´t z virtua´lnı´ho rozhranı´ loopback, nicmeńeˇ dostaly se k na´m odjinud, protozˇe nevyhoveˇly pravidlu na ˇra´dku 36. Ze zarˇ´ızenı´ loopback na´m v obvyklyćh prˇ´ıpadech chodı´ pakety, jejichzˇ zdrojova´ nebo cı´lova´ adresa je pra´veˇ 127.0.0.1. srpen 2004




Na ˇra´dku 44 pak vracı´me do ˇreteˇzce INPUT zpracovańı´ vsˇech paketu˚, ktere´ prˇicha´zejı´ z vneˇjsˇ´ıho sı´t’ove´ho rozhranı´ (tedy z internetu) a nezahodili jsme je v prˇedcha´zejıćıćh pravidlech. V definici pouzˇ´ıva´me pouze kontrolu z vneˇjsˇ´ıcho rozhranı´, protozˇe nemu˚zˇeme specifikovat, jakou zdrojovou adresu majı´ takove´to pakety. Na ˇra´dku 45 pak pravidlo charakterizuje pakety, ktere´ souvisı´ se sluzˇbou DHCP. Takovy´to paket ma´ zdrojovou adresu 0.0.0.0 a cı´lovou adresu 255.255.255.255. Navıć z prˇedchozı´ho je zrˇejme´, zˇe pokud se paket ve vyhodnocovańı´ dostal azˇ sem, mohl prˇijı´t jedineˇ z vnitrˇnı´ho sı´t’ove´ho rozhranı´. Vra´tı´me jej tedy ke zpracovańı´ v ˇreteˇzci INPUT. Vlastnosti Netfilteru jsou takove´, zˇe pokud prˇi zpracovańı´ paketu v aktua´lnı´m ˇreteˇzci nevyhovı´ zˇa´dne´ pravidlo, vracı´ se paket ke zpracovańı´ do ˇreteˇzce, ze ktere´ho skocˇil do pra´veˇ zpracova´vane´ho. V tuto chvı´li je tedy aktua´lnı´m zpracova´vany´m ˇreteˇzcem spoof a nadrˇazeny´ ˇreteˇzec je INPUT. Pokud je vsˇak aktua´lnı´m ˇreteˇzcem INPUT, FORWARD nebo OUTPUT, pouzˇije se pro zpracovańı´ paketu nastavena´ politika v pravidlech 26, 27 cˇi 28. Dobry´m zvykem je nespole´hat se na takove´to chovańı´ a radeˇji v konfiguracˇnı´m skriptu uve´st jako poslednı´ pravidlo s akcı´ RETURN a tı´m ˇr´ıci, zˇe chceme skutecˇneˇ paket da´le zpracova´vat nebo takovy´ paket zahodit akcı´ DROP a nebo jej vra´tit akcı´ REJECT. Prˇ´ıpadneˇ jesˇteˇ prˇed teˇmito akcemi paket zalogovat. To v podstateˇ deˇla´me na ˇra´dku 46. Skocˇ´ıme do ˇreteˇzce spoofdrop, na ˇra´dku 31 jej zalogujeme a na ˇra´dku 32 zahodı´me. Ra´d bych znova zdu˚raznil, zˇe tı´m da´va´me zcela jasneˇ najevo, zˇe jsme na nic nezapomneˇli a zˇe jsme v rˇeteˇzci srpen 2004




skutecˇneˇ mysleli na vsˇechny pakety, ktere´ jı´m mohou procha´zet. Ma´me tedy za sebou u´speˇsˇneˇ ˇreteˇzec spoof a vracı´me se do ˇreteˇzce INPUT na ˇra´dek 76. Na neˇm akceptujeme vsˇechny pakety, ktere´ jizˇ souvisejı´ s existujıćı´mi spojenı´mi patrˇ´ıcı´mi nasˇemu routeru, nebo takove´ pakety, ktere´ sice patrˇ´ı k nove´mu spojenı´, avsˇak to souvisı´ jizˇ s neˇjaky´m nava´zany´m. U volby ESTABLISHED se typicky jedna´ naprˇ´ıklad o odpoveˇdi na dotazy, ktere´ vnesl na´sˇ DNS server. U volby RELATED pak teˇch, ktere´ se mohou ty´kat nasˇeho ftp serveru. Zejmeńa u druhe´ skupiny paketu˚ je tato volba podstatna´, protozˇe po nava´zańı´ spojenı´ na porty, ktere´ ma´me nı´zˇe povoleny, mu˚zˇe komunikace probı´hat po jinyćh portech, na kteryćh se domluvı´ jednotlive´ aplikace, a my bychom pak museli v konfiguraci firewallu tyto porty rucˇneˇ povolovat. Protozˇe je nemusı´me zna´t doprˇedu, museli bychom povolovat urcˇity´ rozsah a to mu˚zˇe by´t nebezpecˇne´. Tı´m, zˇe mu˚zˇeme uve´st volbu --state, necha´me celou rezˇii na ja´drˇe syste´mu. To je take´ du˚vod, procˇ je Netfilter tzv. stavovy´m firewallem. Na ˇra´dku 77 pak zalogujeme vsˇechny pakety, ktere´ navazujı´ neˇjaka´ spojenı´ na protokolu TCP. Pak mu˚zˇeme dohledat, kdo z vnitrˇnı´ sı´teˇ cˇi vneˇjsˇ´ıho rozhranı´ s na´mi navazoval neˇjake´ spojenı´. Na ˇra´dku 78 povolujeme ICMP protokol. ˇ a´dku 79 pak vyhovı´ vsˇechny pakety, ktere´ patrˇ´ı do R rozsahu adres vnitrˇnı´ sı´teˇ (a dı´ky prˇedcha´zejıćı´mu pru˚chodu ˇreteˇzcem spoof jsme si tı´m jisti) a budeme je da´le zpracova´vat v ˇreteˇzci int-fw. Ten popı´sˇi pozdeˇji.

srpen 2004




ˇ a´dku 80 pak vyhovı´ vsˇechny pakety, ktere´ prˇicha´zejı´ R z vneˇjsˇ´ıho sı´t’ove´ho rozhranı´, a budeme je zpracova´vat v ˇreteˇzci bad-fw. Opeˇt je popı´sˇi pozdeˇji. ˇ a´dek 81 je pak urcˇen paketu˚m, ktere´ patrˇ´ı ke sluzˇR beˇ DHCP a ktere´ jdou z vnitrˇnı´ho sı´t’ove´ho rozhranı´. Takove´ pakety akceptujeme (a tı´m pa´dem klienti ve vnitrˇnı´ sı´ti mohou pouzˇ´ıvat DHCP), nicmeńeˇ mohli bychom pro veˇtsˇ´ı bezpecˇnost zalozˇit dalsˇ´ı ˇreteˇzec, jenzˇ by naprˇ´ıklad kontroloval vybrane´ MAC adresy. Take´ bychom mohli tyto pakety akceptovat s upraveny´mi podmıńkami jizˇ na ˇra´dku 45, nicmeńeˇ tato optimalizace (paket by neprocha´zel 6 pravidel navıć) nenı´ nijak vy´razna´. My tak mu˚zˇeme zachovat filozofii ˇreteˇzce spoof, kde se pouze kontrolujı´ vlastnosti paketu˚ v souvislosti se sı´t’ovy´m rozhranı´m, ze ktere´ho dorazily na na´sˇ router. Tı´m ma´me zpracovańo vsˇe, co potrˇebujeme (jak uvidı´me nı´zˇe prˇi popisu rˇeteˇzcu˚ int-fw a bad-fw), a protozˇe se nespole´ha´me na implicitnı´ politiku stanovenou na rˇa´dcıćh 26 azˇ 28, na ˇra´dku 82 zalogujeme vsˇechny prˇ´ıpadne´ nezpracovane´ pakety v ˇreteˇzci INPUT a na ˇra´dku 83 jej pak zahodı´me. Obecneˇ je vhodne´ prˇi vytva´ˇrenı´ konfigurace prˇed kazˇdou akcı´ DROP cˇi REJECT prove´st zalogovańı´. Je to z toho du˚vodu, zˇe pak snadno, naprˇ´ıklad ve vy´pisu prˇ´ıkazu dmesg, vidı´me, na ktere´ pakety jsme zapomneˇli. Le´pe tak najdeme chybu v konfiguraci firewallu a mu˚zˇeme ji rychleji a bez zbytecˇnyćh nervu˚ a chvilek nad kla´vesnicı´ odstranit. Veˇˇrte, zˇe to by´va´ nejcˇasteˇnsˇ´ı prˇ´ıcˇina dlouhe´ho odstranˇovańı´ chyby v konfiguraci firewallu. Proto jesˇteˇ jednou doporucˇuji, aby si prˇed kazˇdy´m REJECT nebo DROP zacˇa´tecˇnıći uva´deˇli pravidlo s akcı´ LOG. Take´ je vhodne´ forma´tovat zacˇa´tek srpen 2004




logovacı´ho ˇreteˇzce volbou --log-prefix pro snadneˇjsˇ´ı prˇehled a srozumitelneˇjsˇ´ı vy´pis. Zby´va´ na´m zpracovat rˇetezce bad-fw a int-fw. Na ˇra´dku 62 a tudı´zˇ drˇ´ıve, nezˇ jsme se poprve´ odka´zali na rˇeteˇzec int-fw v ˇreteˇzci INPUT (cozˇ bylo na ˇra´dku 79), definujeme samotny´ ˇreteˇzec int-fw. Na ˇra´dku 49 pak vybrane´mu pocˇ´ıtacˇi odeprˇeme prˇ´ıstup na sluzˇbu proxy serveru a tı´m mu v podstateˇ zabranˇujeme pouzˇ´ıvat internetove´ sluzˇby. Mohli bychom pouzˇ´ıt akci DROP, nicmeńeˇ toto pravidlo by pak pakety zahazovalo a uzˇivatel by se tak nedozveˇdeˇl, procˇ se nemu˚zˇe na sluzˇbu prˇipojit. A protozˇe se jedna´ o uzˇivatele ve vnitrˇnı´ sı´ti, je vhodneˇjsˇ´ı pouzˇ´ıt akci REJECT. Pravidlo DROP je obecneˇ dobre´ pouzˇ´ıvat tam, kde je mnozˇstvı´ zahozenyćh paketu˚ velke´, a tı´m snizˇujeme jak zatı´zˇenı´ sı´teˇ (neposı´la´me icmp odpoveˇd), tak zatı´zˇenı´ nasˇeho firewallu (nebot’ nemusı´ takovou icmp odpoveˇd’ sestavovat a odesı´lat). Na ˇra´dku 50 pak zaka´zˇeme uzˇivatelu˚m z vnitrˇnı´ sı´teˇ prˇ´ıstup na sluzˇbu ssh. V pravidle na ˇra´dku 51 pak povolı´me vsˇechna spojenı´ na na´sˇ router a tı´m i dostupnost vsˇech ostatnıćh beˇzˇ´ıcıćh sluzˇeb vsˇem uzˇivatelu˚m vnitrˇnı´ sı´teˇ. ˇ eteˇzec bad-fw je definovań pravidlem na ˇra´dku 62. R Na ˇra´dcıćh 63, 64, 65, 67, 68 a 69 pak vsˇem povolujeme prˇ´ıstup na definovane´ sluzˇby. Na ˇra´dcıćh 66 a 71 pak prˇ´ıstup na sluzˇbu ssh budeme zpracova´vat v ˇreteˇzcıćh ssh-me, definovanyćh na ˇra´dcıćh 53 azˇ 56. Prˇ´ıstup na sluzˇbu ftp pak definujeme v rˇeteˇzci ftp-me na ˇra´dcıćh 58 azˇ 60. A protozˇe se na tyto ˇretezce da´ skocˇit jen z ˇreteˇzce bad-fw a tomu vyhovujı´ jen pakety srpen 2004




z ˇra´dku 80, omezujeme tak prˇ´ıchozı´ pakety z vneˇjsˇ´ıho sı´t’ove´ho rozhranı´ (a tudı´zˇ z internetu). Smysl pravidla na ˇra´dku 70 objasnı´m na konci. Tı´m ma´me popsanou cˇa´st INPUT a tudı´zˇ pakety, ktere´ byly urcˇeny (v tabulce filter) nasˇemu routeru. FORWARD

Pravidla v rˇeteˇzci FORWARD popisujı´ zacha´zenı´ s pakety, ktere´ v tabulce filter meˇly jinou zdrojovou a jinou cı´lovou adresu, nezˇ jakou ma´ na´sˇ router na vsˇech svyćh sı´t’ovyćh rozhranıćh, tj. na zarˇ´ızenı´ eth0, eth1 a looopback. Typicky se jedna´ o pakety, ktere´ mı´ˇr´ı z nasˇ´ı vnitrˇnı´ sı´teˇ do internetu. Naprˇ´ıklad kdyzˇ si chce uzˇivatel pomocı´ protokolu icmp oveˇˇrit, zda je dostupny´ neˇktery´ server, naprˇ´ıklad webovy´ server www.seznam.cz. Na zacˇa´tku prˇ´ıkladu jsme stanovili politiku, zˇe prˇ´ıstup uzˇivatelu˚ na internet je zprostrˇedkovań vy´hradneˇ prˇes proxy server. Tudı´zˇ ˇreteˇzec FORWARD by mohl obsahovat jedine´ pravidlo, a to pravidlo na ˇra´dku 89. My si vsˇak na ˇra´dku 86 zalogujeme vsˇechny pokusy o nava´zańı´ spojenı´ po protokolu tcp, da´le pravidlem na ˇra´dku 87 vsˇem uzˇivatelu˚m z vnitrˇnı´ sı´teˇ ozna´mı´me, zˇe prˇ´ımy´ prˇ´ıstup do internetu nenı´ mozˇny´, da´le zalogujeme vsˇechny pokusy o prˇeposı´lańı´ paketu˚ (tedy i mozˇne´ pokusy utocˇnı´ka z venku dostat se do nasˇ´ı vnitrˇnı´ sı´teˇ) a nakonec na ˇra´dku 89 vsˇechny takove´ pakety zahodı´me.

ˇ eteˇzec OUTPUT R

srpen 2004

Zby´va´ na´m vyrˇesˇit ˇreteˇzec OUTPUT. Pro zopakovańı´ uvedu, zˇe ˇreteˇzcem OUTPUT v tabulce filter zpracova´va´me vsˇechny pakety, ktere´ majı´ jako zdrojovou adresu v tabulce filter uvedenou adresu neˇktere´ho ze sı´t’ovyćh rozhranı´ nasˇeho routeru. Typicky se jedna´ o pakety generovane´ nasˇ´ım routerem.




Na ˇra´dku 92 si zalogujeme vsˇechny pakety, ktere´ zajisˇt’ujı´ navazovańı´ neˇjake´ho spojenı´. Tak mu˚zˇeme sledovat aktivity teˇch uzˇivatelu˚, kterˇ´ı majı´ prˇ´ıstup na na´sˇ server prˇes ssh sluzˇbu. Cˇi aktivity nasˇich serverovyćh sluzˇeb. Na ˇra´dku 93 pak povolı´me vesˇkery´ odchozı´ provoz. Na ˇra´dcıćh 95 azˇ 109 pak smazˇeme vesˇkera´ pravidla v tabulkaćh nat a mangle, ktere´ podle nasˇ´ı politiky musı´ by´t pra´zdne´. Jedine´ pravidlo, ktere´ zby´va´ popsat, je pravidlo na ˇra´dku 70. Rˇ´ıka´ na´m, zˇe ma´me vra´tit odesı´lateli icmp ozna´menı´, zˇe sluzˇba nenı´ dostupna´. Procˇ pouzˇ´ıva´me REJECT mı´sto DROP (cˇi proste´ho vynechańı´ takove´ho pravidla)? Takovy´ paket prˇece vyhovuje pravidlu rˇa´dku 83. Na´sˇ server ale navazuje spojenı´ do internetu, naprˇ´ıklad odesı´la´ posˇtu. Obecneˇ platı´, zˇe pokud je naprˇ´ıklad na sluzˇbu smtp navazovańo spojenı´, server obsluhujıćı´ tuto sluzˇbu se mu˚zˇe prˇed sestavenı´m takove´ho spojenı´ zeptat odesı´latele na jeho identitu. Tuto sluzˇbu pak obvykle poskytuje server na portu auth na protokolu tcp. Pokud prˇ´ıstup na tuto sluzˇbu budeme obsluhovat akcı´ DROP, tazatel se nedozvı´, zˇe sluzˇba auth nenı´ dostupna´, a pokusı´ se o znovunava´zańı´ na sluzˇbu auth. Opeˇt mu paket zahodı´me bez ozna´menı´. Za neˇjakou dobu pokus o nava´zańı´ na sluzˇbu auth vzda´ a bude pokracˇovat v sestavovańı´ spojenı´ sluzˇby smtp, kvu˚li ktere´mu se na sluzˇbu auth pokousˇel prˇipojit. Jenzˇe mezitı´m jsme my, jako pu˚vodnı´ tazatel, vzdali pokus o nava´zańı´ spojenı´ na sluzˇbu smtp, a tak takove´to pakety jizˇ nebudou splnˇovat podmıńky pravidla 76. A prˇestozˇe by tyto pakety mohly splnˇovat pravidlo 63, tak pu˚vodnı´ tazatel jizˇ tyto pakety zahodı´ jako bezprˇedmeˇtne´, srpen 2004




protozˇe vzdal pokus o spojenı´. Du˚sledkem je, zˇe se nikdy nebudeme moci prˇipojit na takovy´ smtp server. Proto je velmi du˚lezˇite´ zacha´zet s pakety smeˇˇrujıćı´mi na sluzˇbu auth obezrˇetny´m zpu˚sobem. V souvislosti s logovańı´m paketu˚ je dobre´ da´t pozor na mnozˇstvı´ takovyćhto paketu˚. Na´sˇ router nemusı´ mı´t dostatecˇneˇ velky´ vy´kon CPU, a tak nebude bez proble´mu stı´hat logovańı´ paketu˚. Tı´m se i zpomalı´ pru˚chod ostatnıćh paketu˚ a mu˚zˇe dojı´t k tomu, zˇe nebudeme pakety vu˚bec prˇ´ıjı´mat cˇi odesı´lat. Da´le se na´m take´ mu˚zˇe sta´t, zˇe velice rychle zaplnı´me diskovou kapacitu, protozˇe logy budou naru˚stat neu´meˇrneˇ rychle. Vhodnou volbou je pak pouzˇitı´ parametru -m limit s patrˇicˇny´mi volbami. Je zrˇejme´, zˇe bychom si vystacˇili pouze s rˇeteˇzci INPUT, FORWARD a OUTPUT. Je vsˇak dobre´ zvolit definici vlastnıćh ˇreteˇzcu˚ z neˇkolika du˚vodu˚. Pokud si je dobrˇe pojmenujeme, konfigurace firewallu se sta´va´ vy´razneˇ cˇitelneˇjsˇ´ı, nezˇ kdybychom meˇli velkou sadu pravidel v jednotlivyćh ˇreteˇzcıćh. Modifikace takovyćh pravidel je pak vy´razneˇ jednodusˇsˇ´ı. Druhy´ dobry´ du˚vod je rychlost procha´zenı´ firewallu. Pokud ma´me neˇkolik ma´lo pravidel, je pravdeˇpodobneˇ jedno, jestli je procha´zı´me v nejhorsˇ´ım prˇ´ıpadeˇ vsˇechna a sekvencˇneˇ. Pokud vsˇak ma´me pravidel vıće a pokud ma´me velky´ provoz, vyplatı´ se vybudovat si pomocı´ vlastnıćh ˇreteˇzcu˚ jakousi stromovou strukturu a tı´m pa´dem zrychlit pru˚chod paketu firewallem a i nezpomalovat tak prˇ´ılisˇ provoz na sı´ti. Tı´m ma´me probranou konfiguraci firewallu, jezˇ splnˇuje tu politiku, kterou jsme si na zacˇa´tku stanovili. Natazˇenı´ modulu˚

srpen 2004

Zby´va´ dodat, ze pro spra´vnou funkci stavovosti firewallu (volba -m state) je nutne´ mı´t natazˇene´




moduly ip conntrack a ip conntrack ftp. Ten druhy´ zejmeńa proto, zˇe uzˇivatelu˚m umozˇnˇujeme prˇistupovat na ftp sluzˇby prostrˇednictvı´m nasˇeho proxy serveru. Tyto moduly nata´hneme prˇ´ıkazem modprobe ip conntrack a modprobe ip conntrack ftp. Mu˚zˇeme to udeˇlat v nasˇem skriptu a nebo neˇkde jinde. Jde to take´ udeˇlat mnoha dalsˇ´ımi zpu˚soby, ovsˇem to je mimo te´ma te´to kapitoly. K samotne´mu skriptu, ktery´ je nı´zˇe uvedeny´, je nutno dodat, zˇe jeho obsahem by nebyly mezery prˇed cˇ´ısly ˇra´dku˚, samotna´ cˇ´ısla ˇra´dku˚, dvojtecˇka za cˇ´ıslem ˇra´dku a mezera za touto dvojtecˇkou. Neˇktere´ ˇra´dky jsou ve skriptu delsˇ´ı, nezˇ se vejde do te´to prˇ´ırucˇky. V takove´m prˇ´ıpadeˇ je zde vytisˇteˇn pokracˇovacı´ ˇra´dek, ktery´ uzˇ nema´ cˇ´ıslo a je odsazen. Takto upraveny´ pokracˇovacı´ ˇra´dek by ale ve skutecˇne´m skriptu nefungoval, protozˇe na konci prˇedchozı´ho ˇra´dku chybı´ znak \. Samotny´ 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




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


-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




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




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 && \




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



srpen 2004





9/3.6.2 ˇ ÍKLAD POUZˇITI´ TABULKY NAT PR NA FIREMNI´M FIREWALLU

Uka´zkovy´ skript se opeˇt spousˇtı´ s parametrem start pro nastavenı´ firewallu. Pokud skript spustı´me parametrem stop, filtrovacı´ sluzˇby ja´dra se nastavı´ na hodnoty, ktere´ zˇa´dny´m zpu˚sobem neomezujı´ pru˚chod paketu˚ prˇes dany´ pocˇ´ıtacˇ. Tedy jako v prˇechozı´m prˇ´ıpadeˇ. Na ten se ostatneˇ budu cˇasto odkazovat, a tak jeho pochopenı´ je vcelku podstatne´ pro spra´vne´ pochopenı´ tohoto prˇ´ıkladu. Prˇedstavme si, zˇe ma´me firemnı´ router, ktery´ je opeˇt jednı´m sı´t’ovy´m rozhranı´m prˇipojen do Inetrnetu a ma´ od poskytovatele prˇideˇlenou verˇejnou adresu 164.218.1.10, a druhy´m sı´t’ovy´m rozhranı´m je prˇipojen do vnitrˇnı´ firemnı´ sı´teˇ. Tato sı´t’ ma´ neverˇejnou adresu 192.168.1.0/24 a na´sˇ router ma´ adresu 192.168.1.1. Da´le ma´me na verˇejne´m sı´t’ove´m rozhranı´ jesˇteˇ jednu adresu, a to 164.218.1.11. Tato adresa je sekunda´rnı´ na onom verˇejne´m rozhranı´ eth0.

Prˇedpoklady

srpen 2004




Zadańı´

Na nasˇem routeru pak provozujeme pro ućˇely pocˇ´ıtacˇu˚ z vnitrˇnı´ sı´teˇ i pro pocˇ´ıtacˇe z internetu posˇtovnı´ server, domeńovy´ server, webovy´ server. Da´le pak pro vybrane´ za´kaznı´ky ssh server pro vzda´leny´ prˇ´ıstup, VPN server (realizovany´ nad protokolem IPSec) a ftp server. Nakonec pro pocˇ´ıtacˇe ve vnitrˇnı´ sı´ti provozujeme proxy server. Pozˇadujeme, aby uzˇivatele´ mohli na internetu pouzˇ´ıvat webove´ sluzˇby a ftp sluzˇby, avsˇak pouze prˇes proxy server, ktery´ ma´me za tı´mto ućˇelem na routeru nakonfigurovany´. Da´le chceme umozˇnit uzˇivatelu˚m ve vnitrˇnı´ sı´ti protokol icmp, konkre´tneˇ umozˇnit oveˇˇrenı´, zda server na internetu zˇije. Zˇa´dny´ jiny´ prˇ´ıstup uzˇivatele´ do internetu mı´t nebudou. Na serveru pak mohou pouzˇ´ıvat vsˇechny beˇzˇ´ıcı´ sluzˇby kromeˇ sluzˇby ssh, ktera´ umozˇnˇuje prˇ´ıstup na server. Da´le pozˇadujeme, aby meˇla na sluzˇbu ssh prˇ´ıstup externı´ firma z adres 123.45.67.8 a 123.45.67.9 (naprˇ´ıklad na´m spravuje neˇjakou beˇzˇ´ıcı´ aplikaci) a da´le aby na na´sˇ server meˇla prˇ´ıstup na sluzˇbu ftp tata´zˇ firma a da´le jina´ firma z adres 223.45.67.10 a 223.45.67.11 (naprˇ´ıklad za ućˇelem spra´vy obsahu webovyćh strańek). Konecˇneˇ chceme, abychom propojili nasˇe pobocˇky technologiı´ VPN. Samotne´ propojenı´ realizuje jina´ sluzˇba (beˇzˇ´ıcı´ na nasˇem routeru nezˇ na´sˇ firewall). My vsˇak v nasˇem firewallu musı´me povolit pohyb paketu˚ v ra´mci one´ VPN. Verˇejne´ adresy teˇchto pobocˇek jsou zaznamenańy v uka´zkove´m skriptu zrˇejmy´m zpu˚sobem. Pozˇadujeme, aby provoz mezi pocˇ´ıtacˇi v jednotlivyćh vnitrˇnıćh sı´tıćh pobocˇek byl bez jake´hokoliv omezenı´.

srpen 2004




Vy´sˇe uvedene´ pozˇadavky jsou obdobne´ pozˇadavku˚m v prˇedchozı´m prˇ´ıkladeˇ a opeˇt by na´m stacˇila pouze tabulka filter. My vsˇak jesˇteˇ pozˇadujeme na´sledujıćı´. Pokud budou uzˇivatele´ prˇistupovat pomocı´ webove´ho prohlı´zˇecˇe na adresu https://164.218.1.11/, tak chceme, aby tyto pozˇadavky byly prˇesmeˇrovańy na server ve vnitrˇnı´ sı´ti, jehozˇ adresa je 192.168.1.7. Tote´zˇ prˇesmeˇrovańı´ pozˇadujeme, pokud prˇistoupı´ opeˇt na adresu 164.218.1.11 protokolem tcp na porty 1443 a 8002. Prˇedstavme si, zˇe ve vnitrˇnı´ sı´ti na serveru na teˇchto portech posloucha´ naprˇ´ıklad databa´zovy´ server. Ono prˇesmeˇrovańı´ slouzˇ´ı k tomu, zˇe dane´ sluzˇby jsou dostupne´ z internetu, prˇestozˇe servery, na nichzˇ beˇzˇ´ı, majı´ priva´tnı´, a tudı´zˇ z internetu nedostupne´, adresy. Take´ pozˇadujeme, aby se na server 164.218.1.11 dalo pingnout. Musı´me tedy jesˇteˇ prˇesmeˇrovat protokol icmp. Dalsˇ´ım a poslednı´m pozˇadavkem je pak prˇesmeˇrovańı´ pozˇadavku˚ na externı´ adresu routeru 164.218.1.10 a sluzˇby na portu tcp/3050 na server ve vnitrˇnı´ sı´ti s adresou 192.168.1.6. Nynı´ se pustı´me smeˇle do konfigurace firewallu.

Konfigurace

Na ˇra´dcıćh 3 azˇ 40 (skript s cˇ´ıslovany´mi ˇra´dky je na konci te´to kapitoly) si nastavı´me neˇktere´ promeˇnne´, mezi nimi i verˇejne´ adresy oneˇch pobocˇek, ktere´ se budou prˇipojovat do VPNky. Je vhodne´ si vsˇimnout, zˇe vsˇechny vnitrˇnı´ sı´teˇ jsou podmnozˇinou sı´teˇ 192.168.0.0/16 a takto si ji oznacˇ´ıme promeˇnnou firemni vpn. srpen 2004




Na ˇra´dcıćh 121 azˇ 129 v pravidlech INPUT jizˇ na´m zna´my´m zpu˚sobem oveˇˇr´ıme, zda pakety prˇicha´zejıćı´ z jednotlivyćh sı´t’ovyćh zarˇ´ızenı´ majı´ spra´vnou zdrojovou adresu. Za zmıńku stojı´ virtua´lnı´ sı´t’ove´ zarˇ´ızenı´ ipsec0, ze ktere´ho k na´m budou prˇicha´zet pakety ze sı´tı´, ktere´ jsou zacˇleneˇny do nasˇ´ı VPNky. Da´le povolı´me vsˇechna nava´zana´ spojenı´ na na´sˇ router (rˇ. 121), povolı´me vsˇechna jizˇ nava´zana´ spojenı´ (rˇ. 122), zalogujeme (rˇ. 123) a zahodı´me (rˇ. 124) neplatne´ pakety, jezˇ nemajı´ nastaven SYN bit ale tva´ˇr´ı se jako pakety, ktere´ navazujı´ spojenı´. Pak zalogujeme (rˇ. 125) vsˇechny pakety, ktere´ patrˇ´ı neˇjake´mu pra´veˇ zahajovane´mu spojenı´. Pravidlo na ˇra´dku 126 na´m pak ˇr´ıka´, zˇe vsˇechny pakety z nasˇich vnitrˇnıćh sı´tı´ obslouzˇ´ıme v pravidlech ˇreteˇzce int-fw, ktery´ jsme si zadefinovali na ˇra´dcıćh 83, 84 a 85. Zakazujeme tam prˇ´ıstup pocˇ´ıtacˇu˚m na sluzˇbu ssh a jinak vsˇe povolujeme. Prˇestozˇe sı´t’ 192.168.0.0/16 obsahuje mnohem vıće podsı´tı´ a my pouzˇ´ıva´me jen 6 (int net0 0, radotin net, rubena net, frydlant net, boleslav net a hradec net), mu˚zˇeme si takto dovolit zobecnˇovat, protozˇe jsme to osˇetrˇili v ˇreteˇzci spoof (rˇa´dky 66 azˇ 70). Vsˇechny pakety ostatnıćh podsı´tı´ ze sı´teˇ 192.168.0.0/16 totizˇ zahodı´me (rˇ. 74). Pravidlo na ˇra´dku 127 na´m ˇr´ıka´, jak se budeme chovat k paketu˚m, ktere´ prˇijdou z internetu nasˇ´ım externı´m rozhranı´m eth0. Da´le jde o to, zˇe budeme cı´love´ a zdrojove´ adresy u neˇkteryćh paketu˚ prˇepisovat v tabulce nat. Proto na tomto mı´steˇ zdu˚raznˇuji, zˇe jsme v tabulce filter. Da´le jizˇ tuto znalost prˇedpokla´da´m a odkazuji se na

srpen 2004




prˇedchozı´ prˇ´ıklad a znalosti z neˇj a nebudu se tudı´zˇ vzˇdy zminˇovat, ve ktere´ tabulce se nacha´zı´me. Na ˇra´dku 128 a 129 pak zalogujeme a zahodı´me vsˇechny pakety, ktere´ nevyhoveˇly zˇa´dne´mu pravidlu v ˇreteˇzci INPUT. Upozornˇuji, zˇe zˇa´dny´ takovy´ prˇ´ıpad by nemeˇl nastat. Na ˇra´dcıćh 107 azˇ 119 definujeme ˇreteˇzec bad-fw, kde je nastaven prˇ´ıstup podle vy´sˇe uvedenyćh pozˇadavku˚. Prˇ´ıstup na posˇtovnı´, webovy´ a domeńovy´ server vsˇem pocˇ´ıtacˇu˚m z internetu. Na sluzˇby ftp, ssh a VPN serveru pak prˇ´ıstup omezujeme v ˇreteˇzcıćh ftp-me (rˇa´dky 87 azˇ 92), ssh-me (rˇa´dky 94 azˇ 97) a to ipsec (rˇa´dky 99 azˇ 105). V pravidlech ˇreteˇzce OUTPUT jen logujeme vsˇechna odchozı´ navazujıćı´ spojenı´ z nasˇeho serveru. Provoz neomezujeme nijak. V pravidlech ˇreteˇzce FORWARD prova´dı´me vsˇe zna´me´ jizˇ z drˇ´ıveˇjsˇka. Pravidlo na ˇra´dku 154 pak ˇr´ıka´, zˇe provoz mezi pocˇ´ıtacˇi ve VPNce je neomezovany´. Pravidlo na ˇra´dku 155 se odkazuje na pravidla v ˇreteˇzci int-ext, kde povolı´me pocˇ´ıtacˇu˚m ve vnitrˇnı´ sı´ti pouze ping na pocˇ´ıtacˇe v internetu a vsˇe ostatnı´ zaka´zˇeme. Pravidla na ˇra´dcıćh 156 a 157 pak definujı´ prˇ´ıstup na prˇ´ıslusˇne´ pocˇ´ıtacˇe v nasˇ´ı vnitrˇnı´ sı´ti. Dı´ky ˇra´dku 154 teˇmto dveˇma pravidlu˚m mohou vyhovovat pakety, jejichzˇ zdrojova´ adresa nenı´ ani z nasˇ´ı vnitrˇnı´ sı´teˇ, ani ze sı´tı´ z neˇjake´ nasˇ´ı pobocˇky, ale je pouze adresou z internetu. Zajı´mave´ to ovsˇem v tomto prˇ´ıkladeˇ zacˇ´ına´ by´t azˇ v tabulce nat. Nebudeme ji procha´zet pravidlo po pravidle, ny´brzˇ se podı´va´me, jake´ podmıńky musı´ splnˇovat srpen 2004




pakety s teˇmi omezenı´mi, ktera´ jsme si stanovili na zacˇa´tku. Zacˇneme poslednı´m pozˇadavkem, a to prˇesmeˇrovańı´ paketu˚ z internetu urcˇenyćh nasˇemu routeru (externı´ adresa 164.218.1.10) a sluzˇby na portu tcp/3050 na server ve vnitrˇnı´ sı´ti s adresou 192.168.1.6. Nezˇ prˇ´ıchozı´ paket dorazı´ do tabulky filter, procha´zı´ tabulkou nat. Pravidlem na ˇra´dku 188 ˇr´ıka´me, zˇe vsˇechny pakety urcˇene´ nasˇ´ı externı´ adrese (a je v tuto chvı´li jedno, zda prˇisˇel z rozhranı´ eth0, eth1 nebo ipsec0) na port tcp/3050 zpracujeme v ˇretezci to-ext ip (jsme v tabulce nat). V pravidle na ˇra´dku 178 pak pu˚vodnı´ cı´lovou adresu 164.218.1.10 prˇepı´sˇeme na novou cı´lovou adresu, a to 192.168.1.6. Kdyzˇ pak paket procha´zı´ tabulkou filter v ˇreteˇzci FORWARD, zpracujeme jej pra´veˇ pravidlem 157 a na´sledneˇ ˇreteˇzcem to-amonit. Pak jizˇ paket da´le nenı´ v tabulce filter zpracova´vań a v tabulce nat take´ nevyhovuje zˇa´dne´mu pravidlu POSTROUTING (avsˇak akceptuje jej na´mi nastavena´ politika) a je odeslań sı´t’ovy´m rozhranı´m eth1 pra´veˇ na server s adresou 192.168.1.6. Zdu˚raznˇuji, zˇe jsme takove´mu paketu prˇepsali jen cı´lovou adresu. Zdrojova´ zu˚sta´va´ sta´le stejna´. Kdyzˇ tento server odpovı´da´ tazateli podle zdrojove´ adresy dosˇle´ho paketu, tak takova´to odpoveˇd (resp. paket) nevyhovuje zˇa´dne´mu pravidlu v tabulce nat v ˇreteˇzci PREROUTING. Paket je prˇedań do tabulky filter, kde jej zpracuje pravidlo na ˇra´dku 150 ˇreteˇzce FORWARD. Da´le paket putuje opeˇt do tabulky nat, kde vyhovı´ pravidlu 208 ˇreteˇzce POSTROUTING, a akcı´ MASQUERADE je zdrojova´ adresa prˇepsańa na nasˇi externı´ adresu 164.218.1.10. Takovy´to paket pak srpen 2004




zdroj zpracuje, protozˇe bude patrˇit spojenı´, ktere´ nava´zal. Totizˇ spojenı´, jehozˇ jednı´m koncem je tazatel a druhy´m konecm na´sˇ router. Zˇe jsme paket prˇesmeˇrovali do vnitrˇnı´ sı´teˇ, tazatel nepozna´. Pro zopakovańı´ uvedu, zˇe akce MASQUERADE kromeˇ jine´ho prˇepisuje zdrojovou adresu na prima´rnı´ adresu takove´ho sı´t’ove´ho rozhranı´, jı´mzˇ bude paket odeslań. To si mechanismus obsluhujıćı´ tuto akci zjistı´ z routovacı´ tabulky. Da´le mechanismus prˇepı´sˇe zdrojovy´ port na neˇjakou hodnotu a charakteristiku takove´ho spojenı´ si zapı´sˇe do tabulky. Azˇ k neˇmu dorazı´ odpoveˇd’, tak nezˇ paket pustı´ do tabulky nat, prˇepı´sˇe cı´lovou adresu (a cı´lovy´ port) v odpoveˇdi na adresu (port), kterou tato akce „zamasˇkara´dovala“. Nynı´ na´m jizˇ zby´va´ zpracovat pozˇadavek na prˇesmeˇrovańı´ provozu urcˇene´ho na sluzˇby tcp/1443, tcp/8002 a tcp/443 (https) z pu˚vodnı´ adresy 164.218.1.11 na adresu 192.168.1.7, a to ve vsˇech prˇ´ıpadech. Tedy z pocˇ´ıtacˇu˚ z nasˇ´ı vnitrˇnı´ sı´teˇ a z pocˇ´ıtacˇu˚ z internetu. Na prvnı´ pohled je situace podobna´ jako v prˇedchozı´m pozˇadavku v tom, zˇe prˇesmeˇrova´va´me provoz na adresu ve vnitrˇnı´ sı´ti. Avsˇak musı´me da´t pozor na neˇkolik veˇcı´. Uka´zˇe se, zˇe ta podobnost je jen zdańliva´. Pokud prˇijde na na´sˇ server pozˇadavek na adresu 164.218.1.11 a naprˇ´ıklad na sluzˇbu tcp/8002 (a je opeˇt jedno, jestli ze zarˇ´ızenı´ eth0, eth1 cˇi ipsec0), pak jej zpracujeme v tabulce nat v ˇreteˇzci PREROUTING pravidlem na ˇra´dku 189 a na´sledneˇ v ˇreteˇzci to-terminalPC pravidlem na ˇra´dce 202. Paket pak jizˇ putuje do tabulky filter, kde jej zpracujeme v ˇreteˇzci FORWARD v pravidle 156 a na´sledneˇ v ˇreteˇzci to-terminalPC pravidlem na ˇra´dku 139. srpen 2004




Pak paket opeˇt putuje do tabulky nat, avsˇak nevyhovuje zˇa´dne´mu pravidlu v ˇreteˇzci POSTROUTING. Vyhovuje vsˇak nastavene´ politice (prˇ´ıkaz na ˇra´dku 147), a tak opustı´ tabulku nat jizˇ beze zmeˇny. Tı´m jsme tedy prˇepsali cı´lovou adresu z 164.218.1.11 na 192.168.1.7. Zdu˚raznˇuji, zˇe je nutne´ si prˇi tomto vy´kladu da´t pozor, zda se pohybujeme v tabulce nat nebo filter. Rˇeteˇzec se jmeńem to-terminalPC ma´me v obou dvou. Tento paket dorazı´ tedy na server s adresou 192.168.1.7. Prˇedpokla´da´me, zˇe ma´ v routovacı´ tabulce za´znam, zˇe sı´t’ 192.168.1.0/24 routuje prˇ´ımo do sve´ho sı´t’ove´ho rozhranı´ (je prˇece v nasˇ´ı vnitrˇnı´ sı´ti) a jako svou brańu (default gateway) ma´ uvedenu vnitrˇnı´ adresu nasˇeho routeru 192.168.1.1. Server 192.168.1.7 nynı´ odesˇle odpoveˇd’ s cı´lovou adresou, ktera´ je stejna´ jako zdrojova´ adresa v pra´veˇ dosˇle´m paketu. Mohou nastat dveˇ situace. Tou prvnı´ je, zˇe tazatel je ze sı´teˇ 192.168.1.0/24, cˇili nasˇ´ı vnitrˇnı´ sı´teˇ. V tom prˇ´ıpadeˇ jej odesˇle prˇ´ımo jemu a takova´ odpoveˇd vu˚bec nepu˚jde prˇes na´sˇ router. Tazateli vsˇak dorazı´ paket, ktery´ se tva´ˇr´ı, jakozˇe patrˇ´ı neˇjake´mu spojenı´, ktere´ tazatel sice navazuje, avsˇak navazuje jej na adresu 164.218.1.11 a z nı´ take´ ocˇeka´va´ odpoveˇd’. Jemu vsˇak dorazila odpoveˇd’ z 192.168.1.7. O te´ si pochopitelneˇ bude myslet, zˇe je to podvrh nebo chyba a takovy´ paket prosteˇ zahodı´. Spojenı´ pak cˇasem vyprsˇ´ı a nikdy se nenava´zˇe. Nasˇ´ım u´kolem je tedy zajistit, aby odpoveˇd sˇla prˇes na´sˇ router. Toho dosa´hneme tak, zˇe nezˇ pu˚vodnı´ paket vypustı´me do sı´t’ove´ho rozhranı´, prˇepı´sˇeme mu v tabulce nat v pravidle POSTROUTING zdrojovou adresu.

srpen 2004




Pravidlem na ˇra´dku 207 tedy zajistı´me, zˇe vsˇem paketu˚m, ktere´ prˇeposı´la´me v tabulce nat serveru 192.168.1.7 a jejichzˇ zdrojova´ adresa patrˇ´ı neˇkomu z nasˇ´ı vnitrˇnı´ sı´teˇ, prˇepı´sˇeme zdrojovou adresu na nasˇ´ı vnitrˇnı´ adresu 192.168.1.1. Server 192.168.1.7 pak posı´la´ odpoveˇdi na´m, my takove´to pakety „odmasˇkara´dujeme“, cˇili cı´lovou adresu prˇepı´sˇeme na pu˚vodnı´ zdrojovou, v tabulce nat se pak v ˇreteˇzci PREROUTING nic neodehraje, paket putuje do tabulky filter a tam je zpracovań v pravidle 150 ˇreteˇzce FORWARD. Kdyzˇ opousˇtı´ tabulku nat, tak dı´ky pravidlu v rˇeteˇzci POSTROUTING na ˇra´dku 206 jej zpracujeme v ˇreteˇzci from-terminalPC pravidlem na ˇra´dku 195 a odesˇleme do sı´teˇ. K tazateli v nasˇ´ı vnitrˇnı´ sı´t’i pak dorazı´ paket, ktery´ ma´ spra´vnou zdrojovou adresu. Druha´ situace je takova´, zˇe tazatel nepocha´zı´ z nasˇ´ı vnitrˇnı´ sı´teˇ. Protozˇe server 192.168.1.7 ma´ v routovacı´ tabulce jako brańu uvedeny´ na´sˇ server, tak takova´to odpoveˇd’ jizˇ pu˚jde prˇes na´sˇ router. Protozˇe jsme neprˇepisovali odesı´latelovu zdrojovou adresu, server 192.168.1.7 odpovı´da´ tomu, komu ma´. Nasˇ´ım u´kolem je tedy jen zajistit prˇepis zdrojove´ adresy v odpoveˇdi, aby si tazatel myslel, zˇe komunikuje se serverem s adresou 164.218.1.11 (a spra´vny´m portem). To zajistı´me pravidlem na ˇra´dku 206, kde posˇleme paket na zpracovańı´ do ˇretezce from-terminalPC a pravidlem na ˇra´dku 195 zdrojovou adresu a port prˇepı´sˇeme. Toto jsme provedli pro spojenı´ na portu tcp/8002, a obdobneˇ to zby´va´ prove´st pro sluzˇby tcp/443, tcp/1443 a icmp. Pravidlo na ˇra´dku 190 pak ma´ usnadnit zˇivot uzˇivatelu˚m ve vnitrˇnı´ sı´ti. Pokud by si ve sve´m prohlı´zˇecˇi srpen 2004




nenastavili jako proxy server na´sˇ router, tak by vesˇkere´ pozˇadavky na webove´ strańky skoncˇily v rˇeteˇzci int-ext. My tı´mto pravidlem takove´to pakety prˇesmeˇrujeme na na´sˇ router na port 3128, kde posloucha´ daemon, ktery´ sluzˇbu proxy serveru zajisˇt’uje. Zby´va´ probrat pravidlo na ˇra´dku 179. Jde o to, zˇe provoz, ktery´ je urcˇen nasˇemu routeru, procha´zı´ take´ tabulkou nat (jako ostatneˇ vsˇechny pakety). Pravidlo na ˇra´dku 178 prˇesmeˇrova´va´ pouze jeden port, kdezˇto pravidlo na ˇra´dku 179 pak zby´vajıćı´ pakety s nasˇ´ı prima´rnı´ externı´ adresou jakou cı´lovou akceptuje. Tı´m zajistı´me, zˇe bude paket do tabulky filter prˇedań se spra´vnou cı´lovou adresou. Za domaćı´ cvicˇenı´ si mu˚zˇete zdu˚vodnit, procˇ je toto pravidlo v te´to konfiguraci zbytecˇne´ a mu˚zˇeme jej u´plneˇ vypustit :-) Tı´m ma´me probranou tabulku nat, ve ktere´ jsme se pra´veˇ sezna´mili s pouzˇ´ıtı´m akcı´ DNAT, SNAT a MASQUERADE. Zbytek prˇ´ıkladu je jizˇ stejny´ jako prˇedchozı´ prˇ´ıklad. Tı´m je dokoncˇena´ konfigurace firewallu, jenzˇ splnˇuje tu politiku, kterou jsme si na zacˇa´tku stanovili. Mozˇna´ se va´m v tuto chvı´li zda´ vy´znam tabulky nat zmateny´ cˇi prˇ´ılisˇ slozˇity´. Veˇˇrte ale, zˇe s prˇepisovańı´m hlavicˇek v paketu lze dosa´hnout velmi zajı´mavyćh vy´sledku˚ a mozˇnyćh ˇresˇenı´. K samotne´mu skriptu, ktery´ je nı´zˇe uvedeny´, je nutno opeˇt dodat, zˇe jeho obsahem by nebyly mezery prˇed cˇ´ısly ˇra´dku˚, samotna´ cˇ´ısla ˇra´dku˚, dvojtecˇka za cˇ´ıslem ˇra´dku a mezera za touto dvojtecˇkou. Neˇktere´ ˇra´dky jsou ve skriptu delsˇ´ı, nezˇ se vejde do te´to prˇ´ırucˇky. V takove´m prˇ´ıpadeˇ je zde vytisˇteˇn pokracˇovacı´ ˇra´dek, ktery´ uzˇ nema´ cˇ´ıslo a je odsazen. Takto upraveny´ srpen 2004




pokracˇovacı´ ˇra´dek by ale ve skutecˇne´m skriptu nefungoval, protozˇe na konci prˇedchozı´ho ˇra´dku chybı´ znak \. Samotny´ 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




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:


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




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


-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




116: 117: 118: 119:


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


-N -A -A -A -A -A -A

to-terminalPC to-terminalPC to-terminalPC to-terminalPC to-terminalPC to-terminalPC to-terminalPC


-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


-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




156: 157: 158: 159:


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


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




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




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



srpen 2004





9/3.6.3 ˇ ÍKLAD POUZˇITI´ TABULKY PR MANGLE

Cely´ tento prˇ´ıklad svou koncepcı´ zapada´ do kapitoly o omezovańı´ sı´t’ove´ho provozu na u´rovni protokolu IP. Zde tedy uvedu jen prˇ´ıklad, na ktery´ se budu odkazovat pra´veˇ z one´ kapitoly o omezovańı´ sı´t’ove´ho provozu. Tabulka mangle se v linuxove´m firewallu netfilter pouzˇ´ıva´ zrˇ´ıdka. Je vhodna´ zejmeńa ke znacˇkovańı´ paketu˚. Takove´ znacˇkovańı´ se hodı´ zejmeńa v prˇ´ıpadeˇ, zˇe pakety da´le zpracova´va´me (at’ uzˇ na pocˇ´ıtacˇi, kde znacˇkujeme, nebo neˇjake´m dalsˇ´ım pocˇ´ıtacˇi, kudy musı´ sı´t’ovy´ provoz procha´zet). V linuxovyćh ja´drech do verze 2.4.17 vcˇetneˇ meˇla tabulka mangle pouze dva vestaveˇne´ ˇreteˇzce. PREROUTING pro zpracovańı´ prˇ´ıchozıćh paketu˚ prˇed routovańı´m a OUTPUT pro zpracovańı´ paketu˚ vygenerovanyćh loka´lneˇ a zpracovanyćh opeˇt prˇed routovańı´m. Od ja´dra 2.4.18 pak prˇibyly ˇreteˇzce INPUT pro pakety prˇicha´zejıćı´ dovnitrˇ pocˇ´ıtacˇe, uńor 2005




FORWARD pro pakety procha´zejıćı´ routovacı´m procesem pocˇ´ıtacˇe a POSTROUTING pro pakety, ktere´ z pocˇ´ıtacˇe odcha´zejı´. K oznacˇenı´ paketu prˇ´ıslusˇnou znacˇkou slouzˇ´ı u prˇ´ıkazu iptables akce MARK. Pokud paket vyhovı´ dane´mu pravidlu, je oznacˇen. Jeho pru˚chod firewallem vsˇak nekoncˇ´ı (naprˇ´ıklad na rozdı´l od akcı´ ACCEPT cˇi DROP), ale pokracˇuje dalsˇ´ım pravidlem. Proto je nutne´ prˇi vytva´ˇrenı´ posloupnosti pravidel postupovat od obecnyćh podmıńek ke konkre´tneˇjsˇ´ım. Zadańı´

uńor 2005

Definice zadańı´ v kapitole o omezovańı´ sı´t’ove´ho provozu je pak na´sledujıćı´. Jsme veˇtsˇ´ı firmou prˇistupujıćı´ do Internetu prˇes jedinou verˇejnou adresu, kterou jsme dostali od poskytovatele prˇipojenı´. V budoveˇ, kde sı´dlı´ nasˇe firma, vsˇak sı´dlı´ jesˇteˇ jina´ firma, ktera´ je prˇipojena do nasˇ´ı vnitrˇnı´ sı´t’eˇ a ktera´ take´ prˇes nasˇi verˇejnou adresu prˇistupuje do Internetu. Rˇekneˇme, zˇe nasˇe firma pouzˇ´ıva´ sı´t’192.168.0.0 s maskou 255.255.255.0 a ona druha´ firma pouzˇ´ıva´ 192.168.1.0 s maskou 255.255.255.0. Rychlost nasˇ´ı linky prˇi uploadu je 512/768 kbps (download/upload). Ra´di bychom prˇideˇlene´ pa´smo rozdeˇlili tak, zˇe nasˇe firma bude pouzˇ´ıvat 300/500 kbps kapacity linky a sousednı´ firma 212/268 kbps kapacity. V patrˇicˇne´m pomeˇru se takto deˇlı´ i o cenu fakturovanou poskytovatelem. A da´le bychom chteˇli, aby pocˇ´ıtacˇ 192.168.0.30, ktery´ je v nasˇ´ı vnitrˇnı´ sı´ti, meˇl alesponˇ garantovanou rychlost 128 kbps. Je to totizˇ pocˇ´ıtacˇ nasˇeho ˇreditele, ktery´ ma´ prˇipojenou IP telefonii a obcˇas telefonuje prˇes Internet, a je nutne´ mu garantovat tuto rychlost. Da´le si prˇejeme, aby vza´jemny´ provoz mezi nasˇ´ı firmou a sousednı´ firmou nebyl nijak omezovań. Nakonec jen doda´m, zˇe verˇejna´ adresa nasˇeho routeru je 123.45.67.8, adresa do nasˇ´ı vnitrˇnı´ sı´teˇ je 192.168.0.1 a adresa do




vnitrˇnı´ sı´teˇ sousednı´ firmy je 192.168.1.1. Skutecˇnost, zdali jsou segmenty firemnıćh sı´tı´ fyzicky oddeˇleny (a na´sˇ router ma´ v tomto prˇ´ıpadeˇ trˇi ethernetove´ karty) nebo jsou na jednom segmentu (a na´sˇ router ma´ v tomto prˇ´ıpadeˇ pravdeˇpodobneˇ dveˇ ethernetove´ karty), je v tuto chvı´li nepodstatna´. Uvedu zde jen cˇa´st firewallovacıćh pravidel, a to teˇch, ktere´ se ty´kajı´ tabulky mangle. Samozrˇejmeˇ bude nutne´ spra´vneˇ nakonfigurovat i pravidla v tabulkaćh filter a nat, ovsˇem to dostatecˇneˇ popisujı´ prˇedchozı´ prˇ´ıklady pouzˇitı´ firewallu. Pro na´sˇ prˇ´ıklad je vhodne´ oznacˇkova´vat pakety, ktere´ nejsou v principu urcˇene´ nasˇemu pocˇ´ıtacˇi, v ˇreteˇzci FORWARD, protozˇe zde jsou pakety z vnitrˇnıćh sı´tı´ prˇed masˇkara´dou (a tudı´zˇ nemajı´ zkreslenou zdrojovou adresu) a pakety z Internetu jsou jizˇ po odmasˇkara´dovańı´, tudı´zˇ konecˇna´ spra´vna´ cı´lova´ adresa je take´ zna´ma. Pakety, ktere´ generuje na´sˇ router, oznacˇkujeme v pravidlech ˇreteˇzce OUTPUT. Jedine´, co neznacˇkujeme, jsou pakety, ktere´ jsou urcˇeny nasˇemu pocˇ´ıtacˇi. Na ˇra´dcıćh 1 azˇ 6 definujeme promeˇnne´, ktere´ da´le pouzˇijeme v prˇ´ıkladu nasˇeho firewallu. Na ˇra´dcıćh 9 azˇ 16 definujeme defaultnı´ politiku pravidel v jednotlivyćh ˇreteˇzcıćh. Na ˇra´dku 18 oznacˇ´ıme vsˇechen provoz, ktery´ generujı´ pocˇ´ıtacˇe z nasˇ´ı vnitrˇnı´ sı´teˇ a ktery´ nenı´ urcˇeny´ pro na´sˇ router. Jsme totizˇ v pravidle FORWARD. Bude sem patrˇit provoz, jenzˇ smeˇˇruje do Internetu (nezna´me cı´lovou adresu), a da´le provoz, ktery´ smeˇˇruje do vnitrˇnı´ sı´teˇ sousednı´ firmy. Na ˇra´dku 19 je pak provoz, ktery´ generuje pocˇ´ıtacˇ pana ˇreditele. uńor 2005




Na ˇra´dku 20 je obdobneˇ tote´zˇ pro pakety smeˇˇrujıćı´ do nasˇ´ı vnitrˇnı´ sı´teˇ. Na ˇra´dku 21 pak oznacˇ´ıme provoz, ktery´ smeˇˇruje do pocˇ´ıtacˇe pana rˇeditele. Da´le na ˇra´dcıćh 22 a 23 oznacˇ´ıme provoz, ktery´ smeˇˇruje z a do vnitrˇnı´ sı´teˇ sousednı´ firmy. My vsˇak potrˇebujeme jinou znacˇkou oznacˇit provoz, ktery´ je mezi vnitrˇnı´mi sı´teˇmi nasˇ´ı a sousednı´ firmy. Ucˇinı´me tak na ˇra´dcıćh 24 a 25. Pak je jesˇteˇ nutno oznacˇit provoz, ktery´ generuje na´sˇ router. To provedeme na ˇra´dku 26, 27 a 28. Oznacˇili jsme tak vesˇkery´ provoz, ktery´ odcha´zı´ z nasˇeho routeru, a ma´me neoznacˇen jen ten provoz, ktery´ smeˇˇruje z vnitrˇnıćh sı´tı´ a z Internetu na na´sˇ router. Procˇ takovy´ provoz neoznacˇ´ıme, je vysveˇtleno v kapitole o omezovańı´.

uńor 2005




T

Tabulka znacˇek pro vesˇkery´ provoz

adresa zdrojova´

cı´lova´

znacˇ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

uńor 2005




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

uńor 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}"




9/3.7 IDS

IDS (Intrusial Detection System) jsou aplikace urcˇene´ pro automatickou detekci nejru˚zneˇjsˇ´ıch forem u´toku˚ cı´lenyćh na dany´ server. Sami o sobeˇ nezvysˇujı´ bezpecˇnost dane´ho syste´mu, ale jejich pouzˇitı´ umozˇnˇuje administra´torovi sledovat potencia´lneˇ nebezpecˇne´ akce na sı´ti/syste´mu.

IDS

IDS syste´my mu˚zˇeme rozdeˇlit do trˇ´ı kategoriı´: • klasicke´ (offline) IDS, • sı´t’ove´ (realtime) IDS, • IDS spolupracujıćı´ s TCP/IP za´sobnı´kem operacˇnı´ho syste´mu.

Poslednı´ typ IDS syste´mu nenı´ v soucˇasne´ dobeˇ prˇ´ılisˇ beˇzˇny´. Na rozdı´l od prˇedchozıćh typu˚ analyzuje pakety jesˇteˇ prˇed tı´m, nezˇ jsou da´le zpracovańy v operacˇnı´m syste´mu a aplikacıćh, cozˇ umozˇnˇuje IDS potencia´lneˇ prosinec 2003




nebezpecˇne´ pakety zahazovat a zvysˇovat tı´m bezpecˇnost stroje cˇi cele´ sı´teˇ. Offline IDS jsou zvla´sˇtnı´ skupinou mezi IDS ˇresˇenı´mi, nemonitorujı´ sı´t’ovy´ provoz, ale logy syste´mu/programu˚. V neˇkteryćh ohledech jsou lepsˇ´ı nezˇ sı´t’ove´ IDS (pro sı´t’ova´ IDS je naprˇ. obtı´zˇneˇ urcˇitelne´, zda byl pokus o pru˚nik u´speˇsˇny´). Naproti tomu sı´t’ove´ IDS syste´my fungujı´ tak, zˇe monitorujı´ vesˇkery´ sı´t’ovy´ provoz a analyzujı´ ho. Jednotlive´ schopnosti a mozˇnosti IDS se lisˇ´ı. Nicmeńeˇ nejcˇasteˇjsˇ´ım cı´lem pozornosti IDS jsou pokusy o pru˚nik pomocı´ zna´meˇjsˇ´ıch na´stroju˚ vyuzˇ´ıvajıćıćh zna´myćh bezpecˇnostnıćh chyb, pokusy o skenovańı´ portu˚ a takte´zˇ neplatne´ pakety, ktere´ jsou cˇasto pouzˇ´ıvańy pro identifikaci pouzˇ´ıvane´ho operacˇnı´ho syste´mu cˇi obcha´zenı´ jednodusˇsˇ´ıch firewallu˚. IDS syste´my nemusı´ by´t omezeny pro detekci nebezpecˇne´ho provozu z venkovnıćh sı´tı´, stejneˇ tak dobrˇe mu˚zˇe by´t monitorovań provoz na loka´lnı´ sı´ti. To mu˚zˇe administra´toru poslouzˇit na detekci prˇ´ıpadnyćh proble´mu˚ na loka´lnı´ sı´ti – jako naprˇ. sˇ´ıˇrenı´ nejru˚zneˇjsˇ´ıch cˇervu˚. Mozˇne´ je i pouzˇitı´ jako na´stroje pro monitorovańı´ aktivity uzˇivatelu˚ – modernı´ IDS syste´my obsahujı´ naprˇ. pravidla pro detekci sı´t’ove´ho provozu generovane´ho ru˚zny´mi P2P syste´my. IDS tedy obecneˇ kontrolujı´ obsah paketu˚ a vlastnosti spojenı´. Jsou tedy o u´rovenˇ vy´sˇe nezˇ paketovy´ filtr zmıńeˇny´ v prˇedchozı´ kapitole. IDS rˇesˇenı´ na Linuxu

prosinec 2003

Jednı´m z nejzna´meˇjsˇ´ıch open source IDS syste´mu˚ pro Linux je bezpochyby SNORT. Jedna´ se o sı´t’ove´ IDS ˇresˇenı´. Podporuje detekci velke´ho mnozˇstvı´ sı´t’ove´ho




provozu pomocı´ prˇeddefinovanyćh pravidel. SNORT je navrzˇen natolik otevrˇeneˇ, zˇe nenı´ proble´m si do neˇj prˇidat dalsˇ´ı pravidla a tı´m si SNORT prˇizpu˚sobit. Samozrˇejmostı´ je te´zˇ obrana proti pokusu˚m o skrytı´ nebezpecˇne´ho sı´t’ove´ho provozu prˇed IDS (naprˇ. silne´ fragmentovańı´, zahlcovańı´ IDS pakety se zmeˇneˇny´mi zdrojovy´mi IP adresami obsahujıćı´mi data, ktera´ zpu˚sobı´ logovańı´ nepovolene´ho sı´t’ove´ho provozu u IDS atd.) Dalsˇ´ım velice dobry´m IDS na Linuxu je projekt LIDS. Jedna´ se o u´plneˇ jiny´ druh IDS nezˇ SNORT, LIDS je z veˇtsˇiny umı´steˇn v ja´drˇe a meˇnı´ standardnı´ bezpecˇnostnı´ model v Linuxu. LIDS umozˇnˇuje administra´torovi velmi podrobneˇ nastavit pro kazˇdou aplikaci ACL pra´va pro prˇ´ıstup k souborove´mu syste´mu, omezit jejı´ pouzˇ´ıvańı´ sı´teˇ atd. Kromeˇ toho poskytuje neˇktere´ za´kladnı´ sluzˇby sı´t’ove´ho IDS, jako naprˇ. detekci skenovańı´ portu˚. Nutno poznamenat, zˇe acˇkoliv LIDS velmi vy´razneˇ zveˇtsˇuje bezpecˇnost cele´ho syste´mu, jeho konfigurace je netrivia´lnı´ a nenı´ doporucˇovańa zacˇ´ınajıćı´m administra´toru˚m. Kromeˇ standardnıćh mozˇnostı´ zabezpecˇenı´ existuje jesˇteˇ neˇkolik patchu˚ ja´dra, ktere´ meˇnı´ standardnı´ bezpecˇnostnı´ syste´m. Tyto patche nahrazujı´ standardnı´ bezpecˇnostnı´ model vlastnı´m, vıće konfigurovatelny´m. Jednı´m z nejzna´meˇjsˇ´ıch podobnyćh patchu˚ je grsecurity. Ten zava´dı´ mozˇnost ACL pra´v na u´rovni procesu, kazˇde´mu procesu jsou prˇirˇazena zvla´sˇtnı´ pra´va k souborove´mu syste´mu. Da´le pak u kazˇde´ho procesu mu˚zˇeme nastavit, jaka´ pra´va (capabilities) bude mı´t dany´ proces v ja´drˇe. Pomocı´ tohoto patche a jeho vhodne´ho nakonfigurovańı´ je mozˇne´ vy´razneˇ zvy´sˇit bezpecˇnost syste´mu. Na veˇtsˇineˇ serveru˚ je spusˇteˇno veˇtsˇ´ı cˇi mensˇ´ı mnozˇstvı´ daemonu˚ (serveru˚).

Vysˇsˇ´ı metody zabezpecˇenı´ syste´mu

prosinec 2003




Neˇktere´ z nich musejı´ pracovat pod ućˇtem superuzˇivatele, protozˇe jinak by nemeˇly prˇ´ıstup k urcˇity´m funkcionalita´m operacˇnı´ho syste´mu (prˇ´ıkladem takove´ho serveru je naprˇ. SSHD) grsecurity a podobne´ patche ˇresˇ´ı proble´my s mozˇnou deˇravostı´ takovyćhto kritickyćh serveru˚ – i kdyzˇ se u´tocˇnı´kovi podarˇ´ı zı´skat dı´ky bezpecˇnostı´ chybeˇ v takove´mto serveru ućˇet root (cˇi jiny´ loka´lnı´ ućˇet), dı´ky grsecurity budou jeho mozˇnosti hodneˇ omezene´. Prˇi spra´vne´ konfiguraci ACL pra´v nebude mı´t mozˇnost zapsat do adresa´ˇru˚ s programy, nebude mı´t prˇ´ıstup k neˇktery´m funkcı´m ja´dra (jako naprˇ. natahovańı´ modulu˚, prˇ´ıstup k firewallu atd.). Je tudı´zˇ i po kompromitaci jednoho daemonu slusˇna´ sˇance, zˇe u´tocˇnı´k nebude moci kompromitovat cely´ syste´m. Grsecurity patch te´zˇ poskytuje velmi rozsa´hle´ mozˇnosti auditu, nenı´ u neˇj proble´m naprˇ. logovat vesˇkere´ aktivity neˇkteryćh uzˇivatelu˚ cˇi aktivit na syste´mu. Soucˇa´stı´ grsecurity je te´zˇ patch PaX, ktery´ se stara´ o ochranu pameˇti a zteˇzˇuje pokusy o zneuzˇitı´ chyb praće s pameˇtı´ (cozˇ jsou na UNIXech jedny z nejcˇasteˇjsˇ´ıch) pomocı´ neˇkolika technik (nespustitelne´ strańky, randomizace adresnı´ho prostoru aplikace, . . . ). Nicmeńeˇ grsecurity je pomeˇrneˇ slozˇity´ patch, jeho konfigurace netrivia´lnı´ a cˇasoveˇ na´rocˇna´, tudı´zˇ by ji meˇli prova´deˇt jen zkusˇeneˇjsˇ´ı administra´torˇi. Navıć platı´, zˇe samotna´ instalace grsecurity nestacˇ´ı, prˇedevsˇ´ım ACL pra´va a omezenı´ pra´v (capabilities) musı´ by´t vhodneˇ nastavena, jinak grsecurity zˇa´dne´ zvy´sˇenı´ bezpecˇnosti neprˇinese (cˇi naopak zpu˚sobı´ proble´my s beˇhem neˇkteryćh aplikacı´).

prosinec 2003




9/3.8 NESSUS

Zabezpecˇenı´ linuxove´ho serveru mu˚zˇe by´t pomeˇrneˇ na´rocˇna´ za´lezˇitost. Na typicke´m linuxove´m serveru beˇzˇ´ı pomeˇrneˇ znacˇna´ sbı´rka ru˚znyćh programu˚, v nichzˇ se cˇas od cˇasu mohou objevit bezpecˇnostnı´ chyby. Ale samotne´ pravidelne´ za´platovańı´ nestacˇ´ı, syste´m musı´ by´t neˇjaky´m rozumny´m zpu˚sobem nakonfigurovań, aby byl bezpecˇny´. Prˇi zabezpecˇovańı´ serveru je pomeˇrneˇ snadne´ neˇco opomenout. Proto existujı´ ru˚zne´ na´stroje, ktere´ mohou administra´torovi tuto u´lohu ulehcˇit. Prvnı´ na´stroj podobne´ho typu se objevil v polovineˇ devadesa´tyćh let a nesl poeticke´ oznacˇenı´ SATAN (Security Administrator Tool for Analyzing Networks), umozˇnˇoval hledat neˇkolik druhu˚ beˇzˇnyćh bezpecˇnostnıćh chyb na specifikovanyćh strojıćh.

Nessus

Od zacˇa´tku bylo jasne´, zˇe takovy´to na´stroj na jednu stranu sice prˇedstavuje zpu˚sob ulehcˇenı´ administrace, ale na druhou stranu poskytuje u´tocˇnı´kovi velmi prosinec 2003




jednoduchou mozˇnost, jak otestovat stroj, o jehozˇ kompromitaci se pokousˇ´ı, na prˇ´ıtomnost neˇkolika beˇzˇnyćh bezpecˇnostnıćh chyb. Nicmeńeˇ na na´stroj SATAN postupem cˇasu nava´zaly dalsˇ´ı podobne´ na´stroje. Jednı´m z nich je Nessus, ktery´ takte´zˇ prˇedstavuje urcˇity´ druh penetracˇnı´ho testu. Nessus je bezpecˇnostnı´ scanner. Umozˇnˇuje administra´torovi jednodusˇe otestovat bezpecˇnost sı´t’ovyćh sluzˇeb spusˇteˇnyćh na serveru. Nessus zjisˇt’uje, jake´ sluzˇby jsou na dane´m pocˇ´ıtacˇi spusˇteˇne´ a pak se pokousˇ´ı o zjisˇteˇnı´ (prˇesneˇji veˇtsˇinou se pokousˇ´ı o jejich zneuzˇitı´) neˇkteryćh zna´myćh bezpecˇnostnıćh chyb v nich. Kromeˇ toho je schopen detekovat naprˇ. prˇ´ıtomnost neˇkteryćh backdooru˚ (samozrˇejmeˇ jen teˇch, ktere´ lze detekovat prˇes sı´t’) a prova´deˇt dalsˇ´ı bezpecˇnostnı´ audit. Na za´veˇr administra´torovi sestavı´ podrobny´ report, kde jsou popsańa jednotliva´ zjisˇteˇna´ bezpecˇnostnı´ rizika. Cˇasto te´zˇ doplnı´ instrukce, jak zneuzˇitı´ te´to chyby zabrańit, poprˇ. i odkaz na podrobneˇjsˇ´ı informace (naprˇ. konference bugtraq, databa´ze bezpecˇnostnıćh chyb CVE cˇi CERT). To administra´torovi umozˇnˇuje pomeˇrneˇ rychle a jednodusˇe otestovat bezpecˇnostnı´ stav svyćh serveru˚. Nicmeńeˇ je nutno poznamenat, zˇe Nessus zdaleka nenı´ na´strojem neomylny´m a vsˇeodhalujıćı´m. Spı´sˇe se jedna´ o pomu˚cku, ktera´ mu˚zˇe administra´torovi usnadnit zabezpecˇovańı´ serveru˚. Co cˇinı´ Nessus zajı´mavy´m oproti ostatnı´m podobny´m produktu˚m? Prˇedevsˇ´ım se jedna´ o velice uceleny´ produkt schopny´ detekovat velmi sˇirokou sˇka´lu bezpecˇnostnıćh proble´mu˚. Je postaven na architekturˇe klient-server, ze serveru probı´ha´ ono scannovańı´, jeho pru˚beˇh je nicmeńeˇ ˇr´ızen klientem. Server je provozuschopny´ na velke´m mnozˇstvı´ UNIXovyćh operacˇnıćh syste´mu˚, tudı´zˇ samozrˇejmeˇ i na Linuxu. Stejneˇ tak i prosinec 2003




klient je k dispozici pro mnoho platforem, dokonce existuje i klient pro platformu Microsoft Windows. Dalsˇ´ı nespornou vy´hodou scanneru Nessus je jeho snadna´ rozsˇirˇitelnost. Umozˇnˇuje snadne´ prˇidańı´ dalsˇ´ıch testu˚ pomocı´ za´suvnyćh modulu˚ napsanyćh v jazyce C. Da´le pak umozˇnˇuje implementaci dalsˇ´ıch testu˚ v jazyce NASL (Nessus Attack Scripting Language). Nessus se prˇi scannovańı´ snazˇ´ı by´t co nejvıće du˚sledny´ – neprˇedpokla´da´ prˇ´ıtomnost urcˇityćh sluzˇeb na pevneˇ danyćh portech (naprˇ. http server na portu 80), takte´zˇ nehledı´ na zjisˇteˇne´ verze softwaru. Nessus se automaticky snazˇ´ı zjistit, jaka´ sluzˇba beˇzˇ´ı na dane´m portu a podle toho volı´ prˇ´ıslusˇne´ testy. Instalaci produktu Nessus musı´me prova´deˇt pod uzˇivatelem root.

Instalace

Existujı´ v podstateˇ trˇi mozˇnosti, jak nainstalovat Nessus. Prvnı´ a nejjednodusˇsˇ´ı je instalace balı´ku vytvorˇene´ho pro danou distribuci. Takovy´ balı´k je naprˇ. k dispozici pro Debian. Dalsˇ´ı mozˇnostı´ je kompilace. Ta mu˚zˇe by´t provedena bud’ automaticky pomocı´ skriptu nebo manua´lneˇ. Onen skript i samostatne´ zdrojove´ soubory klientske´ i serverove´ cˇa´sti mu˚zˇeme sta´hnout z www.nessus.org. Pro kompilaci pomocı´ skriptu sta´hneme z teˇchto strańek skript nessus-installer.sh, ktery´ na´sledneˇ spustı´me. Skript se zepta´ na neˇkolik informacı´, naprˇ. kam chceme Nessus nainstalovat, a automaticky spustı´ kompilaci. Nicmeńeˇ je mozˇne´, zˇe skript nahla´sı´ neprˇ´ıtomnost neˇkteryćh knihoven (naprˇ. GTK), v takove´m prˇ´ıpadeˇ musı´me doinstalovat prˇ´ıslusˇne´ balıćˇky. Je nutne´ nainstalovat jak balı´ky obsahujıćı´ ony knihovny, tak prˇ´ıslusˇne´ vy´vojove´ (devel) balı´ky k nim. prosinec 2003




Po u´speˇsˇne´ kompilaci spustı´me na stroji, kde budeme chtı´t provozovat serverovou cˇa´st, program nessus-mkcert. Tento skript slouzˇ´ı k vygenerovańı´ X.509 certifika´tu serveru. Certifika´t se pouzˇ´ıva´ k autentizaci serveru prˇi prˇipojenı´ z klienta (ochrana proti man-in-the-middle u´toku˚m). Vesˇkera´ komunikace mezi klientem a serverem probı´ha´ sˇifrovaneˇ pomocı´ protokolu SSL. Pro prˇ´ıstup k serverove´ cˇa´sti Nessus je nutno vytvorˇit uzˇivatelske´ ućˇty v jeho databa´zi (tito uzˇivatele´ nepotrˇebujı´ norma´lnı´ ućˇet na dane´m stroji). Opra´vneˇnı´ jednotlivyćh uzˇivatelu˚ se mohou lisˇit, stejneˇ tak je mozˇno omezit stroje, u nichzˇ mohou prova´deˇt bezpecˇnostnı´ audit pomocı´ tohoto na´stroje. K vytvorˇenı´ uzˇivatelu˚ slouzˇ´ı program nessus-adduser. Opeˇt se jedna´ o interaktivnı´ program, ktery´ se zepta´ na vsˇechny potrˇebne´ u´daje. Podrobneˇjsˇ´ı informace naleznete v cˇa´sti „Spra´va uzˇivatelu˚“. Pouzˇitı´

Jak jizˇ bylo ˇrecˇeno, Nessus funguje na architekturˇe klient-server. Pro jeho pouzˇitı´ tudı´zˇ musı´me nejprve na neˇjake´m stroji pustit serverovou cˇa´st – program nessusd. Tento program musı´ by´t spusˇteˇny´ pod uzˇivatelem root. Klientskou cˇa´st spustı´me pomocı´ prˇ´ıkazu nessus. Po spusˇteˇnı´ se na´m objevı´ za´kladnı´ obrazovka, v nı´zˇ mu˚zˇeme specifikovat, na ktere´m stroji je spusˇteˇna serverova´ cˇa´st Nessusu a prˇihlasˇovacı´ informace.

prosinec 2003




Obra´zek: Nessus – klient:

O

Po prˇihla´sˇenı´ na´m Nessus nabı´dne mozˇnost urcˇit, jake´ testy majı´ by´t provedeny. Pro prˇehlednost jsou rozdeˇleny do neˇkolika kategoriı´: kdyzˇ klikneme na na´zev testu, tak se zobrazı´ podrobne´ informace o dane´m testu. Na dalsˇ´ı karteˇ je mozˇne´ nastavit mnoho parametru˚ scanu. Jako prvnı´ mu˚zˇeme nastavit parametry scanu prova´deˇne´ho na´strojem nmap. To je pomeˇrneˇ vyspeˇly´ na´stroj slouzˇ´ıcı´ kromeˇ jine´ho ke zjisˇteˇnı´ otevrˇenyćh prosinec 2003




portu˚ (u protokolu TCP, omezeneˇ i UDP) na dane´m stroji. Pro veˇtsˇinu situacı´ nastavı´me metodu scannovańı´ portu˚ bud’ na connect() nebo SYN scan. Metoda connect() scan je nejbeˇzˇneˇjsˇ´ı typ scannovańı´ portu˚ – nmap se prˇi neˇm pokousˇ´ı o prˇipojenı´ na dany´ port striktneˇ podle RFC. Naproti tomu prˇi SYN scanu nenı´ procedura otevrˇenı´ portu provedena striktneˇ azˇ do konce – cˇ´ımzˇ mu˚zˇe zabrańit zalogovańı´ onoho pokusu o spojenı´ u jednodusˇsˇ´ıch firewallu˚. Operacˇnı´ syste´m vzda´lenoho stroje mu˚zˇe by´t te´zˇ detekovań pomocı´ typicke´ho chovańı´ jeho TCP/IP za´sobnı´ku. To mu˚zˇe by´t nezˇa´doucı´, cˇ´ım meńeˇ informacı´ ma´ potencia´lnı´ u´tocˇnı´k o stroji, tı´m je mensˇ´ı sˇance, zˇe se mu podarˇ´ı prove´st u´speˇsˇny´ pru˚nik. Nessus na´m nabı´zı´ volbu „Identify the remote OS“, po jejı´m zasˇkrtnutı´ se prostrˇednictvı´m na´stroje nmap pokusı´ vydedukovat operacˇnı´ syste´m dane´ho stroje. Da´le mu˚zˇeme nastavit rozsah portu˚, ktere´ se majı´ scannovat. Krom scanu vsˇech portu˚ v rozsahu zadane´m na dalsˇ´ı karteˇ je mozˇne´ scannovat pouze porty, na kteryćh beˇzˇneˇ posloucha´ neˇjaky´ program. Takove´to porty jsou ulozˇeny v souboru nmap-services, spolu s popisem daemonu, jenzˇ tento port beˇzˇneˇ vyuzˇ´ıva´. Dalsˇ´ı mozˇnostı´ je scannovańı´ vsˇech portu˚ v te´to databa´zi a jesˇteˇ vsˇech privilegovanyćh portu˚. Privilegovane´ porty jsou takove´, ktere´ majı´ cˇ´ıslo mensˇ´ı nezˇ 1024. Na teˇchto portech mu˚zˇe poslouchat jen daemon spusˇteˇny´ s pra´vy roota. Volba „Timing policy“ urcˇuje rychlost scanu. Ve veˇtsˇineˇ prˇ´ıpadu˚ mu˚zˇeme nastavit rychlost na nejvysˇsˇ´ı mozˇne´ nastavenı´ – „Insane“. Vy´jimkou je ovsˇem situace, kdy ma´me na dane´m stroji nainstalovany´ neˇjaky´ firewall, ktery´ ma´ ochranu proti DoS u´toku˚m a zahazuje pakety, pokud prˇicha´zejı´ prˇ´ılisˇ rychle z jednoho stroje. prosinec 2003




Pozornost da´le veˇnujme cˇa´sti Login configurations, pro neˇktere´ scany je nutne´ nastavit platne´ uzˇivatelske´ jmeńo pro dane´ sluzˇby. Obra´zek: Nessus – nastavenı´ uzˇivatelskyćh jmen:

O

Na dalsˇ´ı karteˇ nalezneme mozˇnost nastavit rozsah portu˚, ktery´ se bude scannovat. Prˇi pouzˇitı´ daemonu, ktery´ pracuje na neˇjake´m nestandardnı´m portu, budeme muset pravdeˇpodobneˇ zveˇtsˇit standardneˇ nastaveny´ rozsah. Za zmıńku stojı´ volba „Designate hosts by their MAC address“, ktera´ urcˇ´ı, zˇe Nessus bude identifikovat jednotlive´ scannovane´ stroje podle jejich MAC adresy mı´sto IP adresy. Tato volba je uzˇitecˇna´, pokud prosinec 2003




prova´dı´me scannovańı´ sı´teˇ, v nı´zˇ se IP adresy prˇideˇlujı´ dynamicky pomocı´ DHCP. Nessus ma´ dveˇ mozˇnosti, jak zjistit, zda dany´ software obsahuje bezpecˇnostnı´ chybu – prvnı´ mozˇnostı´ je pokusit se o jejı´ zneuzˇitı´ a druhou je urcˇenı´ mozˇne´ prˇ´ıtomnosti chyby podle zjisˇteˇne´ verze dane´ho softwaru. Prvnı´ metoda je o poznańı´ spolehliveˇjsˇ´ı, nicmeńeˇ mu˚zˇe zpu˚sobit pa´d dane´ sluzˇby, pokud skutecˇneˇ danou bezpecˇnostnı´ chybu obsahuje. Druha´ mozˇnost je bezpecˇneˇjsˇ´ı, ale na druhou stranu nenı´ schopna poznat, zˇe naprˇ. dany´ software obsahuje za´platu opravujıćı´ danou bezpecˇnostı´ chybu, a tak mu˚zˇe dojı´t k falesˇny´m poplachu˚m. Ve veˇtsˇineˇ prˇ´ıpadu˚ je lepsˇ´ı pouzˇ´ıt prvnı´ mozˇnost, je spolehliveˇjsˇ´ı, a pokud dojde k shozenı´ sluzˇby, tak se ve veˇtsˇineˇ prˇ´ıpadu˚ nic azˇ tak kriticke´ho nestane, kdyzˇ ji vlastneˇ takto mohl shodit (nebo rovnou kompromitovat) jaky´koliv u´tocˇnı´k se sı´t’ovy´m prˇ´ıstupem k serveru. Ovsˇem za´lezˇ´ı na druhu bezpecˇnostnı´ chyby – v ojedineˇlyćh prˇ´ıpadech mu˚zˇe dojı´t k pa´du cele´ho syste´mu cˇi neˇktere´ zˇivotneˇ du˚lezˇite´ sluzˇby (naprˇ. sshd, cozˇ by administra´toru ve veˇtsˇineˇ prˇ´ıpadu˚ znemozˇnilo vzda´leny´ prˇ´ıstup na server). Na te´to karteˇ te´zˇ mu˚zˇeme nastavit maxima´lnı´ pocˇet stroju˚, ktere´ majı´ by´t scannovańy za´rovenˇ, a maxima´lnı´ pocˇet testu˚, ktere´ mohou by´t za´rovenˇ spusˇteˇny prˇi scanu jednoho stroje. Prˇ´ılisˇ vysoke´ hodnoty se nedoporucˇujı´. Na dalsˇ´ı karteˇ mu˚zˇeme konecˇneˇ nastavit, jake´ stroje chceme scannovat. Mu˚zˇeme specifikovat IP adresu jednoho stroje nebo rozsah v syntaxi pocˇa´tecˇnı´ IP – koncova´ IP (naprˇ. 172.16.17.1-172.16.17.3). Pak jizˇ nic nebrańı´ pustit scan. Ten veˇtsˇinou bude trvat mnoho minut. Po jeho u´speˇsˇne´m dokoncˇenı´ Nessus prosinec 2003




zobrazı´ vy´sledky. Zobrazı´ otevrˇene´ porty na dane´m stroji a poprˇ. i jmeńa sluzˇeb na nich nalezenyćh. Tento vy´sledny´ report mu˚zˇeme exportovat do mnoha forma´tu˚, naprˇ. HTML cˇi LaTEX. Prˇi nalezenı´ bezpecˇnostnı´ho proble´mu vypı´sˇe prˇ´ıslusˇne´ varovańı´. Obra´zek: Nessus – vy´sledky testu:

Prˇi vytva´ˇrenı´ na´stroje Nessus byl brań zrˇetel i na to, zˇe jeden server mu˚zˇe by´t pouzˇ´ıvań vıće nezˇ jednı´m uzˇivatelem. A tito uzˇivatele´ nemusejı´ mı´t stejne´ pravomoci. Uzˇivatele se deˇlı´ na norma´lnı´ a administra´torske´. Ti s pra´vy administra´tora majı´ prˇedevsˇ´ım pra´vo nahra´vat nove´ scannovacı´ pluginy do globa´lnıćh adresa´ˇru˚ s pluginy, jezˇ jsou samozrˇejmeˇ sdı´leny vsˇemi uzˇivateli. Beˇzˇny´ uzˇivatel mu˚zˇe pluginy nahra´vat pouze do sve´ho adresa´ˇre. Da´le ma´ kazˇdy´ uzˇivatel nastaveno, jake´ stroje smı´ cˇi nesmı´ scannovat z tohoto serveru.

O

Spra´va uzˇivatelu˚

prosinec 2003




Teˇmto nastavenı´m je nutne´ veˇnovat pozornost zejmeńa v prˇ´ıpadeˇ, zˇe nessusd je pusˇteˇny´ na neˇjake´ verˇejne´ IP a ma´ k neˇmu prˇ´ıstup vıće uzˇivatelu˚. Naprˇ. pokud bychom meˇli nessusd pusˇteˇny´ na serveru, ktery´ je za´rovenˇ NAT pro loka´lnı´ sı´t’, tak by bez dalsˇ´ıch nastavenı´ vsˇichni uzˇivatele´ s ućˇtem na nessusd mohli oscannovat naprˇ. i celou loka´lnı´ sı´t’, pro kterou deˇla´ onen stroj NAT. Rˇesˇenı´m by tedy bylo zaka´zat scan adresnı´ho rozsahu loka´lnı´ sı´teˇ. V prˇ´ıpadeˇ obav o to, zˇe by uzˇivatele´ mohli pouzˇ´ıt tento nessusd na oscannovańı´ neˇjake´ho cizı´ho stroje (u ktere´ho by se pochopitelneˇ v logu objevila IP onoho stroje s nessusd), mu˚zˇeme naprˇ. scan omezit na IP, z ktere´ se aktua´lneˇ prˇipojujı´ nessusd. Dalsˇ´ı veˇcı´, kterou mu˚zˇeme u kazˇde´ho uzˇivatele nastavit, je autentizacˇnı´ metoda. Kazˇdy´ uzˇivatel se mu˚zˇe autentizovat bud’ nastaveny´m heslem nebo pomocı´ certifika´tu. Certifika´t pochopitelneˇ prˇedstavuje bezpecˇneˇjsˇ´ı zpu˚sob autentizace, ale v praxi se u na´stroje Nessus prˇ´ılisˇ nepouzˇ´ıva´. Jednotlive´ uzˇivatele mu˚zˇeme prˇida´vat pomocı´ programu nessus-adduser. Jedna´ se o interaktivnı´ program, ktery´ se zepta´ na uzˇivatelske´ jmeńo, autentizacˇnı´ metodu, heslo, poprˇ. dname (distinguished name) certifika´tu. Da´le na´m umozˇnı´ omezit pra´va dane´ho uzˇivatele pomocı´ neˇkolika pravidel. Syntaxe teˇchto pravidel je: accept/deny IP/maska default deny/accept Jak jizˇ je jasne´ z na´zvu, direktiva accept specifikuje subsı´t’, kterou mu˚zˇe uzˇivatel scannovat a deny naopak zakazuje. Direktivou default mu˚zˇeme urcˇit, zda ma´

prosinec 2003




uzˇivatel pra´vo scannovat vsˇechny stroje kromeˇ zaka´zanyćh (volba accept), cˇi naopak ma´ pra´vo scannovat pouze explicitneˇ povolene´ subsı´teˇ. Mı´sto IP adresy a masky mu˚zˇeme pouzˇ´ıt volbu client ip, ktera´ bude v pravidlu znacˇit IP adresu klienta, z ktere´ se prˇipojuje. Prˇ´ıklad pravidel pro povolenı´ scanu vlastnı´ IP adresy a subsı´teˇ 172.16.17.0/24: accept 172.16.17.0/24 accept client\_ip default deny Dalsˇ´ım na´strojem pro praći s uzˇivatelskou databa´zı´ je nessus-rmuser, pomocı´ neˇjzˇ mu˚zˇeme zrusˇit existujıćı´ho uzˇivatele. Meˇjme modelovou loka´lnı´ sı´t’, na ktere´ je linuxovy´ server obstara´vajıćı´ DNS, posˇtu, SSH a IMAP server. Server je prˇipojeny´ do sı´teˇ Internet a funguje jako NAT (Network Address Translation) pro loka´lnı´ sı´t’. Tento stroj bude mı´t IP adresu 172.16.17.1. Da´le bude na nasˇ´ı modelove´ sı´ti stroj s IP adresou 172.16.17.3 s nainstalovany´m operacˇnı´m syste´mem firmy Microsoft. Stroj je pouzˇ´ıvań pro beˇzˇnou administrativnı´ praći, nenı´ na neˇm provozovańa zˇa´dna´ sluzˇba. Poslednı´ stroj v te´to sı´ti bude mı´t IP 172.16.17.2, bude na neˇm beˇzˇet Linux a takte´zˇ to bude stroj, z ktere´ho budeme pousˇteˇt scan. Cı´lem scanu bude prove´st za´kladnı´ bezpecˇnostnı´ audit stroju˚ na lokalnı´ sı´ti.

Prˇ´ıklad pouzˇitı´ na´stroje Nessus

Na stroji 172.16.17.2 pustı´me nmapd a vytvorˇ´ıme uzˇivatele pomocı´ utility nessus-adduser. Spustı´me klientskou cˇa´st (nessus). Na karteˇ „Target selection“ zada´me v poli „Target(s)“ masku sı´teˇ, kterou chceme

prosinec 2003




scannovat. Jelikozˇ IP adresy stroju˚ te´to sı´teˇ jsou v rozsahu 172.16.17.1 azˇ v 172.16.17.3 vcˇetneˇ, mu˚zˇeme zadat masku sı´teˇ jako 172.16.17.0/29. Pak se ovsˇem bude scannovat vıće IP, nezˇ kolik skutecˇneˇ ma´me na te´to sı´ti stroju˚. Lepsˇ´ı je tudı´zˇ pouzˇ´ıt druhe´ho zpu˚sobu za´pisu a zadat tedy rozsah 172.16.17.1-172.16.17.3. Na karteˇ „Scan options“ prˇepı´sˇeme rozsah scannovanyćh portu˚ na 1-65535. Zvy´sˇ´ı se tı´m sice doba scanu, ale na druhou stranu tı´m mu˚zˇeme odchytit sluzˇby poslouchajıćı´ na vysokyćh portech. Odsˇkrtneme volbu „Safe checks“, abychom dosta´vali prˇesneˇjsˇ´ı vy´sledky i za cenu rizika, zˇe mu˚zˇe eventua´lnı´ deˇrava´ sluzˇba spadnout. Dole v polozˇkaćh „Port scanner“ necha´me zasˇkrtly´ pouze na´stroj nmap. Na karteˇ „Prefs“ veˇnujme pozornost volba´m pro nmap. Zapneme SYN scan a volbu „Identify the remote OS“, abychom videˇli, zda je nmap schopen identifikovat TCP/IP za´sobnı´k na dane´m stroji. Zapnutı´m volby „Fragment IP packets“ te´zˇ protestujeme, jak si dane´ firewally poradı´ s fragmentovany´mi IP pakety (cozˇ je jedna z nejstarsˇ´ıch technik obcha´zenı´ pravidel firewallu). Jelikozˇ na strojıćh nepouzˇ´ıva´me zˇa´dne´ anti-DoS nastavenı´ firewallu, ktere´ by zpu˚sobovalo zahazovańı´ paketu˚ prˇicha´zejıćıćh ve velkyćh kvantech z jednoho stroje, nastavı´me „Timing policy“ na hodnotu „Insane“, cozˇ vy´razneˇ urychlı´ cely´ scan. Aby mohl Nessus efektivneˇ otestovat IMAP server, nastavı´me v cˇa´sti „Login configurations“ platne´ uzˇivatelske´ jmeńo a heslo pro posˇtovnı´ ućˇet, na ktere´m budeme IMAP testovat. Dalsˇ´ı karta je pojmenovana´ „Plugins“ a v nı´ odsˇkrtneme neˇktere´ pluginy, ktere´ jsou evidentneˇ zbytecˇne´. Je zcela zbytecˇne´ testovat naprˇ. na bezpecˇnostnı´ proble´my platformy Netware cˇi CISCO, kdyzˇ se zˇa´dny´ prosinec 2003




produkt takovyćhto spolecˇnostı´ v nasˇ´ı sı´ti nevyskytuje. Nynı´ mu˚zˇeme pustit scan. Pru˚meˇrny´ scan trva´ mnoho minut. Obra´zek: Vy´sledky scanu:

O

Ve vy´sledcıćh scanu se na´m objevil pouze stroj 172.16.17.1, u ostatnıćh stroju˚ nevygeneroval Nessus zˇa´dne´ varovańı´ (cozˇ ukazuje, zˇe konfigurace firewallu˚ teˇchto dvou pracovnıćh stanic je v porˇa´dku). Podı´vejme se ovsˇem na stroj 172.16.17.1. Zde u DNS serveru (bind) Nessus vygeneroval hla´sˇenı´ o prˇ´ıtomnosti bezpecˇnostnı´ chyby. Veˇnujme tedy pozornost one´ zpra´veˇ (viz obra´zek).

prosinec 2003




O

Obra´zek: Hla´sˇenı´ o bezpecˇnostnı´ chybeˇ v DNS serveru:

Jak je patrno ze zpra´vy, toto zjisˇteˇnı´ provedl Nessus cˇisteˇ na za´kladeˇ zjisˇteˇne´ verze Bindu. Tudı´zˇ nemohl zaregistrovat, zˇe na serveru je ve skutecˇnosti nainstalovańa verze se za´platou opravujıćı´ tuto bezpecˇnostnı´ chybu. Nicmeńeˇ pozornost bychom meˇli veˇnovat sluzˇbeˇ sunrpc beˇzˇ´ıcı´ na portu 111 (tcp). Jedna´ se o tzv. mapovacˇ portu˚ pro RPC sluzˇby. Prˇ´ıkladem RPC sluzˇeb je naprˇ. NFS. Na onom modelove´m serveru ale nenı´ zˇa´dna´ RPC sluzˇba nutna´, tudı´zˇ mapovacˇ portu˚ na neˇm beˇzˇ´ı zcela zbytecˇneˇ a z bezpecˇnostnıćh du˚vodu˚ by meˇl by´t vypnut. Tote´zˇ platı´ i o RPC sluzˇbeˇ beˇzˇ´ıcı´ na UDP portu 1189. Ve znacˇne´ cˇa´sti distribucı´ jsou po standardnı´ instalaci zapnuty a spusˇteˇny ru˚zne´ sı´t’ove´ sluzˇby, jako je naprˇ. mapovacˇ portu˚. Jejich ponechańı´ na serveru je jedna z nejcˇasteˇjsˇ´ıch chyb, kteryćh se dopousˇteˇjı´ zacˇ´ınajıćı´ administra´torˇi. Takove´to zbytecˇne´ sluzˇby snizˇujı´ bezpecˇnost cele´ho syste´mu, protozˇe nenı´ mozˇno vyloucˇit,

prosinec 2003




zˇe v nich nenı´ neˇjaka´ bezpecˇnostnı´ dı´ra, a tudı´zˇ potencia´lneˇ da´vajı´ u´tocˇnı´kovi mozˇnost pru˚niku na server. Obecneˇ platı´, zˇe na kazˇde´m serveru by meˇly by´t spusˇteˇny jen ty sluzˇby, ktere´ skutecˇneˇ budou vyuzˇ´ıvańy. Da´le se ve varovańıćh programu Nessus nacha´zı´ zpra´va o tom, zˇe je mozˇne´ prˇes neˇj posı´lat rekurzivnı´ DNS dotazy, cozˇ jsou dotazy na domeńova´ jmeńa, ktere´ nemu˚zˇe DNS server sa´m zodpoveˇdeˇt, a proto je musı´ prˇelozˇit za pomoci nadrˇazenyćh jmennyćh serveru˚. Ovsˇem v nasˇem prˇ´ıpadeˇ slouzˇ´ı tento stroj jako DNS server pro loka´lnı´ sı´t’(ostatnı´ stroje prˇekla´dajı´ domeńova´ jmeńa pomocı´ neˇj), tudı´zˇ je nutne´ mı´t rekurzivnı´ dotazy povolene´. Samozrˇejmeˇ by meˇl by´t prˇ´ıstup na DNS server na tomto serveru zaka´zań z venku pomocı´ firewallu (cˇi nastavenı´ onoho DNS serveru). Na za´veˇr nutno opeˇt poznamenat, zˇe Nessus nenı´ na´strojem neomylny´m a zejmeńa kontroly prova´deˇne´ na za´kladeˇ zjisˇteˇne´ verze dane´ho daemonu mohou by´t velmi neprˇesne´. Rozhodneˇ nenı´ vsˇele´kem na bezpecˇnost a nenahrazuje administra´toru˚v dohled nad serverem, spousta bezpecˇnostnıćh rizik zu˚stane prˇed jeho zrakem z principu zcela skryta – prˇ´ıkladem takovyćh bezpecˇnostnıćh rizik mohou by´t vsˇechny loka´lnı´ bezpecˇnostnı´ chyby. A nad nimi si administra´tor v drtive´ veˇtsˇineˇ prˇ´ıpadu˚ nemu˚zˇe dovolit maćhnout rukou. Naprˇ´ıklad v minulosti bylo v ja´drˇe Linuxu objeveno neˇkolik kritickyćh loka´lnıćh bezpecˇnostnıćh chyb, ktere´ umozˇnˇovaly loka´lnı´m uzˇivatelu˚m zı´skat ućˇet uzˇivatele root. A navıć ani to, zˇe na dane´m stroji nemajı´ zˇa´dnı´ dalsˇ´ı uzˇivatele´ ućˇet (poprˇ. ućˇet majı´ jen du˚veˇryhodnı´), nenı´ za´rukou nezneuzˇitelnosti podobnyćh chyb – u´tocˇnı´k mu˚zˇe pro zı´skańı´ neprivilegovane´ho ućˇtu pouzˇ´ıt bezpecˇnostnıćh deˇr v jinyćh spusˇteˇnyćh daemonech (cˇi trˇeba skriptech, pokud se jedna´ o www server).

Za´veˇrem

prosinec 2003




Navıć je nutno si uveˇdomit, zˇe Nessus a podobne´ dalsˇ´ı na´stroje mohou by´t pouzˇity u´tocˇnı´kem proti va´m – stejny´m zpu˚sobem, jako vy testujete bezpecˇnost sve´ho serveru mu˚zˇe by´t „odzkousˇena“ bezpecˇnost ktere´hokoliv jine´ho stroje v sı´ti Internet. Nessus tedy prˇedstavuje pomeˇrneˇ uzˇitecˇny´ penetracˇnı´ test, ktery´ mu˚zˇe administra´torovi o neˇco usnadnit otestovańı´ bezpecˇnosti serveru.

prosinec 2003




9/3.9 TRIPWIRE

I prˇes vsˇechny snahy administra´tora nenı´ nikdy mozˇne´ vyloucˇit, zˇe bude jı´m spravovany´ stroj kompromitovań. Nemusı´ se prˇitom jednat ani o selhańı´ administra´tora, v dnesˇnı´ dobeˇ existujı´ naprˇ. tzv. black hat komunity, skupiny lidı´ s velmi vysokou znalostı´ IT bezpecˇnosti zaby´vajıćıćh se prˇedevsˇ´ım hledańı´m bezpecˇnostnıćh deˇr v existujıćı´m softwaru a jejich na´sledny´m vyuzˇ´ıvańı´m ve vlastnı´ prospeˇch (bez uverˇejneˇnı´ zpra´vy o objevenı´ chyby). Cˇasto se spekuluje o tom, zda black hat komunita veˇdeˇla o pra´veˇ objevene´m bezpecˇnostnı´m proble´mu jizˇ drˇ´ıve. Tı´m se tato komunita zcela odlisˇuje od jinyćh skupin lidı´, kterˇ´ı jsou me´dii cˇasto oznacˇovańi jako hackerˇi – zde se jedna´ o skutecˇne´ experty schopne´ hledat bezpecˇnostnı´ chyby a zneuzˇ´ıvat je.

Tripwire

Ani velice vcˇasne´ za´platovańı´ softwaru tedy nezarucˇuje se 100% jistotou, zˇe stroj nemu˚zˇe by´t kompromitovań. A v praxi je situace jesˇteˇ o neˇco horsˇ´ı. Ma´loktery´ prosinec 2003




administra´tor prova´dı´ za´platovańı´ chvı´li pote´, co je objevena bezpecˇnostnı´ dı´ra. V prˇ´ıpadeˇ, zˇe se u´tocˇnı´kovi povede zneuzˇitı´ neˇjake´ bezpecˇnostnı´ chyby a zı´ska´ za´rovenˇ i pra´va uzˇivatele root, co pravdeˇpodobneˇ na stroji udeˇla´? Veˇtsˇina u´tocˇnı´ku˚ si na stroj nainstaluje neˇjaka´ zadnı´ vra´tka, pomocı´ kteryćh se v budoucnosti mohou na stroj dostat. Mnoho u´tocˇnı´ku˚ pouzˇ´ıva´ kompromitovane´ stroje jako efektivnı´ anonymize´ry pouzˇ´ıvane´ k provedenı´ dalsˇ´ıch u´toku˚. Mozˇnostı´, jak takova´to zadnı´ vra´tka (backdoor, rootkit) vytvorˇit, je mnoho. Jednou z mozˇnostı´ je umı´steˇnı´ rootkitu do ja´dra. To samozrˇejmeˇ vyzˇaduje pra´va uzˇivatele root a ve veˇtsˇineˇ prˇ´ıpadu˚ i podporu modulu˚ v ja´drˇe. Ovsˇem vypnutı´m podpory dynamickyćh modulu˚ v ja´drˇe proble´m neodstranı´me, kernel mu˚zˇe by´t modifikovań i pomocı´ zarˇ´ızenı´ /dev/kmem, ktery´ obsahuje mapovanou pameˇt’ja´dra. Takovy´ ko´d v ja´drˇe mu˚zˇe by´t velmi nebezpecˇny´, mu˚zˇe efektivneˇ maskovat procesy u´tocˇnı´ka cˇi soubory jı´m zmeˇneˇne´ cˇi rovnou slouzˇit jako backdoor do syste´mu. Dalsˇ´ı mozˇnostı´, ktera´ je pomeˇrneˇ cˇasto vyuzˇ´ıvańa, je instalace pozmeˇneˇnyćh programu˚, ktere´ obsahujı´ prˇ´ıslusˇny´ backdoor, poprˇ. jesˇteˇ vy´meˇna za´kladnıćh utilit jako ps cˇi netstat za verze, ktere´ maskujı´ u´tocˇnı´kem pouzˇ´ıvane´ procesy a sokety. Kombinace obou technik se nevylucˇuje, ba naopak. Jak se tedy brańit? To mu˚zˇe by´t obtı´zˇne´. Jednı´m ˇresˇenı´m jsou bezpecˇnostnı´ patche jako LIDS cˇi grsecurity, ktere´ vy´razneˇ omezujı´ pravomoci spusˇteˇnyćh programu˚, a tudı´zˇ prˇ´ıpadne´mu u´speˇsˇne´mu u´tocˇnı´kovi zteˇzˇujı´ cˇi dokonce zcela znemozˇnˇujı´ kompromitovat cely´ syste´m. Tyto patche krom jine´ho dany´m programu˚m

prosinec 2003




umozˇnˇujı´ nastavit specificka´ prˇ´ıstupova´ pra´va k souborove´mu syste´mu, zmeˇnit jejich pra´va (capabilities) atd. Dalsˇ´ım druhem ochrany, ktery´ se samozrˇejmeˇ nevylucˇuje s prvnı´ mozˇnostı´ (ba naopak, jejich kombinace zajisˇt’uje velice slusˇnou da´vku bezpecˇnosti), jsou na´stroje na kontrolu integrity souboru˚. Tyto na´stroje nemajı´ nic spolecˇne´ho s na´stroji na kontrolu integrity souborove´ho syste´mu, jako je naprˇ. fsck. Jejich u´kolem je udrzˇovat databa´zi souboru˚ v urcˇenyćh adresa´ˇr´ıch. Takova´to databa´ze kromeˇ jine´ho obsahuje velikost souboru, cˇas poslednı´ho prˇ´ıstupu k neˇmu, hashovacı´ hodnotu a dalsˇ´ı podobne´ u´daje. Porovnańı´m hodnot z databa´ze oproti hodnota´m souboru˚ na souborove´m syste´mu je mozˇno efektivneˇ zjistit, zda soubor byl cˇi nebyl modifikovań. Nicmeńeˇ tato technika ma´ mnoho nedostatku˚ a jednı´m z nejvy´znamneˇjsˇ´ıch je skutecˇnost, zˇe pomineme-li mozˇnost mı´t databa´zi na neˇjake´m me´diu jen pro cˇtenı´ (naprˇ. disk cdrom), tak u´tocˇnı´kovi nic nebrańı´ databa´zi upravit tak, aby obsahovala hodnoty jı´m zmeˇneˇnyćh souboru˚. Tudı´zˇ je nutne´ neˇjaky´m zpu˚sobem zajistit integritu databa´ze. Na cˇa´stecˇne´ ˇresˇenı´ tohoto proble´mu se uzˇ´ıva´ asymetricke´ kryptografie; databa´ze kontrolnıćh soucˇtu˚ je digita´lneˇ podepsańa. K u´speˇsˇne´mu podepsańı´ databa´ze je nutne´ heslo, ktery´m je zasˇifrovań klıćˇ, ktery´ se pouzˇ´ıva´ prˇi podepisovańı´ a sˇifrovańı´ neˇkteryćh souboru˚. Stejny´m zpu˚sobem jsou ochrańeˇny i dalsˇ´ı soubory – jako naprˇ. konfiguracˇnı´ soubory. Nicmeńeˇ i tak je doporucˇovańo za´lohovat databa´zi kontrolnıćh soucˇtu˚ a konfiguracˇnı´ soubory. Kdyzˇ uzˇ nic jine´ho, tak u´tocˇnı´k, ktery´ zı´skal pra´va uzˇivatele root, mu˚zˇe databa´zi smazat a vypnout automatickou kontrolu integrity souboru˚. . . A mozˇnosti prosinec 2003




u´tocˇnı´ka jsou mnohem sˇirsˇ´ı – zvla´sˇteˇ, pokud ma´ v ja´drˇe natazˇeny´ svu˚j modul. . . Jednı´m z na´stroju˚ na kontrolu integrity souboru˚ je pra´veˇ Tripwire od stejnojmenne´ firmy (vıće o licencˇnı´ politice Tripwire – viz cˇa´st Instalace Tripwire). V Tripwire se navıć na ućˇely ochrany databa´ze a konfiguracˇnıćh souboru˚ nepouzˇ´ıva´ jeden klıćˇ, ale dva – sı´t’ovy´ klıćˇ a loka´lnı´ klıćˇ. Toto ˇresˇenı´ je pouzˇito z du˚vodu˚ usnadneˇnı´ administra´torovy praće – pokud ma´ Tripwire na vıće strojıćh na sı´ti, mohou pouzˇ´ıvat jen jeden sı´t’ovy´ klıćˇ. Ten se pouzˇ´ıva´ naprˇ. na ochranu konfiguracˇnı´ho souboru. Druhy´ klıćˇ, loka´lnı´, se chrańı´ naprˇ. loka´lnı´ databa´zı´ kontrolnıćh soucˇtu˚. Instalace Tripwire

Tripwire existuje ve dvou verzıćh, open source a komercˇnı´. Open source verze je volneˇ ke stazˇenı´ na adrese http://www.tripwire.org. K dispozici jsou balıćˇky pro RedHat a tgz balı´k obsahujıćı´ snadno pouzˇitelny´ instala´tor. Eventua´lneˇ je zde mozˇnost sta´hnutı´ zdrojovyćh ko´du˚ a jejich na´sledna´ kompilace. Nejjednodusˇsˇ´ım postupem je asi instalace pomocı´ bina´rnı´ho tgz balı´ku. Ten obsahuje i skript install.sh, ktery´ po sve´m spusˇteˇnı´ nainstaluje Tripwire, vygeneruje klıćˇe (prˇi instalaci se neˇkolikra´t zepta´ na heslo pro sı´t’ovy´ i loka´lnı´ klıćˇ), konfiguraci i za´sady.

Konfigurace a bezpecˇnostnı´ za´sady

Soubory Tripwire najdeme standardneˇ v adresa´ˇri /etc/tripwire. Veˇtsˇina souboru˚ v tomto adresa´ˇri je prˇ´ıtomna ve dvou formaćh – nezasˇifrovane´ textove´ a zasˇifrovane´ bina´rnı´. Tripwire samo o sobeˇ pracuje pouze s oneˇmi bina´rnı´mi soubory. Tudı´zˇ po aktualizovańı´ textovyćh souboru˚ je nutne´ jej zasˇifrovat a prˇeve´st do prˇ´ıslusˇne´ formy pomocı´ prˇ´ıkazu twadmin.

prosinec 2003




Vy´jimku tvorˇ´ı klıćˇe. Kromeˇ nich v adresa´ˇri najdeme textove´ soubory (a samozrˇejmeˇ jejich zasˇifrovane´ verze) obsahujıćı´ konfiguraci a bezpecˇnostnı´ za´sady Tripwire. Konfigurace Tripwire je standardneˇ ulozˇena v bina´rnı´ formeˇ v souboru /etc/tripwire/tw.cfg. Jeho textovy´ obsah mu˚zˇeme vypsat opeˇt pomocı´ programu twadmin, prˇ´ıkazem twadmin --print-cfgfile. V te´to konfiguraci mu˚zˇeme nastavit neˇkolik veˇcı´, nicmeńeˇ podstatna´ je snad pouze mozˇnost nastavenı´ logovańı´ prˇes syslogd (volba SYSLOGREPORTING). Vycˇerpa´vajıćı´ popis konfiguracˇnıćh voleb Tripwire naleznete v man 4 twconfig. Mnohem zajı´maveˇjsˇ´ı jsou bezpecˇnostnı´ za´sady Tripwire. Pomocı´ nich specifikujeme to nejdu˚lezˇiteˇjsˇ´ı – soubory a adresa´ˇre, jejichzˇ integritu chceme kontrolovat. Textovou verzi databa´ze bezpecˇnostnıćh za´sad mu˚zˇeme zı´skat pomocı´ prˇ´ıkazu twadmin --print-polfile. Za´kladnı´ syntaxe bezpecˇnostnıćh za´sad v tomto textove´m souboru je na´sledujıćı´: objekt -> příznaky; Prˇitom objekt mu˚zˇe by´t adresa´ˇrem i souborem. Prˇ´ıznaky mohou by´t slozˇeny ze skupiny znaku˚:

prosinec 2003




T

Tabulka znaku˚ prˇ´ıznaku˚:

+

bude kontrolovat zmeˇnu danyćh vlastnostı´ objektu

-

nebude kontrolovat zmeˇnu danyćh vlastnostı´ objektu

a

cˇas poslednı´ho prˇ´ıstupu

b

pocˇet alokovanyćh bloku˚

d

ID zarˇ´ızenı´

g

GID objektu

i

cˇ´ıslo inodu

l

souboru se zveˇtsˇila de´lka

m

cˇas modifikace

n

pocˇet referencı´ na inodu

p

pra´va

s

velikost

t

typ souboru

u

UID objektu

C

CRC32 kontrolnı´ soucˇet

H

Hash hodnota alg. Haval

M

MD5 hash. hodnota

S

SHA hash. hodnota Kromeˇ manua´lnı´ho zada´vańı´ vsˇech prˇ´ıznaku˚ ke vsˇem objektu˚m mu˚zˇeme te´zˇ vyuzˇ´ıt mozˇnostı´ substituce – syntaxe je $(jméno proměnné). Konstrukce je substituovańa na hodnotu one´ zadane´ promeˇnne´. Hodnotu promeˇnnyćh mu˚zˇeme nastavit pomocı´ za´pisu identifikátor=hodnota;. Naprˇ´ıklad pokud

prosinec 2003




budeme chtı´t u neˇkolika souboru˚ mı´t nastavene´ prˇ´ıznaky kontroly na zmeˇnu souboru, mu˚zˇeme si ulehcˇit jejich za´pis pomocı´ promeˇnne´: P_MOD=+pmin; /usr/sbin/sshd -> $(P_MOD); /usr/sbin/ipop3d -> $(P_MOD); K jednotlivy´m za´sada´m mu˚zˇeme prˇirˇadit i ru˚zne´ atributy. Mu˚zˇeme je specifikovat dveˇma zpu˚soby – bud’ ve stylu objekt -> příznaky (atribut=hodnota); nebo (atribut=hodnota) { objekt -> příznaky; } Pokud pomocı´ druhe´ho za´pisu napı´sˇeme mezi slozˇene´ za´vorky vıće za´sad, bude mı´t kazˇda´ za´sada nastaveny specifikovane´ atributy. A co za atributy mu˚zˇeme u za´sad nastavit? rulename – pomocı´ atributu rulename mu˚zˇeme prˇiˇradit za´sada´m neˇjaky´ identifika´tor, ktery´ se posle´ze objevı´ i v reportu. Tyto identifika´tory je vhodne´ pouzˇ´ıvat zejmeńa v prˇ´ıpadeˇ, zˇe ma´me nadefinovańo velke´ mnozˇstvı´ za´sad. Mu˚zˇeme takte´zˇ za´sady logicky organizovat podle balı´ku˚ cˇi skupin programu˚ a podle toho jim prˇirˇazovat identifika´tory (naprˇ. identifika´tor OpenSSH pro za´sady kontrolujıćı´ zmeˇnu u programu˚ /usr/sbin/sshd, /usr/bin/ssh atd.) emailto – tento atribut slouzˇ´ı k specifikaci emailove´ adresy, na kterou je poslań report, v prˇ´ıpadeˇ pouzˇitı´ volby --email-report prˇi kontrole a zjisˇteˇne´ zmeˇny neˇktere´ho z hlı´danyćh u´daju˚. severity – atributem severity mu˚zˇeme za´sada´m nastavit urcˇitou u´rovenˇ du˚lezˇitosti. Hodnotou atributu prosinec 2003




mu˚zˇe by´t cˇ´ıslo od 0 do 1 000 000. Prˇi kontrole pak mu˚zˇeme prova´deˇt filtraci na za´kladeˇ u´rovnı´ nastavenyćh jednotlivy´m za´sada´m (tudı´zˇ je mozˇne´ naprˇ. specifikovat, zˇe se majı´ kontrolovat jen za´sady s u´rovnı´ 50 a vysˇsˇ´ı). recurse – tı´mto atributem mu˚zˇeme ovlivnit chovańı´ Tripwire v prˇ´ıpadeˇ, zˇe je jako objekt zadań adresa´ˇr. Urcˇuje se jı´m maxima´lnı´ u´rovenˇ zanorˇenı´, v ktere´ bude Tripwire sledovat integritu objektu˚. Mu˚zˇe naby´vat hodnot od −1 do 1 000 000. −1 znamena´ neomezenou rekurzi, kdezˇto u´rovenˇ 0 urcˇuje, zˇe se podadresa´ˇre a soubory v dane´m adresa´ˇri nemajı´ kontrolovat. Standardnı´ hodnotou je −1, tedy monitorovańı´ vsˇech podadresa´ˇru˚ a souboru˚ v nich. Aby Tripwire mohlo pouzˇ´ıvat na´mi nakonfigurovane´ za´sady, je nutne´ prˇeve´st textovy´ konfiguracˇnı´ soubor zpeˇt do bina´rnı´ formy a podepsat ho. Pokud jizˇ ma´me vytvorˇenou databa´zi kontrolnıćh soucˇtu˚, pouzˇijeme na konverzi prˇ´ıkazu tripwire -m p textový_soubor Pokud ne, tak uzˇijeme prˇ´ıkazu twadmin --create-polfile textový_soubor Inicializace databa´ze kontrolnıćh soucˇtu˚

prosinec 2003

Pro ovla´dańı´ Tripwire se pouzˇ´ıva´ prˇedevsˇ´ım prˇ´ıkaz tripwire. K inicializaci one´ databa´ze pouzˇijeme prˇ´ıkaz tripwire -m i. Tripwire pote´ projde soubory a adresa´ˇre specifikovane´ v za´sadaćh a spocˇ´ıta´ jejich kontrolnı´ soucˇet/hashovacı´ hodnotu, kterou na´sledneˇ ulozˇ´ı do databa´ze spolu s dalsˇ´ımi u´daji o souboru. Po instalaci Tripwire bychom meˇli zaza´lohovat oba klıćˇe, databa´zi kontrolnıćh soucˇtu˚, konfiguraci a databa´zi bezpecˇnostnıćh za´sad na neˇjake´ me´dium urcˇene´ jen pro cˇtenı´ (cdrom). V prˇ´ıpadeˇ kompromitace stroje




i Tripwire pak mu˚zˇeme prove´st kontrolu zmeˇneˇnyćh souboru˚. Po vytvorˇenı´ databa´ze kontrolnıćh soucˇtu˚ bychom meˇli cˇas od cˇasu spustit kontrolu integrity souboru˚. Prˇi neˇm Tripwire zkontroluje podle databa´ze bezpecˇnostnıćh za´sad vsˇechny sledovane´ soubory a neˇktere´ u´daje u nich. V prˇ´ıpadeˇ zmeˇny vypı´sˇe varovańı´, ktere´ mu˚zˇe za´rovenˇ automaticky poslat emailem. Pro kontrolu integrity souboru˚ na´m slouzˇ´ı prˇ´ıkaz tripwire -m c. Eventua´lneˇ mu mu˚zˇeme prˇidat neˇkolik parametru˚, naprˇ. --email-report pro poslańı´ vy´sledku˚ emailem, -l u´rovenˇ pro kontrolu za´sad s u´rovnı´ du˚lezˇitosti veˇtsˇ´ı nebo rovnu specifikovane´mu cˇ´ıslu. Vycˇerpa´vajıćı´ popis parametru˚ opeˇt naleznete v man 8 tripwire.

Kontrola integrity souboru˚

Tento prˇ´ıkaz te´zˇ mu˚zˇeme umı´stit do cronu, aby se spousˇteˇl v dane´m cˇasove´m intervalu a v prˇ´ıpadeˇ porusˇenı´ integrity poslal administra´torovi email. Nicmeńeˇ podobne´ mechanismy va´s ochranı´ maxima´lneˇ tak prˇed u´tocˇnı´kem, jehozˇ vrchol schopnostı´ prˇedstavovala kompilace exploitu a stazˇenı´ backdoorovane´ho sshd. . . I kdyzˇ pustı´me kontrolu integrity manua´lneˇ, tak si nemu˚zˇeme by´t jisti, zˇe skutecˇneˇ zˇa´dny´ soubor mo´ tocˇnı´k mohl naprˇ. vymeˇnit klıćˇe, difikovań nebyl. U databa´zi a dalsˇ´ı konfiguracˇnı´ soubory. . . To bychom samozrˇejmeˇ poznali v prˇ´ıpadeˇ, zˇe bychom se pokusili o operaci, ktera´ vyzˇaduje desˇifrovańı´ klıćˇu˚ a jejich na´sledne´ pouzˇitı´ na podpis neˇjake´ho souboru (heslo ke klıćˇu˚m by samozrˇejmeˇ bylo jine´). Ale tı´m mozˇnosti u´tocˇnı´ka zdaleka nekoncˇ´ı, mu˚zˇe naprˇ. vymeˇnit bina´rnı´ soubory Tripwire a nahradit je svy´mi, ktere´ budou potichu ignorovat zmeˇnu v souborech, ktere´ u´tocˇnı´k vymeˇnil. Dalsˇ´ı mozˇnostı´ u´tocˇnı´ka je naprˇ. umı´stit na prosinec 2003




stroj modul ja´dra, ktery´ v prˇ´ıpadeˇ, zˇe se Tripwire pokusı´ o prˇ´ıstup k zmeˇneˇny´m souboru˚m, vra´tı´ hodnoty a obsah origina´lnıćh souboru˚ (skrytyćh neˇkde na pevne´m disku). Tato technika boje proti Tripwire je z teˇch uvedenyćh asi nejza´kerˇneˇjsˇ´ı, protozˇe na rozdı´l od prˇedesˇlyćh technik proti nı´ nenı´ obrana vu˚bec jednoducha´ – nepomu˚zˇe ani zaka´zańı´ podpory modulu˚ v ja´dru. Jediny´m ˇresˇenı´m jsou bezpecˇnostnı´ za´platy jako grsecurity a na´sledne´ zaka´zańı´ prˇ´ıstupu k souboru˚m /dev/kmem, /dev/mem a pra´va CAP SYS MODULE, ktere´ je nutne´ pro natazˇenı´ modulu do ja´dra. Nutno ale ˇr´ıci, zˇe pouzˇitı´ podobne´ techniky je jizˇ pomeˇrneˇ znacˇneˇ slozˇite´ a rozhodneˇ vyzˇaduje pomeˇrneˇ znacˇne´ znalosti od u´tocˇnı´ka. A pokud se oba´va´me podobnyćh u´toku˚, tak by pouzˇitı´ za´plat, jako je grsecurity, meˇlo by´t samozrˇejmostı´. Pra´veˇ z du˚vodu, zˇe loka´lnı´ databa´ze rozhodneˇ nenı´ v absolutnı´m bezpecˇ´ı, je velmi vhodne´ zaza´lohovat si konfiguracˇnı´ soubory Tripwire, klıćˇe a databa´zi kontrolnıćh soucˇtu˚ v dobeˇ jejı´ho vytvorˇenı´. Pak, pokud dojde ke kompromitaci stroje, mu˚zˇeme vzı´t jeho pevny´ disk, umı´stit ho do neˇjake´ho jine´ho pocˇ´ıtacˇe (to je nutne´ z du˚vodu eliminace vlivu prˇ´ıpadne´ho modulu ja´dra, ktery´ mohl u´tocˇnı´k na stroji umı´stit) a prove´st kontrolu integrity souboru˚. Musı´me ale pocˇ´ıtat s tı´m, zˇe pokud ona pu˚vodnı´ databa´ze bude starsˇ´ıho data, tak Tripwire bude hla´sit i zmeˇny, ktere´ jsme provedli sami (za´platovańı´). Aktualizace databa´ze kontrolnıćh soucˇtu˚ prosinec 2003

Ke zmeˇna´m hlı´danyćh souboru˚ mu˚zˇe te´zˇ dojı´t opra´vneˇneˇ – prˇ´ıkladem budizˇ za´platovańı´ cˇi instalace nove´ho softwaru. V takove´m prˇ´ıpadeˇ je nutne´ aktualizovat databa´zi, aby se v dalsˇ´ıch reportech jizˇ neobjevovalo




varovańı´. Databa´zi mu˚zˇeme aktualizovat pomocı´ prˇ´ıkazu tripwire -m u -r report. Jako report specifikujeme jmeńo souboru s reportem, ktery´ vygeneroval Tripwire prˇi kontrole integrity souboru˚. Jmeńo souboru je prˇi kontrole vzˇdy vypsańo na jejı´m zacˇa´tku. Tripwire prˇedstavuje velmi dobry´ na´stroj na kontrolu integrity souboru˚. Prˇi prˇ´ıpadne´m pru˚niku mu˚zˇe administra´torovi velmi ulehcˇit obnovu syste´mu a napoveˇdeˇt mu, co onen u´tocˇnı´k na stroji provedl. Nenı´ vsˇak samozrˇejmeˇ na´strojem vsˇemocny´m, schopny´ u´tocˇnı´k jej pochopitelneˇ doka´zˇe vyrˇadit.

Za´veˇrem

prosinec 2003



prosinec 2003





9/3.10 ´ NI´ SI´TˇOVE´HO PROVOZU OMEZOVA

´ vod 9/3.10.1 U 9/3.10.2 Omezovańı´ provozu na u´rovni protokolu TCP/IP

uńor 2005



uńor 2005





9/3.10.1 ´ VOD U

Omezovańı´ sı´t’ove´ho provozu je problematika, ktera´ se na kazˇde´m operacˇnı´m syste´mu cˇi v kazˇde´ aplikaci, chovajıćı´ se jako aplikacˇnı´ proxy server, da´ ˇresˇit mnoha zpu˚soby. Vsˇechny vsˇak majı´ jednu spolecˇnou veˇc. Mnozˇstvı´ dat, ktera´ k na´m prˇicha´zejı´ z cizıćh zdroju˚, nemu˚zˇeme nijak ovlivnit. Naprˇ´ıklad pokud ma´me od poskytovatele prˇideˇlenou linku o neˇjake´ kapaciteˇ a ra´di bychom ji rozdeˇlili da´le cˇi omezili neˇktere´ uzˇivatele, tak samozrˇejmeˇ neˇjaky´mi zpu˚soby mu˚zˇeme. Pokud se vsˇak neˇjaky´ hacker nebo vir v Internetu rozhodne nasˇ´ı linku zahltit, tak se mu to podarˇ´ı, protozˇe my nemu˚zˇeme ovlivnit data, ktera´ k na´m prosteˇ posˇle. Mu˚zˇeme prˇ´ımo ovlivnit pouze ta data, ktera´ prˇeposı´la´me da´le nebo ktera´ chceme do Internetu odesı´lat. A aby toho nebylo ma´lo, tak je nutno poznamenat, zˇe efektivneˇ se da´ omezovat pouze protokol TCP. Na efektivnı´m omezovańı´ protokolu UDP cˇi ICMP mu˚zˇeme s klidny´m sveˇdomı´m zapomenout. uńor 2005



uńor 2005





9/3.10.2 ´ NI´ PROVOZU NA OMEZOVA ´ ROVNI PROTOKOLU TCP/IP U

Na u´vod zopakuji, zˇe nejsme naprosto vu˚bec schopni ovlivnit mnozˇstvı´ dat, ktera´ k na´m dorazı´ z Internetu. To je pravidlo, na ktere´ je nutno neusta´le pamatovat. Nasˇteˇstı´ je protokol TCP, ktery´ pouzˇ´ıva´ veˇtsˇina aplikacı´, navrzˇen s na´sledujıćı´ vlastnostı´. Klient pozˇa´da´ server o neˇjaka´ data. Server zacˇne tato data posı´lat co mozˇna´ nejrychlejsˇ´ım zpu˚sobem. Kdyzˇ klient dosta´va´ jednotlive´ pakety, posı´la´ potvrzenı´ o jejich prˇijetı´. Da´va´ tı´m serveru na veˇdomı´, zˇe je prˇipraven prˇijı´mat dalsˇ´ı data. Pokud pakety s potvrzenı´m prˇicha´zejı´ k serveru pomaleji, tak si server „zacˇne myslet“, zˇe se s pakety na cesteˇ neˇco deˇje, a sa´m zacˇne klientovi posı´lat data v mensˇ´ım mnozˇstvı´. Da´ tak klientovi (nebo take´ routeru˚m na cesteˇ) sˇanci zpracovat cely´ provoz bez nutnosti posı´lat veˇtsˇinu paketu˚ znovu.

uńor 2005




Te´to vlastnosti vyuzˇijeme prˇi nasˇem omezovańı´ protokolu TCP. Donutı´me servery v Internetu k pomalejsˇ´ımu odesı´lańı´ dat. Je zrˇejme´, zˇe je vhodne´ nejen regulovat pakety, ktere´ smeˇˇrujı´ z Internetu ke klientu˚m, ale take´ data od klientu˚ do Internetu. Technika omezovańı´

Ra´d bych uvedl, zˇe zacˇnu celou techniku popisovat znacˇneˇ zjednodusˇeneˇ a teprve na konci uvedu mozˇne´ vy´jimky cˇi nepravdy, jichzˇ se v pru˚beˇhu dopustı´m. Je to proto, abych nema´tl prˇ´ıpadne´ zacˇa´tecˇnı´ky. Z vy´sˇe uvedene´ho popisu jasneˇ plyne, zˇe jsme schopni prˇ´ımo ovlivnit pouze provoz, ktery´ odcha´zı´ z pocˇ´ıtacˇe. Technika, ktera´ se k tomu pouzˇ´ıva´, se da´ popsat na´sledovneˇ. Pote´, co paket projde filtrovacı´m a routovacı´m procesem na routeru, je rozhodnuto, ktery´m sı´t’ovy´m rozhranı´m bude z routeru odcha´zet. Prˇed toto sı´t’ove´ rozhranı´ pak zjednodusˇeneˇ postavı´me trpaslı´ka, ktery´ bude podle neˇjakyćh pravidel ˇr´ıkat, ktery´ paket do sı´teˇ propustı´, ktery´ pozdrzˇ´ı cˇi ktery´ zahodı´ (a pak je na aplikaci/protokolu, jak se s takovou ztra´tou paketu vyrovna´). Onen trpaslı´k je neˇkdo, kdo bdı´ nad jaky´msi strukturovany´m skladem. Jednotlive´ skladovacı´ mı´stnosti majı´ prˇideˇlenu kapacitu. Tuto aktua´lnı´ kapacitu mu˚zˇe na´sˇ trpaslı´k prˇepocˇ´ıta´vat, pokud to dovoluje konfigurace toho strukturovane´ho skladu. Jednotlive´ pakety se umist’ujı´ do jednotlivyćh skladovacıćh mı´stnostı´ a trpaslı´k podle konkre´tnı´ho algoritmu pro kazˇdou jednotlivou mı´stnost rozhoduje, jestli bude paket z mı´stnosti odeslań do sı´t’ove´ho rozhranı´, nebo zda bude zahozen do propadlisˇteˇ deˇjin.

uńor 2005




Zmıńeˇny´ algoritmus mu˚zˇe by´t naprˇ´ıklad typu FIFO (first in, first out), podle ktere´ho se z mı´stnosti vezme a odesˇle do sı´t’ove´ho rozhranı´ ten paket, ktery´ je v mı´stnosti nejstarsˇ´ı. Zmıńeˇna´ skladovacı´ mı´stnost ma´ pevnou velikost (naprˇ´ıklad 20 paketu˚). Pokud je plna´ a vsˇechny pakety v nı´ cˇekajı´ na odeslańı´, tak se pakety, ktere´ do nı´ majı´ spadnout, prosteˇ zahodı´ a ztratı´ v onom propadlisˇti deˇjin. Aplikace, ktera´ vytvorˇila takovy´to paket, nenı´ o tomto zahozenı´ nijak informovańa a je jen na nı´, aby zpozorovala, zˇe se jı´ pakety po cesteˇ ztraćejı´. Popis ve vy´sˇe uvedenyćh dvou odstavcıćh je mozˇna´ na prvnı´ pohled zmateny´, nicmeńeˇ prˇi dalsˇ´ım cˇtenı´ a zhle´dnutı´ neˇkolika obra´zku˚ bude vsˇe jasneˇjsˇ´ı. Nynı´ vsˇak jizˇ dost teorie a pojd’me se podı´vat na neˇjaky´ konkre´tnı´ prˇ´ıklad. Ma´me veˇtsˇ´ı firmu, prˇistupujıćı´ do Internetu prˇes jedinou verˇejnou adresu, kterou jsme dostali od poskytovatele prˇipojenı´. V budoveˇ, kde sı´dlı´ nasˇe firma, vsˇak sı´dlı´ jesˇteˇ jina´ firma, ktera´ je prˇipojena do nasˇ´ı vnitrˇnı´ sı´t’eˇ a ktera´ take´ prˇes nasˇi verˇejnou adresu prˇistupuje do Internetu. Rˇekneˇme, zˇe nasˇe firma pouzˇ´ıva´ sı´t’ 192.168.0.0 s maskou 255.255.255.0 a ona druha´ firma pouzˇ´ıva´ 192.168.1.0 s maskou 255.255.255.0. Rychlost nasˇ´ı linky je 512/768 kbps (download/upload). Ra´di bychom prˇideˇlene´ pa´smo rozdeˇlili tak, zˇe nasˇe firma bude pouzˇ´ıvat 300/500 kbps kapacity linky a sousednı´ firma 212/268 kbps kapacity. V patrˇicˇne´m pomeˇru se takto deˇlı´ i o cenu fakturovanou poskytovatelem. Da´le bychom chteˇli, aby meˇl pocˇ´ıtacˇ 192.168.0.30, ktery´ je v nasˇ´ı vnitrˇnı´ sı´ti, alesponˇ garantovanou rychlost 128 kbps. Je to totizˇ pocˇ´ıtacˇ nasˇeho ˇreditele, ktery´ ma´ prˇipojenou IP telefonii a obcˇas telefonuje prˇes Internet

Zadańı´

uńor 2005




a je nutne´ mu garantovat tuto rychlost. A da´le si prˇejeme, aby vza´jemny´ provoz mezi nasˇ´ı firmou a sousednı´ firmou nebyl nijak omezovań. Nakonec jen doda´m, zˇe verˇejna´ adresa nasˇeho routeru je 123.45.67.8 a je na sı´t’ove´m rozhranı´ eth0, adresa do nasˇ´ı vnitrˇnı´ sı´teˇ je 192.168.0.1 (eth1), adresa do vnitrˇnı´ sı´teˇ sousednı´ firmy je 192.168.1.1 (eth2). Na´sˇ router tak ma´ trˇi sı´t’ove´ karty. Mozˇna´ va´s napadne, zˇe bychom ra´di dosa´hli, aby prˇi male´m provozu jedne´ firmy mohla druha´ vyuzˇ´ıvat cˇa´st kapacity prvnı´ a naopak. Tento pozˇadavek prozatı´m nevzna´sˇejme, dostaneme se k neˇmu pozdeˇji a samozrˇejmeˇ jej splnı´me. V kapitole 9/3.6.3 jsme pomocı´ firewallu a tabulky mangle dosa´hli oznacˇkovańı´ prˇ´ıslusˇnyćh paketu˚. Zopakuji zde znovu pro prˇehlednost tabulku, ze ktere´ je zrˇejme´, jak je ktery´ provoz paketu˚ oznacˇkovań.

uńor 2005




T

Tabulka znacˇek pro vesˇkery´ provoz

adresa zdrojova´

cı´lova´

znacˇ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ı´

Samotny´ 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 7: tc class add dev eth0 parent 1:1 classid 1:3

htb rate 268kbit ceil

268kbit 8:

uńor 2005




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


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

uńor 2005




Na obra´zku k zarˇ´ızenı´ eth0 vidı´me strukturu, kterou jsme vytvorˇili prˇ´ıkazy na ˇra´dcıćh 1 azˇ 7. Struktura pro odchozı´ provoz na zarˇ´ızenı´ eth0

Provoz do Internetu

O

Na ˇra´dku 1 smazˇeme prˇ´ıpadneˇ drˇ´ıve vytvorˇene´ struktury. Na rˇa´dku 2 vytvorˇ´ıme korˇenovou disciplıńu (qdisc) 1:0 na zarˇ´ızenı´ eth0 a budeme na nı´ pouzˇ´ıvat algoritmus htb. Na tuto korˇenovou disciplıńu poveˇsı´me trˇ´ıdu (class) 1:1 a ˇrekneme, zˇe jejı´ kapacita je 768 kilobitu˚ za sekundu. To je konec koncu˚ kapacita pro upload, kterou na´m prˇideˇlil na´sˇ poskytovatel Intenetu. Na ˇra´dku 4 a 7 na trˇ´ıdu 1:1 poveˇsı´me dveˇ dalsˇ´ı trˇ´ıdy, a to 1:2 s kapacitou 500 kbps a 1:3 s kapacitou 268 kbps. Tyto dveˇ trˇ´ıdy reprezentujı´ pa´sma, ktere´ rozdeˇlujeme mezi nasˇi firmu (trˇ´ıda 1:2) a sousednı´ firmu (1:3). Parametr ceil si vysveˇtlı´me na konci. Protozˇe vsˇak v nasˇ´ı firmeˇ chceme garantovat odchozı´ provoz na rychlosti 128 kbps pro pocˇ´ıtacˇ pana ˇreditele, rozcˇlenı´me trˇ´ıdu 1:2 na dalsˇ´ı dveˇ potrˇ´ıdy. To provedeme na ˇra´dcıćh 5 a 6. Na ˇra´dku 6 vytvorˇ´ıme trˇ´ıdu pro pocˇ´ıtacˇ pana ˇreditele a ˇrekneme, zˇe jejı´ kapacita uńor 2005




je 128 kbps. Na rˇa´dku 5 jsme pak vytvorˇili trˇ´ıdu, jejı´zˇ kapacita je 372 kbps (tedy 500 minus 128). Parametr rate ˇr´ıka´, jaka´ ma´ by´t garantovana´ rychlost trˇ´ıdy, a parametr ceil ˇr´ıka´, jaka´ mu˚zˇe by´t maxima´lnı´ rychlost trˇ´ıdy. Na ˇra´dku 7 tedy stanovujeme, zˇe pokud ma´ trˇ´ıda 1:2 (tedy trˇ´ıda pro nasˇi firmu) volnou kapacitu, mu˚zˇe pocˇ´ıtacˇ pana ˇreditele odesı´lat data rychlostı´ azˇ 500 kbps, tedy veˇtsˇ´ı rychlostı´ nezˇ 128 kbps. Podobneˇ na ˇra´dku 6 ˇr´ıka´me, zˇe pokud pocˇ´ıtacˇ pana ˇreditele nevyteˇzˇuje linku rychlostı´ 128 kbps, mohou ostatnı´ pocˇ´ıtacˇe v nasˇ´ı firmeˇ prˇistupovat na Internet veˇtsˇ´ı rychlostı´ nezˇ 372 kbps. Nadefinovali jsme tedy, zˇe pocˇ´ıtacˇ pana ˇreditele a ostatnı´ pocˇ´ıtacˇe v nasˇ´ı firmeˇ sdı´lejı´ pa´smo 500 kbps, prˇicˇemzˇ v prˇ´ıpadeˇ potrˇeby ma´ ˇreditelu˚v pocˇ´ıtacˇ zajisˇteˇnu rychlost 128 kbps. Pokud se hodnoty parametru˚ rate a ceil rovnajı´, pak si dana´ trˇ´ıda nemu˚zˇe od sve´ho rodicˇe zˇa´dne´ pa´smo vypu˚jcˇit. Na rˇa´dcıćh 4 a 5 jsme to ˇrekli o pa´smu pro nasˇi a sousednı´ firmu. Na ˇra´dcıćh 9 azˇ 11 pak ˇr´ıka´me, do ktere´ skladovacı´ mı´stnosti pak pu˚jde ten ktery´ paket. Vsˇechny odchozı´ pakety jsme sami oznacˇkovali v pravidlech firewallu v kapitole 9/3.6.3. Prˇ´ıkaz tc filter add dev eth0 parent 1:2 protocol ip handle 20 fw flowid 1:10 na ˇra´dku 9 ˇr´ıka´, zˇe pakety se znacˇkou 20 odcha´zejıćı´ zarˇ´ızenı´m eth0 pu˚jdou do trˇ´ıdy 1:10. Na ˇra´dku 10 pak do trˇ´ıdy 1:11 ha´zˇeme vsˇechny pakety, ktere´ odcha´zejı´ zarˇ´ızenı´m eth0 a majı´ znacˇku 22, a do trˇ´ıdy 1:3 pak hodı´me vsˇechny pakety, ktere´ majı´ znacˇku 21 a opeˇt odcha´zejı´ zarˇ´ızenı´m eth0. Provoz do Internetu, ktery´ bude generovat na´sˇ pocˇ´ıtacˇ, ma´me oznacˇkovany´ znacˇkou 50, a protozˇe jsme pro tuto znacˇku nenadefinovali zˇa´dne´ pravidlo, ktere´ by uńor 2005




ˇr´ıkalo, do ktere´ trˇ´ıdy patrˇ´ı, zpracujeme jej v defaultnı´ trˇ´ıdeˇ 1:10, jak se dozvı´me na konci prˇ´ıkladu. Podı´vejme se nynı´ na strukturu na zarˇ´ızenı´ eth1, tedy sı´t’ove´ zarˇ´ızenı´ do vnitrˇnı´ sı´teˇ nasˇ´ı firmy, kterou jsme vytvorˇili na ˇra´dcıćh 13 azˇ 22. Struktura pro odchozı´ provoz na zarˇ´ızenı´ eth1

Provoz do vnitrˇnı´ sı´teˇ nasˇ´ı firmy

O

Na ˇra´dku 14 opeˇt nejprve vytvorˇ´ıme korˇenovou disciplıńu 1:0, na kterou poveˇsı´me (rˇa´dek 15) korˇenovou trˇ´ıdu 1:1. Na tuto trˇ´ıdu poveˇsı´me dveˇ podtrˇ´ıdy. Trˇ´ıda 1:2 (rˇa´dek 16) bude slouzˇit pro provoz z Internetu do nasˇ´ı vnitrˇnı´ sı´teˇ a trˇ´ıda 1:3 (rˇa´dek 19) bude slouzˇit pro provoz z vnitrˇnı´ sı´teˇ sousednı´ firmy do nasˇ´ı vnitrˇnı´ sı´teˇ. Bude mı´t kapacitu te´meˇˇr 100 Mbps, cozˇ je rychlost nasˇ´ı sı´t’ove´ karty. Trˇ´ıdu 1:2 jsme da´le rozdeˇlili na podtrˇ´ıdu 1:10, kam bude smeˇˇrovat provoz z Internetu do pocˇ´ıtacˇu˚ v nasˇ´ı vnitrˇnı´ sı´ti kromeˇ pocˇ´ıtacˇe pana ˇreditele. Pro provoz z Internetu na pocˇ´ıtacˇ pana ˇreditele pak vytvorˇ´ıme trˇ´ıdu 1:11 (rˇa´dek 18).

uńor 2005




Rychlost trˇ´ıdy 1:11 jsme stanovili na 128 kbps s tı´m, zˇe pokud nenı´ vyuzˇ´ıvańo pa´smo trˇ´ıdy 1:10, tak jej vyuzˇijeme a mu˚zˇeme dosa´hnout rychlosti azˇ 300 kbps. Na ˇra´dku 21 pak ˇr´ıka´me, zˇe pakety oznacˇene´ znacˇkou 40 (tedy provoz mezi sousednı´ firmou a nasˇ´ı firmou) pu˚jdou do trˇ´ıdy 1:3 na zarˇ´ızenı´ eth1. Na ˇra´dku 22 pak zarˇadı´me do trˇ´ıdy 1:10 ten provoz, ktery´ je z Internetu urcˇen pocˇ´ıtacˇu˚m ve vnitrˇnı´ sı´t’i (kromeˇ pocˇ´ıtacˇe pana ˇreditele) a do trˇ´ıdy 1:11 pak zarˇadı´me ten provoz, ktery´ je z Internetu urcˇen na pocˇ´ıtacˇ pana ˇreditele. Je nutno v nasˇem prˇ´ıpadeˇ poznamenat, zˇe trˇ´ıda 1:2 si nikdy nesmı´ pu˚jcˇit pa´smo od trˇ´ıdy 1:1, protozˇe bychom tı´m de facto prˇestali omezovat provoz z Internetu. Na to je nutno vzˇdy pamatovat. Pokud bychom nechteˇli sdı´let pa´smo pro provoz z Internetu mezi pocˇ´ıtacˇm pana rˇeditele a ostatnı´mi pocˇ´ıtacˇi v nasˇ´ı vnitrˇnı´ sı´ti, pak by strukutra na zarˇ´ızenı´ eth1 mohla vypadat na´sledovneˇ:

O

Provoz z Internetu do sousednı´ firmy uńor 2005

Mozˇna´ struktura pro odchozı´ provoz na zarˇ´ızenı´ eth1




Struktura na sı´t’ove´m zarˇ´ızenı´ eth2 (a tedy pokry´vajıćı´ provoz do sı´teˇ sousednı´ firmy) vypada´ jizˇ velmi jednodusˇe. Na ˇra´dcıćh 25, 26 a 27 provedeme obvykle´ u´kony. Da´le definujeme dveˇ podtrˇ´ıdy pro trˇ´ıdu 1:1. Trˇ´ıda 1:10 (rˇa´dek 28) bude slouzˇit pro provoz z nasˇ´ı firmy do sousednı´ firmy a trˇ´ıda 1:11 (rˇa´dek 29) pak bude slouzˇit pro provoz z Internetu do sousednı´ firmy. Opeˇt je nutno ˇr´ıci, zˇe trˇ´ıda 1:11 musı´ mı´t pevnou rychlost a nepu˚jcˇuje si od rodicˇovske´ trˇ´ıdy 1:1 (tj. hodnota parametru ceil se rovna´ hodnoteˇ parametru rate). Zby´va´ vysveˇtlit, co znamenajı´ ˇra´dky 2, 14 a 26. Na nich se definuje trˇ´ıda pro ty pakety, ktere´ ve vy´sledku nespadnou do zˇa´dne´ trˇ´ıdy. My jsme vsˇak oznacˇkovali ve firewallu vesˇkery´ odchozı´ provoz z routeru, a tak jsou tyto definice defaultnıćh trˇ´ıd zbytecˇne´. Sˇta´bnı´ kultura vsˇak ˇr´ıka´, zˇe je vhodne´ a slusˇne´ je definovat. Vy´sˇe uvedene´ ˇresˇenı´ ma jeden za´sadnı´ proble´m. Linuxove´ ja´dro na´m v tomto konkreńı´m prˇ´ıpadeˇ zacˇne v rea´lne´m provozu protestovat proti prˇ´ılisˇ rozdı´lny´m hodnota´m trˇ´ıd. A ma´ skutecˇneˇ pravdu, protozˇe vhodneˇ rozdeˇlovat provoz mezi cca 100 Mbit trˇ´ıdou (1:3 na eth1, 1:10 na eth2) a ostatnı´mi kapacitneˇ vy´razneˇ mensˇ´ımi trˇ´ıdami na prˇ´ıslusˇne´m rozhranı´ je co do vy´pocˇetnı´ho vy´konu a rozhodovańı´, ktere´ pakety zahodit a ktere´ jesˇteˇ ne, na´rocˇne´.

Proble´my

ˇ esˇenı´ je dvojı´. Zaprve´ mu˚zˇeme nedefinovat trˇ´ıdy R default (na zarˇ´ızenıćh eth1 a eth2) a vu˚bec tyto kapacitneˇ velke´ trˇ´ıdy. Tı´m, zˇe nebudeme mı´t trˇ´ıdu default a nebudeme pomocı´ prˇ´ıkazu˚ tc filter... vu˚bec umı´st’ovat pakety mezi nasˇ´ı vnitrˇnı´ sı´tı´ a sı´tı´ sousednı´ firmy do trˇ´ıd, tak tyto pakety spadnou jaksi mimo a po filtrovacı´m a routovacı´m procesu pu˚jdou rovnou uńor 2005




do sı´t’ove´ho zarˇ´ızenı´ bez jake´hokoliv omezenı´. Na´sledujıćı´ druhy´ zpu˚sob je cˇistsˇ´ı. Snı´zˇ´ıme hodnoty pro tyto objemne´ trˇ´ıdy na takovou u´rovenˇ, proti ktere´ linuxove´ ja´dro neprotestuje. Provoz mezi vnitrˇnı´mi sı´teˇmi pak nebude probı´hat na rychlosti 100 Mbps, ale naprˇ´ıklad 10 Mbps nebo 2 Mbps, podle toho, jakou hodnotu linuxove´ ja´dro zvla´dne. Pomalejsˇ´ı provoz mezi vnitrˇnı´mi sı´teˇmi je danı´ za cˇistotu konfigurace. Sami si vyberte, co je va´m blizˇsˇ´ı. Pokud vyberete prvnı´ zpu˚sob, doporucˇuji, abyste tento svuj u´mysl nedefinovat default trˇ´ıdy zapsali v komenta´ˇri do skriptu, odkud budete omezovańı´ spousˇteˇt. Dalsˇ´ım proble´mem je to, zˇe omezujeme vsˇechny protokoly. Jak TCP, u ktere´ho to ma´ smysl, tak naprˇ. UDP cˇi ICMP, u kteryćh to zˇa´dny´ smysl nema´. Co s tı´m, uvidı´me da´le.

uńor 2005




Z prˇedchozı´ho vy´kladu a z popisu prˇ´ıkazu tc plyne, zˇe omezovat pa´smo lze pouze na konkre´tnı´m fyzicke´m zarˇ´ızenı´. V nasˇem prˇedchozı´m prˇ´ıkladu hypoteticke´ firmy vsˇak ma´ na´sˇ server samostatnou sı´t’ovou kartu pro vnitrˇnı´ sı´t’nasˇ´ı firmy a samostatnou sı´t’ovou kartu pro vnitrˇnı´ sı´t’sousednı´ firmy.

Sdı´lenı´ volne´ho pa´sma

Cˇasto se asi bude sta´vat, zˇe celkovy´ provoz obou firem nebude veˇtsˇ´ı nezˇ kapacita linky. Pokud jsme ale pevneˇ rozdeˇlili tuto kapacitu v neˇjake´m pomeˇru mezi dveˇ sı´teˇ a provoz v jedne´ z nich dosa´hne prˇideˇlene´ kapacity, linka nebude vyuzˇita. Nabı´zı´ se proto ˇresˇenı´, kdy „zapu˚jcˇ´ıme“ cˇa´st volne´ kapacity, kterou nevyuzˇ´ıva´ druha´ sı´t’. Proble´mem vsˇak je, jak jsem prˇed chvı´lı´ zmıńil, nemozˇnost pu˚jcˇit si kapacitu mezi dveˇma fyzicky´mi sı´t’ovy´mi zarˇ´ızenı´mi. Neklesejme na mysli, v linuxove´m sveˇteˇ se nepta´me, zdali neˇco lze udeˇlat, ale pta´me se, jak se to ma´ udeˇlat. Odpoveˇd’ je dvojı´. Bud’ si prˇ´ıslusˇny´ program napsat sa´m a nebo hledat na Internetu, zdali to jizˇ neˇkdo neudeˇlal za na´s. Druha´ varianta je obvykle pravdeˇpodobneˇjsˇ´ı. IMQ je falesˇne´ sı´t’ove´ zarˇ´ızenı´ a nelze s nı´m prova´deˇt nic jine´ho, nezˇ na neˇj poveˇsit neˇjakou sı´t’ovou disciplıńu qdisc. Drˇ´ıve jsem se zminˇoval pouze o disciplıńaćh. Ted’ jen pro porˇa´dek zmıńı´m, zˇe existujı´ dva druhy: prˇ´ıchozı´ (ingress) a odchozı´ (egress). Jaky´ je mezi nimi rozdı´l, je v tuto chvı´li nedu˚lezˇite´. Zminˇuji se o tom proto, zˇe na IMQ zarˇ´ızenı´ lze poveˇsit pouze odchozı´ (egress) disciplıńu. Prˇ´ıchozı´ (ingress) disciplıńu na neˇj poveˇsit z du˚vodu vlastnostı´ linuxove´ho firewallu Netfilter nemu˚zˇeme, nicmeńeˇ prˇ´ıchozı´ provoz lze omezovat na IMQ pomocı´ odchozı´ disciplıńy.

IMQ

listopad 2005




O tom, jak zarˇ´ızenı´ IMQ nainstalovat, se zmıńı´m na konci. Zmeˇna zadańı´

V pu˚vodnı´m zadańı´ ze zacˇa´tku kapitoly 9.3.10.1 jsme ˇrekli, zˇe nasˇe firma bude mı´t prˇideˇlenou prˇ´ıchozı´ kapacitu 268 kbps a sousednı´ firma pak 500kbps. Odchozı´ kapacitu 512 kbps jsme rozdeˇlili tak, zˇe nasˇe firma dostala 212 kbps a sousednı´ firma 300 kbps. Doplnˇme nasˇe zadańı´ tak, zˇe v prˇ´ıpadeˇ, kdy jedna z firem dosa´hne sve´ho limitu, zapu˚jcˇ´ı si volne´ pa´smo od firmy druhe´. Samozrˇejmeˇ za takovyćh podmıńek, kdy se takto zapu˚jcˇene´ volne´ pa´smo bude automaticky pru˚beˇzˇneˇ meˇnit tak, jak bude kolı´sat provoz druhe´ firmy. Te´ totizˇ musı´me garantovat rychlost 268 kbps. Neboli sdı´lı´me kapacitu linky mezi firmami s tı´m, zˇe garantujeme neˇjake´ minima´lnı´ meze. Pro odchozı´ provoz je u´prava pu˚vodnı´ho skriptu velmi jednoducha´. Pu˚vodnı´ ˇra´dky 3 azˇ 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

ˇr´ıkajı´, zˇe trˇ´ıda 1:3 (nasˇe firma) ma´ garantovanou rychlost 268 kbps a tato rychlost je nemeˇnna´, protozˇe parametr ceil ma´ stejnou hodnotu jako parametr rate a nemu˚zˇe si tak od nadrˇazene´ trˇ´ıdy 1:1 nic zapu˚jcˇit. Ani trˇ´ıda 1:2 (sousednı´ firma) si nemu˚zˇe od nadrˇazene´ trˇ´ıdy zapu˚jcˇit pa´smo. Avsˇak trˇ´ıdy 1:11 (pocˇ´ıtacˇ ˇreditele sousednı´ firmy) a 1:10 (ostatnı´ pocˇ´ıtacˇe sousednı´ firmy) majı´ sice garantovanou pevnou rychlost, avsˇak mohou si od nadˇrazene´ trˇ´ıdy pu˚jcˇit tolik, zˇe jejich rychlost mu˚zˇe vzru˚st na 500 kbps. listopad 2005




Abychom vyhoveˇli pozˇadavku sdı´lenı´ pa´sma s garantovany´mi minima´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 nasˇe firma (trˇ´ıda 1:3) bude mı´t provoz mensˇ´ı nezˇ 268 kbps a pocˇ´ıtacˇ ˇreditele sousednı´ firmy provoz veˇtsˇ´ı nezˇ 500 kbps, cely´ mechanismus omezovanı´ provozu zajistı´, zˇe volna´ kapacita trˇ´ıdy 1:3 bude (nasˇ´ım trpaslı´kem z odstavce Technika omezovańı´) zapu˚jcˇena trˇ´ıdeˇ 1:2. Tato zapu˚jcˇena´ kapacita da´le propadne do trˇ´ıdy 1:11, a ˇreditel sousednı´ firmy tak dosa´hne vysˇsˇ´ı rychlosti odchozı´ho provozu do Internetu. Zde tedy nasˇe virtua´lnı´ zarˇ´ızenı´ IMQ nepouzˇijeme. U prˇ´ıchozı´ho provozu z Interntu je vsˇak situace slozˇiteˇjsˇ´ı. Zde provoz omezujeme na sı´t’ovyćh zarˇ´ızenıćh eth1 a eth2 a korˇenove´ trˇ´ıdy na nich poveˇsˇene´ si nemajı´ jak mezi sebou kapacitu pu˚jcˇit. Na chvı´li odbocˇ´ım a poznamena´m, zˇe jsme na zacˇa´tku z du˚vodu bezpecˇnosti pozˇadovali, aby byla sı´t’ nasˇ´ı firmy fyzicky oddeˇlena od sı´teˇ sousednı´ firmy. To jsme realizovali pouzˇitı´m dvou sı´t’ovyćh karet. V tuto chvı´li se nabı´zı´ mysˇlenka, zˇe pokud se na´m podarˇ´ı zajistit, aby sˇel tok dat do teˇchto dvou zarˇ´ızenı´ prˇes neˇjake´ jedno virtua´lnı´ mı´sto (bude jı´m virtua´lnı´ sı´t’ove´ zarˇ´ızenı´ IMQ) a omezovat budeme v tomto virtua´lnı´m mı´steˇ (poveˇsı´me neˇjakou disciplıńu na zarˇ´ızenı´ IMQ), ma´me vyhrańo.

listopad 2005




Prˇesmeˇrovańı´ provozu (neboli jednotlivyćh paketu˚) prˇes zarˇ´ızenı´ IMQ se prova´dı´ pomocı´ iptables v tabulce mangle prˇ´ıkazem iptables -t mangle -A POSTROUTING -j IMQ --todev 0. Protozˇe mu˚zˇeme mı´t v syste´mu neˇkolik zarˇ´ızenı´ IMQ, musı´me specifikovat parametrem --todev cˇ´ıslo tohoto zarˇ´ızenı´. Nebot’ budeme omezovat pouze provoz, ktery´ k na´m prˇ´ıcha´zı´ z Internetu, v pravidlech POSTROUTING prˇesmeˇrujeme do IMQ zarˇ´ızenı´ jen tento provoz. Pouzˇitı´ IMQ ma´ v tomto prˇ´ıpadeˇ jednu nespornou vy´hodu oproti pu˚vodnı´mu ˇresˇenı´. V odstavci, kde jsem popisoval proble´my onoho ˇresˇenı´, jsem zmıńil, zˇe ja´dro bude protestovat proti velky´m rozdı´lu˚m v kapacitaćh jednotlivyćh trˇ´ıd. To nynı´ odpadne, protozˇe ma´me od poskytovatele k dispozici kapacitu 512 kbps a tu budeme rozdeˇlovat tak, zˇe pomeˇr jednotlivyćh trˇ´ıd nebude nijak velky´. Protozˇe se na´m do omezovańı´ nebude ple´st provoz mezi vnitrˇnı´mi sı´teˇmi nasˇ´ı a sousednı´ firmy, bude moci tento provoz beˇzˇet na maxima´lnı´ rychlosti, ktera´ je dańa rychlostmi pouzˇityćh sı´t’ovyćh prvku˚, cozˇ jsou v tomto prˇ´ıpadeˇ sı´t’ove´ karty (100 Mbps). Kdybychom meˇli do omezovańı´ mıćhat i tento provoz, pra´veˇ kapacita od poskytovatele 512 kbps je ve velke´m nepomeˇru s rychlostı´ na vnitrˇnıćh sı´t’ovyćh kartaćh a proti tomuto nepomeˇru ja´dro protestuje! Nadefinujeme tedy na´sledujıćı´ strukturu:

listopad 2005




O

Zbytek upravene´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 omezovańı´ provozu je tak dı´ky pouzˇitı´ zaˇr´ızenı´ IMQ vy´razneˇ kratsˇ´ı. Zby´va´ na´m doplnit firewallovacı´ skript v kapitole 9/3.6.3, a to doplneˇnı´m pravidel POSTROUTING v tabulce mangle. Prˇida´me na jeho konec tyto rˇa´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




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 ˇra´dku 35 prˇesmeˇruji vsˇechny pakety do zarˇ´ızenı´ imq0 kromeˇ paketu˚, ktere´ jsem „akceptoval“ v prˇedchozıćh pravidlech a ktere´ dı´ky akci ACCEPT ukoncˇ´ı pru˚chod v tabulce mangle v rˇeteˇzci POSTROUTING. Mezi tyto pakety patrˇ´ı vsˇechny takove´, ktere´ slouzˇ´ı pro internı´ potrˇebu sı´t’ove´ho provozu na firewallu a jdou tak po virtua´lnı´m zarˇ´ızenı´ loopback (rˇa´dek 30), da´le pakety, ktere´ patrˇ´ı k provozu mezi vnitrˇnı´mi sı´teˇmi nasˇ´ı a sousednı´ firmy (rˇa´dky 31 a 32), da´le pakety, ktere´ patrˇ´ı provozu mezi nasˇ´ım firewallem a vnitrˇnı´ sı´tı´ nasˇ´ı firmy (rˇa´dek 33), a konecˇneˇ pakety, ktere´ patrˇ´ı provozu mezi nasˇ´ım firewallem a vnitrˇnı´ sı´tı´ sousednı´ firmy (rˇa´dek 34). Vsˇechen ostatnı´ provoz je provoz z Internetu. Bohuzˇel jej nemu˚zˇeme nijak jednodusˇe specifikovat pomocı´ neˇjake´ho pravidla. Proto jsou uvedena pravidla na rˇa´dcıćh 30 azˇ 34. Nicˇemu to vsˇak nevadı´, a ućˇel je splneˇn. My tak budeme moci sve´mu sˇe´fovi ozna´mit splneˇnı´ u´kolu. Neˇco o IMQ

listopad 2005

Pu˚vodnı´m autorem jaderne´ho ko´du zarˇ´ızenı´ IMQ je Martin Devera (je mimochodem take´ autorem omezovacı´ disciplıńy HTB). Pu˚vodnı´ strańky projektu lze nale´zt na adrese http://luxik.cdi.cz/~devik/ /qos/imq.htm. Autor se vsˇak jizˇ projektu neveˇnuje a takte´zˇ ani jeho na´stupce. Protozˇe vsˇak byla potrˇeba zarˇ´ızenı´ typu IMQ natolik silna´, nasˇlo se neˇkolik nadsˇencu˚, kterˇ´ı se rozhodli v projektu pokracˇovat. Jako nejvıće zˇivotaschopny´ se jevı´ projekt na strańce




http://www.linuximq.net/. Je nejcˇasteˇji aktualizovany´ a pouzˇ´ıva´ jej nejvıće spra´vcu˚ (alesponˇ podle emailu˚, ktere´ chodı´ do linuxovyćh konferencı´). IMQ se skla´da´ ze dvou cˇa´stı´. Tou prvnı´ je samotny´ ovladacˇ v ja´drˇe. Ten nenı´ standardneˇ ani ve vanilla ja´drˇe (ja´dro, vydane´ na kernel.org), ani v obvyklyćh distribucıćh, jako naprˇ. RedHat. Je proto nutno sta´hnout patch do ja´dra a opatchovat jej. Patch pro prˇ´ıslusˇne´ verze je dostupny´ na strańkaćh projektu.

Instalace IMQ

Druhou cˇa´stı´ je modul do iptables, ktere´ take´ neumı´ standardneˇ pracovat se zarˇ´ızenı´m IMQ. Patch do iptables je opeˇt dostupny´ na strańkaćh projektu IMQ a opeˇt je nutno pouzˇ´ıt spra´vnou verzi ke konkre´tnı´ verzi iptables. Pak zby´va´ prˇekompilovat iptables. Jak opatchovat ja´dro se docˇtete v dokumentaci ja´dra, jak opatchovat a zkompilovat konkre´tnı´ verzi iptables se docˇtete na strańkaćh projektu IMQ a take´ na strańkaćh iptables (http://www.netfilter.org/). Po spra´vne´ kompilaci ja´dra se po nabootovańı´ objevı´ zarˇ´ızenı´ imq0 (a prˇ´ıpadneˇ dalsˇ´ı, pokud jsme prˇi kompilaci zadali pocˇet) a nebo je nutno nata´hnout prˇ´ıkazem modprobe imq patricˇne´ moduly. Parametrem modulu imq je numdevs, ktery´m specifikujeme, kolik virtua´lnıćh zarˇ´ızenı´ chceme pouzˇ´ıvat. Na´m stacˇ´ı jedno, defaultneˇ se vytva´ˇrejı´ dveˇ. Po natazˇenı´ spra´vne´ho modulu je nutne´ toto zarˇ´ızenı´ aktivovat, a to naprˇ´ıklad prˇ´ıkazem ip link set dev imq0 up a teprve pak s nı´m lze pracovat. Lze s nı´m pracovat i drˇ´ıve (prˇ´ıkazy iptables a tc), avsˇak IMQ nefunguje, resp. se neprojevuje konfigurace. Je nutno pamatovat na to, zˇe pro zprovozneˇnı´ IMQ musı´me patchovat ja´dro. Prˇi prˇ´ılisˇ velke´m provozu

Proble´my s IMQ

listopad 2005




nebo prˇ´ılisˇ kosˇate´m stromu disciplıń mu˚zˇe by´t ja´dro nestabilnı´ a s nı´m i cely´ syste´m. Take´ se mu˚zˇe sta´t, zˇe neˇktera´ starsˇ´ı verze ja´dra a verze IMQ je stabilneˇjsˇ´ı nezˇ noveˇjsˇ´ı verze ja´dra a IMQ. Je nutno chvı´li experimentovat. Sta´le se jedna´ o ko´d, ktery´ obsahuje neˇjake´ chyby a nenı´ dostatecˇneˇ odladeˇny´, nicmeńeˇ jizˇ je pouzˇitelny´ a take´ se cˇasto pouzˇ´ıva´. Pokud se va´m tedy bude zda´t, zˇe je syste´m nestabilnı´, zkuste IMQ odstranit z ja´dra a provozovat syste´m chvı´li bez omezovańı´ a nebo bez omezovańı´ se sdı´lenı´m kapacity. Prˇi proble´mech se take´ nebojte obra´tit na autory projektu cˇi do e-mailove´ konference, ktera´ je na strańkaćh projektu uvedena, protozˇe autorˇi jsou velmi ochotni ke spolupraći. Obvykle je jizˇ va´sˇ proble´m vyrˇesˇen a vy jen pouzˇ´ıva´te nevhodnou konfiguraci.

listopad 2005


čá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



(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-



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




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



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




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



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




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



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




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



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




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



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




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



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




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



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 :<port>) tak, jako se běžně používá pro testování klasické komunikace příkaz telnet <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




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



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


kvûten 2006




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




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



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




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



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




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



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


kvûten 2006


3 BEZPEČNOST V LINUXU

Recommend Documents