Řešení bezpečnostních incidentů

Technická zpráva CESNETu číslo 20/2005
k dispozici též ve formátech PDF, PostScript a XML.

Andrea Kropáčová, Pavel Kácha
12. 12. 2005

1 Bezpečnostní incidenty

Spolu s nárůstem uživatelů, kteří mají přístup do celosvětové sítě, stoupá i počet bezpečnostních incidentů, kterých se uživatelé dopouštějí svou nedbalostí, neznalostí nebo úmyslně. Při zjištění vzniklého bezpečnostního incidentu je nejdůležitější rychlá a adekvátní reakce. Vzhledem ke stále se zvětšujícímu počtu strojů, které mají správci na starosti, existuje ale reálná možnost, že přes všechna preventivní opatření dojde k narušení bezpečnosti počítače, správce tento problém nezaregistruje včas a stroj v jeho správě je napaden a zneužit k dalším útokům. V takovém případě se ovšem správci napadených strojů brání a na útok si stěžují. Základním komunikačním prostředkem je v těchto případech elektronická pošta. Na kontaktní e-mail adresy správců zodpovědných za konkrétní síť jsou v případech bezpečnostních incidentů posílána tzv. hlášení o incidentu.

2 Kontaktní informace domén a IP rozsahů

Základním zdrojem kontaktů pro jednotlivé domény a IP rozsahy jsou databáze registrátorů národních domén a regionálních internetových registrátorů, kteří přidělují IP rozsahy lokálním internetovým registrátorům. Regionálních internetových registrátorů je v současnosti pět: RIPE NCC, APNIC, ARIN, AfriNIC a LACNIC. Každá organizace, která má vlastní internetové připojení, má svůj rozsah IP adres zaregistrovaný v databázi jednoho z výše uvedených registrátorů. Každý z nich spravuje určitou zeměpisnou oblast: v Evropě přiděluje rozsahy RIPE NCC, v severní Americe ARIN, v Latinské Americe a Karibiku LACNIC, v Africe AFRINIC a v Asii a Pacifiku organizace APNIC. Každý přidělený rozsah IP adres je pak spolu se základními údaji o organizaci, která o rozsah žádala, zanesen do jedné z databází. Všechny databáze jsou veřejně přístupné.

Například blok adres, do kterého patří IP adresa 195.113.144.230, na které běží hlavní webový server www.cesnet.cz sdružení CESNET, z. s. p. o., má v databázi RIPE tento záznam:

inetnum:      195.113.144.128 - 195.113.144.255
netname:      BB4-TCZ
descr:        CESNET, z.s.p.o.
descr:        Prague
country:      CZ
admin-c:      VN2-RIPE
tech-c:       VN2-RIPE
status:       ASSIGNED PA
mnt-by:       TENCZ-MNT
source:       RIPE # Filtered

person:       Vaclav Novak
address:      CESNET, z.s.p.o.
address:      Zikova 4
address:      Praha 6
address:      160 00
address:      The Czech Republic
phone:        +420 224352978
fax-no:       +420 224313211
e-mail:       NovakV@cesnet.cz
nic-hdl:      VN2-RIPE
source:       RIPE # Filtered

% Information related to '195.113.0.0/16AS2852'

route:        195.113.0.0/16
descr:        CESNET2
origin:       AS2852
mnt-by:       AS2852-MNT
remarks:      Please report abuse -> abuse@cesnet.cz
source:       RIPE # Filtered

Z tohoto výpisu se člověk dozví základní kontaktní informace pro adresový blok 195.113.144.128 - 195.113.144.255 jako jsou jméno organizace, které byl tento blok přidělen, do kterého AS (Autonomního Systému) náleží, osobu zodpovědnou za tento blok a mimo jiné i e-mail adresu určenou k hlášení bezpečnostních incidentů, kterých se dopustí stroj s IP adresou z tohoto rozsahu. Pro tuto e-mail adresu je doporučené používat tvar abuse@doména.tld, tedy např. pro hlášení bezpečnostních incidentů v doméně cesnet.cz existuje adresa abuse@cesnet.cz . Podrobnější informace naleznete v dokumentu , který vydala organizace RIPE.

Obdobná situace panuje na poli doménových jmen. Každý registrátor doménových jmen udržuje základní veřejné informace o registrovaných doménách a jejich "majitelích" v databázi, která je veřejně k dispozici. Výčet registrátorů doménových jmen by byl obsáhlý, za všechny proto jmenujme jednoho z registrátorů TLD .cz (Top Level Domain) sdružení CZ.NIC.

2.0.1 Základní pravidla pro kontaktní informace

Je v zájmu všech správců sítí, aby veškeré údaje o svých sítích (přidělených IP adresách a registrovaných doménách) udržovali v databázích registrátorů aktuální a funkční.

Základní technická doporučení pro provoz adresy pro hlášení bezpečnostních incidentů:

Je vhodné, aby ji přijímalo více lidí (správců) a to z důvodů co nejrychlejší reakce na ohlášený incident a z důvodu zástupnosti.
Je nutné dobře zvážit antispamovou a antivirovou ochranu pro příjem zpráv na tuto adresu. Lepší je zvolit mírnější pravidla: v případě striktně nastavené obrany nemusí být důležité hlášení doručeno a následky mohou být vážné.
Veškerou komunikaci z a na adresu abuse archivovat a pravidelně zálohovat! Je to vhodné pro případné pozdější dohledání toho, kdo, jakým způsobem a s jakým výsledkem ohlášený incident řešil.

Spoustu užitečných informací týkajících se provozu tzv. abuse adres můžete najít zde.

2.0.2 Dohledání kontaktů k dané IP adrese nebo doméně

Většina registrátorů provozuje na svých stránkách službu, která umožňuje prohledávat údaje registrovaných domén a přidělených IP rozsahů. Např. organizace RIPE provozuje tzv. whois službu, která umožňuje zjistit základní informace o IP adresách. Pro vyhledání informací o doméně v TLD .cz je možné použít vyhledávací službu například na stránkách sdružení CZ.NIC.

Některé operační systémy pak mají přímo ve svém základním vybavení nástroje pro prohledávání těchto databází - za všechny zmíním např. utility whois a její vylepšenou verzi jwhois na OS Un*x a podobných. Použití těchto utilit je triviální; na příkazové řádce stačí napsat např. následující příkaz:

whois -h whois.ripe.net 195.113.144.230

jwhois cesnet.cz

a program vrátí základní informace o IP adrese 195.113.144.230 a doméně cesnet.cz. Program jwhois navíc přináší možnost, jak bez podrobnější znalosti problematiky "kdo přiděluje IP adresy v Tibetu nebo Venezuele" získat informace o jakékoliv IP adrese.

Jak je tedy vidět, svět Internetu teoreticky není úplně anonymní a ve většině případů se lze dopátrat, kdo je za danou IP adresu a doménu zodpovědný. Úmyslně uvádím "ve většině případů", výjimky samozřejmě existují i zde - například velké rozsahy pro dynamické přidělování adres, které byly v minulosti vyčleněny na podporu rozvoje Internetu v zemích Asie a Jižní Ameriky. Proto obecné doporučení - v případě, že nejste schopni dohledat, kdo je za určitou adresu zodpovědný, zeptejte se zkušenějšího kolegy, prohledejte WWW stránky, případně se obraťte na organizace typu RIPE a ICANN.

3 Postup při řešení bezpečnostního incidentu

V případě, že správce zjistí, že na zařízení v síti, za kterou je zodpovědný, někdo útočí, je vhodné postupovat v následujících krocích:

Co nejdříve zabránit útoku, např. omezením přístupu útočníka do sítě.
Zkontrolovat integritu a zabezpečení sítě a provozovaných strojů.
Shromáždit důkazní materiál o útoku.
Informovat kolegy, případně nadřízené, o útoku.
Zvážit možné následky útoku, např. zda nemohlo dojít k odchycení hesel a jejich následnému zneužití.
"Proces" s pachatelem - v případě, že se útoku dopustil "lokální" uživatel, je situace jednodušší, protože lze uplatnit pravidla nastavená v organizaci pro tyto případy. V případě útoku "zvenčí" je vhodné na vzniklou situaci upozornit zodpovědného správce, tj. vytvořit a poslat hlášení o incidentu.

Při vytváření hlášení o incidentu je vhodné dodržet pár základních pravidel:

Zvolit vhodně jazyk, pouze v případě, že si jsme 100% jistí, že cílový adresát rozumí konkrétnímu jazyku, je možné jej použít. V opačném případě je vhodné dopis zformulovat anglicky.
Hlášení by mělo být:
- stručné, jasné, srozumitelné a slušné
- jednoduchý textový mail, v případě nutnosti s přílohou
Hlášení by mělo obsahovat:
- důkaz - hlavičku spamu, část logu, URL
- výstižný Subject, který bude obsahovat například IP adresu útočníka nebo typ incidentu (spam, vir, DOS, porušení autorských práv apod.).
- pomocné informace - časová zóna, zdrojová a cílová adresa, porty a podobně
- informaci o tom, jestli na stížnost požadujete odpověď, nebo ji berete pouze jako informativní
jen jedna IP adresa nebo adresový blok na jedno hlášení
podpis - "občanský" podpis je samozřejmostí, z hlediska ochrany vlastní identity a obsahu zprávy je vhodný elektronický podpis
základní kontaktní informace - jméno, jméno firmy, adresa firmy, telefon, fax a podobně. Dalším vhodnou iformací může být sdělení, jakým způsobem je možné vás kontaktovat (e-mailem, telefonicky).

Příklad správně vytvořené stížnosti:

Date: Sat, 24 Sep 2005 10:08:19 +0000 (GMT)
From: abuse@somewhere.in.the.earth
To: abuse@cesnet.cz
Subject: Network scan from 195.113.xxx.yyy

Dear Madam/Sir,

we have detected a scan of our network which appears to have originated 
from source address 195.113.xxx.yyy. Scanning started at approximately
2005-09-23 15:00:08 UTC. This address attempted to scan approximately 500
addresses on TCP/22.

A reply to this message is not required but the activity above must be 
stopped. If you need to contact us about this issue, please do not hesitate
to reply to this message.

Thank you

Security Team Somewhere In The World
e-mail: abuse@somewhere.in.the.earth
tel: +433 2 2456 7890
City, Some Country
                                                                                                   
Sample of log entries:

2005-09-23 15:00:08 UTC,Src IP 195.113.xxx.yyy:4914,Dst IP xxx.yyy.56.12:22,tcp
2005-09-23 15:00:08 UTC,Src IP 195.113.xxx.yyy:4914,Dst IP xxx.yyy.56.13:22,tcp
2005-09-23 15:00:08 UTC,Src IP 195.113.xxx.yyy:4914,Dst IP xxx.yyy.56.12:22,tcp
2005-09-23 15:00:08 UTC,Src IP 195.113.xxx.yyy:4914,Dst IP xxx.yyy.56.13:22,tcp
2005-09-23 15:00:23 UTC,Src IP 195.113.xxx.yyy:4914,Dst IP xxx.yyy.107.116:22,tcp
2005-09-23 15:00:23 UTC,Src IP 195.113.xxx.yyy:4914,Dst IP xxx.yyy.107.119:22,tcp
2005-09-23 15:00:23 UTC,Src IP 195.113.xxx.yyy:4914,Dst IP xxx.yyy.107.112:22,tcp
2005-09-23 15:00:23 UTC,Src IP 195.113.xxx.yyy:4914,Dst IP xxx.yyy.107.115:22,tcp
2005-09-23 15:00:30 UTC,Src IP 195.113.xxx.yyy:4914,Dst IP xxx.yyy.149.101:22,tcp
2005-09-23 15:00:30 UTC,Src IP 195.113.xxx.yyy:4914,Dst IP xxx.yyy.149.103:22,tcp
...

3.1 Příjem hlášení bezpečnostního incidentu a jeho řešení

I přes maximální péči o všechny spravované stroje se může stát, že k narušení bezpečnosti dojde, ať už zvnějšku, nebo se ho dopustí lokální uživatel, a dojde k útoku na stroje ve vzdálené ("cizí") síti. V takovém případě je velmi pravděpodobné, že na adresu pro hlášení bezpečnostních incidentů dorazí stížnost, na kterou ve většině případů bude nutné a vhodné odpovědět.

Při vyřizování (zpracování) incidentu postupujeme následujícím způsobem:

Ověříme, jestli incident spadá do "naší" kompetence (kompetence adresáta). V případě, že:

Nespadá vůbec do naší sítě (AS)

Autorovi stížnosti odpovíme, že incident byl špatně ohlášen a do naší kompetence nepatří.

Nespadá, ale týká se naší sítě

V tomto případě je vhodné zvážit, jestli je lepší na hlášení odpovědět, že za dané IP nejsme zodpovědní, nebo zvážit přeposlání kolegovi, o kterém víme, že má dané IP na starosti. Zde samozřejmě záleží na tom, jak je daná síť rozsáhlá a jaké jsou vazby mezi jejími správci.

Spadá

Stížnost je oprávněná. Řešíme.
Lokalizujeme postižený prvek sítě (stroj, uživatele)
Co nejrychleji zabráníme dalším nekalým aktivitám - prvek odpojíme od sítě a teprve poté zkoumáme. Při fyzické nedostupnosti prvku omezíme provoz na relevantním síťovém prvku tak, aby utočník neměl možnost dále škodit.
Analyzujeme příčinu, zaarchivujeme stav - je vhodné pro získávání zkušeností. I zkušení správci občas zbrkle všechny důkazy zničí ve snaze co nejrychleji obnovit normální chod daného prvku. Občas dojde ke zničení důležitých důkazů čistě z toho důvodu, že správce bere narušení bezpečnosti stroje/služby jako své osobní selhání a má tedy snahu co nejrychleji problém zakamuflovat.
Odstraníme příčinu - v souvislosti s předchozím bodem zvážíme použití náhradního prvku (serveru, disku).
Zvážíme, jestli nemohlo dojít ke zneužití hesel, dat, apod. V kladném případě je nutné zajistit například změnu zkompromitovaných uživatelských hesel ještě předtím, než službu znova zprovozníme.
Odpovíme na stížnost
Informujeme kolegy, uživatele, nadřízené apod.
Podnikneme preventivní kroky, aby se útok neopakoval - bezpečnostní audit systému, osvěta uživatelů, apod.

Některé z výše uvedených kroků mohou samozřejmě běžet paralelně, záleží např. na závažnosti incidentu nebo na počtu správců, kteří se na odstranění incidentu podílí. Snažíme se reagovat rychle.

3.2 Reakce (odpovídání) na hlášení incidentu:

Po odstranění bezpečnostního incidentu je samozřejmě ještě nutné odpovědět na stížnosti, které přišly na kontaktní abuse adresu pro hlášení bezpčnostních incidentů.

Proč bychom měli odpovídat? Protože:

Je to slušné.
Přispívá to k informovanosti a tedy k prevenci.
Tím, že incidenty řešíme a odpovídáme na ně, dáváme najevo, že naše síť je slušná a dobře vedená; tím chráníme dobré jméno sítě a organizace.
Tím, že incidenty řešíme a odpovídáme na ně, si sami shromažďujeme důkazy o tom, jak bezpečnostní incidenty řešíme; tyto důkazy nám mohou pomoci v případě soudních sporů apod.
Odpovídáme i na incidenty, které se ukáží být neopodstatněné nebo nedostatečně podložené. V druhém případě můžeme požádat o doplňující informace.
Odpovídáme i na incidenty, které do naší kompetence nepatří, tj. byly ohlášeny chybně.

Jak bychom měli odpovídat?:

Odpověď na hlášení incidentu by měla obsahovat informaci, že se daným incidentem zabýváme (v případě, že odstranění problému bude dlouhodobější záležitostí), nebo že jsme problém odstranili. Samozřejmě v případě, že stížnost byla oprávněná a k incidentu skutečně došlo.
Je vhodné odpovídat pokud možno na všechny adresy uvedené v hlavičce e-mailu, aby všichni, kterým bylo hlášení odesláno, byli informováni o jeho vyřešení.
Je nutné odpovědět na všechna hlášení daného incidentu. Typicky v případě, kdy byl útok proveden na více cílů a stížnost poslalo více stran. Odpovědět je vhodné i na ta hlášení, která dojdou po odstranění příčiny.

Obecná doporučení:

Při řešení incidentů je vhodné mít na paměti, že uživatelům chceme především pomoci, takže je nutné zvolit klidný, ale i dostatečně rázný přístup.
Pokud se jedná o hříšníka z naší sítě, je vhodné zvážit, jestli je nezbytné mu přeposlat celé originální hlášení incidentu. Některé stížnosti mohou obsahovat žádost o odpověď formou vyplnění webového formuláře s předpřipravenými odpověďmi; pak může hrozit, že uživatel vyplašený faktem, že způsobil bezpečnostní incident, použije nevhodnou nebo nesprávnou formulaci. Vždy je proto lepší, aby na incidenty odpovídal zkušený a zopovědný správce, ne koncový uživatel (např. student).
Při formulování odpovědi je nutné dbát, aby nedošlo k porušení Ochrany osobních údajů. V odpovědi stačí stručná informace o odstranění problému, případně o přijatých opatřeních.
Automatická odpověď, tj. nasazení autoresponderu, nemusí být dostatečnou odpovědí na incident.
Z důvodu ochrany vlastní identity a integrity odpovědi je vhodné používat elektronický podpis.
Veškeré přijaté incidenty a odpovědi na ně je vhodné archivovat a pravidelně zálohovat.
Máme na paměti dobré mravy - slušnost, vstřícnost, věcnost.
Je lepší odpovědět pozdě, než nikdy!

3.3 Základní mailová etiketa

Dodržování základní poštovní etikety a správné používání poštovního klienta zefektivňuje a zpřehledňuje management vytvoření, příjmu a zpracování hlášení bezpečnostního incidentu (a e-mailovou komunikaci obecně).

Pro převážně technickou komunikaci kolem správy incidentů je vhodné řídit se zásadami síťové etikety tak, jak doporučuje RFC 1855. Z praktických zkušeností vyplývá i několik dalších konkrétnějších dodatků, jejichž dodržení tuto výměnu informací prostřednictvím elektronické pošty usnadňuje. Při řešení incidentů je velmi žádoucí, aby zpráva příjemci dorazila a přečetl ji, je tedy vhodné připravovat mu co nejméně možných komplikací.

3.3.1 Text vs. HTML

Správci obvykle používané programy jsou často terminálové (Mutt, Pine); usnadníte jim tedy práci, pokud budete používat čistě textovou komunikaci. V opačném případě hrozí, že mail sice uvidí, ale často ne tak, jak byste si představovali.

Textový formát mailu usnadňuje práci automatickým parserům, které často na adresách, vyřizujících bezpečnostní incidenty bývají nasazeny - ať už jsou to analyzátory na IP adresy a klíčová slova, nebo ticketovací systémy.

Microsoft Outlook při odesílání dopisů ve formátu "Rich Text (RTF)" připojuje přílohy ve vlastním formátu - jako soubor winmail.dat, se kterým si poradí jen on sám. Odesílatel má tedy dojem, že je vše v pořádku, ale příjemce s jiným poštovním programem nemá šanci si kompletní dopis prohlédnout.

HTML formát může mít v některých konkrétních případech opodstatnění, ale u pošty technického typu zřídka.

3.3.2 Předmět zprávy

Kromě toho, že je to slušné, je i účelné zachovávat Subject (předmět) zprávy v kompletní podobě. Většina mailových klientů dokáže zpracovat reference zapsané v jiných hlavičkách zprávy, nicméně některé se stále řídí pouze informací v Subjectu. Již zmíněné automatické analyzátory také mohou mít problém s navázáním referencí souvisejících mailů.

3.3.3 Reference

Až na několik speciálních výjimek obsahuje každý dopis v obálce hlavičku Message-Id, která ho jednoznačně identifikuje. Dopis také může obsahovat hlavičku In-Reply-To a/nebo References, ve kterých jsou uložena Message-Id předchozích souvisejících zpráv. Klient je poté schopen zrekonstruovat složitější průběh diskuse a její souvislosti ("vlákna"), což bývá v případě řešení incidentů více než užitečné.

Obrázek 1: Reference v hlavičce zprávy

Obrázek 2: Reference v živé komunikaci

Klient zachovává reference pouze pokud ví, že uživatel odpovídá. Je-li odpověď vytvořena tak, že uživatel vytvoří novou zprávu (ať už použije stejný subject, nebo subject s Re:, nebo ne), je reference ztracena.

Obrázek 3: Poškozené reference

Klient ale také zachovává reference vždy, když uživatel odpovídá, opět nezávisle na tom, zda použije úplně jiný Subject. Je-li zpráva vytvořena odpovědí na jinou - nesouvisející, zařadí se mezi ostatními zprávami do nesouvisejícího tématu.

Obrázek 4: Nadbytečné reference

Lze tedy důrazně doporučit: používejte pro nové zprávy striktně New message/Nová zpráva a odpovídejte pouze pomocí Reply/Odpovědět.

3.3.4 Signatura versus Podpis

Signaturou je míněn blok textu na konci dopisu, obvykle používaný k připojení rozšiřujících informací o odesílateli či firmě, či motivačního textu. Není příliš známo, že i připojení signatury má své konvence - měla by být oddělena separátorem "- " (dva znaky mínus od začátku řádku, následované mezerou a koncem řádku). Většina mailových klientů tuto konvenci dodržuje, signaturu rozezná a kromě jejího zobrazení jiným stylem je schopna ji při odpovídání odříznout. Je-li signatura použita, je v pořádku (a dokonce vhodné), končí-li mail podpisem a následně ještě signaturou.

Obrázek 5: Signatura

3.3.5 Čas

I u příjemce se zařazení zprávy řídí časem, který do ní zaznamenal poštovní klient odesílatele - proto se také mnoho spamů (s nekorektním časem) zařazuje ve schránkách tříděných podle času na začátek, namísto na konec. Špatně nastavený a posléze do zprávy zapsaný čas může také nemile ovlivnit průchod antispamovou kontrolou (např. SpamAssassin přidává za rozpoznaný nekorektní čas trestné body).

Je proto rozumné zvážit synchronizaci pracovní stanice a poštovních serverů se síťovými zdroji přesného času - v síti CESNET2 tik.cesnet.cz a tak.cesnet.cz, případně přímo servery projektu NTP pool.ntp.org.

3.4 Co hrozí při neřešení a nereagování na bezpečnostní incident:

Následky, které hrozí, pokud na hlášení bezpečnostního incidentu pocházejícího ze sítě, za kterou zodpovídáme, adekvátně nereagujeme, mohou být velice vážné. Z těch méně závažných jmenujme například zablokování přístupu ze strany napadené sítě a tím zabránění přístupu k zajímavým informacím a zdrojům dat. V horším případech se poškozená síť může bránit tím, že nelichotivé informace o neochotě a neschopnosti bezpečnostní incidenty řešit zveřejní prostřednictvím Internetu - např. v diskusních fórech, na webových stránkách, na odborných konferencích. Často se ani nemusí jednat o úmyslné jednání, ale prosté statistické zveřejnění, jak si která síť (organizace) v této problematice počíná. Následkem takové situace pak může být poškození dobrého jména firmy a jejích zaměstnanců se všemi důsledky, které z toho vyplývají - ztráta obchodních partnerů, informací, financí apod. V krajních případech se daná organizace může dočkat žaloby, soudního sporu, pokuty. Řada uživatelů a bohužel i správců se totiž stále mylně domnívá, že ve světě Internetu zákony nejsou. Opak je pravdou, nejen, že existují, také se aplikují (Ochrana Osobních Údajů, Autorské právo).

Bezpečnostní incidenty a hlášení o nich není tedy dobré brát na lehkou váhu. Nejenom z hlediska osobní prestiže, ale také z důvodů ryze praktických - zákonodárci České republiky a Evrospké Unie na počítačovou kriminalitu myslí stále víc, takže se dá očekávat, že v brzké době se dočkáme řady nových zákonů, které život počítačovým pirátům ještě více znepříjemní. Bude proto lepší být připraven.