| Linuxové noviny | 11/99 | ||
|
| |||
ÚvodZabezpečení serveru před průnikem je jednou z prvních věcí, které je třeba udělat, chystáme-li se provozovat nějaké veřejně dostupné služby. To samozřejmě platí i v prostředí interních sítí, neboť podle statistik k 80% neautorizovaných průniků dochází od legitimních uživatelů sítě. V tomto prvním díle se budeme zabývat metodami zjišťování služeb běžících na serveru, neboť sbírání informací je obvykle prvním krokem, který útočník podnikne.
Port scan - detekce služeb běžících na vašem serveru zjištěním otevřených TCP/UDP portůScanování portů patří mezi základní metody zjišťování informací o vašem serveru. Útočník ho provádí proto, aby zjistil služby běžící na serveru, což mu umožní udělat si představu o snadnosti nebo nesnadnosti průniku (a ev. také názor na admina). Vzhledem k tomu, že tato znalost může průnik značně usnadnit, je vhodné vědět, jakým způsobem port scan funguje, a jak se proti němu lze bránit. Popišme si základní druhy scanů a možnosti jejich detekce.
connect() scanJe nejjednodušším a také nejstarším druhem scanu. Scanner se jednoduše opakovaným voláním funkce connect() pokouší vytvořit spojení na všechny (ev. pouze zadané) porty oběti. Pokud se pokus podaří, je port označen za otevřený. Vzhledem k tomu, že z hlediska detekce má mnoho společného s následujícím druhem, popíšeme možnosti detekce později. Tento druh scanu se útočník pokusí použít až jako poslední možnost, neboť programy, na které se spojení podaří, obyčejně tuto událost zaznamenají do logu, a pokud ho admin kontroluje, obyčejně ho (zejména na málo vytížených serverech) může zjistit na první pohled.
SYN stealth scanJe obdobou předchozího, liší se ale v tom, že nenavazuje plné spojení. Podle příslušného RFC793 probíhá navazování TCP spojení následujícím způsobem: žadatel o spojení zašle na server paket s nastaveným flagem SYN (žádost o synchronizaci sekvenčního čísla) a server této žádosti vyhoví zasláním paketu s nastavenými flagy SYN a ACK, což žadatel zpětně potvrdí ACK paketem a tím je spojení navázáno. SYN scan namísto posledního potvrzujícího paketu zašle RST, čímž žádost okamžitě zruší a ke spojení nedojde. To je výhodné, neboť se tím vyhne záznamu v logu. Pokud se tímto způsobem pokusí komunikovat se zavřeným portem, místo SYN+ACK paketu dostane od serveru RST odpověď. Tímto způsobem dokáže jednoznačně odlišit otevřené porty od zavřených.Problém s detekcí tohoto typu scanu je, jak odlišit pakety jdoucí od scanneru od paketů, kterými legitimní uživatelé navazují se serverem spojení. Způsobů je několik, můžeme použít některý z následujících algoritmů, případně vymyslet nějaký jiný: Algoritmus 1: pokud z jedné adresy ve specifikovaném čase přijde pokus o spojení na více než určitý počet portů, jde pravděpodobně o scan. Algoritmus 2: pokud z jedné adresy přicházejí SYN pakety ve stejných časových intervalech (s rozumnou odchylkou), a navíc jdoucí na různé porty, půjde také pravděpodobně scan. Algoritmus 3: některé porty (ty, na kterých buď nějaké služby provozujeme, nebo se na nich některé často provozované vyskytují) označíme za hlídané, a pokud na určité množství z nich přijdou SYN pakety ve specifikovaném časovém intervalu, zaznamenáme scan.
ProtiakcePokud zaznamenáme scan z nějaké adresy, můžeme už v jeho průběhu reagovat tak, že na SYN pakety jdoucí na otevřené porty budeme jako odpověď posílat RST pakety, čímž útočníkovi efektivně znemožníme detekci. Tento způsob chování by měl být zachován ještě po nějakou dobu dobu po skončení scanu. Pokud totiž útočníkův scanner zareaguje inteligentně a sníží frekvenci SYN paketů, tak, že se dostane mimo námi definované meze, stále nebude nic detekovat.
ProblémyVšechny tři zde uvedené algoritmy vyžadují pečlivé nastavení. Na méně zatížených serverech (řekněme do deseti spojení za sekundu) si můžeme dovolit poměrně volné nastavení, ovšem při vysoké zátěži si spolehlivé nastavení může vyžádat větší experimentování (hlavně tam, kde se poskytuje větší množství služeb a přistupuje se tudíž na větší množství portů). Zejména v případě, kdy proti útočníkovi podnikáme výše uvedené protiakce, je třeba se vyhnout falešným detekcím, protože by byly pro legitimní uživatele značně frustrující. I v případě pečlivého vyvážení se nelze vyhnout tomu, že některé pečlivě prováděné scany nebudeme schopni detekovat, např. pokud se útočník zaměří pouze na několik nejpoužívanějších portů a bude posílat jeden paket za hodinu, nebo třeba den. Navíc u všech záznamů v logu je třeba mít na paměti, že zdrojová adresa může být padělaná v zásadě dvěma způsoby: útočník sice scanuje ze své IP adresy, ale zároveň posílá stejné pakety s padělanými adresami z většího množství souboru adres (a my nejsme schopni odlišit jeho od falešných), nebo ke scanu používá jiný počítač, do kterého se již dostal.
FIN, Xmas tree a NULL scanTyto tři typy scanů využívají chybné implementace TCP protokolu v Linuxu (a dalších operačních systémech). Nejprve se zmíníme, v čem se liší jednotlivé druhy paketů, které se používají pro průzkum. FIN scan používá pakety s nastaveným FIN flagem (normálně žádost o zrušení spojení), Xmas tree nastavuje kromě toho flagy URG a PUSH, a NULL scan ponechává všechny flagy nenastavené. Podle příslušné specifikace je OS povinen odpovědět paketem RST na všechny pakety, které nejsou součástí některého probíhajícího spojení (s výjimkou RST paketů samozřejmě). Bohužel Linux a některé další systémy tyto pakety jdoucí na otevřené porty pouze zlikviduje bez jakékoliv odpovědi, čímž umožňuje snadno detekovat běžící služby.Poznámka: pokud se podíváte do kódu, který to má na svědomí (net/ipv4/tcp_ipv4.c u 2.2 a 2.3), zjistíte, že implementátoři strukturou kódu následovali strukturu příslušného RFC, a tento test, který je zmíněn na zcela jiném místě, vynechali. Jiné systémy (Windows, OpenBSD) tuto chybu neobsahují. Detekce je v tomto případě jednoduchá. Pokud zaznamenáme některý z výše uvedených paketů a nedokážeme ho přiřadit žádnému soketu, jednoduše ho zlikvidujeme a zašleme RST odpověď. Falešné detekce jsou možné pouze v případě zbloudilých paketů, kterých se pravděpodobně nebude vyskytovat nijak významné množství. Patch na jádro, který tento problém řeší systémově, je k dispozici. Dále je třeba poznamenat, že pokud zaznamenáme ve stejný okamžik větší množství scanů z různých adres, měli bychom logovat pouze jeden scan, neboť pravděpodobně všechny pakety budou mít stejného původce a pouze jedna adresa nebude padělaná.
Další typy TCP scanůTěžko vymyslet něco dalšího. Je zřejmé, že i další možné typy scanů budou založené na chybách nebo nekonzistentnosti implementace TCP protokolu. Uriel Maimon uvádí v časopise Phrack č. 49, soubor 15, zajímavý druh scanu, proti kterému jsou novější jádra imunní. Program zveřejněný v tomto článku posílá na každý port dva ACK pakety s různými hodnotami sekvenčních čísel a window a porovnává došlé RST pakety. Pakety jdoucí z otevřených portů mohou od svých původců převzít hodnotu window, případně mohou mít nižší hodnotu ttl, než pakety jdoucí ze zavřených portů. Program jsem nezkoušel se staršími jádry 2.0, ale při pohledu do zdrojových textů je zřejmé, že právě tato část kódu je zde řešena odlišně než v 2.2 a 2.3, takže na 2.0 a ev. starších by mohl tento druh scanu fungovat. Teoreticky lze další varianty odhalit např. pomocí nějakého generátoru paketů a programu tcpdump. Způsob detekce je shodný jako u FIN & spol. scanů.
UDP scanyScanováním UDP portů často seriózní hackeři opovrhují, neboť postrádá komplexnost TCP scanů, to ovšem neznamená, že by ho nepoužívali. Mnoho často používaných programů stavěných nad UDP se v nedávných dobách stávalo vděčným terčem útoků, zmiňme např. bind. Vzhledem k tomu, že UDP protokol neudržuje žádné informace o spojení, a podle RFC1122 není ani povinen zasílat chybové zprávy, není UDP scanování obecně nejlehčí. Linux sice dodržuje doporučení a chybové zprávy zasílá, přesto jsou zde další komplikace. Popišme princip funkce.Pokud zašleme nějaký UDP paket s nesmyslným nebo prázdným obsahem na otevřený port, příjemce mu pravděpodobně neporozumí, zlikviduje ho, a nepošle zpět žádnou odpověď (ev. odpoví UDP paketem). Pokud zašleme paket na zavřený port, systém by měl (ovšem nemusí, ale Linux to dělá) zaslat zpět ICMP zprávu PORT_UNREACHABLE, tj. port je nedostupný. Linux navíc limituje množství těchto odpovědí (jak je doporučeno v RFC1812) na 80 za 4 sekundy, a pokud je tento limit překročen, ještě dále zpomalí. Je zřejmé, že detekovat běžící UDP služby pod Linuxem tedy lze, a detekce scanu je v principu shodná s detekcí TCP SYN scanu, pouze musíme testovat všechny pakety a vzít v úvahu, že kvůli daným omezením na frekvenci odpovědí bude scanner posílat jednotlivé pakety menší frekvencí. To se odrazí v prahových hodnotách, které nastavujeme pro všechny tři uvedené algoritmy. Další možné způsoby zjišťování běžících služeb:
Možné problémy spojené s detekcíJe třeba si uvědomit, že v případě port scanu nejde o aktivní útok na náš server (ev. síť), a tomu přizpůsobit reakci. Předně většina detekovaných scanů nebude zaměřena přímo proti vaší síti, půjde spíše o masově prováděné scany podsítě nebo domény, do které patříte. Hacker si pak z výsledného seznamu bude vybírat ty servery, které budou vypadat zranitelně, takže pokud dokážete scanu zabránit, budete mimo jeho pozornost (je ovšem třeba uvést, že pro ty schopnější můžete v tomto případě znamenat výzvu). Dále je třeba zvážit případné protiakce. Odepření přístupu z detekované adresy bude v mnoha případech znamenat, že ho odepřete úplně někomu jinému, protože hacker neprovádí scan ze svého počítače. Dále v případě, že je skryt za maškarádou nebo NAT, odepřete přístup i mnoha dalším nevinným uživatelům. Protože nejde vlastně o útok, měli byste se omezit pouze na detekci a zabránění vlastnímu scanu.
ScanneryPokud chcete vědět, co všechno je možné zjistit o vašem serveru po síti, zde jsou odkazy na nejlepší scannery dostupné pro Linux:http://www.insecure.org/nmap/ - nmap - nejznámější port scanner od Fyodora. Kromě všech uvedených typů scanů provádí také zjišťování typu OS průzkumem jeho TCP stacku a zjišťuje uživatele, pod kterými běží jednotlivé služby (pokud používáte identd). Dále dokáže scan maskovat v souboru zadaných adres a nebo použít jako proxy cizí ftp server (což je celkem dlouho známá vlastnost ftp serverů). Ideální nástroj, pokud chcete zkusit pouze čistý portscan. http://www.arc.com/se.html - SARA - přímý potomek slavného SATANA od Wietse Venemy a Dana Farmera. V port scanu nijak nevyniká, zato vám dokáže poskytnou o vašem systému spoustu informací, které byste raději neviděli. Má celou databázi možných problémů a všechny zkouší na vašem serveru najít. Výhodou je i snadné ovládání přes browser. Doporučuji instalovat spolu s nmapem a sambou, které dokáže při sbírání informací použít. http://www.nessus.org - nessus je ze stejného soudku jako SARA, disponuje velkým množstvím pluginů a dokáže poskytnout velké množství informací o zabezpečení vašeho systému. http://www.phrack.com - ve zmíněném 49 čísle vyšel scanner, který implementuje zmíněnou metodu ACK scanování.
Scan detektoryscan_detect - můj vlastní příspěvek k detekci scanů. Výhodou z hlediska detekčních schopností je, že běží přímo v jádře (jako modul nebo součást jádra), takže má přístup ke všem paketům a navíc je schopen snadno na ně reagovat. Mimo jiné řeší i problém s FIN & spol. scany. Zatím je dostupný pouze pro jádra 2.3, verze pro 2.2 se chystá po odladění. Veřejně bude dostupný na mých připravovaných stránkách o počítačové bezpečnosti pod Linuxem (adresa zatím neznámá). Implementuje všechny zmíněné metody detekce.http://www.openwall.com - scanlogd - celkem jednoduchý detektor z projektu Openwall. I když se ho rozhodnete nepoužívat, doporučuji navštívit jejich stránky, najdete tam zajímavý bezpečnostní patch na jádra 2.0 a 2.2 (mimo jiné non-executable stack), známý lamač unixových hesel John The Ripper a bezpečný POP3 server. http://www.psionic.com - portsentry - solidní detektor z projektu Abacus. Při neadekvátní konfiguraci může ovšem způsobit mnoho problémů, od odepření přístupu (viz výše) až po náchylnost k DoS útokům přímo proti detektoru via přeplnění logů. Doporučuji zachovat zdrženlivost při konfigurování těchto schopností. Samozřejmě existují další, ty jsou ovšem součástí komplexnějších balíků. Budeme se jimi zabývat později.
Sbírání podrobnějších informacíMezi další informace užitečné pro průnik patří znalost konkrétního typu služeb, které na serveru běží, tj. programů a jejich verzí, dále verze systému a jeho příslušnost k určité distribuci. Užitečnost první informace je zřejmá: pokud útočník zjistí, že na serveru běží např. bind verze 4.9.5-P1, snadno na internetu najde exploit přesně na tuto verzi (zde klasický buffer overflow problém), pokud žádný nenajde, může se pustit do studia zdrojových textů programu, a ev. objevit nějakou novou chybu. Druhá informace může být také užitečná, jednotlivé distribuce obsahují různé defaultní účty, služby a nastavení, které může útočník přímo vyzkoušet. Podívejme se na tyto metody sbírání informací a způsoby, jak jim zabránit.
Sbírání bannerůVětšina interaktivních služeb, jako jsou telnet nebo ftp, se před nebo po přihlášení prezentuje sdělením názvu programu, verze a verze systému, což jsou po útočníka cenné údaje. I další služby, které nekomunikují s uživatelem přímo, mohou ve svých odpovědích některé z těchto informací obsahovat. Navíc mnoho administrátorů trpí přílišnou hrdostí na svůj systém, a i když jejich stránky nemají s Linuxem nic společného, můžete na nich najít loga jako Linux (Redhat, Apache...) inside. Zlomyslný hacker je může snadno přesvědčit, že jejich systém není tak skvělý, jak si mysleli. Je zřejmé, že ve správně zabezpečeném systému je třeba nesdělovat alespoň informace o jednotlivých službách a jejich verzích (navíc je vhodné používat takové programy, které byly programovány s ohledem na bezpečnost, skoro ke všemu existuje vhodná alternativa).U některých programů lze tyto úvodní informace přímo specifikovat. Měly by obsahovat neutrální informace jako "Vítejte na ftp serveru firmy Security & spol., pokud chcete ...". U dalších bude nutné zasáhnout do zdrojových textů programu, pokud však vyžadujete vysoký stupeň bezpečnosti, měli byste takové změny udělat, nebo najít alternativní program, kde lze tyto věci konfigurovat.
Použití informačních služebMnoho služeb běžících na serveru je přímo určeno k získávání těchto informací. Mezi ně patří finger (umožňuje získávat informace o jménech účtů, domácích adresářích, shellech, aktivních uživatelích atd.), portmapper (umožňuje získat porty, na kterých běží RPC služby, a čísla programů, které obsluhují), NIS (je obecně považován za špatně zabezpečenou službu s nízkou bezpečností a mnoha problémy, kterou lze nahradit jinými), některé r-služby, chybně zkonfigurované SNMP, vděčným zdrojem informací může být i DNS.U jediné služby, kterou poskytnout musíte - DNS - byste měli poskytovat stejně neutrální informace, jako ve výše uvedeném případě. U ostatních služeb je třeba zvážit jejich použití a v případě nutnosti použít upravené verze, které budou poskytovat skutečně pouze ty informace, které poskytnout chcete. Služby jako NIS lze nahradit jinými, např LDAP.
Odposlech síťového provozuTato metoda patří mezi nejnebezpečnější, neboť většina služeb komunikuje nešifrovaně a bezstarostně posílá po síti např. nešifrovaná hesla. Některé služby sice hesla šifrují, ale použitý algoritmus buďto používá slabou šifru, anebo odchycená hesla mohou být podrobena slovníkovému útoku, nebo útoku hrubou silou. Má-li hacker možnost instalovat sniffer do místa, přes které jde velká část vašeho externího síťového provozu, bude mít pravděpodobně jednoduchou práci, a může vynechat ostatní metody. Pokud uživatelé používají na veřejných internetových serverech stejná hesla, jako v interní síti (free i komerční služby), což je běžná situace, může během relativně krátké doby posbírat dostatečné množství párů jméno/heslo, včetně administrátorských.Obrana není jednoduchá. Tam, kde to jde, byste měli používat šifrování s kvalitními algoritmy, např. ssh místo telnetu, šifrovat poštu, která obsahuje citlivé informace. Měli byste mít kvalitní bezpečnostní politiku, která bude přesně definovat způsob zacházení s hesly s ohledem na jejich možný odposlech, a použít některý ze systémů pro jednorázová hesla atd. Pokud používáte internet k propojení dvou privátních sítí, je jednoznačně nutné šifrovat kompletní provoz. I když je pro Linux dostupná technologie PPTP, měli byste použít IPSec, neboť u PPTP bylo popsáno několik způsobů útokú (zejména ve spolupráci s NT). Proti všem používaným heslům byste měli pouštět program John The Ripper (nebo jiný lamač hesel), hesla, která dokáže rozšifrovat před jejich expirací, jsou špatná hesla.
Sociální inženýrstvíZmíníme jen na okraj, neboť se mu lze těžko vyhnout technickými prostředky. Sociální inženýrství je víceméně umění vydávat se za někoho jiného s cílem získat požadované informace. Zřejmě jedinou účinnou metodou je striktní bezpečnostní politika, která bude definovat, jaké informace je kdo komu oprávněn sdělovat. Hesla patří mezi informace, které by měli znát pouze uživatelé sami, přístup k nim nemá ani administrátor. Ten, kdo je zodpovědný za dodržování této politiky, může ověřovat chování uživatelů právě metodami sociálního inženýrství, je dosti pravděpodobné, že uživatel, který heslo prozradí, to po takovéto lekci podruhé neudělá.
Metody, které můžete použít proti vlastním systémůmNejjednodušší a z hlediska efektivnosti nejhorší je telnet na každý otevřený port. Takto můžete posbírat bannery od interaktivních služeb stavěných na TCP protokolu a komunikujících textově. Patří sem např. telnet, SMTP, POP3, IMAP a HTTP. Efektivnější metodou může být použití programu netcat (standardně v některých Linuxových distribucích), kde můžete sbírání automatizovat pomocí skriptu. Také některé výše uvedené scannery toto dělají automaticky. Pokud chcete vědět, co se skrývá v netextových a UDP paketech, můžete použít některý ze snifferů, které používají hackeři, nebo standardní tcpdump.
ZávěrJe jednoduchý. Měli byste se starat o to, co vše může o vašem serveru kdokoliv zjistit, a pokud možno tomu zabránit a pokusy detekovat. Velmi užitečné je použít alespoň první dva scannery proti vlastním systémům a udělat si tak obrázek o jejich zabezpečení. Pokud hrdě sdělujete, že na vašem serveru kromě httpd běží také lpd, identd, finger, rpc služby, nebo dokonce linuxconf, pouze proto, že se to tak defaultně nainstalovalo, hacker si snadno udělá obrázek o vašich administrátorských schopnostech a zabezpečení serveru.
PříštěBezpečnost jednotlivých služeb, alternativy k běžně používaným programům.
|
|||