Ukládání hesel a (ne)bezpečnost protokolů pro přenos souborů
Snad všechny nejpoužívanější FTP klientské programy umožňují svým uživatelům ukládat hesla a od chvíle, kdy tuto funkci začaly nabízet, je rovněž známo, že je velice snadné takto uložená hesla zpětně přečíst. Vývojáři na toto dříve nebo později zareagovali implementací šifrování uložených hesel s použitím tzv. master hesla, ale kupodivu nejrozšířenější a nejpoužívanější FTP klient tuto funkci zavedl až po velkém nátlaku v loňském roce jen v beta verzi svého klienta, když se začaly šířit viry, které z něj hesla masově vykrádaly a zneužívaly.
Často je v souvislosti s tím zmiňováno, že protokol FTP je velmi starý, má řadu nedostatků a ačkoliv existují moderní, prověřené a bezpečné protokoly pro přenos souborů, je FTP stále nejpoužívanějším způsobem přenosu souborů minimálně na poli klasického web hostingu tedy pro správu webových stránek. V tomto případě ale vůbec nejde o samotný protokol FTP, neboť stejným způsobem by mohly být vykrádány hesla k šifrovaným FTPS, SFTP resp. SCP účtům.
Poznámka: Není bez zajímavosti, že v poslední době zaznamenáváme, jak jsou obdobným způsobem vykrádána uživatelům hesla na SMTP s autorizací, aby přes ně mohl být následně masově rozesílán spam, tedy problém se netýká jen protokolů pro přenos souborů.
Použití jiného protokolu a šifrování přenosu dat proto v tomto případě nepomůže, neboť bezpečnost zde závisí především na pohodlnosti uživatelů a kvalitní implementaci klientského programu, kde by velmi pomohlo, pokud by se šifrování používalo jako implicitní nastavení a uživatel byl vybídnut k zadání master hesla již během instalace nebo při prvním pokusu o uložení libovolného hesla. Ani jedno z toho ale nemůže poskytovatel služby v dostatečné míře ovlivnit a tak musí hledat jiné cesty, jak zákazníkům zabezpečit jejich účty.
Vykrádání a zneužívání uživatelských hesel, které masově probíhá od loňského roku, se dotklo každého webhostera. Ti lepší implementovali možnost zamykání FTP účtů nebo omezování přístupu na vydefinované IP adresy, řada ostatních věc jednoduše neřešila, resp. jen sepsala FAQ a zákazníky ponechali v pozici, že chyba je na jejich straně, tedy si ji musí vyřešit svépomocí.
Jak jsme k řešení přistoupili v ACTIVE 24
Nejprve se případy zneužitých FTP účtů objevovaly velmi sporadicky a řešili jsme je po objevení ručně změnou hesla, odstraněním škodlivého obsahu nebo obnovou celého webu ze zálohy z času před napadením a následnou komunikací se zákazníkem, kde mu bylo doporučeno, jak dále postupovat. Zároveň jsme spustili dva mechanismy automatické kontroly všech námi provozovaných webů na škodlivý obsah, abychom se o odcizení hesla dozvěděli co nejdříve a zkrátili tak na minimum čas, kdy může dojít ke zneužívání účtu a poškozování návštěvníků zákaznického webu.
První mechanismus spočívá v kontrole všech souborů změněných přes FTP na přítomnost sekvencí typických pro webový malware. Pro jejich hledání jsme za pomoci dříve zaznamenaných případů sepsali několik regulárních výrazů a ty spouštíme nad každým HTML/PHP souborem změněným přes FTP. Každá podezřelá sekvence je pak nahlášena a zkontrolována administrátorem. Druhý mechanismus využíval veřejnou část dat z databáze stránek se škodlivým obsahem, kterou provozuje StopBadware.org resp. Google a vyhledával v nich podle názvu domény. Záhy se ukázalo, že uvedených případů přibývá, a tak jsme začali hledat možnosti protiopatření.
Motivací byla jednak snaha maximálně zákazníkům zabezpečit weby proti známé hrozbě, i když chyba v zabezpečení nebyla na našich serverech, ale na domácích počítačích zákazníků, a také zkušenost, že čekání, až vlna nějakého útoku opadne a problém se vyřeší sám, je přístup, který zkrátka nefunguje problémy ve skutečnosti ustanou vždy až po zavedení účinného protiopatření.
První nápady
Nejprve se nabízela dvě možná řešení (která také později nasadila řada webhosterů):
- Uzamčení FTP účtů a jejich odemykání přes zákaznické centrum (naši zákaznickou webovou administraci). Toto jsme považovali za příliš restriktivní opatření, které by velké množství zákazníků znatelně omezovalo v jejich práci, a to i těch, kteří si své heslo dobře chrání a nikde neukládají. K tomu správce stránek nemusí být totožný s majitelem hostingu a tedy nemusí mít ani přístup k zákaznickému heslu, a to zejména v případech, kdy existuje k jednomu virtualhostu více FTP účtů. Hrozilo, že si zákazníci začnou účty ve velkém opět odemykat a tím opatření samo ztratí svůj efekt. Dále bychom tím ohrozili bezpečnost dalšího a ještě důležitějšího hesla – toho do zákaznického centra, protože by jej bylo nutné používat mnohem častěji (tedy by jej častěji někdo ukládal do prohlížeče nebo psal na papírky u počítače apod.) a zadávalo by se častěji i na zavirovaných počítačích, odkud bylo vykradeno FTP heslo a kde je tak pravděpodobnější i přítomnost nějakého keyloggeru. V důsledku se tímto opatřením velkému počtu zákazníků přinese více problémů, než se jich vyřeší.
- Omezování přístupu na FTP podle IP adres, které si definují sami zákazníci. Zde je problém s implicitním nastavením. Pokud účty implicitně znepřístupníme a povolíme přístup jen z definovaných IP, pro většinu zákazníků nastane stejný problém jako v předchozím případě. Následně budou složitě řešit, z jakých IP adres si tedy mají přístup povolit a nakonec stejně ve chvíli, kdy budou chtít na stránkách něco změnit např. z mobilního připojení, budou muset opět zjišťovat svou adresu a tu explicitně povolovat. Pokud bychom nechali účty implicitně otevřené odkudkoliv s možností volitelného omezení na definované IP, problém bude pro většinu zákazníků přetrvávat i nadále a nijak bychom je neochránili.
Dá se to řešit lépe?
Ačkoliv jsou obě opatření lepší než žádné, nelíbilo se nám ani jedno z nich a zaměřili jsme se více na IP adresu klientů, kterou kromě jména a hesla známe jako jedinou již v průběhu přihlašování.
Vycházeli jsme z toho, že uvedení správného uživatelského jména a hesla při přihlašování na FTP již nemůžeme považovat za dostatečnou autorizaci pro přístup k zákaznickému účtu a snažili jsme se najít způsob, jak s vysokou pravděpodobností podle IP adresy rozpoznat, jestli se jedná o oprávněný přístup nebo potenciální zneužití. Pokud by se to podařilo, mohli bychom zvolit podobný princip, který se nám již osvědčil na mailovém clusteru. Na něm podle testů IP adresy SMTP klienta rozhodujeme, jestli mail rovnou přijmeme nebo bude greylistován. A protože podezřelost IP adresy jako potenciálního spammera dokážeme určovat s vysokou pravděpodobností, dokážeme také převážnou většinu regulérní pošty přijímat bez zdržení a zároveň spam odmítat hned na začátku procesu přijetí mailu. FTP logy u napadených účtů ukazovaly zcela zřejmě, že útoky přicházejí ze zahraničí. Zároveň jsme se analýzou všech logů přesvědčili o tom, že drtivá většina zákazníků přistupuje na FTP z adres registrovaných v ČR nebo SR (dle GeoIP databáze).
Chtěli jsme tedy autorizaci na FTP rozšířit o GeoIP testy. Autorizace u nás využívá modulů PAM, nicméně neexistuje žádný modul jako pam_geoip. Tento jsme později sami v testovacím prostředí implementovali, ale implementace se velice zesložiťovala našimi dalšími nároky a ukázala se jako značně neflexibilní pro provádění později definovaných kontrol. Chtěli jsme GeoIP testy následně spojit s možností individuální konfigurace IP adres oprávněných k přístupu na FTP účet.
Po dalším testování padla volba na velice jednoduchý a poměrně málo známý modul pam_exec, který pro ověření autorizace jednoduše zavolá externí příkaz, v našem případě python script. V tomto scriptu jsme již dokázali velice rychle implementovat potřebnou funkčnost. Script dostane vstupní informace prostřednictvím systémových proměnných PAM_USER a PAM_RHOST, IP adresu klienta ověří dle GeoIP databáze a individuálních nastavení zákazníka a následně pomocí exitcode předá zpět informaci o povolení nebo zamítnutí přístupu. Mohli jsme tak rychle vytvořit nové implicitní nastavení schopné produkčního nasazení, které povoluje přístup jen z CZ/SK IP adres, což je doposud nejvhodnější nastavení pro většinu našich zákazníků a volitelně šlo účet otevřít pro přístup odkudkoliv.
Řešení má zjevně i své slabší stránky
Spíše drobnost, která ale může být v některých případech matoucí, tkví v tom, že přes modul pam_exec není možné zpětné předávání informace o tom, proč byla autorizace zamítnuta, tedy výsledné chybové hlášení pro klienta je stejné, jako kdyby zadal špatné jméno/heslo.
Zjevná je ale větší slabina – řešení se stane neúčinným ve chvíli, kdy by útočníci na FTP účty přistupovali přímo z počítačů, kde ukradli příslušné přístupové údaje. O tomto problému samozřejmě víme, ale realita je taková, že v současné době útoky tímto způsobem vedené nejsou a pravděpodobnost, že by byl počítač použitý k útoku (obvykle součást botnetu) zrovna v českém či slovenském IP rozsahu, se ukazuje jako velice malá. V praxi naopak zaznamenáváme chování, kdy je každý soubor na napadeném účtu měněn z jiné IP adresy. Naše řešení je v každém případě postavené tak, že umožňuje do budoucna snadno a libovolně testy IP adres modifikovat podle aktuálního vývoje hrozeb (výkonnou část obstarává běžný Python script). Pokud by se tedy způsob vedení útoků změnil, můžeme do testů zahrnout i další proměnné, jako je například čas (ať už aktuální čas nebo časový odstup od jiné události). Podobné úvahy a modifikace tedy mohou přijít, jestliže se způsob útoků změní. Situaci samozřejmě průběžně sledujeme, ale zatím nic nenasvědčuje tomu, že by se útoky nějak významně vyvíjely.
Zkušenosti po nasazení
Nejdůležitější poznatky jsou dva:
- Od nasazení tohoto způsobu FTP autorizace jsme několik následujících měsíců nezaznamenali jediný případ zneužitého FTP účtu, tedy účinek byl zásadní! Později se sporadicky několik jednotlivých případů objevilo, ale většinou se týkaly účtů, kde si zákazník sám přístup otevřel odkudkoliv.
- Objevilo se naprosté minimum případů, ve kterých nové nastavení způsobilo zákazníkovi nějaké omezení, a pokud ano, dostal velice rychle radu, jak postupovat. Řádově šlo o promile z celkového počtu aktivních FTP účtů.
Na základě připomínek několika zákazníků jsme ověřovací script následně rozšířili a umožnili tak přes zákaznické centrum těm náročnějším navolit libovolné země, IP adresy nebo celé IP rozsahy, ze kterých chtějí na FTP přístup povolit.
Vysoká efektivnost tohoto řešení spočívá právě v implicitním nastavení, které chrání naše zákazníky, aniž by museli sami zkoumat, co je pro ně nejvhodnější a aniž by byly obtěžováni odemykáním a zamykáním svých účtů nebo změnami IP adres u svých ISP. Využíváme zde stejného principu, který razí tzv. behaviorální ekonomie a díky němu chráníme ve výsledku velkou většinu klientů před chybami na jejich vlastních počítačích, aniž bychom komukoliv omezovali možnost volby, jak chce mít přístup k vlastnímu účtu nastaven. Ohlas na tento způsob FTP autorizace byl velice pozitivní a záhy jsme jej rozšířili i na službu dedikovaných serverů pro nejnáročnější zákazníky. Potvrdila se i naše dlouholetá zkušenost, že nejúčinnější řešení bývají většinou poměrně jednoduchá, „jen“ se na ně musí přijít a vše uvést do praxe.
ČLÁNKY DO MAILU