Intervendor IDS. analyseren 1 van IDMEF karakteristieken. Marju Jalloh en Stéfan Deelen. 3 juni 2007

Transcriptie

1 Intervendor IDS analyseren 1 van IDMEF karakteristieken Marju Jalloh en Stéfan Deelen 3 juni Praktisch IDS onderzoek in opdracht van de Universiteit van Amsterdam

2 Samenvatting In dit rapport staan de resultaten beschreven van het onderzoek naar Intervendor koppelingen tussen IDS systemen. Dit onderzoek is een belangrijk praktijkonderdeel van het vak Intrusion Detection Systems (IDS) waarvan de doelstelling het verkrijgen van inzicht en vaardigheid in een IDS deelonderwerp bedraagt. Het vak IDS is één van de courses van de opleiding System and Network Engineering van de Universiteit van Amsterdam. In de geest van SNE is een Intervendor koppeling gebaseerd op open standaarden en protocollen. Daarom is in dit Intervendor kader op IDMEF gefocussed. IDMEF is net als IDXP een uit een werkgroep voortgekomen open standaard, waarvan de rfc[4]-status door de IETF als experimental is geclassificeerd. IDMEF is een XML format waarmee tussen IDS en uit te wisselen security messages beschreven kunnen worden, een belangrijk onderdeel dus van een Intervendor koppeling. Naast IDMEF wordt in dit document ook een blik geworpen op communicatie-protocollen waaronder IDXP, en op de de facto standaard die tussen commerciële IDS leveranciers wordt gebruikt. Het praktijk-onderdeel van dit onderzoek bestond uit het bouwen van een testbed. Hiermee zijn open source IDS systemen gekoppeld en is de wijze waarop security messages uitgewisseld worden onderzocht. Er is onderzoek gedaan naar de karakteristieken van een IDMEF koppeling gekeken vs. een niet-idmef gebaseerde MySQL koppeling door middel van XML overhead-, en performance metingen. De gebruikte open source software in het testbed is snort en prelude. Snort is hierin geconfigureerd met een IDMEF-plugin, een MySQL-plugin, en met een prelude-idmef plugin. Uit het verrichtte onderzoek concluderen wij dat IDXP nog zelden gebruikt wordt, en dat IDMEF door closed source leveranciers bijna niet ondersteund wordt i.t.t. open source leveranciers. Tijdens IDMEF XML conversie hebben wij een acceptabele overhead factor gemeten van Wel menen wij dat een TLS koppeling in combinatie met IDMEF een redelijke belasting kan vormen op IDS sensoren in extreme omstandigheden. Als future work adviseren wij onderzoek naar IDMEF/IDXP in extreme omstandigheden waarbij het nut van offloading van XML-, en crypto taken op IDS sensoren onderzocht wordt voor high performance omgevingen.

3 INHOUDSOPGAVE INHOUDSOPGAVE Inhoudsopgave 1 Introductie Projectcontext Doelstelling project Onderzoeksaanpak Opbouw document IDMEF Achtergrond IDMEF, IDXP en IDWG IDMEF format IDMEF implementaties? OPSEC ISS Prelude Onderzoeksaanpak Beschrijving testbed Overhead IDMEF XML code IDMEF via Tcp/IP non-idmef via Tcp/IP Performance meting Meetresultaten Voor -, vs. na IDMEF XML - conversie Koppeling Prelude-IDMEF Koppeling MySQL Resultaten performance metingen Conclusies 15 6 Bijlage 1, IDMEF format 16 7 Bijlage 2, Projectvoorstel 19 1

4 1 INTRODUCTIE 1 Introductie 1.1 Projectcontext Organisaties en instellingen zetten vaak gedistribueerde IDS en in die in eerste instantie als geheel van één vendor afkomstig zijn. In beginsel wordt vaak gekozen voor één leverancier om redenen van productsupport. In een later stadium blijkt een uitbreiding met extra IDS sensoren of nieuwe IDS features afhankelijk van de mogelijkheden van dit bestaande systeem, waar vervolgens de benodigde (dure) licenties (bijv. per sensor) extra voor aangeschaft moeten worden. Netwerk IDS en zijn vaak gedistribueerd opgezet, er zijn dan diverse systemen gekoppeld. Het is in deze omstandigheden soms wenselijk om te koppelen met andere systemen van andere leveranciers. Indien dit vanwege proprietary protocollen niet of slecht mogelijk is, lijkt dit op een vorm van vendor lock-in. Onder intervendor koppelingen verstaan wij een functionele koppeling tussen twee systemen van verschillende leveranciers. Deze bestaan er in verschillende (vaak proprietary) uitvoeringen die specifiek voor de betreffende toepassing ontwikkeld zijn. Ook bestaan er door vendors geïnitieerde standaarden, (mede) als gevolg van een destijds afwezige, algemene standaard. 1.2 Doelstelling project Het project Intervendor IDS heeft als doelstelling het verrichten van: 1. onderzoek naar een gewenste intervendor methodiek voor het uitwisselen van security alerts, 2. en het doen van praktisch onderzoek ter beoordeling van deze methodiek. 1.3 Onderzoeksaanpak In eerste instantie is door ons gekeken naar de mogelijkheid tot het ontwerp van een koppeling tussen een specifiek closed source IDS en een open source IDS. Om redenen die in hoofdstuk 2 in dit document staan beschreven is na oriëntatie bewust verder weinig aandacht hieraan besteed en heeft dit onderzoek zich voornamelijk beperkt tot IDMEF 1 wat een door de IETF [7] voorgestelde standaard methodiek is in het kader van intervendor koppelingen. Er is praktijkonderzoek verricht naar toepassingen van IDMEF, met behulp van een testbed waarin IDS systemen zijn gekoppeld. Om een beeld te krijgen van de performance van IDMEF zijn aan deze koppelingen en systemen tijdens verschillende (attack) scenario s metingen verricht. In dit testbed verzorgt het Prelude management systeem [17] de verwerking van de -in IDMEF format 1 Intrusion Detection Message Exchange Format 2

5 1.4 Opbouw document 1 INTRODUCTIE aangeleverde- alerts. Dit heeft ons een beeld opgeleverd van de werking en de performance van IDMEF [8]. 1.4 Opbouw document In hoofdstuk 1 is de projectcontext, doelstelling, onderzoeks-aanpak en de opbouw van dit document beschreven. In hoofdstuk 2 zijn de IDMEF achtergronden, enkele IDS en en de werkwijze van IDS vendors ten aanzien van (IDMEF-)koppelingen beschreven. In hoofdstuk 3 wordt de door ons gekozen onderzoeks-aanpak onderbouwd. In hoofdstuk 4 van dit document worden de resultaten beschreven van de getestte IDMEF koppelingen tussen Prelude (geconfigureerd als management server) en snort 2 (geconfigureerd als sensor). Hoofdstuk 5 bevat de conclusies die volgen uit ons onderzoek. 2 Snort is an open source network intrusion prevention and detection system 3

6 2 IDMEF 2 IDMEF 2.1 Achtergrond IDMEF, IDXP en IDWG Naar aanleiding van onderzoek bij DARPA[2] naar een uniform messaging systeem tussen IDS en, is er onder de IETF vlag de IDWG (Intrusion Detection Working Group) opgericht die het IDXP (Intrusion Detection format exchange Protocol) en het IDMEF (Intrusion Detection Message Exchange Format) ontwikkelden. Tussen 2000 en 2006 heeft de IDWG de drafts van het IDXP en IDMEF gestaag ontwikkeld, maar in maart 2007 zijn er experimental rfc s voor IDXP en ID- MEF gepubliceerd [4], [18], [6]. Deze rfc s vormen (nog) geen door de IETF ondersteunde open standaard, maar hebben wel die intentie bij gebrek aan een beter alternatief. In de genoemde rfc s treffen we het volgende aan over het IDXP en het IDMEF...IDMEF messages should be used for the structured representation of this intrusion detection data, although IDXP may be used to exchange unstructured text and binary data.. IDXP is dus bedoeld als communicatie-protocol voor de overdracht van ID- MEF gestructureerde messages, maar IDMEF is daar niet van afhankelijk. Hoewel er in de open source wereld op IDMEF gebied al redelijk wat effort is verricht, zijn er nog maar weinig IDXP implementaties. Op sourceforge.net zijn er welgeteld twee IDXP gerelateerde projecten. IDXP steunt op het gebruik van een profile binnen BEEP [12] zodat voor de gewenste communicatie eigenschappen (vertrouwelijkheid, authenticiteit, etc.) niet het wiel opnieuw uitgevonden behoefde te worden. Voor IDXP en BEEP wordt vaak een proprietary TLS of SSL gebaseerd alternatief gebruikt. Figuur 1: IDXP concept. 4

7 2.2 IDMEF format 2 IDMEF 2.2 IDMEF format IDMEF is ontworpen als oplossing voor diverse potentiële problemen, waaronder deze: Gegenereerde security messages uit verschillende omgevingen zijn heterogeen: Hoe beschrijf je deze met een eenduidige structuur? Een gelijktijdige detectie van één attack door verschillende sensor systemen of OS en wordt verschillend beschreven, De beschreven messages zijn niet gemakkelijk te verwerken, Commerciële vendors wensen attack info uitbreidbaar te representeren, met hetzelfde message format. Het object georiënteerde data model van IDMEF weet goed met deze problemen om te gaan. De keuze voor het flexibele en niet aan patenten gebonden XML maakt een evt. gewenste verwerking van de beschreven messages op flexibele wijze mogelijk. Een IDMEF message is onafhankelijk van het communicatie protocol (bijv. IDXP) en kent de volgende structuur: De top-level class is IDMEF-Message, daaronder bestaan twee typen nl. Alert -, of Heartbeat messages. Binnen elk type kunnen optionele subclasses gebruikt worden voor het beschrijven van attack kenmerken. Een message van het type heartbeat wordt gebruikt als keepalive vanaf de sensor richting de manager. Voor een schematische weergave van de in de rfc beschreven IDMEF structuur voor security messages, wordt verwezen naar sectie 6, hetgeen bijlage 1 van dit document is. Hier staat ook een voorbeeld van een security message die wordt beschreven met het IDMEF XML format. 2.3 IDMEF implementaties? Het valt op dat vendors van closed source IDS systemen zoals ISS[9], Checkpoint [15], Cisco[14], etc. IDMEF niet of slecht ondersteunen. Checkpoint heeft met zijn OPSEC [13] standaard, een industrie-breed alternatief wat als middel gebruikt wordt om proprietary twee security systemen te koppelen. Checkpoint ondersteunt hierbij geen IDMEF, snort beschikt daarom naast een IDMEF plugin [10], ook over een OPSEC plugin. In de volgende subsecties worden enkele achtergronden beschreven die enigzins de richting voor ons onderzoek hebben bepaald OPSEC De ontwikkeling van de door Checkpoint, een Israëlische leverancier van firewall s, IDS en en verwante technologiën, zelfverklaarde de facto standaard OPSEC -Open Platform for Security- is ongeveer gelijktijdig met IDMEF in 5

8 2.3 IDMEF implementaties? 2 IDMEF 1997 van start gegaan. OPSEC is bedoeld als intervendor interface t.b.v. samenwerking waarin de overdrachtsfunctie van security messages plaats vindt. OPSEC is een framework van API s waarmee vendors koppelingen kunnen maken met de producten uit het portfolio van Checkpoint. Binnen het framework zijn de message veld-beschrijvingen van enkele API s (de Log Export API (LEA) en Event Logging API (ELA)) vergelijkbaar met de functionaliteit van IDMEF. Ook de IDXP functie heeft Checkpoint proprietary ontwikkeld. Het probleem met dit OPSEC-geheel is dat indien in een dergelijke koppeling wordt geïnvesteerd, dit in feite een bedrijfsinvestering is. OPSEC is namelijk geen open standaard die in IETF ondersteunde en uitgevaardigde rfc s beschreven staat ISS Op het moment van het opstellen van de opdrachtdefinitie was ons nog weinig bekend van IDMEF. Het aanvankelijke idee om zelf een koppeling te ontwerpen tussen snort en bijv. ISS is na oriënterend onderzoek (wat onder meer bestond uit de implementatie van een trial-versie ISS IDS management-server) losgelaten. Het productbeleid van een commerciële, closed source IDS vendor maakt het veelal oninteressant om tijd en energie hierin te investeren. Het ISS beleid is wat dit betreft een voorbeeld, waardoor wij zelfs denken dat een evt. ontworpen koppeling tussen ISS en snort al snel ongedaan zou worden gemaakt (via een product update of patch), omdat dit het eigen sensor portfolio (E10K per sensor) ondermijnt. Uit ISS documentatie op de website blijkt dat iedere third party koppeling een aparte licentiemodule op zich kost (alleen de interface). Dan moet uiteraard de third party module zelf ook nog betaald worden, wat alleen een select aantal commerciële IDS producten kunnen zijn: Een heus ontmoedingsbeleid voor het maken van intervendor koppelingen, want als je een component uit het eigen portfolio gebruikt scheelt dat sowieso de koppelingslicentie. Een FAQ aan ISS over IDMEF support wordt als volgt beantwoord: What industry standards are supported - Intrusion Detection Exchange Format working group (IDWG), Intrusion Alert Protocol (IAP), Intrusion Detection Message Exchange Format (IDMEF), IDXP - and in what way? ISS X-Force are founding members of the IDMEF working group. However, this standard has not yet been adopted by the industry. Uit deze redenering blijkt een ontwijking van de vraag, want ISS is deel van die industrie Prelude Open source IDS en blijken wel een redelijke ondersteuning te bieden, Prelude- IDS is daar een voorbeeld van. Alle externe IDS communicatie tussen sensoren, manager(s) en third party systemen is in de Prelude architectuur gebaseerd op IDMEF. Voor third party systemen zijn prelude-idmef plugins ontwikkeld, of er is code beschikbaar die voor de ontwikkeling hiervoor gebruikt kan worden. Honeyd kan bijvoorbeeld uitgerust worden met de prelude-lml software, 6

9 2.3 IDMEF implementaties? 2 IDMEF een log analyser van bijv. de honeyd alerts. Deze prelude-lml cliënt converteert een relevante honeypot alert naar IDMEF gebaseerde XML structuur, en forward deze message via een beveiligde koppeling naar de centrale preludemanager. Ook heeft prelude aan potentiële performance problemen gedacht bij de transport en verwerking van XML data door deze data eerst naar binair te converteren alvorens deze te transporteren en te verwerken. Wat wel gezegd moet worden is dat in de prelude interface (nog) geen IDXP wordt toegepast, maar een proprietary exchange protocol voor de XML uitwisseling waarbij de transport security met GnuTLS[11] verzorgt wordt. Na deze oriëntatie hebben wij besloten ons praktische onderzoek verder te richten op IDMEF in open source omgevingen. Voor een totaalbeeld is er naar een implementatie van een niet-idmef gebaseerde gelijkwaardige open source intervendor koppeling gekeken. 7

10 3 ONDERZOEKSAANPAK 3 Onderzoeksaanpak In dit hoofdstuk wordt onderbouwd wat we onderzocht hebben, en hoe we dit hebben aangepakt. Na de beschrijving van het gebruikte testbed volgt een uitleg over testen voor het meten van XML overhead en uitleg over testen in het kader van koppelingen en performance. 3.1 Beschrijving testbed Voor de analyse van IDMEF is een op prelude-, en snort software gebaseerde testomgeving gebruikt. In de opstellingen is de prelude-manager, en MySQL server software ingezet als server waar security messages (al dan niet beschreven in XML) werden afgeleverd. Prelude heeft een client interface en IDMEF API s beschikbaar gesteld waarmee developers hun IDS software kunnen koppelen met de prelude-manager. Voor snort en diverse andere IDS systemen zijn hiermee prelude-idmef plugins [16] ontwikkeld. Door een snort-sensor met verschillende output-plugins uit te rusten is het voor ons mogelijk de gegenereerde (XML of niet-xml) alerts vergelijkend te onderzoeken. In de praktijk blijkt dat een plugin voor een bepaalde snort versie is ontwikkeld, dus installeren wij meerdere versies. De prelude-manager software is mede interessant om als koppeling te onderzoeken, omdat er voorafgaand aan het datatransport een extra vertaalslag van XML naar binairy gemaakt wordt. Dit is een proprietary mechanisme op de plaats waar IDXP geimplementeerd had kunnen zijn. De log van de installatie van de prelude-manager is te vinden via ref [5]. Figuur 2: Eenvoudige weergave IDMEF testbed. De door ons gebruikte software versies voor het genereren van de gewenste output of het maken van de koppelingen zijn: 8

11 3.2 Overhead IDMEF XML code 3 ONDERZOEKSAANPAK Snort versie voor een snort-prelude koppeling: Version (Build 54), Snort versie voor een MySQL koppeling: Version (Build 14), Snort versie met IDMEF XML conversie: Version (Build 28), Benodigde IDMEF packages: libidmef beta1 en libxml++2.6-dev, Libpreludedb-config version: , Libprelude-config version: Overhead IDMEF XML code Door vergelijkend te meten willen we de verhouding bekijken tussen de oorspronkelijke alert output en het resultaat na XML conversie dankzij de IDMEF plugin van snort. Hiermee brengen wij de XML overhead in beeld voor wat betreft data-opslag en datatransport. Figuur 3: Test file vs. IDMEF output. Onze aanname bij metingen in het kader van het onderzoeken van de alert vs. de IDMEF XML code is: Als een attack identiek herhaald wordt, zal dit altijd resulteren in het zelfde aantal alerts als de vorige. Mocht dit anders blijken, dan is dit het gevolg van performance issues op de snort sensor. Het uitgangspunt hierbij is dat alle componenten constant blijven (version, ruleset, etc). 3.3 IDMEF via Tcp/IP Deze testen zijn bedoeld om een totaalbeeld te krijgen van de karakteristieken van twee verschillende koppelingen met dezelfde functionaliteit. Om de alerts vanuit snort naar een prelude-manager te versturen, moeten we snort opnieuw compileren met de prelude-idmef plugin. Deze plugin bevat naast de XML conversie-functie tevens een TLS koppelfunctie zodat de prelude koppeling secure gemaakt kan worden. Na compilatie en installatie van 9

12 3.4 non-idmef via Tcp/IP 3 ONDERZOEKSAANPAK Figuur 4: Test IDMEF koppeling. snort met deze plugin meten we de ratio tussen de grootte van de originele alert file in verhouding tot de verstuurde hoeveelheid bytes met een tcpdump. (Deze meting is beeldvormend en is niet gerelateerd aan de voorgestelde meting in de vorige sectie Overhead IDMEF XML code ). 3.4 non-idmef via Tcp/IP Figuur 5: Test Mysql koppeling. Ter vergelijking met een niet-idmef koppeling compileren we een snort versie met een MySQL-plugin en meten karakteristieken op het moment van de overdracht van alerts. In deze situatie transporteert de snort sensor via een MySQL-client de alerts naar een remote MySQL database. 10

13 3.5 Performance meting 3 ONDERZOEKSAANPAK 3.5 Performance meting Met deze metingen wordt getracht te inventariseren wat de cpu-impact is als gevolg van de te genereren, converteren en te transporteren alerts naar aanleiding van een nmap attack bij verschillende configuraties. Wij zijn ook geïnteresseerd in de impact van XML processing en van de secure koppeling op de performance van de sensor. In dit [3] artikel over XML accelerators wordt offloading van XML processing als oplossing voor performance problemen aangeboden. Bij de uitvoering van de performance testen houden we dit in gedachten. We voeren via een script een nmap attack uit, en op dat moment monitoren we de max. cpu-impact en vergelijken de resultaten tussen de testopstellingen wanneer dit mogelijk en correct is. Om een redelijke vergelijking te kunnen maken moeten we proberen bij iedere opstelling een zelfde hoeveelheid gelijke alerts te genereren. 11

14 4 MEETRESULTATEN 4 Meetresultaten In dit hoofdstuk worden de resultaten van de in het vorige hoofdstuk beschreven metingen en de interpretatie van de resultaten beschreven. 4.1 Voor -, vs. na IDMEF XML - conversie De output van snort alerts wordt in deze test ook in een IDMEF-gebaseerde XML file weggeschreven. De output files /var/log/snort/alert en /var/log/snort/idmef-message.log bevatten onze meetresultaten die in onderstaande tabel zijn verwerkt. Er zijn een aantal oriënterende testen gedaan met verschillende nmap flags; met een script zijn de in de tabel vermeldde nmap herhalingen uitgevoerd. Onder de overhead factor verstaan wij in dit geval de grootte (aantal bytes) van de IDMEF file vs. de grootte van de alert file, dus bijv: (1775/285) = 6,22. snort nmap aantal alert file IDMEF file overhead versie flag nmap (bytes) (bytes) factor v ss v O v ss v st v st v ss De alerts zijn gegenereerd met de nmap flags - ss, - O, of - st, de content van de verschillende alerts zijn dus verschillend, maar de grootte blijkt als gevolg van de eenvoudige ruleset van deze snort versie hetzelfde. Uit deze resultaten is af te lezen dat de grootte van de originele file na de XML conversie een factor 6,22 toeneemt. Deze factor blijkt een constante, waarmee onze in paragraaf 3.2 beschreven aanname wordt bevestigd. De XML file is dan nog slechts lokaal opgeslagen. 4.2 Koppeling Prelude-IDMEF We verwachten dat door de TLS-, en tcp/ip protocol overhead de factor zal toenemen. Maar omdat de prelude implementatie van IDMEF een vertaalslag naar binairy heeft, vermoeden we een optimalisatie. Uit deze meetresultaten blijkt dat de overhead factor niet groter, maar juist kleiner is geworden. Ook blijkt het constante karakter van de overhead factor verdwenen: Naarmate de hoeveelheid te versturen IDMEF data toeneemt, wordt de overhead factor kleiner. 12

15 4.3 Koppeling MySQL 4 MEETRESULTATEN snort alert file tcpdump overhead versie (bytes) (bytes) factor v ,98 v ,04 v ,93 v ,88 v , Koppeling MySQL Deze meting is met verschillende alerts uitgevoerd, met een andere inhoud en grootte dan de alerts uit eerdere rulesets. Op zich is dit geen probleem, mits we hier bij het trekken van vergelijkingen rekening mee houden. Er worden in gemeten met 3 nmap attacks die eenmalig worden uitgevoerd met de flags - ss, - st en - O. We weten dat de rules van deze snort versie voor iedere nmap flag een andere alert zal genereren. snort nmap aantal alert file tcpdump overhead versie flag alerts (bytes) (bytes) factor v ss v st v O Onder de overhead factor verstaan wij in dit geval de grootte (aantal bytes) van de tcpdump vs. de grootte van de alert file, dus bijv: (6303/1003)=6,28. Uit de resultaten blijkt dat de overhead factor variëert. Een reden hiervoor kan de MySQL structuur zijn waarin de alert wordt weergegeven. Voor een beschrijving van een alert als gevolg van een - st attack is de weergave in MySQL blijkbaar minder efficiënt dan de - O alert. 4.4 Resultaten performance metingen Test nr. 1 creëert en schrijft alerts alleen weg in een lokale output file; test nr. 2 creëert en converteert alerts in XML IDMEF. In test nr. 3 wordt nog eens een extra optimalisatie toegepast door het XML resultaat in een binairy te converteren, met TLS te encrypten en te versturen via tcp/ip. De situatie in opstelling 4 creëert een gewone alert die via een MySQL client en tcp/ip wordt verzonden naar een MySQL-database. Test snort aantal alert file max. CPU(%) Situatie versie alerts size (bytes) (snort pid) nr. 1, file v nr. 2, XML v nr. 3, Prelude v nr. 4, MySQL v

16 4.4 Resultaten performance metingen 4 MEETRESULTATEN Bij de uitvoering van deze stress-test is het niet gelukt om de opstellingen te overloaden. Hier is een zwaardere aanpak voor nodig waarbij meer energie in scripting dient te worden gestoken, eventueel met een gedistribueerde aanpak met stress-tools als httperf, autobench en/of handmatige gemaakte rules die na triggering meer cpu-belastende alerts genereren. Het cpu-impact resultaat van 53.6% vinden wij reeds aanleiding om vervolg-onderzoek aan te bevelen naar het nut van een TLS/XML offloader. Uit de resultaten van test nr. 1 waar snort zonder MySQL of IDMEF output plugins is uitgerust blijkt na vergelijking met test nr 4. de cpu-impact van de MySQL koppeling. Uit de resultaten blijkt verder dat testopstelling no. 3 met de extra TLS en tcp/ip taken logischerwijs het zwaarst belast wordt. Verder willen we geen vergelijkend performance waardeoordeel met deze testen vellen. Opstelling nr. 4 verricht namelijk geen encryptie en draait met een andere snort versie. De prelude configuratie in test nr. 3 uitrusten zonder TLS encryptie zou wenselijk zijn, maar dit blijkt via tcp/ip niet mogelijk aldus prelude. Daarom is het interessant om nr. 4 met SSL of TLS uit te rusten, zodat deze koppeling de eigenschappen van de prelude-idmef koppeling nog meer benaderd. De vorige performance metingen zijn verricht met verschillende rules voor iedere snort versie. De gegenereerde alerts belasten de snort systemen op een niet vergelijkbare wijze. We doen de voorgaande testen opnieuw en zorgen er nu voor door aanpassing van de snort rules, dat bij iedere test exact dezelfde alerts qua hoeveelheid en vorm worden gegenereerd. Wederom noteren wij de cpu-impact. Test snort aantal alert file max. CPU(%) Situatie versie alerts size (bytes) (snort pid) nr. 1, file v nr. 2, XML v nr. 3, Prelude v nr. 4, MySQL v nr. 5, MySQL-SSL v De resultaten komen qua onderlinge verhoudingen overeen met de vorige performance metingen. De bedoeling van test nr. 5 is dus om met het resultaat een performance vergelijking te kunnen trekken tussen twee qua functionaliteit gelijkwaardige intervendor koppelingen. We hebben deze opstelling getracht te implementeren, maar in het ons gegeven tijdsbestek bleek dit niet haalbaar. Nr. 5 blijven wij qua meting relevant vinden, omdat er dan een correctere vergelijking met de Prelude test, nr. 3 verricht kan worden. Nr. 5 bevelen wij aan als future work [1]. 14

17 5 CONCLUSIES 5 Conclusies We hebben met dit onderzoek eigenschappen van IDMEF en intervendor koppelingen bloot gelegd. De conversie van onze snort security messages naar de voorgeschreven IDMEF XML beschrijving leverde een acceptabele overhead factor van Er is met metingen aangetoond dat deze XML overhead factor niet snel de veroorzaker zijn zal van een problematische cpu-impact. Er is aangetoond dat het TLS gebaseerde communicatie-protocol van prelude waarschijnlijk meer potentiëel in zich heeft als veroorzaker van een problematische cpu-impact in extreme omstandigheden, dan de XML bewerkingen. Verder concluderen wij dat: IDMEF in combinatie met IDXP beschouwd mag worden als de meest wenselijke toekomstige intervendor koppelmethodiek, omdat het een experimental IETF standaard is (er is nog geen harde standaard voor deze protocollen). Maar ook de meest wenselijke methodiek omdat daarmee de in paragraaf 2.2 geschetste potentiële problemen worden opgelost, Prelude een schappelijk alternatief voor IDXP heeft toegepast, vanwege het ontbreken van de toen nog niet experimental zijnde IDXP standaard, OPSEC geen interessante intervendor methodiek is, omdat er geen pogingen gedaan zijn om van OPSEC een open standaard te maken, De verrichtte metingen in het kader van performance van intervendor koppelingen, lieten blijken dat de cpu-impact van 53,6% als gevolg van de XML en TLS bewerkingen behoorlijk is: Een onderzoek naar het nut van de inzet van een offloader of accelerator verdient aanbeveling, (Wij hebben niet onderzocht of dit reeds wordt toegepast met snort configuraties). Om de door ons geïmplementeerde intervendor koppelingen correcter te kunnen vergelijken dient de MySQL koppeling met TLS of SSL te worden uitgerust. Ook dit beschouwen wij als future work. 15

18 6 BIJLAGE 1, IDMEF FORMAT 6 Bijlage 1, IDMEF format IDMEF-Message Alert <>- Analyzer Heartbeat <>- Analyzer <>- CreateTime <>- CreateTime <>- DetectTime <>- AdditionData <>- AnalyzerTime <>- Source <>- Node <>- User <>- Process <>- Service <>- Target <>- Node <>- User <>- Process <>- Service Classification <>- File Assessment <> <> <> AdditionalData

19 6 BIJLAGE 1, IDMEF FORMAT Deze voorgeschreven structuur wordt toegepast op het volgende security message: # cat /var/log/snort/kalevsverpakt/xmas-alert [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] 05/24-00:02: : > :22 TCP TTL:46 TOS:0x0 ID:50873 IpLen:20 DgmLen:40 **U*P**F Seq: 0xFB323FA7 Ack: 0x0 Win: 0x400 TcpLen: 20 UrgPtr: 0x0 [Xref => Hetgeen als resultaat de volgende XML output geeft: <?xml version="1.0"?> <!DOCTYPE IDMEF-Message PUBLIC "-//IETF//DTD RFC XXXX IDMEF v1.0//en" "/usr/local/share/idmef-message.dtd"> <IDMEF-Message version="1.0"> <Alert messageid="95"> <Analyzer analyzerid="ids1" manufacturer="snort IDMEF Plugin, (c) Joe McAlerney, Sandro Poppi" class="ids/ips" model="snort" version="2.4.4" ostype="linux" osversion= " generic"> <Node category="unknown"> <name/> </Node> </Analyzer> <CreateTime ntpstamp="0xc9ff388f.0xed14f483"> T22:02:55Z</CreateTime> <AnalyzerTime ntpstamp="0xc9ff388f.0xf "> T22:02:55Z</AnalyzerTime> <Source> <Node category="unknown"> <Address category="ipv4-addr"> <address> </address> </Address> </Node> <Service ip_version="4" iana_protocol_number="6" iana_ protocol_name="tcp"> <name>tcp</name> <port>42616</port> </Service> </Source> <Target> <Node category="unknown"> <Address category="ipv4-addr"> <address> </address> </Address> </Node> <Service ip_version="4" iana_protocol_number="6" iana_ 17

20 6 BIJLAGE 1, IDMEF FORMAT protocol_name="tcp"> <name>tcp</name> <port>22</port> </Service> </Target> <Classification text="scan nmap XMAS"> <Reference origin="vendor-specific" meaning="sid"> <name>1228</name> <url> </Reference> <Reference origin="vendor-specific" meaning="arachnids"> <name>30</name> <url> </Reference> </Classification> <Assessment> <Impact severity="medium" type="recon" completion= "failed">attempted Information Leak</Impact> </Assessment> <AdditionalData type="integer" meaning="sig_rev" >7</AdditionalData> </Alert> </IDMEF-Message> 18