Bankovní institut vysoká škola Praha. Informační bezpečnost v praxi

Bankovní institut vysoká škola Praha Katedra matematiky statistiky a informačních technologií

Informační bezpečnost v praxi diplomová práce

Autor:

Bc. Martin Šinský Informační technologie a management

Vedoucí práce:

Ing. Vladimír Beneš

Praha

červen, 2011

1

Prohlášení: Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Praze, dne 27.června 2011

Bc. Martin Šinský

2

Poděkování: Děkuji tímto především své rodině, ţe mi umoţnila se soustředit na vytoření této práce, dále děkuji svému vedoucímu diplomové práce Ing. Vladimíru Benešovi za pomoc a konzultace, v neposlední řadě také děkuji společnosti, ve které jsem zaměstnán.

3

Anotace Tato diplomová práce se zabývá teoreticky i prakticky bezpečností informačních systémů.

Byl zde zpracován projekt Změny infrastruktury

informačních technologií u mého současného zaměstnavatele. Jednalo se o přechod řešení pouţitých při zaloţení firmy, které byl velmi omezeno jak finančně, tak moţnostmi řešení konzultovat s odborníky, ke kvalitnímu návrhu v rozumné finanční hladině s podporou majitelů firmy. Podle počítačových odborníků a především těch, kteří mají vrcholné znalosti a praxi v oblasti bezpečnosti systémů, jsou největší potencionální hrozbou informační techniky vlastní zaměstnanci. Proto se tato práce také zabývá eliminací jejich případných neúmyslných útoků vyplývajících z neznalosti, nevzdělanosti a podcenění sama sebe nebo dokonce proti útokům úmyslným – cíleným, s vidinou získání přízně a finančních výhod od konkurence.

Annotation This dissertation looks theoretically and practically into security of information systems. It deals with the project Change in Information Technologies Infrastructure at my present employer. It was a case of switching - with assistance of company owners - from a solution applied at the establishment of the company to a quality solution at reasonable financial costs under limitations not only financial but also in posibility to consult it with experts. According to computer specialists, primarily to those who have top knowledge as well as practice in the area of security of systems, the highest potential threat to information technologies is represented by own employees. That is why this Dissertation also addresses elimination of their possible unintentional attacks following from ignorance, lack of education and underrating of themselves or even of intentionally directed attacks following the vision of courting the favour and financial advantage from the competition.

4

OBSAH Úvod .............................................................................................................................. 7 1 Informační bezpečnost......................................................................................... 10 1.1 Definice informační bezpečnosti ................................................................. 10 1.2 Předmět ........................................................................................................ 10 1.3 Hlavní cíle bezpečnosti informačních sítí ................................................... 10 1.4 Definice počítačové bezpečnosti ................................................................. 11 2 Charakteristiky současných informačních bezpečnostních systémů a jejich zabezpečení.................................................................................................................. 13 2.1 Sítě a komunikace v nich ............................................................................. 13 2.1.1 Lokální sítě a jejich propojení ............................................................. 14 2.1.1.1 Počítače připojené do virtuální privátní sítě (VPN) ........................ 15 2.1.2 VPN a firewall ..................................................................................... 16 2.1.3 Šifrování elektronické pošty ................................................................ 16 2.1.3.1 Integrace do poštovních klientů....................................................... 16 2.1.3.2 Šifrování prostřednictvím PGP........................................................ 17 2.1.3.3 Šifrování FTP protokolu .................................................................. 18 2.1.3.4 Šifrování HTTP protokolu ............................................................... 18 2.2 Bezpečnost komunikací pomocí SSL .......................................................... 18 2.2.1 Princip SSL .......................................................................................... 18 2.2.2 Zabezpečení komunikací prostřednictvím SSH .................................. 19 2.2.3 Firewall ................................................................................................ 19 2.2.4 Testování sítí ....................................................................................... 22 2.3 Bezpečnostní audit....................................................................................... 22 2.3.1 Auditní záznamy .................................................................................. 23 3 Bezpečnostní rizika ............................................................................................. 25 3.1 Bezpečnostní politika informačních a telekomunikačních technologií ....... 25 3.1.1 Proces a dokumentace bezpečnosti ..................................................... 27 3.1.2 Bezpečnostní projekt ........................................................................... 28 3.1.2.1 Části bezpečnostního projektu ......................................................... 29 3.1.2.2 Zabezpečení počítačového systému ................................................ 29 3.1.2.3 Zabezpečení informací .................................................................... 29 3.1.2.4 Ekonomické a právní zabezpečení .................................................. 30 3.1.3 Bezpečnostní dekompozice informačního systému............................. 30 3.1.3.1 Faktory informační bezpečnosti ...................................................... 32 3.1.4 Personální bezpečnost ......................................................................... 33 3.1.4.1 Podpora uţivatelů ............................................................................ 36 3.1.4.2 Reţimová bezpečnost ...................................................................... 37 3.1.4.3 Technická bezpečnost ...................................................................... 39 3.1.5 Nebezpečí na komunikačních sítích .................................................... 39 3.1.5.1 Typické útoky na počítačové sítě .................................................... 40 3.1.5.2 Ochrana a způsoby zabezpečení informačních sítí .......................... 43 3.1.5.3 Standard ISO bezpečnostní sluţby .................................................. 44 3.1.6 Základní metody ochrany komunikací ................................................ 45 3.1.6.1 Řízení směru toku dat ...................................................................... 45 3.2 Doporučení při prosazování otázek bezpečnosti IS..................................... 46

5

4 Návrh a implementace opatření na minimalizaci bezpečnostních rizik - projekt „Změna infrastruktury ICT“ ........................................................................................ 48 4.1 Počáteční analýza stavu ICT ....................................................................... 49 4.1.1 Hardware ............................................................................................. 49 4.1.2 Software ............................................................................................... 50 4.1.3 Síťové prostředí ................................................................................... 51 4.2 Definice potřeb ............................................................................................ 51 4.3 Návrh a implementace ................................................................................. 53 4.3.1 Změna návrhu sítě a nové aktivní prvky ............................................. 53 4.3.2 Router a Firewall - blokování provozu ................................................ 53 4.3.3 Interní chat a pošta............................................................................... 55 4.3.4 Monitoring sluţeb a systémů ............................................................... 58 4.3.5 Intrusion detection system ................................................................... 59 4.3.5.1 Instalace a konfigurace SNORT - IDS ............................................ 60 4.3.5.2 Provoz IDS ...................................................................................... 67 4.3.6 Data loss prevention ............................................................................ 69 4.3.6.1 Instalace a konfigurace MyDLP ...................................................... 69 4.4 Eliminace vnitřního nepřítele ...................................................................... 79 4.4.1 Vlastní zaměstnanci představují důvěryhodného nepřítele ................. 79 4.4.2 Řízení rizik - analýza informační bezpečnosti .................................... 82 4.4.3 Návrh bezpečnostních opatření ........................................................... 83 4.4.4 Budování informační bezpečnosti v organizaci .................................. 84 4.5 Provádění kontroly ...................................................................................... 85 4.5.1 Penetrační testy a bezpečnostní audity ................................................ 87 Závěr ............................................................................................................................ 91 Příloha 1....................................................................................................................... 94 Příloha 2....................................................................................................................... 95 Příloha 3..................................................................................................................... 100 Příloha 4..................................................................................................................... 106 Příloha 5..................................................................................................................... 111 Příloha 6..................................................................................................................... 114 Příloha 7..................................................................................................................... 116 Zdroje a pouţitá literatura ......................................................................................... 118

6

Úvod Na světě existují zhruba 2 miliardy uţivatelů Internetu. Přes 600 milionů aktivních uţivatelů sociální sítě Facebook. V České republice vyuţívá internetové sluţby okolo 7 milionů obyvatel a z tohoto počtu 2 miliony šíří zvěsti o sobě, svých rodinách, okolí, přátelích a známých prostřednictvím „Facebooku“. Zkuste si odskočit na stránky www.lide.cz a zjistíte, ţe i tady se nacházejí přes 2 miliony aktivních uţivatelů. A to uţ je opravdu síla. Přiznejme si, ţe některé naše informace nebo důvěrné zprávy bychom někdy raději nepředávali dál prostřednictvím počítače a uvaţujeme, jestli nezvolíme jinou cestu – třeba osobní rozhovor s protějškem, protoţe ani telefonáty dnes nejsou zcela bezpečné. A co teprve bezpečí informací uloţených uvnitř informačních systémů organizací? Ty jsou dnes a denně námětem diskusí odborníků i laiků. Není to tak dávno, co důvěrné informace o klientele unikly z Raiffeissen Bank. Pár let zpět byla stejným problémem postiţena naše největší pojišťovna. Informace mají cenu zlata! Důvěrná data a jejich ochrana. Témata týkající se zajištění dostatečné úrovně informační bezpečnosti organizace patří mezi často diskutovaná. Bohuţel se tak děje spíš na „teoretické“ - diskusní úrovni. Prosazení konkrétních bezpečnostních opatření a procesů do praxe pak ve valné většině případů selhává. Řeší se pouze zabezpečení samotných informačních technologií, ale neméně důleţitá opatření v oblasti organizační bezpečnosti se ztrácejí ve zmatcích hierarchie organizace. Teprve v několika posledních letech se organizace začaly zabývat otázkou bezpečnosti vlastních informačních systémů. Podle statistických zdrojů v roce 1998 bylo prodáno v České republice téměř čtvrt milionu počítačů a celkový objem investic do informačních systémů činil 1,4 milionu dolarů, coţ představuje 2,7 procenta našeho hrubého domácího produktu. Od té doby se počet prodaných počítačů mnohonásobně zvýšil a tím představuje větší a větší hrozbu pro únik citlivých dat. Informace ve firemních počítačích mají mnohonásobně vyšší hodnotu a pro chod organizací důleţitý, mnohdy strategický a existenční význam. Proto je na jejich manaţerech, aby je zabezpečili před únikem, připusťme i před krádeţemi, nejen

7

vůči konkurencí, ale i před počítačovými hackery, kteří by mohli získaná data výhodně zpeněţit nebo jinak zneuţít. Luboš Dobda, jeden z autorů, jehoţ vědomosti a zkušenosti ve své diplomové práci vyuţívám, v úvodu knihy Ochrana dat v informačních systémech píše: „Před několika lety jsem se ocitl v roli pracovníka, zodpovídajícího za bezpečnost rozsáhlého informačního systému, a téměř nic jsem o této problematice nevěděl. Neexistovala ani dostupná literatura a jediným zdrojem informací byl pro mne zpočátku Internet, kde se o otázkách bezpečnosti informačních systémů rozsáhle diskutuje. Cennou pomocí pro mě byla i pětidenní konzultace, při které mi pan James Donald Gay předal řadu svých dlouholetých zkušeností z oblasti ochrany informačních systémů.“[1] Dnes je situace zcela jiná. Bezpečností informačních systémů se zabývá mnoho odborníků, kteří navrhují stále vylepšená opatření, zabraňující úniku nebo odcizení citlivých informací z počítačů. Přesto jsem byl překvapen, ţe při sběru podkladů pro tuto práci jsem narazil na renomované podniky, které svoje zabezpečení informačních systémů spustily teprve se zahájením výroby produktů nebo ještě ani zařízení pro únik informací nevlastní, případně mají od svých zaměstnanců podepsaná pouze prohlášení „o utajení, resp. nezneuţití“. Prostě: bezpečná síť je jedním z důleţitých faktorů dobrého zajištění výroby a obchodování s výrobky, produkty, ale především citlivými údaji jedinců. Řada firem dnes spadá pod dohled vládních a komerčních nařízení, jako například HIPAA (Health Insurance Portability and Accountability Act) v oblasti zdravotnictví, GLBA (Gramm-Leach-Bliley Act, známý téţ jako Financial Services Modernization Act z roku 1999) a Basel_II (Doporučení bankovních zákonů a regulace vydaná Basel Committee on Banking Supervision) ve finančním sektoru a PCI DSS (Payment Card Industry Data Security Standard) pro organizace zpracovávající transakce platebních karet. Únik citlivých dat, chráněných na základě těchto nařízení, můţe mít dopad ve výrazných finančních postizích. Velkým problémem pro řadu firem se stává ztráta intelektuálního vlastnictví, například ve formě softwarového kódu, technických plánů či know-how. Firmy také často pracují s citlivými daty svých zákazníků, která je zapotřebí velmi dobře chránit.

8

Pro všechny organizace má případná ztráta citlivých dat negativní dopad na jejich dobrou pověst, který se v případě medializace úniku citlivých dat ještě násobí. Významnou část finančních ztrát pak tvoří platby smluvních sankcí a následné ukončení kontraktů. Tak jak se pracovní síla stává víc a víc mobilní, riziko moţné ztráty dat se výrazně zvětšuje. Firemní notebooky často obsahují desítky gigabytů informací a pozbytí takového zařízení můţe mít rozsáhlé finanční dopady i na dobré jméno společnosti. Podle analýzy společnosti World at Work (z roku 2009) povoluje zaměstnancům 42 procent zaměstnavatelů v USA práci mimo kancelář například formou práce z domova. Evropa pomalu USA následuje i v tomto ohledu a podíl takto „zaměstnaných“ lidí se rok od roku zvětšuje. Na jednu stranu logické opatření – úspora financí za kanceláře, spotřebu elektřiny, vody apod. Na stranu druhou – absolutní ztráta kontroly při nakládání s důvěrnými nebo dokonce tajnými daty. Dalším velkým problémem pro firmy jsou externí spolupracovníci, kontraktoři a partneři. Ani u nich není jistota, ţe důvěrné informace v jejich osobních počítačích nezneuţije jiná osoba nebo firma. Podle studie provedené Ponemon Institutem v roce 2009 bylo přes 44 procent všech případů úniku dat spojeno s třetími stranami (externími subjekty). Poslední podchycená „průmyslová špionáţ“ postihla nedávno francouzskou automobilku Renault. Zmizela odtud do jedné z čínských automobilek citlivá data pro výrobu aut na hybridní pohon. Není co dodat. Světové koncerny i malé soukromé firmy budou muset sáhnout hlouběji do svých pokladen a začít se zabývat ochranou vlastních počítačových sítí. Kaţdá ztráta citlivých dat je pro ně mnohem větší škodou neţ statisícové investice do bezpečnosti informačních systémů.

9

1 Informační bezpečnost 1.1 Definice informační bezpečnosti Informační bezpečnost představuje ochranu informací ve všech jejich formách a po celý jejich ţivotní cyklus - tedy v průběhu jejich vzniku, zpracování, ukládání, přenosu i likvidace. Je oborem informatiky, který se zabývá zabezpečením informací v počítačích, odhalením a zmenšením rizik spojených s uţíváním počítače. Mimo jiné počítačová bezpečnost zahrnuje následující úkoly: 1. zabezpečení ochrany před neoprávněným manipulováním se zařízeními počítačového systému; 2. ochranu před neoprávněnou manipulací s daty; 3. ochranu informací před krádeţemi (nelegální výrobou kopií dat) nebo poškozením; 4. bezpečnou komunikaci a přenos dat (kryptografie); 5. bezpečné uloţení dat; 6. celistvost a nepodvrhnutelnost dat.[7]

1.2 Předmět Předmětem ochrany z pohledu informační bezpečnosti jsou informace bez ohledu na to, zda jsou uloţeny v informačním systému, vytištěny na papíře nebo existují pouze v něčí mysli.

1.3 Hlavní cíle bezpečnosti informačních sítí Cílem bezpečnosti informačních sítí je zajištění následujících základních atributů chráněných informací: důvěrnosti (ochrana před neoprávněným čtením)

10

celistvosti (ochrana před neoprávněnými úpravami nebo zničením) dostupnosti (zajištění adekvátního přístupu, ochrana před jeho neoprávněným zamezením) Velmi důležité a potřebné je zajistit: autentizaci (ověření, ţe subjekt je tím, za koho se vydává) autorizaci (omezení dostupnosti operací, jakými jsou například čtení nebo zápis informací, jen pro oprávněné uţivatele) nepopiratelnost (vyloučení moţnosti popřít dřívější provedení nějaké operace)[5]

1.4 Definice počítačové bezpečnosti Abychom mohli odlišit dva podstatné pojmy ochrany informací, je zapotřebí krátce se zabývat i počítačovou ochranou, která úzce navazuje na techniku a matematiku, neţ některé jiné počítačové oblasti. Počítačová ochrana má tři podstatné kroky: 1. prevence – ochrana před hrozbami; 2. detekce – odhalení neoprávněných (skrytých, nezamýšlených) činností a slabých míst v systému; 3. náprava – odstranění slabého místa v systému; Zlepšení počítačové bezpečnosti by mělo zahrnovat: povolení fyzického přístupu k počítači pouze těm osobám, které budou dodrţovat bezpečnost při práci s počítači a daty; pouţití hardwarových zařízení, která vynucují bezpečnostní opatření, coţ sniţuje

závislost

počítačové

bezpečnosti

programech);

11

na

software

(počítačových

vyuţití mechanismů operačního systému, která vynucují pravidla chování programů, aby byl omezen rozsah programů, kterým je nutné důvěřovat; vyuţití záznamů o změnách v programu (verzování) které je moţné vyuţít pro sledování jejich vývoje; Hovoříme-li o počítačové bezpečnosti musíme mít na zřeteli bezpečnost samotného operačního systému, bezpečnostního projektu a bezpečného šifrování (kryptografie).

12

2 Charakteristiky současných informačních bezpečnostních systémů a jejich zabezpečení 2.1 Sítě a komunikace v nich Pro tzv. síťový protokol byly stanoveny normy ISO/OSI. Referenční model ISO/OSI se pouţívá jako názorný příklad řešení komunikace v počítačových sítích pomocí vrstevnatého modelu, kde jsou jednotlivé vrstvy nezávislé a snadno nahraditelné. Ty jsou rozděleny do následujících skupin: 1. Fyzická vrstva – specifikuje fyzickou komunikaci. Jedná se především o síťové karty, stanovuje přenos „jedniček a nul“. 2. Linková vrstva – poskytuje spojení mezi dvěmi sousedními systémy. Převádí data z fyzické vrstvy do rámců. Seřazuje přenášené rámce, oznamuje neopravitelné chyby. Na této vrstvě pracují přepínače a mosty. 3. Síťová vrstva – se stará o směrování v síti a síťové adresování, spojuje systémy, které spolu přímo nesousedí. Zde pracují směrovače. 4. Transportní vrstva – zajišťuje přenos dat mezi koncovými uzly. Jejím úkolem je rozdělit je na jednotlivé pakety, opatřit hlavičkami a předat dál – niţší vrstvě. Vrstva nabízí spojově (TCP-zajišťuje přenos dat se zárukou) a nespojově (UDPzajišťuje přenos dat bez záruk) orientované protokoly. 5. Relační vrstva – organizuje a synchronizuje dialog mezi spolupracujícími relačními vrstvami obou systémů a řídí výměnu dat mezi nimi. Umoţňuje vytvoření a ukončení relačního spojení, synchronizaci a obnovení spojení, oznamování výjimečných stavů. Do této vrstvy se řadí NetBIOS, AppleTalk, RPC, SSL. 6. Prezentační vrstva – má na starosti např. konverzi číselných formátů z jiných typů operačního systému, přizpůsobení pořadí bajtů apod. Sem patří například protokol SMB (Samba).

13

7. Aplikační vrstva – na ní pracují tzv. aplikační protokoly, v TCP/IP např. FTP (přenos souborů), HTTP (www stránky), SMTP (elektronická pošta), vzdálené přihlašování a další. Např. definují formát poštovní zprávy, tj. odesílatele, adresáta, předmět zprávy, jeho tělo, připojené soubory a další.

Jako dobrý příklad můţe poslouţit: odeslání zprávy na opačný konec světa; přitom poštovní program předá zprávu (její přílohy, adresy odesílatele, adresáty) aplikační vrstvě síťového protokolu. Ta ji nasměruje do prezentační vrstvy, ta do relační vrstvy a ta do transportní vrstvy, v níţ je rozdělena do paketů, které označí adresami odesílatele a příjemce. Ty dál putují do síťové vrstvy, která rozhoduje o nejbliţším počítači, do které budou pakety odeslány, aby se dostaly co nejblíţe cílovému počítači. Na nejbliţším počítači se kontroluje, jestli není cílovým počítačem. Pokud ne, je určen nejbliţší počítač ve směru cílového počítače a celý proces se opakuje, dokud pakety nedorazí do určeného cíle. Sniffer – jedná se o program, sledující průběh celé operace „odeslání zprávy na druhý konec světa“, kontrolou paketů procházejících kolem našeho počítače, zachycuje je a ukazuje jejich obsah. Autoři programů zabezpečení sítí vycházeli při jejich sestavování ze dvou alternativ: 1. Šifrování na úrovni paketů – program existuje mezi transportní a síťovou vrstvou a šifrují se všechny pakety bez ohledu na jejich obsah. Šifrovací klíč je dán certifikací cílových adres, resp. jednotlivých stanic. 2. Šifrování na úrovni aplikačních vrstev. Tyto aplikace jsou vyuţívány pro samostatné šifrování elektronické pošty, FTP, HTTP přenosů nebo vzdáleného přihlašování apod.

2.1.1 Lokální sítě a jejich propojení Virtuální privátní sítě původně vznikly jako alternativa k drahým pronajatým okruhům. Pracují na principu pouţití veřejné sítě (např. Internet) jako sítě soukromé a jejich hlavní výhodou je levné připojení. Aby bylo eliminováno

14

nebezpečí napadení takových sítí, jsou zabezpečeny zařízeními, která šifrují data procházející mezi jednotlivými lokálními sítěmi. Vstupní zařízení mohou být hardwarová nebo softwarová a jsou nazvána brána VPN. Sledují odcházející pakety. Pokud je příjemcem „spřátelená“ lokální síť, jsou pakety šifrovány veřejným klíčem brány této sítě, podepíše a odešle. Jdou-li pakety jinam do světa (e-mail, www stránky) odcházejí nezměněny. Vstupní brány se vzájemně autentizují při výměně dat a jejich tok TCP/IP je šifrován pomocí šifrovacích algoritmů.

2.1.1.1 Počítače připojené do virtuální privátní sítě (VPN) Doba a rozvoj počítačové sítě, včetně narůstajícího mnoţství soukromých drţitelů osobních počítačů (PC) prokázala, ţe bude zapotřebí další z moţných variant řešení, kterou bylo propojení těchto přístrojů navzájem a to v rámci centrálního serveru v systému organizace – pracovníci nebo obchodní cestující – filiálky a klientela nebo zákazníci. Např. firma disponuje rozsáhlou distribuční sítí po celém světě a jejím cílem je on-line propojení se sítěmi umístěnými v různých zemích (vedení – obchodní centrum a marketing jsou např. v Evropě; výrobní část firmy v Asii a výzkumná pracoviště např. v USA). Obchodní oddělení má dvacet poboček v různých státech světa a přitom musí sledovat skladové zásoby, trţby, poptávku a nabídku zboţí v té které zemi. Obchodníci i management mají poţadavek, aby se mohli do centrální sítě připojovat z celého světa a podávat svoje hlášení a zprávy o dění v té nebo oné zemi. Řešení je dnes poměrně jednoduché: vstupní body do Internetu jsou v Evropě (např. Praha) – v Asii jsou instalovány programy typu VPN brána (VPN, Gateway). Ve všech VPN branách jsou konfigurovány IP adresy ostatních bran, patřících do virtuální sítě a je vymezen klíčový pár pro autentizaci a šifrování. Klíče jsou doručeny bezpečně na ostatní servery. Na serveru obchodního oddělení zapojíme sluţbu pro připojení samostatných klientů poboček a PC (notebooků) obchodních zástupců. Kaţdý server a všichni klienti mají vygenerovaný klíčový pár a bezpečným způsobem vymění veřejné části klíčů. Moderní VPN ve svých řešeních nahrazují pouţití veřejných klíčů certifikáty podle předem stanovené normy X.509.[2]

15

Aby byla zajištěna kompatibilita jednotek VPN řešení mezi sebou, bylo předem zapotřebí zvolit standard. Většinu VPN produktů podporuje standard IPSec. (V – Secure VPN+; Gauntlet VPN; VPN-1 apod.). Některý z uvedených protokolů pak podporuje autentizaci a šifrování, ale nic nehovoří o výměně klíčů. Proto vznikl tzv. „prostor pro tvořivost“ jednotlivých výrobců.

2.1.2 VPN a firewall Se zabezpečením vstupní brány do Internetu souvisí ještě jeden základní typ síťového zařízení – firewall. Většina komerčně prodávaných firewallů nabízí i funkce VPN.[2]

2.1.3 Šifrování elektronické pošty Jednou z bezpečnostních aplikací (podle modelu ISO/OSI) je šifrování elektronické pošty, při níţ se šifrování provádí přímo do klientských programů, přesněji do aplikační vrstvy. To znamená, ţe do aplikační vrstvy se data dostávají uţ zašifrovaná a podepsaná. Tento krok se provádí v klientské stanici odesílatele a prochází všemi síťovými vrstvami. Zpráva je následně rozšifrována aţ v klientském poštovním programu příjemce. Prvním šifrovacím programem pro elektronickou poštu byl program Philla Zimmermanna – PGP. Po svém sestrojení byl masově distribuován, protoţe byl k dispozici volně na Internetu. PGP však koupila firma Network Associates a udělala z něho komerční software. Proto vznikla svobodná alternativa GPG, která plně odpovídá standardu OpenPGP.

2.1.3.1 Integrace do poštovních klientů Počítačoví experti se snaţili sestrojit jednoduchý software s jednoduchým ovládáním, aby plnil bezpečnostní funkci přímo uvnitř klientských poštovních produktů. Díky těmto vlastnostem měl být oblíben u široké veřejnosti. Jedním z takových doplňků se stal šifrovací plug-in (zásuvný modul) s tím předpokladem, ţe je poštovní aplikace schopna tyto moduly pouţívat.[2] V současné době obsahuje

16

velké mnoţství klientů podporu šifrování přímo v sobě (Evolution, Thunderbird a další).

2.1.3.2 Šifrování prostřednictvím PGP Výzkum i vývoj šly neustále kupředu a tak se skupina programů patřících do mezinárodní verze balíku PGP rozrostla a dnes ho firma dodává jako celek, do něhoţ patří: 1. PGP for e-mail and files – sem patří plug-in pro MS Exchange/MS Outlook a další mailové klienty a samostatný program pro šifrování jednotlivých souborů a dat ve schránce Windows. 2. PGP disk – on-line šifrování celých disků pro Macintosh a Windows. 3. PGP sdk – soubor knihoven pro zapojení funkcí PGP do aplikace. 4. PGP Certificate server – nástroj pro centrální ukládání veřejných klíčů na jeden centrální server, kde jsou pak přístupné všem klientům sítě. 5. Policy Management Agent – zajímavá aplikace umoţňující nastavení omezující podmínky pro odesílanou poštu ze serveru. Tzn. nelze odeslat zprávu, která není šifrována.

Public Key Infrastructure (PKI) je důleţitý u aplikací pro šifrování elektronické pošty, kdy vznikla potřeba bezpečně uchovávat veřejné klíče (certifikáty) v centrálním organizovaném skladu. Např. kaţdý zaměstnanec můţe nainstalovat do svého poštovního programu i bezpečnostní plug-in, vygenerovat klíčový pár, veřejný klíč si pak nechá podepsat autoritou. Vzhledem k tomu, ţe při velkém počtu zaměstnanců by byla autorizace klíče obtíţná (musí se autorizovat mezi všemi navzájem) vznikly vnitropodnikové servery uchovávající šifrovací klíče všech uţivatelů v síti. Kdyţ klientský šifrovací program poţaduje certifikát některého z kolegů, se kterým ještě nekomunikoval, zeptá se serveru, zda ho nemá. Pokud ho server vlastní, obdrţí klient kopii do své lokální „klíčenky“ (lokání databáze klíčů vedená kaţdým lokálním šifrovacím programem – anglicky keyring).

17

2.1.3.3 Šifrování FTP protokolu Dalším z aplikačních je tzv. FTP protokol. Jedná se o velmi starý protokol, který sám o sobě neobsahuje ţádné zabezpečení. Protokol se vyuţívá pro přenos souborů mezi uzly. Další alternativou je pro přenos vyuţít protokol SSH, konkrétně jeho sluţbu SFTP, která přenáší soubory přes šifrované SSH spojení. Postupem času vzniklo rozšíření FTP protokolu pojmenované FTPS. Jedná se o rozšíření o příkazy umoţňující přejít na šifrovanou komunikaci jak u kontrolního tak u datového spojení. Pro šifrování se pouţívá SSL/TLS. Někdy se také pojmem FTPS myslelo zabalení normálního FTP v kryptovaném tunelu pomocí SSL/TLS wrapperu.

2.1.3.4 Šifrování HTTP protokolu Šifruje se i přístup k www stránkám, v dnešní době přístupu k bankovním sluţbám či placení přes internet je to naprostá nutnost. Toto šifrování řeší HTTPS, nadstavba aplikačního protokolu HTTP, která umoţňuje zabezpečit spojení mezi webovým prohlíţečem a serverem před odposloucháváním a podvrţením dat. Také umoţňuje ověřit identitu protistrany. Vše je šifrované pomocí SSL/TLS.

2.2 Bezpečnost komunikací pomocí SSL 2.2.1 Princip SSL Počítačoví experti vsunuli do protokolu TCP/IP nad transportní vrstvu šifrovací modul (vrstvu), který můţe šifrovat všechny aplikační sluţby (HTTP, Telnet, FTP, SMTP a další). Nastavení protokolu můţe být právě v MS Explorer, v němţ se dají importovat certifikáty serverů, se kterými chceme bezpečně komunikovat. Protokol SSL je standardní součástí Windows a dalších operačních systémů a standardně ho podporují všechny běţné prohlíţeče i www servery. Např. Šifrování http protokolu je nezbytné pro realizaci elektronického obchodu. Jako příklad uvádím: ţe server vyţaduje zadání čísla kreditní karty, aby mohl provést odpočet peněz z konta. Sestavení SSL spojení funguje na principu asymetrické šifry, kaţdá ze stran má dvojici šifrovacích klíčů – soukromý a veřejný. Pomocí veřejné části klíče

18

protistrany dokáţeme potvrdit, ţe cokoli zašifrované soukromou částí jeho klíče pochází přímo od něj. Také máme zajištěno, ţe cokoli zašifrujeme veřejnou částí klíče, rozšifruje pouze majitel jeho soukromé části.

2.2.2 Zabezpečení komunikací prostřednictvím SSH Server SSH umoţňuje nastavit pouţití šifrování pro kterýkoli pouţívaný TCP/IP port. Říká se tomu „tunelování přes SSH“. Klientská aplikace je stanovena na bázi, ţe aplikace pak nekomunikuje přímo se vzdáleným serverem, ale s místním proxy-serverem, který pomocí klienta SSH zajišťuje šifrování spojení na tomto portu. Tak lze bezpečně komunikovat s pouţitím jakékoli internetové sluţby. Sluţbu SSH standardně obsahují LINUX/UNIX operační systémy i systémy MacIntosh (Mac OS X). Do Windows lze podporu SSH doinstalovat jako produkt třetích stran.

2.2.3 Firewall Firewall je hardwarové nebo softwarové zařízení instalované na vstupní bráně do Internetu. Účinně odděluje lokální a veřejnou síť a kontroluje přenos dat mezi nimi. Z bezpečnostního hlediska to znamená: 1. Pracuje jako „škrtící místo“ – všechny data směřující z lokální sítě do Internetu nebo naopak musí tímto místem projít. Tady mohou být analyzována a podle bezpečnostních pravidel lze rozhodnout, zda mohou opustit síť nebo mohou být do sítě vpuštěny. 2. Firewall můţe zaznamenat statistické i konkrétní údaje o datech přes něho procházející. Ty pak mohou slouţit jako zdroj dat pro kontrolu funkčnosti bezpečnosti systému. 3. Omezuje nebezpečí průniku do sítě zvenčí, ze strany Internetu. Běţné typy firewallů nabízejí základní funkce pro zajištění bezpečnosti: a) Paketový filtr – jedná se o selektivní směrování IP paketů. Filtr registruje kaţdý paket, který přijde na firewall, chce přes něj projít a čte jeho hlavičku, kde je uvedeno na jakou adresu paket směřuje. Pakety jsou analyzovány na úrovni IP paketů. Dá se tak omezovat přístup lokálních uţivatelů na některé konkrétní www

19

servery nebo celé podsítě apod. Jsou známy případy, kdy konkurenční firmy vzájemně zakazují přístup na své servery apod. Tato opatření však nejsou příliš účinná, protoţe konkurent můţe nahlíţet na stránky z jiné, neţ obvyklé IP adresy, aniţ by byl identifikován. Pro firmy má tento filtr význam v tom, ţe omezuje přístup zaměstnanců na www servery. Firewally umoţní nastavení tzv. stavově závislé filtrace – tj. rozhodnutí o tom, jestli paket smí projít a to na základě existence/neexistence a obsahu paketů přicházejících na firewall v historii. Tato funkce omezuje přístup hackerům pro případné zneuţití nedokonalosti aplikačních protokolů. Výhodami paketového filtru jsou: 

vysoký výkon,



flexibilní konfigurace,



jednoduchost a spolehlivost implementace. [2]

Za nevýhody lze povaţovat: 

nemoţnost detailní konfigurace na aplikační úrovni,



nutnost dodatečného překladu adres. [2]

b) Aplikační brána – také filtr aplikačních protokolů. Na firewallu je pro kaţdý aplikační protokol vytvořena proxy brána. Klientský program (např. FTP) pro danou sluţbu tak nekomunikuje přímo se serverem na Internetu, ale pouze místní proxy bránou na firewallu. Ta prověří, zda jednotlivé poţadavky klienta jsou korektní a jednotlivé příkazy posílá skutečnému serveru na Internetu. Klientské aplikace nikdy nekomunikují se servery přímo, ale pouze s jednotlivými aplikačním proxy pro jednotlivé protokoly. Proxy brány tak obvykle neposílají do Internetu přímo IP adresy klientů lokální sítě, ale překládají všechny adresy v odcházejících paketech na jedinou „venkovní“ adresu. Při příchodu odpovědi z Internetu proxy opět vymění „venkovní“ IP adresu za adresu lokálního počítače, který sluţbu poţadoval. Řešení je bezpečné, protoţe celá síť pak z hlediska Internetu působí jako jediný počítač, a to sniţuje moţnost průniku do lokální sítě zvenčí. Princip zakrývání IP adres počítačů z vnitřní sítě nazýváme dynamický překlad IP adres.

20

Princip samotné aplikační brány spočívá v detailním nastavení průchodnosti proxy bran pro jednotlivé aplikační protokoly – např. pro HTTP můţeme nastavit, zda bude povolen průchod ActiveX apletů, u elektronické pošty můţe být povoleno zasílání připojených souborů, lze nastavit jejich maximální velikost, u FTP povolit/zakázat jednotlivé příkazy apod. Některé

aplikační

brány

umoţňují

provádět

antivirovou

kontrolou

procházejících dat např. souborů připojených ke zprávám k elektronické pošty, souborů staţených pomocí FTP nebo stránky HTTP. Základem kaţdého firewallu je kombinace paketového filtru a aplikačních bran. Výhody aplikační brány : a) Co není povoleno, je zakázáno. Sluţby, pro které neexistuje proxy brána, jsou automaticky zakázány. b) Umoţňují přesné nastavení filtrování obsahu paketů. c) Proxy umoţňují skrýt adresy počítačů ve vnitřní síti. d) Aplikační brány umoţňují vytváření velmi podrobných protokolů o jejich činnosti.

Nevýhody: a) Jednotlivé proxy mohou překladem adres zpomalovat průchodnost paketů. To můţe přivodit problémy např. u multimediálních aplikací, jako RealAudio/Video, MS NetShow apod. c) Zaznamenání běhových informací – záznamy událostí o datech, která firewallem prošla, pokoušela se projít a byla odmítnuta. Kopie protokolů mohou být automaticky odeslány administrátorům na jejich e-mail nebo si protokoly (logy) mohou přímo prohlíţet.

d) Autentizace uživatelů – i firewall potřebuje vědět, stejně jako kaţdý bezpečnostní systém, kdo po něm poţaduje jaké sluţby. Kritický je proces jeho nastavování, čtení a

21

mazání protokolu o událostech. Proto není výjimkou přihlašování prostřednictvím čipových karet, jednorázových S/Key hesel atd. e) Virtuální privátní síť a firewally - některé firewally jsou současně i VPN branou, nemusí to však být pravidlem.

2.2.4 Testování sítí Firewally jsou nástrojem pro zabezpečení informačních sítí proti útokům hackerů na lokální síť zvenku. Celková bezpečnost je dána jejich kvalitou, nastavením, ale také testovacími programy zranitelnosti systému. K nim patří např. program Nessus, který podává reporty o zranitelných místech (většinou zastaralé aplikace na serverech) a informace o počítačích v síti. Bohuţel ho ke zjišťování slabin pouţívají i hackeři, aby si usnadnili přístup do počítačové sítě. Dále pro detekci pokusů o průnik do sítě lze pouţít nějaký IDS (Intrusion Detection System). Jedná se o obranný systém, který monitoruje síťový provoz a snaţí se odhalit podezřelé aktivity. Příklady konkrétních produktů jsou např. Snort nebo Cisco Secure IDS.

2.3 Bezpečnostní audit Při zabezpečení všech komunikačních sítí organizace je zapotřebí provádět pravidelně se opakující akce, jejichţ smyslem je vyhodnocení funkčnosti zavedených bezpečnostních opatření – bezpečnostní audit. Jeho smyslem je posouzení celkové bezpečnosti na úrovni nových technologií, a tím i vzniklých zranitelných míst a hrozeb. V průběhu auditu jsou posouzeny všechny části informačního systému a nalezeny nedostatky a mezery v konstrukci způsobu jeho správy a pouţívání, které by do budoucna mohly mít za následek bezpečnostní incident. Většinou jsou audity: a) Pravidelné – prováděné jako prevence pro odhalení nových zranitelných míst a hrozeb. b) Mimořádné – prováděné na ţádost managementu, obvykle jako reakce na incident porušující bezpečnost organizace[2]

22

V průběhu auditu jsou samozřejmě zkoumány záznamy z historie provozu. Tímto způsobem je moţné odhalit, zda v minulosti nebyl proveden útok a v případě jeho zjištění ozřejmit, jakým způsobem. Audit provádějí pracovníci, kteří jsou nezávislí. Proto řada organizací ţádá o jeho vypracování některou z auditorských nebo odborných a specializovaných firem. Aby byl audit úspěšný, musí být auditorovi umoţněn přístup ke všem (i důvěrným) informacím. Proto je zapotřebí dodrţet následující čtyři body: 1.

Organizace zpracování dat – posuzuje se především oddělení jednotlivých fází nebo procesů (např. oddělení vývoje od provozu a uţivatelů).

2.

Kontrola dalšího rozvoje IS a jeho dokumentace – ověřuje se účast všech stran – od uţivatelů přes systémové analytiky aţ po bezpečnostní managery a auditory. Důraz je kladen na metodiku testování nového informačního systému a jeho zavedení do praxe.

3.

Kontrola přístupu – posuzuje se zabezpečení fyzického přístupu k hardware a programovému vybavení, datům a jejich zálohám i ke všem komunikacím.[2]

4.

Aplikační (procedurální a datové) kontroly – zkoumají další oblasti:

a) zabezpečení vstupu dat do systému b) zpracování dat c) výstup ze systému

2.3.1 Auditní záznamy Účelem a obsahem auditních záznamů je sledování jednotlivých akcí, které se v informačním systému staly. Záznamy mají velký význam pro vyhodnocování bezpečnostních incidentů a zjišťování jejich příčin, kdo je za incident odpovědný a jak se dá zjednat náprava, případně jaká nová opatření přijmout, aby se podobné situace nebo chyby nemohly opakovat. Kaţdý informační systém by měl uchovávat následující: a) datum a čas události, b) uţivatele, který byl k systému přihlášen,

23

c) počítač, ze kterého byla operace prováděna, d) provedená akce s co nejpodrobnějším popisem, e) úspěšnost provedené akce – sem je zapotřebí zaznamenat i provedené neúspěšné pokusy, např. přihlášení do systému. [2]

Přitom je zapotřebí váţně záznamy vyhodnotit, protoţe mají z hlediska zabezpečení informační techniky nejvyšší stupeň citlivosti. Mohlo by neoprávněnými uţivateli dojít k jejich zneuţití (manuální opravy, poškození záznamů). Pak by ztratily auditní záznamy svoji hodnotu a staly se zcela bezcenné. Auditní protokol se stává nástrojem kontroly práce administrátorů systémů. Systém rozeznává následující základní typy klientů: 1. Uživatel – pracovník s přístupem k definované části IS, která odpovídá jeho pracovní náplni. Operace, které smí uţivatel provádět by měly být protokolovány. 2. Administrátor – profesionální technik, která má výkonná práva pro nastavování a údrţbu systému. I jeho práce by měla být zapsána v protokolech a neměl by mít moţnost do nich zpětně zasahovat. 3. Auditor – uţivatel sice nemá výkonná práva, tj. nemůţe systém nastavovat, avšak jeho zásadním privilegiem je práce a analýza záznamů v AuditLogu. Auditoři by měli být přímo podřízeni nejvyššímu managementu společnosti, ve které je audit prováděn. [2]

24

3 Bezpečnostní rizika 3.1 Bezpečnostní politika informačních a telekomunikačních technologií „Bezpečnostní politika je základní východisko pro budování bezpečnosti informačního systému.“[1] Bezpečnostní politika organizace tvoří jeden ze základních pilířů, na kterém stojí celý systém řízení informační bezpečnosti. Její definice je jedním z nutných kroků. Pokud nejsou oficiálním způsobem jednoznačně definovány některé základní parametry, jako jsou např. povinnosti a odpovědnosti klíčových rolí a zaměstnanců organizace, můţe být následně celý systém budován chaoticky, neefektivně a neúčelně. Jen na pevných a stabilních základech můţe být vystavěn pevný a stabilní systém řízení. .

Bezpečnostní politika vymezuje základní bezpečnostní poţadavky a nařízení,

které mají zajistit ochranu a bezpečnost informací v organizacích. Přesně určuje rámec informační bezpečnosti organizace a je po schválení jejím vedením závazná pro všechny zaměstnance, ale i externí spolupracovníky, kteří mají moţnost kontaktu s ICT sluţbami dané organizace. Při jejím vyuţívání by se mělo vycházet z existujících a platných interních směrnic a směrů činnosti, které rozvíjí s ohledem na aplikovatelnost bezpečnostní dokumentace do prostředí organizace. Reflektuje závěry získané z analýzy rizik IS a definuje mechanismy zajišťující efektivní řízení informační bezpečnosti. Je podkladem pro budování niţších a specifických stupňů bezpečnostní dokumentace. Pro vypracování bezpečnostní politiky existuje několik různých přístupů. Obecně nejrozšířenější je vypracování bezpečnostní politiky v souladu s normou ISO/IEC 27001 Systémy managementu bezpečnosti informací a na základě ISO/IEC 27002 Informační technologie - Soubor postupů pro řízení informační

25

bezpečnosti. Tento přístup je moţné v současné době pokládat za jeden z nejlepších pohledů na řízení bezpečnosti ICT v organizaci.[4] Abychom správně v organizaci aplikovali bezpečnostní politiku, musíme zachovat určité principy jejího zpracování, které se dají formulovat následovně a tvoří společný základ: a) veškerých platných dokumentů organizace vztahujících se k bezpečnosti (BOZP, PO, apod.) nebo jiných nadřízených dokumentů; b) systémových bezpečnostních poţadavků; c) výsledků analýzy rizik; d) bezpečnostních

poţadavků

uvedených

v zákonech,

vyhláškách,

normách,

předpisech a standardech. Při samotné definici bezpečnostní politiky organizace (podniku) musíme nezbytně přihlíţet k dané legislativě, kterou vytvářejí: 

Zákon č. 102/1971 Sb. O ochraně státního tajemství a jeho novely č. 383/1990 Sb. a č. 558/1991 Sb.;



Zákon č. 140/1961 Sb., Trestní zákon;



Zákon č. 256/1992 Sb., O ochraně osobních údajů v informačních systémech;



Zákon č. 101/2000 Sb., O ochraně osobních údajů;



Zákon č. 127/2005 Sb., O elektronických komunikacích;



Zákon č. 121/2000 Sb., O právu autorském, o právech souvisejících s právem autorským (tzv. autorský zákon);



Zákon č. 227/2000 Sb., O elektronickém podpisu;



Zákon č. 480/2004 Sb., O některých sluţbách informační společnosti;



Vyhláška ÚOOÚ č. 366/2001 Sb. k zákonu o elektronickém podpisu;



další legislativa (vyhlášky, standardy atd.) MV ČR, ÚOOÚ, NBÚ apod. Základní strukturu bezpečnostní politiky představují:



stanovení účelu bezpečnostní politiky;

26



definice poţadované úrovně bezpečnosti;



definice zodpovědnosti za klasifikaci dat, zaměstnanců a přístupových práv (ve smyslu fyzickém i informačním);



definice zodpovědnosti jednotlivých článků organizační struktury při řízení bezpečnosti ICT;



normy chování zaměstnanců (včetně právních a etických aspektů);



havarijní plány a postupy při budování bezpečnosti ICT v obecné rovině;



definice úrovní zabezpečení a míry odolnosti v jednotlivých oblastech bezpečnosti (personální, organizační, technická atd.);



podmínky auditu

3.1.1 Proces a dokumentace bezpečnosti V rámci systému řízení informační bezpečnosti je třeba definovat a dokumentovat řadu základních bezpečnostních pravidel a procesů. Základními dokumenty jsou bezpečnostní politiky firmy (podniku), které definují strategii informační bezpečnosti a základní pravidla organizace. Další dokumenty upravují a upřesňují metodiku dílčích oblastí a procesů bezpečnosti. Navazující dokumentace popisuje procesy bezpečnosti zpracování informací a správy IS – stanovuje a definuje jednotlivé procesy, definuje role, jejich odpovědnosti a povinnosti při vykonávání potřebných procesů. Součástí základní bezpečnostní dokumentace (dokumentace procesů

bezpečnosti

informací)

můţe

být

mnoţina

několika

návazných

bezpečnostních dokumentů. Jejich rozdělení si organizace můţe definovat podle svých konkrétních (interních) potřeb následujícím způsobem:

27

Tabulka 1: http://www.aec.cz/cz/sluzby/procesy-a-dokumentace-bezpecnosti

3.1.2 Bezpečnostní projekt Pro efektivní ochranu počítačového systému a uloţených dat je zapotřebí vypracovat bezpečnostní projekt, který zajistí takový stav zařízení, aby práce na něm, riziko úniku dat a finanční prostředky k narušení bezpečnostního systému byly adekvátní v porovnání s hodnotou, která je bezpečnostním systémem chráněna.

28

3.1.2.1 Části bezpečnostního projektu Zabezpečení fyzického přístupu: spočívá v zabránění přístupu nepovolaných osob k počítačovému systému. Pro tento způsob ochrany se pouţívají bezpečnostní prvky, kterými nejčastěji jsou: a) přidělení rozdílných práv zaměstnancům; b) elektronické zámky, poplašná zařazení, kamerové systémy; c) autorizační systémy chráněné hesly, čipovými kartami; d) autentizační systémy na snímání otisků prstů, dlaně, oční duhovky, rozpoznání hlasu; e) auditovací systémy na sledování a zaznamenávání určitých akcií zaměstnanců (vstup zaměstnanců do místnosti, přihlášení se do systému, kopírování údajů apod.).

3.1.2.2 Zabezpečení počítačového systému Zabezpečení počítačového systému se většinou vyuţívá proti útokům crackerů - škodlivých programů (vir, červ, trojský kůň, spyware, adware apod.) Do této problematiky můţeme zařadit školení zaměstnanců, kteří jsou povinni chovat se při vyuţívání počítačů v souladu s jejich bezpečností a dodrţováním zásad bezpečného pouţívání počítačové sítě.

3.1.2.3 Zabezpečení informací Zabezpečení informací spočívá v bezpečném zálohování dat. To by mělo být provedeno takovým způsobem, aby nemohlo nastat jejich ohroţení přímým útokem (zaměstnanci, externí spolupracovníci, hackeři) nebo přírodní katastrofou (poţár, povodně apod.). Zálohovaná data je dobré, pro větší jistotu, chránit proti neoprávněné manipulaci vyuţitím vhodného šifrovacího systému.

29

3.1.2.4 Ekonomické a právní zabezpečení Ekonomické a právní zabezpečení vychází ze správné motivace, ale také případného postihu zaměstnanců (spolupracovníků firmy nebo organizace).

3.1.3 Bezpečnostní dekompozice informačního systému Pro pochopení informační bezpečnosti je důleţité poznat, jakou roli (z hlediska ochrany) mají jednotlivé její části. Kaţdý informační systém se skládá z několika základních – standardních částí. Ty rozdělujeme na: a) datovou; b) programovou; c) technickou; d) komunikační; e) osoby, které systém vyuţívají. Obecně platí pravidlo: Bezpečnost informačního systému je taková, jaká je bezpečnost jeho nejslabší části.[1] Nevyplácí se proto zabezpečit operační systémy, ale přitom nevěnovat pozornost ochraně komunikačních cest. Nejobecnějším je dělení informační bezpečnosti na vnější a vnitřní. Vnější bezpečnosti se týkají opatření, která informační systém nedokáţe zajistit sám sobě. Vnitřní opatření jsou části systému ochrany dat, programového a technického vybavení (software, hardware). Mezi vnější a vnitřní bezpečností je přesně definovaná hranice informačního systému. Uvnitř této hranice je implicitně vše chráněno. Mimo ni je vše nechráněno. Proto je zapotřebí najít vhodný kompromis a přesně definovat hranice, po které se informační systém zabezpečí. Téměř vţdy je hranice mezi interní a externí bezpečností. Systém leţící uvnitř interní bezpečnosti se dá rozdělit na části: která vynucuje a udrţuje bezpečnostní úroveň a v níţ leţí vše ostatní v rámci informačního systému (uţivatelské programy, tiskárny apod.).

30

Pomyslná hranice mezi těmito částmi se nazývá bezpečnostní perimetr (Security Perimeter).[1] Bezpečnostní perimetr je bezpečnostní omezená oblast, ve které jsou v činnosti a platnosti objekty, které vynucují a udrţují poţadovanou bezpečnostní úroveň a kontrolní opatření za účelem ochrany hodnot. To co leţí uvnitř něho, je podstatná část, na které stojí bezpečnost konkrétního informačního systému. Zjednodušeně se dá říci, ţe perimetr je vytvořen z několika vrstev, jejichţ část leţí uvnitř něho. Např. se jedná o hardware a operační systém (zabezpečený) a zabezpečené systémy řízení databáze. Operační systém, který má aspoň minimální bezpečnostní vlastnost, obsahuje zpravidla modul (Trusted Computer Base – TCB), který má za úkol v rámci operačního systému spravovat bezpečnost.

Informační bezpečnost

interní

externí

komunikační bezpečnost

fyzická bezpečnost

datová bezpečnost

personální bezpečnost

programová bezpečnost

reţimová bezpečnost

Tabulka 2.: DOBDA, L. Ochrana dat v informačních systémech, s. 80

31

3.1.3.1 Faktory informační bezpečnosti V této podkapitole bych se podrobněji zabýval některými aspekty, které jsem představil v předcházejí kapitole 2.2 Bezpečnostní projekt, z toho důvodu, ţe obě části mezi sebou úzce souvisejí. Fyzická bezpečnost (Physical Security) – jedná se o opatření, která jsou pouţita k zajištění fyzické ochrany aktiv proti náhodným a úmyslným hrozbám. K tomu jsou vyuţity technické prostředky ochrany. Celý informační systém je umístěn v určitém fyzickém prostředí – budovy, místnosti. Úkolem fyzické bezpečnosti je jejich zabezpečení a ochrana vlastního informačního systému před přírodními vlivy, neoprávněnému vniknutí, bezpečným uloţením datových nosičů s informacemi, tiskových výstupů, způsoby likvidace nepotřebných informací a médií, jejich ochranou proti poţárům apod. Součástí těchto opatření je také dodávka stabilizované elektrické energie. Personální bezpečnost (Personnel security) – se zabývá eliminací hrozeb způsobených lidským faktorem. Jedná se o ochranu pracovníků jako nedílné součásti informačního systému a zároveň ochrana systému před jejich nedovoleným jednáním. Mimo jiné personální ochrana zahrnuje prověřování pracovníků a udělování práv zaměstnancům, kteří jsou seznamováni s citlivými informacemi, včetně jejich odborné způsobilosti, kterou zajišťují pravidelná školení. Režimová bezpečnost (Procedural Security) – prosazuje respektování právních norem a zákonů (mezinárodních a národních), které se týkají provozu informačního systému, bezpečnostních standardů a interních směrnic a pravidel (bezpečnostních směrnic) stanovených pro výstavbu a provoz informačních systémů. V podstatě se jedná o komplex administrativních opatření a systém kontrol zajištění bezpečnosti systému. Technická bezpečnost (Technical Security) – řeší ochranu dat pouţitím odpovídajícího technického vybavení – jeho kvalitním výběrem a zajištěním potřebné spolehlivosti a servisních sluţeb. Řadíme sem i ochranu technických prostředků před elektromagnetickým vyzařováním.

32

Programová bezpečnost (Program Security) – bezpečnost programového vybavení, především operačních systémů, systémů řízení databází a aplikačních programů; jeho výběr podle poţadovaných bezpečnostních kvalit a pracovní spolehlivosti. Mimo jiné sem patří dodrţování licenčních podmínek a kontrola přístupu k programům. Datová bezpečnost (Data Security) – ochrana dat v souborech a databázích proti neoprávněnému cizímu zásahu, poškození nebo ztrátě, antivirovou ochranu a kontrolu přístupu k datům. Komunikační bezpečnost (Communications Security) – řeší problematiku ochrany komunikačních cest mezi jednotlivými komponenty informačního systému. Definuje způsoby zajištění důvěrnosti a integrity přenosu dat po nich.[1]

3.1.4 Personální bezpečnost Lidský faktor převaţuje ve všech činnostech. Je proto zapotřebí eliminovat s určitostí všechny negativní dopady lidského jednání na bezpečnost informační techniky. Největším nebezpečím, které můţe napadnout komunikační techniku zaměstnavatelů, jsou jeho neloajální zaměstnanci. Pracovník, jehoţ zájmy nejsou stejné se zájmy zaměstnavatele, představuje vţdy potencionální hrozbu. Kapitolu o personální bezpečnosti např. uvádí Luboš Dobda mottem: „Lidské jednání se dá jen těžko odhadnout.“[1] Proto řada majitelů informačních systémů nelituje finančních prostředků a vkládá je do zajištění technických a programových bezpečnostních opatření, která by zamezila zaměstnancům jakékoliv ohroţení bezpečnosti informačních systémů. K jejich poškození totiţ můţe dojít záměrně (krádeţ, pomsta, zlomyslnost, vidina zisku z konkurenčního prostředí) nebo neúmyslně – nevhodně zmáčknutá klávesa „delete“. I pouhým omylem můţe málo opatrný nebo špatně proškolený pracovník připravit svého zaměstnavatele o důleţitá data. O selhání lidského faktoru se dozvídáme dnes a denně z hromadných sdělovacích prostředků. Varováním pro nás mohou být věty volně pouţívané novináři např.: „…ze zdrojů, které si nepřejí být uvedeny; …blízký spolupracovník ministra,

33

který si nepřál být jmenován; …dobře informovaný zdroj nám potvrdil…“. Lidé jsou jedním z článků informačního systému, a proto i jim je zapotřebí věnovat dostatečnou pozornost, protoţe nikdy nevíme, co mohou svým jednáním způsobit za škody. Ochranu informačního systému před neţádoucím vlivem lidského faktoru zajišťuje personální bezpečnost. Druhy personálních hrozeb jsou následující: - Neoprávněná úprava vlastních přístupových práv ke zdrojům informačního systému. - Neoprávněná úprava přístupových práv jiných zaměstnanců organizace. - Záměrné nebo nechtěné poškození dat - jejich vymazání, změna hodnot, přidání nových údajů, nebo nenávratná „likvidace“ starých údajů. - Úprava konfigurace – nastavení některé části nebo celého informačního systému. - Nedodrţování stanovených bezpečnostních předpisů, a to jednak záměrné nebo i z neznalosti. - Nelegální instalace vlastních programů a jejich vyuţívání (např. počítačové hry). Proto by se měli personalisté velkých, ale i menších firem zabývat tzv. ţivotním cyklem podřízených (personálu). Ten se dá rozdělit do čtyř základních etap. 1. Výběr nových zaměstnanců na základě předem definovaných poţadavků. 2. Základní příprava a zaškolení nových pracovníků. 3. Průběţné zkvalitňování personálu. 4. Ukončení pracovního poměru a odchod z pracoviště. Především výběr nových spolupracovníků je jedním ze základních předpokladů zvyšování kvality zaměstnaneckého personálu. Významným kritériem (vedle znalostí a schopností) by měly být jejich morálně-volní, osobní a pracovní vlastnosti (uvědomělost, spolehlivost, poctivost, psychická odolnost, dobré rodinné zázemí apod.). Jejich odborné znalosti a dovednosti zcela spolehlivě prověří ústní nebo písemné testy. Velký význam pro nového zaměstnavatele mohou mít i reference z předcházejících zaměstnání nových adeptů. V poslední době vyţadují někteří zaměstnavatelé vyplňování dotazníku vlastní rukou (ne psacím strojem nebo na PC). I písmo můţe odhalit, co se uvnitř člověka skrývá, pokud ho prostuduje grafolog (znalec písma) a podle něho můţe stanovit docela přesnou charakteristiku člověka.

34

Nejpřísnějším kritériím by měl být podroben nový adept, jehoţ pracovní zařazení mu umoţní osobní kontakt s citlivými daty. Při přijímání nových pracovníků by bylo vhodné poţadovat výpis z rejstříku trestů a podrobit je testům na uţívání drog nebo alkoholu. Přijatý zaměstnanec je ihned po nástupu seznámen s bezpečnostními předpisy organizace, kam patří i práce s důvěrnými informacemi apod. Absolvování školení (poučení) by měl stvrdit vlastnoručním podpisem. Důleţité je i zapracování v nové funkci formou odborného školení nebo samostudia. Nově přijatý pracovník by měl mít zpočátku omezený přístup k „citlivým“ informacím organizace a teprve po získání důvěry na pracovišti by se mělo jeho bezpečnostní oprávnění postupně zvyšovat. Bezpečnostní kvalita zaměstnanců se dosahuje pravidelným tréninkem, kontrolou dodrţování bezpečnostních poţadavků a směrnic a školeními. Důleţitou součástí je zjišťování příčin negativního jednání pracovníků a jejich analýza a postupné zpracování závěrů, případně vyvození důsledků. Ta by společně měla negativnímu jednání v budoucnu zamezit. Kvalitně zaškolený a vycvičený personál je zapotřebí si udrţet, protoţe čas a námaha vloţená do jeho zkvalitňování je velmi pozitivní investicí organizace. Proto je třeba – z hlediska psychologického – vytvářet u zaměstnanců pocit sounáleţitosti s organizací, pocit jejich důleţitosti, hmotně i morálně je stimulovat, vytvořit jim pozitivní pracovní perspektivu a umoţnit další růst. Pracovníky, kteří jsou zaměstnáni na důleţitých postech informačního systému je zapotřebí sledovat a to nejen na pracovišti, ale částečně se informovat i o jejich soukromém ţivotě. Je vhodné vést podrobné informace o jejich přístupu k financím – náročných zálibách (hazard, drogy, sex apod.). Neobvyklých změnách v chování a jejich příčinách. O nenadálých změnách majetkových poměrů apod. V případě, ţe dojde ke ztrátě důvěry vůči pracovníkovi z jakýchkoliv důvodů a pohnutek, je lepší takového zaměstnance propustit. Bohuţel je takové rozhodnutí nepopulární, mnohdy sporné a tvrdé, ale pokud by měl organizaci škodit, bude lepší se s ním opravdu rozloučit.

35

Přitom je potřeba mít na zřeteli, ţe si dobře vyškolený zaměstnanec s sebou odnáší své „duševní vlastnictví“, které mnohdy tvoří citlivé a tajné informace organizace. Navíc si musíme uvědomit skutečnost, ţe nad jeho budoucností ztratíme jakoukoliv kontrolu. Proto by měl být kaţdý odcházející poučen o svých povinnostech vůči bývalému zaměstnavateli, často bývají kladeny poţadavky mlčenlivosti po určitou dobu po jeho odchodu ze zaměstnání. Záznam o poučení by měl odcházející pracovník opět stvrdit vlastnoručním podpisem.

3.1.4.1 Podpora uživatelů Abychom

nevypadali

jako

špatní

zaměstnavatelé,

musíme

svým

zaměstnancům vytvořit dobré pracovní podmínky a dát jim moţnosti rozvoje a podporovat všemi směry jejich pracovní činnost. K tomu lze zařadit i informační podporu uživatelů našeho informačního systému. Poměrně naivní představa je, ţe všechno bude fungovat bez problémů. V kaţdé organizaci však můţe dojít k selhání technického i lidského faktoru. Abychom mohli pracovat bez poruch a problémů, musíme vytvořit přijatelný „servisní“ systém, který dokáţe zaznamenat, vyhodnotit problémy, navrhnout jejich co nejrychlejší a nejúčinnější odstranění, případně odstranit škody nebo udělat taková protiopatření, aby se v budoucnu neopakovaly. Takový přístup nazýváme informační podpora uţivatelů a jedná se o informační a organizační strukturu schopnou poskytovat podporu koncovým uţivatelům informačního systému a zajistit součinnost všech servisních subjektů při řešení jakýchkoliv problémů s údrţbou software nebo hardware. Informační podporu můţeme rozdělit do dvou částí: 1. Systém lokální podpory (tzv. Helpdesk). 2. Systém sdílených informací. Lokální helpdesk pomáhá řešit kaţdodenní problémy uţivatelů s provozem informačních systémů a eviduje a zpracovává jejich poţadavky. Rovněţ zaznamenává

36

hlášení problémů předaných k řešení servisním subjektů – dodavatelům. To znamená, ţe helpdesk plní tyto funkce: 1. Podporu

koncových

uţivatelů

v oblasti

aplikačního

a

systémového

programového vybavení. 2. Eskalaci nevyřešených problémů vyššímu stupni podpory. 3. Shromaţďování podnětů pro odstranění chyb v aplikacích (vytvořených lokálním vývojovým týmem). 4. Monitorování a spravování výkazů činnosti helpdesku. Systém sdílení informací je informační databankou vyřešených problémů (druh a způsob řešení problému) a diskusním fórem k řešení tematických otázek (např. i na Internetu). V diskusních fórech by se ovšem měly řešit nepříliš urgentní problémy a sdílet zkušenosti s provozem informačního systému. Pro potřeby uţivatelské podpory existují speciální programy, zaměřené na centralizované řízení této problematiky. Zpravidla řeší: 1. Logování a řešení chyb v rámci informačního systému. 2. Vytváření a udrţování informační základny informačního systému – přehled pracovišť, jejich vybavení nutné pro výchozí informace při rozhodovací činnosti administrátora – obsahuje údaje o instalovaném software a hardware, telefonní čísla, adresy, jména uţivatelů a odpovědných pracovníků, konfigurační parametry apod. 3. Znalostní báze – resp. databáze, která zaznamenává historii a způsob řešení známých problémů jak obecného, tak typického charakteru pro daný informační systém.[1]

3.1.4.2 Režimová bezpečnost Komplex administrativních opatření, nařízení a systém kontrol tvoří tzv. reţimovou bezpečnost informačního systému. Pomocí nich se prosazuje respektování právních norem a zákonů (mezinárodních, národních), bezpečnostních standardů, normativů v provozu informačního systému. Dodrţování všech stanovených zásad je

37

důleţitým a rozhodným kritériem při posuzování charakteru vzniklých škod, určování viníků, míry jejich zavinění, případně vyvozených trestně právních následků za porušení bezpečnosti práce, resp. bezpečnosti informačního systému. Reţimovou bezpečnost tvoří základní procedury: 1. Procedury definující reţim vstupu do objektů a místností a způsoby kontroly. Vedení přehledu o přítomnosti osob v objektech a vyhrazených prostorech. 2. Metodika výběru a prověřování osob pro výkon funkcí na citlivých úsecích. 3. Definice oprávněných a zakázaných činností uţivatelů informačního systému, kontrola přístupu k jednotlivým zařízením a rozsah oprávnění pro manipulaci s nimi. 4. Pouţití kryptografické ochrany. Metody generování šifrovacích klíčů a jejich distribuce, uloţení a likvidace. 5. Procedury způsobu označování a evidence médií. Postupy při ničení médií. 6. Způsoby bezpečného zálohování dat a uloţení záloţních a archivních médií. 7. Postup připojení nového počítače do informačního systému. 8. Postup při zřízení nového uţivatelského účtu – kdo je povoluje, atd. 9. Postup při rušení uţivatelského účtu – kdo je oznamuje a komu. 10. Metodika nastavení přístupových práv. 11. Postup přihlášení a odhlášení se k systému. 12. Postup při odchodu z pracoviště (např. zamknutí obrazovky). 13. Způsoby testování poţadovaných bezpečnostních parametrů. Pokud se vyskytne nějaký bezpečnostní incident, připravená IT skupina pracovníků nepodléhá panice a v klidu ho řeší. Často však opak bývá pravdou a to v tom momentě, kdy nejsou zpracovány potřebné materiály a doporučení, podle kterých by se měla organizace řídit v případě této nepříjemné situace. Určitě by měly být zpracovány základní postupy a pravidla řešení bezpečnostního incidentu podle následujícího scénáře: a) podezření na napadení informačního systému je nutné ihned hlásit; b) všechny inkriminované účty musejí okamţitě změnit heslo;

38

c) provést kontrolu všech účtů jestli jsou oprávněné a zda se nevyskytují nějaké navíc (tzv. černá duše); d) provést kontrolu nastavení přístupových práv a systémové politiky; e) provést kontrolu bezpečnostních vztahů mezi doménami; f) provést přejmenování účtů s právy administrace.[1]

3.1.4.3 Technická bezpečnost Ochranu dat za pouţití odpovídajícího vybavení řeší tzv. technická bezpečnost. Technickou bezpečnost však zároveň chápeme jako zajištění dostupnosti a integrity, to znamená neporušenost informací. V případě, ţe budeme potřebovat bezpečně odstranit problémy na firemním informačním systému a nemáme dostatečně technicky a znalostmi vybavené IT odborníky, je mnohem vhodnější zajistit tento servis některou ze zkušených servisních organizací, které se problematikou bezpečnosti a ochrany dat, technických vybavení a správou komunikačních cest profesionálně zabývají. Tento problém dál rozvádím i v praktické části této diplomové práce.

3.1.5 Nebezpečí na komunikačních sítích Všechny počítačové komunikace mají své specifické vlastnosti, z nichţ logicky musí vycházet i specifické zdroje bezpečnostních problémů. Pro úplnost této kapitoly uvádím výběr podstatných: Sdílení objektů – hlavně lokální počítačové sítě umoţňují skupinové sdílení adresářů a souborů umístěných na souborových serverech (File Server). Kaţdý uţivatel, který s nimi pracuje, můţe dodrţovat jiné bezpečnostní chování a provozovat tak na svém počítači jinak zabezpečený operační systém. Technologická složitost – komunikační síť má zpravidla jeden nebo i několik různých druhů operačních systémů. Ty společně komunikují prostřednictvím spojovacího mechanismu. Ten by měl, kromě obecných úloh, současně zajišťovat ochranu sítě.

39

Neznámý bezpečnostní perimetr – nelze přesně určit, kdo všechno je ke komunikační infrastruktuře připojen a jak se chová. Neznámá přenosová trasa – nelze zpravidla ovlivnit jednoznačně přenosovou trasu, po které budeme data přenášet. Neexistuje přesná informace o tom, kdo můţe při přenosu dat informace získat. Množství zranitelných míst – sloţitost zabezpečení je přímo úměrná rozsahu informačního systému a různorodosti jeho technologií. Útoky na komunikační sítě lze dělit podle cíle útoku na dvě skupiny: 1. Útok proti správné funkcionalitě komunikačního subsystému nebo jeho části. 2. Útok proti informačnímu systému napojenému na komunikační subsystém. Přitom se potenciální útočník snaţí vţdy najít a vyuţít, vyplývající z logických důvodů, nejslabší místa komunikační sítě: a) Neznalost nebo nedodržování zásad ochrany informací jejich uţivateli. b) Slabiny autentizačních procedur. Např. přihlašování uţivatele pomocí hesla se dá v síťovém prostředí lehce napadnout. Heslo můţe vygenerovat ze sítě v databázi uloţené sekvence hesel. c) Bezpečnostní nedostatky kaţdé komunikační technologie. Proto můţeme uvést, ţe bezpečnost počítačové sítě závisí na pouţitém přenosovém médiu. Útoky proti komunikačním cestám pak mohou být pasivní (odposlech komunikace) nebo aktivní (vkládání dalších informací do komunikace).

3.1.5.1 Typické útoky na počítačové sítě Pasivní odposlech („napíchnutí“, wiretaping) – odposlechnutí informace a pouţití ve vlastní prospěch. Patří k nejstarším a klasickým útokům na jakýkoliv informační systém. Nejvíce jím mohou být postiţeny pevné komunikační linky (ovšem v době mobilních telefonů není problém provést „napíchnutí“ i u nich).

40

V tomto případě je zapotřebí přenášené informace chránit šifrováním; technickou ochranu mohou poskytnout kabely s omezeným vyzařováním nebo zařízení, která detekují připojení odposlouchávacího zařízení. Vkládání falešných informací – zasílání klamných a zavádějících informací po síti, takţe se příjemce domnívá, ţe jsou věrohodné a platné. (Mohou tak být vysílány poštovní zprávy pod falešnou poštovní adresou). Vkládání starých zpráv a informací – jediný rozdíl oproti předchozímu odstavci je v tom, ţe útočník falešné informace uměle negeneruje. Posílá do komunikačního kanálu ty, které na něm dříve zachytil a zachoval. (Např. tak můţe docházet k bankovnímu převodu dané finanční částky i několikrát za sebou, samozřejmě na jiné konto). Ochranou proti této metodě je pouţití tzv. časových razítek – potvrzení, kdy byl datový blok vyslán nebo identifikačních příznaků – tokenů, které mají omezenou časovou platnost. Příjemce zprávy pak má moţnost porovnat čas přijetí informace s časem odeslání a zkontrolovat a potvrdit si, zda jsou uvedená data korektní. Změna informace v průběhu přenosu – mnohem nebezpečnější neţ předchozí uvedený případ je modifikace zasílané informace v průběhu jejího přenosu. Všechny atributy jsou stejné s jediným rozdílem, ţe namísto paralelního připojení ke komunikačnímu kanálu musí útočník kanál přerušit a přidat do něho svoje zařízení, které v reálném čase můţe identifikovat procházející datové bloky a podle svých potřeb pak můţe měnit jejich obsah. Vymazání přenášené informace – tímto útokem můţe příjemce přijít o důleţitou skupinu informací. Bohuţel tento způsob útoku můţe dokonce napadnout komunikační sítě, po nichţ jsou informace přenášeny. Zadržení a zpoždění informace – k tomuto útoku můţe dojít v průběhu přenosu a je velmi nebezpečný pro systémy, které pracují v reálném čase. Tyto systémy vyţadují informace, které přenášejí, aby byly přeneseny v určité a přesné časové posloupnosti. Přerušení komunikace – patří k základním typům útoků na komunikační systém. Útok hlavně ohrozí ty komunikační sítě, které nemají náhradní způsob přenosu informací pomocí alternativních komunikačních kanálů. Efektivita útoku

41

spočívá v tom, ţe je kanál přerušen v okamţiku, kdy je informace vysílána a kdy ji příjemce nejvíce potřebuje. K přerušení komunikace dochází nejčastěji třemi způsoby: fyzické přerušení – útočník má znalosti u lokálních sítí a moţnost přímého přístupu ke komunikačním trasám (např. vlastní zaměstnanec). Pokud chce vstoupit zvenčí, musí překonat fyzické zábrany (lupič); zahlcení – přetíţení komunikačního kanálu, kdy útočník pomocí „nesmyslných zpráv“ zcela „ucpe“ komunikační cesty (konkurence); změna komunikační trasy – útočník (konkurence) upraví nastavení předdefinovaných komunikačních cest, takţe se odeslaný blok vůbec nedostane k příjemci nebo ho získá se značným zpoţděním, takţe pro něho ztratí svoji hodnotu. Útok na koncovou stanici - i kdyţ koncové stanice nejsou zařazovány do komunikačního subsystému, protoţe představují nástroje administrace a uţivatelské rozhraní do informačního systému, mohou v případě napadení sehrát významnou roli při ochraně komunikačního subsystému nebo jeho napadení. Pokud útočník pronikne do koncové stanice, můţe odtud získat konkrétní data nebo stanici můţe pouţít, aby zaútočil na kompletní informační systém. Sledování zátěže sítě – poměrně netypickým druhem útoku je sledování zátěţe komunikačních cest, podle kterých můţe útočník zjistit, ve kterém místě informačního systému má zaútočit. Útočník dlouhodobě zachycuje veškerou komunikaci na komunikačním kanále a provádí rozbor situace. Postupně zjišťuje, kdo a s kým komunikuje a jak je komunikace častá. V tomto případě provádí analýzu zátěţe sítě. Z náhlých změn můţe vyvozovat potřebné závěry. Ochranou je uţití generátoru tzv. vycpávací zátěţe kanálu. Ten vysílá náhodné zprávy v době, kdy kanál není zatíţen a kdy nedochází ke skutečné komunikaci. Útočník proto nezíská věrohodné údaje o zátěţi kanálu. Útok prostřednictvím komunikačního protokolu – jeden z nejběţnějších druhů útoku z veřejné komunikační sítě. Útočník při něm vyuţívá nízkou bezpečnost komunikačního protokolu. Útok prostřednictvím elektronické pošty – spuštěním přiloţených souborů dat a spustitelných programů v e-mailové poště si můţeme „zavirovat“ počítač.[1]

42

3.1.5.2 Ochrana a způsoby zabezpečení informačních sítí Komunikační síť se skládá z několika subsystémů, které mají svoje specifické úkoly. V základním pojetí splňují minimálně tři: komunikaci, administraci a bezpečnost. Bezpečnostní subsystém by měl pracovat samostatně, nezávisle na dalších komponentech, aby ho případná porucha jiného technického vybavení nevyřadila z provozu. Tím by přestal zcela plnit svoji bezpečnostní funkci. I v prostředí komunikačních sítí platí bezpečnostní zásady a principy, protoţe stačí narušit jeden prvek komunikační sítě a u většiny technologií by mohlo dojít k narušení celé bezpečnostní sítě. Proto i tady platí heslo:

bezpečnost

komunikačního systému odpovídá bezpečnosti jeho nejslabšího článku. Kaţdý produkt celku, kterým je komunikační systém, by měl splňovat minimální bezpečnostní úroveň. Předmětem ochrany komunikačních systémů jsou tyto části: Zdroje sítě – především uţivatelské systémy, které jsou chráněny proti nelegálním průnikům za pomoci komunikačního média nebo vlastní komunikační infrastrukturou. Vzájemné relace – vyţadují zajištění věrohodné identifikace a autentizace; zajištění a utajení přenášených dat. Informace a data – ty obsahují datové soubory a programy. Proto je vyţadována integrita a důvěryhodnost přenášené informace.

43

3.1.5.3 Standard ISO bezpečnostní služby Standard ISO 7498-21 Security Architekture definuje základní bezpečnostní sluţby, které

jsou vyţadovány pro

komunikační sítě.

Tyto mohou být

implementovány v různých vrstvách referenčního modelu ISO/OSI. Autentizace komunikujících entit – nastává při navázání spojení a prověřuje, jestli je komunikující partner tím, za koho se vydává. Bohuţel výsledek platí pouze v okamţiku autentizace. Autentizace datového zdroje – prověří odesilatele dat, ale nemůţe zabránit modifikaci datového bloku. Autentizace spojení – dochází k ní během celého spojení a tak je zabráněno, aby mohl být měněn obsah zpráv. Řízení přístupu – úkolem je zamezit neoprávněnému pouţití prostředků dostupných v rámci sítě. Sluţba však není součástí síťových protokolů. Uplatňuje se aţ jako bezpečnostní vlastnost operačního systému nebo aplikačního vybavení. Zajištění důvěrnosti – ochrana přenášených informací před neoprávněným přístupem. Základním nástrojem je kódování a šifrování. Zajištění integrity – ochrana přenášených informací před neoprávněnou změnou, tzn. modifikací. Neodmítnutí zodpovědnosti – odesilatel nesmí odmítat zodpovědnost za odeslanou zprávu a současně příjemce potvrzuje, ţe informaci obdrţel v pořádku. Tato zásada platí i v opačné variantě – neodmítnutí příjemce vůči odesilateli s tím, ţe odesilatel potvrdí a prokáţe příjemci, ţe zprávu odeslal.

1

Termín ISO není akronym, jedná se o pojem odvozený z řeckého slova isos (rovný, stejný), akronym IOS nemá ţádný význam. Zdroj: International Organization for Standardization (ISO) Mezinárodní organizace pro standardizaci. www.fi.muni.cz/usr/staudek/vystavelova/index.html#obsah

44

3.1.6 Základní metody ochrany komunikací Jediným cílem následujících metod je dosáhnout takového stavu, aby byly bezpečné všechny komunikační cesty sítě, aby se na nich nedaly provádět odposlech, jejich přerušení nebo jiným způsobem zjistit obsah přenášených informací (dat). Protoţe komunikace není pouze lokálního charakteru a můţeme ji směle nazývat celosvětovou, všechny dálkové spoje musíme současně povaţovat za absolutně nebezpečné. Lokální sítě je moţno zabezpečit několika způsoby: Ochrana komunikačních portů (Port protection) – dochází při ní k zablokování moţnosti pouţití prázdných síťových zásuvek síťového rozvodu. Jedná se o doplňkovou ochranu mechanismu autentizace uţivatele koncové stanice. Řízení připojení do sítě – zabraňuje, aby se kdokoliv do ní připojil bez vědomí správce sítě. Např. přípojky k počítačové síti nejsou umísťovány do veřejně přístupných prostor. Zabezpečení kabelových spojů – zabraňuje, aby se na tyto spoje mohl někdo neoprávněně připojit. Kabeláţ je nedostupně umístěna např. v trubkách, ve zdi apod. Zamezení elektromagnetického vyzařování – kabely musí být opatřeny vhodným stíněním.

3.1.6.1 Řízení směru toku dat Komunikační trasy pro chráněná data jsou nastaveny tak, ţe definujeme cesty, po kterých mohou procházet a kterým důvěřujeme. Současně jsou zakázány toky, kterými nesmí být informace propouštěny. Technologie řízení tras se uskutečňuje za pomoci síťových prvků – směrovači (routers), mosty (bridges) nebo přepínači (switches). Při předávání paketů ze sítě do sítě směrovače povolují průchod pouze podle předem definovaných pravidel. Např. se filtruje na základě adresy odesilatele/příjemce a typu paketu. Pokud jsou tyto zabezpečovače vyuţity mezi vnitřní - firemní a vnější – veřejnou sítí, označují se jako firewall. Ty nekontrolují komunikaci uvnitř sítě, ale řídí tok dat s vnějším prostředím. Bohuţel tento typ ochrany nezabrání odposlechu nebo modifikaci v průběhu přenosu.

45

Dalším typem ochrany toku dat jsou dvoubodové spoje. Z pohledu bezpečnosti jsou nejvýhodnější, protoţe u terminálových sítí se ke kaţdému terminálu přenášejí pouze data pro něj určená. Pokud je síť napadena odposlechem, nelze zjistit víc o informacích posílaných na další terminály. Vícebodové spoje – těmi je v současné době zabezpečena většina sítí. Informace vysílané z jednoho uzlu sítě mohou zachytit i všechny ostatní síťové uzly. Bohuţel pro odposlech je to velmi „výhodné“. To platí v případě, ţe jako centrální bod ve hvězdicové topologii (v současnosti nejrozšířenější topologie lokálních sítí) by byl pouţit rozbočovač (hub). To ovšem dnes uţ prakticky nehrozí, protoţe rozbočovače byly plně nahrazeny přepínači, které na základě cílové síťové adresy posílají paket pouze tam, kde je jeho příjemce; tedy neplatí, ţe jakoukoli komunikaci mohou zachytit i všechny ostatní síťové uzly. Přepínače si ve své paměti udrţují tabulku síťových adres, kterou plní na základě procházejících paketů, ukládají si jejich zdrojovou síťovou adresu. I zde však existuje moţnost útoku, lze tuto tabulku různými technikami přeplnit (arp poisoning) a přepínač se začne chovat jako rozbočovač a posílat pakety do všech směrů, kromě zdrojového. Kryptografická ochrana – základním mechanismem je šifrování, které zabezpečí tři faktory: důvěryhodnost, integritu a autentizaci. Tento druh ochrany se dá aplikovat do všech oblastí komunikace. V tomto ohledu jsme sami sobě hodně dluţni. S rozvojem kryptografie budou muset dříve či později začít všechny organizace, které prozatím nevzaly na vědomí, ţe v komunikaci dochází ke stále větší globalizaci. Nejdříve by měl být kryptograficky ošetřen hardware a automaticky by se měly distribuovat šifrovací klíče. Provozovatelé takto ochráněných IT pracovišť, sítí atd. by měli počítat s tím, ţe šifrovací klíče nelze pouze rozeslat, ale také provádět jejich správu a certifikaci pro jejich ověřování.[1]

3.2 Doporučení při prosazování otázek bezpečnosti IS Při prosazování otázek BIS je zapotřebí mít absolutní podporu vedení společnosti (firmy). To musí přímo řídit jednu pověřenou osobu starající se o celou firemní „bezpečnost“. Bezpečnost v tomto případě neznamená pouze nákup hardware

46

a software a jejich pouţití, ale také zpracování potřebných směrnic a předpisů. Důleţitou roli u pověřené osoby sehrává i práce s lidským faktorem, kde je zapotřebí mnohdy změnit (a to je to nejtěţší) myšlení zaměstnanců. Nedá se dosáhnout změn v organizaci, pokud jsou v ní hluboce zakořeněny myšlení a stará organizační struktura. Proto je podpora managementu klíčovým a výchozím faktorem úspěšné implementace nového bezpečnostního projektu. Je vhodné předloţit managementu pádné argumenty pro vybudování nového bezpečnostního systému. Zpočátku to sice přináší pouze investice do budování nové struktury a její údrţbu, ale poprvé se projeví v případě mimořádných událostí, kterých nikdy není v běţném provozu málo. Obecně se dá konstatovat, ţe bezpečnostní opatření mají preventivní charakter; z dlouhodobého hlediska však tvoří nezbytnou součást firemní (organizační) politiky. Důleţité argumenty pro management mohu shrnout do následujících bodů: 1. Zvýšení

důvěryhodnosti

a

vylepšení

jména

společnosti.

Prezentace

bezpečnostní politiky je pádným argumentem vůči zákazníkům. 2. Nedochází k poškození dobrého jména společnosti medializací v případě úniku dat. 3. Ochrana stability organizace tím, ţe je minimalizován únik dat z informačního systému vnějším narušitelem. 4. Ochrana investic do výzkumu a vývoje před zneuţitím ze strany konkurence. 5. Ochrana před útokem hackerů. 6. Ochrana před počítačovými viry a dalšími kybernetickými útočníky. 7. Ochrana informací obchodního charakteru. 8. Ochrana před zneuţitím systému zaměstnanci. 9. Omezuje „absolutní moc“ administrátorů nad informačním systémem. 10. Analyzuje podezřelé situace v systému a odhalí „narušitele“ dřív, neţ stačí způsobit negativní zásah. 11. Vytváří jistotu, ţe při selhání technického zařízení nebo ţivelné katastrofě je na vzniklou situaci firma připravena.[2]

47

4 Návrh a implementace opatření na minimalizaci bezpečnostních rizik - projekt „Změna infrastruktury ICT“ V předchozí části této diplomové práce jsem se zabýval především technickým zabezpečením informační techniky. Protoţe nejen teorie, ale především praxe ukazuje a potvrzuje, co je zapotřebí udělat pro to, abychom naše počítače a komunikační cesty uchránili útokům zvenčí a také zevnitř, přináším druhou část práce, ve které jsem vyuţil poznatků expertů počítačové techniky, bezpečnosti informační techniky a technologie, svých vlastních znalostí a zkušeností nasbíraných za více neţ 10 let působení v oblasti IT na různých pracovních pozicích od administrátora koncových stanic pracujících především se softwarem od firmy Microsoft aţ po administrátora převáţně Linuxových serverů a správce rozsáhlých heterogenních sítí. Kdyţ jsem pátým rokem pracoval pro jednu větší českou telekomunikační společnost, kontaktoval mě přes kolegu můj budoucí šéf z menší firmy, která hledala odborníka na unixové systémy, počítačové sítě a bezpečnost IT. Za poslední rok se ve mě střádaly problémy, které provázely částečnou restrukturalizaci (jiţ několikáté velké propouštění), rušení zaměstnaneckých výhod a obecně zhoršení pracovních podmínek ze strany zaměstnavatele. Spolu s tím mi začala vadit i nepruţnost struktury řízení firmy (i kdyţ samozřejmě chápu, ţe velká firma jinak řídit nelze), cokoliv sloţitějšího vyřešit byl běh na dlouhou trať, často ještě komplikovaný obecně špatnou náladou v celé společnosti. Proto mi tato nabídka přišla celkem vhod a po dvou seznamovacích schůzkách a debatě, co o de mě firma očekává a co já naopak očekávám od ní jsme se domluvili na podmínkách a já podepsal novou pracovní smlouvu a ve stávajícím zaměstnání podal výpověď. V nové práci se ode mě očekávalo, ţe plně převezmu odpovědnost za celé ICT a postarám se o jeho rozvoj a zabezpečení.

48

4.1 Počáteční analýza stavu ICT Jiţ při podpisu smlouvy v prostorách firmy jsem se byl podívat po kancelářích a do serverovny. Místnost pro servery byl kumbál bez klimatizace velikosti zhruba metr na metr a půl, kde na zemi stály dva servery a nad nimi přímo do switchů ústila strukturovaná kabeláţ. Ţádný rack, ţádné patch panely. Taktéţ na druhé straně kabeláţe se nenacházely ţádné zásuvky, ale koncovka kabelu vedla rovnou do počítače. Byl jsem upozorněn, ţe současný stav není plně vyhovující, ale firma se měla v rámci měsíců stěhovat do nových prostor, které budou daleko lépe vyhovovat. To bylo také jedním z důvodů, proč jsem byl do společnosti přijat, zařídit nové prostory po ICT stránce tak, aby mohla firma dále růst a poskytovat sluţby více zákazníkům. Stávající řešení bylo děláno prakticky na koleně a dost amatérsky, také si člověk, co to vše dělal, oddychnul, kdyţ jsem od něj tuto práci převzal a on se mohl plně soustředit na svůj hlavní obor, ústředny.

4.1.1 Hardware První věc, kterou jsem po nástupu do práce v serverovně hledal, byl firewall. Objevil jsem ho na SHDSL modemu, byl to Ovislink RS-1000. Přístroj, který při plném vyuţití zvládne uroutovat asi tak 2Mbity provozu. To by sice na rychlost 2 Mbit DSL linky bylo dostatečné, ale nejde na něm prakticky cokoliv rozumného nakonfigurovat, zvládne pouze základní nastavení NATu, těţkopádně DHCP, hrozné výstupy do LOGU apod. Switche byly také od firmy Ovislink, a to FSH-2400. Na webu se výrobce chlubí, jakýţe to není zázrak s managementem, ale v tomto konkrétním případě management znamená aplikace do systému windows s moţností nastavení VLAN. Switche nepodporují protokol SNMP, takţe grafy vytíţenosti jednotlivých portů byly z říše sci-fi, stejně jako sledování chybovosti.

49

Jak uţ jsem se zmínil v předešlé kapitole, na zemi stály dva počítače v Midi skříni, kterým se říkalo servery. Tyto stroje byly pro provoz společnosti naprosto klíčové, důleţité bylo i internetové připojení a ISDN PRI linka, vedoucí do jednoho ze serverů. Jeden z nich tedy zastával funkci ústředny a druhý byl aplikační a databázový server, na kterém běţela podpůrná webová aplikace pro zaměstnance na práci s klienty. Na těchto počítačích byly pouţity běţné desktopové komponenty a nainstalován operační systém na bázi Linuxu, coţ bylo první pozitivní zjištění. Jako klientské počítače v open space kanceláři určené pro provoz call centra byly pouţity barebone systémy ASUS s nainstalovaným operačním systémem Linux, v ostatních kancelářích určených pro back office byly podobné počítače se systémem Windows XP Home Edition. Jako závěr z analýzy hardwaru ve firmě vyplynulo, ţe jediné, co bylo pouţitelné do budoucna bez podstatných úprav byly klientské počítače, vše ostatní bude muset být nahrazeno.

4.1.2 Software Jak jiţ jsem psal výše, stanice v call centru byly a v současné době stále jsou provozovány na operačním systému na bázi Linuxu, coţ je pro vyuţití těchto počítačů naprosto vhodný operační systém jak vzhledem ke správě, tak vzhledem k ceně. S ostatními stanicemi určenými pro back office uţ je to trošku horší, protoţe většina z nich je provozována se systémem Windows XP Home, který není vhodný pro korporátní nasazení. V této práci se ale těmito koncovými stanicemi nebudu zabývat, do budoucna je plánována postupná náhrada těchto počítačů a operačního systému pro domácnosti a zprovoznění Active Directory pro snadnou správu. Pro interní komunikaci se pouţíval Instant Messaging systém MSN od firmy Microsoft. Neexistovala zde ţádná správa skupin či práv a já toto povaţuji za zbytečnou závislost na cizí společnosti, nehledě na to, ţe licenční podmínky této sluţby měly několik stránek a je zbytečné si k jejich prostudování najímat právníka. To, ţe interní komunikace firmy byla provozována přes cizí servery vně společnosti,

50

uţ je jen taková bezpečnostní třešnička no dortu. Daleko lepší sluţby s velmi širokými moţnostmi konfigurace a správy a větší mírou bezpečnosti si můţu poskytovat sám v rámci firmy. Pošta byla provozována na sluţbě u hostingové společnosti Forpsi. Je to opět závislost na cizí společnosti a platí tady podobné co u IM systému, v rámci firmy si tuto sluţbu dokáţu poskytovat sám a lépe. Současný stav infrastruktury dále neumoţňoval prakticky ţádné moţnosti blokování odchozího provozu a jen minimální moţnosti konfigurace blokace provozu příchozího. Dále neexistovala spolehlivá a jednoduchá cesta, jak

dostat

s hardwarového firewallu nějaké pouţitelné logovací soubory pro analýzu. K tomu se váţe i absence sledování dostupnosti sluţeb, tedy v podstatě chyběl jakýkoli monitoring sluţeb a hardwaru. Jediný monitoring fungoval prostřednictvím uţivatelů a jejich stíţností. Jako závěr z analýzy softwaru také vyplynulo, ţe jediné, co zůstane zachované beze změn, jsou koncové stanice na call centru. Počítače v back office zůstanou zatím zachovány také s budoucím výhledem na změnu.

4.1.3 Síťové prostředí Veškeré počítače a zařízení jsou umístěny v jedné síti, veškerá komunikace v rámci lokální sítě probíhá po druhé vrstvě modelu ISO/OSI, tedy ţe neprochází přes router, coţ v některých případech není ţádoucí.

4.2 Definice potřeb Po předchozí analýze a konzultaci se spolupracovníky a majiteli firmy jsem definoval tyto potřeby pro zázemí ICT v nových prostorech: Klimatizovaná

místnost

pro

servery

s rackem

a

ukončenou

strukturovanou kabeláží v patch panelech. Kvalitní plnohodnotné servery, v žádném případě desktopové počítače.

51

Rychlé a spolehlivé připojení k internetu se zálohou. Lépe navržená počítačová síť, DMZ a zvláštní síť pro management zařízení. Možnost řízení (blokování) příchozího i odchozího provozu. Nutný vnitrofiremní chat a pošta provozovaná vlastními prostředky. Monitoring systémů a služeb. Kontrola legitimního provozu. Kontrola odchozího provozu na čísla kreditních karet.

52

4.3 Návrh a implementace Stěhování do nových prostor se ukázalo jako obrovská výhoda při změně infrastruktury, coţ se ostatně dalo čekat. Hlavně zprovoznění nové serverovny a vybudování strukturované kabeláţe by bez větších výpadků nebylo moţné provést. Pořídily se nové servery od firmy Supermicro, dále pak 42U rack se 100 centimetrovou hloubkou a výkonná dvoujednotková klimatizace. Po jednáních s několika společnostmi firma GTS dodala symetrické 20Mbit připojení realizované v profesionálním mikrovlnném pásmu (36Ghz) a

4MBit SHDSL linku jako

automaticky přepínanou zálohu.

4.3.1 Změna návrhu sítě a nové aktivní prvky Původně z jedné sítě vzniknou sítě tři, původní z rozsahem 192.168.0.0/24, další síť 192.168.1.0/24 pro management zařízení jako jsou switche, ipmi serverů a podobně a poslední síť 192.168.2.0/24 bude fungovat jako demilitarizovaná zóna (DMZ), do této poslední sítě se postupně přesunou veškeré servery, které mají přístupné sluţby z internetu. Tento přesun bude dlouhodobější záleţitost, neţ se odladí provoz v DMZ. Jako nové switche jsem zvolil plně L2 od firmy SMC s funkcí POE na všech portech (kvůli VOIP telefonům, o kterých se tato práce nezmiňuje). Jedná se o plně managovatelné switche s plnou podporou všech funkcí druhé vrstvy ISO/OSI modelu. Jejich konzole se podobá konzolím firmy Cisco, konfigurace v příkazovém řádku je bezproblémová, přístup lze nastavit přes ssh. Jako velmi levná alternativa oproti Cistu je to dobrá volba.

4.3.2 Router a Firewall - blokování provozu Jako hlavní prvek sítě jsem zvolil jeden z nakoupených serverů doplněných o více síťových rozhraní s nainstalovaným operačním systémem Debian Linux. Zvaţoval jsem i alternativu HW routeru od firmy Cisco, ale to nenabízí takové

53

moţnosti nastavení jako Linux a jeho Iptables, které se pouţívají pro zastání funkce firewallu. Další věcí je samozřejmě i cena a má osobní inklinace k Linuxu. Pouţitá síťová rozhraní na routeru jsou celkem 3, jedno směřuje k technologii GTS, která se stará o internet, druhé funguje pro síť 192.168.0.0/24 a 192.168.1.0/24 (oddělených VLANami) a třetí rozhraní je určené pro DMZ se sítí 192.168.2.0/24. Debian Linux se konfiguruje pro to, aby fungoval jako router, velice jednoduše, stačí vyeditovat soubor /etc/sysctl.conf a zde odkomentovat řádek net.ipv4.ip_forward=1. Toť

vše,

po

restartu

serveru

(anebo

po

příkazu

echo

“1”

>

/proc/sys/net/ipv4/ip_forward bez nutnosti restartu) začne Linux předávat pakety v rámci svých síťových rozhraní. Na routeru jsem ještě nastavil IP adresy všech rozhraní prostřednictvím souboru /etc/network/interfaces. Firewall uţ tak snadný není. Existuje dost projektů, které se konfiguraci firewallu pomocí iptables snaţí zjednodušit a uţivatelsky zpříjemnit (např. Shorewall), ale nikdy jsem k těmto snahám nenašel cestu. Pouţil jsem vlastní skripty, které historicky vycházejí ze skriptu mpfw Mirka Petříčka, který napsal koncem roku 2001. Společné jiţ mnoho nemají, ale vţdy mi restart firewallu připomene mé začátky s Linuxem. Kouzlo iptables tkví v tom, ţe nástroj pro znalého člověka nabízí široké moţnosti konfigurace na blokaci a povolení příchozího a odchozího provozu, pomocí něj dokáţeme i prioritizovat provoz na základě námi daných poţadavků, i kdyţ tato konfigurace uţ tak snadná není a vyţaduje větší znalosti nějaké QoS disciplíny (převáţně HTB). Iptables se nijak neinstaluje, je to součástí standardní instalace distribuce Debian. Jediné, co musíme zajistit je, aby se skript načetl při startu systému. Existuje moţnost načítání přes init skripty při startu systému, já osobně preferuji start firewallu při spuštění síťových sluţeb, protoţe při pouţití init skriptu server bude několik sekund nechráněn, neţ po startu sítě tyto skripty proběhnou. Toto spuštění je jednoduché, do jiţ výše zmíněného souboru /etc/network/interfaces jsem přidal pod definici lokálního rozhraní tento řádek:

54

pre-up iptables-restore < /etc/firewall-rules Soubor firewall-rules vzniká při ručním spuštění či restartování skriptu mpfw. Samotný skript jsem umístil do /root/scripts/firewall spolu s vypínacím skriptem a skriptem na restart. Nejzajímavější výtah ze samotného skriptu na firewall opatřeným komentáři uvádím pro jeho délku v příloze číslo 3.

4.3.3

Interní chat a pošta

Pro interní komunikaci pomocí instant messagingu jsem zvolil jedinou moţno otevřenou variantu a to protokol XMMP/Jabber. Je to decentralizovaný systém, který původně vznikl jako protokol pro síť Jabber, která poskytovala instant messagingové sluţby. Později se rozrostl ještě o další moţnosti, jako je vzájemná komunikace programů a automatických sluţeb a byl přijat jako Internetový standard a definován v RFC dokumentech. Konkrétně jsem si vybral produkt Ejabberd pod licencí GPLv2, pro jeho snadnou správu (např. skupin), široké konfigurační moţnosti a v neposlední řadě i velmi pozitivní osobní zkušenost. Instalace probíhala velmi jednoduše, stačil mi na to příkaz: #aptitude install ejabberd Protoţe jsem chtěl software pouţívat společně s databází, vytvořil jsem ještě mysql databázi

a

naplnil

ji

tabulkami.

Tabulky

byly

k dispocizi

v souboru

/usr/share/doc/ejabberd/examples/mysql.sql.gz. Tedy jsem soubor rozzipoval a pouţil následující příkazy: #mysqladmin create ejabberd #mysql -u root -p -D ejabberd < /tmp/mysql.sql Vlastní konfigurace ejabberd je jako příloha 4, taktéţ je opatřena komentáři proč jsem co jak nastavil. Další nastavení jako je přidání uţivatelů či definice skupin jiţ probíhá přes webové rozhraní.

55

Obrázek 1.: Nastavení uţivatelů

Obrázek 2.: Nastavení skupin Jako poštovní systém jsem zvolil kombinaci Postfix a Dovecot jako MTA a MDA (mail transfer agent a mail delivery agent, MTA se stará o posílaní pošty, MDA o doručení do schránky, ke čtení pak slouţí MUA, mail user agent, . tedy poštovní

56

klient). Postfix je vysoce výkonný a zároveň maximálně jednoduše konfigurovatelný MTA, který vznikl jako alternativa ke komplikovanému Sendmailu. Zároveň v rámci něj můţe fungovat filtr Amavis, který pomocí různých pluginů jako je spamassassin, razor, pyzor2, clamav apod. kontroluje poštu proti spamu a virům. Na toto filtrování se tato diplomová práce nesoustředí, i kdyţ ochrana proti spamům a virům je velmi důleţitá součást bezpečnostní politiky firmy. V konfiguračních souborech ale tyto věci definovány jsou, takţe v nich alespoň budou mírně okomentovány. Obě aplikace, jak postfix tak dovecot, budou navázány na spolupráci s databází. Postfix a Dovecot se nainstalují opět jednoduchým způsobem: #aptitude install postfix-mysql dovecot-pop3d dovecot-imapd Vytvoříme databázi a vloţíme potřebné tabulky: #mysqladmin create mailserver mysql> CREATE TABLE `virtual_domains` ( id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50) NOT NULL ) ENGINE = InnoDB; CREATE TABLE `virtual_users` ( id int(11) NOT NULL AUTO_INCREMENT PRIMARY KEY, domain_id INT(11) NOT NULL, user VARCHAR(40) NOT NULL, password VARCHAR(32) NOT NULL, CONSTRAINT UNIQUE_EMAIL UNIQUE (domain_id,user), FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE ) ENGINE = InnoDB; CREATE TABLE `virtual_aliases` ( id int(11) NOT NULL AUTO_INCREMENT PRIMARY KEY, domain_id INT(11) NOT NULL, source VARCHAR(40) NOT NULL, destination VARCHAR(80) NOT NULL, FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE ) ENGINE = InnoDB; CREATE VIEW view_users AS

57

SELECT CONCAT(virtual_users.user, '@', virtual_domains.name) AS email, virtual_users.password FROM virtual_users LEFT JOIN virtual_domains ON virtual_users.domain_id=virtual_domains.id; CREATE VIEW view_aliases AS SELECT CONCAT(virtual_aliases.source, '@', virtual_domains.name) AS email, destination FROM virtual_aliases LEFT JOIN virtual_domains ON virtual_aliases.domain_id =virtual_domains.id; 0 Komentovaná konfigurace postfixu a dovecotu se nachází v příloze 5.

4.3.4 Monitoring služeb a systémů Aby administrátor vypadal, ţe neustále sleduje systémy pod svojí správou, je dobré mít nějaký dohledový systém, který mu v případě problému dá vědět. Já jsem si vybral základ velké části monitorovacích systémů, a to projekt Nagios. Jedná se o robustní dohledový systém, který monitoruje sluţby a systémy pomocí pluginů, které mohou být napsány například v perlu, pythonu či shellu. Není problém najít plugin prakticky na jakoukoli sluţbu, kterou bychom chtěli monitorovat. S připojenou sms bránou tak neunikne ţádný problém sluţby či systému, který monitorujeme. Nagios umí monitorovat buď pomocí SNMP, ICMP či jednotlivých protokolů sedmé vrstvy modelu ISO/OSI nebo aktivní či pasivní kontrolou pomocí pluginu nainstalovaném na kontrolovaném serveru. Aktivní kontrola znamená, ţe poţadavek na kontrolu vyšle systém Nagios a výsledek si stáhne, pasivní znamená to, ţe server odešle výsledky kontroly na systém Nagios. Osobně pouţívám aktivní kontrolu, jelikoţ systémy, které kontroluji, nejsou velmi rozsáhlé, pasivní kontrola je vhodná tam, kde se monitoruje velké mnoţství cílů, jelikoţ nezatěţuje monitorovací server takovým způsobem, jako kontrola aktivní. Instalaci monitorovacího systému jsem provedl následujícím způsobem: #aptitude install nagios3 nagiosgrapher

58

Instalace pluginu pro aktivní kontrolu je taktéţ jednoduchá: #aptitude install nagios-nrpe-server Konfiguraci přikládám jako přílohu 6, níţe je obrázek systému Nagios, kde je vidět kontrola sluţeb na databázovém serveru.

Obrázek 3.: Nagios přehled kontrolovaných sluţeb

4.3.5 Intrusion detection system Intrusion detection system je zařízení či software, které monitoruje síťové aktivity a ty podezřelé společně s aktivitami porušujícími definovaná pravidla reportuje administrátorovi. Jedná se o pasivní zařízení, které pouze sleduje, nezasahuje do provozu sítě. Je to vhodný doplněk k firewallu, který blokuje neţádoucí komunikaci, ale povoluje tu, co provozovat potřebujeme. IDS se zaměřuje právě na tuto ţádoucí komunikaci a v ní hledá pokusy o útok na konkrétní aplikace.

59

K vlastní analýze paketů IDS pouţívá dvě základní technologie, signatury a dekódování protokolů, které kombinuje. Snort je defacto standardem v oblasti open source IDS, tak padla volba logicky na něj. Po prvotním prostudováním stránek s projektem jsem se pustil do instalace a konfigurace.

4.3.5.1 Instalace a konfigurace SNORT - IDS Jelikoz na stroji, kde jsem chtěl IDS nainstalovat, běţí distribuce Debian Lenny, začal jsem instalaci z balíčků distribuce. Stroj se jmenuje GW a jak název napovídá, je to gateway a zároveň firewall pro komunikaci vnitřní sítě s okolím a opačně. Instalace probíhala celkem jednoduše: # aptitude install snort-mysql s následnou konfigurací s dotazy na moji domácí síť a připojení do databáze Bohuţel jsem v zápětí zjistil, ţe verze v balíčkách je jiţ mírně zastaralá a uţ pro ní nejsou pravidelné updaty pravidel. Nezbývalo nic jiného, neţ celé moje předchozí snaţení zahodit (pravda, nebylo ho tak moc) a začít znovu s kompilací ze zdrojových kódů. Před vlastní kompilaci snorta je nutno zkompilovat a nainstalovat tento software: Libpcap – API pro zachytávání paketů Libdnet – API k přístupu k některým protokolům (ARP, GRE..) DAQ – Data-Acquistion API je potřeba pro Snort verze 2.9.0 a vyšší Postup kompilace a instalace Libpcap: # cd /usr/usr/snort # wget http://www.tcpdump.org/release/libpcap-1.1.1.tar.gz # tar xvfz libpcap-1.1.1.tar.gz

60

# cd libpcap-1.1.1 # ./configure --prefix=/usr --enable-shared # make # checkinstall Postup kompilace a instalace Libdnet: cd /usr/usr/snort # wget http://libdnet.googlecode.com/files/libdnet-1.12.tgz # tar xvfz libdnet-1.12.tgz # cd libdnet-1.12 # ./configure --prefix=/usr --enable-shared # make # checkinstall Postup kompilace a instalace DAQ: cd /usr/usr/snort # wget http://www.snort.org/dl/snort-current/daq-0.5.tar.gz # tar xvfz daq-0.5.tar.gz # cd daq-0.5 # ./configure # make # checkinstall Při kompilaci DAQ, konkrétně při příkazu configure systém zahlásil, ţe mu chybí některé aplikace, jednalo se o lex a bison. Vyřešeno příkazem: # aptitude install flex bison Dále uţ vše probíhalo v pořádku a DAQ se zkompiloval a nainstaloval.

61

Obrázek 4.: chyba při kompilaci DAQ A konečně se dostáváme k samotné kompilaci a instalaci snorta: # cd /usr/src/snort # wget http://www.snort.org/dl/snort-current/snort-2.9.0.5.tar.gz # tar xvfz snort-2.9.0.5.tar.gz # cd snort-2.9.0.5 # ./configure --with-mysql --enable-dynamicplugin --enable-perfprofiling -enable-zlib --enable-reload # make # checkinstall Opět příkaz configure zahlásil chybějící knihovny, a to libpcre, libmysqlclient. Vyřešeno doinstalováním: # aptitude install libpcre3-dev libmysqlclient15-dev Pokračoval jsem vytvořením adresářů a změnou jejich vlastníka a nakopírováním defaultních konfiguračních souborů. Také jsem chtěl vytvořit uţivatele a skupinu snort, ale skript na odinstalaci původního pokusu nebyl důsledný a uţivatele a skupinu v systému nechal: # mkdir /etc/snort /etc/snort/rules /var/log/snort /var/log/barnyard2 /usr/local/ lib/snort_dynamicrules # chown snort:snort /var/log/snort /var/log/barnyard2

62

# cp /usr/src/snort/snort-2.9.0.5/etc/*.conf* /etc/snort # cp /usr/src/snort/snort-2.9.0.5/etc/*.map /etc/snort Nyní je nutno upravit konfigurační soubor, aby bylo moţno provést základní test funkčnosti IDS. V konfiguračním souboru definuji svojí domácí síť, upravím načítání pravidel a připravím výstup pro program barnyard2, který parsuje výsledky nasbírané snortem: ipvar HOME_NET 192.168.0.0/16 ipvar EXTERNAL_NET !$HOME_NET var RULE_PATH ./rules output unified2: filename snort.log, limit 128 include $RULE_PATH/local.rules #vstatní includy s pravidly zakomentovat Dále připravíme jednoduché pravidlo na otestování, budeme logovat všechny icmp pakety. Do souboru /etc/snort/rules/local.rules přidáme: alert icmp any any -> $HOME_NET any (msg:”ICMP test”; sid:10000001;) Teď přišla ta správná chvíle na první spuštění a otestování: #/usr/local/bin/snort -A console -q -u snort -g snort -c /etc/snort/snort.conf -i eth1 Pošleme ping na adresu vnitřního rozhraní serveru a na konzoli by se mělo objevit něco takového:

63

Obrázek 5.: Základní test funkčnosti Po úspěšném základním testu je ještě nutno připravit databázi, nainstalovat a zkonfigurovat parser logů barnyard2, připravit webový frontend, nastavit automatické spouštění a pravidla pro detekci a připravit automatické stahování pravidel a automatický reporting. Příprava databáze: Jelikoţ balíčková verze zanechala v databázi uţivatele snort i s heslem, stačí udělat samotnou databázi s názvem snort a naplnit ji tabulkami: # mysqladmin create snort # mysql –u root –p –D snort < /usr/src/snort/snort-2.9.0.5/schemas/create_mysql Instalace a konfigurace barnyard2: # cd /usr/src/snort # wget http://www.securixlive.com/download/barnyard2/barnyard2-1.9.tar.gz # tar xvfz barnyard2-1.9.tar.gz # cd barnyard2-1.9 # ./configure --with-mysql

64

# make # checkinstall # mv /usr/local/etc/barnyard2.conf /etc/snort Upravím konfigurační soubor /etc/snort/barnyard2.conf: output alert_fast output database: log, mysql, user=snort password=tajneheslo dbname=snort host=localhost A teď je potřeba otestovat správnou funkčnost celého systému i se zápisy do databáze. Nastartuji snorta společně s barnyardem2 a zkontroluji databázi: #/usr/local/bin/snort –q –u snort –g snort –c /etc/snort/snort.conf –i eth1 & /usr/local/bin/barnyard2 –c /etc/snort/barnyard2.conf –d /var/log/snort –f snort.log –w /etc/snort/bylog.waldo –G /etc/snort/gen-msg.map –S /etc/snort/sidmsg.map –C /etc/snort/clasification.config & # mysql –u root –p –D snort –e „select * from event“ Jestli po posledním příkazu a provedení pár pingů na server vidíme nějaké záznamy v tabulce event, je vše v pořádku a můţeme pokračovat nastavením webového frontendu. Instalace a konfigurace BASE: # cd /usr/src/snort # wget http://sourceforge.net/projects/secureideas/files/BASE/base1.4.5/base.1.4.5.tar.gz # tar xvfz base-1.4.5.tar.gz # cp -r base-1.4.5 /var/www/base Po otevření http://gw/base se provede jednoduchá konfigurace databáze a vytvoří se tabulky, potřebné pro běh BASE. Před vytvořením tabulek zahlásilo base chybu:

65

Obrázek 6.: Chyba při konfiguraci BASE Problém jsem vyřešil doinstalováním balíku php-pear a dvěma příkazy: # pear install Mail # pear install Mail_Mime Po tomto zásahu jiţ konfigurace proběhla v pořádku a frontend mi ukázal události, které se uloţily při předchozím testu. Pro automatický start IDS jsem si ze stránek projektu stáhnul init skript (viz. Příloha 3), uloţil ho do /etc/init.d/snort a vloţil do startup skriptů příkazem: #update-rc.d snort defaults Pro správný běh IDS ho musíme naplnit pravidly, podle kterých bude kontrolovat provoz, k tomu vyuţijeme projekt pulledpork: # cd /usr/src/snort # wget http://pulledpork.googlecode.com/files/pulledpork-0.6.0.tar.gz # tar xvfz pulledpork-0.6.0.tar.gz # cd pulledpork-0.6.0 # cp pulledpork.pl /usr/local/bin # cp etc/*.conf /etc/snort

66

Na stránkách https://www.snort.org/signup se zaregistrujeme a vygenerujeme tkz. oinkcode, který je potřeba pro stahování pravidel. Nakonfigurujeme prostřednictvím editace /etc/snort/pulledpork.conf: rule_url=https://www.snort.org/reg-rules/|snortrules-snapshot.tar.gz|oinkcode rule_url=https://www.snort.org/reg-rules/|opensource.gz|oinkcode rule_path=/etc/snort/rules/snort.rules local_rules=/etc/snort/rules/local.rules sid_msg=/etc/snort/sid-msg.map config_path=/etc/snort/snort.conf distro=Debian-Lenny snort_version=2.9.0.5 Funkčnost stahování pravidel vyzkoušíme příkazem: # /usr/local/bin/pulledpork.pl -c /etc/snort/pulledpork.conf -T –l Po provedení bychom měli vidět soubor pravidel /etc/snort/rules/snort.rules. Tímto jsme se dostali na závěr instalace a konfigurace, ještě je nutno zakomentovat lokální testovací pravidlo v /etc/snort/rules/local.rules, do konfigurace /etc/snort/snort.conf přidat řádek pro načítaní staţených pravidel: include $RULE_PATH/snort.rules a přidat updatování pravidel do cronu jednou týdně.

4.3.5.2 Provoz IDS Při následném sledování jsem zjistil, ţe vzniká neskutečné mnoţství alarmů, které nejsou vůbec podstatné, bylo jich aţ 20 tisíc denně. Přišlo mi, ţe to projekt má nastavené takto úmyslně, aby si člověk, který si s tím nedokáţe poradit, zaplatil jejich podporu. Já platím jen za to, co opravdu musím, takţe jsem postupně potlačoval pravidla, která byla jenom čistě informační a nic neříkala o proběhnutém pokusu o

67

útok. Potlačení se provádí jednoduše, do souboru /etc/snort/threshold.conf, kam přidáme gen_id pravidla a sig_id pravidla ve tvaru: # suppress gen_id 119, sig_id 15 Gen_id a sig_id je zjistitelné z logu /var/log/baynyard2/alert či to lze zjistit z tabulky mapování názvů pravidel /etc/snort/gen-msg.map. Webový frontend obsahuje pouze názvy pravidel. Kdyţ bych nechtěl nějaké pravidlo zakázat kompletně, je moţno vyspecifikovat cílovou či zdrojovou IP adresu nebo CIDR blok, či jejich negace. Po odstranění těchto pravidel: http_inspect: OVERSIZE REQUEST-URI DIRECTORY http_inspect: LONG HEADER http_inspect: NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE stream5: Bad segment, overlap adjusted size less than/equal 0 stream5: Limit on number of overlapping TCP packets reached stream5: TCP Small Segment Threshold Exceeded stream5: Reset outside window ssp_ssl: Invalid Client HELLO after Server HELLO Detected sensitive_data: sensitive data global threshold exceeded se situace značně zlepšila. Pro otestování jsem pouţil bezpečnostní scanner nessus.

Obrázek 7.: Test bezpečnostním scannerem Nessus

68

4.3.6 Data loss prevention Data loss prevention je systém, který se snaţí řešit problematiku úniku dat z firmy do jejího okolí. Děje se tak například pomocí scannování obsahu dat při průchodu serverem, který DLP zajišťuje či přímou kontrolou na koncových stanicích. Můţeme rozlišit tyto typy DPP systémů: Síťové DLP – analyzuje síťový provoz blízko bezpečnostního perimetru. Detekuje citlivá data na základě bezpečnostních politik. Endpoint DLP – běţí na koncových stanicích. Zajišťuje kontrolu externích zařízení připojených ke stanici, vyuţití clipboardu a tisknutí. Storage DLP – software, který scannuje data centra a snaţí se najít citlivé soubory Jelikoţ firma, ve které pracuji, disponuje citlivými daty zákazníků, byl hlavní poţadavek zaměstnatele na systém DLP takový, aby nemohly unikat čísla kreditních karet přes mail či web ven z firmy. Po procházení internetu jsem narazil na projekt pod GNU licencí, který se jmenuje MyDLP. Přesněji řečeno, volně šiřitelná je pouze jeho Community Edition, Enterprise Edition uţ je placená. Neváhal jsem a MyDLP Community Edition jsem začal zkoušet.

4.3.6.1 Instalace a konfigurace MyDLP Ze stránek http://www.mydlp.org jsem si stáhnul upravené CD s instalací Ubuntu Server 10.04 a MyDLP Appliance. Jedná se o klasickou instalaci Linuxu, tedy je nutno nabootovat a instalaci provést:

69

Obrázek 8.: Výběr jazyka systému

Obrázek 9.: Volba regionu. Kvůli updatům je dobré zvolit Českou Republiku Po volbě anglické klávesnice si instalátor vzal ip adresu z DHCP serveru. V zápětí mi přišel mail od ARP WATCHe, který mi hned prozradil MAC adresu. Zatím jsem

70

povolil internet ručně, později převedu IP adresu MyDLP z volného IP poolu na statickou. Instalátor dál pokračoval konfigurací LVM, dotázal se na uţivatelské jméno a heslo pro přihlášení. Na otázku, zdali se má kryptovat home adresář, jsem odpověděl ne, nebudou zde ţádná tajná data.

Obrázek 10.: Dotaz na LVM

71

Obrázek 11.: Vytvoření uţivatele

Obrázek 12.: Dotaz na kryptování home adresáře

Obrázek 13.: Závěr instalace Před závěrečným zmáčknutím klávesy Enter jsem ještě na DHCP serveru přidělil ip adresu pro MyDLP a přidal jméno a ip do dns.

72

Obrázek 14.: Konfigurace DHCP serveru Po restartu serveru jsem změnil jeho hostname, nainstaloval vmware tools, protoţe to celé je instalováno na virtuální server. I kdyţ si správnou ip adresu server vezme z DHCP, stejně jsem mu ji nastavil napevno, ostatně, tak to mám na všech svých serverech. Nastavení hostname: # echo “mydlp” > /etc/hostname # echo “mydlp.em-agency.com” > /etc/mailname Nastavení ip adresy, editace /etc/network/interfaces: auto etho iface etho inet static address 192.168.0.99 netmask 255.255.255.0 broadcast 192.168.0.255 gateway 192.168.0.1 Následoval pro jistotu restart celého serveru, pro ověření, ţe je vše správně nastaveno.

73

Obrázek 15.: Kontrola, zdali neběţí DHCP klient a je nastavena ip adresa Pokračoval jsem vlastní konfigurací MyDLP systému. Po zadání https://mydlp jsem vytvořil uţivatele, který je potřeba pro pouţití management konzole. Pro test konfigurace a endpoint protekce jsem na vmware serveru nainstaloval Windows XP Professional, vytvořil síť v rámci vmware, kde MyDLP server figuroval jako gateway. Pro transparentní směrování http a https poţadavků na proxy server SQUID, přes který se filtrují poţadavky na webové stránky, jsem přidal do /etc/rc.local na serveru tyto dva řádky: iptables -t nat -A PREROUTING -i eth1 -p TCP --dport 80 -j REDIRECT --toport 3128 iptables -t nat -A PREROUTING -i eth1 -p TCP --dport 443 -j REDIRECT --toport 3129 Pak jsem začal z WinXP stanice zkoušet nějaké stránky, abych viděl, zdali to prochází filtry. Velkým překvapením bylo, ţe vše jelo neskutečně pomalu, jen stránka s vyhledávačem Google se načítala několik desítek sekund, o naboptnalém Seznamu se snad ani nemá cenu zmiňovat. V proxy servery SQUID jsem vypnul ICAP filtr, který se stará o propojení s DLP systémem a vše jelo rychle tak, jak má. Tím jsem sice odhalil problém, ale samozřejmě vyřadil kontrolu prohlíţení stránek. Asi půl dne jsem se snaţil všemoţně zjistit, proč se tak děje, psal jsem na fórum výrobce DLP

74

systému a hledal po internetu. Jelikoţ se jedná o relativně nový projekt, byl uveřejněn na konci minulého roku, internet byl na informace velmi skoupý a od výrobce nikdo nereagoval. Pak jsem vyzkoušel nainstalovat DLP znovu, a přímo na fyzický počítač. Jediný rozdíl byl v tom, ţe jsem teď pouţil 64bit verzi místo 32bit. Vše fungovalo tak jak má, rychlost byla bezproblémová. Upravil jsem tedy virtuální server, smazal původní instalaci MyDLP, zvýšil pamět a nainstalovatl 64bit verzi. Nyní uţ byla rychlost také bezproblémová, takţe jsem mohl pokračovat v testech. Po přihlášení do managementu MyDLP jsem zkusil jeho jednoduchou verzi a hned jsem nastavil filtrování kreditních karet:

Obrázek 16.: Jednoduché nastavení filtrování čísel kreditních karet Vše jsem začal zkoušet na webovém frontendu k mailu a testovací mail s několika čísly kreditních karet opravdu nešel odeslat:

75

Obrázek 17.: Mail s čísly kreditních karet nelze odeslat Pro potvrzení, ţe se nejedná o náhodu, jsem v nastavení pravidla vypnul blokování události a nechal pouze logování, pak šel mail bez problémů odeslat a zápis o této události se objevil v logu. Chvíli jsem ještě zkoušel různé webové stránky a zjišťoval, jestli vše funguje ok a v zápětí jsem si všiml, ţe v logu přibývají falešná hlášení.

Obrázek 18.: Zobrazení logu v Management konzoli

76

Falešných hlášení nebylo mnoho a většinou se týkaly reklam, konkrétně níţe MyDLP zakázal reklamu ze systému googleads, měla být na pravé straně:

Obrázek 19.: Nezobrazení reklamy jako důsledek falešného poplachu Jiţ na začátku jsem tušil, ţe jednoduchá verze bude mít své mouchy a proto jsem jednoduchý management vypnul a vytvořil si pravidlo vlastní, kde je moţno specifikovat Whitelist domén, na které se nebude filtrace uplatňovat. Do Whitelistu jsem přidal dva reklamní systémy, co jsem zaznamenal v logách a budu zde přidávat další, které se případně objeví. Poté falešné poplachy prakticky ustaly. Ještě jsem vyzkoušel filtrování SMTP, tedy posílání mailů z poštovního klienta. Na serveru jsem mírně upravil konfiguraci poštovního systému postfix, přidal jsem do poloţky relayhost ip adresu stávajícího serveru pro poštu ve firmě, aby se mail po filtrování předal dál na zpracování. Na WinXP stanici jsem nastavil Outlook Express a zkusil odeslat mail s čísly kreditních karet. Mail se sice tvářil jako odeslaný (coţ je z hlediska toho, jak je filtr na poštu na MyDLP udělán, jasné, protoţe v postfixu je DLP integrováno pomocí content filteringu, tedy ţe mail od klienta převezme a aţ následně se před odesíláním scannuje na potenciálně závadný obsah), ale v zápětí dorazila do schránky odesílatele informace, ţe mail nebude odeslán z důvodu porušení pravidel.

77

Obrázek 20.: Whitelist domén v nastavení pravidel

Obrázek 21.: Mail se v poštovním klientovi tváří jako odeslaný

78

Obrázek 22.: Zpráva o nedoručení mailu, který porušuje pravidla Po těchto základních testech jsem ještě pokračoval ve zkoušení na virtuálním klientském počítači a ani po několika dnech se ţádné problémy nevyskytly a vše fungovalo v pořádku. Nasadil jsem tedy MyDLP transparentně do firemní sítě, do stávajícího proxy serveru jsem přidal ICAP propojení na MyDLP a v DNS jsem změnil ip adresu u názvu odchozího serveru na MyDLP server a na stávajícím postfixovi zakázal přístup z lokální sítě pro klientské počítače mimo DLP.

4.4 Eliminace vnitřního nepřítele 4.4.1 Vlastní zaměstnanci představují důvěryhodného nepřítele Noční můrou všech administrátorů, správců sítí nebo bezpečnostních ředitelů firem a organizací se stává stále častěji tzv. „vnitřní nepřítel.“ Mezi počítačovými experty, ale i u široké veřejnosti je spíš znám pod anglickým výrazem Insider. Tento název by se dal definovat jednoduše: jedná se o současného nebo bývalého zaměstnance firmy nebo kontraktora, který s firmou spolupracoval nebo ještě spolupracuje a kaţdý z nich měl (nebo ještě má) přístup do informačního systému organizace.[3]

79

Takoví lidé, podle Tomáše Přibyla, představují největší nebezpečí, protoţe kromě přístupu znají systém jako nikdo jiný. „Často bezpečnostní systém celé organizace navrhovali, nasazovali nebo s ním alespoň pracovali a vědí, jak jsou v něm ošetřené jednotlivé aspekty, včetně bezpečnostních. Vědí, kde jsou slabé stránky a především mají příleţitost systém napadnout – a to takovou příleţitost, jaká se externímu útočníkovi nikdy nenaskytne.“ [3] Takoví potencionální útočníci jsou nebezpeční, protoţe mají většinou naši důvěru. Přitom právě bezpečnost a spolehlivost kaţdého informačního systému jsou zaloţeny na spolehlivosti jednotlivých pracovníků, který provozovatel plně důvěřuje. „Bohuţel, kromě výše zmíněné příleţitosti mají insideři často také ještě jednu – mnohem nebezpečnější – věc. Motivaci.“ [3] Na nečinnost příslušného vedení firem a organizací v tomto „odvětví“ bezpečnosti informačních systémů poukázaly dvě studie společnosti Forrester Research, která zveřejnila zprávu Data Security Challenges and Technology Adoption in 2008. Ta se týká podniků všech velikostí a přitom je konstatováno, ţe plných 88 procent z nich povaţuje data a jejich ochranu za velkou výzvu. Jenomţe čtyřicet procent nemá odpovídající znalosti nebo nástroje, které by je ochránily před úniky informací. Naopak studie další organizace Redshift Research se zaměřuje pouze na menší firmy. Plná polovina malých a středních firem „se neobává“ moţnosti úniku dat prostřednictvím zaměstnanců. A pouhých 22 procent věří, ţe vnitřní hrozby jsou větší externích. Jen 45 procent organizací ze segmentu SMB má aplikace, které automaticky kontrolují pokusy o připojení externích disků (a kopírování dat). To však není jediný moţný vektor úniku. Podle studie pouhých 35 procent kontroluje PDA a podobný hardware. Coţ ale znamená nejen riziko úniku dat, ale i ohroţení bezpečnosti. Také další zjištěná čísla jsou zaráţející: 60 procent malých organizací nemá politiku pro regulaci přístupu externích zařízení k síti. Dalších 20 procent nemá schopnost zjistit, kde jsou právě teď uloţena kritická data. Jedna třetina organizací nedokáţe zjistit, jaká přenosná zařízení byla připojena k síti. A 40 procent není schopno zjistit, zdali na ně byla přenesena nějaká data.[6]

80

Důvody „neošetření“ dostatečného zajištění úniku dat jsou jednoduché: Zpočátku firmy věnovaly poměrně hodně finančních prostředků pro antivirové a antispamové aplikace – externí hrozby (hrozby zvenčí). Navíc se rozšířil špatný názor, ţe v tomto případě bude vnitřní síť bezpečná, a ten na mnoha místech přetrvává dodnes. Podle studie společnosti Forrester mají největší zájem o technologie bránící úniku dat firmy působící na trhu ve finančnictví, pojišťovnictví, energetice nebo telekomunikacích. Na druhou stranu nejmenší zájem o únik dat jeví firmy zabývající se maloobchodem, výrobou nebo obchodem. Opět přináším další komentář Tomáše Přibyla na výše zmíněné téma špatného zabezpečení informační techniky a to jak proti vnějšímu, tak vnitřnímu nepříteli. Ten konstatuje: další průzkum v USA ukázal, ţe útoky pocházející zevnitř systému jsou často nereportované. Tak trochu dle přísloví „co se doma uvaří, to se doma sní.“[3] Podle Ponemon Institute LLC v Elks Rapid, stát Michigan, jsou většinou vnitřní úniky dat nereportované, a to proto, ţe společnosti nemají zdroje nebo chuť, aby je monitorovaly. Plných 79 procent účastníků průzkumu připustilo, ţe během posledního roku ví nejméně o jednom interním incidentu, který nebyl nijak řešený. Dalších 61 procent potvrdilo, ţe s náhodnými úniky dat se setkávají často nebo velmi často. A 48 procent také připustilo, ţe se často nebo velmi často setkávají s „počítačovou sabotáţí“ (záměrným mazáním dat nebo fyzickou destrukcí hardwaru). Deset procent správců IT si přitom v rámci průzkumu postěţovalo, ţe více neţ polovinu svého času tráví řešením právě vnitřních incidentů. A přes 55 procent dotázaných jim věnuje více neţ třetinu svého času. Jaká můţe proti insiderům existovat obrana? 1. Omezení počtu osob pracujících s tzv. „doloţkou nejvyšších výhod.“ To je těch pracovníků, kteří poţívají u vrchního managementu nejvyšší důvěru.

81

2. Čím méně je zasvěcených do celé záleţitosti, tím se zmenšují moţnosti jakékoliv problému (nejen v bezpečnosti informačních technologií). 3. Důsledná kontrola pracovníků s „doloţkou nejvyšších výhod.“ 4. Přísný výběr nových zaměstnanců (kontrola trestního rejstříku, posudky z předchozích zaměstnání, morální bezúhonnost, závazek mlčenlivosti apod.). 5. Pravidelná kontrola pracovišť, ochranných opatření, školení a testy. To vše zajišťuje, ţe uţivatelé budou mít odpovídající znalosti IT a jsou obeznámeni se svými právy a povinnostmi, stejně jako s provozem IT. 6. Omezení mnoţství důvěry, kterou má kaţdý pracovník s poukazem, ţe kdo koncentruje u sebe velké mnoţství moci a pravomocí, můţe současně představovat

potencionální

nebezpečí

(např.

univerzální

hesla

nebo

univerzální klíče). Moc u takových pracovníků by se měla překrývat. Kaţdý je na svém pracovišti nahraditelný (zastupitelný). Překrýváním polí důvěry se nastavuje několikastupňová bezpečnost: kdyţ selţe jeden systém, zastoupí ho druhý. 7. Auditní systém – by měl být na kaţdém pracovišti oddělen od běţného provozu, protoţe jinak by v praxi kontroloval opět pouze sám sebe. 8. Odcházející zaměstnanci by měli být ihned po podepsání výpovědi „odstřiţeni“ od přístupů do systémů. S rozvázáním pracovního poměru by měli podepsat i čestné prohlášení o mlčenlivosti, a uvědomit si, ţe jejich případné počínání v neprospěch bývalého zaměstnavatele by mohlo být dokonce trestné.

4.4.2 Řízení rizik - analýza informační bezpečnosti Dalším běţným postupem při odhalování slabých míst v zajištění bezpečnosti informační techniky je pravidelné provádění kontrol – přesněji analýz informační bezpečnosti. Právě dobře provedené analýzy mohou poukázat z vnějšího i vnitřního prostředí na určitá bezpečnostní rizika. Tato by měla organizace co nejrychleji sníţit, případně úplně odstranit. Sníţení rizika lze provést na „akceptovatelnou úroveň“ tzn. ţe opatření jsou taková, aby neohrozila podstavu fungování organizace (firmy). Samozřejmě, ţe míra akceptovatelnosti rizika se odvíjí od odvětví, ve kterém

82

organizace působí a také na dalších specifických podmínkách. Všechna rizika by měla být dříve či později identifikována a periodicky přezkoumávána, včetně jejich dokumentace. „V případě, kdy jsme v pozici bezpečnostního manaţera menší nebo střední organizace, bychom měli dbát na to, abychom rizika řídili alespoň do té míry, ţe je dokáţeme v rámci organizace identifikovat, dokumentovat a máme o nich přiměřeně aktuální povědomí.“[3] Dál rozvíjí Přibyl teorii o moţnosti tzv. outsourcingu

(přenesení

rizika),

coţ

v praxi

znamená

provoz

určitého

problematického systému, pojištění moţných škod v případě, ţe by byla další opatření příliš náročná na realizaci – buď po finanční nebo organizační stránce. Někdy můţe nastat případ, ţe riziko je tak vysoké a efektivita opatření naopak nízká, ţe organizace nakonec udělá rozhodnutí, ţe raději přestane v dané oblasti podnikat.

4.4.3 Návrh bezpečnostních opatření Při návrhu vhodných bezpečnostních opatření se můţeme inspirovat v normě ISO/IEC 27002, která se za tímto účelem v praxi všeobecně vyuţívá. Jejím cílem je dosáhnout vyváţeného komplexu bezpečnostních opatření, který dokáţe pokrýt všechny relevantní oblasti IT. Poměrně často se dá zaznamenat výrazná chyba, kdy se v organizacích soustředí pouze na technické zabezpečení – výběr firewallů, antivirových programů, šifrovacích klíčů, šifrovacího software, čipových karet apod. a zcela opominou lidský faktor. K těmto chybám dochází v důsledku nákupu zabezpečovacích zařízení z rozhodnutí pracovníků IT oddělení (přesněji jejich vedoucích). Výsledkem je zajištění informačních technologií, které však není vůbec efektivní, protoţe kdokoliv ze zaměstnanců můţe prozradit přístupová hesla do sítě apod. a tento problém se nedá odstranit nákupem drahých technologických zařízení. Znovu stojí za zopakování, ţe kaţdý zaměstnanec by měl mít v sobě vypěstováno bezpečnostní povědomí, které se dá pouze zlepšovat na poradách a školeních.

83

„Mezi typické oblasti informační bezpečnosti, které mohou být ošetřeny s minimální potřebou finančních investic, patří organizace bezpečnosti (stanovení bezpečnostních rolí, jmenování vlastníků aktiv, nastavení základních procesů – například hlášení incidentů apod.), personální bezpečnost (výběr zaměstnanců, školení uţivatelů informačního systému atd.) nebo soulad s poţadavky (definice legislativních

poţadavků

s vlivem

na

poţadavky

na zabezpečení

apod.).

Pokud by ale někdo nabyl dojmu, ţe nejlevnější pro organizaci bude, kdyţ všechno týkající se informační bezpečnosti realizuje vlastními silami, nemusí to být zdaleka pravda. Proto doporučuji řadu sluţeb specializovaných externích dodavatelů. Ty jsou ve výsledném vyúčtování mnohem levnější neţ kompletní souhrn všech vnitřních nákladů, který zahrnuje nejen mzdové náklady, ale například i náklady ušlých příleţitostí.“[3]

4.4.4 Budování informační bezpečnosti v organizaci Pokud organizace s budováním informační bezpečnosti teprve začíná, měla by se kromě implementace nezbytného technického zabezpečení věnovat: 1. Zpracování plánu bezpečnosti (viz. kapitola 3.1) 2. Definici bezpečnostní politiky organizace (tamtéţ) 3. Vytvoření základních bezpečnostních rolí 4. Zpracování bezpečnostní příručky pro uţivatele 5. Zvyšování bezpečnostního povědomí2 6. Proces implementace můţe být účinně podpořen formou externích konzultací.3

2

Uţivatelé neustále představují nejslabší článek informační bezpečnosti organizace. S tímto faktem

bohuţel nic neuděláme. Řešením můţe být školení sestavené na základě konkrétních podmínek organizace a cílené pro uţivatele určité specifické úrovně. V rámci školení si uţivatelé informačního systému osvojí základní zásady informační bezpečnosti, které jsou potřebné při kaţdodenní práci s počítačem připojeným do sítě a k internetu, čímţ se mimo jiné zvýší i jejich odolnost vůči určitým specifickým hrozbám, jako je například sociální inţenýrství. V praxi nebývá na škodu, pokud je školení zakončeno testem, který ověří míru pochopení odpřednášené problematiky.

84

„Správný bezpečnostní manaţer by se měl snaţit o takové počáteční nastavení úrovně informační bezpečnosti, která bude pro organizaci a její zaměstnance snesitelná. Teprve následně by se měl snaţit vytvářet přiměřený tlak, kterým bude firemní kulturu „přizpůsobovat“ potřebám bezpečnosti. Typickým způsobem je postupné zpřísňování bezpečnostních opatření. I kdyţ kaţdý bezpečnostní profesionál zná například standardní poţadavky na kvalitu a pouţívání hesel, pokud víme, ţe uţivatelé nebudou schopni je plnit, je pro organizaci daleko menším zlem tato pravidla na přechodnou dobu mírně uvolnit (například vyţadovat méně často změnu hesla). Pokud bychom v tomto případě striktně trvali na svém, můţeme se také dočkat toho, ţe hesla budou napsána na kaţdé druhé klávesnici a stejně ničeho nedosáhneme. Tím však rozhodně netvrdím, ţe bychom měli před uţivateli kapitulovat a nesnaţit se je k dodrţování potřebných pravidel přinutit. Jen je třeba, aby byl tlak plynulý a pro uţivatele snesitelný.“[3]

4.5 Provádění kontroly Pokud bezpečnostní správce nebo manaţer organizace berou na vědomí všechny svoje úkoly spojené s bezpečnostní IT systému organizace váţně a opravdově, určitě se jejich úsilí neobejde bez účinných a pravidelných kontrol neobejde. Soustavné kontroly jsou důleţité ze dvou základních důvodů: 1. Potřebujeme získat informace, jak se nám podařila implementovat navrţená a uţívaná bezpečnostní opatření – zda fungují správně, efektivně a jestli je zaměstnanci zcela respektují a řídí se jimi.

3

I kdyţ je způsob řešení informační bezpečnosti v kaţdé organizaci do určité míry originální, existuje

řada běţně se vyskytujících úskalí, jejichţ vliv dokáţe zkušený externí konzultant svými vhodnými návrhy omezit.

85

2. Průběţně potřebujeme zjišťovat stav bezpečnosti organizace a ověřovat její úroveň zajištění. Výsledky kontrol se stávají nezbytným podkladem pro operativní a systémové změny v oblasti bezpečnosti. Podle poznatků z nich můţeme provádět korekce stávajících bezpečnostních opatření případně po vyhodnocení výsledků stanovit nová. Účinná kontrola se nejčastěji zaměřuje na dvě základní oblasti:

a) Kontrola technického zabezpečení V největší míře se soustřeďuje na kontrolu technických bezpečnostních opatření a technických parametrů, které se zabezpečením souvisejí. Takové kontroly mohou mít následující formu: 1. Penetrační testy informačního systému organizace a/nebo klíčových aplikací, 2. Technické prověrky a bezpečnostní audity klíčových zařízení, serverů apod., 3. Analýzy logů důležitých zařízení a aplikací (např. logy událostí z firewallu, centrální správy AV ochrany, webové proxy apod., dále přístupové logy centrálních datových úloţišť, významných aplikací, databází atd.), 4. Prověrky konkrétních stanic, notebooků apod.

b) Kontrola organizačního/procesního/personálního zabezpečení Samozřejmě nesmíme zapomínat na ostatní oblasti informační bezpečnosti – i jejich stav můţe mnohé vypovídat o bezpečnosti IT organizace. Jedná se například o kontroly zaměřené na ověřování úrovně bezpečnostního povědomí uţivatelů, funkčnosti stěţejních bezpečnostních procesů (jako jsou například incident management, kontinuita provozu informačního systému apod.), případně o kontroly přímo na úrovni jednotlivých uţivatelů a jejich počítačů (jak průběţné, tak například i v rámci vyšetřování incidentů). Pro tyto kontroly můţeme v praxi vyuţít následující metody:

86

1. Simulace útoků metodami sociálního inţenýrství. 2. Simulace vybraných situací vzhledem k ověření funkčnosti souvisejících procesů (např. v oblasti havarijního plánování). 3. Prověrka znalostí konkrétních uţivatelů (formou dotazování – co byste dělal/a kdyby...). 4. Prověrka dodrţování stanovených pravidel uţivateli (např. i včetně kontroly počítače uţivatele – data, instalovaný software, historie internetového prohlíţeče atd.). [3]

4.5.1 Penetrační testy a bezpečnostní audity Význam penetračních testů spočívá v simulaci činnosti potenciálního útočníka, který se snaţí prolomit zabezpečení informačního systému organizace nebo jeho specifické části (např. konkrétní aplikace). Pokud vyuţíváme nástroje penetračního testování ke kontrolám bezpečnosti, můţeme je dělat na různých úrovních:

1. Základní bezpečnostní skeny „Tyto mohou provádět jak bezpečnostní správce nebo administrátoři organizace. Pro jejich pouţití je vhodným nástrojem například skener zranitelností Nessus, administrátorský nástroj Hyena či třeba Microsoft Baseline Security Analyzer. Typický základní sken nám odpoví na otázku, zda se v našich systémech nevyskytují kritické zranitelnosti způsobené například chybějícími významnými bezpečnostními záplatami, nevhodným nastavením apod. Provedení základní sady skenů sítě a zhodnocení výstupů by v praxi nemělo být sloţité a měl by ho zvládnout kaţdý se základními znalostmi daných technologií. Obvykle tedy není třeba za podobnou sluţbu platit.“[3]

87

Poznámka: V praxi můţeme narazit na sluţby, ve kterých je „prověřování“ nazváno penetrační test, ale jejich dodavatel provede pouze základní sken zranitelností (vulnerability scanning). Jako výstup zákazník dostane zprávu obsahující jen souhrn nalezených zranitelností, který je většinou generován přímo v daném skeneru. Tyto sluţby jsou nabízeny za daleko niţší ceny neţ plnohodnotné penetrační testy, jejichţ kvality ale zdaleka nedosahují. Bohuţel, právě otázka ceny je dnes pro mnohé rozhodující. 2. Plnohodnotné penetrační testy Jedná se o standardní činnost, která by měla být periodicky prováděna v kaţdé organizaci, kde aktivně vyuţívají ICT. Cílem je zjištění, do jaké míry je konkrétní IS odolný proti potencionálním útokům, kde jsou jeho slabá místa a jak je efektivně odstranit. Testeři v rámci testů vyuţívají renomované komerční toolkity a frameworky, volně dostupné nástroje a často jednoúčelové nástroje vlastní produkce, které vznikají podle aktuálních potřeb testů. Výstupem bývá podrobná zpráva, která popisuje nalezené zranitelnosti a jejich rizika s odhadem míry dopadu. Ke kaţdému identifikovanému riziku by mělo být přiloţeno základní vysvětlení a rámcové doporučení k jeho odstranění, případně sníţení dopadu na únosnou úroveň. Provedením plnohodnotných penetračních testů se zabývají specializované firmy a je vhodné jejich sluţeb vyuţít. 3. Prověrky a audity Moţná, ţe někomu připadá nevhodné uvádět jedno a to samé neustále dokola. Praxe však hovoří plně pro neustálé opakování. A to platí i při provádění bezpečnostních kontrol a auditů v organizacích. Pravidelné prověrky a audity totiţ mnohdy odhalí nedostatky, na které by např. nepoukázal ani uţivatel sám. Proto je vhodné vyuţít u specifických systémů, serverů a aplikací, u kterých potřebujeme mít větší míru jistoty jejich zabezpečení, neţ nám dokáţou dát plošné penetrační testy informačního systému, právě tento postup. Rovněţ v tomto případě platí doporučení, zadat jejich provedení specializované firmě.

88

U provádění penetračních testů se testeři stavějí do role potenciálních útočníků; při bezpečnostních prověrkách a auditech se vţívají do rolí systémových administrátorů a implementátorů zkoumaného prvku. Při kontrole nastavení jednotlivých systémů se vyuţívá znalostí a zkušeností bezpečnostních a systémových specialistů, doporučení výrobců pro hardening apod. Výstupem bývá zpráva z auditu, která popisuje jednotlivé nalezené zranitelnosti, jejich rizika a uvádí základní moţnosti odstranění. 4. Kontrola uživatelů Uţivatelé tvoří podstatnou část IS kaţdé organizace. Proto i jim musíme věnovat patřičnou pozornost – přesněji jejich zabezpečení. Jen uţivatel, který dodrţuje stanovená bezpečnostní opatření organizace, je dobrým uţivatelem. To ovšem neznamená, ţe i v takové situaci nemůţe nastat neţádoucí riziko. „Některé metody pro kontrolu dodrţování bezpečnostních pravidel uţivateli jsou výborné nejen jako ověření stávajícího stavu, ale také jako prostředek pro jejich výraznější osvětu (takové věci se lidem jednoduše vryjí do paměti a stávají se i tématem hovorů na pracovišti). Platí to například u testování uţivatelů metodami sociálního inţenýrství. Provádění kontrol zaměřených na sociální inţenýrství je vhodné jak v rámci komplexních penetračních testů organizace, tak i samostatně jako ověření správných návyků uţivatelů, například po bezpečnostním školení. V praxi můţeme pouţít různé scénáře, jako například podstrčení souboru (např. trojského koně) pod různými záminkami e-mailem nebo prostřednictvím webového odkazu, nucení uţivatele k prozrazení přístupových informací (login a heslo) přes telefon (například s pouţitím falešné identity), podstrčení škodlivého obsahu na médiích v prostorách organizace apod. V rámci těchto a dalších scénářů vytvořených dle konkrétního prostředí organizace se vyuţívají různé stresové situace a záminky – třeba: Máte zavirovaný počítač!“ [3]

89

5. Sledování stavu a zlepšování bezpečnosti Pro zajištění fungování PDCA cyklu a neustálé zlepšování bezpečnosti, je zapotřebí stanovit pro jednotlivé prováděné kontroly vhodné metriky, které umoţní hodnotit a sledovat vývoj úrovně bezpečnosti organizace. „Průměrné organizaci s průměrnými potřebami postačí stanovit a sledovat pouze základní metriky, které spočívají třeba v počtu virových incidentů za dané období, počtu útoků detekovaných IPS/IDS zařízením, počtu uţivatelů, kteří se „nechali nachytat“ na sociální inţenýrství, výsledky písemného testu uţivatelů po bezpečnostním školení a tak dál.“[3] Přestoţe se úroveň bezpečnosti IT nedá přesně fyzicky změřit, musíme se dál snaţit posuzovat, v jakém stavu se právě nachází.

90

Závěr Předcházející stránky této diplomové práce přinášejí poznatky a zkušenosti z ochrany a zabezpečení informační techniky i praktický příklad provedení informační a komunikační infrastruktury v menší firmě. Téma pro práci je velmi rozsáhlé a mohu konstatovat, ţe by určitě nebylo na škodu přinést více podrobností k jednotlivým opatřením, která by ještě více vylepšila bezpečnost informačních sítí. Stálo by však za úvahu, kde přesně začít, a kterou problematikou se podrobněji zabývat, aby výsledky přinesly alespoň teoretické návrhy pro moţná vylepšení ochrany proti vnějšímu a především vnitřnímu nepříteli. Po prostudování veškerých teoretických materiálů z vydané odborné literatury, webových stránek jednotlivých specializovaných firem, které se zabezpečením výpočetní techniky zabývají, mohu uvést následující: Vyvstává důleţitý problém počítačových sítí. Odborníci zabývající se matematikou by rádi definovali, co je na webu důleţité, jak s ním zacházet, jak ho měřit a kolik má prvků. „Síť reálně existuje, je všude, třeba jako vzduch, je obrovská, a přitom není definována. Musíme ji pochopit, a proto ji zkoumáme.“0 Moţná se najdou, právě díky matematikům a jejich definicím, další moţné postupy i v bezpečnosti informačních sítí – určitě podchycené pouze teoreticky, ale jejich samotná existence umoţní expertům ve výpočetní technice hledat další faktory, jak celou síť ještě více zabezpečit a vytvořit takovou ochranu dat, ţe přes ni nepronikne ani ten nejsvětovější hacker. Podle matematika Jaroslava Nešetřila jsou webové sítě všude a nikde, a proto se je matematik snaţí poznat a pochopit jejich vlastnosti, slabiny i rizika. „Co je na síti, nelze utajit. Např. moje ţena s oblibou vyuţívá internet k vedení bankovního účtu. Já tuším rizika webu a raději platím účty na přepáţce. Člověk počítače vymyslel, ale ty uţ teď ţijí vlastním ţivotem, je to úplně jiná inteligence. To je podle mě fantastické, ale i nebezpečné. Lidé podceňují počítače. Kdyţ dostanete spam, je to vzkaz od počítače, a nikoliv od konkrétní osoby,“ rozvíjí matematik svoje úvahy od obecného ke konkrétnímu a hned dodává: „Těţko můţete

91

zkoumat web, kdyţ nevíte, co to je. Existuje uţ několik matematických modelů, ale ţádný neodpovídá na všechny otázky. Přitom cílem matematiků je vytvoření modelu sítě, její rámcové pochopení pak umoţní vyhnout se rizikům a nějak se sítí zacházet.“ 0 I takové teoretické kroky mohou přinést mnohé ozřejmení pro inţenýry informačních technologií, kteří pomocí nových matematických definic získají teoretické základy pro převedení potřebných faktů do praxe. Rád bych se ale vrátil k realitě této diplomové práce, kde se zjevně teorie s praxí prolínají od jejího začátku aţ do poslední kapitoly. Proto mohu v jejím závěru konstatovat, ţe „škůdci“ bezpečnosti informačních technologií se stávají pouze a jen lidé. Ať se jedná o zjevný úmysl, poškodit informaci zvenčí nebo (ne)úmysl některého ze stávajících zaměstnanců nebo blízkých spolupracovníků. Proto mohu pouze opakovat doporučení teoretiků i praktiků, která jsem citoval v předcházejících kapitolách. Jejich obsah by se dal shrnout do několika vět: 1. Nepodceňovat přípravu instalace nové informační techniky. 2. Správně volit nové zaměstnance a s těmi zkušenými, kteří plní své úkoly uţ delší dobu v organizaci, pracovat citlivě a nepodceňovat kontroly a školení. 3. Dbát o absolutní loajalitu zaměstnanců vůči organizaci. 4. Nepodceňovat vyhodnocení kaţdého incidentu, který zachytí administrátor. 5. Nepodceňovat audity a pokud moţno nechávat je provádět nezávislým a specializovaným firmám a odborníkům 6. Nepodceňovat obnovu technického a technologického zabezpečení informační techniky a technologií. 7. Sledovat veškeré změny a inovace, kterými výpočetní technika prochází. V těchto sedmi bodech jsem se pokusil shrnout zásady, které by měly platit pro všechny, kdo se dostanou do osobního styku s jakoukoliv informační technikou. Jen jejich dodrţování můţe přinést úspěch v boji proti „vnitřnímu nepříteli“ našich informační techniky. Nalézt ten správný směr v řešení otázek bezpečnosti informačních systémů je opravdu sysifovská práce. Náskok mají výrobci zabezpečovacích technologií.

92

Náskok, jak se zdá, mají i útočníci zvenčí. Musíme tedy dělat vše pro to, aby před námi náskok nezískal tzv. „vnitřní nepřítel.“ Nesmíme proto zapomínat, ţe problematika bezpečnosti informačních systémů je nikdy nekončící proces a musí se operativně přizpůsobovat rozvoji a nasazování nových technologií. Prozatím jde vývoj kupředu ve spirále. Jestli se někdy dokáţe proměnit v uzavřený kruh, to prozatím nikdo nedokáţe odhadnout. Já osobně se domnívám, ţe ne.

93

Příloha 1 ČSNI - Český normalizační institut Český normalizační institut (ČSNI) byl státní příspěvkovou organizací, zřízený 1: ledna 1993 v souvislosti s reorganizací státní správy po rozpadu České a Slovenské federální republiky, řízený Ministerstvem průmyslu a obchodu. Na základě sdělení Ministerstva průmyslu a obchodu č. 237/1997 Sb. prováděl zákon č. 22/1997 Sb. a zajišťoval tvorbu, vydávání a zveřejňování českých technických norem ČSN. ČSNI se také účastnil spolupráce s nevládními mezinárodními a evropskými organizacemi zabývajícími se technickou normalizací a zabezpečoval technickou normalizaci způsobem obvyklým ve vyspělých evropských zemích.; sídlil v Praze, Biskupský dvůr 5. Tato příspěvková organizace byla s platností 31. prosince 2008 k rozhodnutím ministra průmyslu a obchodu zrušena; tvorbu a vydávání ČSN od 1. ledna 2009 zajišťuje Úřad pro technickou normalizaci, metrologii a státní zkušebnictví. Technické normy vydané ČSNI (pokud doznaly ze zákona změn) zůstávají v platnosti i nadále.

94

Příloha 2 České technické normy České technické normy přejímané z ISO/IEC JTC1 SC 27 pokrývají problematiku bezpečnosti informačních technologií na průřezové úrovni, jsou tedy všeobecně vyuţitelné. Zajišťují normalizaci generických metod a technik pro bezpečnost informačních technologií. To zahrnuje: identifikaci generických poţadavků (včetně poţadavků na metodologii) pro bezpečnostní sluţby systémů IT vývoj bezpečnostních technik a mechanismů (včetně registračních postupů a vztahů mezi bezpečnostními komponentami) vývoj bezpečnostních směrnic (např. interpretační dokumenty) vývoj dokumentace a norem určených k podpoře managementu (např. terminologie a kritéria pro hodnocení bezpečnosti, problematika analýzy rizik). České technické normy přejímané z ISO/IEC JTC1 SC 27 pokrývají normalizaci kryptografických algoritmů pro zajištění sluţeb integrity, autentizace a nepopiratelnosti. Zahrnují rovněţ normalizaci kryptografických algoritmů pro zajištění sluţeb důvěrnosti a to v souladu s mezinárodně akceptovanými zásadami. Přehled ČSN z oblasti bezpečnosti informačních technologií: ČSN ISO/IEC 2382-1 Informační technologie - Slovník - Část 1: Základní termíny ČSN ISO/IEC 2382-8 Informační technologie - Slovník - Část 8: Bezpečnost ČSN ISO/IEC 2382-14 Informační technologie - Slovník - Část 14: Spolehlivost ČSN ISO/IEC 10116 Informační technologie - Bezpečnostní techniky - Módy činnosti pro n-bitovou blokovou šifru

95

ČSN ISO/IEC 10118-1 Informační technologie - Bezpečnostní techniky Hašovací funkce - Část 1: Všeobecně ČSN ISO/IEC 10118-2 Informační technologie - Bezpečnostní techniky Hašovací funkce - Část 2: Hašovací funkce pouţívající n-bitovou blokovou šifru ČSN ISO/IEC 10118-3 Informační technologie - Bezpečnostní techniky Hash funkce - Část 3: Dedikované hash funkce ČSN ISO/IEC 10118-4 Informační technologie - Bezpečnostní techniky Hašovací funkce - Část 4: Hašovací funkce pouţívající modulární aritmetiku ČSN ISO 10126-1 Bankovnictví - Postupy pro šifrování zpráv (bankovní sluţby pro velkou klientelu) - Část 1: Obecné zásady ČSN ISO 10126-2 Bankovnictví - Postupy pro šifrování zpráv (bankovní sluţby pro velkou klientelu). Část 2: Algoritmus DEA ČSN ISO 10202-1 Identifikační karty. Karty pro finanční transakce. Bezpečnostní architektura systémů finančních transakcí vyuţívajících karty s integrovanými obvody. Část 1: Ţivotní cyklus karty ČSN ISO 11131 Bankovnictví - Autentizace přihlášením ČSN

ISO

11166-1

Bankovnictví

-

Správa

klíčů

prostřednictvím

asymetrických algoritmů - Část 1: Zásady, postupy a formáty ČSN ISO 11166-2 Bankovnictví - Správa klíčů pomocí asymetrických algoritmů - Část 2: Schválené algoritmy pouţívající kryptosystém RSA ČSN EN ISO 11568-1 Bankovnictví - Správa klíčů (bankovní sluţby pro drobnou klientelu) - Část 1: Úvod do správy klíčů ČSN EN ISO 11568-2 Bankovnictví - Správa klíčů (bankovní sluţby pro drobnou klientelu) - Část 2: Techniky správy klíčů pro symetrickou šifru ČSN EN ISO 11568-3 Bankovnictví - Správa klíčů (bankovní sluţby pro drobnou klientelu) - Část 3: Ţivotní cyklus klíče pro symetrickou šifru ČSN ISO/IEC 11770-1 Informační technologie - Bezpečnostní techniky Správa klíčů - Část 1: Struktura ČSN ISO/IEC 11770-2 Informační technologie - Bezpečnostní techniky Správa klíčů - Část 2: Mechanismy pouţívající symetrické techniky

96

ČSN ISO/IEC 11770-3 Informační technologie - Bezpečnostní techniky Správa klíčů - Část 3: Mechanismy pouţívající asymetrické techniky ČSN ISO/IEC 13335-1 Informační technologie - Směrnice pro řízení bezpečnosti IT - TR Část 1: Pojetí a modely bezpečnosti IT ČSN ISO/IEC TR 13335-2 Informační technologie - Směrnice pro řízení bezpečnosti IT - Část 2: Řízení a plánování bezpečnosti IT ČSN ISO/IEC TR 13335-3 Informační technologie - Směrnice pro řízení bezpečnosti IT - Část 3: Techniky pro řízení bezpečnosti IT ČSN ISO/IEC TR 13335-4 Informační technologie - Směrnice pro řízení bezpečnosti IT - Část 4: Výběr ochranných opatření ČSN ISO/IEC 13888-1 Informační technologie - Bezpečnostní techniky Nepopiratelnost - Část 1: Všeobecně ČSN ISO/IEC 13888-2 Informační technologie - Bezpečnostní techniky Nepopiratelnost - Část 2: Mechanismy pouţívající symetrické techniky ČSN ISO/IEC 13888-3 Informační technologie - Bezpečnostní techniky Nepopiratelnost - Část 3: Mechanismy pouţívající asymetrické techniky ČSN ISO/IEC 14888-1 Informační technologie - Bezpečnostní techniky Digitální podpisy s dodatkem - Část 1: Všeobecně ČSN ISO/IEC 14888-2 Informační technologie - Bezpečnostní techniky Digitální podpisy s dodatkem - Část 2: Mechanismy zaloţené na identit ČSN ISO/IEC 14888-3 Informační technologie - Bezpečnostní techniky Digitální podpisy s dodatkem - Část 3: Mechanismy zaloţené na certifikátu ČSN ISO/IEC 15408-1 Informační technologie - Bezpečnostní techniky Kritéria pro hodnocení bezpečnosti IT - Část 1: Úvod a všeobecný mode ČSN ISO/IEC 15408-2 Informační technologie - Bezpečnostní techniky Kritéria pro hodnocení bezpečnosti IT - Část 2: Bezpečnostní funkční poţadavky ČSN ISO/IEC 15408-3 Informační technologie - Bezpečnostní techniky Kritéria pro hodnocení bezpečnosti IT - Část 3: Poţadavky na záruky bezpečnosti

97

ČSN ISO/IEC 17799 Informační technologie - Soubor postupů pro řízení informační bezpečnosti ČSN ISO 6166 Cenné papíry a příbuzné finanční nástroje - Mezinárodní systém identifikačního číslování cenných papírů (ISIN) ČSN ISO 7775 Bankovnictví - Cenné papíry - Schéma pro typy zpráv ČSN ISO 8372 Zpracování informací - Módy činnosti pro algoritmus 64bitové blokové šifry ČSN ISO 8730 Bankovnictví - Poţadavky na autentizaci zprávy (bankovní sluţby pro velkou klientelu) ČSN ISO 8731-1 Bankovnictví - Schválené algoritmy pro autentizaci zprávy Část 1: DEA ČSN ISO 8731-2 Bankovnictví - Schválené algoritmy pro autentizaci zprávy Část 2: Algoritmus autentikátora zprávy ČSN ISO 8732 Bankovnictví - Správa klíčů (bankovní sluţby pro velkou klientelu) ČSN ISO 8908 Bankovnictví a souvisící finanční sluţby - Slovník a datové prvky ČSN ISO 9564-1 Bankovnictví - Řízení a bezpečnost osobních identifikačních čísel. Část 1: Principy a techniky ochrany PIN ČSN ISO 9564-2 Bankovnictví - Řízení a bezpečnost osobních identifikačních čísel. Část 2: Schválené algoritmy pro šifrování PIN ČSN ISO 9735-5 Elektronická výměna dat pro správu, obchod a dopravu (EDIFACT) - Pravidla syntaxe aplikační úrovně (Číslo verze syntaxe: 4) Část 5: Pravidla bezpečnosti pro dávkovou EDI (autentičnost, integrita a nepopření původu) ČSN ISO 9735-6 Elektronická výměna dat pro správu, obchod a dopravu (EDIFACT) - Pravidla syntaxe aplikační úrovně (Číslo verze syntaxe: 4) Část 6: Bezpečnostní autentizace a potvrzení (Zpráva AUTACK) ČSN ISO/IEC 9796-2 Informační technologie - Bezpečnostní techniky Schémata digitálního podpisu umoţňující obnovu zprávy - Část 2: Mechanismy vyuţívající hash funkci

98

ČSN ISO/IEC 9796-3 Informační technologie - Bezpečnostní techniky Schémata digitálních podpisů umoţňující obnovu zprávy - Část 3: Mechanismy zaloţené na diskrétních logaritmech ČSN ISO/IEC 9797 Informační technologie - Bezpečnostní techniky Mechanismus integrity dat pouţivající kryptografickou kontrolní funkci s vyuţitím algoritmu blokové šifry ČSN ISO/IEC 9797-1 Informační technologie - Bezpečnostní techniky - Kódy pro autentizaci zprávy (MAC) - Část 1: Mechanismy pouţívající blokovou šifru ČSN ISO/IEC 9798-1 Informační technologie - Bezpečnostní techniky Mechanismy autentizace entit - 1. část: Obecný model ČSN ISO/IEC 9798-2 Informační technologie - Bezpečnostní techniky Autentizace entit - Část 2: Mechanismy pouţívající symetrické šifrovací algoritmy ČSN ISO/IEC 9798-3 Informační technologie - Bezpečnostní techniky Mechanismy autentizace entit - Část 3: Autentizace entit pouţívající algoritmus s veřejným klíčem ČSN ISO/IEC 9798-4 Informační technologie - Bezpečnostní techniky Autentizace entit - Část 4: Mechanismy pouţívající kryptografickou kontrolní funkci ČSN ISO/IEC 9798-5 Informační technologie - Bezpečnostní techniky Autentizace entit - Část 5: Mechanismy pouţívající techniku nulových znalostí ČSN ISO 9807 Bankovnictví - Poţadavky na autentizaci zpráv (bankovní sluţby pro drobnou klientelu) ČSN ISO/IEC 9979 Informační technologie - Bezpečnostní techniky Postupy pro registraci kryptografických algoritmů

99

Příloha 3 Firewall skript: #!/bin/sh # #mail gw INET_IP="x.x.x.178" INET_IFACE="eth0" #nx INET_2IP="x.x.x.179" #webcallcentre a nxbuntu INET_3IP="x.x.x.180" #is,eis a webmail INET_4IP="x.x.x.181" # IP a broadcast adresa a rozhrani vnitrni site LAN_IP="192.168.0.1/32" LAN_BCAST="192.168.0.255/32" LAN_IFACE="eth1" #dohledova LAN LAN_2IP="192.168.1.1/32" LAN_2BCAST="192.168.1.255/32" #DMZ LAN_3IP="192.168.2.1/32" LAN_3BCAST="192.168.2.255/32" LAN_3IFACE="eth2" #tunel ip TUN0_IP="172.16.0.1/32" TUN0_IFACE="tun0" # Lokalni loopback rozhrani LO_IFACE="lo" LO_IP="127.0.0.1/32" # Cesta k programu iptables IPTABLES="/sbin/iptables" # Inicializace databaze modulu /sbin/depmod -a # Zavedeme moduly pro nestandardni cile /sbin/modprobe ipt_LOG /sbin/modprobe ipt_REJECT /sbin/modprobe ipt_MASQUERADE # Modul pro FTP prenosy /sbin/modprobe ip_conntrack_ftp /sbin/modprobe ip_nat_ftp # Zapneme routovani paketu, pro jistotu echo "1" > /proc/sys/net/ipv4/ip_forward # rp_filter na zamezeni IP spoofovani for interface in /proc/sys/net/ipv4/conf/*/rp_filter; do echo "1" > ${interface}

100

done # Implicitni politikou je zahazovat nepovolene pakety $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP $IPTABLES -P FORWARD DROP # # Retezec PREROUTING v NAT tabulce # # Presmerovani portu na port stanice uvnitr site # z netu $IPTABLES -t nat -A PREROUTING -p udp -s x.x.106.6 -d $INET_IP --dport 10000:20000 -j DNAT --to 192.168.0.7 # Martin doma sip phone $IPTABLES -t nat -A PREROUTING -p udp -s x.x.106.6 -d $INET_IP --dport 5060:5082 -j DNAT --to 192.168.0.7 # Martin doma sip phone #dalsi ipka #sluzby na fw $IPTABLES -t nat -A PREROUTING -p tcp -d $INET_2IP --dport 22 -j DNAT --to 192.168.0.8:22 # ssh kvuli nx $IPTABLES -t nat -A PREROUTING -p tcp -d $INET_3IP --dport 22 -j DNAT --to 192.168.0.228:22 #nxbuntu ssh $IPTABLES -t nat -A PREROUTING -p tcp -d $INET_3IP --dport 80 -j DNAT --to 192.168.0.254:80 $IPTABLES -t nat -A PREROUTING -p tcp -d $INET_3IP --dport 443 -j DNAT --to 192.168.0.254:443 $IPTABLES -t nat -A PREROUTING -p tcp -d $INET_3IP --dport 1080 -j DNAT --to 192.168.0.254:1080 # # Retezec POSTROUTING v NAT tabulce # # IP maskarada - SNAT # NATujeme $IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -s 192.168.2.4 -j SNAT --to $INET_8IP #wifi v dmz na vlastni IP $IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to $INET_IP #vse ostatni jede pres hlavni verejnou adresu # # Pridavne retezce pro snazsi kontrolu na rezervovane adresy # # Zahazovat a logovat (max. 5 x 3 pakety za hod) $IPTABLES -N logdrop $IPTABLES -A logdrop -m limit --limit 5/h --limit-burst 3 -j LOG --log-prefix "Rezervovana adresa: " $IPTABLES -A logdrop -j DROP # V tomto retezci se kontroluje, zda prichozi pakety nemaji nesmyslnou IP adresu $IPTABLES -N IN_FW #$IPTABLES -A IN_FW -s 192.168.0.0/16 -j logdrop # rezervovano podle RFC1918 nemuzu, jelikoz nat $IPTABLES -A IN_FW -s 10.0.0.0/8 -j logdrop # ---- dtto ---#$IPTABLES -A IN_FW -s 172.16.0.0/12 -j logdrop # ---- dtto ---# Omezeni netu na 80, 110, 443, 5190 $IPTABLES -N OMEZ $IPTABLES -A OMEZ -p ICMP --icmp-type echo-request -j ACCEPT # ping $IPTABLES -A OMEZ -p TCP --dport 80 -j ACCEPT # www $IPTABLES -A OMEZ -p TCP --dport 110 -j ACCEPT # pop3

101

$IPTABLES -A OMEZ -p TCP --dport 443 -j ACCEPT # https $IPTABLES -A OMEZ -p TCP --dport 5190 -j ACCEPT # icq # Omez2 $IPTABLES -N OMEZ2 $IPTABLES -A OMEZ2 -p ICMP --icmp-type echo-request -j ACCEPT # ping $IPTABLES -A OMEZ2 -p TCP --dport 5190 -j ACCEPT # icq $IPTABLES -A OMEZ2 -p TCP --dport 1935 -j ACCEPT # kamery $IPTABLES -A OMEZ2 -p TCP -d 80.188.188.212 --dport 8843 -j ACCEPT # dementni cpost gwl.cpost.cz # Retezec pro stanoveni limitu prichozich SYN konexi (ochrana pred SYN floods) # propusti pouze 50 SYN segmenty/sec $IPTABLES -N syn-flood $IPTABLES -A syn-flood -m limit --limit 1/s --limit-burst 50 -j RETURN $IPTABLES -A syn-flood -j DROP # # Retezec FORWARD # # Navazovani spojeni ala Microsoft # Paket navazuje spojeni, ale nema nastaveny priznak SYN, pryc s nim $IPTABLES -A FORWARD -p tcp ! --syn -m state --state NEW -j DROP # Nechceme rezervovane adresy na internetovem rozhrani $IPTABLES -A FORWARD -i $INET_IFACE -j IN_FW #povolit forwardovani mezi tun0 a LAN $IPTABLES -A FORWARD -i $TUN0_IFACE -o $LAN_IFACE -j ACCEPT $IPTABLES -A FORWARD -i $LAN_IFACE -o $TUN0_IFACE -j ACCEPT #forward do managementove site $IPTABLES -A FORWARD -i $LAN_IFACE -o $LAN_IFACE -s 192.168.0.9 -d 192.168.1.0/24 -j ACCEPT #service $IPTABLES -A FORWARD -i $LAN_IFACE -o $LAN_IFACE -s 192.168.1.0/24 -d 192.168.0.9 -j ACCEPT #service $IPTABLES -A FORWARD -i $LAN_IFACE -o $LAN_IFACE -s 192.168.0.146 -d 192.168.1.0/24 -j ACCEPT #martin $IPTABLES -A FORWARD -i $LAN_IFACE -o $LAN_IFACE -s 192.168.1.0/24 -d 192.168.0.146 -j ACCEPT #martin #forwardy do DMZ z LAN (weby apod) $IPTABLES -A FORWARD -i $LAN_IFACE -o $LAN_3IFACE -s 192.168.0.0/16 -d 192.168.2.12/32 -p tcp -dport 80 -j ACCEPT #z cele lan na mailer port 80 $IPTABLES -A FORWARD -i $LAN_3IFACE -o $LAN_IFACE -s 192.168.2.12/32 -d 192.168.0.0/16 -p tcp -sport 80 -j ACCEPT #z maileru na celou lan #martin na vsechno $IPTABLES -A FORWARD -i $LAN_IFACE -o $LAN_3IFACE -s 192.168.0.146 -d 192.168.2.0/24 -j ACCEPT $IPTABLES -A FORWARD -i $LAN_3IFACE -o $LAN_IFACE -s 192.168.2.0/24 -d 192.168.0.146 -j ACCEPT # Umoznit presmerovani portu na stanici dovnitr site #net1 $IPTABLES -A FORWARD -i $INET_IFACE -o $LAN_IFACE -p udp -d 192.168.0.7 --dport 4569 -j ACCEPT $IPTABLES -A FORWARD -i $INET_IFACE -o $LAN_IFACE -p udp -d 192.168.0.7 --dport 5060:5082 -j ACCEPT $IPTABLES -A FORWARD -i $INET_IFACE -o $LAN_IFACE -p udp -d 192.168.0.7 --dport 10000:20000 -j ACCEPT $IPTABLES -A FORWARD -i $INET_IFACE -o $LAN_IFACE -p tcp -d 192.168.0.8 --dport 22 -j ACCEPT $IPTABLES -A FORWARD -i $INET_IFACE -o $LAN_IFACE -p tcp -d 192.168.0.254 --dport 80 -j ACCEPT

102

$IPTABLES -A FORWARD -i $INET_IFACE -o $LAN_IFACE -p tcp -d 192.168.0.254 --dport 1080 -j ACCEPT $IPTABLES -A FORWARD -i $INET_IFACE -o $LAN_IFACE -p tcp -d 192.168.0.254 --dport 443 -j ACCEPT $IPTABLES -A FORWARD -i $INET_IFACE -o $LAN_3IFACE -p tcp -d 192.168.2.13 --dport 80 -j ACCEPT $IPTABLES -A FORWARD -i $INET_IFACE -o $LAN_3IFACE -p tcp -d 192.168.2.13 --dport 873 -j ACCEPT $IPTABLES -A FORWARD -i $INET_IFACE -o $LAN_3IFACE -p tcp -d 192.168.2.13 --dport 3389 -j ACCEPT # Routing zevnitr site ven #net1 $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.146/32 -p tcp --dport 25 -j ACCEPT #Martin na smtp ano $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.148/32 -p tcp --dport 25 -j ACCEPT #Martin na smtp ano $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.140/32 -p tcp -d x.x.173.212 -dport 25 -j ACCEPT #Iva na moje smtp ano $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.141/32 -p tcp -d x.x.173.212 -dport 25 -j ACCEPT #Vera mother na moje smtp ano $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.182/32 -p tcp -d x.x.173.212 -dport 25 -j ACCEPT #Petr na moje smtp ano $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.0/24 -d x.x.9.86 -p tcp --dport 20 -j ACCEPT #vsichni na nase FTP ano $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.0/24 -d x.x.9.86 -p tcp --dport 21 -j ACCEPT #vsichni na nase FTP ano $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.0/24 -d 140.90.128.70 -p tcp -dport 80 -j ACCEPT #vsichni na pocasi v ubuntu ano $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -p tcp --dport 25 -j DROP # toto ven ne $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -p tcp --dport 135 -j DROP # toto ven ne $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -p tcp --dport 136 -j DROP # toto ven ne $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -p tcp --dport 137 -j DROP # toto ven ne $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -p tcp --dport 138 -j DROP # toto ven ne $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -p tcp --dport 139 -j DROP # toto ven ne $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -p tcp --dport 445 -j DROP # toto ven ne $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.11/32 -j OMEZ2 # jen kecalci $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.12/32 -j OMEZ2 # jen kecalci $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.13/32 -j OMEZ2 # jen kecalci $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.14/32 -j OMEZ2 # jen kecalci $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.15/32 -j OMEZ2 # jen kecalci $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.16/32 -j OMEZ2 # jen kecalci $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.17/32 -j OMEZ2 # jen kecalci $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.18/32 -j OMEZ2 # jen kecalci $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.19/32 -j OMEZ2 # jen kecalci, jedou pres proxy $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.20/32 -j OMEZ2 # jen kecalci, jedou pres proxy $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.21/32 -j OMEZ2 # jen kecalci, jedou pres proxy $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.22/32 -j OMEZ2 # jen kecalci, jedou pres proxy $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.23/32 -j OMEZ2 #podpora-hr jen pres squida $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.99/32 -j ACCEPT #mydlp $IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -s 192.168.0.100/32 -j ACCEPT #watchdog # #sluzby z DMZ $IPTABLES -A FORWARD -i $LAN_3IFACE -o $INET_IFACE -s 192.168.2.4/32 -j ACCEPT #WIFI v DMZ # Routing zvenku dovnitr pouze pro navazana spojeni (stavovy firewall) #net $IPTABLES -A FORWARD -i $INET_IFACE -o $LAN_IFACE -m state --state ESTABLISHED,RELATED -j ACCEPT

103

$IPTABLES -A FORWARD -i $INET_IFACE -o $LAN_3IFACE -d 192.168.2.13 -m state --state ESTABLISHED,RELATED -j ACCEPT # Ostatni pakety budou zahozeny, tak je budeme logovat (12 x 5 pkt/hod) $IPTABLES -A FORWARD -m limit --limit 12/h -j LOG --log-prefix "forward drop: " # # Retezec INPUT # # Navazovani spojeni ala Microsoft # Paket navazuje spojeni, ale nema nastaveny priznak SYN, pryc s nim $IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP # Nejprve se zbavime nezadoucich adres $IPTABLES -A INPUT -i $INET_IFACE -j IN_FW # Odfiltrovat pokusy o syn-flooding #tohle sice odfiltruje syn, ale zaroven neumozni novou konexi, takze je to #uplne na hovno (test nmap z nejakeho stroje a z jineho uz zadna SYN konexe) #$IPTABLES -A INPUT -i $INET_IFACE -p tcp --syn -j syn-flood # Odfiltrovat pokusy o zahlceni icmp #$IPTABLES -A INPUT -i $INET_IFACE -p icmp -j syn-flood #povolime vse z tun0 $IPTABLES -A INPUT -i $TUN0_IFACE -j ACCEPT #pakety z tunelu ano # Pravidla pro povolene sluzby $IPTABLES -A INPUT -i $INET_IFACE -d $INET_IP -p TCP -s x.x.106.6 --dport 22 -j ACCEPT #SSH server martin $IPTABLES -A INPUT -i $INET_IFACE -d $INET_IP -p TCP -s x.x.106.253 --dport 22 -j ACCEPT #SSH server martin $IPTABLES -A INPUT -i $INET_IFACE -d $INET_IP -p TCP --dport 25 -j ACCEPT #SMTP server $IPTABLES -A INPUT -i $INET_IFACE -d $INET_4IP -p TCP --dport 80 -j ACCEPT #SMTP server $IPTABLES -A INPUT -i $INET_IFACE -d $INET_IP -p TCP --dport 110 -j ACCEPT #POP3 server $IPTABLES -A INPUT -i $INET_IFACE -d $INET_IP -p TCP --dport 143 -j ACCEPT #IMAP server $IPTABLES -A INPUT -i $INET_IFACE -d $INET_4IP -p TCP --dport 443 -j ACCEPT #HTTPS server $IPTABLES -A INPUT -i $INET_IFACE -d $INET_IP -p TCP --dport 993 -j ACCEPT #IMAP server $IPTABLES -A INPUT -i $INET_IFACE -d $INET_IP -p TCP --dport 6222 -j ACCEPT #ejabber server docasne trvale $IPTABLES -A INPUT -i $INET_IFACE -d $INET_IP -p TCP --dport 6223 -j ACCEPT #ejabber server ssl docasne trvale # Sluzbu AUTH neni dobre filtrovat pomoci DROP, protoze to muze # vest k prodlevam pri navazovani nekterych spojeni. Proto jej # sice zamitneme, ale tak, aby nedoslo k nezadoucim prodlevam. $IPTABLES -A INPUT -i $INET_IFACE -p TCP --dport 113 -m limit --limit 12/h -j LOG $IPTABLES -A INPUT -i $INET_IFACE -p TCP --dport 113 -j REJECT --reject-with tcp-reset #AUTH server # Propoustime pouze ICMP ping $IPTABLES -A INPUT -i $INET_IFACE -p ICMP --icmp-type echo-request -j ACCEPT # Loopback neni radno omezovat $IPTABLES -A INPUT -i $LO_IFACE -j ACCEPT # Stejne jako pakety z lokalni site, jsou-li urceny pro nas $IPTABLES -A INPUT -i $LAN_IFACE -d $LAN_IP -j ACCEPT

104

$IPTABLES -A INPUT -i $LAN_3IFACE -d $LAN_3IP -j ACCEPT $IPTABLES -A INPUT -i $LAN_IFACE -d $INET_IP -j ACCEPT $IPTABLES -A INPUT -i $LAN_IFACE -d $INET_2IP -j ACCEPT $IPTABLES -A INPUT -i $LAN_IFACE -d $INET_3IP -j ACCEPT $IPTABLES -A INPUT -i $LAN_IFACE -d $INET_4IP -j ACCEPT $IPTABLES -A INPUT -i $LAN_IFACE -d $TUN0_IP -j ACCEPT #tady dodelat omezeni do dohledove site $IPTABLES -A INPUT -i $LAN_IFACE -d $LAN_2IP -j ACCEPT #tady DMZ $IPTABLES -A INPUT -i $LAN_IFACE -d $LAN_3IP -j ACCEPT # Broadcasty na lokalnim rozhrani jsou take nase $IPTABLES -A INPUT -i $LAN_IFACE -d $LAN_BCAST -j ACCEPT $IPTABLES -A INPUT -i $LAN_3IFACE -d $LAN_3BCAST -j ACCEPT # MS klienti maji chybu v implementaci DHCP $IPTABLES -A INPUT -i $LAN_IFACE -p udp --dport 67 -j ACCEPT # Pakety od navazanych spojeni jsou v poradku $IPTABLES -A INPUT -d $INET_IP -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A INPUT -d $INET_2IP -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A INPUT -d $INET_3IP -m state --state ESTABLISHED,RELATED -j ACCEPT # Vsechno ostatni je zakazano - tedy logujeme, maxim. 12x5 pkt/hod $IPTABLES -A INPUT -m limit --limit 12/h -j LOG --log-prefix "INPUT drop: " # # Retezec OUTPUT # # Povolime odchozi pakety, ktere maji nase IP adresy $IPTABLES -A OUTPUT -s $LO_IP -j ACCEPT $IPTABLES -A OUTPUT -s $LAN_IP -j ACCEPT $IPTABLES -A OUTPUT -s $LAN_2IP -j ACCEPT $IPTABLES -A OUTPUT -s $LAN_3IP -j ACCEPT $IPTABLES -A OUTPUT -s $INET_IP -j ACCEPT $IPTABLES -A OUTPUT -s $INET_2IP -j ACCEPT $IPTABLES -A OUTPUT -s $INET_3IP -j ACCEPT $IPTABLES -A OUTPUT -s $INET_4IP -j ACCEPT $IPTABLES -A OUTPUT -s $TUN0_IP -j ACCEPT # Povolime DHCP broadcasty na LAN rozhrani $IPTABLES -A OUTPUT -o $LAN_IFACE -p UDP --dport 68 --sport 67 -j ACCEPT # Ostatni pakety logujeme (nemely by byt zadne takove) $IPTABLES -A OUTPUT -j LOG --log-prefix "OUTPUT drop: " #ulozime firewall pomoci iptables-save iptables-save > /etc/firewall-rules

105

Příloha 4 Konfigurační skript ejabberd: %%% %%% %%%

ejabberd configuration file

%%% ========= %%% DEBUGGING %% %% loglevel: Verbosity of log files generated by ejabberd. %% 0: No ejabberd log at all (not recommended) %% 1: Critical %% 2: Error %% 3: Warning %% 4: Info %% 5: Debug %% {loglevel, 4}. %% %% watchdog_admins: If an ejabberd process consumes too much memory, %% send live notifications to those Jabber accounts. %% {watchdog_admins, ["[email protected]"]}. %%% ================ %%% SERVED HOSTNAMES %% %% hosts: Domains served by ejabberd. %% You can define one or several, for example: %% {hosts, ["example.net", "example.com", "example.org"]}. %% {hosts, ["xxx.bz"]}. %%% =============== %%% LISTENING PORTS %% %% listen: Which ports will ejabberd listen, which service handles it %% and what options to start it with. %% {listen, [ {6222, ejabberd_c2s, [ {certfile, "/etc/ejabberd/ejabberd.pem"}, starttls, {access, c2s}, {shaper, c2s_shaper}, {max_stanza_size, 65536} ]}, %% %% To enable the old SSL connection method in port 5223:

106

%% {6223, ejabberd_c2s, [ {access, c2s}, {shaper, c2s_shaper}, {certfile, "/etc/ejabberd/ejabberd.pem"}, tls, {max_stanza_size, 65536} ]}, #jelikoz provozuji pouze vnitrofiremni server, moznost spoluprace #s ostatnimi servery bude vypnuta, tedy je zbytecne, aby server #na tomto portu vubec naslouchal % {5269, ejabberd_s2s_in, [ % {shaper, s2s_shaper}, % {max_stanza_size, 131072} % ]}, #toto je dulezity port pro webovou spravu {5280, ejabberd_http, [ http_poll, web_admin ]} ]}. %% %% S2S whitelist or blacklist %% %% Default s2s policy for undefined hosts. %% #pro jistotu, nechci jakekoli s2s konexe {s2s_default_policy, deny}. %%% ============== %%% AUTHENTICATION #autentizace bude probihat oproti databazi, nize je vse nastavene %% %% Authentication using ODBC %% Remember to setup a database in the next section. %% {auth_method, odbc}. %%% ============== %%% DATABASE SETUP %% ejabberd uses by default the internal Mnesia database, %% so you can avoid this section. %% This section provides configuration examples in case %% you want to use other database backends. %% Please consult the ejabberd Guide for details about database creation. %% %% MySQL server: %% {odbc_server, {mysql, "localhost", "ejabberd", "ejabberd", "mojetajneheslo"}}. %%% =============== %%% TRAFFIC SHAPERS %%

107

%% The "normal" shaper limits traffic speed to 1.000 B/s %% {shaper, normal, {maxrate, 1000}}. %% %% The "fast" shaper limits traffic speed to 50.000 B/s %% {shaper, fast, {maxrate, 50000}}. %%% ==================== %%% ACCESS CONTROL LISTS #zde se definuji pristupova prava, skupina admin jako skupina administratoru #skupina mucadmin jako skupina administratoru multiuzivatelskeho chatu %% %% The 'admin' ACL grants administrative privileges to Jabber accounts. %% You can put as many accounts as you want. %% {acl, admin, {user, "sinsky_martin", "xxx.bz"}}. {acl, admin, {user, "admin", "xxx.bz"}}. %% ACL for MUC admins, whoose can administer and create chatrooms {acl, mucadmin, {user, "admin", "xxx.bz"}}. {acl, mucadmin, {user, "sinsky_martin", "xxx.bz"}}. %% %% Local users: don't modify this line. %% {acl, local, {user_regexp, ""}}. %%% ============ %%% ACCESS RULES #zde je pokracovani definic pristupovych prav %% Define the maximum number of time a single user is allowed to connect: {access, max_user_sessions, [{10, all}]}. %% This rule allows access only for local users: {access, local, [{allow, local}]}. %% Only non-blocked users can use c2s connections: {access, c2s, [{deny, blocked}, {allow, all}]}. %% For all users except admins used "normal" shaper {access, c2s_shaper, [{none, admin}, {normal, all}]}. %% For all S2S connections used "fast" shaper {access, s2s_shaper, [{fast, all}]}. %% Only admins can send announcement messages: {access, announce, [{allow, admin}]}. %% Only admins can use configuration interface: {access, configure, [{allow, admin}]}. %% Admins of this server are also admins of MUC service: {access, muc_admin, [{allow, mucadmin}]}. %% All users are allowed to use MUC service: {access, muc, [{allow, all}]}.

108

#toto je dulezite, uzivatele se nemohou sami registrovat, #vse musi udelat admin predem %% Every username can be registered via in-band registration: %% To disable in-band registration, replace 'allow' with 'deny'. {access, register, [{deny, all}]}. %% Everybody can create pubsub nodes {access, pubsub_createnode, [{allow, all}]}. %%% ================ %%% DEFAULT LANGUAGE %% %% language: Default language used for server messages. %% {language, "cs"}. %% %% Set a different language in a virtual host. %% %%{host_config, "localhost", %% [{language, "ru"}] %%}. %%% ======= %%% MODULES #dulezita vlastnost ejabberd je jeho modularnost %% %% Modules enabled in all ejabberd virtual hosts. %% {modules, [ {mod_adhoc, []}, {mod_announce, [{access, announce}]}, % recommends mod_adhoc {mod_caps, []}, {mod_configure,[]}, % requires mod_adhoc {mod_disco, []}, %%{mod_echo, [{host, "echo.localhost"}]}, {mod_irc, []}, {mod_last_odbc, []}, {mod_muc, [ %%{host, "conference.@HOST@"}, {access, muc}, {access_create, muc_admin}, {access_persistent, muc_admin}, {access_admin, muc_admin}, {history_size, 100} ]}, {mod_muc_log,[ {access_log, muc_admin}, {cssfile, false}, {dirtype, plain}, {outdir, "/var/www/jablogs"}, {timezone, local} ]}, {mod_offline_odbc, []}, {mod_privacy_odbc, []}, {mod_private_odbc, []}, %%{mod_proxy65,[]}, {mod_pubsub, [ % requires mod_caps

109

{access_createnode, pubsub_createnode}, {plugins, ["default", "pep"]} ]}, {mod_register, [ %% %% After successful registration, the user receives %% a message with this subject and body. %% {welcome_message, {"Welcome!", "Welcome to this Jabber server."}}, %% %% When a user registers, send a notification to %% these Jabber accounts. %% %%{registration_watchers, ["[email protected]"]}, {access, register} ]}, {mod_roster_odbc, []}, %%{mod_service_log,[]}, {mod_shared_roster,[]}, {mod_stats, []}, {mod_time, []}, {mod_vcard_odbc, []}, {mod_version, []}, {mod_archive_odbc, [{database_type, "mysql"}, {default_auto_save, true}, {enforce_default_auto_save, false}, {default_expire, infinity}, {enforce_min_expire, 0}, {enforce_max_expire, infinity}, {replication_expire, 31536000}, {session_duration, 1800}, {wipeout_interval, 86400}]} ]}.

110

Příloha 5 Konfigurační soubory postfixu: main.cf: # See /usr/share/postfix/main.cf.dist for a commented, more complete version smtpd_banner = $myhostname ESMTP $mail_name biff = no # appending .domain is the MUA's job. append_dot_mydomain = no # Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h # TLS parameters smtpd_tls_cert_file=/etc/postfix/smtpd.cert smtpd_tls_key_file=/etc/postfix/smtpd.key smtpd_use_tls=yes smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache # See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for # information on enabling SSL in the smtp client. myhostname = gw.xx-xxx.com alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases mydestination = gw.em-agency.com, localhost relayhost = mynetworks = 127.0.0.0/8, 192.168.0.0/16 transport_maps = hash:/etc/postfix/transport #zde se mapuji jednotlive selecty do databaze virtual_alias_maps = mysql:/etc/postfix/mysql-virtual_forwardings.cf mysql:/etc/postfix/mysql-virtual_email2email.cf virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual_domains.cf virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual_mailboxes.cf virtual_mailbox_base = /home/vmail #definujeme jednoho usera a skupinu, pod kterou jsou maily ulozeny virtual_uid_maps = static:5000 virtual_gid_maps = static:5000 virtual_transport = dovecot smtpd_sasl_auth_enable = yes

111

broken_sasl_auth_clients = yes #zde jsou restrikce vuci klientum smtpd_client_restrictions = reject_unauth_pipelining #reject_rbl_client bl.spamcop.net, #reject_rbl_client opm.blitzed.org, #reject_rbl_client dnsbl.njabl.org #zde jsou restrikce vuci prijemcum smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_hostname, reject_unauth_destination mailbox_command = procmail -a "$EXTENSION" mailbox_size_limit = 0 message_size_limit = 20480000 recipient_delimiter = + inet_interfaces = 127.0.0.1, 192.168.0.1, 192.168.2.1, x.x.148.178 content_filter = smtp-amavis:[127.0.0.1]:10024 receive_override_options = no_address_mappings inet_protocols = ipv4 readme_directory = /usr/share/doc/postfix html_directory = /usr/share/doc/postfix/html mysql-virtual_domains.cf: user = vmail_admin password = xxx dbname = vmail table = domains select_field = 'virtual' where_field = domain hosts = 127.0.0.1 mysql-virtual_email2email.cf: user = vmail_admin password = xxx dbname = vmail table = users select_field = email

112

where_field = email hosts = 127.0.0.1 mysql-virtual_forwardings.cf: user = vmail_admin password = xxx dbname = vmail table = forwardings select_field = destination where_field = source hosts = 127.0.0.1 mysql-virtual_mailboxes.cf: user = vmail_admin password = xxx dbname = vmail table = users select_field = CONCAT(SUBSTRING_INDEX(email,'@',1),'/',SUBSTRING_INDEX(email,'@',1),'/') where_field = email hosts = 127.0.0.1

113

Příloha 6 Ukázka konfigurace Nagios: define service { hostgroup_name debian-servers service_description disks check_command check_nrpe_1arg!check_all_disks use generic-service notification_interval 120 } define service { hostgroup_name debian-servers service_description swap check_command check_nrpe_1arg!check_swap use generic-service notification_interval 120 } define service { hostgroup_name debian-servers service_description load check_command check_nrpe_1arg!check_load use generic-service notification_interval 120 } define service { hostgroup_name hwraidareca-servers service_description raid-areca check_command check_nrpe_1arg!check_areca use generic-service notification_interval 120 } define service { hostgroup_name swraid-servers service_description raid-sw-md check_command check_nrpe_1arg!check_md use generic-service notification_interval 120 } define service{ use hostgroup_name service_description check_command } define service{ use hostgroup_name service_description

generic-service ; Inherit values from a template switches uptime check_snmp!-C public -o sysUpTime.0

generic-service ; Inherit values from a template ups uptime

114

check_command

check_snmp!-C public -o sysUpTime.0

} define service{ use hostgroup_name service_description check_command }

generic-service ; Inherit values from a template ups load check_snmp!-C public -o mib-2.33.1.4.4.1.5.1

define service{ use hostgroup_name service_description check_command }

generic-service ; Inherit values from a template ups temperature check_snmp!-C public -o mib-2.33.1.2.7.0

define service{ use hostgroup_name service_description check_command }

generic-service ; Inherit values from a template ups battery_capacity check_snmp!-C public -o mib-2.33.1.2.4.0

#define service{ # use # host # service_description # check_command #} define service{ use host service_description check_command } define service{ use host service_description check_command }

generic-service ; Inherit values from a template gsm01 uptime check_snmp!-C public -o sysUpTime.0

generic-service ; Inherit values from a template gw amavis check_nrpe_1arg!check_amavis

generic-service ; Inherit values from a template pbx2 vodafone_microwave check_nrpe_1arg!check_ping_vodafone

115

Příloha 7 Startup skript pro běh IDS: #! /bin/sh # ### BEGIN INIT INFO # Provides: snortbarn # Required-Start: $remote_fs $syslog mysql # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # X-Interactive: true # Short-Description: Start Snort and Barnyard ### END INIT INFO . /lib/init/vars.sh . /lib/lsb/init-functions mysqld_get_param() { /usr/sbin/mysqld --print-defaults \ | tr " " "\n" \ | grep -- "--$1" \ | tail -n 1 \ | cut -d= -f2 } do_start() { log_daemon_msg "Starting Snort and Barnyard" "" # Make sure mysql has finished starting ps_alive=0 while [ $ps_alive -lt 1 ]; do pidfile=`mysqld_get_param pid-file` if [ -f "$pidfile" ] && ps `cat $pidfile` >/dev/null 2>&1; then ps_alive=1; fi sleep 1 done /sbin/ifconfig eth1 up /usr/local/bin/snort -q -u snort -g snort -c /etc/snort/snort.conf -i eth0 & /usr/local/bin/barnyard2 -q -c /etc/snort/barnyard2.conf -d /var/log/snort -f snort.log w /etc/snort/bylog.waldo \ -G /etc/snort/gen-msg.map -S /etc/snort/sid-msg.map -C /etc/snort/classification.config 2> /dev/nul & log_end_msg 0 return 0

116

} do_stop() { log_daemon_msg "Stopping Snort and Barnyard" "" kill $(pidof snort) 2> /dev/nul kill $(pidof barnyard2) 2> /dev/nul log_end_msg 0 return 0 } case "$1" in start) do_start ;; stop) do_stop ;; restart) do_stop do_start ;; *) echo "Usage: snort-barn {start|stop|restart}" >&2 exit 3 ;; esac exit 0

117

Zdroje a použitá literatura Tištěné monografie [1]

DOBDA, L. Ochrana dat v informačních systémech. Grada Publishing, spol. s r.o., 1998. ISBN 80-7169-479-7

[2]

KUCHAŘ, M. Bezpečná síť. Grada Publishing, 1999. ISBN 80-7169-886-5

[3]

PŘIBYL,

T.

Actinet

informačních

[online].

2010

technologií.

[cit.

2011-02-10].

Dostupné

Bezpečnost z WWW:

. Webovská sídla [4]

AEC [online]. 2009 [cit. 2011-03-20]. Služby informační bezpečností. Dostupné

z WWW:


bezpecnosti>. [5]

ČIMIB [online]. 2010 [cit. 2011-02-02]. Český institut manažerů informační bezpečnosti. Dostupné z WWW: .

[6]

GFI [online]. [cit. 2011-01-15]. UK SMEs understimate Langer posed by thein employees. Dostupné z WWW: <www.gfi.cz/company/news-andevents/press-releases/2009/uk-smes-drastically-under.htm>.

[7]

Wikipedia [online]. 2010 [cit. 2011-01-10]. Computer security. Dostupné z WWW: .

[8]

Workaround [online]. 2007 [cit. 2011-06-20]. Preparing the Database. Dostupné z WWW: .

Články v tištěných seriálech [9]

MATYÁŠ, J. Do banky chodím osobně, znám rizika internetu, říká vědec. Lidové noviny. 2011, 4. ledna, s. 32.

118