INTRUSION DETECTION SYSTEMS

INTRUSION DETECTION SYSTEMS

WWW.GOVCERT.NL POSTADRES

Postbus 84011 2508 AA Den Haag BEZOEKADRES

Wilhelmina van Pruisenweg 104 2595 AN Den Haag TELEFOON

070 888 75 55 FAX

070 888 75 50 E-MAIL

[email protected]

Auteur Versie Den Haag

: GOVCERT.NL : 1.2 : 21 maart 2008

0

SAMENVATTING Sinds begin jaren 2000 was er sprake van een sterke toename van de toepassing van Intrusion Detection Systems (IDS) als belangrijke schakel van netwerkbeveiliging. Ondertussen is veel geleerd over de IDS-sen en kan meer genuanceerd gesproken worden over de manier waarop ze effectief ingezet kunnen worden. Een IDS is een systeem dat ongeautoriseerde toegangen tot een informatiesysteem of netwerk herkent en signaleert. Het is dus een middel dat als detectiemaatregel ingezet kan worden. Deze white paper geeft een overzicht van de technologie en de factoren die van invloed zijn op het succes van de toepassing van IDS. IDS is geen Haarlemmer olie voor security problemen, maar vormt een onderdeel in de beveiligingsketen. Er moeten aan een aantal randvoorwaarden worden voldaan, om gebruik te kunnen maken van de toegevoegde waarde die een IDS kan bieden. Een goede organisatorische inbedding is één van de vereisten om optimaal gebruik te kunnen maken van een IDS. Een IDS kan effectief ingezet worden voor het verkorten van de responstijd bij aanvallen en het analyseren van de toedracht van een incident. Snel kunnen correleren van meldingen helpt hierbij. Daarnaast is het een bron van statistische informatie over onregelmatigheden op netwerken en systemen. Belangrijk is vooraf helder te maken voor welk doel IDS wordt toegepast en hoe dit in de aanpak voor security management past. Daarnaast moet rekening gehouden worden met additionele kosten in beheer en onderhoud en respons op meldingen, die hoger kunnen uitvallen dan vooraf voorzien. Een derde punt is dat een IDS niet kennis en ervaring kan vervangen bij het inschatten van de ernst van een melding en de prioriteitstelling bij vervolgstappen. Dit wordt versterkt omdat de betrouwbaarheid van de output van een IDS door loze alarmen en ongedecteerde aanvallen kan verminderen. Het monitoringsysteem dat GOVCERT.NL samen met SURFNet heeft ontwikkeld is een vorm van een gedistribueerde hybride IDS. Dit systeem maakt gebruik van enkele in deze white paper beschreven technieken.

INHOUD 0

Samenvatting ..................................................................................................2

1 1.1 1.2 1.3

Inleiding..........................................................................................................1 Positionering IDS.............................................................................................. 1 Opbouw IDS .................................................................................................... 2 Leeswijzer ....................................................................................................... 3

2 2.1 2.2

Waarom een IDS?............................................................................................4 Doelbepaling.................................................................................................... 4 Scope bepaling................................................................................................. 5

3 3.1 3.2 3.3 3.4 3.5 3.6

Concepten .......................................................................................................7 Detectie van patronen of afwijkingen................................................................... 7 Network IDS of Host IDS ................................................................................... 7 Honeypots ....................................................................................................... 9 Passieve en reactieve Intrusion Detection systemen .............................................. 9 Intrusion prevention systems ........................................................................... 10 Generiek of specifieke IDS ............................................................................... 10

4 4.1 4.2 4.3 4.4 4.5 4.6 4.7

Aandachtspunten bij toepassing van IDS ......................................................12 Kosten .......................................................................................................... 12 Tuning en updates .......................................................................................... 13 Betrouwbaarheid output .................................................................................. 13 Uitvoeren van monitoring taken ........................................................................ 14 Interpretatie van IDS output ............................................................................ 15 Correlatie ...................................................................................................... 16 Versleuteling van dataverkeer .......................................................................... 17

5 5.1 5.2 5.3

Organisatorische Inbedding van een IDS ......................................................18 Relatie met andere processen........................................................................... 18 Beleid rondom een IDS.................................................................................... 19 Opzet IDS ..................................................................................................... 10

6 6.1 6.2 6.3 6.4

Kwetsbaarheden van IDS ..............................................................................20 Omzeilen van IDS functionaliteit ....................................................................... 20 Toegang tot de IDS......................................................................................... 21 Locatie van het IDS ........................................................................................ 21 Onbetrouwbare IDS output .............................................................................. 22

7

Ervaringen met een IDS ................................................................................23

8

Conclusies .....................................................................................................25

1

INLEIDING Begin jaren 2000 was er sprake van een hype rondom de term Intrusion Detection Systems (IDS) waarbij deze werden gezien als een kernpunt van de netwerkbeveiliging. Inmiddels is duidelijk geworden dat het niet zo eenvoudig ligt. De betrouwbaarheid en het feit dat IDS-en per definitie achter de feiten aanhollen – het kwaad is vaak al geschied op het moment dat een IDS het detecteert speelt hierbij een grote rol. Toch kan een goed toegepaste IDS belangrijke informatie geven voor de response en afwikkeling van een beveiligingsincident. Deze white paper geeft een overzicht van de technologie en de factoren die van invloed zijn op het succes van de toepassing van IDS.

NOOT 1 Detectiesystemen tegen fysieke inbraak in gebouwen worden ook vaak Intrusion Detection Systems genoemd. In deze white paper wordt met een IDS een component in een informatiesysteem of netwerk bedoeld.

1.1

Positionering IDS

Een IDS is een systeem dat afwijkende patronen in toegang tot een informatiesysteem of netwerk signaleert en is dus duidelijk gepositioneerd als detectieve maatregel.

Dreigingen

Preventie Incident Detectie Repressie Herstel Evaluatie Figuur 1-1 De keten van beveiligingsmaatregelen

In Figuur 1-1 is de samenhang tussen verschillende type maatregelen te zien.

Intrusion Detection Systems versie 1.2 21 maart 2008

1/26

Preventieve maatregelen worden getroffen om relevante dreigingen het hoofd te bieden. Een firewall voorkomt ongeautoriseerde toegang tot een netwerk en is een preventieve maatregel. Dreigingen kunnen manifest worden als de preventieve maatregel faalt of als een geaccepteerd risico toch een incident tot gevolg heeft. Detectieve maatregelen zorgen voor herkenning van een incident. Een audit is een detectieve maatregel, net als een rookalarm. Ook een IDS is een detectieve maatregel. Vervolgens moeten er nog maatregelen aanwezig zijn die erop gericht zijn om de vervolgschade te kunnen beperken en de normale situatie te herstellen. Deze repressie- en herstelmaatregelen worden in gang gezet door detectie van een incident. Een vroege detectie, gevolgd door een doeltreffende reactie kan veel schade voorkomen. Het doel is de tijd tussen het begin van een incident en het moment van ingrijpen zodanig te verkorten dat schade kan worden voorkomen. Ten slotte zal op basis van een evaluatie bepaald moeten worden hoe het incident heeft kunnen plaatsvinden en welke maatregelen eventueel aangepast moeten worden. Een IDS op zichzelf speelt hiermee een beperkte rol in de gehele keten van beveiliging. Deze rol wordt sterker als het is gekoppeld aan effectieve respons. De maatregelen liggen niet alleen op technisch vlak en daarom is het noodzakelijk om ook de organisatorische inbedding van een IDS te realiseren. 1.2

Opbouw van een IDS

Monitor (presentatie)

Output

Log

Engine

Data

Processing

Sensor

Sensor

Sensor

Sensor

Figuur 1-2 Generieke opbouw van een IDS

Figuur 1-2 geeft schematisch weer uit welke generieke componenten een IDS in het algemeen is opgebouwd: •

Eén of meerdere sensoren die in de datastroom speuren naar elementen die een incident kunnen vormen en de waarnemingen daarvan doorgeven.


2/26

•

Een centrale verwerkingseenheid die de waarnemingen van de sensoren verwerkt, correleert en dit vertaalt naar waarschuwingen. Daarbij kunnen de resultaten van de sensoren door de engine opgeslagen worden in een database.

•

De monitor (ook wel console genoemd) wordt vervolgens gebruikt om de waarschuwingen op een voor mensen begrijpelijke vorm te presenteren.

Afhankelijk van de fabrikant en omvang van een IDS kunnen deze componenten verdeeld zijn over verschillende systemen of geïntegreerd zijn in één systeem. 1.3

Leeswijzer

Dit rapport biedt handvatten voor het opzetten van een Intrusion Detection System. Hoofdstuk 2 gaat in op het bepalen van het doel en scope van een IDS. Daarna wordt in Hoofdstuk 3 ingegaan op de verschillende IDS concepten. De met een IDS samenhangende probleemgebieden en valkuilen worden in Hoofdstuk 4 beschreven. De organisatorische en beleidsmatige aspecten komen in Hoofdstuk 5 aan bod. Een IDS kent ook kwetsbaarheden, welke in Hoofdstuk 6 worden beschreven. Om te leren van de praktijk wordt in Hoofdstuk 7 de ervaringen uit het monitoringproject van GOVCERT.NL gegeven. In dit document wordt veelvuldig gebruik gemaakt van afkortingen en specifieke termen. Een overzicht van alle gebruikte afkortingen en termen kunt u terugvinden in Bijlage A.

NOOT 2 Indien in dit document de naam van een product, dienst, fabrikant of leverancier wordt genoemd betekent dit niet dat GOVCERT.NL deze op enige wijze goedkeurt, afkeurt, aanraadt, afraadt of anderszins hiermee verbonden is.


3/26

2

WAAROM EEN IDS? Het in stand houden van een IDS, inclusief de organisatie eromheen is niet triviaal. Het advies is dan ook eerst goed na te denken over het doel van een IDS voordat besloten wordt om deze daadwerkelijk in te zetten. Want mits goed toegepast kan een IDS een waardevolle bron van informatie zijn, maar de hoeveelheid informatie kan evengoed een valkuil worden. De twee kernvragen om te stellen zijn: 1. “Over welke incidenten wil ik informatie verzamelen?” En 2. “Wat wil ik vervolgens met deze informatie doen?” De vraag die daaruit logisch volgt is uiteindelijk: 3. “Kan een IDS daadwerkelijk bijdragen aan een antwoord op de voorgaande vragen?” Om optimaal gebruik te kunnen maken van een IDS is een duidelijk beeld noodzakelijk over het doel waarmee het wordt ingezet. Dit heeft namelijk sterke invloed op de wijze waarop een IDS moet worden geïmplementeerd in een organisatie. Soms is het doel vooraf duidelijk, m.n. als het gaat over het beschermen van een specifiek systeem of bepaalde informatie. De vraag is dan vooral hoe een IDS het beste toegepast kan worden. 2.1

Doel van het IDS

Het doel waarmee een IDS wordt ingezet bepaalt onder andere de complexiteit van een IDS, waar een IDS wordt geïmplementeerd en hoe de (beheer)organisatie rondom een IDS er uit ziet. Doel: statistische informatie Vaak wordt een IDS ingezet voor het verkrijgen van statistische informatie. Denk hierbij bijvoorbeeld aan rapportages over het aantal gedetecteerde inbraakpogingen Hierbij kan de vraag gesteld worden of deze informatie echt relevant is voor de organisatie of dat het bedoeld is als scare tactic richting het management. Een andere meer positieve benadering is gebruiken van deze rapportages om de effectiviteit van beveiligingsmaatregelen te bepalen. Als dit het doel is van een IDS is het goed om te weten dat de informatie voor dit soort rapportages in de vorm van logginginformatie vaak al elders in de organisatie beschikbaar is.


4/26

Figuur 2-1 Voorbeeld van statistische informatie uit het monitoringsysteem. Uit deze grafiek blijkt dat 62% van de aangeboden malware niet herkend wordt door de virusscanners op het analysesysteem.

Doel: detectie Behalve het verzamelen van informatie over wat er speelt op de IT-infrastructuur is een ander doel van IDS de reactietijd bij een incident te versnellen. Als een inbraak pas bij de wekelijkse controle van de logfiles wordt gesignaleerd kan al veel schade berokkend zijn. Ook kunnen wormbesmettingen soms vroegtijdig ontdekt worden door een toename van poortscans op het netwerk. Door een snelle analyse en reactie kan een grootschalige uitbraak en hiermee afname van beschikbaarheid van systemen worden voorkomen. Doel: analyse Informatie uit een IDS kan worden toegepast om de toedracht van een incident achteraf te reconstrueren. Deze informatie is vaak gedetailleerd en relevant, mits de IDS-sen goed geplaatst en geconfigureerd zijn. Als dit het enige doel van de IDS is, is het goed na te gaan of dezelfde informatie niet al gelogd wordt op andere plaatsen in het systeem, bijvoorbeeld een firewall log. 2.2

Scope van het IDS

Na de keuze van het doel moet het toepassingsgebeid bepaald worden. In het kader van IDS wordt onderscheid gemaakt tussen de beveiliging van de infrastructuur en de beveiliging van informatie. Scope: beveiliging van infrastructuur De beveiliging van de infrastructuur richt zich vooral op het verkrijgen van inzicht of er ongeautoriseerde toegang tot of wijzigingen aan componenten in de infrastructuur plaatsvinden (proactief) of hebben plaatsgevonden (reactief). De Intrusion Detection Systems versie 1.2 21 maart 2008

5/26

benodigde informatie over de infrastructuur is vaak in handen van één organisatieonderdeel, de ICT organisatie. Het verkrijgen van inzicht in de beveiliging van de infrastructuur is vaak eenvoudiger te realiseren dan inzicht in de beveiliging van informatie. Dit wil overigens niet zeggen dat het simpel is. Hoe complexer de infrastructuur hoe complexer een IDS voor de beveiliging hiervan zal zijn. Scope: informatiebeveiliging Om inzicht te krijgen in ongeautoriseerde toegang tot informatie moet bekend zijn wie bij welke informatie mag en waar ongeautoriseerde toegang uit bestaat. Hiervoor is een vergaand inzicht in de samenhang informatiestromen en de infrastructuur noodzakelijk. De inrichting van een IDS zal in dit geval een stuk complexer worden omdat meerdere organisatieonderdelen hier een rol in zullen spelen. Scope: Incidenten Het kan zijn dat specifieke incidenten door het IDS gedetecteerd moeten worden, bijvoorbeeld bepaalde typen malware of netwerkscans. Dit heeft direct invloed op het type en de plaatsing van de IDS. 2.3

Voorbeelden

Hieronder volgen een aantal voorbeelden waarvoor een IDS ingezet kan worden. •

Inzet van een IDS voor het vaststellen van ongeautoriseerde wijzigingen op de infrastructuur. Als alternatief hiervoor kan gekeken worden naar het aanscherpen van wijzigingsprocedures voor de infrastructuur. Van belang is om vast te stellen wat het gewenste effect is en welk geheel van maatregelen hier het beste bij past binnen een organisatie.

•

Inzet van een IDS bij het ondersteunen van forensisch onderzoek. Hierbij wordt een IDS gebruikt om na een incident na te kunnen gaan wat er gebeurd is en speelt dus een belangrijke rol in de evaluatie van een incident. Indien het ook de bedoeling is om dit te gebruiken in een juridisch proces is het noodzakelijk om de gegevens uit een IDS te verzamelen en op te slaan conform de juridische eisen.

•

Inzet van een IDS als “audit/evaluatie” middel waarbij een IDS helpt om ongeautoriseerde systemen en applicaties op te sporen. Ook hierbij kunnen juridische aspecten een rol spelen bijvoorbeeld wanneer een IDS een van de maatregelen is om aan te kunnen tonen dat aan voorgeschreven regels wordt voldaan.

Uit de voorgaande voorbeelden is af te leiden dat het doel waarvoor een IDS wordt ingezet in sterke mate bepaalt hoe een IDS organisatorisch ingebed wordt.


6/26

3

CONCEPTEN Er is een aantal verschillende IDS-concepten te onderkennen. Dit is vaak een bron van verwarring met betrekking tot de rol die een IDS kan vervullen in het beveiligen van een organisatie, omdat ieder concept z’n eigen toepassing kent. Dit hoofdstuk gaat in op de verschillende concepten die de basis vormen van de huidige verschijningsvormen van een IDS. 3.1

Detectie van patronen of afwijkingen

Ruwweg zijn er twee concepten voor de werking van een IDS. Enerzijds is het mogelijk om op basis van patronen of zogenaamde signatures te werken. Dit zijn karakteristieken van specifieke aanvallen die een IDS gebruikt om te bepalen of die aanval plaats vindt. Ieder type aanval kent een eigen patroon, zoals een poortscan of de toepassing van een bepaalde exploit. Een IDS controleert dus niets anders dan of de acties die het ziet voldoen aan een bekend patroon. Het grote nadeel van deze signatures is dat de aanval in principe al bekend moet zijn bij de IDS leverancier en dat deze hiervoor een werkende signature beschikbaar heeft. Er kan dus een lange tijd sprake van zijn dat de aanval wel kan worden uitgevoerd, terwijl deze niet kan worden gedetecteerd. In feite specificeert een signature-based IDS alle mogelijke bekende ongewenste gedragingen. Anderzijds kan het IDS ook gebruik maken van zogenaamde afwijking of anomaly detectie. Dat wil zeggen dat het IDS kennis heeft wat normaal gedrag is. Op het moment dat gedrag daar (te veel) van afwijkt, geeft het een waarschuwing af. Deze methode probeert dus het grote probleem van signatures te vermijden, door te definiëren wat toegestaan is. Een eenvoudig voorbeeld van zo’n regel kan zijn: werknemers werken normaliter tussen 9 en 5 uur. In die periode mogen dus werknemers inloggen op hum werkplek. Wanneer er dus om 1 uur ’s nachts wordt ingelogd is er sprake van een afwijking op het normale gedrag. Samenvattend is een signature detectie systeem een systeem dat definieert wat niet is toegestaan, terwijl een anomaly detectie systeem definieert wat wel is toegestaan. Deze laatste vorm van detectie – anomaly - is tamelijk moeilijk te implementeren, zeker wanneer er sprake is van complexe aanvallen. Ook is een leerperiode nodig voor het goed functioneren van een anomally based IDS 3.2

Network IDS of Host IDS

Een Intrusion Detection Systeem kan op twee manieren worden ingezet. Het uitgangspunt is dat detectie plaatsvindt op een plek zo dicht mogelijk bij de bron van de aanval of zo dicht mogelijk bij het doel van de aanval. In geval van een netwerk IDS wordt het eerste gekozen, met als aanname dat de aanvallen via de externe koppeling het eigen domein in komen. In de praktijk zal dit in een DMZ zijn, in de buurt van de firewall behorende bij die koppeling. Ook op andere knooppunten in het netwerk kan zo’n Network based IDS (NIDS) worden geplaatst. Een NIDS richt zich dan ook op het detecteren van aanvallen die op het netwerk gericht zijn of van het netwerk gebruik maken. Een NIDS richt zich vaak op een breed scala van systemen, namelijk van welke het de netwerkstromen kan Intrusion Detection Systems versie 1.2 21 maart 2008

7/26

inspecteren, en dus over de netwerkinterface van het NIDS komen. Snort1 is een typisch voorbeeld van een Netwerk IDS.

Figuur 3-1, voorbeeld van plaatsing van NIDS in de netwerkinfrastructuur. De plaatsing is afhankelijk van het doel en zo dicht mogelijk bij de bron

Een Host based IDS (HIDS) daarentegen is een applicatie die op het eindsysteem wordt geplaatst. Dit kan zowel serversystemen betreffen als ook werkstations van gebruikers. Naast netwerkaanvallen die specifiek gericht zijn op het systeem, kan een HIDS ook aanvallen die op applicaties gericht zijn onderzoeken. Hierbij valt te denken aan het voorkomen van buffer overflows, of het overschrijven van systeembestanden. Een HIDS is vaak sterk geïntegreerd in het operating systeem waar het op draait en kan in principe ook de interne datastructuren van het OS monitoren om te bepalen of er sprake is van een aanval. Veelal zijn dergelijke producten voor de consumentenmarkt geïntegreerd in een personal firewall of virusscanner. Virusscanners zijn in principe niets anders dan een specialistische vorm van een HIDS. Deze detecteren, voornamelijk op basis van signatures, of bestanden virussen2 bevatten. Een andere specifieke vorm van een HIDS is een applicatie die de integriteit van bestanden beschermd zoals AIDE3 of de commerciële producten van Tripwire. Een dergelijke applicatie genereert van alle of een geselecteerd aantal bestanden een zogenaamde signature – in feite is dit niets anders dan een hash functie – en controleert het periodiek of de bestanden gewijzigd zijn. Zo ja dan is er blijkbaar

1

http://www.snort.org

2

Virussen, of wormen en andere “malware”

3

http://sourceforge.net/projects/aide


8/26

een aanval geweest. In sommige gevallen wordt deze functionaliteit ook in een virusscanner geïmplementeerd. Het probleem met deze software is dat het altijd achteraf controleert of er iets is misgegaan. Tevens is het dan heel moeilijk om het vertrouwen ergens op te baseren, namelijk wanneer er een aanval heeft plaatsgevonden, is het zeer goed mogelijk dat de aanvaller ook aanpassingen heeft gedaan in het IDS of het besturingssysteem, waardoor de detectie niet meer goed werkt. De enige manier om dit af te vangen is het controle mechanisme alsmede de signatures gescheiden op te slaan en het controle mechanisme te gebruiken in een vertrouwde toestand. Het is ook verstandig de IDS te verbergen, bijvoorbeeld door de netwerkinterface geen IP-adres toe te kennen of te verbinden met een read-only interface. 3.3

Honeypots

Om aanvallers af te leiden van echte systemen worden er soms systemen ingezet die ogenschijnlijk eenvoudig zijn te misbruiken – een dergelijk systeem wordt ook wel honeypot genoemd. In vele gevallen wordt hierbij ook een detectie systeem ingezet die waarschuwt op het moment dat een aanval plaatsvindt. Een honeypot kan een complete, maar ongebruikte omgeving bevatten (z.g. hig-hinteraction honeypots). Er zijn ook speciale systemen beschikbaar die wel de interfaces bieden maar niet de functionaliteit (de low-interaction honeypots). Een honeypot kan naast afleiding ook als doel hebben om inzicht te krijgen in aanvallen die plaatsvinden waardoor in het feitelijke netwerk al acties kunnen worden ondernomen om hiertegen bescherming te bieden. Het uitgangspunt is dat een honeypot een aantrekkelijker doelwit moet lijken dan het feitelijke netwerk. Een implementatie van honeypots is het Honeynet project4 dat gebruikt maakt van verschillende toepassingen om onderzoek te doen naar nieuwe aanvallen die op Internet plaatsvinden. Ook het monitoringsysteem van GOVCERT.NL maakt gebruik van honeypots. 3.4

Passieve IDS en reactieve IDS

Oorspronkelijk is een IDS een systeem dat gebruikt wordt om inbreuken te detecteren. In feite betekent dit dat het passief is, het geeft alleen aan dat er iets aan de hand is en specificeert voor zover mogelijk wat het probleem is. Het is echter ook mogelijk om een reactief IDS op te zetten. Een reactief IDS reageert op de gedetecteerde aanvallen. Op technisch niveau zijn er talloze manieren waarop een IDS kan reageren op een aanval. Hierbij valt te denken aan het afsluiten van een TCP verbinding door een TCP Reset te sturen naar beide eindpunten van de verbinding of door het tijdelijk blokkeren van een IP adres of IP range in de firewall of door een actie te blokkeren. Hierin schuilt echter een gevaar, namelijk dat het IDS wordt gebruikt om een Denial of Service (DoS) te realiseren. Ook kan dit als resultaat hebben dat er onnodige reacties plaatsvinden die het goed functioneren van de te beschermen omgeving tegengaan. Bij het definiëren van acties is het erg belangrijk vast te stellen wat de mogelijke gevolgen van een actie zijn. Een reactieve IDS vertoont een zekere overlap met het IPS concept, zie paragraaf 3.5. Het grote verschil tussen een

4

http://www.honeynet.org/


9/26

reactieve IDS en een IPS is dat een IPS een pro-actief wordt ingezet om aanvallen te voorkomen. 3.5

Intrusion prevention systems

Een Intrusion Prevention System (IPS), kan enerzijds worden gezien als een uitbreiding op het concept van een IDS, maar anderzijds is het eerder een uitbreiding op het concept van een firewall waarbij ook op applicatie niveau wordt gecontroleerd. In feite is een IPS een functionaliteit die netwerkverkeer opvangt en op basis van access control regels bepalen of het verkeer al dan niet wordt toegestaan. In vele gevallen wordt dit geïntegreerd in een firewall of in een proxy systeem. 3.6

Generiek of specifieke IDS

De meeste IDS-en zijn tamelijk generiek opgezet. Dat wil zeggen ze zijn dusdanig ontwikkeld dat ze zoveel mogelijk aanvallen kunnen detecteren, meestal gericht op Internet omgevingen. Daarnaast zijn er ook systemen die zich meer richten op specifieke dreigen. Hierbij valt bijvoorbeeld te denken aan fraude management systemen die gebruikt worden door telecom providers om verdachte (trans)acties op het gebied van telefoonverkeer te vinden en het bijbehorende billing systeem. 3.7

Opzet IDS

Er is een aantal verschillende redenen mogelijk om een IDS in gebruik te nemen. Over het algemeen is de belangrijkste reden om inzicht te krijgen in het netwerkverkeer (zie ook hoofdstuk 2, Waarom een IDS?). Pas als het doel duidelijk is, is het mogelijk om te bepalen hoe en waar een IDS ingezet moet worden. Dit is van toepassing op zowel de netwerkarchitectuur (bij NIDS) als op de inbedding in de organisatie. In het geval van HIDS is de netwerkarchitectuur minder relevant, omdat deze applicatie altijd op de hostcomputer aanwezig is. De output van de HIDS moet vaak wel via het netwerk naar een centrale server gestuurd worden voor correlatie en analyse, maar dit wordt over het algemeen over het normale intranet gedaan. In geval van NIDS wordt hier ook wel een parallel managementnetwerk voor gebruikt (zoals weergegeven in Figuur 3-1. Het sterke punt van een HIDS is het feit dat het naar meer bronnen kijkt dan alleen netwerkverkeer om inbraken te bepalen. Zo kunnen ook bepaalde hardware gegevens, zoals de inhoud van het geheugen, worden gebruikt. Een NIDS kan dit niet en zal daarom altijd afhankelijk zijn van het netwerkverkeer om analyses op te baseren. Een NIDS kan informatie verschaffen in de aanvallen die van het externe netwerk komen door het NIDS tussen die netwerkkoppeling te plaatsen. Als het goed is worden die aanvallen geneutraliseerd door middel van een firewall; om inzicht in het totale patroon van aanvallen te krijgen kan er ook een IDS aan de andere kant van de firewall geplaatst worden. Dit wordt toegepast bij GOVCERT.NL’s monitoringsysteem, waarbij de sensoren buiten de firewall en buiten de normale datastroom staat.


10/26

Omdat een NIDS vaak inzicht moet hebben in al het verkeer zijn er twee mogelijkheden: 1. het NIDS is een systeem met meerdere netwerkinterfaces, welke geplaatst is tussen de netwerkkoppeling waar al het verkeer doorheen gaat; 2. het NIDS wordt ‘naast’ de te monitoren koppeling(en) geplaatst, en door middel van de netwerkconfiguratie wordt gerealiseerd dat alle data bij het NIDS aankomt. In Figuur 3-2 zijn deze twee alternatieven schematisch weergegeven.

Alternatief 1 NIDS

Netwerksegment A Alternatief 2

Netwerksegment A

Netwerksegment B

NIDS

Netwerksegment B

Figuur 3-2 Plaatsing van een NIDS als schakel in de koppeling of als monitor ernaast

Het nadeel van alternatief 1 is dat het NIDS een Single Point of Failure (SPoF) is, maar staat wel toe dat het NIDS direct maatregelen neemt. Een voorbeeld hiervan is het tegenhouden van aanvallen na detectie. Ook de prestaties van het NIDS worden belangrijker, deze beïnvloeden immers de netwerkcapaciteit van de koppeling. Bij mogelijkheid 2 kan het IDS ook ingrijpen, maar dit vereist dat het NIDS de configuratie kan wijzigen van netwerkelementen als routers of firewalls, indien adreslijsten in de routers moet worden aangepast. In geval van bijvoorbeeld een hardware crash zal het netwerkverkeer niet beïnvloedt worden; in tegenstelling tot mogelijkheid 1. Onvoldoende prestatie van de NIDS leidt tot minder goede detectie en niet tot vermindering van netwerkcapaciteit.


11/26

4

AANDACHTSPUNTEN BIJ TOEPASSING VAN IDS Zoals in de voorgaande hoofdstukken is beschreven, speelt een samenspel van factoren een rol bij de introductie van een IDS. Dit hoofdstuk gaat in op een aantal van deze factoren om zo vaak gemaakte fouten te kunnen voorkomen. 4.1

Kosten

Bij de introductie van een IDS is er een aantal andere kosten waar rekening mee gehouden moet worden. Deze omvatten in ieder geval: 1) Aanschafkosten 2) initiële installatie/configuratiekosten; 3) operationele kosten. Ad 1) In deze eerste categorie vallen de kosten van het IDS zelf. Deze kosten kunnen in de vorm zijn van licentiekosten van een softwarepakket welke de rol van IDS vervuld. Naast deze softwarepakketten is het ook mogelijk dat het IDS wordt geleverd in de vorm van een appliance, waarbij de software op speciale hardware wordt geleverd. Deze hardware is veelal geoptimaliseerd voor maximaal rendement en voldoet aan de minimale systeemeisen van de software. De aanschafkosten zijn sterk afhankelijk van de fabrikant van het pakket, configuratie van de hardware en mogelijke onderhoudscontracten afgesloten met fabrikant/leverancier. Naast commerciële software pakketen zijn er ook een aantal software pakketen waaraan geen licentiekosten zijn verbonden zoals Snort. Snort – Open Source IDS

Al geruime tijd vormt Snort een de facto standaard voor

netwerk IDS. Het systeem, ontwikkeld als open source product door Martin Roesch en Sourcefire, is beschikbaar voor Linux en Windows platforms en wordt breed ingezet voor monitoring van IPnetwerken. Bij nieuwe typen aanvallen worden door de open source community (www.bleedingedge.com) en Sourcefire nieuwe signatures ontwikkeld. De Snort signatures vormen een de-facto standaard die ook door andere producten gebruikt worden.

Ad 2) De inzet van een IDS kan niet worden gezien als het toevoegen van een extra server in de infrastructuur. Mogelijk dat er wijzigingen in de infrastructuur/configuratie noodzakelijk zijn voor een correcte werking van het IDS. Denk hierbij bijvoorbeeld aan configuratie monitoring poort in een switched netwerk en/of koppeling naar beheeromgeving. Naast deze noodzakelijke aanpassingen in de infrastructuur kan ook de configuratie van het IDS een tijdrovende activiteit worden. Dit hangt samen met het doel van het IDS. Naast deze configuratie zal het IDS ook correct, volgens het beleid betreffende het IDS, moeten worden geconfigureerd voor onder andere een juiste reactie bij detectie van onregelmatigheden. Dit tunen is uiterst belangrijk. Ad 3) De kosten in deze categorie zijn onder andere de kosten voor eventuele updates van signatures en software, indien deze niet onder de onderhoudscontracten vallen. Naast deze directe kosten zijn er nog andere kosten welke worden gemaakt tijdens het operationeel zijn van het IDS zoals de kosten voor monitoren van het IDS (mogelijk 24/7); opleiden van personeel welke de Intrusion Detection Systems versie 1.2 21 maart 2008

12/26

gegevens van het IDS juist kunnen interpreteren. Daarbij komen ook nog de overige beheerkosten voor de systemen waaruit de IDS is opgebouwd. Al de bovenstaande aspecten maken de inzet van een IDS kostbaarder dan alleen de aanschafkosten van het product met mogelijk extra hardware. Al deze aspecten samen bepalen de totale kosten van het systeem, vaak worden deze kosten sterk onderschat! De kosten kunnen ook worden samengenomen door de uitbesteding van de monitoring en respons aan een bedrijf dat gespecialiseerd is in managed security services. Aanschaf- en operationele kosten worden in het uitbestedingscontract opgenomen, er moet nog wel rekening gehouden worden met de kosten van transitie. Deze transitie kosten zijn de kosten die gemaakt moeten worden om van een experimenteer opstelling naar een operationeel systeem over te gaan. 4.2

Tuning en updates

Onafhankelijk van de gebruikte methode, signatures of anomaly detectie, dient het IDS wel zo geconfigureerd te worden dat deze daadwerkelijk onregelmatigheden detecteert en niet te veel valse alarms afgeeft. De meeste op signatures gebaseerde IDS-en, beschikken over een breed scala aan mogelijke intrusions welke niet alle van toepassing zijn op de infrastructuur waar deze wordt ingezet. Als voorbeeld kan een infrastructuur zijn opgebouwd uit alleen maar systemen met een windows besturingssysteem. De signatures welke betrekking hebben op andere besturingssystemen zullen voor deze organisatie minder relevant zijn. Daarnaast kunnen deze signatures false positives (zie volgende paragraaf) opleveren. Het is dan ook zaak om deze signatures een lage prioriteit te geven of uit te schakelen. Naast deze tuning waarbij onderscheid wordt gemaakt in relevante en minder relevante patronen zal het IDS ook moeten worden aangepast als er veranderingen in de infrastructuur plaatsvinden. In bovenstaand voorbeeld, als er in verloop van tijd alsnog andere besturingssystemen worden geïntroduceerd worden de bijbehorende signatures weer relevant. Hierbij geldt dan dat het tuning een proces is waarbij het IDS continue moet worden geëvalueerd en waarnodig bijgesteld. Een handig tool bij het tunen van een IDS is Snot. Dit programma kun je configureren met de regels van je IDS, waarna het patronen gaat genereren die de IDS dan weer kan detecteren. Afgezien van het toekennen van verschillende prioriteiten aan de beschikbare signatures, komen in de loop van de tijd ook nieuwe signatures beschikbaar. Over het algemeen zal de beschikbaarheid van nieuwe signatures achter lopen op het optreden van onregelmatigheden. Het is belangrijk voor de doeltreffendheid van de IDS om een zo volledig mogelijk beeld te houden over de onregelmatigheden welke optreden, al is het dan niet altijd 100%. Zorg daarom dat het IDS is up-todate is met de meest recente signatures. 4.3

Betrouwbaarheid output

Een algemeen probleem van detectieve maatregelen is dat de alertheid voor respons afneemt met het aantal valse alarmen, dat gegenereerd wordt. Daarom is het cruciaal te bepalen in hoeverre de informatie die het IDS geeft juist is.


13/26

In het geval van een onjuiste configuratie, tuning of het niet up-to-date zijn van de laatste aanvalssignatures kan een onjuist beeld ontstaan van de onregelmatigheden welke optreden. Er zijn twee soorten foutieve resultaten, namelijk false positive en false negative. In het geval van een false positive wordt een melding gemaakt van een onregelmatigheid daar waar geen onregelmatigheid is opgetreden. Een ongewenst effect van het herhaaldelijk optreden van een false positive is dat in de toekomst het vertrouwen in meldingen afneemt. Bovendien bestaat de mogelijkheid dat echte meldingen niet meer worden gezien door de hoeveelheid van de foutieve meldingen. Een derde nadeel van false positives is de onnodige effort en/of kosten die gemaakt worden bij een respons. In het geval van false negative wordt er geen melding gegeneerd in het geval waar wel een onregelmatigheid optreedt. Dit houdt in dat er een mogelijke aanval wordt uitgevoerd waarbij er in het IDS geen melding van wordt gemaakt, waardoor hierop geen (re)actie wordt gegeven. 4.4

Uitvoeren van monitoring taken

Het geven van meldingen door het IDS op zichzelf is niet voldoende. Ze krijgen pas waarde als ze worden geïnterpreteerd en er mogelijk actie wordt ondernomen. Afhankelijk van het doel en de acceptabele response tijden, kan dit leiden tot een continue monitoring/beschikbaarheid, 24x7, aangezien onregelmatigheden niet aan kantoortijden gebonden zijn. Een alternatief is alarmering van de beheerder buiten kantoortijden via pager of SMS, waarna actie kan worden ondernomen. Dit aspect zal zijn weerslag hebben op de operationele kosten van de inzet van het IDS. De meldingen die worden gegenereerd verschillen in detail, zowel per type melding als ook per IDS product. In de meeste gevallen wordt een overzicht gegeven met een generieke aanval benaming, waarbij veel naar de bekende kwetsbaarhedendatabases wordt verwezen, zoals CVE. Vaak is het mogelijk om via een gebruikersinterface aanvullende informatie op te vragen. In enkele gevallen is er ook informatie beschikbaar over de pakketten die geleid hebben tot het genereren van een melding. Voor een juiste interpretatie van meldingen en het selecteren van een juiste (re)actie dient de beheerder van het IDS te beschikken over een gedegen kennis. Deze kennis is niet alleen beperkt tot het kunnen vertalen van deze generieke aanvalsbenaming naar meer detail. De beheerder moet in staat zijn een vertaling te maken wat dit voor de infrastructuur betekent. Dit houdt in dat de beheerder tenminste kennis moet hebben van omgang met de IDS omgeving en algemene infrastructuur kennis. Bovendien moet de beheerder kennis hebben over de mogelijke onregelmatigheden die kunnen optreden. Zo zal een beheerder bijvoorbeeld een ”smurf aanval” moeten kunnen interpreteren. Na de interpretatie van een melding zal besloten moeten worden welke vervolgstappen genomen worden. Deze zijn afhankelijk van de ernst en aard van de melding en kan uiteindelijk bestaan uit escalatie naar de informatiebeveiligingsverantwoordelijke of GOVCERT.NL Voor een beheerder dient het duidelijk te zijn welke vervolgstappen mogelijk zijn en in welk geval welke keuze gemaakt dient te worden. Hieraan ligt een heldere incidentmanagement procedure ten grondslag. Hierin is een duidelijk escalatiepad Intrusion Detection Systems versie 1.2 21 maart 2008

14/26

noodzakelijk. Het moet dus ook duidelijk zijn wie welke verantwoordelijkheid en welke bevoegdheid heeft. In het ergste geval zal de gehele infrastructuur moeten wordt afgesloten om escalatie van problemen te voorkomen. 4.5

Interpretatie van IDS output

Een van de belangrijkste onderdelen van het effectief toepassen van een IDS is de manier waarop de IDS-output wordt verwerkt. Voorbeelden van het verwerken van IDS-output zijn: •

Bepalen of een melding van een aanval correct is;

•

Bepalen of een aanval succesvol is geweest;

•

Bepalen of meerdere meldingen kunnen worden gecorreleerd tot 1 aanval;

•

Bepalen of er nieuwe soorten aanvallen zijn uitgevoerd;

•

Verzamelen van meer informatie over een aanval (bijvoorbeeld locatie aanvaller).

Dit kan natuurlijk volledig handmatig gedaan worden, maar dat wordt onpraktisch wanneer het IDS veel data genereert. Er zijn wel oplossingen die de IDS-output automatisch kunnen correleren en verwerken tot een rapportage maar deze bevinden zich nog grotendeels in de ontwikkelfase. Er is ook software die de output van meerdere IDS-en en eventueel ook andere bronnen zoals firewalls, virusscanners, honeypots, nessus-scans etc. Deze software is zodanig geconfigureerd dat het de input kan correleren en combineren tot een enkele presentatie. Voorbeelden zijn Prelude, Sims, OSSIM, OpenSims, OSSEC. Deze pakketten zijn over het algemeen lastig te configureren. Om de correcte interpretatie van IDS-output te controleren, zowel door het IDS, de IDS-output processor en de beheerders, is het mogelijk om periodiek penetratietesten uit te voeren om te bepalen of a) de IDS werkt en b) de beheerders hier correct op reageren. Indien dit laatste een van de doelstellingen is van een penetratietest is het nodig dat de beheerders niet op de hoogte zijn van deze penetratietest. Feitelijk is een IDS nutteloos als er geen kundige beheerders zijn die de IDSoutput correct weet te interpreteren. De beheerders moeten daarom technisch onderlegd zijn, en weten welke handelingen wanneer uitgevoerd moeten worden. Op basis van kennis en ervaring van de beheerders moeten beslissingen genomen worden, zoals: •

Blokkeren van netwerktoegang voor een IP adres

•

Het melden van misbruik aan de leiding gevende van een gebruiker die de IDS melding veroorzaakt

•

Abuse-mail sturen naar ISP van aanvaller

•

Escaleren naar de security officer


15/26

Figuur 4-1 Voorbeeld van een IDS-monitor (SAM in combinatie met Snort)

4.6

Correlatie tussen meldingen

Naast de vervolgstappen op meldingen van het IDS is het mogelijk om de meldingen te gebruiken voor de identificatie van relaties tussen verschillende meldingen van verschillende systemen en/of sensoren. Correlatie van meldingen kan worden gebruikt voor het verminderen van foutieve meldingen, zowel false positives als false negatives. Zo kan bijvoorbeeld aan de hand van een tweede melding worden gecontroleerd of de eerste melding valide is (alarmverificatie). Tevens is het mogelijk door de combinatie van twee meldingen meer informatie in te winnen over de onregelmatigheid. Een voorbeeld is dat detectie van een netwerkscan gevolgd door een portscan van eenzelfde bron geeft inzicht over de mogelijke voortgang van een aanval. In de meest eenvoudige vorm worden meerdere sensoren van hetzelfde IDS geplaatst in de infrastructuur. Deze sensoren genereren meldingen welke centraal worden geanalyseerd en gecorreleerd. In dit geval wordt er gebruik gemaakt van een leverancier welke meerdere sensoren plaatst. Het formaat en syntaxis van meldingen kan door de leverancier gekozen worden, en zolang het centrale analyse en correlatie onderdeel deze syntaxis kan interpreteren kan correlatie plaatsvinden. In een tweede opzet worden sensoren van verschillende leveranciers gecombineerd. In dit geval zal het niet altijd mogelijk zijn om deze meldingen (automatisch) aan elkaar te relateren doordat de syntaxis van de meldingen van beide leveranciers afwijken en geen van beide de syntaxis van de ander kan interpreteren. Er zijn ontwikkelingen voor een generieke syntaxis welke dit


16/26

probleem zal kunnen overbruggen. Een voorbeeld hiervan is het Intrusion Detection Message Exchange Format (IDMEF). Dit vereist veelal een aanpassing van de software van de verschillende leveranciers, of het inzetten van een middleware oplossing. Naast het koppelen van meldingen van IDS-en kan een meer generieke aanpak gekozen worden door gebruik te maken van informatie die beschikbaar is in de infrastructuur. Bestaande systemen beschikken veelal over de mogelijkheid om activiteiten op te slaan en te rapporteren. Deze informatie kan gebruikt worden voor optimalisatie van het detecteren van onregelmatigheden. Een voorbeeld is de syslog informatie beschikbaar op routers of de log-informatie gegenereerd en opgeslagen op firewalls. Ook hier gelden dan de beperkingen van formaat en syntaxis van de verschillende systemen. De relaties tussen verschillende meldingen kan vergeleken worden met bekende aanvalspatronen. Dit houdt in dat er vooraf kennis moet zijn over de mogelijk verschillende relaties tussen meldingen en dat deze moeten worden geconfigureerd in het IDS systeem. Uiteindelijk komt het erop neer dat de kennis met betrekking tot relaties, van de beheerder wordt verschoven naar een automatische analyse. Deze automatische analyse komt van pas daar waar veel meldingen worden gegenereerd en waar het handmatig niet meer overzien kan worden. Dit kan ook komen door relaties tussen meldingen welke over een lange tijdsperiode optreden. Het invoeren van deze kennis in een correlatieproces moet niet worden gezien als vervanging van de eigen kennis met betrekking tot aanvalspatronen en kennis over de infrastructuur. Deze eigen kennis is nog steeds essentieel in het gehele proces, omdat dit de ernst van aanvallen helpt inschatten of recente wijzigingen in de infrastructuur inbrengt. Voor IDS-en bestaat de mogelijkheid deze nauw samen te laten werken met bijvoorbeeld kwetsbaarheidscanners zoals Nessus. De resultaten van een kwetsbaarheidscanner kan invloed hebben op het bepalen van prioriteiten van aanvalspatronen. Kwetsbaarheidscanners beschikken over de mogelijkheid om te bepalen welke services op een systeem aangeboden worden. Daarnaast zijn ze ook vaak in staat te achterhalen welk besturingssysteem op de verschillende componenten gebruikt wordt. Deze informatie kan worden gebruik bij het configureren en afstellen van het IDS. 4.7

Versleuteling van dataverkeer

IDS-en die gebruik maken van signatures moeten toegang hebben tot onversleutelde gegevens om het dataverkeer te kunnen beoordelen op eventuele problemen. Het gebruik van versleuteld dataverkeer, zoals bijvoorbeeld het geval is bij https of ander SSL verkeer, kan er voor zorgen dat het IDS niet kan bepalen of er sprake is van een aanval, immers het IDS kan de versleutelde data niet interpreteren. Deze beperking betreft voornamelijk netwerk IDS-en, aangezien Host IDS-en over het algemeen wel toegang hebben tot de onversleutelde data omdat deze meestal geïntegreerd zijn in het operating systeem. Een mogelijkheid is dat het IDS wordt uitgerust met de sleutels die voor de versleuteling worden gebruikt. Al roept dit allerlei nieuwe vragen op ten aanzien van het werken met sleutelmateriaal.


17/26

5

ORGANISATORISCHE INBEDDING VAN EEN IDS Uit het voorgaande blijkt dat IDS geen kwestie is van simpelweg een systeem installeren. Afhankelijk van scope en doel zijn verschillende partijen binnen een organisatie betrokken bij het inrichten van een IDS. 5.1

Relatie met andere processen

Zelfs wanneer een IDS “alleen” ingezet wordt om de infrastructuur te beveiligen is het noodzakelijk om na te denken wat de relatie is met andere processen zoals vulnerability- en patchmanagement.

Configuratie management

Leverancier(s)

patches Patchmanagement

Producenten Security gerelateerde patches

Incident management

GOVCERT.NL

Leverancier(s) Producenten Security bedrijven

Leverancier(s) Producenten Security bedrijven

Vulnerability management

Beveiligingsadvies

Vulnerabiltiy informatie

IDS Signatures

Figuur 5-1 Relatie met andere security management processen

Vulnerability management richt zich op het inzage krijgen in de mogelijke kwetsbaarheden in de infrastructuur en kan daarbij input leveren voor een IDS. Daarnaast kan een IDS ondersteuning bieden bij het oplossen van incidenten binnen een incidentmanagement proces. Om te voorkomen dat er een ongecontroleerde wildgroei van functionaliteit gaat ontstaan is het aan te raden om bij de introductie van een IDS ook een systeemeigenaar aan te wijzen. Deze is verantwoordelijk voor bepalen van de vereiste functionaliteit en coördineert veranderingen aan de IDS binnen de kaders van het beleid of geeft advies over bijstelling van dit beleid.


18/26

5.2

Beleid rondom een IDS

Het opstellen van het beleid rondom een IDS hangt sterk samen met de scope en doelstelling van een IDS en vloeit voort uit de strategie voor security management en het algemene beveiligingsbeleid. Over het algemeen raakt een IDS meerdere gebieden en is het daarom aan te bevelen het beleid op te stellen onder de verantwoordelijkheid van het overkoepelende management. Vergeet niet om de bevoegdheden van de betrokken rollen te benoemen. Zeker in het geval van proactief kunnen reageren op potentiële problemen is snelheid van handelen gewenst. Sluit ook hier waar mogelijk aan op bestaande escalatiepaden en rollen die al in de organisatie belegd zijn. Waar in het beleid antwoord op gegeven moet worden zijn onder andere de relatie tussen een IDS en prioriteit voor het uitvoeren van patches. Een IDS kan gebruikt worden om inzicht te krijgen welke kwetsbaarheden actief uitgebuit dreigen te worden. In zo’n geval is het noodzakelijk om een duidelijke relatie met het patchmanagement proces te hebben. Belangrijke vragen hierbij zijn: -

bij wie ligt de beslissing om prioriteiten voor patches vast te stellen? en

-

hoe verhoudt deze zich tot de beheerder van de IDS?

Omgekeerd is er ook een relatie omdat patches van invloed kunnen zijn op een IDS. Zo zal de alarmering van potentieel misbruik van een bepaalde kwetsbaarheid uit een IDS van een lagere prioriteit moeten worden zodra alle systemen die kwetsbaar waren voorzien zijn van een patch, om zo false positives te voorkomen. Waar in het beleid ook rekening mee gehouden moet worden zijn privacy aspecten. Een IDS kan een grote hoeveelheid data verzamelen en inzichtelijk maken. Afhankelijk van de inrichting van de IDS kan het voorkomen dat hier privacy gevoelige informatie tussen zit. Het is goed om bij het opstellen van het beleid rekening te houden met relatie tussen het doel waarmee de IDS wordt ingezet en de noodzakelijke informatie. Het is aan te bevelen om hierover te overleggen met de juridische afdeling en indien nodig de gebruikers te informeren. Ook moet vooraf worden afgesproken zijn welke stappen worden ondernomen als privacy gevoelige informatie wordt verzameld. Dit wordt meestal snel aan het management overgelaten. Uiteindelijk blijft een belangrijke vraag over. Rechtvaardigt de introductie van een IDS het creëren van nieuwe rollen of worden additionele taken toegewezen aan al bestaande rollen?


19/26

6

KWETSBAARHEDEN VAN IDS Net als elke verandering brengt ook het inzetten van een IDS potentiële kwetsbaarheden met zich mee. Het is goed om kennis te nemen van deze kwetsbaarheden voordat keuzes gemaakt worden over de inzet en inrichting van een IDS. 6.1

Omzeilen van IDS functionaliteit

Zo zijn er talloze methoden om IDS-en te omzeilen. In feite is dit een wedloop tussen de good guys en de bad guys. Wanneer er een nieuwe evasion techniek is bedacht, proberen IDS ontwikkelaars nieuwe detectie methoden te bedenken. In feite blijft het zo dat de IDS ontwikkelaars altijd achter de feiten aan blijven lopen. Een bekend voorbeeld van een evasion techniek is om het pad van een bestand aan te passen. In plaats van rechtstreeks het bestand “/etc/passwd” op te vragen wordt “/etc/X11/.././passwd” opgevraagd. Indien een IDS alleen detecteert of de bestandsnaam “/etc/passwd” is zal string “/etc/X11/.././passwd” ongemerkt het IDS passeren, terwijl het effectief hetzelfde bestand aanduidt. In principe is dit een voorbeeld van het uitbuiten van de signature aanpak. In de lijst met signatures zal het IDS een regel hebben staan dat “/etc/passwd” niet mag worden opgevraagd, terwijl de string “/etc/X11/.././passwd” hier niet aan voldoet. Er zijn talloze van dergelijke methodes die het goed functioneren van een IDS kunnen belemmeren, zoals fragmenteren van pakketten en fouten in CRC-checks maken. Het hierboven beschreven probleem geldt vooralsnog met name voor signature gebaseerde oplossingen. Waar ook voor gewaakt moet worden is de situatie dat een aanvaller telkens een vals alarm door het IDS laat genereren, waardoor de beheerder er na verloop van tijd geen aandacht meer aan besteed, of zelfs het alarm voor dat type aanval uitschakelt. De aanvaller kan dan ongestoord de echte aanval uitvoeren zonder dat het zal worden opgemerkt. Dit worden injection technieken genoemd. Een vergelijkbare aanval bestaat uit het continu genereren van aanvallen (door het bron-IP-adres te vervalsen kan een aanvaller zijn locatie verbergen waardoor het moeilijk is om de aanvallen te stoppen). De beheerder zal vervolgens veel moeite hebben om uit alle valse meldingen de echte aanvallen te halen. Een implementatie van een anomaly-based IDS zal veelal op basis van neurale netwerken zijn waarbij het IDS zelf-lerend is. In de beginperiode moet het IDS zelf bepalen wat normaal verkeer is. Tijdens dit leerproces is een IDS erg kwetsbaar. Misbruik in deze periode kan er voor zorgen dat gelijksoortige misbruiken in een latere fase niet worden herkend. Ook in een latere fase bestaat het gevaar dat het leer-vermogen van het IDS wordt misbruikt om bepaalde aanvallen niet meer als een anomaly te zien. Een voorbeeld hiervan is een poortscan beginnen met 2 poorten, en dan elk uur het aantal poorten langzaam op te laten lopen. Uiteindelijk zou het IDS een volledige poortscan niet meer als anomaly en dus aanval zien.


20/26

Er zijn dan ook weinig betrouwbare systemen die op basis van alleen anomaly detectie functioneren. In de meeste gevallen wordt daarom gekozen voor een signature gebaseerde oplossing, gecombineerd met een klein aantal vooraf bepaalde regels op basis van anomaly detectie. 6.2

Toegang tot de IDS

De beheertoegang tot de NIDS wordt vaak vanaf een aparte verbinding gedaan, waardoor alleen de beheerstations toegang hebben. Hiermee wordt een groot risico sterk verminderd, namelijk beheertoegang voor aanvallers door bijvoorbeeld brute-force aanvallen op de login, of door password guessing. Alleen wanneer de aanvaller al toegang heeft weten te krijgen tot het beheernetwerk is dit nog mogelijk. Om toegang tot de IDS te beperken is het voor een passieve NIDS voor de hand liggend om de netwerkinterface naar het IDS toe uni-directioneel te maken. Hierdoor wordt het IDS zelf minder kwetsbaar voor aanvallen en kan niet misbruikt kan worden als platform voor verdere aanvallen. Dit heeft echter wel enige consequenties voor de inrichting. Niet elke netwerkinterface card (NIC) ondersteunt eenvoudigweg het doorknippen van het verzendkanaal. Deze zal ofwel moeten worden kortgesloten met het ontvangstkanaal, of er zal een andere maatregel moeten worden getroffen. In sommige gevallen ondersteunen switches een zogenaamde monitoring poort die standaard alleen kan worden gebruikt om informatie (naar het IDS) te versturen, zodat het IDS effectief alleen informatie kan ontvangen. Wanneer er een hoge mate van zekerheid vereist is dat de interface uitsluitend informatie kan ontvangen is een zogenaamde datadiode een oplossing. 6.3

Locatie van het IDS

Wanneer het NIDS wordt geplaatst in een netwerkverbinding waar veel informatie door wordt gestuurd, kan het NIDS tijdens hoge netwerkbelasting een bottleneck vormen waardoor willekeurige pakketten niet meer aankomen. Ze vormen dan een risico voor DoS-aanvallen. Ook als het NIDS de data indirect krijgt aangeleverd (dus geen schakel is in de directe verkeersstroom) bestaat het gevaar dat het NIDS het dataverkeer niet kan verwerken. Dit zal niet leiden tot pakketten die niet op de bestemming aankomen, maar eventueel wel tot het missen van aanvallen. Een HIDS heeft het gevaar dat softwarefouten in de HIDS leiden tot remote exploits die door de aanvaller juist gebruikt kunnen worden om het systeem ‘over te nemen’. Dit risico wordt vergroot doordat het IDS vaak geïntegreerd wordt met het besturingssysteem waardoor een kwetsbaarheid in de HIDS kan leiden tot toegang tot het besturingssysteem. Dit betekent dat het een interessant platform is om te misbruiken – hoewel dat in de praktijk nog niet heel vaak gebeurd. Wel zijn er al een aantal kwetsbaarheden in de bekende viruspakketten als NORTON e.d. geweest. Wat wellicht belangrijker is, een HIDS kan een forse impact hebben op de performance van het bewaakte systeem.


21/26

6.4

Onbetrouwbare IDS output

Er zijn ook IDS-en die in sommige gevallen zelf actie ondernemen, bijvoorbeeld het tegenhouden van bepaalde pakketten, of het tijdelijk tegenhouden van al het netwerkverkeer van/naar een systeem. In het geval van een geavanceerde aanval kan zo’n IDS (dit geldt zowel voor een HIDS als een NIDS) juist gebruikt worden om een aanval uit te voeren. Denk bijvoorbeeld aan het genereren van aanvallen met als bron-IP-adres de interne domainserver, wanneer de IDS automatisch dat IP adres blokkeert, zorgt dat voor een Denial of Service voor alle werkstations in het netwerk. Omdat de IDS-output onbetrouwbaar is (zie bovenstaande voorbeelden waarbij informatie wordt vervalst) is het voor de beheerder niet verstandig om alleen hierop beslissingen te baseren. Het is daarom van belang dat de IDS output alleen als een ondersteunende informatiebron gebruikt wordt. Pas na validatie van de informatie, bijvoorbeeld door het traceren van het kwaadaardige netwerkverkeer via de routers, kan actie worden ondernomen.


22/26

7

ERVARINGEN MET EEN IDS GOVCERT.NL heeft nu bijna twee-en-een-half anderhalf jaar ervaring in het monitoring project opgebouwd. Het monitoring project is een vorm van IDS, bestaande uit verschillende slimme sensoren en honeypot technologie. Op basis van een pilot is bepaald welke bijdrage een monitoringsysteem kan bieden bij de dienstverlening vanuit GOVCERT.NL en welke functionaliteit daarvoor noodzakelijk is. Het doel van het monitoringproject is het ontwikkelen van een betrouwbaar earlywarningsysteem door objectieve gegevens te verzamelen over bekende en onbekende aanvallen op de netwerken van Nederlandse overheidsinstanties. Een sleutelfunctie is het elimineren van false positives waarbij het systeem wormen, virussen en bekende exploits herkent.

LOGGING

SENSOR

HONEYPOT

WEBSERVER

PRODUCTION LAN

Figuur 7-1 Opzet van het GOVCERT.NL Monitoringsysteem

Ervaringen in het monitoringproject zijn samen te vatten in de volgende kernboodschappen: •

Stel een duidelijk doel aan de start van het project om te voorkomen dat gedurende het traject de plannen steeds wijzigen. Stel het doel verder dan het eind van de pilot.

•

Kijk goed om je heen, maak gebruik van organisaties die ervaring opgebouwd hebben op het gebied van IDS. Denk hierbij bijvoorbeeld aan de “Network Monitoring Special Interest Group for the Forum for Incident Response and Security Teams (FIRST)”.

•

Houd rekening met privacy gevoelige informatie. Een monitoringsysteem verzamelt een verscheidenheid aan informatie zoals IP adressen en inhoud van IP pakketten. Overleg met de juridisch adviseur over de juridische aspecten van een monitoringsysteem.


23/26

•

Maak een gedegen afweging van de voor- en nadelen van technische opties. Onderschat ogenschijnlijk triviale aspecten niet. Zo heeft het een behoorlijke tijd geduurd om een geschikte combinatie van hardware en een bootable USB stick te vinden.

•

Een plaatje zegt meer dan duizend woorden. Indien het IDS ook management informatie moet presenteren besteed dan voldoende tijd aan een gedegen user interface.

•

Betrek een gebruikersgroep die feedback geeft over de bruikbaarheid van het IDS voor de gestelde doelen en communiceer helder over de acties die genomen zijn op basis van de feedback.


24/26

8

CONCLUSIES Deze white paper geeft een overzicht van verschillende Intrusion Detection Systemen en de aandachtspunten bij toepassing van IDS. •

•

•

•

•

De effectiviteit van een IDS wordt aanzienlijk verhoogd als vooraf goed wordt nagedacht over de doelen van de toepassing van IDS. Dit bepaald type en plaatsing van de IDS en de verwachtingen die je kunt stellen ten aanzien van IDS. De kosten van het implementeren van IDS liggen vooral in de operatie en niet in de aanschaf. Onderhoud en beheer vergen behoorlijke inspanning en de response op meldingen zorgen voor meer operationele druk. Een IDS is ook kwetsbaar voor misleiding en fouten Daarnaast levert IDS false positives en false negatives, die de output minder betrouwbaar maken. Dit maakt dat een IDS niet kennis en ervaring kan vervangen. Om de gegevens van een IDS te kunnen overzien en correlaties tussen meldingen te maken, moet overwogen worden om management tools te gebruiken. Toepassing van IDS vergt aanpassing van beleid en procedures en vastleggen van escalatiepaden voor meldingen en incidenten die privacy gevoelig zijn.


25/26

BIJLAGE A: AFKORTINGEN

Afkorting

Omschrijving

CVE

Common Vulnerabilities and Exposures, een standaard systeem voor beschrijving en volgen van kwetsbaarheden (cve.mitre.org)

DMZ

De-Militarized Zone,

DoS

Denial of Service

HIDS

Host based Intrusion Detection System

HIPS

Host based Intrusion Prevention System

IDMEF

Intrusion Detection Message Exchange Format

IDS

Intrusion Detection System

IP

Internet Protocol

IPS

Intrusion Prevention System

ISP

Internet Service Provider

NIC

Network Interface Card

NIDS

Network based Intrusion Detection System

NIPS

Network based Intrusion Prevention System

OS

Operating System (Besturingssysteem)

SPoF

Single Point of Failure

TCP

Transport Control Protocol

VA

Vulnerability Assessment


26/26

INTRUSION DETECTION SYSTEMS

Recommend Documents