Správa linuxového serveru: Bezpečnost služeb
U jednotlivých služeb je především třeba si projít dokumentaci a nastavit je co nejbezpečněji. Nemusí být od věci pokusit se jim omezit přístup jen tam, kam opravdu potřebují. Za tímto účelem je používán nástroj (resp. systémové volání) chroot, kdy se pro službu změní kořenový adresář za nějaký adresář v hierarchii systému (např. adresář s daty). To znamená, pokud konfigurujete webový server s chrootem, pak pro běžící webový server nebude kořenový adresář systémový /, ale třeba /var/www. I kdyby útočník kompromitoval webový server a získal nad ním kontrolu, dostane se pouze k datům ve /var/www, nikoliv pak ke zbytku systému. Konfigurace chrootu nicméně bývá obtížná, zejména tam, kde má aplikace více komponent (např. Apache a PHP), protože do chrootu se pak musí umístit i příslušné binárky, knihovny a v některých případech i speciální zařízení (např. /dev/null apod.). A všechny tyto komponenty je pak samozřejmě třeba pravidelně aktualizovat. Navíc má chroot řadu reálných či potenciálních bezpečnostních problémů. Předně, proces běžící s právy roota se z chrootu může dostat a získat přístup k celému systému (to řeší např. projekt grsecurity, ale ten není oficiální součástí jádra).
Jiné možnosti izolace služeb představuje virtualizace - dnes není až takový problém izolovat služby do několika virtuálních strojů, které běží na jednom fyzickém serveru. Tato forma izolace sice zkomplikuje správu a údržbu takového řešení, ale zase zajistí, že případný útočník, který získá oprávnění roota, kompromituje virtuální server, na kterém běží třeba jen webový server, ale už ne databáze. Nebo, ještě lépe, útočník se probourá na virtuální server, kde běží pouze proxy, která zajišťuje předávání požadavků některému z dalších virtuálních serverů. Dlužno dodat, že i v rámci virtualizace může existovat nějaká zranitelnost, která může za jistých okolností útočníkovi umožnit získat přístup k hypervizoru, tedy mateřskému systému, který virtualizaci řídí a má přístup ke všem virtuálním strojům, i když ta šance je podstatně nižší.
Pokud není třeba, aby daná služba poslouchala na síti (např. databáze), pak ji nastavte tak, aby naslouchala jen na místní smyčce (127.0.0.1). Někdy se stane, že služba otevírá kromě standardních portů i nějaký další, který třeba slouží pro synchronizaci v clusteru nebo pro správu dané služby, a vy nemůžete nastavit, aby v případě tohoto portu naslouchala jen na místní smyčce. V takovém případě můžete využít firewallu a zablokovat přístup k danému portu (tedy pokud se port při každém spuštění nemění, s čímž už jsem se také setkal - pak pomůže nastavit u firewallu výchozí politiku řetězce INPUT na DROP a naopak jen povolit, co je třeba - toto je ostatně z hlediska stavění firewallu vhodná strategie).
Vůči síťovým útokům vám mohou pomoci nástroje jako fail2ban (či denyhosts v případě SSH). Ty mohou zablokovat útočníka, pokud začne páchat brute force útok s různými jmény a hesly ve snaze získat někam přístup. Něco podobného je s jistými omezeními možné vytvořit i na úrovni firewallu. V souvislosti s tím připomínám Praktické rady pro zabezpečení (nejen) SSH. V některých případech lze použít aplikační proxy, ve které můžete precizněji filtrovat typy požadavků na samotnou aplikaci (pokud to jde, je lepší to dělat spíše na úrovni dané služby). Extrémnějším řešením může být skrývání služeb prostřednictvím port knockingu, ale to lze uplatnit spíše u služeb jako SSH, kde není třeba, aby byla daná služba viditelná pro veřejnost.
V neposlední řadě může pomoci i výběr samotných aplikací - některé aplikace mají nepříjemnou historii mnoha bezpečnostních problémů, zatímco jiné byly postaveny s ohledem na bezpečnost, a bezpečnostní problémy u nich nejsou hlášeny tak často. Ze stejných důvodů bývá dobré volit zralé služby, které vyvíjí aktivní komunita, spíše než experimentální služby v rané vývojové fázi, které vyvíjí třeba jediný člověk.
Existuje řada oficiálních či méně oficiálních bezpečnostních patchů, které si kladou za cíl zjemnit systém oprávnění tak, aby ani služba běžící s právy roota v případě kompromitace neumožnila postup útočníka do zbytku systému. Zde je nejvíce známý v jádře obsažený SELinux, který je ovšem natolik komplexní, že se ho řada správců štítí, popřípadě ho rovnou vypínají, pokud jej distribuce ve výchozím stavu zapíná. Konkurencí pro SELinux je AppArmor, který je jednodušší, zejména pak na tvorbu nových pravidel (AppArmor to řeší tak, že aplikaci sleduje, zjišťuje, kam přistupuje, a podle toho sám tvoří pravidla přístupu). Dalším zajímavým bezpečnostním patchem je grsecurity, který mj. řeší i bezpečnost chrootu. Tyto mechanismy umožňují zvýšit bezpečnost provozu služeb, ale cenou za jejich použití je nutnost jim dobře porozumět. Jejich nevýhodou je, že špatně nastavená pravidla mohou vést k nefunkčnosti (v lepším případě), nebo k zvláštnímu až takřka "nevysvětlitelnému" chování jednotlivých služeb (v horším případě). Např. SELinux závisí na značkování souborů, takže když jsem jednou přenášel soubory z /var/lib/mysqlpři přesunu dat z jednoho serveru na druhý, přepsal jsem označkované soubory novými, a pak jsem dlouho řešil, proč MySQL tvrdí, že nemá oprávnění přistupovat do tohoto adresáře, když všechna unixová práva jsou nastavena správně. Přirozeně, SELinux umožňuje provádět přeznačkování souborového systému, ale o tom vy musíte vědět a musí vás to napadnout.
Pokud provozujete třeba domácí server, nebo naopak server v podnikové síti, pak se vás týká nejenom zabezpečení serveru, ale také sítě, ve které se server nachází, a to pokud možno tak, aby případná kompromitace serveru neohrozila jiné počítače v síti. S tím vám může pomoci samotná síťová architektura, respektive tzv. demilitarizovaná zóna. To je koncept, kde figuruje router/firewall se třemi síťovými rozhraními - k jednomu je připojen Internet, ke druhému místní síť a ke třetímu samotný server. Firewall pak řídí přístup tak, aby server mohl přistupovat na Internet (a Internet naopak k němu), ale aby nemohl přistupovat do místní sítě, zatímco místní síť k serveru přistupovat může (viz stavový firewall). Toto řešení je podrobně popsáno třeba v tomto článku. Další mechanismy pro ochranu sítě zahrnují dříve zmíněné IDS, které mohou síť sledovat a upozornit na případné útoky.
Možností pro zvýšení bezpečnosti je mnoho. Já jsem nicméně zastáncem teorie, že příliš mnoho bezpečnostních opatření může ve výsledku buď narušit funkcionalitu či dostupnost, nebo vést paradoxně ke snížení bezpečnosti. Typický příklad snížení bezpečnosti je agresivní politika hesel, která u uživatelů vede k tomu, že si heslo napíší na papírek a nalepí na monitor. Jinou možností může být skutečnost, že každá další služba, kterou na server nasadíte, byť je určena k zajištění bezpečnosti, je místem, kde se může objevit zranitelnost. Pokud tato služba naslouchá přímo na síti nebo monitoruje jakýkoliv uživatelský vstup (viz parsery logů v článku o zabezpečení SSH), je to potenciální problémové místo. Řada aktivních bezpečnostních opatření pak může vést k zablokování přístupu nebo omezení dostupnosti služby. Stejně tak vede příliš mnoho bezpečnostních opatření k tomu, že je lidé (nebo hůř - samotní správci) začnou obcházet či ignorovat a dané bezpečnostní opatření pak ztratí účinnost. Proto je třeba navrhovat bezpečnost rozumně.