Monitor zpráv dle ISO8583

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Bakalářská práce

Monitor zpráv dle ISO8583 Jan Koktan

Vedoucí práce: Ing. Jan Kubr Studijní program: Softwarové technologie a management Obor: Softwarové inženýrství

4.ledna 2011

Poděkování Chtěl bych poděkovat Aleši Sokolovi za vstřícnost při studiu.

ii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 7.1.2011

………………………………………

iii

iv

Abstract In this thesis I’ve designed and described an implementation of my application for monitoring message flows according to the ISO8583 standard. I’ve put emphasis on monitoring using a method of passive network traffic capture and data processing respecting PCI/DSS requirements.

Abstrakt V této práci jsem navrhnul a popsal implementaci aplikace určené ke sledování výměny zpráv dle standardu ISO8583. Důraz jsem kladl na sledování metodou pasivního odposlechu síťového provozu a zpracování dat dle požadavků standardu PCI/DSS.

v

vi

Obsah 1

Úvod ...............................................................................................................................- 1 -

2

Stručný popis ISO protokolu.........................................................................................- 2 2.1

Formát ISO 8583 zprávy .................................................................................................- 2 -

2.2

Výměna zpráv...................................................................................................................- 3 -

3

Popis řešeného problému ..............................................................................................- 5 -

4

Analýza problému..........................................................................................................- 6 4.1

Varianta „aplikační brána“ ............................................................................................- 6 -

4.2

Varianta „zachycení systémových volání“.....................................................................- 7 -

4.3

Varianta „síťový odposlech“...........................................................................................- 7 -

4.3.1 4.3.2

5

4.4

Porovnání variant ............................................................................................................- 9 -

4.5

Dekódování ISO zpráv ..................................................................................................- 10 -

4.6

Požadavky PCI/DSS.......................................................................................................- 10 -

4.7

Datové úložiště................................................................................................................- 11 -

Popis implementace.....................................................................................................- 12 5.1

Architektura řešení........................................................................................................- 12 -

5.2

Implementace SA ...........................................................................................................- 12 -

5.3

Implementace MISO......................................................................................................- 13 -

5.3.1 5.3.2 5.3.3 5.3.4

6

7

8

Architektura programu MISO ...................................................................................................- 13 Průběh zpracování v aplikaci MISO..........................................................................................- 14 Převzetí dat od SA.....................................................................................................................- 15 Implementace PCI/DSS požadavků pro MISO .........................................................................- 16 -

Testy aplikace ..............................................................................................................- 18 6.1

Zkušební verze ...............................................................................................................- 18 -

6.2

Vývojové testování .........................................................................................................- 18 -

6.3

Funkční testy ..................................................................................................................- 18 -

6.4

Výkonnostní testy...........................................................................................................- 19 -

Návod k použití ............................................................................................................- 20 7.1

Instalace ..........................................................................................................................- 20 -

7.2

Spuštění aplikace SA......................................................................................................- 20 -

7.3

Spuštění aplikace MISO ................................................................................................- 21 -

Závěr ............................................................................................................................- 23 8.1

9

varianta „síťový odposlech - wireshark“.....................................................................................- 8 varianta „síťový odposlech - libnids“..........................................................................................- 8 -

Možnosti dalšího rozvoje...............................................................................................- 23 -

Literatura .....................................................................................................................- 24 -

Příloha A - obsah přiloženého CD.....................................................................................- 25 Příloha B – vzorový protokol o běhu ..................................................................................- 26 Příloha C – vzorový výstup..................................................................................................- 27 -

vii

Seznam obrázků Obrázek 2-1 hlavní části ISO zprávy .....................................................................................- 2 Obrázek 2-2 příklad výměny zpráv dle ISO protokolu ..........................................................- 3 Obrázek 4-1 schéma nasazení ,,aplikační brána" ...................................................................- 6 Obrázek 4-2 schéma nasazení ,,zachycení sys. volání"..........................................................- 7 Obrázek 4-3 schéma nasazení ,,síťový odposlech s libnids"..................................................- 9 Obrázek 5-1 průběh zpracování zpráv v MISO ...................................................................- 14 -

Seznam tabulek Tabulka 4-1 porovnání variant ...............................................................................................- 9 Tabulka 5-1 příklad konfigurace skrytí pole č.35 ................................................................- 17 -

viii

1 Úvod Cílem mé práce je navržení aplikace pro zachytávání a dekódování zpráv dle standardu ISO 8583 [1]. Tento standard specifikuje formát zpráv, určených pro finanční transakce (někdy označované též jako EFT – Electronic Fund Transfer) prováděné platebními kartami. Smyslem aplikace je zachycené zprávy dekódovat a uložit do databáze pro pozdější analýzu výměny těchto zpráv mezi aplikacemi. Standard ISO 8583 definuje pouze formát a význam zpráv. Způsob kódování zpráv při přenosu není určen, a proto existuje mnoho různých způsobů jak zprávu přenést po komunikační lince: od dnes již opouštěných protokolů SNA a X.251 přes TCP/IP se zavedeným rámcováním až po XML kódované zprávy v souborech.

1

Označení zastaralých síťových protokolů. SNA – IBM System Network Architecture, X.25 – ITU-T X.25

-1-

2 Stručný popis ISO protokolu 2.1 Formát ISO 8583 zprávy Samotná zpráva je tvořena třemi hlavními částmi: MTI, primární (volitelně i sekundární či terciární) bitmapa a datové pole. Obrázek 2-1 znázorňuje pořadí těchto částí.

Obrázek 2-1 hlavní části ISO zprávy

První část, zvaná Message Type Indicator (MTI), je čtyřciferné číslo charakterizující typ zprávy (kódováno v řádu stovek) a bližší určení funkce (kódováno v řádu desítek a jednotek). Příkladem může být 0200 (nová platba), 0400 (zrušení transakce) nebo 0800 (služební zpráva). Druhá část je tvořena jednou až třemi bitmapami. Každá bitmapa je tvořena 64 bity, kde každý bit udává přítomnost či nepřítomnost daného pole. Poslední bit každé bitmapy určuje zda následuje další bitmapa. První bitmapa je povinná, druhá a třetí je volitelná. Třetí částí jsou pak samotná pole s přenášenými hodnotami. Obsah jednotlivých polí je formátován dle standardu různými způsoby (s pevnou délkou / s prefixem délky), v některých případech může být jednotlivé pole dále členěno do podpolí. Standard ISO8583 existuje ve třech verzích, pojmenovaných dle data standardizace, ISO 8583-1:1987, ISO 8583-2:1993 a ISO 8583-1:2003. V této práci se počítá s verzí z roku 1987.

-2-

2.2 Výměna zpráv Samotný standard ISO 8535 specifikuje jen formát a význam zpráv, celkový protokol pro výměnu těchto zpráv není určen a je poplatný konkrétní aplikaci. V minulosti byly často používány dnes již zastaralé síťové protokoly jako je IBM SNA nebo ISO X.25. U zařízení, kde nebylo možné použít tyto nákladné technologie, jako jsou třeba platební terminály na pokladně u obchodníka, byl (a je stále doposud) použit přenos přes asynchronní sériovou linku s vloženými PSTN2 modemy. V současné době jsou tyto zastaralé síťové technologie nahrazeny protokolovým zásobníkem TCP/IP.

Obrázek 2-2 příklad výměny zpráv dle ISO protokolu

Při použití protokolu TCP je nutné dodefinovat další parametry výměny zpráv: •

2

síťová relace. Specifikace která strana navazuje spojení. Dále která z komunikujících aplikaci ukončuje spojení a za jakých podmínek.

Public Switched Telephone Network – označuje veřejnou telefonní síť s klasickou technologií, nikoliv VoIP

-3-

•

•

delimitace zpráv. TCP protokol je proudově orientovaný, příjemce nedokáže rozlišit jednotlivé zprávy a může dojít ke sloučení více zpráv nebo naopak k přijetí jen fragmentu jedné ISO zprávy3. Pro vyčlenění jedné zprávy z proudu bytů jsou proto jednotlivé zprávy odděleny zvláštním znakem, nebo jsou předřazeny délkou v bytech. kódování délky zprávy a znakové sady. Délka zprávy může být kódována binárně v big-endian nebo little-endian formátu různé délky, nebo je kódována textově. Znaková sada samotné ISO zprávy a (textově vyjádřené) délky může být ASCII nebo EBCDIC4.

Obrázek 2-2 znázorňuje příklad vzorové výměny zpráv představující autorizace prodejní transakce. Světle modrý obdélník „POS“ představuje platební terminál, číslované modré obdélníky znázorňují ISO zprávy jím poslané. Číslované tyrkysové obdélníky pak představují ISO zprávy, jimiž autorizační aplikace odpovídá na zprávy terminálu.

3 4

Pojem ISO zpráva v tomto dokumentu vždy představuje zprávu dle standardu ISO 8583-1:1997. Jména znakových sad: ASCII - American Standard Code for Information Interchange, EBCDIC - Extended Binary Coded Decimal Interchange Code

-4-

3 Popis řešeného problému Smyslem navrhované aplikace je umožnit sledování výměny ISO zpráv mezi dvěmi zařízeními/aplikacemi na úrovni síťové komunikace. Analýzou zaznamenaných ISO zpráv bude možné objasnit chování aplikace, efektivněji identifikovat případné chyby a zjistit rychlost odezvy sledovaných zařízení/aplikací. Při řešení problému, jakým způsobem sledovat ISO zprávy mezi dvěmi různými aplikacemi jsem zohlednil následující požadavky: • samotné sledování nesmí ovlivňovat tok zpráv mezi sledovanými aplikacemi • sledování nesmí ovlivňovat sledované aplikace. V krajním případě havárie sledovací aplikace nesmí nijak ohrozit činnost sledovaných aplikací. • sledovací aplikace nesmí předpokládat konkrétní aplikaci, musí být použitelná pro libovolnou aplikaci komunikující protokolem ISO 8583 přes TCP/IP. • sledovací aplikace by měla být univerzální, neměla by předpokládat konkrétní kódování zpráv. Schopnost přizpůsobit se použitému kódování nebude vyžadovat změnu v kódu, jen změnu konfigurace. • aplikace bude schopna dekódovat ISO zprávy včetně strukturovaných polí a zjištěné hodnoty ukládat v textové podobě pro pozdější analýzu. • aplikace bude schopná samostatného běhu na pozadí, s možností pozdější analýzy zachycených dat. Dalším nutným požadavkem je splnění bezpečnostní oborové normy PCI/DSS [3]. Tato norma ukládá mnoho povinností, jejichž smyslem je zamezení neoprávněného přístupu k citlivým datům, tykajících se elektronických transakcí platebními kartami.

-5-

4 Analýza problému Monitorovací aplikace je možné rozdělit na tři hlavní funkční celky: • získání dat sledovaných aplikací • dekódování zpráv na jednotlivá pole a podpole • uložení těchto polí pro následnou analýzu. Získání požadovaných dat je možné více způsoby, jež se principem velmi liší. Jednotlivé varianty jsou proto popsány v samostatném odstavci.

4.1 Varianta „aplikační brána“

Obrázek 4-1 schéma nasazení ,,aplikační brána"

První varianta řešení je využití modelu monitorující aplikační brány. Monitorovací aplikace by při tomto způsobu pracovala jako příjemce i odesílatel zpráv, které by nijak nemodifikovala, jen by je po zaznamenání přeposlala skutečnému příjemci. Tento způsob řešení má mnoho předností. Je snadno použitelný vzhledem ke skutečnosti, že monitorovací aplikace se při tomto modelu chová jako standardní příjemce/odesílatel ISO zpráv, což velmi usnadňuje využití knihoven třetích stran, které mají API navržené právě pro tento případ. Další velkou výhodou je možnost využití standardního síťového rozhraní dané platformy. Jeho využití je implementačně velmi jednoduché, na rozdíl od složitého přístupu k datům v ostatních variantách. Splnění požadavku na nezávislost na konkrétní aplikaci a konkrétní variantě kódování ISO protokolu je u této varianty jednoduché a přirozené. Nevýhodou této varianty je nutnost včlenit monitorovací aplikaci mezi dvě sledované. Toto včlenění může způsobit riziko ovlivňování sledovaných aplikací. Chyba v implementaci monitorovací aplikace může způsobit to, že přeposlané ISO zprávy nebudou přesně odpovídat přijatým zprávám, v krajním případě havárie monitorovací aplikace způsobí úplnou nefunkčnost sledovaných aplikací. Některé vlastnosti předaných ISO zpráv nelze z principu nijak zachovat – rozdělení dat do TCP segmentů a jejich časování se při průchodu monitorující aplikací ztratí. Tuto variantu jsem pro zmíněné riziko ovlivnění sledovaných aplikací zavrhnul. Obrázek 4-1 schématicky znázorňuje možný scénář nasazení.

-6-

4.2 Varianta „zachycení systémových volání“

Obrázek 4-2 schéma nasazení ,,zachycení sys. volání"

Podstatou této varianty je implementace knihovny zachycující síťová systémová volání sledované aplikace. Knihovna funkcí, implementovaná v jazyce C, je prostředky operačního systému využitím proměnné prostředí LD_PRELOAD inicializována při startu aplikace. Knihovnu funkcí tvoří funkce se stejným jménem jako mají systémová volání. Tímto je zajištěno převzetí běhu programu (sledované aplikace) při systémových voláních. Zachycením systémových volání read a write (připadně i recv a send) dokáže knihovna získat přístup k odesílaným či přijímaným datům. Výhodou této varianty je možnost sledování provozu beze změny konfigurace sledované aplikace (na rozdíl od předchozí varianty), což zjednodušuje případné operativní nasazení sledování. Nevýhody této varianty jsou: • obtížnější přenositelnost mezi platformami. V případě jednoúčelových průmyslových zařízení (platební terminály) pak úplná nemožnost nasazení. • nutnost restartu sledované aplikace v případě nové verze monitorující aplikace. • Obtížnější využití již existujících knihoven třetích stran pro dekódování ISO formátu. Důvod je stejný jako u varianty „aplikační brána“, API5 těchto knihoven je navrženo pro jiný účel. • Možnost ovlivnění sledované aplikace chybou v implementaci monitorující aplikace Tuto variantu jsem zavrhl pro její náročnou implementaci na různých platformách a hlavně pro možnost ovlivnění sledované aplikace. Obrázek 4-2 znázorňuje možný scénář nasazení.

4.3 Varianta „síťový odposlech“ Po zvážení nevýhod předchozích variant, zejména rizika vzájemné nežádoucí interakce, jsem se rozhodl rozpracovat variantu získávaní dat pomocí síťového odposlechu. Samotné získání dat odposlechem je nutné realizovat na stejném počítači, nebo je nutné mít k dispozici síťový prvek s funkcí přeposílání kopie sledovaných paketů/rámců. Tato funkce je 5

Application Programming Interface – sada funkcí knihovny určená k použití jinými programy

-7-

často nazývána „port mirroring“. Pro testy jsem využil tuto funkci na ethernetovém přepínači firmy Cisco, která ji nazývá „SPAN port“. Obrázek 4-3 znázorňuje schéma nasazení této varianty. Odposlechnuté pakety lze zpracovávat speciální knihovnou. Zvolil jsem knihovnu libpcap[4], jelikož se jedná o v podstatě jedinou použitelnou open-source knihovnu. První velkou nevýhodou této varianty je fakt, že takto zachycená data mají podobu zachycených paketů, nikoliv proudu bytů aplikačních dat přenášených protokolem TCP. Z paketů je tedy nejprve třeba vybrat jednotlivá TCP spojení a z těchto spojení pak zrekonstruovat přenášená aplikační data. Rekonstrukce jednotlivého TCP/IP proudu je implementačně náročná, je potřeba se vypořádat se ztracenými nebo zduplikovanými IP pakety a fragmenty, dále se ztracenými, zduplikovanými TCP segmenty či TCP segmenty mimo pořadí. Protože se funkčně jedná o de-facto kompletní implementaci TCP/IP protokolového zásobníku, rozhodl jsem se použít již existujícího software.

4.3.1 varianta „síťový odposlech - wireshark“ První možností, jak zrekonstruovat proud dat ze zachycených paketů TCP proudu, je využití existující aplikace určené právě pro tento účel – aplikace wireshark/tshark[6]. Monitorovací aplikace by pak byla zásuvným modulem do této aplikace, dle terminologie používané vývojáři wiresharku by se jednalo o „protocol dissector“. Bohužel aplikace wireshark/tshark jsou určené pro interaktivní práci a nehodí se pro monitorovací aplikaci, která musí být schopna soustavného běhu a kdy vyhodnocení zachycených ISO zpráv proběhne až zpětně.

4.3.2 varianta „síťový odposlech - libnids“ Druhou možností, jak zrekonstruovat proud dat ze zachycených paketů TCP proudu, je využití nikoliv existující aplikace, ale jen knihovny určené tento účel. Z dostupného open source software jsem úspěšně otestoval knihovnu libnids [5]. Knihovna libnids byla od začátku navržena jako základní stavební kámen NIDS bezpečnostních systémů (Network Intrusion Detection Systém), proto její schopnost znovusestavení proudu dat přenášených TCP proudem je velmi robustní. Nevýhodou této varianty je obtížné využití API knihoven třetích stran na dekódování protokolu ISO 8583.

-8-

Obrázek 4-3 schéma nasazení ,,síťový odposlech s libnids"

4.4 Porovnání variant Po porovnání výhod a nevýhod všech variant jsem se rozhodl implementovat variantu síťového odposlechu s využitím knihoven libpcap a libnids. Tabulka 4-1 obsahuje srovnávací kritéria, rozhodující kritérium bylo nezávislost sledovaných aplikací/zařízení na monitorovací aplikaci. Zvolená varianta je v tabulce uvedena pod názvem libnids. Varianta / Vlastnost

Aplikační brána

Systémové volání

*shark

libnids

Ovlivnění toku dat

značné

žádné

žádné

žádné

Možné ovlivnění sledovaných aplikací

značné

značné

žádné

žádné

Univerzálnost nasazení

vyhovující

problematická

vyhovující vyhovující

Možnost běhu na pozadí

vyhovující

vyhovující

nelze

vyhovující

Použití API pro dekódování

snadné

obtížné

obtížné

obtížné

Tabulka 4-1 porovnání variant

-9-

4.5 Dekódování ISO zpráv Ze zrekonstruovaného TCP/IP proudu je možné získat samotná přenášená data. V těchto datech jsou obsaženy ISO zprávy včetně oddělujících záhlaví. V některých případech můžou být v proudu dat obsaženy ještě doplňující, standardu ISO8583 neodpovídající, specifická záhlaví. V datovém toku jsem nalezl jen jedno specifické záhlaví, a sice číslo platebního terminálu ASCII znakově kódované v prvních 8 bytech. Toto číslo je odesláno ihned po navázání TCP/IP spojení a je využíváno pro identifikaci terminálu autorizační aplikací. Zachycení tohoto nestandardního záhlaví a jeho odstranění z proudu dat (není ISO zprávou, musí být odstraněno aby nemohlo být mylně interpretováno jako začátek ISO zprávy) bude nutné implementovat před zpracováním následujících dat. Odstraněním nestandardních záhlaví zbudou v zachyceném proudu dat jen samotné ISO zprávy. Samotný formát ISO8583 je poměrně složitý, zejména kvůli možnosti kódovat jednotlivá pole rozdílnými způsoby. Například pro číselnou hodnotu je možné zvolit kódování znakově v ASCII nebo EBCDIC podobě, v BCD kódovaném řetězci, či nakonec v čistě binární nebo BCD binární podobě. Konkrétní forma je daná pro každou sledovanou aplikaci. Z těchto důvodů jsem se rozhodl použít existující knihovnu pro dekódování ISO zpráv. Z existujících open source knihoven jsem uvažoval mezi knihovnou j8583 a jPOS. Zvolil jsem knihovnu jPOS, oproti j8583 je její funkčnost mnohem rozsáhlejší a dle referencí [2] je často využívána i pro komerční účely ve velkém měřítku. To dává větší jistotu, že funkčnost knihovny je dobře prověřená a bude rozvíjená i do budoucna.

4.6 Požadavky PCI/DSS Standard PCI/DSS je oborový bezpečnostní předpis pro oblast platebních karet. Předepisuje povinnosti každé instituce pracující s daty obsahující údaje z platebních karet. A protože monitorovací aplikace bude pracovat právě s těmito citlivými údaji, je nutné zvolit takovou implementaci, aby byly požadavky tohoto standardu splněny. Standard PCI/DSS je rozsáhlý a požaduje splnění mnoha požadavků, jež jsou svou povahou sahají od velmi obecných (používejte silnou kryptografii) až po velmi konkrétní (změňte hesla nastavená výrobcem). Motivací tohoto standardu je snížit riziko úniku dat, která by mohla být použita pro provedení falešných platebních transakcí. Hlavní myšlenkou tohoto standardu je: • zamezení ukládání dat, jež jsou svou povahou velmi kritická a není nutné je uchovávat (CVV2/CAV26, PIN Blok7, ekvivalent druhé magnetické stopy) • zavedení přísných pravidel pro ukládání čísla karty. Jsou-li čísla karet uchovávána spolu s doprovodnými údaji, jako je datum platnosti karty, platí tato omezení i na tyto údaje.

6 7

CVV2 a CAV2 jsou kryptograficky chráněné kontrolní součty používané k ověření autenticity karty Pole obsahující šifrovaný PIN

- 10 -

Monitorovací aplikace tedy musí bezpodmínečně umožnit neukládání dat, u nichž je to standardem zakázáno. Dalším požadavkem je schopnost uložení dat v částečně pozměněné podobě.Tato vlastnost, obzvláště bude-li použita u čísel karet, umožní uložit jen část zachycené hodnoty a přístup k uloženým zachyceným datům nebude podléhat PCI/DSS režimu. Při vývoji aplikace je nutné mít na zřeteli, že citlivá data se nesmí objevit nejenom v regulérním výstupu aplikace (tj v databázi), ale ani v diagnostických log souborech.

4.7 Datové úložiště Monitorovací aplikace musí ukládat dekódované ISO zprávy ve tvaru vhodném k pozdější analýze. Vhodným řešením by mohlo být ukládání dat do textových souborů, nebo do SQL databáze. Použití textového souboru/ů by přineslo efektivnější využití místa v datovém úložišti (obzvláště při kompresi), nicméně dohledávání jednotlivých zpráv by bylo velmi pracné, nebo by vyžadovalo vyvinout další aplikaci určenou k prohlížení uložených dat. Předpokládaný způsob vyhledávání v datech lze jen stěží předem odhadnout, protože aplikace je primárně určena pro zjišťování závad a problémů, jejichž charakter je různorodý a nepředvídatelný. Využití SQL databáze je sice náročnější na velikost datového úložiště (obzvláště při dlouhodobém monitorování může být množství dat značné), ale výhoda univerzálnosti dotazovacího jazyka SQL je přesvědčivá. Datové úložiště jsem se rozhodl realizovat v relační SQL databázi. Konkrétně jsem zvolil databázi Oracle, se kterou mám největší zkušenosti.

- 11 -

5 Popis implementace 5.1 Architektura řešení Při návrhu architektury řešení byla nejvíce omezující skutečnost, že zvolené programátorské knihovny jsou implementovány v odlišných jazycích – knihovny libpcap a libnids jsou napsány v jazyce C, knihovna jPOS je v jazyce Java. Java sice umožňuje využití knihoven psaných v jazyku C dle specifikace JNI, tento způsob je ale nevýhodný, protože vlastnosti JNI komplikují či znemožňují hledání chyb nebo využití některých technik, jako je třeba práce se signály v unixových systémech. Dále obě knihovny libnids i jPOS používají techniku inverze volání, což by přineslo složitější implementaci. Pro výše uvedené nevýhody jsem se rozhodl rozdělit aplikaci na dva různé programy. První část, pojmenovaná SA (= Sniffing Agent), je samostatný program implementovaný v jazyce C a využívá knihovny libnids pro příjem paketů . Druhá část je samostatný program. implementovaný v jazyce Java, využívájící knihovny jPOS pro dekódování přijatých zpráv. Tato druhá část se jmenuje Monitor ISO zpráv, zkráceně MISO. Oba dva programy spolu komunikují specifickým protokolem navrženým pro tento účel za pomoci frameworku Google Protocol Buffers [7] (dále jen GPB) přes TCP/IP. GPB je framework generující C a Java kód s implementací síťového protokolu dle zadaného souboru. Tento soubor tedy určuje význam polí daného protokolu, a vygenerovaný kód umožňuje rychlou a komfortní výměnu dat daným protokolem. Výhodou tohoto rozdělení je navíc možnost v budoucnosti upravit aplikaci tak, aby jedna instance MISO dokázala přijímat zachycená data z více instancí SA. Běh více instancí SA je nutný, bude-li třeba sledovat síťový provoz aplikací běžících v různých částech firemní sítě, například při provozu v jiném datovém centru nebo v odděleném segmentu sítě, typicky demilitarizované zóně8.

5.2 Implementace SA Program SA získává data voláním funkcí knihovny libnids. Libnids zase získává data z knihovny libpcap. Knihovna libpcap je v podstatě jediná knihovna pro přístup k zachyceným paketům běžící na většině unixových operačních systémech, proto se stala základním stavebním kamenem téměř všech open source aplikací určených pro analýzu síťového provozu jako je tcpdump nebo wireshark. Velmi užitečnou vlastností libpcap je schopnost načítat odposlechnuté pakety nejenom v reálném čase ze síťového rozhraní, ale i z předem připraveného souboru. Tato vlastnost je velmi důležitá pro testování celé aplikace, kde umožnila opakované testy s neměnnými vstupními daty. V opačném případě by všechny testy musely probíhat na reálném provozu, který je velmi proměnlivý a znemožnilo by to opakovaně testovat konkrétní testovací scénář. Knihovna libpcap však pracuje s pakety na nízké úrovni, nedokáže nijak pracovat s TCP protokolem. Tento nedostatek jsem odstranil právě použitím knihovny libnids, která je schopna provést rekonstrukci datového toku přenášeného TCP protokolem. Korektní rekonstrukce datového toku je velmi důležitá, v každé síti dochází ke ztrátám paketů nebo k doručení mimo pořadí. Bez libnids by MISO aplikace získávala datový proud, ve kterém by některá data byla nesprávně duplicitní a/nebo by byla v nesprávném pořadí a mohlo by dojít například k promíchání dvou různých ISO zpráv. 8

DMZ (demilitarizovaná zóna) je částečně izolovaný¨typ sítě, určený pro provoz aplikací s vyšší mírou zabezpečení

- 12 -

Při prvních testech jsem navíc zjistil, že k duplicitnímu doručování paketů dochází u některých TCP spojení vždy. Je to zaviněno nikoliv velkou ztrátovostí paketů v testovací síti a následnými opakovanými doručeními, jak jsem původně předpokládal, ale specifickým nastavením SPAN portu. SPAN port jsem nastavil na sledování obou dvou směrů u dvou ethernet portů, abych mohl sledovat síťový provoz dvou aplikací běžících na dvou různých serverech. Zároveň však dochází k výměně ISO zpráv mezi těmito dvěma servery a protože jsou SPAN portem zaznamenávány oba dva směry u obou dvou portů, obdrží běžící instance SA právě dvě kopie téhož paketu. Po obdržení dat z libnids je SA doplní pomocnými údaji jako je časové razítko, IP adresy a porty zachyceného TCP proudu a takto strukturovanou zprávu serializuje za pomocí knihovny vygenerované frameworkem GPB. Serializovanou zprávu pak odešle TCP spojením druhému programu MISO. TCP spojení mezi programy SA a MISO navazuje vždy MISO. PCI požadavky vztahující se na SA jsou dvojího druhu: neukládat zakázané informace na diskové úložiště a zajistit kontrolu přístupu k datům. Protože program SA neumí nijak dekódovat ISO zprávy obsažené v datech (toto zpracování provádí až MISO), neumí ani určit která data je možné uložit a která nikoliv. Proto v diagnostických log souborech nemůžou být uložena žádná přijatá data. Druhý požadavek na kontrolu přístupu k datům je splněn omezením komunikace jen na server s běžící aplikací MISO prostředky operačního systému.

5.3 Implementace MISO 5.3.1 Architektura programu MISO Při návrhu architektury samotné aplikace MISO jsem využil návrhový vzor SEDA, Staged Event Driven Architecture [8]. Podstatou architektury SEDA je rozdělení programu na více samostatně běžících procesů/vláken, jež si spolu vyměňují zpracovávané požadavky pomocí front. Každé vlákno (nebo skupina vláken) pak přijímá požadavky ze své vstupní fronty, částečně je zpracuje a posléze je předá do výstupní fronty dalšímu vláknu. Zpracování jednoho požadavku je tedy rozděleno do více etap. (stages), zpracování požadavku v každém kroku je prováděno jiným vláknem. Každým vláknem tedy projdou postupně všechny požadavky, ale toto vlákno provádí vždy jen část samotného zpracování. Tato odlišnost charakterizuje návrhový vzor SEDA od ostatních, jako je velmi často používaný vzor souběžného zpracování dedikovanými vlákny, kde jedno vlákno zpracovává právě jeden požadavek od začátku do konce (např. model Apache prefork). Výhodou vzoru SEDA je využití paralelismu při zpracovávání požadavků bez nutnosti koordinace přístupu ke sdíleným prostředkům, například spojení do databáze. Tento přístup tedy umožňuje dosažení větší rychlosti běhu programu částečnou paralelizací zpracování současně s nižším rizikem chybného souběhu (race condition). Předáváním rozpracovaného požadavku do další etapy pomocí front se program lépe vyrovná s krátkodobým přetížením jednotlivých etap a navíc lze toto přetížení dobře monitorovat sledováním hloubky fronty. Pokud je některá etapa zpracování časově náročná, může ji být přiřazeno více vláken nebo může být počet vláken dynamicky přizpůsobován. Této vlastnosti jsem využil pro etapu, kde dochází k samotnému dekódování ISO zpráv – každé sledované TCP spojení využívá dvojici vláken pro dekódování. Nevýhodou architektury SEDA je obtížnější řešení běhových chyb, ke kterým dochází z principu opožděně a obtížnější trasování jednoho vstupního požadavku při průchodu jednotlivými etapami zpracování.

- 13 -

5.3.2 Průběh zpracování v aplikaci MISO Zpracování příchozích zpráv v programu MISO jsem rozdělil do čtyř etap: • Přijmutí zprávy od SA, identifikace spojení a předání do fronty dekodéru • Načtení zprávy. - neobsahuje-li ISO zprávu (např. zpráva o ukončení sledovaného spojení), vytvoření záznamu pro uložení a jeho předání do fronty pro zápis do databáze. - obsahuje-li ISO zprávu, předání do fronty ISO dekodéru. • Dekódování ISO zprávy, vytvoření záznamů pro uložení obsahu polí a podpolí do databáze, předání do fronty pro zápis do databáze • Načtení záznamů pro uložení a provedení samotného zápisu do databáze.

Obrázek 5-1 průběh zpracování zpráv v MISO

Obrázek 5-1 zobrazuje symbolicky architekturu aplikace MISO spolu s průběhem zpracování zpráv. Modré obdélníky představují vlákna (spolu se jmény tříd pomocí kterých je implementována jejich funkcionalita), která odpovídají jednotlivým etapám zpracování zpráv. Předávání zpráv je realizováno pomocí front spravovaných přijímajícím vláknem, znázorněných světle zeleně.

- 14 -

5.3.3 Převzetí dat od SA Program MISO po startu naváže TCP spojení s programem SA. Obrázek 5-1 toto spojení znázorňuje šipkou č. 1. Tímto spojením získává strukturované zprávy, obsahující samotná data zachycená SA včetně doplňujících informací. Zprávy deserializuje opět za pomoci sady funkcí vygenerovaných frameworkem GPB a podle TCP/IP portu a adresy zjistí odpovídající cílovou frontu některého z ISOMill vláken. Je-li zpráva typu „nové spojení“, vytvoří se pro ni nová cílová fronta a její vlákno ISOMill. Do této fronty je pak předána zpráva k dalšímu zpracování, na obrázku znázorněno šipkou č. 2.

5.3.3.1 Zjištění typu zprávy Vlákna ISOMill odebírají zprávy ze svých front, obsahující jen data a události pro jedno sledované TCP spojení. Každá zpráva představuje jeden ze dvou typů – TCP událost či přenášená data. TCP událost může být navázání spojení, nebo jeho ukončení. Tyto události zpracuje vlákno ISOMill samo a předá je rovnou k zápisu do databáze předáním zprávy do fronty vlákna DBWriter. Na obrázku je předání označeno šipkou č. 3. Je-li zpráva typu přenášená data, předá vlákno ISOMill zprávu k dekódování párovému vláknu MsgProcessor (šipka č. 4). Fronta pro předávání zpráv mezi vlákny ISOMill a MsgProcessor je implementována pomocí interního TCP spojení (na obrázku není zakresleno). Tento způsob předávání dat je značně krkolomný, s vysokou režií a navíc neumožňuje zachovat časové razítko příchozí ISO zprávy. Bohužel API knihovny jPOS neumožňuje jiný způsob předávání vstupních dat, jelikož je navržena pro nasazení v roli běžného klienta či serveru a tento mnou požadovaný způsob využití autoři jPOS nepředpokládali.

5.3.3.2 Dekódování ISO zprávy Vlákna třídy MsgProcessor odebírají ze své fronty čistý proud dat, tak jak je odeslaly/přijmuly sledované aplikace a s pomocí knihovny jPOS provedou dekódování samotné ISO zprávy. Můj původní předpoklad, že jPOS bude schopná bez problémů dekódovat libovolnou ISO zprávu, se bohužel nepotvrdil. Při testech jsem narazil na některá pole s proprietární strukturou, pro která jsem musel implementovat vlastní kód pro rozklad na podpole. ISO zprávy, dekódované na jednotlivá pole a podpole, jsou pak předány k zápisu do databáze vláknu DBWriter. Znázorněno šipkou číslo 5.

5.3.3.3 Uložení Vlákno DBWriter odebírá ze své fronty jednotlivé objekty, představující záznamy k uložení do databáze. Samotná komunikace s databázovým serverem je implementována s využitím JDBC rozhraní 9 Pro vyšší efektivitu jsem použil dávkového zpracovaní. Vlákno DBWriter čeká na nahromadění většího množství dat k uložení, a poté všechny požadavky stejného typu odešle databázovému serveru v jedné dávce. Tedy všechny SQL příkazy INSERT nebo UPDATE pro jednu tabulku jsou odeslány najednou, a poté stejným způsobem jsou zpracovány ostatní záznamy k uložení do dalších tabulek.

9

JDBC – Java DataBase Connectivity

- 15 -

Výsledek zpracování dat celé aplikace je uložen do čtyřech tabulek: • • • •

conntab – každý záznam představuje informaci o jednom spojení, zejména časové razítko počátku a konce komunikace a informaci o IP adresách a TCP portech. msgtab – každý záznam představuje jednu zprávu, nejdůležitější informace jsou typ zprávy (MTI), odesílatel a časové razítko příchodu zprávy fldtab - každý záznam představuje jedno pole nebo podpole ISO zprávy hdrtab – zde jsou uložena případná záhlaví, každý záznam představuje jedno záhlaví.

Pro každé spojení je tedy vložen jeden záznam do tabulky conntab, s identifikátorem cid. Zprávy z tohoto spojení jsou ukládány do tabulky msgtab, s odkazem na tabulku conntab (atribut cid) a s vlastním identifikátorem mid. Všechna pole a podpole z těchto zpráv jsou uložena v tabulce fldtab, opět s odkazem na tabulku msgtab (atribut mid). Bylo-li zaznamenáno nějaké záhlaví na začátku komunikace, je uloženo v tabulce hdrtab spolu s odkazem na identifikátor spojení cid v tabulce conntab. Návrh tabulek jsem částečně denormalizoval pro snazší prohledávání dat – v tabulce fldtab jsou uloženy jak pole tak jejich podpole a zároveň je zde uvedeno navíc časové razítko. Příklad uložených dat je znázorněn v příloze C.

5.3.4 Implementace PCI/DSS požadavků pro MISO Požadavky PCI/DSS týkající se programu MISO jsou stejné jako u SA - neukládat zakázaná pole a zajistit kontrolovaný přístup k citlivým datům. Na rozdíl od programu SA umí ale MISO pracovat s jednotlivými poli a podpoli ISO zpráv, proto je možné selektivně některá data nezapisovat do logu či neukládat. Předpokládaný scénář nasazení monitorovací aplikace je jak v testovacím prostředí, kde se nevyskytují žádná citlivá data, tak v produkčním prostředí, kde je nutné zajistit neuložení citlivých polí v datovém úložišti i v log souborech. Z těchto důvodů jsem do programu MISO přidal možnost neukládat hodnoty některých polí vůbec, nebo je uložit až po úpravě. Seznam polí nebo podpolí obsahující citlivé údaje je možné vyjmenovat v konfiguračním souboru, spolu s informací zda se nemají ukládat vůbec či zda je možné uložit jen část hodnoty. Je-li nutné ukládat jen část hodnoty, je v konfiguračním souboru nastaven regulární výraz vzoru a výraz nahrazující danou hodnotu. Konfigurační parametry nutné pro splnění PCI/DSS požadavků mají takové implicitní hodnoty, aby v případě jejich nepřítomnosti (nebo překlepu) v konfiguračním souboru byla aplikace v souladu s touto normou.

5.3.4.1 Příklad skrytí konkrétního pole Například číslo platební karty je dle standardu PCI/DSS považováno za citlivý údaj, nicméně číslo karty je důležitý identifikátor a neuložení tohoto čísla by znemožnilo následnou analýzu zachycených zpráv či ji alespoň výrazně ztížilo.

- 16 -

Avšak pokud bude uloženo jen prvních 6 a posledních 4 číslice, nejedná se o číslo karty u tento údaj již není považován za citlivý. Tabulka 5-1 ukazuje vzorové nastavení právě pro číslo karty na počátku pole 35.

####################################################################### # # PCI/DSS parameters # ####################################################################### pci.mask=true pci.debug=true pci.strictPattern=true pci.field35.pattern=^([0-9]{6})([0-9]*)([0-9]{4})=(.*)$ pci.field35.replace=$1xxxx$3=$4 pci.field55.9f10.pattern=^(.{4})(.*)(.{4})$ pci.field55.9f10.replace=$1xxx..9f10..xx$3

Tabulka 5-1 příklad konfigurace skrytí pole č.35

- 17 -

6 Testy aplikace Provedené testy aplikace lze rozdělit do třech kategorií: • zkušební verze (test konceptu, implementovatelnosti) • vývojové testování • funkční testy • výkonnostní testy

6.1 Zkušební verze Prvním testem bylo vytvoření velmi zjednodušené verze aplikace, které proběhlo v první etapě vývoje. Cílem testu bylo vyzkoušet, zda je záměr na vybudování takovéto aplikace vůbec realizovatelný. Prvotní verze aplikace byla oproti té finální velmi jednoduchá, jak co do velmi omezené funkčnosti tak i neflexibilním designem. Během tohoto testu se mnohé počáteční předpoklady ukázaly jako liché (např. že funkčnost libpcap není dostačující) a svou představu o implementaci jsem musel výrazně změnit. V tomto období jsem testoval funkčnost knihoven třetích stran, které jsem zamýšlel použít. Z tohoto testu také vyplynula nutnost rozdělit aplikaci na dva samostatné programy, což jsem původně nezamýšlel. Výsledkem testu byla částečně fungující proof-of-concept aplikace a finální výběr knihoven, které jsem využil v dalších etapách vývoje.

6.2 Vývojové testování Vývojové testy jsem prováděl průběžně, dle pokračující implementace. Funkčnost jsem implementoval zhruba ve stejném pořadí, jakým prochází zpracovávané zprávy celou aplikací. Základem pro většinu testů byla schopnost knihovny libpcap načíst vstupní data z předem připravených souborů, což mi umožnilo provádět opakované testy se stejnými daty a výrazně mi ulehčilo hledání chyb.

6.3 Funkční testy Funkční testování jsem realizoval vytvořením sady testovacích scénářů, každý z těchto scénářů jsem zkoušel po větších změnách v kódu a po ukončení vývoje aplikace. Jednotlivé testovací scénáře jsou vytvořeny tak, aby představovaly část reálně zachyceného provozu, nebo aby simulovaly některou kombinaci vstupních dat, která prověří i kód jinak zřídka kdy využitý. Příklady použitých testovacích scénářů: • • • •

- 18 -

ověření funkčnosti komponenty SA, čtení dat ze síťového rozhraní ověření funkčnosti komponenty SA, čtení dat ze souboru ověření funkčnosti zpracování proudu dat s chybějícím úvodním sestavením TCP spojení ověření funkčnosti celé aplikace, vstupní soubor obsahuje síťový provoz třech kompletních TCP spojení.

• •

ověření dekódování ISO zpráv se strukturovanými podpoli č.48 a 55 ověření schopnosti modifikace zadaných polí a podpolí dle regulárního výrazu

6.4 Výkonnostní testy Z pohledu výkonu lze u aplikace MISO posuzovat jen rychlost zpracování zpráv. Pro zjištění, zda je rychlost zpracování dostatečná, jsem se pokusil odhadnout jaký je nejvyšší počet zpráv, který by měla aplikace zvládnout při nejnáročnějším scénáři nasazení. Můj odhad, při zátěži cca 50 finančních transakcí za sekundu a při průměrném počtu 5 ISO zpráv na jednu transakci, vychází na nejmenší nutnou rychlost zpracování 250 zpráv za sekundu. Protože 250 zpráv za sekundu je nutno považovat za průměrnou hodnotu, ve špičkách bude počet zpráv výrazně vyšší. Rychlost zpracování jsem měřil za pomoci předpřipraveného souboru, obsahujícího síťový provoz 2466 spojení s 7597 ISO zprávami. Finální verze aplikace je schopná zpracovat tento soubor za cca 16 sekund, což odpovídá 450 zprávám za sekundu. Předchozím verzím trvalo zpracování téhož souboru přes 24s. Pomalejší zpracování bylo způsobeno neoptimálním ukládáním dat do databáze, po úpravě spočívající v zavedení dávkového způsobu ukládání dat do databáze se rychlost zvětšila. Rychlost 450 zpráv za sekundu považuji za dostatečnou.

- 19 -

7 Návod k použití 7.1 Instalace Pro instalaci je nutné mít k dispozici: • počítač s 64bit distribucí linux (testováno na RHEL 5.5), vybavený programem Oracle SQL*Plus a běhovým prostředím Java verze 6. • běží-li sledované aplikace na jiných počítačích, je nutné připojení k SPAN portu. • databázi Oracle včetně „partitioning option“ Postup instalace: • vytvořte adresář, kde bude aplikace umístěna, nakopírujte do něj obsah složky install. Ve skriptu run.sh zkontrolujte, zda nastavení proměnných APPHOME a JAVA odpovídá Vašemu prostředí. • nainstalujte knihovny libpcap a libnet • vytvořte účet v databázi spuštěním skriptu create_schema.sql v SQL*Plus pod uživatelem s DBA privilegii. Skript se dotáže na jméno a heslo uživatele, jméno tablespace pro ukládání dat a kvótu pro tohoto uživatele. • Spusťte skript create_objects.sql pod uživatelem vytvořeným v předchozím kroku. • Je-li vhodné, omezte přístup k programu SA nastavením firewallu.

7.2 Spuštění aplikace SA Nejdříve je třeba spustit první část aplikace, program SA, umístěný v sa/sa. Parametry programu SA jsou:

usage: sa {listenport} {ifname|filename} [pcap filter expression]

Parametr listenport je číslo portu, na kterém bude program SA očekávat spojení z druhé části aplikace – programu MISO. Následuje jméno souboru nebo síťového rozhraní, ze kterého bude SA načítat pakety. Běží-li program SA na stejném počítači jako sledovaná aplikace, zadejte jméno rozhraní které využívá sledovaná aplikace. V ostatních případech zadejte jméno rozhraní, k němuž je připojen SPAN port síťového prvku. Ujistěte se, že má program SA dostatek oprávnění k požadované akci. Posledním parametrem je výraz knihovny pcap pro filtrování paketů, zadejte jen čísla portů kde probíhá komunikace sledovaných aplikací.

- 20 -

7.3

Spuštění aplikace MISO

Po spuštění programu SA, je nutné spustit program MISO. Nejdříve ale zkontrolujte nastavení aplikace v souboru miso.properties: ####################################################################### # # Common parameters # ####################################################################### sa.host=localhost sa.port=4444 db.username=miso db.password=******* #db.url=jdbc:oracle:thin:@//test-tecom.ack-prg.csint.cz:4009/TECOM" db.url=jdbc:oracle:thin:@test-tecom.ack-prg.csint.cz:4009:TECOM #db.trace.level=0

####################################################################### # # Stream identification # ####################################################################### stream0.name=cspos stream0.port=5522 stream0.header.name=posid stream0.header.length=8 stream0.header.charset=US-ASCII stream0.channel=org.jpos.iso.channel.ASCIIChannel stream0.packager=cs_pos.xml stream1.name=csvisa stream1.port=5500 stream1.channel=org.jpos.iso.channel.VAPChannel stream1.packager=base1.xml ####################################################################### # # PCI/DSS parameters # ####################################################################### pci.mask=true pci.debug=false pci.strictPattern=true pci.field35.pattern=^([0-9]{6})([0-9]*)([0-9]{4})=(.*)$ pci.field35.replace=$1xxxx$3=$4 pci.field55.9f10.pattern=^(.{4})(.*)(.{4})$ pci.field55.9f10.replace=$1xxx..9f10..xx$3

Do parametrů sa.host, sa.port doplňte jméno počítače kde běží SA a číslo portu na kterém komunikuje. Parametry db.username, db.password a db.url určují spojení do databáze. Dále je třeba zadat aplikaci parametry sledovaných spojení. V konfiguračním souboru jsou tyto parametry pro konkrétní sledované spojení označeny řetězcem streamN. Povinné parametry pro každý typ spojení jsou: - 21 -

streamN.name – pojmenování typu spojení streamN.port – číslo portu dle kterého bude spojení rozpoznáno streamN.channel – jméno jPOS třídy zajišťující typ rámcování ISO zpráv streamN.packager – jméno xml konfiguračního souboru pro jPOS dekodér. Obsahují-li sledovaná spojení též identifikaci zařízení (nebo jiné záhlaví) odesílaná na začátku, je třeba zadat parametry streamN.header.name – symbolické jméno streamN.header.length – délka záhlaví v bytech streamN.header.charset – označení znakové sady tohoto záhlaví dle standardu Java. V předposlední skupině jsou parametry ovlivňující soulad aplikace s normou PCI/DSS. Nastavením parametrů pci.fieldN.pattern/replace nebo pci.fieldX.YY.pattern/replace na regulární výraz se docílí ukládání hodnot pole N nebo podpole X.YY nikoliv v původní podobě, ale po provedení substituce dle zadaného regulárního výrazu. Syntaxe regulárních výrazů odpovídá standardu Java. Parametry pci.mask, pci.debug a pci.strictPattern lze ovlivnit celkové chování aplikace vhledem ke standardu PCI/DSS, parametrem pci.mask=false lze nahrazování hodnot úplně potlačit, parametrem pci.debug=true lze povolit diagnostický výpis samotného průběhu nahrazování a nastavením parametru pci.strictPattern na true lze vynutit nahrazení hodnoty citlivého pole i v případě selhání regulárního výrazu.

- 22 -

8 Závěr Problematika zachytávání ISO zpráv nezávisle na aplikaci se v průběhu práce ukázala zřetelně složitější než jsem na začátku odhadoval. Požadavek na nezávislost na sledovaných aplikacích mě donutil implementovat metodu pasivního síťového odposlechu, která s sebou přinesla další komplikace. Rovněž problematika samotné dekódování ISO zpráv byla komplikovanější. Mojí původní ideou bylo využití knihovny jPOS k veškeré „práci“ s dekódováním zpráv, ale byl jsem donucen implementovat specifickou funkčnost pro rozpoznání některých polí. Největším neúspěchem zůstává nepřesnost časových razítek u uložených zpráv, které je způsobeno omezeným API knihovny jPOS. Tento nedostatek má za následek nemožnost použít vytvořenou aplikaci pro diagnostiku některých problémů, které jsou způsobeny těsným souběhem několika ISO zpráv. I přes tento dílčí neúspěch považuji práci za úspěšnou, splňující zadání. Aplikace je použitelná k deklarovanému účelu, ISO zprávy bez potíží zachytává a dekódované ukládá do SQL databáze.

8.1 Možnosti dalšího rozvoje Jsem přesvědčen, že architektura aplikace je vhodně navržená a flexibilní, což jsem ověřil i během vývoje při přepracovávání některých částí kódu. Rovněž výkon aplikace je uspokojivý. Proto si myslím, že je aplikace vhodná k dalšímu rozvoji. Prvním cílem dalšího vývoje bude určitě odstranění výše zmíněného nedostatku s časovými razítky. Předpokládám, že těsnější integrací s knihovnou jPOS tohoto cíle půjde dosáhnout. Další možností vylepšení je upravit aplikaci tak, aby bylo možné měnit konfigurační parametry bez restartu aplikace, který s sebou přináší ztrátu zachycených paketů. Z hlediska dlouhodobého rozvoje budu zvažovat, zda do aplikace nedodělat komplexnější logiku zpracování a analýzy ISO zpráv. Samotné ukládání zpráv je sice velkým přínosem pro dohledávání aplikačních chyb, ale další možnosti, jako např. sledování doby odezvy na konkrétní zprávy nebo možnost detekce neobvyklého souběhu/počtu některých zpráv v reálném čase by mohla zvýšit užitečnost aplikace na novou úroveň.

- 23 -

9 Literatura [1]

[2] [3]

[4] [5] [6] [7] [8]

ISO 8583:1987. Financial transaction card originated messages - Interchange message specifications. Genéve, Switzerland : International Organization for Standartization, 1987. 119 s. JPOS [online]. c2010 [cit. 2011-01-04]. JPOS references. Dostupné z WWW: . PCI Security Standards Council Releases [online]. c2011 [cit. 2011-01-04]. Documents Library. Dostupné z WWW: . TCPDUMP/LIBPCAP public repository [online]. 2010 [cit. 2011-01-04]. Pcap. Dostupné z WWW: . WOJTCZUK, Rafal. Http://libnids.sourceforge.net/ [online]. 2010 [cit. 2011-01-04]. Libnids. Dostupné z WWW: . Wireshark - Go Deep [online]. 2010 [cit. 2011-01-04]. Get Wireshark. Dostupné z WWW: . Protocol Buffers [online]. c2011 [cit. 2011-01-04]. Google code. Dostupné z WWW: . WELSH, Matt. SEDA: An Architecture for Highly Concurrent Server Applications [online]. 2006 [cit. 2011-01-04]. Harvard School of Engineering and Applied Sciences. Dostupné z WWW: .

- 24 -

Příloha A - obsah přiloženého CD /install

- adresář se soubory nutnými pro běh aplikace

/install/miso.jar

- spustitelná forma programu MISO

/install/miso.properties

- vzorový konfigurační soubor programu MISO

/install/run.sh

- skript na spuštění programu MISO

/install/sql

- SQL příkazy pro vytvoření uživatelského schéma a objektů

/install/sa/sa

- spustitelná forma programu SA pro platformu Linux/x64.

/install/lib

- knihovny třetích stran nutné pro běh programu MISO.

/src/miso

- zdrojové soubory programu MISO

/src/sa

- zdrojové soubory programu SA

/src/sa/libnids-1.24

- zdrojové soubory knihovny libnids včetně patche.

/text_bp

- vlastní text bakalářské práce

- 25 -

Příloha B – vzorový protokol o běhu 20101229/19:55:46.001 INFO main Server: Config file miso.properties loaded 20101229/19:55:46.482 INFO main DBWriter: Connect ok 20101229/19:55:46.685 INFO main DBWriter: trace level set to 12 for connection 183.15352 20101229/19:55:46.688 INFO main PCIEngine: pci.mask set to true 20101229/19:55:46.688 INFO main PCIEngine: pci.strictPattern set to true 20101229/19:55:46.689 INFO main PCIEngine: pci.debug set to true 20101229/19:55:46.691 INFO SAConnector(localhost:4444) SAConnector: connected to localhost:4444 20101229/19:55:46.823 INFO ISOMill000b ISOMill: stream 10.189.123.181:5522/10.191.24.2:64067 identified as stream0 20101229/19:55:46.823 INFO ISOMill0000 ISOMill: stream 10.189.123.185:5522/10.191.161.97:46698 identified as stream0 20101229/19:55:46.823 INFO ISOMill000a ISOMill: stream 10.189.123.181:5522/10.191.24.2:12812 identified as stream0 20101229/19:55:46.826 INFO ISOMill0009 ISOMill: header [ 823343] captured for cid 9928 20101229/19:55:46.878 INFO ISOMill0012 ISOMill: header [ 832342] captured for cid 9944 20101229/19:55:46.964 INFO DBWriter DBWriter: 36 rows inserted/updated in 72 ms 20101229/19:55:46.965 INFO ISOMill0025 ISOMill: header [ 824348] captured for cid 9958 20101229/19:55:46.965 INFO ISOMill0020 ISOMill: stream 10.189.123.185:5522/10.191.161.97:45120 identified as stream0 20101229/19:55:47.036 INFO ISOMill002c ISOMill: header [ 971358] captured for cid 9970 20101229/19:55:47.120 INFO MsgProc0008 MsgProcessor: new message 0940 cid 9930 20101229/19:55:47.120 INFO MsgProc0014 MsgProcessor: new message 0940 cid 9946 20101229/19:55:47.121 INFO ISOMill0014 ISOMill: stream 10.189.123.181:5522/10.191.24.2:9474 finished 20101229/19:55:47.124 INFO ISOMill002d ISOMill: stream 10.92.60.128:64705/10.189.123.233:5522 identified as stream0 20101229/19:55:47.124 INFO ISOMill002d ISOMill: header [999993^@^@] captured for cid 9971 20101229/19:55:47.141 INFO MsgProc0000 MsgProcessor: new message 0200 cid 9926 20101229/19:55:47.142 INFO MsgProc0000 MsgProcessor: new message 0210 cid 9926 20101229/19:55:47.142 INFO MsgProc0000 MsgProcessor: new message 0940 cid 9926 20101229/19:55:47.142 INFO ISOMill0000 ISOMill: stream 10.189.123.185:5522/10.191.161.97:46698 finished 20101229/19:55:47.149 INFO MsgProc000d MsgProcessor: new message 0210 cid 9932 20101229/19:55:47.149 INFO MsgProc000d MsgProcessor: new message 0940 cid 9932 20101229/19:55:47.149 INFO ISOMill000d ISOMill: stream 10.189.123.185:5522/10.191.161.97:20284 finished 20101229/19:55:47.149 INFO MsgProc0006 MsgProcessor: new message 0210 cid 9933 20101229/19:55:47.150 INFO MsgProc0006 MsgProcessor: new message 0940 cid 9933 20101229/19:......... INFO ... 20101229/19:......... INFO ... 20101229/19:......... INFO ... 20101229/19:......... INFO ... 20101229/19:56:00.561 INFO DBWriter DBWriter: 710 rows inserted/updated in 51 ms 20101229/19:56:00.715 INFO DBWriter DBWriter: 1115 rows inserted/updated in 79 ms 20101229/19:56:00.931 INFO DBWriter DBWriter: 1370 rows inserted/updated in 118 ms 20101229/19:56:00.938 INFO main Server: joined SAConnector thread 20101229/19:56:00.941 INFO ISOMill09a1 ISOMill: stream 10.189.123.181:5522/10.191.24.2:59054 finished 20101229/19:56:00.947 INFO main Server: queues not yet empty, total 0 messages remaining 20101229/19:56:00.947 INFO ISOMill099c ISOMill: stream 10.189.123.185:5522/10.191.161.97:59393 finished 20101229/19:56:01.194 INFO DBWriter DBWriter: 758 rows inserted/updated in 57 ms 20101229/19:56:01.471 INFO main Server: DBWriter thread joined 20101229/19:56:01.471 INFO main Server: finished

- 26 -

Příloha C – vzorový výstup

SQL> -- pocet radek v jednotlivych tabulkach po zachyceni 7500 zprav SQL> @row_count TNAME CNT ------- ---------conntab 2466 msgtab 7597 fldtab 128205 hdrtab 2453 SQL> -- vypis poli a podpoli posledních čtyřech ISO zprav SQL> select m.mti,f.mid,f.f,f.sf,f.val from msgtab m, fldtab f where f.mid = m.mid and f.mid > 45793 order by f.mid,f.f,f.sf;

MTI MID F ------ ---------- ---------0940 45794 0 7 11 37 0200 45795 0 3 4 7 11 12 22 23 24 25 29 35 41 42 48 49 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 64

SF VAL ---------- ------------------------0940 1230344001 042641 000234598296 0200 000000 000000003800 1230134000 022565 103430134956 051 000 200 00 673 440752xxxx2278=1345234241 934228 950828 22 C10104C1104C 203 5f2a 0203 82 5D00 84 A00000000341010 95 0000008000 9a 101230 9c 00 9f02 000000003800 9f03 000000000000 9f09 008C 9f10 0601xxx..9f10..xx0000 9f1a 0203 9f27 80 9f33 E0E1C8 9f34 415602 9f35 22 9f36 01C3 9f37 D2455D34 C8367F78

- 27 -

0210

45796

0940

45797

- 28 -

0 2 3 4 7 11 12 37 38 39 41 49 55 91 64 0 7 11 37

0210 443452222345234234 000000 000000003800 1230673201 022575 10125635433956 0002503543538 06734500 000 999928 203 2EA72345367234FD7B353030 ADFC9679 0940 123034524001 023452375 0002503453428

- 29 -