FTP server nabízí klíče k našim webům

Nešťastné praktiky některých oddělení firmy otevírají dveře hackerům. A někteří zaměstnanci nemají nejmenší ...


Nešťastné praktiky některých oddělení firmy otevírají dveře hackerům. A někteří
zaměstnanci nemají nejmenší tušení, jak na útoky hackerů reagovat.
Stalo se už takřka standardem, že se ve své práci místo hledání způsobů řešení
dlouhodobých úkolů věnuji hašení každodenních požárů i ohníčků. Také tento
týden začal tím, že jsem byl vyrušen od projektů, kterými se mám zabývat, a to
proto, že jsem měl vyšetřit dva bezpečnostní incidenty. Oba z nich se týkaly
smazaných souborů na našich serverech, které pokaždé provedl někdo, kdo tam
neměl co dělat.
První incident byl spíše záležitostí špatné konfigurace serveru než klasickým
bezpečnostním incidentem, ale stejně přitáhl mou pozornost. Začalo to tím, že
jeden zákazník poslal zprávu adresovanou na náš e-mailový účet vyhrazený
stížnostem, kde uváděl, že zaznamenal několik podezřelých souborů na našem
serveru vyhrazeném pro FTP. Tak jsem se k tomuto serveru přihlásil jako
anonymní uživatel a skutečně, bylo tu vytvořeno několik adresářů a do nich byly
nakopírovány 4 GB neautorizovaných hudebních souborů MP3.
A co bylo ještě více alarmující, je skutečnost, že jsem tu našel soubor s
názvem Commands, který obsahoval názvy uživatelských účtů používaných pro
správu našich webových stránek a hesla k nim.
Speciální uživatelské účty, které nám umožňují zajišťovat technickou podporu
našich webů, vyžadují po přihlašující se osobě uživatelské jméno a heslo.
Ukázalo se, že naše skupina zajišťující uživatelskou podporu pro naše produkty
dala tento soubor do nezabezpečené oblasti FTP serveru, protože ho považovala
za sdílenou, nijak citlivou informaci. Pokud čekáte bližší vysvětlení,
nedočkáte se ho. Ani já jsem se ho nedočkal.

Co s FTP
Odstranění inkriminovaného souboru bude jednoduché, horší je to ale s řešením
problému obecného zajištění bezpečnosti našeho FTP serveru. Nejjistější by bylo
prostě anonymní FTP server zrušit. Ale jde o cennou uživatelskou službu a náš
tým pro technickou podporu ji běžně využívá, aby mohl uživatelům snadno
nabídnout záplaty na softwarové chyby a pro poskytování další softwarové
podpory.
Naši zákazníci jej také využívají pro uploady logů událostí, ke kterým došlo u
nich na serverech. Existují jistě i jiné způsoby, jak tyto služby poskytovat,
ale anonymní FTP server se ukázal jako nejefektivnější a byl akceptován naším
personálem i zákazníky. Takže by měl zůstat na svém místě. Když ale nebude
správně nastaven, může být anonymní FTP server snadno zneužit a stát se
semeniště právních, výkonnostních i bezpečnostních problémů.
Soubory MP3 jsou právě takovým případem. Snadno se mohou stát zdrojem právních
potíží. Dá se totiž předpokládat, že porušují autorská práva a vyšetřování se
pak může nepříjemně dotknout naší společnosti. Také výkonnost naší
infrastruktury utrpí, když bude FTP server saturován přenosy takových souborů.
Lze totiž očekávat, že k nim bude při pokusech o jejich stažení přistupovat
příliš velké množství lidí současně. My pochopitelně nechceme, aby se kdokoli
další zvenku připojoval na naše servery, jejichž prostřednictvím poskytujeme
podporu svým zákazníkům.
Náš FTP server byl nakonfigurován tak, aby umožňoval anonymním uživatelům
vytvářet jejich vlastní adresáře, nebyly ani nastaveny žádné limity pro
velikost uploadovaných souborů. Jednoduché kvóty na velikost uploadů a správné
nastavení práv k adresářům může takovým incidentům snadno zabránit. Chystám se
tedy vydat návod, jak konfigurovat anonymní FTP server tak, aby to odpovídalo
našim základním předpisům pro bezpečnost IT infrastruktury firmy.

Problém s hackerem
Druhý incident, o kterém jsem se v úvodu zmiňoval, zahrnoval nekalou aktivitu
proti našem serveru v certifikační laboratoři. Jeden z našich systémových
inženýrů si všiml, že jeden ze serverů obsahující naše zdrojové kódy
nereagoval, když k němu zkoušel přistupovat prostřednictvím Secure Shellu. Aby
získal administrátorský přístup k serveru, musel použít jeho konzoli. U ní si
všiml, že byly smazány některé klíčové adresáře, které měly na svědomí to, že
se zpočátku na server nemohl dostat. A tak se začal porozhlížet kolem po log
souborech.
Jsem si jist, že tento muž chtěl zjistit rozsah škod a identifikovat
individuální odpovědnost. Ale s tím, co udělal, je problém. Zaprvé se incident
objevil přibližně před měsícem a onen inženýr o něm informuje až nyní. Za
druhé, přistupováním k jednotlivým souborům na serveru a zápisem do logovacích
souborů zkomplikoval rozeznání toho, co jsou jeho legitimní aktivity a co
aktivity hackera. V tomto případě to ale zase tak nevadilo, ptotože hacker
smazal takřka všechny log soubory na systému.
Výsledkem tohoto incidentu je situace, kdy budeme muset provést důkladnou
kontrolu, abychom zajistili, zda jsou všechny naše systémy, a to dokonce i ty
pokusné, bezpečně nakonfigurovány. Dočasně také zkonfigurujeme jeden senzor
našeho systému detekce napadení IDS tak, aby sledoval provoz na segmentu
příslušejícímu našemu pokusnému systému. Hacker se pravděpodobně pokusí získat
k pokusnému systému znovu přístup. Tentokrát by nám už ale neměl uniknout.
Doporučím, aby byly všechny logy přesměrovány na centrální zabezpečený server,
odkud je nebude možno snadno smazat.

Podle pravidel
Bezpečnostní incidenty jsou problémem nejen samy o sobě, ale také pokud jde o
následující chování zodpovědných zaměstnanců. Velké problémy činí většinou u
celosvětově působících firem jednotlivci, kteří nemají nejmenší tušení, jak
správně reagovat na aktivity hackerů. Je třeba, aby rozuměli tomu, že určité
akce musejí být provedeny bezprostředně poté, co je zjištěn potenciální průnik
do systému. V některých případech by měl správce například vytvořit zrcadlový
obraz celého systému, který se stal obětí útočníka. Tímto způsobem je zachován
přehled o proběhlých dějích i poté, co správce provede zásahy související např.
s tím, aby byl systém zase on-line a bezpečný.
Soubor obsahující záznam stisků kláves provedených uživatelem obsahuje
zpravidla důkazy hackerovy aktivity. Pokud ale správce provedl na systému po
incidentu nějaké změny, je pro vyšetřovatele obtížné říci, které ze
zaznamenaných aktivit byly realizovány útočníkem.
Abych se s tímto problémem vypořádal, rozhodl jsem se dát dohromady program pro
hlášení incidentů. První část projektu bude zahrnovat vytváření dokumentů,
které budou pomáhat jak správcům Unixu, tak Windows NT, aby mohli zhodnotit
stav systémů v okamžiku, kdy mají podezření na nějaké nežádoucí aktivity.
Poskytnu jim také dokumenty na trénování ostražitosti, zaměřené na rekci na
incidenty. A nakonec požádám náš databázový tým, aby vytvořil databázi a k ní
příslušející webové rozhraní, které by umožnily snadné vkládání zpráv o
bezpečnostních incidentech. Výsledek poté bude zaslán e-mailem mému týmu a my
budeme moci provést odpovídající akci.
Řešíte podobné problémy jako Mathias Thurman? Podělte se o svoje zkušenosti s
námi i se čtenáři Computerworldu. Můžete psát na adresu bezpecnost@idg.cz.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.