Bezpečná počítačová síť - People(dot)tuke(dot)sk

Transkript

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
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
BEZPEČNÁ POČÍTAČOVÁ SÍŤ
část 9, dı́l 3, kapitola 1, str. 1
dı́l 3, Bezpečnost v Linuxu
9/3.1
LINUXOVÉ JÁDRO, INSTALACE
LINUXU
Linuxové jádro je to, co se stará o přidělovánı́ hardwarových 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ı́ch, kde každá
větev má svého správce. Jednotlivé řady 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́nı́ jádra v řadě X.Y. Je-li čı́slo Y sudé,
pak se jedná o stabilnı́ řadu, 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 řadu vývojovou. Ta
sloužı́ vývojářům jádra k přidávánı́ nových vlastnostı́
a jejich testovánı́. 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ı́ch větvı́ ještě existujı́ dalšı́,
spravované různými vývojáři. Poměrně známá je tzv.
ac větev spravovaná jednı́m z vývojářů jádra – Alanem Coxem. Tyto větve vznikly proto, že do stabilnı́
řady nepronikly některé vlastnosti z různých 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ı́cı́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̌řeno na různém množstvı́ hardwaru, který vlastnı́
vývojáři 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́ řadě 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́řovou strukturu a Linux se jı́ držı́. Kořenem celého
prosinec 2003
adresářového systému je adresář /. V něm se nacházı́ dalšı́ adresáře, z nich nejvýznamnějšı́ jsou /etc,
/bin, /tmp, /var, /home a /usr. V adresáři /etc
se nacházı́ většina konfiguračnı́ch souborů, /bin je
adresář určený základnı́m utilitám systému, /tmp pak
sloužı́ k dočasnému vytvářenı́ 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́ři
/usr je pak umı́stěn zbytek programového vybavenı́
systému.
Na serverových systémech je z hlediska bezpečnosti vhodné, aby nebyly všechny adresáře umı́stěny na
jednom diskovém oddı́lu. Do adresáře /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́ře, 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́ři /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́ch logovacı́ch souborů v adresáři /var.
Podobných situacı́ nastává při běhu systému vı́ce.
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́řet logovacı́ soubory a ostatnı́ věci kromě
prosinec 2003
adresářů /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́nku 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ı́ce tento server ulehčuje kapacitě linky. Volba 1 GB je dostačujı́cı́. 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́nı́ bychom měli vzı́t v úvahu
swapovánı́. Linuxové jádro umožňuje swapovat jak
do souboru, tak přı́mo do diskového oddı́lu. Platı́, že
swapovánı́ do diskového oddı́lu je rychlejšı́, a proto
pro swap vyhradı́me dalšı́ diskový oddı́l.
Chceme-li navı́c zvýšit rychlost systému, je vhodné
oddı́ly swap a ostatnı́ mı́t na zvláštnı́ch discı́ch. 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́čtech na systému soubor /etc/passwd.
Hesla k jednotlivým účtům však umožňuje uložit v odděleném souboru /etc/shadow, který je navı́c 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́ře, 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́n, ale útočnı́k by pomocı́ tohoto viru
nedokázal zahltit linku. Administrátor navı́c 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́ně zbytečného softwaru, tı́m méně potenciálnı́ch zbytečných chyb.
prosinec 2003
prosinec 2003
9/3.2
ZÁPLATOVÁNÍ SYSTÉMU
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́nkách distributora a jsou obvykle dostupné
přes FTP server. Proto je po čisté instalaci systému
nutné zkontrolovat, zdali již nejsou vydány záplaty, a
pokud ano, je nutné je nainstalovat.
Většina distribucı́ má nějaký mechanismus pro automatickou instalaci bezpečnostnı́ch záplat. Je nutné se
tedy obrátit na dokumentaci k přı́slušné distribuci.
Pro bezpečnost systému je pravidelné záplatovánı́ klı́č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́nı́ pro
Automatické
záplatovánı́
systému v Debianu
prosinec 2003
něj nepředstavuje problém. Zjištěnı́ přı́tomnosti nových opravných balı́ků můžeme provést pomocı́ přı́kazu apt-get update, stáhnutı́ a nainstalovánı́ 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́ch intervalech spouštět z crond
(program pro automatické spouštěnı́ programů v daných intervalech). Tı́m zajistı́me automatickou aplikaci záplat do systému. Ovšem pozornost je nutné věnovat serverům, z kterých 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ı́čky, může do systému zcela nepozorovaně
dostat backdoor!
V poslednı́ verzi Debianu již nástroje na ověřovánı́ integrity existujı́, nicméně většina balı́ků nenı́ podepsána. To by měla napravit přı́štı́ verze Debianu (Sarge).
Automatické
záplatovánı́
v RedHatu
prosinec 2003
K automatickému záplatovánı́ v této distribuci sloužı́
nástroj up2date. Pro jeho použı́vánı́ je nutná registrace v RedHat Network na webovských stránkách
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́nem 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́n.
prosinec 2003
prosinec 2003
9/3.3
UŽIVATELSKÉ ÚČTY
Databáze uživatelských úč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́čtu – jako např. unikátnı́ ID účtu (UID – user
ID), čı́slo skupiny (GID), umı́stěnı́ domovského adresáře a použitý shell (interpretr přı́kazového řádku).
Shell bývá většinou nastaven na /bin/sh či jiný interpretr přı́kazového řádku, ale pokud chceme zabránit
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́nit uživatelům majı́cı́m na serveru poštovnı́ účet
v přihlášenı́.
prosinec 2003
prosinec 2003
9/3.4
BEZPEČNOST NA ÚROVNI
SOUBOROVÉHO SYSTÉMU
Linux standardně nepodporuje ACL (Access Control
List), tudı́ž jsou možnosti nastavenı́ práv u jednotlivých souborů/adresářů 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́řů je nutné povolit prováděnı́, jinak nenı́ možné do adresáře přejı́t.
Pokud má uživatel právo prováděnı́ u daného adresáře, ale nikoliv právo čtenı́, nemůže si vypsat seznam
souborů v tomto adresáři. 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́nı́
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ı́ 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́ch pı́smen je následujı́cı́: r –
čtenı́, w – zápis, x – prováděnı́, s – setuid/setgid, t –
sticky.
Nastavenı́ práv je typicky podstatné u konfiguračnı́ch
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́ch 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́ch přı́padech nenı́ možné práva nastavit pomocı́ klasických UNIXových práv a je nutné použı́t
ACL. Bohužel ACL práva nejsou součástı́ současné
stabilnı́ řady jádra 2.4.x, a tudı́ž se administrátor musı́
uchýlit k aplikaci záplat do zdrojových souborů jádra
a následně jádro rekompilovat. Naštěstı́ nová jádra
řady 2.6.x již ACL práva podporujı́ nativně. Nicméně
v současné době ještě neexistuje stabilnı́ jádro z této řady, tudı́ž jejich použitı́ na produkčnı́ch serverech
nenı́ doporučováno.
prosinec 2003
prosinec 2003
9/3.5
VZDÁLENÁ SPRÁVA SYSTÉMU
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́no. 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́na.
SSH zajišt’uje též ověřovánı́ identity stroje, na který se
přihlašujeme. Při prvnı́m přihlášenı́ si SSH uložı́ veřejný klı́č serveru, a pokud dojde ke změně veřejného
klı́če druhé strany, SSH okamžitě ukončı́ spojenı́, protože důvodem změny veřejného klı́č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́nı́ hesla (které je samozřejmě posı́láno šifrovaně) může být klient v protokolu
SSH 2 autentizován pomocı́ RSA/DSA klı́če, popř.
pomocı́ hostbased autentizace, kdy server nejprve ověřı́ klı́č 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́na velmi
zřı́dka a mı́sto nı́ se použı́vá autentizace pomocı́ páru RSA/DSA klı́čů. Ta funguje tak, že klient pomocı́
privátnı́ho klı́č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́ch klı́čů použitelných
pro tuto autentizaci, a pokud se mu podařı́ pomocı́
některého z nich ověřit podpis, tak klienta přihlásı́.
Pro Linux existuje vı́cero implementacı́ protokolu.
Nejznámějšı́ je implementace OpenSSH, kterou najdeme ve většině distribucı́. Obsahuje jak SSH klient,
tak server. Podporuje obě existujı́cı́ 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ı́ch systémů.
Bezpečná
konfigurace sshd
prosinec 2003
Konfiguraci sshd (SSH daemon, server implementujı́cı́ SSH protokol) bychom měli věnovat při zabezpečovánı́ 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́ny pouze lokálně. Navı́c bylo v minulosti v sshd objeveno několik kritických bezpečnostnı́ch
chyb, některé z nich mohl útočnı́k dokonce využı́t pro
zı́skánı́ 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́ch 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́ch (důvěryhodných) 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́na v přı́padě,
že nechceme zadávat při každém přihlášenı́ heslo, což
je užitečné zejména při použitı́ ssh ve skriptech, které
potom nemusejı́ být interaktivnı́. Prvnı́m krokem je
vygenerovánı́ páru klı́č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́nı́
klı́če pro SSH1 RSA autentizaci.
Použitı́ autentizace
pomocı́ páru
RSA/DSA klı́čů
v OpenSSH
Vygenerovaný veřejný klı́č pro SSH 2 se uložı́
do souboru ~/.ssh/id (rsa|dsa).pub, privátnı́
klı́č pak do ~/.ssh/id (rsa|dsa).pub. Veřejný
klı́č poté nakopı́rujeme na cı́lový stroj do souboru
~/.ssh/authorized keys (či jiného souboru, pokud je standardnı́ jméno 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́ři. Z bezpečnostnı́ch 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ı́cı́ IP protokol o autentizaci a šifrovánı́. Sestává se z několika protokolů implementovaných nad protokolem IP. V praxi se nejčastěji použı́vá protokol ESP (Encapsulating Security
Payload) použı́vaný k šifrovánı́ dat i zajištěnı́ integrity přenášených dat. Méně použı́vaný je protokol AH
(Authentication Header), který zajišt’uje pouze autentizaci přenášených 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́no 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ı́ch, mezi nimiž je
tunel vytvořen.
Dalšı́ nespornou výhodou IPsec je jeho rozšı́řenost –
oproti jiným podobným řešenı́m je IPsec standardizován a je k dispozici na většině použı́vaných 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ı́ch asociacı́. Bezpečnostnı́ asociace (SA, Security Associations) popisujı́ jednosměrnou relaci mezi dvěma stroji. Jednotlivé
asociace jsou definovány zdrojovou a cı́lovou IP adresou, unikátnı́m ID nazývaným SPI a bezpečnostnı́m
protokolem (AH nebo ESP).
Úkolem IKE je též autentizace obou stran. Autentizaci 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ı́č, který se použije spolu s daty
paketu na spočı́tánı́ 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́nı́ záplat do
jádra. Nejrozšı́řeně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́ny 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ı́ch s těmito jádry je tudı́ž hodně podobná té
v Open/FreeBSD (či dalšı́ch operačnı́ch 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́ch spojenı́
filtruje provoz na sı́t’ových rozhranı́ch (kartách) 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ı́ch. Firewall tedy
nekontroluje obsah jednotlivých 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ı́ce 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́ch 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́ch pravidel. Seznam tabulek, jež budou k dispozici, je závislý na konfiguraci jádra (zda byly zakompilovány, popř. zkompilovány jako moduly). Při
zpracovánı́ paketu se procházejı́ jednotlivá pravidla
v daném řetězci pravidel, pokud dané pravidlo platı́,
provede se u něj specifikovaná akce, což může být bud’
skok do jiného řetězce nebo předánı́ paketu přı́slušnému modulu netfilteru (pro úplnost, některé z akcı́ jsou
zpracovávány 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́nı́ paketů. V této tabulce jsou
definovány následujı́cı́ standardnı́ řetězce pravidel:
INPUT
příchozí pakety
OUTPUT
lokálně generované pakety
prosinec 2003
FORWARD
pakety routované přes tento stroj.
Dalšı́ řetězce si můžeme definovat pomocı́ volby -N
u iptables, pakety do nich budou zařazovány 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́nı́ a pozdějšı́ klasifikaci
paketů pomocı́ filtrů v QoS. Do poslednı́ tabulky, nat,
se zařazujı́ pakety vytvářejı́cı́ nové spojenı́. Jak již
název napovı́dá, tabulka se použı́vá pro NAT, tedy pro
překlad adres.
Syntaxe pro přidánı́ 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 řetě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 řetězce pravidla nebo některá z akcı́ implementována 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 řetězcı́ch INPUT, FORWARD a PREROUTING.
-o iface
Sı́t’ové rozhranı́, na které bude paket poslán. Volba je
platná jen v řetězcı́ch OUTPUT, FORWARD a POSTROUTING.
Tı́m nejsou možnosti iptables pro kategorizaci paketu samozřejmě zdaleka vyčerpány. 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́nı́ 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́no jednotlivými moduly. Popis standardnı́ch 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́ch se může spojenı́ asociované s aktuálně zpracovaným paketem nacházet. Možné stavy jsou:
Stavový firewall
INVALID – paket nenı́ asociován s žádným spojenı́m.
NEW – paket se snažı́ o navázánı́ nového spojenı́.
ESTABLISHED – paket je součástı́ již vytvořeného
spojenı́.
prosinec 2003
RELATED – paket se snažı́ o navázánı́ nového spojenı́, které je vázané na nějaké existujı́cı́ (např. poslánı́
ICMP paketu).
Akce prováděné
s pakety
V netfilteru jsou definovány tyto základnı́ akce s pakety:
ACCEPT – paket bude akceptován.
DROP – paket bude zahozen.
RETURN – ukončı́ zpracovánı́ tohoto řetězce pravidel.
Dalšı́ akce jsou definovány 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́na. Popřı́padě je vhodné některé služby povolit jen
z IP, z kterých budou využı́vány.
Pokud chceme zakázat nějakou službu, měli bychom
na to použı́t akci DROP, která paket kompletně
zahodı́. Lepšı́m řeš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́nı́ 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́nı́ 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
PŘÍKLAD SKRIPTU KONFIGURACE
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́čely počı́tačů
z vnitřnı́ sı́tě i z internetu poštovnı́ server, doménový
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́čelem na routeru nakonfigurovaný. Žádný jiný přı́stup uživatelé do
internetu mı́t nebudou.
Pořadujeme navı́c, 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́čelem správy obsahu webových stránek), 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 řádcı́ch 3 až 13 (viz ukázku skriptu s čı́slovanými
řá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́no sauvignon
nám a nebo někomu, kdo bude skript upravovat, řekně
zcela jistě vı́ce, než jen ip adresa 123.45.67.8. . .
Na řádcı́ch 21, 22 a 23 smažeme všechna pravidla
a všechny řetě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 řádcı́ch 26, 27 a 28 pak nastavı́me politiku pro
řetě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́ řetězec INPUT (řádek 75), řetězec FORWARD (řádek 86) a
řetězec OUTPUT (řádek 92). Jsou to totiž řetezce, kde
začı́ná průchod paketu firewallem.
Pro zopakovánı́ 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́ch rozhranı́ samotného routeru. Je nutné zdůraznit, že paket může
Řetězec INPUT
srpen 2004
mı́t v tabulce filter jinou cı́lovou (ale také zdrojovou) adresu, než jakou ji může mı́t v tabulkách 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́ch konfiguracı́ to bude zřejmé.
Na řá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 řetezec spoof.
Protože Netfilter zná implicitně jen řetězce INPUT,
FORWARD a OUTPUT (stále hovořı́me pouze o tabulce
filter), musı́ být v definici firewallu někde dřı́ve
řetězec spoof nadefinován. Tı́m mı́stem je řádek 35
a tam se nynı́ přesunuje naše pozornost.
Na řádku 31 zadefinujeme řetezec spoof a na řádcı́ch
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́ch sı́t’ových 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́nı́ zabezpečit.
Dalšı́m smyslem pravidel v řetězci spoof je zakázat
obecně routovánı́ adres z neveřejných sı́tı́. Tyto sı́tě
jsou trojı́ho druhu: 10.0.0.0/8, 172.16.0.0/12 a
192.168.0.0/16. Úkolem pravidel v řetězci spoof
je všechny korektnı́ pakety vrátit zpět ke zpracovánı́ na dalšı́ pravidlo v řetězci, ze kterého sem skočily.
V našem přı́padě to bude zpět do řetězce INPUT. eth1.
Nynı́ popı́šeme samotná pravidla v řetězci spoof. Na
řá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́nı́ na tomto rozhranı́
má někdy smysl, nicméně v našem přı́padě jej omezovat nepotřebujeme.
Na řá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ı́ch definicı́ch 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́ny v řetězci spoof a jsou
vráceny pro zpracovánı́ v řetězci INPUT.
Na řá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 řetezce spoofdrop.
Spoofdrop je opět řetězec, který nenı́ implicitně definován. 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 řádku 30.
V řetězci spoofdrop pak máme na řádku 31 akci, která způsobı́ zalogovánı́ informacı́ o takovémto paketu,
a na řádku 32 pak takový paket zahodı́me.
Vrátı́me se zpět do řetězce spoof a na řádcı́ch 39 až
41 pak vidı́me zpracovánı́ paketů, které jsou z neveřejného rozsahu. Na řádcı́ch 42 a 43 pak zpracováváme
pakety, které by měly přijı́t z virtuálnı́ho rozhranı́ loopback, nicméně dostaly se k nám odjinud, protože nevyhověly pravidlu na řádku 36. Ze zařı́zenı́ loopback
nám v obvyklých přı́padech chodı́ pakety, jejichž zdrojová nebo cı́lová adresa je právě 127.0.0.1.
srpen 2004
Na řádku 44 pak vracı́me do řetězce INPUT zpracovánı́ 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ı́cı́ch 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 řá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ı́c z předchozı́ho je zřejmé,
že pokud se paket ve vyhodnocovánı́ dostal až sem,
mohl přijı́t jedině z vnitřnı́ho sı́t’ového rozhranı́.
Vrátı́me jej tedy ke zpracovánı́ v řetězci INPUT.
Vlastnosti Netfilteru jsou takové, že pokud při zpracovánı́ paketu v aktuálnı́m řetězci nevyhovı́ žádné pravidlo, vracı́ se paket ke zpracovánı́ do řetězce, ze kterého skočil do právě zpracovávaného. V tuto chvı́li
je tedy aktuálnı́m zpracovávaným řetězcem spoof a
nadřazený řetězec je INPUT. Pokud je však aktuálnı́m
řetězcem INPUT, FORWARD nebo OUTPUT, použije se
pro zpracovánı́ paketu nastavená politika v pravidlech
26, 27 či 28.
Dobrým zvykem je nespoléhat se na takovéto chovánı́
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 řádku 46. Skočı́me do řetězce spoofdrop, na řádku
31 jej zalogujeme a na řá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̌ řetězec spoof a vracı́me
se do řetězce INPUT na řádek 76. Na něm akceptujeme
všechny pakety, které již souvisejı́ s existujı́cı́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́na u druhé skupiny paketů je
tato volba podstatná, protože po navázánı́ spojenı́ na
porty, které máme nı́že povoleny, může komunikace probı́hat po jiných portech, na kterých 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 řá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 řádku 78 povolujeme ICMP protokol.
Řádku 79 pak vyhovı́ všechny pakety, které patřı́ do
rozsahu adres vnitřnı́ sı́tě (a dı́ky předcházejı́cı́mu průchodu řetězcem spoof jsme si tı́m jisti) a budeme je
dále zpracovávat v řetězci int-fw. Ten popı́ši později.
srpen 2004
Řádku 80 pak vyhovı́ všechny pakety, které přicházejı́
z vnějšı́ho sı́t’ového rozhranı́, a budeme je zpracovávat
v řetězci bad-fw. Opět je popı́ši později.
Řádek 81 je pak určen paketům, které patřı́ ke služ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́ně mohli bychom pro většı́ bezpečnost založit dalšı́ řetězec,
jenž by napřı́klad kontroloval vybrané MAC adresy.
Také bychom mohli tyto pakety akceptovat s upravenými podmı́nkami již na řádku 45, nicméně tato
optimalizace (paket by neprocházel 6 pravidel navı́c)
nenı́ nijak výrazná. My tak můžeme zachovat filozofii řetě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́no 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ı́ch 26 až 28, na řádku 82 zalogujeme všechny
přı́padné nezpracované pakety v řetězci INPUT a na
řádku 83 jej pak zahodı́me.
Obecně je vhodné při vytvářenı́ konfigurace před každou akcı́ DROP či REJECT provést zalogovánı́. 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́ch nervů a chvilek
nad klávesnicı́ odstranit. Věřte, že to bývá nejčastěnšı́ přı́čina dlouhého odstraňovánı́ chyby v konfiguraci
firewallu. Proto ještě jednou doporučuji, aby si před
každým REJECT nebo DROP začátečnı́ci uváděli pravidlo s akcı́ LOG. Také je vhodné formátovat začátek
srpen 2004
logovacı́ho řetě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 řádku 62 a tudı́ž dřı́ve, než jsme se poprvé odkázali
na řetězec int-fw v řetězci INPUT (což bylo na řádku
79), definujeme samotný řetězec int-fw.
Na řá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́ně 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́ch 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 řádku 50 pak zakážeme uživatelům z vnitřnı́ sı́tě
přı́stup na službu ssh.
V pravidle na řádku 51 pak povolı́me všechna spojenı́ na náš router a tı́m i dostupnost všech ostatnı́ch
běžı́cı́ch služeb všem uživatelům vnitřnı́ sı́tě.
Řetězec bad-fw je definován pravidlem na řádku 62.
Na řádcı́ch 63, 64, 65, 67, 68 a 69 pak všem povolujeme přı́stup na definované služby. Na řádcı́ch 66 a 71
pak přı́stup na službu ssh budeme zpracovávat v řetězcı́ch ssh-me, definovaných na řádcı́ch 53 až 56.
Přı́stup na službu ftp pak definujeme v řetězci ftp-me
na řádcı́ch 58 až 60. A protože se na tyto řetezce dá
skočit jen z řetězce bad-fw a tomu vyhovujı́ jen pakety
srpen 2004
z řádku 80, omezujeme tak přı́chozı́ pakety z vnějšı́ho
sı́t’ového rozhranı́ (a tudı́ž z internetu). Smysl pravidla
na řá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́ch sı́t’ových rozhranı́ch, 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̌řit, 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́n výhradně
přes proxy server. Tudı́ž řetězec FORWARD by mohl
obsahovat jediné pravidlo, a to pravidlo na řádku 89.
My si však na řádku 86 zalogujeme všechny pokusy
o navázánı́ spojenı́ po protokolu tcp, dále pravidlem
na řá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́nı́ paketů (tedy i možné pokusy utočnı́ka z venku dostat se do našı́
vnitřnı́ sı́tě) a nakonec na řádku 89 všechny takové
pakety zahodı́me.
Řetězec OUTPUT
srpen 2004
Zbývá nám vyřešit řetězec OUTPUT. Pro zopakovánı́
uvedu, že řetě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́ch rozhranı́ našeho routeru. Typicky se jedná
o pakety generované našı́m routerem.
Na řádku 92 si zalogujeme všechny pakety, které zajišt’ujı́ navazovánı́ 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́ch
služeb.
Na řádku 93 pak povolı́me veškerý odchozı́ provoz.
Na řádcı́ch 95 až 109 pak smažeme veškerá pravidla
v tabulkách nat a mangle, které podle našı́ politiky
musı́ být prázdné.
Jediné pravidlo, které zbývá popsat, je pravidlo na
řá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́nı́ 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́no spojenı́, server obsluhujı́cı́ 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́nı́ na službu auth. Opět mu
paket zahodı́me bez oznámenı́. Za nějakou dobu pokus o navázánı́ na službu auth vzdá a bude pokračovat
v sestavovánı́ 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́nı́
spojenı́ na službu smtp, a tak takovéto pakety již nebudou splňovat podmı́nky 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̌řujı́cı́mi
na službu auth obezřetným způsobem.
V souvislosti s logovánı́m paketů je dobré dát pozor
na množstvı́ takovýchto paketů. Náš router nemusı́ mı́t
dostatečně velký výkon CPU, a tak nebude bez problému stı́hat logovánı́ paketů. Tı́m se i zpomalı́ průchod
ostatnı́ch 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ı́ch řetě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́ch řetězcı́ch. Modifikace takových 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ı́ce a pokud máme
velký provoz, vyplatı́ se vybudovat si pomocı́ vlastnı́ch řetě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́na 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
řádků, samotná čı́sla řádků, dvojtečka za čı́slem řádku
a mezera za touto dvojtečkou. Některé řá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ı́ řádek, který už
nemá čı́slo a je odsazen. Takto upravený pokračovacı́
řádek by ale ve skutečném skriptu nefungoval, protože
na konci předchozı́ho řá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 -d
iptables -A spoof -i
--dport bootps
iptables -A spoof -j
lo -j ACCEPT
"${int_net0_0}" -i "${int_dev0}" -j RETURN
"${int_net0_0}" -j spoofdrop
192.168.0.0/16 -j spoofdrop
172.16.0.0/12
-j spoofdrop
10.0.0.0/8
-j spoofdrop
127.0.0.0/8
-j spoofdrop
127.0.0.0/8
-j spoofdrop
"${ext_dev}" -j RETURN
0.0.0.0 -d 255.255.255.255 -p udp --sport bootpc
-j RETURN
spoofdrop
47:
48:
49:
50:
51:
iptables
iptables
iptables
iptables
-N
-A
-A
-A
int-fw
int-fw -s "${pc1}" -p tcp --dport squid -j REJECT
int-fw -p tcp --dport ssh -j REJECT
int-fw -j ACCEPT
iptables
iptables
iptables
iptables
-N
-A
-A
-A
ssh-me
ssh-me -s "${ogebenec}"
ssh-me -s "${sauvignon}"
ssh-me -j RETURN
52:
53:
54:
55:
56:
57:
srpen 2004
-j ACCEPT
-j ACCEPT
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
PŘÍKLAD POUŽITÍ TABULKY NAT
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́nı́
Na našem routeru pak provozujeme pro účely počı́tačů
z vnitřnı́ sı́tě i pro počı́tače z internetu poštovnı́ server,
doménový 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́čelem na routeru nakonfigurovaný. Dále chceme umožnit uživatelům
ve vnitřnı́ sı́ti protokol icmp, konkrétně umožnit ověřenı́, 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́čelem správy obsahu
webových stránek).
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́ny v ukázkovém skriptu zřejmým způsobem. Požadujeme, aby provoz mezi počı́tači v jednotlivých vnitřnı́ch sı́tı́ch 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ı́cı́. 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́ny na server ve vnitřnı́ sı́ti, jehož adresa je 192.168.1.7.
Totéž přesměrovánı́ 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́nı́ 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́nı́
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 řádcı́ch 3 až 40 (skript s čı́slovanými řá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 řádcı́ch 121 až 129 v pravidlech INPUT již nám
známým způsobem ověřı́me, zda pakety přicházejı́cı́
z jednotlivých sı́t’ových zařı́zenı́ majı́ správnou zdrojovou adresu. Za zmı́nku 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 řádku 126 nám pak řı́ká, že všechny
pakety z našich vnitřnı́ch sı́tı́ obsloužı́me v pravidlech
řetězce int-fw, který jsme si zadefinovali na řádcı́ch
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ı́ce 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 řetězci spoof (řádky 66
až 70). Všechny pakety ostatnı́ch podsı́tı́ ze sı́tě
192.168.0.0/16 totiž zahodı́me (ř. 74).
Pravidlo na řá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́ch 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 řádku 128 a 129 pak zalogujeme a zahodı́me
všechny pakety, které nevyhověly žádnému pravidlu
v řetězci INPUT. Upozorňuji, že žádný takový přı́pad
by neměl nastat.
Na řádcı́ch 107 až 119 definujeme řetězec bad-fw,
kde je nastaven přı́stup podle výše uvedených požadavků. Přı́stup na poštovnı́, webový a doménový
server všem počı́tačům z internetu.
Na služby ftp, ssh a VPN serveru pak přı́stup omezujeme v řetězcı́ch 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 řetězce OUTPUT jen logujeme všechna
odchozı́ navazujı́cı́ spojenı́ z našeho serveru. Provoz
neomezujeme nijak.
V pravidlech řetězce FORWARD provádı́me vše známé
již z dřı́vějška. Pravidlo na řádku 154 pak řı́ká, že
provoz mezi počı́tači ve VPNce je neomezovaný. Pravidlo na řádku 155 se odkazuje na pravidla v řetě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 řádcı́ch 156 a 157 pak definujı́ přı́stup na
přı́slušné počı́tače v našı́ vnitřnı́ sı́ti. Dı́ky řá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ı́nky 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́nı́
paketů z internetu určených 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 řá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 řetezci
to-ext ip (jsme v tabulce nat).
V pravidle na řá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 řetězci FORWARD, zpracujeme jej právě pravidlem 157 a následně řetězcem to-amonit.
Pak již paket dále nenı́ v tabulce filter zpracováván
a v tabulce nat také nevyhovuje žádnému pravidlu
POSTROUTING (avšak akceptuje jej námi nastavená
politika) a je odeslán 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 řetězci PREROUTING. Paket je předán do tabulky
filter, kde jej zpracuje pravidlo na řádku 150 řetězce FORWARD. Dále paket putuje opět do tabulky nat,
kde vyhovı́ pravidlu 208 řetězce POSTROUTING, a akcı́ MASQUERADE je zdrojová adresa přepsána 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́nı́ 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́n.
To si mechanismus obsluhujı́cı́ 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́nı́ 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́nlivá.
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 řetězci
PREROUTING pravidlem na řádku 189 a následně
v řetězci to-terminalPC pravidlem na řádce 202.
Paket pak již putuje do tabulky filter, kde jej zpracujeme v řetězci FORWARD v pravidle 156 a následně
v řetězci to-terminalPC pravidlem na řádku 139.
srpen 2004
Pak paket opět putuje do tabulky nat, avšak nevyhovuje žádnému pravidlu v řetězci POSTROUTING.
Vyhovuje však nastavené politice (přı́kaz na řá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́nem 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́nu (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 řá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 řetězci PREROUTING nic neodehraje, paket
putuje do tabulky filter a tam je zpracován v pravidle 150 řetězce FORWARD. Když opouštı́ tabulku nat,
tak dı́ky pravidlu v řetězci POSTROUTING na řádku
206 jej zpracujeme v řetězci from-terminalPC pravidlem na řá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́nu 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 řádku 206, kde pošleme paket na
zpracovánı́ do řetezce from-terminalPC a pravidlem
na řá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 řá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́nky 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 řá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 řádku 178 přesměrovává pouze jeden port, kdežto
pravidlo na řádku 179 pak zbývajı́cı́ pakety s našı́ primárnı́ externı́ adresou jakou cı́lovou akceptuje. Tı́m
zajistı́me, že bude paket do tabulky filter předán se
správnou cı́lovou adresou. Za domácı́ 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̌řte ale, že s přepisovánı́m
hlaviček v paketu lze dosáhnout velmi zajı́mavých
výsledků a možných řeš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 řádků, samotná čı́sla řádků, dvojtečka za čı́slem
řádku a mezera za touto dvojtečkou. Některé řá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ı́ řádek, který už nemá čı́slo a je odsazen. Takto upravený
srpen 2004
pokračovacı́ řádek by ale ve skutečném skriptu nefungoval, protože na konci předchozı́ho řá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:
# nastaveni
iptables -t
iptables -t
iptables -t
POLICY
filter -P INPUT DROP
filter -P FORWARD DROP
filter -P OUTPUT ACCEPT
56:
57:
58:
59:
60:
# Logovaci retezce
iptables -N spoofdrop
iptables -A spoofdrop -j LOG
iptables -A spoofdrop -j DROP
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
# Anti-spoofing, ktery castecne dela jadro
iptables -N spoof
iptables -A spoof -i lo -j ACCEPT
iptables -A spoof -s "${int_net0_0}"
-i "${int_dev0}"
iptables -A spoof -s "${radotin_net}" -i "${vpn_dev0}"
iptables -A spoof -s "${rubena_net}"
-i "${vpn_dev0}"
iptables -A spoof -s "${frydlant_net}" -i "${vpn_dev0}"
iptables -A spoof -s "${boleslav_net}" -i "${vpn_dev0}"
iptables -A spoof -s "${hradec_net}"
-i "${vpn_dev0}"
iptables -A spoof -s "${ext_net0_0}"
-i "${ext_dev}"
iptables -A spoof -s "${firemni_vpn}" -j spoofdrop
iptables -A spoof -s "${ext_net0_0}" -j spoofdrop
iptables -A spoof -s 192.168.0.0/16
-j spoofdrop
iptables -A spoof -s 172.16.0.0/12
-j spoofdrop
srpen 2004
-j
-j
-j
-j
-j
-j
-j
RETURN
RETURN
RETURN
RETURN
RETURN
RETURN
RETURN
76:
77:
78:
79:
80:
iptables
iptables
iptables
iptables
iptables
-A
-A
-A
-A
-A
spoof
spoof
spoof
spoof
spoof
-s
-s
-d
-i
-j
10.0.0.0/8
-j spoofdrop
127.0.0.0/8
-j spoofdrop
127.0.0.0/8
-j spoofdrop
"${ext_dev}" -j RETURN
spoofdrop
81:
82:
83:
84:
85:
# Pravidla pro skok z INPUTu
iptables -N int-fw
iptables -A int-fw -p tcp --dport ssh -j REJECT
iptables -A int-fw -j ACCEPT
86:
87:
88:
89:
90:
91:
92:
iptables
iptables
iptables
iptables
iptables
iptables
-N
-A
-A
-A
-A
-A
ftp-me
ftp-me
ftp-me
ftp-me
ftp-me
ftp-me
iptables
iptables
iptables
iptables
-N
-A
-A
-A
ssh-me
ssh-me -s "${ogebenec}" -j ACCEPT
ssh-me -s "${bystrc}"
-j ACCEPT
ssh-me -j DROP
iptables
iptables
iptables
iptables
iptables
iptables
iptables
-N
-A
-A
-A
-A
-A
-A
to_ipsec
to_ipsec
to_ipsec
to_ipsec
to_ipsec
to_ipsec
to_ipsec
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
-N
-A
-A
-A
-A
-A
-A
-A
-A
bad-fw
bad-fw
bad-fw
bad-fw
bad-fw
bad-fw
bad-fw
bad-fw
bad-fw
-s
-s
-s
-s
-j
"${mitas}"
"${kontik}"
"${ogebenec}"
"${bystrc}"
DROP
-j
-j
-j
-j
ACCEPT
ACCEPT
ACCEPT
ACCEPT
93:
94:
95:
96:
97:
98:
99:
100:
101:
102:
103:
104:
105:
-s
-s
-s
-s
-s
-j
"${radotin}"
"${rubena}"
"${frydlant}"
"${boleslav}"
"${hradec}"
DROP
-j
-j
-j
-j
-j
ACCEPT
ACCEPT
ACCEPT
ACCEPT
ACCEPT
106:
107:
108:
109:
110:
111:
112:
113:
114:
115:
-p
-p
-p
-p
-p
-p
-p
-p
tcp
tcp
tcp
tcp
tcp
udp
tcp
50
--dport
--dport
--dport
--dport
--dport
--dport
--dport
smtp
https
ssh
ftp
domain
domain
auth
-j
-j
-j
-j
-j
-j
-j
-j
ACCEPT
ACCEPT
ssh-me
ftp-me
ACCEPT
ACCEPT
REJECT
to_ipsec
srpen 2004
116:
117:
118:
119:
iptables
iptables
iptables
iptables
-A
-A
-A
-A
bad-fw
bad-fw
bad-fw
bad-fw
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
iptables
-A
-A
-A
-A
-A
-A
-A
-A
-A
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
-p
-p
-j
-j
51
-j to_ipsec
udp --sport 500 --dport 500 -j to_ipsec
LOG
DROP
120:
121:
122:
123:
124:
125:
126:
127:
128:
129:
-j
-m
-p
-p
-p
-s
-i
-j
-j
spoof
state --state ESTABLISHED,RELATED
tcp \! --syn -m state --state NEW
tcp \! --syn -m state --state NEW
tcp --syn -m state --state NEW -j
"${firemni_vpn}" -j int-fw
"${ext_dev}"
-j bad-fw
LOG
DROP
-j ACCEPT
-j LOG
-j DROP
LOG
130:
131:
132:
133:
134:
# Forwardovaci pravidla
iptables -N int-ext
iptables -A int-ext -p icmp -j ACCEPT
iptables -A int-ext -j REJECT
135:
136:
137:
138:
139:
140:
141:
142:
iptables
iptables
iptables
iptables
iptables
iptables
iptables
-N
-A
-A
-A
-A
-A
-A
to-terminalPC
to-terminalPC
to-terminalPC
to-terminalPC
to-terminalPC
to-terminalPC
to-terminalPC
iptables
iptables
iptables
iptables
-N
-A
-A
-A
to-amonit
to-amonit -p tcp -s "${mitas}" --dport 3050 -j ACCEPT
to-amonit -p tcp -s "${kontik}" --dport 3050 -j ACCEPT
to-amonit -j DROP
iptables
iptables
iptables
iptables
iptables
iptables
iptables
-A
-A
-A
-A
-A
-A
-A
FORWARD
FORWARD
FORWARD
FORWARD
FORWARD
FORWARD
FORWARD
-p
-p
-p
-p
-p
-j
tcp --dport https
tcp --dport 1443
tcp --dport 8002
tcp --dport auth
icmp -j ACCEPT
DROP
-j
-j
-j
-j
ACCEPT
ACCEPT
ACCEPT
REJECT
143:
144:
145:
146:
147:
148:
149:
150:
151:
152:
153:
154:
155:
srpen 2004
-j
-m
-p
-p
-p
-s
-s
spoof
state --state ESTABLISHED,RELATED -j ACCEPT
tcp \! --syn -m state --state NEW -j LOG
tcp \! --syn -m state --state NEW -j DROP
tcp --syn -m state --state NEW -j LOG
"${firemni_vpn}" -d "${firemni_vpn}" -j ACCEPT
"${int_net0_0}" -o "${ext_dev}"
-j int-ext
156:
157:
158:
159:
iptables
iptables
iptables
iptables
-A
-A
-A
-A
FORWARD
FORWARD
FORWARD
FORWARD
-d
-d
-j
-j
"${terminal}"
"${amonit}"
LOG
DROP
-j to-terminalPC
-j to-amonit
160:
161:
162:
163:
# Vystupni pravidla
iptables -A OUTPUT -p tcp --syn -m state --state NEW -j LOG
iptables -A OUTPUT -j ACCEPT
164:
165:
166:
167:
168:
169:
170:
## Tabulka nat
# zruseni a nulovani stavajicich pravidel
iptables -t nat -F
iptables -t nat -X
iptables -t nat -Z
171:
172:
173:
174:
175:
# nastaveni
iptables -t
iptables -t
iptables -t
POLICY
nat -P PREROUTING ACCEPT
nat -P POSTROUTING ACCEPT
nat -P OUTPUT ACCEPT
176:
177:
178:
179:
iptables -t nat -N to-ext_ip
iptables -t nat -A to-ext_ip -p tcp --dport 3050 -j DNAT --to
"${amonit}":3050
iptables -t nat -A to-ext_ip -j ACCEPT
180:
181:
182:
183:
184:
185:
186:
iptables -t nat -N to-terminalPC
iptables -t nat -A to-terminalPC
"${terminal}":443
"${terminal}":1443
"${terminal}":8002
-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
PŘÍKLAD POUŽITÍ TABULKY
MANGLE
Celý tento přı́klad svou koncepcı́ zapadá do kapitoly
o omezovánı́ 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́nı́ sı́t’ového provozu.
Tabulka mangle se v linuxovém firewallu netfilter použı́vá zřı́dka. Je vhodná zejména ke značkovánı́ paketů. Takové značkovánı́ se hodı́ zejména 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́ch jádrech do verze 2.4.17 včetně měla tabulka mangle pouze dva vestavěné řetězce.
PREROUTING pro zpracovánı́ přı́chozı́ch paketů před
routovánı́m a OUTPUT pro zpracovánı́ paketů vygenerovaných lokálně a zpracovaných opět před
routovánı́m. Od jádra 2.4.18 pak přibyly řetězce
INPUT pro pakety přicházejı́cı́ dovnitř počı́tače,
únor 2005
FORWARD pro pakety procházejı́cı́ 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́řenı́ posloupnosti pravidel postupovat od obecných
podmı́nek ke konkrétnějšı́m.
Zadánı́
únor 2005
Definice zadánı́ v kapitole o omezovánı́ sı́t’ového provozu je pak následujı́cı́. Jsme většı́ firmou přistupujı́cı́
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 ředitele, 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́n. 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ı́ch 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ı́ch pravidel, a to těch,
které se týkajı́ tabulky mangle. Samozřejmě bude nutné správně nakonfigurovat i pravidla v tabulkách 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 řetězci
FORWARD, protože zde jsou pakety z vnitřnı́ch sı́tı́ před
maškarádou (a tudı́ž nemajı́ zkreslenou zdrojovou adresu) a pakety z Internetu jsou již po odmaškarádovánı́, tudı́ž konečná správná cı́lová adresa je také známa. Pakety, které generuje náš router, označkujeme
v pravidlech řetězce OUTPUT. Jediné, co neznačkujeme, jsou pakety, které jsou určeny našemu počı́tači.
Na řádcı́ch 1 až 6 definujeme proměnné, které dále
použijeme v přı́kladu našeho firewallu.
Na řádcı́ch 9 až 16 definujeme defaultnı́ politiku pravidel v jednotlivých řetězcı́ch.
Na řá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̌řuje do Internetu (neznáme cı́lovou
adresu), a dále provoz, který směřuje do vnitřnı́ sı́tě
sousednı́ firmy.
Na řádku 19 je pak provoz, který generuje počı́tač
pana ředitele.
únor 2005
Na řádku 20 je obdobně totéž pro pakety směřujı́cı́ do
našı́ vnitřnı́ sı́tě.
Na řádku 21 pak označı́me provoz, který směřuje do
počı́tače pana ředitele.
Dále na řádcı́ch 22 a 23 označı́me provoz, který směřuje 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 řádcı́ch 24 a 25.
Pak je ještě nutno označit provoz, který generuje náš
router. To provedeme na řá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̌řuje z vnitřnı́ch sı́tı́ a z Internetu na náš router. Proč
takový provoz neoznačı́me, je vysvětleno v kapitole
o omezovánı́.
únor 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́nor 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
"${net_sousedni_firma}"
"${net_sousedni_firma}"
-d ${net_sousedni_firma}"
-s ${net_sousedni_firma}"
iptables -t mangle -A OUTPUT -j
únor 2005
MARK
MARK
MARK
MARK
MARK
--mark
--mark
--mark
--mark
--mark
20
22
21
24
30
-s
-s
-d
-d
-s
"${net_nase_firma}"
"${pc_nas_reditel}"
"${net_nase_firma}"
"${pc_nas_reditel}"
MARK --mark 31 -d
MARK --mark 40 -s "${net_nase_firma}
MARK --mark 40 -d "${net_nase_firma}
MARK --mark 40 -s "${vnitrni_ip_0}"
MARK --mark 40 -s "${vnitrni_ip_1}"
MARK --mark 50 -s "${nase_verejna_ip}"
9/3.7
IDS
IDS (Intrusial Detection System) jsou aplikace určené
pro automatickou detekci nejrůznějšı́ch forem útoků
cı́lených 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ı́cı́ 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ı́ch typů analyzuje pakety
ještě před tı́m, než jsou dále zpracovány v operačnı́m
systému a aplikacı́ch, 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 řešenı́mi, nemonitorujı́ sı́t’ový provoz, ale logy systému/programů. V některých 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́ně nejčastějšı́m cı́lem pozornosti IDS jsou pokusy o průnik
pomocı́ známějšı́ch nástrojů využı́vajı́cı́ch známých
bezpečnostnı́ch chyb, pokusy o skenovánı́ portů a taktéž neplatné pakety, které jsou často použı́vány 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ı́ch sı́tı́, stejně tak dobře
může být monitorován provoz na lokálnı́ sı́ti. To může
administrátoru posloužit na detekci přı́padných problémů na lokálnı́ sı́ti – jako např. šı́řenı́ nejrůznějšı́ch
červů.
Možné je i použitı́ jako nástroje pro monitorovánı́ 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ı́ně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
řešenı́. Podporuje detekci velkého množstvı́ sı́t’ového
provozu pomocı́ předdefinovaných 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́nı́, zahlcovánı́ IDS pakety se změněnými
zdrojovými IP adresami obsahujı́cı́mi data, která způsobı́ logovánı́ 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́nı́ sı́tě atd. Kromě toho poskytuje některé
základnı́ služby sı́t’ového IDS, jako např. detekci skenovánı́ 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́na
začı́najı́cı́m administrátorům.
Kromě standardnı́ch 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ı́ce konfigurovatelným. Jednı́m z nejznámějšı́ch podobných 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́nı́ 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́č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 řešı́ problémy s možnou děravostı́ takovýchto
kritických serverů – i když se útočnı́kovi podařı́ zı́skat
dı́ky bezpečnostı́ chybě v takovémto serveru účet root
(či jiný lokálnı́ úč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́řů s programy, nebude mı́t přı́stup k některým funkcı́m jádra
(jako např. natahovánı́ 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́ch 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́ce s pamětı́ (což jsou na UNIXech jedny z nejčastějšı́ch) pomocı́ několika technik (nespustitelné stránky, randomizace adresnı́ho prostoru aplikace, . . . ).
Nicméně 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ı́c
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́ch 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́ch programů,
v nichž se čas od času mohou objevit bezpečnostnı́
chyby. Ale samotné pravidelné záplatovánı́ nestačı́,
systém musı́ být nějakým rozumným způsobem nakonfigurován, aby byl bezpečný. Při zabezpečovánı́
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́ch let a nesl poetické
označenı́ SATAN (Security Administrator Tool for
Analyzing Networks), umožňoval hledat několik druhů běžných bezpečnostnı́ch chyb na specifikovaných
strojı́ch.
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́ch bezpečnostnı́ch chyb. Nicméně 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́ch služeb spuštěných 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́ch známých bezpečnostnı́ch chyb v nich.
Kromě toho je schopen detekovat např. přı́tomnost
některých 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́na jednotlivá zjištěná bezpečnostnı́ rizika. Často též doplnı́ instrukce, jak zneužitı́ této chyby zabránit, popř. i odkaz na podrobnějšı́ informace
(např. konference bugtraq, databáze bezpečnostnı́ch
chyb CVE či CERT). To administrátorovi umožňuje
poměrně rychle a jednoduše otestovat bezpečnostnı́
stav svých serverů. Nicméně je nutno poznamenat,
že Nessus zdaleka nenı́ nástrojem neomylným a všeodhalujı́cı́m. Spı́še se jedná o pomůcku, která může
administrátorovi usnadnit zabezpečovánı́ 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ı́ch problémů. Je postaven na architektuře
klient-server, ze serveru probı́há ono scannovánı́, jeho
průběh je nicméně řı́zen klientem. Server je provozuschopný na velkém množstvı́ UNIXových operačnı́ch
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́nı́ dalšı́ch testů pomocı́ zásuvných modulů napsaných 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́nı́ snažı́ být co nejvı́ce důsledný
– nepředpokládá přı́tomnost určitých služeb na pevně
daných 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́nek 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́ně je možné, že skript nahlásı́ nepřı́tomnost některých knihoven (např. GTK), v takovém přı́padě musı́me doinstalovat přı́slušné balı́čky. Je nutné
nainstalovat jak balı́ky obsahujı́cı́ 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́nı́
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́čty v jeho databázi (tito uživatelé nepotřebujı́ normálnı́ účet na daném stroji). Oprávněnı́
jednotlivých 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 řeč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́ch
prosinec 2003
portů (u protokolu TCP, omezeně i UDP) na daném
stroji. Pro většinu situacı́ nastavı́me metodu scannovánı́ portů bud’ na connect() nebo SYN scan. Metoda
connect() scan je nejběžnějšı́ typ scannovánı́ 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́nit zalogovánı́ onoho pokusu
o spojenı́ u jednoduššı́ch firewallů.
Operačnı́ systém vzdálenoho stroje může být též detekován pomocı́ typického chovánı́ jeho TCP/IP zásobnı́ku. To může být nežádoucı́, čı́m méně 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́ch 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́nı́ všech portů v této databázi a
ještě všech privilegovaných 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́no pro dané služby.
Obrázek: Nessus – nastavenı́ uživatelských 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ı́nku 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́nı́ 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́nı́ spolehlivějšı́, nicméně
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ı́cı́ 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́ch 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́ny 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́nı́ 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́na služeb na nich nalezených. 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́nı́.
Obrázek: Nessus – výsledky testu:
Při vytvářenı́ nástroje Nessus byl brán zřetel i na to, že
jeden server může být použı́ván vı́ce 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ı́ch adresářů
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́ře. 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́na v přı́padě, že nessusd je puštěný na nějaké veřejné
IP a má k němu přı́stup vı́ce 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́č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́nı́
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́no, 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́ch (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́ci s uživatelskou databázı́ je
nessus-rmuser, pomocı́ nějž můžeme zrušit existujı́cı́ho uživatele.
Mějme modelovou lokálnı́ sı́t’, na které je linuxový
server obstarávajı́cı́ 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́n pro běžnou administrativnı́ práci,
nenı́ na něm provozována 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ı́ce 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́ch 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ı́cı́ na vysokých 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́ch „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ı́ch nepoužı́váme žádné
anti-DoS nastavenı́ firewallu, které by způsobovalo
zahazovánı́ paketů přicházejı́cı́ch ve velkých 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́no a heslo pro poštovnı́ úč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́chto 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ı́ch scanu se nám objevil pouze stroj
172.16.17.1, u ostatnı́ch strojů nevygeneroval Nessus
žádné varovánı́ (což ukazuje, že konfigurace firewallů
těchto dvou pracovnı́ch 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́na verze se záplatou opravujı́cı́ tuto bezpečnostnı́
chybu.
Nicméně 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ı́ch 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́nı́ na serveru je jedna
z nejčastějšı́ch chyb, kterých se dopouštějı́ začı́najı́cı́
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́ny.
Dále se ve varovánı́ch 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́nová jména, které
nemůže DNS server sám zodpovědět, a proto je musı́ přeložit za pomoci nadřazených jmenných 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́nová jména 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́n 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́na 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ı́ch rizik zůstane před jeho
zrakem z principu zcela skryta – přı́kladem takových
bezpečnostnı́ch 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́chnout rukou. Napřı́klad v minulosti bylo v jádře Linuxu objeveno několik kritických lokálnı́ch bezpečnostnı́ch chyb, které
umožňovaly lokálnı́m uživatelům zı́skat účet uživatele root. A navı́c ani to, že na daném stroji nemajı́ žádnı́
dalšı́ uživatelé účet (popř. účet majı́ jen důvěryhodnı́),
nenı́ zárukou nezneužitelnosti podobných chyb – útočnı́k může pro zı́skánı́ neprivilegovaného účtu použı́t
bezpečnostnı́ch děr v jiných spuštěných daemonech
(či třeba skriptech, pokud se jedná o www server).
Závěrem
prosinec 2003
Navı́c 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́nı́ 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́n. Nemusı́ se přitom jednat ani o selhánı́ administrátora, v dnešnı́ době existujı́ např. tzv. black hat
komunity, skupiny lidı́ s velmi vysokou znalostı́ IT
bezpečnosti zabývajı́cı́ch se předevšı́m hledánı́m bezpečnostnı́ch děr v existujı́cı́m softwaru a jejich následným využı́vánı́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́ch skupin lidı́, kteřı́ jsou médii
často označováni 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́nı́ softwaru tedy nezaručuje se 100% jistotou, že stroj nemůže být kompromitován. A v praxi je situace ještě o něco horšı́. Málokterý
prosinec 2003
administrátor provádı́ záplatovánı́ 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́ch 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́ch
modulů v jádře problém neodstranı́me, kernel může
být modifikován 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́na, je
instalace pozměněných programů, které obsahujı́ přı́slušný backdoor, popř. ještě výměna základnı́ch 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́nit? To může být obtı́žné. Jednı́m řešenı́m jsou bezpečnostnı́ patche jako LIDS či grsecurity,
které výrazně omezujı́ pravomoci spuštěných 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́ch 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́nı́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́n.
Nicméně 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́nı́ databázi upravit tak, aby obsahovala hodnoty jı́m změněných souborů. Tudı́ž je nutné nějakým způsobem
zajistit integritu databáze. Na částečné řešenı́ tohoto
problému se užı́vá asymetrické kryptografie; databáze
kontrolnı́ch součtů je digitálně podepsána. K úspěšnému podepsánı́ databáze je nutné heslo, kterým je
zašifrován klı́č, který se použı́vá při podepisovánı́ a
šifrovánı́ některých souborů. Stejným způsobem jsou
ochráněny i dalšı́ soubory – jako např. konfiguračnı́
soubory. Nicméně i tak je doporučováno zálohovat
databázi kontrolnı́ch 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ı́ce o licenčnı́ politice Tripwire – viz část Instalace Tripwire). V Tripwire se navı́c na účely ochrany databáze a konfiguračnı́ch
souborů nepoužı́vá jeden klı́č, ale dva – sı́t’ový klı́č a
lokálnı́ klı́č. Toto řešenı́ je použito z důvodů usnadněnı́ administrátorovy práce – pokud má Tripwire na
vı́ce strojı́ch na sı́ti, mohou použı́vat jen jeden sı́t’ový
klı́č. Ten se použı́vá např. na ochranu konfiguračnı́ho
souboru. Druhý klı́č, lokálnı́, se chránı́ např. lokálnı́
databázı́ kontrolnı́ch součtů.
Instalace Tripwire
Tripwire existuje ve dvou verzı́ch, open source a komerčnı́. Open source verze je volně ke staženı́ na adrese http://www.tripwire.org. K dispozici jsou balı́čky
pro RedHat a tgz balı́k obsahujı́cı́ snadno použitelný
instalátor. Eventuálně je zde možnost stáhnutı́ zdrojových 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ı́če
(při instalaci se několikrát zeptá na heslo pro sı́t’ový i
lokálnı́ klı́č), konfiguraci i zásady.
Konfigurace a
bezpečnostnı́
zásady
Soubory Tripwire najdeme standardně v adresáři
/etc/tripwire. Většina souborů v tomto adresáři
je přı́tomna ve dvou formách – 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́nı́ textových 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ı́če. Kromě nich v adresáři najdeme textové soubory (a samozřejmě jejich zašifrované verze) obsahujı́cı́ 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́ně podstatná je
snad pouze možnost nastavenı́ logovánı́ přes syslogd
(volba SYSLOGREPORTING). Vyčerpávajı́cı́ popis
konfiguračnı́ch 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́ře, jejichž integritu
chceme kontrolovat. Textovou verzi databáze bezpečnostnı́ch zásad můžeme zı́skat pomocı́ přı́kazu
twadmin --print-polfile.
Základnı́ syntaxe bezpečnostnı́ch zásad v tomto textovém souboru je následujı́cı́:
objekt -> příznaky;
Přitom objekt může být adresářem i souborem. Přı́znaky mohou být složeny ze skupiny znaků:
prosinec 2003
T
Tabulka znaků přı́znaků:
+
bude kontrolovat změnu daných vlastnostı́ objektu
-
nebude kontrolovat změnu daných vlastnostı́ objektu
a
čas poslednı́ho přı́stupu
b
počet alokovaných 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́nı́ 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́na na hodnotu oné zadané proměnné.
Hodnotu proměnných 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ı́ce 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̌iřadit zásadám nějaký identifikátor, který se posléze
objevı́ i v reportu. Tyto identifikátory je vhodné použı́vat zejména v přı́padě, že máme nadefinováno 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ı́cı́ změnu u programů
/usr/sbin/sshd, /usr/bin/ssh atd.)
emailto – tento atribut sloužı́ k specifikaci emailové
adresy, na kterou je poslán report, v přı́padě použitı́
volby --email-report při kontrole a zjištěné změny
některého z hlı́daných 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́ch
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́nı́
Tripwire v přı́padě, že je jako objekt zadán 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́ře a soubory v daném adresáři nemajı́ kontrolovat.
Standardnı́ hodnotou je −1, tedy monitorovánı́ všech
podadresářů 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ı́ch 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ı́ch součtů
prosinec 2003
Pro ovládánı́ 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́ře specifikované v zásadách 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ı́če, databázi kontrolnı́ch součtů, konfiguraci a databázi bezpečnostnı́ch 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́ch
souborů.
Po vytvořenı́ databáze kontrolnı́ch 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ı́ch zásad všechny sledované soubory a některé
údaje u nich. V přı́padě změny vypı́še varovánı́,
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́nı́
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ı́cı́ 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́ně 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 modifikován nebyl. Útočnı́k mohl např. vyměnit klı́če,
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́nı́ klı́čů a jejich následné použitı́ na podpis nějakého souboru (heslo ke
klı́č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ı́ch souborů (skrytých někde na pevném disku).
Tato technika boje proti Tripwire je z těch uvedených asi nejzákeřnějšı́, protože na rozdı́l od předešlých
technik proti nı́ nenı́ obrana vůbec jednoduchá – nepomůže ani zakázánı́ podpory modulů v jádru. Jediným
řešenı́m jsou bezpečnostnı́ záplaty jako grsecurity a
následné zakázánı́ 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́ch 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ı́če a databázi kontrolnı́ch 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́nı́).
Aktualizace
databáze
kontrolnı́ch součtů
prosinec 2003
Ke změnám hlı́daných souborů může též dojı́t oprávněně – přı́kladem budiž záplatovánı́ 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́nı́. Databázi můžeme aktualizovat pomocı́ přı́kazu tripwire -m u -r report. Jako report specifikujeme jméno souboru s reportem, který vygeneroval Tripwire při kontrole integrity souborů. Jméno
souboru je při kontrole vždy vypsáno 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
OMEZOVÁNÍ SÍŤOVÉHO PROVOZU
9/3.10.1 Úvod
9/3.10.2 Omezovánı́ provozu na úrovni
protokolu TCP/IP
únor 2005
únor 2005
9/3.10.1
ÚVOD
Omezovánı́ 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ı́cı́ se jako aplikačnı́ proxy server, dá řeš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ı́ch 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́nı́ protokolu UDP či ICMP můžeme s klidným svědomı́m zapomenout.
únor 2005
únor 2005
9/3.10.2
OMEZOVÁNÍ PROVOZU NA
ÚROVNI PROTOKOLU TCP/IP
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ı́cı́ 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́nor 2005
Této vlastnosti využijeme při našem omezovánı́ protokolu TCP. Donutı́me servery v Internetu k pomalejšı́mu odesı́lánı́ dat.
Je zřejmé, že je vhodné nejen regulovat pakety, které směřujı́ z Internetu ke klientům, ale také data od
klientů do Internetu.
Technika
omezovánı́
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́ch 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́ch skladovacı́ch mı́stnostı́ a trpaslı́k podle konkrétnı́ho algoritmu pro každou jednotlivou mı́stnost rozhoduje, jestli bude paket z mı́stnosti
odeslán do sı́t’ového rozhranı́, nebo zda bude zahozen
do propadliště dějin.
únor 2005
Zmı́ně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ı́něná skladovacı́ mı́stnost má
pevnou velikost (napřı́klad 20 paketů). Pokud je plná
a všechny pakety v nı́ čekajı́ na odeslánı́, 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́na a je jen na nı́, aby zpozorovala, že se jı́ pakety po
cestě ztrácejı́.
Popis ve výše uvedených dvou odstavcı́ch je možná
na prvnı́ pohled zmatený, nicméně 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ı́cı́ 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 ředitele, který má
připojenou IP telefonii a občas telefonuje přes Internet
Zadánı́
únor 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́n. 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́nı́ přı́slušných paketů. Zopakuji zde znovu pro přehlednost tabulku, ze které je
zřejmé, jak je který provoz paketů označkován.
únor 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
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
500kbit
268kbit
8:
únor 2005
9: tc filter add dev eth0 parent 1:2 protocol ip handle 20 fw flowid 1:10
12:
htb rate 102400kbit
300kbit
300kbit
300kbit
102400kbit
20:
24:
27: tc class add dev eth2 parent 1:0 classid 1:1 htb rate 102400kbit
102400kbit
212kbit
30:
únor 2005
Na obrázku k zařı́zenı́ eth0 vidı́me strukturu, kterou
jsme vytvořili přı́kazy na řádcı́ch 1 až 7.
Struktura pro odchozı́ provoz na zařı́zenı́ eth0
Provoz do
Internetu
O
Na řádku 1 smažeme přı́padně dřı́ve vytvořené struktury. Na řádku 2 vytvořı́me kořenovou disciplı́nu
(qdisc) 1:0 na zařı́zenı́ eth0 a budeme na nı́ použı́vat
algoritmus htb. Na tuto kořenovou disciplı́nu pověsı́me třı́du (class) 1:1 a řekneme, 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 řá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 ředitele,
rozčlenı́me třı́du 1:2 na dalšı́ dvě potřı́dy. To provedeme na řádcı́ch 5 a 6. Na řádku 6 vytvořı́me třı́du
pro počı́tač pana ředitele a řekneme, že jejı́ kapacita
únor 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 řá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 ředitele odesı́lat data rychlostı́ až 500 kbps, tedy většı́ rychlostı́ než 128 kbps.
Podobně na řádku 6 řı́káme, že pokud počı́tač pana
ředitele 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 ředitele a ostatnı́ počı́tače v našı́ firmě
sdı́lejı́ pásmo 500 kbps, přičemž v přı́padě potřeby má
ředitelů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ı́ch 4 a 5 jsme to řekli o pásmu pro
naši a sousednı́ firmu.
Na řádcı́ch 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 řádku 9 řı́ká, že pakety se značkou
20 odcházejı́cı́ zařı́zenı́m eth0 půjdou do třı́dy 1:10.
Na řá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́nor 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 řádcı́ch 13 až 22.
Struktura pro odchozı́ provoz na zařı́zenı́ eth1
Provoz do vnitřnı́
sı́tě našı́ firmy
O
Na řádku 14 opět nejprve vytvořı́me kořenovou disciplı́nu 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̌řovat provoz
z Internetu do počı́tačů v našı́ vnitřnı́ sı́ti kromě počı́tače pana ředitele. Pro provoz z Internetu na počı́tač
pana ředitele pak vytvořı́me třı́du 1:11 (řádek 18).
únor 2005
Rychlost třı́dy 1:11 jsme stanovili na 128 kbps s tı́m,
že pokud nenı́ využı́váno pásmo třı́dy 1:10, tak jej
využijeme a můžeme dosáhnout rychlosti až 300 kbps.
Na řá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 řá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
ředitele) a do třı́dy 1:11 pak zařadı́me ten provoz,
který je z Internetu určen na počı́tač pana ředitele.
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́nor 2005
Možná struktura pro odchozı́ provoz na zařı́zenı́ eth1
Struktura na sı́t’ovém zařı́zenı́ eth2 (a tedy pokrývajı́cı́ provoz do sı́tě sousednı́ firmy) vypadá již velmi
jednoduše.
Na řádcı́ch 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ı́ řá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ı́ch 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́ řešenı́ ma jeden zásadnı́ problém. Linuxové jádro nám v tomto konkrénı́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́nı́, které pakety zahodit
a které ještě ne, náročné.
Problémy
Řešenı́ je dvojı́. Zaprvé můžeme nedefinovat třı́dy
default (na zařı́zenı́ch 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́nor 2005
do sı́t’ového zařı́zenı́ bez jakéhokoliv omezenı́. Následujı́cı́ 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́ři do skriptu, odkud budete
omezovánı́ 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́ch to žádný smysl nemá. Co s tı́m,
uvidı́me dále.
únor 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 řeš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ı́nil, 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ı́nu qdisc. Dřı́ve jsem se zmiňoval pouze o disciplı́nách. Ted’ jen pro pořádek zmı́nı́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ı́nu. Přı́chozı́ (ingress) disciplı́nu na něj pověsit z důvodu vlastnostı́ linuxového
firewallu Netfilter nemůžeme, nicméně přı́chozı́ provoz lze omezovat na IMQ pomocı́ odchozı́ disciplı́ny.
IMQ
listopad 2005
O tom, jak zařı́zenı́ IMQ nainstalovat, se zmı́nı́m na
konci.
Změna zadánı́
V původnı́m zadánı́ ze začátku kapitoly 9.3.10.1 jsme
řekli, 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́nı́ 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́ch podmı́nek, 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ı́ řádky 3 až 7
htb
htb
5: tc class add dev eth0 parent 1:2 classid 1:10 htb
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̌ ředitele sousednı́ firmy)
a 1:10 (ostatnı́ počı́tače sousednı́ firmy) majı́ sice garantovanou pevnou rychlost, avšak mohou si od nadřazené 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:
htb
htb
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̌ ředitele 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́nı́) zapůjčena třı́dě 1:2. Tato zapůjčená kapacita
dále propadne do třı́dy 1:11, a ředitel 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́ch zařı́zenı́ch
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́ch 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ı́nu na zařı́zenı́ IMQ),
máme vyhráno.
listopad 2005
Přesměrovánı́ provozu (neboli jednotlivých 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 řešenı́. V odstavci, kde jsem
popisoval problémy onoho řešenı́, jsem zmı́nil, že jádro bude protestovat proti velkým rozdı́lům v kapacitách jednotlivých 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́ch
třı́d nebude nijak velký. Protože se nám do omezovánı́ 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́na rychlostmi použitých sı́t’ových prvků, což jsou v tomto přı́padě sı́t’ové
karty (100 Mbps). Kdybychom měli do omezovánı́
mı́chat i tento provoz, právě kapacita od poskytovatele 512 kbps je ve velkém nepoměru s rychlostı́ na
vnitřnı́ch sı́t’ových kartách a proti tomuto nepoměru
jádro protestuje!
Nadefinujeme tedy následujı́cı́ 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
htb
htb
htb
htb
rate
rate
rate
rate
512kbit
212kbit ceil 512kbit
17:
19: tc filter add dev imq0 parent 1:1 protocol ip handle 21 fw flowid 1:3
Skript pro omezovánı́ provozu je tak dı́ky použitı́ zařı́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
listopad 2005
33: iptables -t mangle -A POSTROUTING -s "${vnitrni_ip_0}"
-j ACCEPT
34: iptables -t mangle -A POSTROUTING -s "${vnitrni_ip_1}"
35: iptables -t mangle -A POSTROUTING -j IMQ --todev 0
-s "${net_nase_firma}"
-s
Na řádku 35 přesměruji všechny pakety do zařı́zenı́
imq0 kromě paketů, které jsem „akceptoval“ v předchozı́ch 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ı́ch 30 až 34. Ničemu to však nevadı́, a úč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ı́ny HTB). Původnı́ stránky 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ı́ce životaschopný se jevı́ projekt na stránce
http://www.linuximq.net/. Je nejčastěji aktualizovaný a použı́vá jej nejvı́ce správců (alespoň podle
emailů, které chodı́ do linuxových 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́ch distribucı́ch, 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́nkách 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́nkách 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́nkách projektu IMQ a také na stránkách iptables (http://www.netfilter.org/).
Po správné kompilaci jádra se po nabootovánı́ 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ı́ch zařı́zenı́ chceme použı́vat. Nám stačı́
jedno, defaultně se vytvářejı́ 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ı́n 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́ně 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́nı́ a nebo bez omezovánı́ 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́nkách projektu uvedena, protože autoři jsou velmi ochotni ke
spolupráci. 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
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
(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 <adresa>:<port>) tak, jako
se běžně používá pro testování klasické komunikace
příkaz telnet <adresa> <port>.
Linux podporuje poměrně široké možnosti, jak implementovat VPN, od protokolu CIPE (Crypto IP Encapsulation) vyvinutého na Linuxu přes různá zapouzdření PPP protokolu, např. do SSL (programem
stunnel) až po standard IPSec. Patrně nejméně bezpečným, zato však na nejrozšířenější klientské platformě nejsnáze podporovaným protokolem je PPTP
(Point-to-Point Tunneling Protocol). Jeho implementaci obsahuje server zvaný Poptop, je možné ho instalovat jak ze zdrojových kódů, tak z předpřipravených
balíčků (kromě rozšířených distribucí Fedora či Debian je přímo na domovské stránce projektu podporována distribuce OpenWrt pro bezdrátové routery).
Virtuální privátní
síť, PPTP
kvûten 2006
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

Bezpečná počítačová síť - People(dot)tuke(dot)sk

Transkript

Podobné dokumenty

Praktikum z operacnıch systému˚ Jméno: I. Strucné odpovedi 1

Arti zots

Tvůrcem už není jen Bůh

4 • 2014