Linux nabízí hromadu možností, jak zabezpečit data a přístup k nim. Může se jednat o komplexní řešení SELinuxu nebo i jednoduchých práv. Je tu ovšem ještě jedna stránka bezpečnosti. Když jeden uživatel zatíží stroj takovým způsobem, že on sám ani další uživatelé se již nepřihlásí, tak skončíme velmi podobně jako při výpadku datového úložiště. K čemu nám jsou data bez přístupu k nim?
Povíme si dnes o jedné vlastnosti autentizačního systému PAM. Pokud máte ve svém systému podporu PAMu zakompilovanou, můžete se podívat po souboru /etc/security/limits.conf. V něm můžeme nastavovat všechno, co se týče spuštěných procesů různými uživateli. Pokud to uděláme dobře, odměnou bude odolnost proti DDoS útokům, chybám konfiguraci a uživatelům.
Kde se omezování prostředků hodí
V praxi se pak setkáme se situacemi, kdy se někdo na běžící Apache pokouší DoS útok z několika stovek nebo i tisíců strojů. Pokud nenastavíme nějaký rozumný limit, vyčerpá nám Apache veškeré prostředky, které budeme nutně potřebovat na nápravu problému.
Další příklad může být spojen se špatně napsanou aplikací, která se jednou za čas rozmnoží o několik procesů. Za několik dní se mohou systémové prostředky vyčerpat, ani si toho nevšimneme, díky malé aplikaci např. pro kontrolu běhu serveru se na systém už nedostaneme a ostatní služby budou rády, když jednou za pár minut odpoví na požadavek.
Poslední příklad, kdy se omezování bude hodit, je sdílení serveru více uživateli. Možná znáte situace, kdy dáte přístup na některý ze svých strojů někomu jinému. I s perfektně nastavenými právy se může stát, že tento jeden uživatel začne konzumovat paměť, která je potřeba jinde. Nastavení správných limitů zabrání uživateli využít víc, než jsme ochotni mu dát.
Jak to funguje
Jak jsme si řekli, limity jsou součástí autentizačního systému PAM. Ten se nestará pouze o samotné přihlášení, ale také o parametry prostředí, a nebo dokáže chrootovat spouštěný proces. PAM je silný nástroj a limity jsou jen kapkou v moři jeho možností.
Konkrétní řádka, kde můžeme ovlivnit aplikování limitů, je v souboru /etc/pam.d/system-auth. Je to soubor, který se vkládá do dalších konfiguračních souborů. Umístění by mělo být ve většině distribucí stejné. Pokud zakomentujeme tento řádek:
session required pam_limits.so Session sekce se provádí po přihlášení a před odhlášením ze systému. Limity pro uživatele se tedy aplikují, hned jak bude přijato heslo. První program PAM je dnes široce podporován již řadu let, takže podporu najdete pomalu v každé distribuci. Vlivu PAMu podléhají i aplikace, které se spouští při bootování, takže nastavená pravidla budou mít vliv na nastartované služby.
Kdo chtěl víc, nedostane nic
Začneme tím, že si popíšeme, jak vypadá syntaxe v tomto souboru:
<doména> <typ> <omezení> <hodnota> Doménou je zde myšlen uživatel, skupina (ta se zapisuje jako @skupina) nebo tzv. wildcard, což je vždy jeden ze znaků * nebo %. Ten první je substitucí za všechny uživatele, ten druhý se používá ve spojení s volbou maxlogins, kdy se pravidlo uplatní na skupinu uživatelů. Syntax je stejná jako u @.
Do typu můžeme napsat jednu ze tří možností. První možnost je „-“, ta zakáže jakékoli omezování pro doménu. Dále máme k dispozici „soft“ a „hard“. Při přihlášení je uživateli nastaven soft limit. Ten se nesmí překročit, ale je možné ho změnit přes program ulimit. Nastavením „hard“ limitu, se uživatel odřízne od dalších systémových prostředků bez výjimky.
Omezení je to, co nás zajímá nejvíce. Sem napíšeme již parametr systému, na který chceme danému uživateli dát limit. S tím souvisí i hodnota, která je již odvislá od zvoleného omezení. Např. omezení a počet procesů má v hodnotě pouze číslo s počtem, u omezení maximální doby používání CPU nastavujeme počet minut. Detailní informace o nejdůležitějších omezení jsou uvedeny v tabulce níže.
| core | maximální velikost paměti, kterou můžeme dumpnout na disk, používá se u ladění programů a normální uživatel zde může mít nulu [kB]| |
|---|---|
| fsize | maximální velikost souboru [kB] |
| nofile | maximální počet otevřených souborů |
| cpu | maximální využitelný procesorový čas [minuty] |
| rss | maximální velikost obsazené fyzické paměti [kB] |
| nproc | maximální počet procesů |
| as | maximální obsazená paměť [kB] |
| maxlogins | maximální počet přihlášení v jednu chvíli |
| priority | priorita procesů [-20,19] |
| nice | maximální možná priorita [-20,19] |
Než budeme pokračovat, zmíním, že je dobré a žádoucí si vytvořenou konfiguraci pečlivě zkontrolovat. Jeden překlep nás může oddělit od systému.
Je tedy čas vyzkoušet první příklad. Zvolíme si jednoduché omezení maximálního počtu procesů na uživatele mylimit:
mylimit hard nproc 10 Když si vyzkoušíte změnit číslo 10 za jiné, třeba menší číslo, a pak se třeba přes SSH nebo su přihlásíte, zjistíte, že po spuštění více jak nastaveného limitu, dostane chybovou hlášku podobnou téhle:
bash: fork: Prostředek je dočasně nepřístupný V UNIXových operačních systémech je bez funkce fork() pomalu nic nespustí, a když ji trochu přiškrtíme, získáme velmi spolehlivý prostředek, jak zabránit následkům útoku na náš stroj.
Další příklad už bude více užitečný. Nastavíme uživateli mylimit omezení na ty nejdůležitější hodnoty, které mohou ohrozit náš systém.
mylimit hard core 0
mylimit hard nproc 30
mylimit hard as 131072
mylimit hard nice 5 Našemu uživateli mylimit, vypneme možnost dumpovat paměť, nastavíme mu maximální počet procesů na třicet a omezíme celkovou paměť na 128 MB RAM. Všechny procesy spuštěné uživatelem budou mít hodnotu nice na 5.
Závěr
Ač se jedná o jednoduché nastavení, je často přehlíženo. Přitom může zachránit nejednu situaci. Osobně se mi již povedlo napsat skript, který se ve velmi krátkém čase naforkoval na 1000 procesů a shodil mi celý desktop. Na serveru se mi zase stalo, že skript pro načítání RSS obsahu se také rozrostl na několik stovek procesů a zablokoval přístup na server i s jeho službami. Přitom šlo o malý překlep, který se projevil až po několika dnech běhu. To jsou přesně ty situace, kterým můžeme jednoduše zabránit. Limity nás mají chránit spíš před našimi vlastními chybami než chybami ostatních. Když nám web server napadne útočník DDoS útokem, tak sice nám nespadne server, ale stejně musíme samotnou situaci nějak vyřešit.
