AccessGuard
Inleiding
Donker zwart, 4 kilo licht en een afmeting van 10 bij 47 bij 60 centimeter. Dit zijn de gegevens van de AccesGuard, een zwaargewicht die hackers, crackers en ander gespuis buiten de deur moet houden. Ontworpen door het Haagse Access Security Advisors (XSA) hebben we hier te maken met een heus turnkey intrusion prevention system (IPS). Je sluit de doos aan en het werkt. Het apparaat is volledig plug'n play, een keyboard en muis zijn dan ook niet nodig. De AccessGuard is echter geen vervanging van een virusscanner en ook uw firewall kan gewoon blijven draaien als de AccessGuard is geïnstalleerd, als extra apparaat, zo laat de productbeschrijving van XSA ons weten.
Het IPS zelf is een 2U 19’’ rack mountable unit die geplaatst wordt tussen de (enge) buitenwereld en het (veilige) interne netwerk.
Verschillen met bestaande IDSs
Zoals de term Intrusion Prevention System al aangeeft is het eerste grote verschil met andere IDSs dat de AccessGuard niet alleen de aanvallen waarneemt maar ook de mogelijkheid bezit om deze tegen te houden.
Het tweede cruciale verschil is dat de AccessGuard functioneert als een bridge, dit betekend dat in tegenstelling tot andere IDSs dat de AccessGuard zelf geen code hoeft te implementeren voor TCP en IP reassembly. Andere IDSs sniffen meestal het netwerkverkeer en implementeren dan zelf code om het netwerkverkeer te reassemblen, dit is een complex proces en vrijwel onmogelijk om helemaal goed voor elkaar te krijgen. Doordat in het geval van de AccessGuard de kernel van het host OS (FreeBSD) al zorg draagt voor alle TCP en IP specifieke processing, is de AccessGuard niet zo makkelijk te omzeilen als een IDS.
Als laatste valt het op dat het werkelijk een “turnkey” product is, in tegenstelling tot andere IDSs is er aan de gebruikers kant geen specifieke kennis nodig om het IPS aan het werk te zetten, het is een kwestie van aansluiten en weglopen.
Log bestanden
Via de gebruikersvriendelijke web interface van de AccesGuard kunnen de aangemaakte log bestanden bekeken worden. Het is echter niet mogelijk om in deze web interface de huidige lijst van signatures te bekijken, bestaande signatures aan te passen of eigen signatures toe te voegen, iets dat voor de meer technische onderlegde klant kan een probleem kan zijn.
Tevens kan de gebruiker niet in de log bestanden zien wanneer er updates op de IPS zijn geïnstalleerd. Op het moment dat er een software update of een nieuwe signature wordt geïnstalleerd door XSA is dit niet zichtbaar.
Technische Analyse
Security.nl heeft de AccessGuard onderhanden genomen. Tijdens deze tests werd gekeken naar de betrouwbaarheid en effectiviteit van het Intrusion Prevention System (IPS) op een aantal verschillende gebieden. De test is onderverdeeld in drie verschillende subdelen; ‘IPS evasion’, ‘IPS false-positives’ en ‘IPS reliability’.
IPS evasion
In dit gedeelte van de audit wordt er gekeken of het IPS omzeild kan worden; er worden verschillende technieken toegepast die als doel hebben een zwakte in de regels (ruleset) of de implementatie van de IPS te lokaliseren.
Toelichting IPS evasion tests
Security.nl voert standaard de volgende IPS evasion tests uit:
Encoded HTTP requests
De requests worden gecodeerd met een aantal verschillende methodes om te bepalen of het IPS de mogelijkheid bezit deze requests te decoderen en ze dan alsnog tegen de ruleset te valideren.
Doubly encoded HTTP requests
De requests worden dubbel gecodeerd met een aantal verschillende methodes om te bepalen of het IPS in staat is de requests goed te hercoderen voordat deze worden doorgestuurd naar de achterliggende webserver.
Mangled HTTP requests
De requests worden op een aantal verschillende manieren verminkt, op zo’n manier dat de achterliggende webserver ze nog wel accepteert, om te bepalen of het IPS dezelfde request-parsing logica ondersteunt als de achterliggende webserver.
Positioned HTTP requests
Er wordt voor gezorgd dat de requests maar voor een gedeelte in de interne buffer van het IPS passen. Dit wordt bereikt door de interne buffer grote van het IPS te bepalen en daarna de requests te prefixen met het juiste aantal (headers) bytes. Het doel van deze test is om te bepalen wat het IPS in dit geval doet.
Simple IP fragmentation
Dit is de simpelste vorm van de IP fragmentatie tests, de requests worden in een aantal op een volgende IP fragments opgesplitst en daarna normaal sequentieel naar het IPS verstuurd. Het doel van deze test is om te bepalen of het IPS in staat is tot IP reassembly.
Reverse IP fragmentation
Dit is de tweede variant op de IP fragmentatie tests, de requests worden wederom verspreid over een aantal IP fragments maar bij deze tests worden de verschillende fragmenten achterstevoren (last-first) naar het IPS verstuurd. Het doel van deze test is om te bepalen om het IPS ook dit kan reassemblen.
Random duplication fragmentation
Dit is de derde variant van de IP fragmentatie tests, de requests worden wederom verspreid over een aantal IP fragments maar nu worden er willekeurig een aantal fragmenten gedupliceerd. Het doel van deze test is om te bepalen hoe het IPS omgaat met dubbele fragmenten.
Interleaved fragmentation
Dit is de laatste variant van de IP fragmentatie tests, de requests worden wederom verspreid over aantal IP fragments maar nu worden er willekeurig een aantal gedupliceerde fragmenten toegevoegd met een andere payload.
Resultaten IPS evasion
| Uitgevoerde Test | Resultaat |
| Encoded HTTP requests | PASS |
| Doubly encoded HTTP requests | PASS |
| Mangled HTTP requests | PASS |
| Positioned HTTP requests | PASS |
| Simple IP fragmentation | PASS |
| Reverse IP fragmentation | PASS |
| Random duplication fragmentation | PASS |
| Interleaved fragmenetation | PASS |
IPS false-positives
In dit gedeelte van de audit wordt er gekeken of het IPS (erg) gevoelig is voor het genereren van zogehete ‘false-positives’. Onder een ‘false-positive’ verstaan we het probleem dat het IPS een aanval signaleert terwijl er geen plaatsvindt.
Op het moment dat een IPS erg veel ‘false-positives’ genereert kan dit tot gevolg dat er ongefundeerde stress op de beheerders wordt gelegd en dat legitieme clients toegang wordt ontzegt tot bijvoorbeeld een webserver.
Toelichting IPS false-positives tests
Security.nl voerde de volgende IPS false-positives tests uit:
Failure on common requests
Tijdens deze tests werd gekeken of het IPS, op dat moment, een ruleset bevatte die er voor kon zorgen dat normale, legale, requests werden aangemerkt als een aanval. Het doel is om de kwaliteit van de ruleset te bepalen.
Resultaten false-positives
| Uitgevoerde Test | Resultaat |
| Failure on common requests | PASS |
IPS reliability
In dit gedeelte van de audit wordt er gekeken naar de stabiliteit van het IPS, er worden verschillende technieken gebruikt om de load op het IPS op te voeren waarna er wordt gekeken of het IPS nog steeds zijn functie vervult.
Toelichting IPS reliability tests
Security.nl voert standaard de volgende IPS reliability tests uit:
High traffic load reliability
Tijdens deze test wordt het IPS gebombardeerd met een grote hoeveelheid data waarbij er ondertussen een aantal legale en illegale requests worden geïnjecteerd. Het doel van deze test is om te bepalen of het IPS nog in staat om op dat moment de illegale requests te blokkeren.
High connection load reliability
Tijdens deze test worden er een groot aantal verschillende connecties opgezet naar de achterliggende webserver waarna er over aantal willekeurige connecties illegale requests worden verstuurd. Het doel van deze test is om te bepalen of het IPS onder deze omstandigheden nog in staat is de illegale requests te blokkeren.
Resultaten IPS reliability
| Uitgevoerde Test | Resultaat |
| High traffic load reliability | PASS |
| High connection load reliability | PASS |
Conclusie
Security.nl heeft geen implementatie of deployment fouten kunnen ontdekken in het AccessGuard product van XSA en is dan ook van mening dat het hier een betrouwbaar en effectief product betreft.
Meer informatie over de AccesGuard is op deze pagina te vinden.
Als bovenstaande er niet in zou hebben gestaan was rest van het artikel ook geloofwaardiger geweest.
Het is uiteraard onzin dat een door te 'bridgen' (poor mans routing) je op eens niet meer zou hoeven TCP of IP te reassemblen.
Sterker nog als AccessGuard dit ook niet zou doen is conclusie gemakkelijk: Alle fragmented attacks zullen er langs kunnen.
Verder vraag ik me af wie het artikel heeft geschreven, het zou wel zo sportief zijn om boven een advertentie, advertentie te vermelden.
Het is uiteraard onzin dat een door te 'bridgen' (poor mans routing) je op eens niet meer zou hoeven TCP of IP te reassemblen.
Sterker nog als AccessGuard dit ook niet zou doen is conclusie gemakkelijk: Alle fragmented attacks zullen er langs kunnen.
De AccessGuard accepteert zelf de TCP verbindingen van de client, en zet zelf een TCP verbinding met de server op. De data die naar de server gaat is dus gegarandeerd gezien door de AccessGuard. Dit gebeurt uiteraard compleet transparant en er komen ook geen nieuwe mac adressen op het netwerk.
Een IDS die alleen maar luistert en aan de hand daarvan probeert vast te stellen welke data er bij de server uitkomt kan niets garanderen. Een retransmit van een TCP packet met andere data geeft al het probleem dat de IDS niet weet of de eerste of tweede data nu door de server is geaccepteerd.
Je hebt gelijk dat er nog steeds TCP en IP reassembly nodig is op de AccessGuard. Dit gebeurt echter door de FreeBSD stack zelf wat fouten in implementatie voorkomt.
Ik hoop dat dit het duidelijker maakt.
Groeten,
Frank van Vliet
<knip>
Verder vraag ik me af wie het artikel heeft geschreven, het zou wel zo sportief zijn om boven een advertentie, advertentie te vermelden.
En het is gewoon een 'review', en geen 'advertentie'
Bedankt voor je commentaar,
Joost Pol
Extra vraag: met welke tools hebben jullie de onderzoeken gedaan?
Ik heb in het verleden geconstateerd dat VPN verbindingen werden gestoord door tussenkomst van dit apparaat. Zijn deze problemen nu opgelost?
U heeft gelijk dat dit voorkwam bij een early-release van de AccessGuard. Alle problemen zijn toen uiteraard direct opgelost.
Frank van Vliet
Extra vraag: met welke tools hebben jullie de onderzoeken gedaan?
Met dank voor de belangstelling,
Joost Pol
Alle test tools zijn ontwikkeld door Pine Digital Security zelf.
Met dank voor de belangstelling,
Joost Pol
Dat is leuk Joost, maar algemene meldingen als "Tijdens deze test wordt het IPS gebombardeerd met een grote hoeveelheid data waarbij er ondertussen een aantal legale en illegale requests worden geïnjecteerd" zijn nogal weinig zeggend. Jullie definitie van grote hoeveelheid data hoeven niet die van de lezer zijn. Het zou prettig zijn als we enig inzicht in die tools zouden hebben..
Dat is leuk Joost <knip> Het zou prettig zijn als we enig inzicht in die tools zouden hebben..
Joost Pol
Hahaha, niet overdrijven 'Unregistered' ;)
Joost Pol
Hoezo overdrijven? 'Wij lezers' hebben geen idee welke tests door die tools uitgevoerd worden anders dan dat jullie er een paar mooie termen voor verzonnen hebben. Ik kan ook een klap op een toetsenbord geven en zeggen dat ik een "advanced AI black-box test" heb uitgevoerd. Maar ik gok dat de meeste mensen deze black-box test niet echt serieus nemen..
Hoezo overdrijven? 'Wij lezers' hebben geen idee welke tests door die tools uitgevoerd worden anders dan dat jullie er een paar mooie termen voor verzonnen hebben. Ik kan ook een klap op een toetsenbord geven en zeggen dat ik een "advanced AI black-box test" heb uitgevoerd. Maar ik gok dat de meeste mensen deze black-box test niet echt serieus nemen..
Hoe kom ik aan een gratis test tool ;)
Toch jammer dat je weer moet updaten en patchen, iets wat ik nou juist niet wil.
Ik kan me goed voorstellen dat u niet zelf uw IDS/IPS wilt updaten en patchen. AccessGuard update zich echter automatisch en direct. Zodra er een nieuwe fingerprint gemaakt is wordt deze op een centrale server gezet die direct alle AccessGuards update. Hetzelfde geldt natuurlijk voor software-updates, alle AccessGuards zijn dus altijd up-to-date.
Frank van Vliet
Hoe kom ik aan een gratis test tool ;)
Alleen al een melding welke soort 'evasions' allemaal getest zijn (klein voorbeeldje desnoods), met hoeveel bandwidth is getest, in welke packetsize enzovoort.
Zo'n tool hoeft niet open source (zijn er al genoeg waarmee je al deze tests kunt doen, moet je alleen veel tijd in steken om het goed uit te zoeken), maar WAT wordt er gemeten?
Er staat bijvoorbeeld:
"Tijdens deze tests werd gekeken of het IPS, op dat moment, een ruleset bevatte die er voor kon zorgen dat normale, legale, requests werden aangemerkt als een aanval. Het doel is om de kwaliteit van de ruleset te bepalen."
Wat is de definitie van legaal (ik denk aan: bestaande urls, of alles wat in de URI spec valt, of wel URI's maar zonder unicode?). Het zijn allemaal onvergelijkbare grootheden, aangezien we Joost noch Frank's (of security.nl's) definitie van de termen kennen.
U heeft gelijk dat dit voorkwam bij een early-release van de AccessGuard. Alle problemen zijn toen uiteraard direct opgelost.
Frank van Vliet
Frank werk jij daar?
Zo ja, dan is het goed om te weten (voor iedereen) dat Joost en Frank goede vrienden zijn.
Hiermee komt objectiviteit in een ander daglicht te staan.
Hoezo overdrijven? .....snip..... Maar ik gok dat de meeste mensen deze black-box test niet echt serieus nemen..
Amen.
Tenzij je doelgroep niet technische MKB is.
Die stellen geen vragen en gaan na overtuiging in zee.
Symantec heeft ook dezelfde marketing strategie, zoveel mogelijk positieve berichten over hun producten komen hiermee klanten overtuigen en vervolgens hen een abonnement aan te smeren.
Daarom vraag ik mij af:
in hoe verre je deze oplossing zonder abonnement kan afnemen
jezelf 'attack-signatures' kan toevoegen.
welke attack-signatures er in zitten
frequentie van updates
time between attack/exploit publication and signature
etc..etc..
Ik denk dat deze argumenten zwaarder wegen dan een loze kreet "we hebben er wat attacks tegen aan gegooid met eigen gemaakte tools en deze werden allen gedetecteerd"
Tenminste zolang je niet tot bovenstaande MKB groep behoord.
De AccessGuard accepteert zelf de TCP verbindingen van de client, en zet zelf een TCP verbinding met de server op. De data die naar de server gaat is dus gegarandeerd gezien door de AccessGuard. Dit gebeurt uiteraard compleet transparant en er komen ook geen nieuwe mac adressen op het netwerk.
Als dit zo is, dan is hij minder transparant dan in het artikel werd geschetst.
Immers er werd geschreven dat hij werkt als een bridge.
Een bridge kijkt nooit verder dan level 2.
Aangezien IP op level 3 werkt en tcp op level 4 en volgens boventaande posting hij TCP sessions bij de accesguard termineerd betekend dat dat hij alle attacks die gebaseerd zijn op level 2 en 3 (zoals een hop ervoor mtu verkleinen) doodleuk tot het gevolg heeft dat accesguard de attacks niet ziet.
Verder zullen een aantal (vooral crypto) toepassingen niet lekker werken als er op TCP nivo een sessie getermineerd word.
Wat ook handig is om te weten is de throughput.
Hoezo overdrijven? 'Wij lezers' hebben geen idee welke tests door die tools uitgevoerd worden anders dan dat jullie er een paar mooie termen voor verzonnen hebben <knip trolling>
Jij, en anderen met soortgelijk commentaar, hebben inderdaad een punt.
Bij de volgende (technische) review zal ik kijken of dit anders/beter kan.
Thanks voor de input,
Joost Pol
Zo ja, dan is het goed om te weten (voor iedereen) dat Joost en Frank goede vrienden zijn. Hiermee komt objectiviteit in een ander daglicht te staan.
Frank en ik kennen elkaar inderdaad.
Gelukkig heeft dit geen invloed op mijn natuurlijke aandrang om lekken te vinden in hard en/of software.
Het zou obviously niet opschieten als ik niets kon auditen van mensen die ik aardig vindt.
Happy Trolling,
J
Frank en ik kennen elkaar inderdaad.
--- snip ---
Het zou obviously niet opschieten als ik niets kon auditen van mensen die ik aardig vindt.
J
Zou je het in dat geval ook publiceren ?
Het spreekt voor zich dat je ook voor je vrienden sourcecode kan/wil auditten.
Maar stel in BSD component van het product zit een vulnerability.
Zo je dat publiceren ?
En indien het in AccesGuard component zou zitten?
Zou je het in dat geval ook publiceren ? Het spreekt voor zich dat je ook voor je vrienden sourcecode kan/wil auditten.Maar stel in BSD component van het product zit een vulnerability.
Zo je dat publiceren ? En indien het in AccesGuard component zou zitten?
Tot nu toe heb ik alle vulnerabilities die ik gevonden heb gepubliceerd.
En ik zie geen reden om dat in dit geval anders te doen.
Mvg,
Joost Pol
Ja, beide gevallen zou ik publiceren.
Tot nu toe heb ik alle vulnerabilities die ik gevonden heb gepubliceerd.
En ik zie geen reden om dat in dit geval anders te doen.
Mvg,
Joost Pol
Zeer nobel en eerlijk van je.
Maar hoe denken je vrienden er over, lijkt me niet relatie bevorderend ;-)
Zeer nobel en eerlijk van je. Maar hoe denken je vrienden er over, lijkt me niet relatie bevorderend ;-)
Het is vooral de manier met het minste gezeik :)
En qua vrienden kunnen we allemaal wel werk en prive gescheiden houden, anders schiet het uberhaupt niet op.
J
Verder wordt er in het artikel gesproken over FreeBSD als OS: dit zou impliceren dat het apparaat niets anders is dan een dedicated PC waarop een FreeBSD met IPfilter draait, in transparent bridging mode. Ik heb wel een swat OpenBSD machines gedeployd met zo'n configuratie (toe ipfilter nog onderdeel van openbsd was). Wel een goeie firewall, stateful, maar (uiteraard) kwetsbaar voor een bepaalde types aanvallen.
Tot slot zie ik de meerwaarde van dit ding niet ten opzicht van de combinatie firewall + IDS. En het wordt me uit het review ook niet duidelijk wat die meerwaarde dan wel zou moeten zijn. Voor de goede orde vind ik plug 'n play security GEEN security.
Tot slot: een goed opgebouwd IDS is zeer lastig aan te vallen, omdat je niet weet dat het IDS er is.
Het interessante vind ik dat je nu iets beweert wat in de test niet naar voren komt. Er is wel uit de naamgeving van het product af te leiden dat het om een vorm van preventie gaat, maar dit komt in de test niet terug.
Overigens heb ik ook mijn vragen bij de techniche kennis van de testers. Eerst wordt er beweerd dat het product als bridge functioneert (dus op OSI laag 2), vervolgens dat het product IP reassembly kan doen. (OSI laag 3). Wat is het nu?
Ook vraag ik me (nog steeds) af in hoeverre dit apparaat een meerwaarde biedt ten opzichte van de traditionele firewall. Kijkt dit apparaat ook in pakketten? Biedt het een bescherming tegen DDoS? Hoe zit het met gefragmenteerde pakketten met een gevaarlijke payload? Biedt dit apparaat een bescherming tegen geavanceerde scans?
Bekijk de website eens, daar wordt duidelijk gesproken over een intrusion prevention systeem dat aanvallen stopt nog voordat ze de firewall bereiken. Dit in tegenstelling tot een IDS. Als de IDS het gedetecteert heeft kan het al te laat zijn: De blaster worm is daar een overduidelijk voorbeeld van. IDS detecteert dat jouw machine geinfecteerd is. Leuk om te weten, maar voorkomen was beter geweest. Duidelijk is ook dat de koppeling met je firewall niet helpt: blaster is al gepasseerd.
Bridge:
Het een sluit het ander natuurlijk NIET uit, voor gewoon verkeer geldt het gedrag van een bridge. Als er sprake is van een aanval wordt het verkeer niet doorgestuurd. Hierdoor bereik je maximale stransparantie.Dat kan dus alleen maar als je in de pakketten kijkt nadat je defragmentatie/reassemnly hebt uitgevoerd.
DDos:
Het verkeer dat via een DDos op een server wordt afgestuurd hoeft niet per se een aanval te bevatten, kan dus ook niet geblocked worden. Vraagje: welke apparaat dat achter de router (en voor de firewall) is geplaatst kan dat wel? Inderdaad, zo'n apparaat bestaat niet en zal ook nooit bestaan. Zo zit Internet nu eenmaal in elkaar.
Scans:
Een port-scan (in welke vorm dan ook) is geen aanval. Het verschaft interessante informatie, maar is daarmee nog steeds geen aanval en zal waarschijnlijk dus niet geblocked worden. Maar, dat is ook geen probleem: daar heb je je firewall voor.
Het zal best dat de marketingmensen van AccessGuard een mooi naampje verzonnen hebben, maat het wordt niet duidelijk of en hoe intrusion prevention nu eigenlijk werkt.
Om aan intrusion prevention te kunnen doen zul je in eerste instantie aan intrusion detection moeten doen. Vervolgens zul je real-time verkeer moeten gaan blokkeren. Helaas is real-time intrusion detection onmogelijk.
Helaas is real-time intrusion detection onmogelijk.
Hmm, kijk eens wat rond op Internet, en kijk ook eens op de sites van andere leveranciers van security produkten. Onwaarschijnlijk dat organisaties als Symantec, Netscreen etc. ronduit liegen. Als zij het kunnen kan een ander het ook.
Hmm, kijk eens wat rond op Internet, en kijk ook eens op de sites van andere leveranciers van security produkten. Onwaarschijnlijk dat organisaties als Symantec, Netscreen etc. ronduit liegen. Als zij het kunnen kan een ander het ook.
Zij zeggen dat ze het kunnen en talloze volledig clueless managers trappen er in.
Ik ga hier niet roepen wie ik ben, in welke organisatie ik werkzaam ben en dergelijke, maar laten we het er maar op houden dat network security mijn dagelijks werk is, en dat de organisatie waar ik voor werk een vrij high profile target is.
Realtime intrusion detection bestaat domweg niet, en iedereen met iets meer kennis van de werking van een IDS dan pakweg het niveau folderlezer weet dit en begrijpt waarom.
Dat jij gelooft in de verkooppraat van een commerciële organisatie vind ik naïef en dom.
Realtime intrusion detection bestaat domweg niet, en iedereen met iets meer kennis van de werking van een IDS dan pakweg het niveau folderlezer weet dit en begrijpt waarom.
Kan iemand mij uitleggen waarom dit helemaal niet zou kunnen bestaan? Ik ben bekend met de werking van een IDS maar snap nietwaarom het niet realtime zou kunnen?
Danku.
Kan iemand mij uitleggen waarom dit helemaal niet zou kunnen bestaan? Ik ben bekend met de werking van een IDS maar snap nietwaarom het niet realtime zou kunnen?
Danku.
REALTIME zou alleen kunnen indien je de condities kunt bepalen waaronder het verkeer -packets en frames- worden aangeboden.
Indien IP reassembly voor dat het verkeer de IDS bereikt al is gerealiseerd is er geen enkele reden meer om te stellen dat realtime niet kan. (mits je minder als 100Mb/s realtime wilt IDS'sen)
Intrusion Prevention:
Bekijk de website eens, daar wordt duidelijk gesproken over een intrusion prevention systeem dat aanvallen stopt nog voordat ze de firewall bereiken. Dit in tegenstelling tot een IDS. Als de IDS het gedetecteert heeft kan het al te laat zijn: De blaster worm is daar een overduidelijk voorbeeld van. IDS detecteert dat jouw machine geinfecteerd is. Leuk om te weten, maar voorkomen was beter geweest. Duidelijk is ook dat de koppeling met je firewall niet helpt: blaster is al gepasseerd.
[/QUOTE]
Ik begrijp dat de potentionele klanten voor dit product zowieso niet van de werking van beveiliging mechanismen willen weten.
Maar elk ander zal op zijn perimeter firewall graag rotzooi zien die daar al wordt tegen gehouden -immers anders is die overbodig-.
Verder zal hij achter die perimeter firewall graag een IDS hebben staan om te zien welke attacks er nog steeds doorheen komen. (aldaniet een active IDS)
Bovenstaande eventueel aangevuld met reverse en gewone proxies.
En verder zal hij de logs van zijn choke-router/firewall/dmz firewalls in de gaten houden voor afwijkend gedrag.
De AccessGuard zal in deze bovenstaande bestpractise situatie -veel voorkomend- simpel weg niet werken, gezien het feit dat hij nooit het internet kan bereiken. (genat wordt er niet.)
Verder vraag ik me af dat afgezien van bovenstaande hoe hij in een redundante omgeving gebruikt kan worden. (failover)
En uiteraard throughput.
Op site is namelijk nergens te vinden waar dit product voor bedoelt is.
Bridge:
Het een sluit het ander natuurlijk NIET uit, voor gewoon verkeer geldt het gedrag van een bridge. Als er sprake is van een aanval wordt het verkeer niet doorgestuurd. Hierdoor bereik je maximale stransparantie.Dat kan dus alleen maar als je in de pakketten kijkt nadat je defragmentatie/reassemnly hebt uitgevoerd.
Hij kan zich niet als een bridge gedragen als hij op level 3 en ingevallen van TCP reassembly 4 werkt.
Indien hij ook nog eens op application (level 5-6) reassembly doet -unicode/input validation etc...- is het niet meer/minder dan een sniffende IDS met koppeling aan ipfilter. (iets wat je met SNORT al kan doen)
Overigens kan je een content -layer 7 switch- router hiervoor ook misbruiken. Aangezien dat een ASICs hebben zal performance vele malen hoger zijn. En mogelijkheden voor loadbalancing , server farm etc..etc.. standaard een onderdeel van uitmaken.
Scans:
Een port-scan (in welke vorm dan ook) is geen aanval. Het verschaft interessante informatie, maar is daarmee nog steeds geen aanval en zal waarschijnlijk dus niet geblocked worden. Maar, dat is ook geen probleem: daar heb je je firewall voor. [/B]
Een portscan is wel degelijk een aanval.
Er is geen enkele reden waarom een wildvreemde aan jouw porten wilt laten snuffelen.
Portscans wil je graag zien -en niet blind blocken- omdat het een mogelijke echte poging kan inluiden.
Als er binnen jouw IP-range een bepaalde port + eventueel banners gechecked worden kan dat duiden dat iemand met een 0-day op zoek is naar plek waar tegen hij het kan gebruiken. Iets waar ook jouw acces-guard niets tegen kan ondernemen.
Hmm, kijk eens wat rond op Internet, en kijk ook eens op de sites van andere leveranciers van security produkten. Onwaarschijnlijk dat organisaties als Symantec, Netscreen etc. ronduit liegen. Als zij het kunnen kan een ander het ook.
Hier komt dus het woord 'perceptie' bij kijken.
Als iets lijkt dat het zo is, dan zal het wel zo zijn.
Als iets geen keiharde leugen is, dan is het waar.
Bovenstaande is -denk ik- de voornaamste rol van Marketing.
Hoe overtuig ik mijn klant het best zonder dat ik daarbij aangeklaagd kan worden.
Bovenstaande organisaties liegen/manipuleren de waarheid wel degelijk.
Dat kan ook niet anders omdat hun business model op FUD gebaseerd is.
Realtime kan alleen indien je de datastroom kan bepalen.
Dus zolang je niet -zoals bij een Cisco Powered omgeving- alle andere componenten onder controle hebt kan jij nooit de data stroom die aan je IDS wordt aangeboden bepalen. (voorwaarden waaraan die stroom moet voldoen voordat het aangeboden wordt/preprocessen van de data).
Realtime wordt ook weleens als cut-through, wire-speed etc.. genoemd, wat in de praktijk neerkomt dat er nauwelijks latency onstaat door het proces.
Waarmee je moet vast stellen dat nauwelijks een vaag begrip is. (voor de 1 is 20ms al onacceptabel terwijl de ander 200ms als not done beschouwd).
Dus als een leverancier je niet kan vertellen in welke situaties hij realtime kan/zal werken -ook aantal rules/processen is van invloed op latency- liegt hij je voor.
(op infosecurity heb je altijd vaak van dit soort mensen rondhuppelen, door gericht te vragen zul je door hun marketing verhaal heen prikken, eenieder die zich lang of gedurende dit gehele proces staande weet te houden weet of veel van techniek/product of verdedigd een goed product. Dit laatste komt vrijwel nooit voor ;-) )
Een portscan is wel degelijk een aanval.
Er is geen enkele reden waarom een wildvreemde aan jouw porten wilt laten snuffelen.
Portscans wil je graag zien -en niet blind blocken- omdat het een mogelijke echte poging kan inluiden.
Als er binnen jouw IP-range een bepaalde port + eventueel banners gechecked worden kan dat duiden dat iemand met een 0-day op zoek is naar plek waar tegen hij het kan gebruiken. Iets waar ook jouw acces-guard niets tegen kan ondernemen. [/B][/QUOTE]
Je zegt het zelf al: een portscan kan de voorbereiding op een aanval zijn. Het is dus geen aanval. Een beetje firewall is prima in staat e.e.a. te detecteren en de juist alarmen te genereren
Hier komt dus het woord 'perceptie' bij kijken.
Lees de posting van Frank eens (15-10-2003) en leg dan eens uit waarom het niet zou kunnen werken.
Lees de posting van Frank eens (15-10-2003) en leg dan eens uit waarom het niet zou kunnen werken.
In die posting zegt Frank dat accesguard sessies termineerd en op nieuw opbouwd, iets wat een bridge -level 2- nooit gedaan kan worden.
Accesguard is dus -waarschijnlijk- slechts een arping device voor achterliggend device, indien hij platgaat -stuk gaat- verdwijnt deze mac adres van het netwerk hier door zal Accesguard geen singlepoint of failure vormen.
Overigens zal dit alleen werken indien achterliggende en voorliggende spullen via een crosscable of een hub de accesguard in serie hebben staan.
Anders heb je nog steeds een probleem.
<knip> Ik ga hier niet roepen wie ik ben, in welke organisatie ik werkzaam ben en dergelijke, maar laten we het er maar op houden dat network security mijn dagelijks werk is, en dat de organisatie waar ik voor werk een vrij high profile target is.
</knip>
Wat voor IDS/IPS (combinatie) gebruikt men bij jullie?
En waarom?
Joost Pol
Just wondering.
Wat voor IDS/IPS (combinatie) gebruikt men bij jullie?
En waarom?
Joost Pol
Sorry, can't tell you. Classified info :)
Filtering router, firewall en op ieder netwerksegment een IDS sensor. Alle internet-facing hosts hardenen, zo veel mogelijk verkeer proxyen en eventueel reverse proxies aanbrengen. Dit geheel blijven auditen. Als je zin hebt nog een honeypot of wat neerzetten, maar doe dat alsjeblieft alleen als je voldoende kennis en tijd hebt.
Hiermee zit je redelijk safe.
of worden alle poorten als gelijke behandeld?
Of kan de gebruiker dit zelf alsnog instellen?
bedankt voor uw tijd.
wat doet de accessguard met streams die niet op de standaard /etc/services poorten draaien? bv een http stream die op port 81 draait ipv 80 (ik geef maar een voorbeeld)
of worden alle poorten als gelijke behandeld?
Of kan de gebruiker dit zelf alsnog instellen?
bedankt voor uw tijd.
Op application layer kijkt deze IDS niet. (tenminste dat hoop ik anders is 'functioneren als een bridge' helemaal misplaatst)
Je moet een IDS zien als een virusscanner, die in voorbij komende pakkets patronen -signatures- ziet van known vulnerabilities.
Dit gesteld vraag ik mij of hij zelflerend is, afwijkende patronen kan detecteren en tegengaan etc..etc..
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
