Ik ben het met beide eens. Ja, het risico is eigenlijk te klein om iets te kunnen doen. Maar aan de andere kant kan het wel een onderdeel zijn van een aanval. Hoe kleiner je die kans maakt, hoe kleiner de succesgraad van een aanval. Eerlijk gezegd een beetje common sense als je in dit vakgebied werkzaam bent...

Je hebt je in de typische techneuten hoek laten manoevreren, nu moet je een 'uphill battle' vechten met mensen die (vaak - auditor ) weinig technisch benul hebben maar wel veel zeggenschap. En trouwens, hier ook mogelijk een punt hebben.

(Wat was beter geweest : de pentest duidelijk scopen op wat er penetreerbaar is vanaf het guest netwerk, en de tester dus geen 'abnormale access' geven. Als de tester dat zelf wist te bereiken heb je natuurlijk ook een probleem gevonden.
_of_ accepteren dat je een test laat doen wat er bereikt kan worden _indien_ een server gecompromitteerd is, en dat mitigeren of aantonen wat je in place hebt om te zorgen dat het compromitteren van de server (of diens plek op het lan) niet mogelijk is.
Nu wil je blijkbaar achteraf de scope van de audit beperken tot wat er mogelijk was vanaf het guest lan. Dat gaat moeilijk worden. )

Inderdaad is ARP spoofing vooral een zorg als je een nogal ongecontroleerd access netwerk hebt waar allerlei untrusted devices op aangesloten kunnen worden.
Dat zijn dus bibliotheeken, studentencampus, en dergelijke (semi) publieke netwerken, of bv hosting/colocatie , of als je ethernet-stijl internet access levert .

In een goed beheerd bedrijfsnetwerk zijn untrusted apparaten in een server segment feitelijk een gevalletje "mag niet voorkomen" .
Het contra-argument is natuurlijk dat als er één server gehacked is, die server als sniffer/spoofer ingezet kan worden, en
ook daar nog een barriere voor moet staan.

*Maar* - een trusted apparaat kan dus malicious worden . Omdat het gehacked is.

Nu naar je argumenten :

NAC - het helpt niet als iemand een server in het segment weet te hacken.

Overigens : gebruik je trouwens echt NAC op 10G switches waar (ook/alleen) server segmenten aan zitten ? M.i. is NAC vooral technologie voor de access laag (werkplekken, printers , guests in de juiste segmenten plaatsen) en is het wat ongebruikelijker om het in het datacenter op core/server access devices ook te implementeren.

ARP - het protocol is wat het is, maar er zijn netwerk switch features die kunnen helpen met arp spoofing.

tap/wireshark - nee, dat is niet met hetzelfde gemak. Een server die je op afstand overneemt kan arp spoofen, maar ik kan op afstand geen fibertap plaatsen .
Je hebt wel gelijk dat *als* je een aanvaller met fysieke toegang tot de server/netwerk infra positioneert, die aanvaller veel mogelijkheden heeft waarvan ARP spoofing er maar eentje is.
Fysieke DoS is heel simpel, en ik zou ook zenuwachtig worden over management access via consoles.
Een aanvaller die alleen bij een aangesloten kabel kan maar niet bij de switch is geen normaal datacenter-scenario - maar wel een access netwerk scenario .

Je zou het merken - dat hoeft niet. Dat je een 10G switch hebt wil niet zeggen dat je ook 10G verkeer doet. Vaak is dat maar 10..20 % - Feitelijk zodra 1G boven de 70% komt wil je graag naar 10G (of een paar 1G bundels).
Het zou best kunnen dat een enkele server in het segment prima al het verkeer naar de gateway kan doorlussen zonder dat dat qua performance enorm opvalt.
Zeker als de server ook al met 10G aansloten zijn, en het niet al te druk hebben - die kan makkelijk een paar G verkeer doorlussen.
Als de beheerders niet strak monitoren op afwijkingen in verkeersstatistieken, hoeven ze dat niet te zien. En als de gebruikers weinig merken, of hooguit "voelt soms een beetje traag" , de IT afdeling die op enkele gebruikersklachten echt alles uit de kast trekt om dat te onderzoeken is zeldzaam.

Let op dat ik dus het scenario 'overgenomen server in het segment' benoem, waar jij je beperkt (waarom ?) tot een ingeplugd laptopje - (dat overigens ook wel een gig kan switchen )

OSPF - Dat gaat echt niet op. Performance is (ongeveer) nooit deel van routing protocol beslissingen. Verder gaat ARP spoofing over het weglussen van verkeer binnen een enkel ethernet segment, en daar speelt OSPF ook geen rol.
OSPF regelt de bereikbaarheid van dat hele segment met andere OSPF routers in het netwerk. Dat binnen dat segment host .43 verkeer van andere hosts naar de gateway kaapt staat er totaal buiten.
Kortom - geen argument.

Een beetje enterprise netwerk apparatuur biedt je mogelijkheden om ARP (en IP/mac) spoofing onmogelijk te maken.
Je betaalt ervoor met geld, en met een stukje beheer/configuratie overhead. Performance impact is niet echt een probleem, de packet filtering zit in hardware .

De volgende features (Cisco termen, want die ken ik nu eenmaal vrij goed, andere enterprise/service provider klasse vendors moeten de mogelijkheden ook hebben ).

port security - beperk het aantal mac adressen wat achter een switchpoort gezien mag worden. Meestal beperkt tot de eerste, of eerste <x> die geleerd worden na een port down/up . Statisch configureren kan ook maar wil je qua overhead echt niet .

private vlan - poorten zijn promiscuous, community of isolated. Een isolated poort stuurt alleen L2 verkeer naar een promiscuous port. Een community poort naar andere community poorten en een promiscuous port, en een promiscuous port stuurt verkeer naar alle poorten in het vlan .

Hiermee kun je bereiken dat ook verkeer hetzelfde vlan (= ip broadcast domein) alleen via de router poort naar andere hosts gaat .(een host zit op een isolated port, de router port is promiscuous).
Op de router port kun je packet filters (L2 of L3) implementeren waarmee je host-onderling verkeer limiteert .

dynamic arp inspection - deze feature zul je meestal icmp dhcp snooping willen gebruiken.
Maar het kan op basis van statische filters (die je zult moeten bijhouden ).

Met de combinatie van dhcp snooping, arp inspection en port security kun je een strakke koppeling afdwingen tussen mac,ip en arp gedrag van een host . Ideaal voor risicovolle access segmenten.
Op een server segment doe je alleen meestal geen dhcp - maar met private vlans, port security en L2 /L3 packet filters kun je ook heel veel problemen tegen gaan.


Overigens : als het ook/vooral ging om een pentest vanaf het access netwerk (dus een foute werkplek gebruiker, evil maid e.d.), dan kun je wel de combi dhcp snooping/dai/port security gebruiken natuurlijk.
Staar je bij een access segment niet blind op performance issues - normale KA werkplekken doen gewoon weinig verkeer - en kun je dus makkelijk doorlussen over een arp-spoofende laptop zonder dat het qua performance onbruikbaar wordt.

Alles bij elkaar :

Een deel van je tegenwerpingen zijn, in het algemeen, niet heel valide. Misschien is er meer in jouw situatie waarom maatregelen tegen ARP spoofing op bepaalde segmenten niet nodig zijn , maar dat is op je post niet te beoordelen.
Met name het uitsluiten van een gehackte host op een server segment moet echt wel goed onderbouwd worden, waarom dat terecht is.

Je mag overigens aardig trots zijn op je infra en beheer als arp spoofing het grootste resterende risico is wat gevonden is :-)
Meestal zijn er dringender problemen op te lossen.
Idem als je (netwerk)monitoring/alarmering/followup echt zo goed is dat je een verschuiving van het verkeerspatroon zou zien en onderzoeken , zonder dat je de aanname doet dat het een totale outage op dat segment geeft.

Men kan software als "arpalert" installeren om eventueel mee te kunnen monitoren samen met een inline Intrusie Detectie Systeem om een golf aan aanvallen snel te kunnen onderkennen en een eventuele aanvaller te kunnen isoleren.

Vermoedelijk begrijp jij dit wel, maar mogelijk andere lezers niet: naast bij routers in een broadcast domain ben je hier alleen kwetsbaar voor indien een of meer poorten van layer-3 (IP) switches zijn gekoppeld aan het betreffende broadcast domain.

Bij het gebruik van layer-2 (ethernet) switches kan een aanvaller natuurlijk wel direct het MAC-adres van een computer (server of client) spoofen.

Als de aanvaller op andere wijze een willekeurige host in je server-VLAN weet te compromitteren, kan hij middels ARP-spoofing wellicht andere servers hacken, waaronder domain controllers. Ook komen ontwerp/configuratiefouten voor waardoor aanvallers soms toch toegang kunnen krijgen tot andere VLAN's dan de bedoeling is. Is al je backbone bekabeling en zijn al je trunk poorten uitsluitend toegankelijk in afgesloten ruimtes waar uitsluitend geautoriseerden in kunnen?

Ik begrijp wat je bedoelt, maar strikt genomen verkleint het niet de impact maar de kans en daarmee het risico.
Ja het ARP-protocol is insecure, maar switch-fabrikanten hebben hier oplossingen voor bedacht. De vraag is of je bereid bent om die te implementeren. En zo niet, of de auditor dat, voor jullie omgeving, acceptabel vindt.

Over een interne DDoS heb ik me nog nooit zorgen gemaakt; daarmee verraadt een aanvaller zijn aanwezigheid (tenzij niemand zoiets vermoedt en aan storingen/defecten denkt - maar dan heb je een groter probleem).

Hoe groot de inpact kan zijn van een MitM aanval hangt af van het verkeer dat over de verbinding gaat. Als peers fatsoenlijk authenticeren en al het uitgewisselde verkeer goed wordt versleuteld, heeft de aanvaller niets aan de uitgewisselde informatie. De praktijk is echter dat men meestal van een "vertrouwd netwerk" spreekt en zelfs wachtwoorden plaintext worden uitgewisseld. Als machines aan jouw LAN's allemaal WPAD requests broadcasten kun je de deur getiteld "ARP-spoofing" wel op slot doen, maar dan staat de WPAD deur nog wagenwijd open.

Ik mag toch hopen dat een kwaadwillende niet zomaar kan tappen op een kabel waar meer dan 1 client over communiceert...
En wat bedoel je met "run je wireshark"? Switches zijn geen security devices, maar als zij unicast verkeer "lekken" dat niet voor de PC bedoeld is waar je Wireshark op draait, dan is er iets niet in orde.

Een aanvaller kan heel selectief ARP-spoofen waarmee perfornance onmerkbaar kan afnemen. Als hij toegang heeft tot een device X in het server-VLAN kan hij voortdurend gratuitous ARP antwoorden naar de layer-3 switch (of router) sturen dat Domain Controller Y het MAC-adres heeft van X. Elk device in een ander broadcast domain dat probeert te connecten met Y, zal dan verbinding krijgen met X.

Zie boven.

Of je risico verwaarloosbaar is, hangt van 2 factoren af: impact (worst case, wat kost het in de minst gunstige situatie) en kans. Kans wordt enigszins beïnvloed door impact: als een aanvaller veel geld kan verdienen met bijv. gegevens die jullie opslaan, zal hij beter zijn best doen en meer geduld hebben, waardoor de kans toeneemt. Aangezien de auditor wel weet wat jullie "te verbergen" hebben en wij niet, hebben wij geen idee.

Kun je geen port-security aanzetten in je server-VLAN, of zijn er zaken die dat onmogelijk maken?

Om hier een gedegen antwoord op te geven is het noodzakelijk om te weten om wat voor bedrijf het gaat.
Gaat het bijvoorbeeld gaan om een autogarage of om een hostingbedrijf?

Bij een autogarage zou ik persoonlijk het risico verwaarlozen. Bij een hosting bedrijf niet.

Just my 2 cents.

Zeg dat je (als je cisco hebt) dat je DAI gaat installeren, en klaar is kees.

Is het heel lastig om ARP-spooronderhoud detectie in je netwerk te krijgen? Anders gewoon doen.
Denk aan je defence in depth.

Je geeft aan dat je niet verantwoordelijk bent omdat het een protocol fout is.
Je gebruikt het protocol toch? Dat maakt je verantwoordelijk.
Kies een ander protocol (succes) of mitigeer de flaws.

Een aanvaller zal je anders echt dankbaar zijn, want die denkt niet in verantwoordelijkheden maar in kwestbaarheden.

Misschien eens een red-team ipv pentest team inhuren om gewoon te zien hoe de aanvaller denkt?

Ook al zou je dat weten, dan kun je nog geen bruikbaar antwoord geven.
*Blijkbaar* vond het bedrijf het al belangrijk genoeg om het te laten testen. En hebben ze een auditor die de resultaten van de test najaagt om op te lossen. (de titel impliceert de dure versie van pentesten)

En de TS zit duidelijk niet in de positie om te *beslissen* om een risico te verwaarlozen. Hij kan alleen redenen aandragen waarom naar zijn mening het risico beperkt is .

Neem mij niet kwalijk, maar ik verlies AL HET RESPECT na zo'n argument.
Ik neem het u niet kwalijk, u zal wel geen verstand hebben.
Ik zou nooit van mijn leven een digitaal product gebruiken van een maker met zo'n slagzin. Sterker nog, ik zou dit bedrijf actief boycotten, als deze uitspraak word gehouden.

Hiermee zeg je namelijk dat de gebruikers alle gevaar mogen lopen, zo lang het niet jouw schuld is.
"Niemand moet anti virus software maken, niemand heeft het nodig, het is toch de fout van een ander"
"Ik gebruik een SDK dat een virus in mijn programma stopt voordat ik het lever aan klanten. Ik ben hiervan bewust, maar dit is niet mijn schuld. Dus ik ga ermee door"

Hoe langer ik deze reactie blijf typen, hoe kwaaier ik word op deze instelling.

M.v.g.
Micheal

Ik ben ook auditor :-)

Neem ook mee de kosten om het risico te mitigeren en het risico.

Het risico is niet zo heel groot nee, maar de kosten zijn ook zo'n beetje NUL.

Gewoon de settings van de switch aanpassen. Cisco: DAI. Kost niks, zit er al in en het helpt je netwerk weer een beetje veiliger te maken.

Dus: geen redenen verzinnen om er niets aan te doen, maar gewoon ff die switch settings verbeteren.

Het feit dat je op een niet-server vlan zit zegt niet dat er niks interessants te spoofen valt. Zo kun je alle hosts van dat vlan middels een spoof doen geloven dat jij de internet proxy of firewall bent. Alle uitgaande verkeer verloopt dan via het systeem vd aanvaller. Ik heb het vaak genoeg gedaan (als demo). Noem je dat geen risico?
Je argument van een tap (wireshark) is ongeldig omdat je alleen kunt tappen wat je op je eigen netwerk segment ziet. Als iedereen op een switch of router zit, zie je enkel je eigen verkeer. Arp spoofing of arp cache poisoning maakt juist mogelijk dat de aanvaller het verkeer van meerdere systemen kan zien.
Een mogelijkheid tot arp spoof maakt dus juist het gebruik v Wireshark mogelijk.
Zoals anderen al opmerken is het probleem eenvoudig te verhelpen.
Verhelp het even en je netwerk is weer een beetje veiliger.

Dat valt nog best wel tegen. Ik ben daar eens mee bezig geweest en het is alleen maar simpel als al je systemen
hun adres via DHCP krijgen, want de database die de ARP spoofing beveiling gebruikt wordt aangeleverd door de
DHCP spoofing. Alle vaste IP adressen moeten vast met hun MAC geconfigureerd worden en daar moet ook
onderhoud op gedaan worden. Bepaald geen kosten NUL dus.

De kosten zijn nooit helemaal nul.
DAI vereist of het gebruik van dhcp snooping (en dus DHCP), of het bijhouden van een access list van mac/ip combinaties.

Als je , zoals vaak op een server segment geen DHCP gebruikt moet je die access-list gaan bijhouden.

Je Move/Add/Change proces wordt dus complexer, en het zoeken naar de storing is opeens ook een stukje lastiger geworden wanneer de arp-acl een foutje bevat .

Een keuze waarbij je opeens op een andere plek statische configuraties in sync moet gaan houden met aanwezige servers kun je niet kwalificeren als 'kosten nul' .

DAI+DHCP snooping is een prima combinatie voor een access segment, en mag je haast wel als kosten nul beschouwen omdat het na configuratie onderhouds vrij is.

DAI zonder DHCP snooping is dat niet.

In welk VLAN zitten jullie medewerkers? Je laat een pentester immers niet alleen testen om een aanvaller te weren die je gasten-wifi weet te hacken. Ook het overnemen van een medewerker/directie computer door middel van Social Engineering/Malware is een risico.

Het IPMIv2 protocol deelt wachtwoordhashes uit aan iedereen die het vraagt, dan is het nog steeds een security-issue die opgelost dient te worden.

Daarnaast is een pentest een momentopname door een extern persoon/bureau. Wanneer jullie als bedrijf zijnde het risico hebben afgewogen en besloten hebben dat de impact te klein is om op te lossen is de keus aan jullie.
Je afsluiting is dan echter weer minder want inderdaad de theoretische zwakheid in encryptiemethoden door quantumcomputers is nú al een aandachtspunt om op de agenda te plaatsen. Wanneer je dit pas gaat doen wanneer de theoretische zwakheid bekend misbruikt wordt ben je te laat.

Dit risicovolle denken wordt ook tegenwoordig nog eens aangemoedigd, want veel oplossingen worden wel 'even" gekopieerd van het Internet. Je kopieert dan de nog niet uitgeteste onveiligheid gelijk mee. Je zal dus zelf de aangegeven zaken moeten nalopen en oplossen. Inderdaad moeilijker dan het misbruik maken, dat gebeurt meestal via een enkele klik en kan nu tevens ook al via een app van een geroote android. Ziet u op windows na het ingeven van het "arp-a" commando een veranderd Mac adres staan, dan is er sprake van ARP poisoning. Via het niet toestaan via een filter van inter-station verkeer komen zulke gewraakte pakketjes niet meer door. Vergeet nooit dat de malcreant aan een enkel werkend wurmgaatje genoeg heeft, terwijl de beveiliger rekening moet houden met een heel draaiboek aan kwetsbaarheden om na te lopen. Daarom staat de kwaadwillende altijd al enigszins op voorsprong tegen over degenen die moeten beveiligen. Maar discussies als deze helpen natuurlijk terdege. Een gewaarschuwd mens telt immers voor twee!

NAC is een manier om te beveiliging tegen misconfiguratie, en simpel misbruik.
NAC is zeker geen manier om bescherming te bieden tegen hackers.

Als je daarnaast ook geen encrypted netwerk gebruik (IPSEC) kunnen hackers (welke dus fysiek bij een netwerkpoort kunnen) direct (<30sec) toegang krijgen tot je infrastructuur.

Een hacker heeft hiermee dezelfde toegang als een geautoriseerd apparaat. Als je dus zorgt dat alle verbindingen ge-encrypt zijn, en verkeer vanaf het client access vlan naar het server vlan via een application firewall gaat, dan zijn de bevindingen van de auditor niet meer van toepassing.

De auditor heeft dus daarwerkelijk wel een punt.

Grt,
DAP

OP hier. Bedankt voor alle tips.
Het heeft mij geholpen om alles in perspectief te plaatsen.


Dit is dus totaal niet het geval. We hebben letterlijk nog XP machines en server 2003 machines in het netwerk met Adobe Flash versie 0.1 beta (en dus 1001 vulnerbailities) waar niks over is gezegd, en ik moet nu de aandacht richten op een veel lager risico. Vandaar ook mijn frustratie. Wij maken goede stappen en nu wordt (nota-bene door een security audit) de aandacht verlegd naar minimale risico's.


Hehe. Je hebt volledig gelijk. Nogmaals weer mijn frustratie, die behoorde absoluut NIET tot de scope van de audit.
Het was een controle audit over eerdere bevindingen, en nu heb ik een nieuwe bevinding in een gebied wat buiten de scope ligt maar wat de auditor weigert om los te laten...

Yes, laten we gewoon functies op switches aanzetten zonder dit gedegen voor te bereiden. Dit klinkt als een goed plan.


Ik bedoel ermee te zegen dat er geen envoudige fix is. Cisco en HP bieden enige functionaliteit, maar lossen het root probleem ('arp protocol onveilig') niet op. Maarehh.. zet jij dan maar lekker het ARP-protocol uit.
Ik zou je uitnodigen om ff te posten hoe dat is verlopen, maar dat gaat je niet meer lukken zonder ARP...

Als je het simpel wilt houden en het gaat om een beheersbaar aantal (server) systemen, dan schakel je port security in op de switch, i.e. mac adres XXX mag uitsluitend 'leven' op port Gig1/0/6 . Dit heb je snel geconfigureerd.
Ook uit een van de eerdere reacties staat belangrijke info over dat deze machines doorgaans in een ander vlan hangen, ofwel een doorsnee kantoor walloutlet heeft geen port actief in dat zelfde vlan als die server (en daar bovenop mogelijk nog een L3 device ertussen).

Als er dit uit een audit komt dan zoeken ze spijkers op laag water. In feite kan ik zo 98% van de bedrijven binnenlopen en zeggen dat ze hiermee een risico lopen. Lekker snel scoren.

Meteen dit soort 'pentesters' de kop indrukken. Oh op het server vlan? Prima, laat maar zien hoe jij daar komt als 'aanvaller'. Oh, zo werkt het niet? Hoe valide is dan die bevinding? Als je toch al een server moet hacken voordat je dit kan doen (fysiek kom je er immers waarschijnlijk niet bij), ben je dan al niet zover dat je andere aanvallen met andere tools kunt bedenken? En ben je daar dan wel tegen beschermd, en zou dat juist niet uit zo'n rapport moeten komen?

Meteen zo'n discussie de kop indrukken. Het is alsof je zegt "ja, als ik in de beveiligde zone van je gebouw ben, dan zou ik om de hoek van een kantoor een gesprek kunnen afluisteren". Ja, dat is leuk gast maar 1) ben je niet in die beveiligde zone noch heb je aangetoond dat je daarbij kunt, en 2) ook al zou je dat gesprek afluisteren weet je dan waar het überhaupt over gaat (dusdanig dat je het zou kunnen manipuleren in jouw voordeel? Dat gaat in de praktijk toch echt niet zo makkelijk kan ik je vertellen...

Nee echt, als arp spoofing als een 'hoog' risico uit een pentest komt, dan hebben ze of verder niks kunnen vinden, maar zoals ik jou hoor met oude systemen en software kun je stellen dat het gewoon een baggerslechte pentest was. Ram dat erin als argument, en je zaagt gewoon aan de poten van de credibility van die 'onderzoeker'. Betwist de factuur. Echt...

Wat ook vreemd overkomt, is dat er geen mitigatie-voorstel ligt. Bij elke onveiligheid hoort m.i. ook een voorstel om dit manco zo goed mogelijk op te kunnen heffen. Ook moet dit voor ARP-spoofing kunnen en dient de security expert in kwestie een oplossing en oplossingstraject aan te leveren, alsmede de consequenties van e.e.a.
Bij iets geheel anders kan dat ook. SRI hashes niet gegenereerd, geeft aan hoe het genereren van SRI hashes met een generator kan gebeuren. Iets "enabled" geset wat "disabled" moet staan, eenvoudig aan te geven hoor. Excessieve info proliferatie kan in de settings gebeuren als de server setting die mogelijkheid tenminste verschaft. Root certificaatjes, verkeerde chain volgorde implementeringen idem dito. DROWn exploits die doorwerken van laag naar hoger op en ga zo maar door en ga zo maar verder.
Iemand die even snel wil scoren door wat te roeptoeteren in een rapport en niet exact kan aangeven hoe het dan anders moet, kan niet en moet niet eens serieus genomen worden. De lui die er geen verstand van hebben hoger in de boom kunnen degenen die het op moeten lossen, dus de IT-man op de werkvloer, het leven nog wel aardig zuur maken vanwege het interessant doen van iemand met aangenomen gezag via een flut-assessment. Dit hoort in de klasse 'hitman pro draaien" a raison van 60 euri per bezoek of iets dergelijks thuis. Een duur certificaat dekt dan als vlag meestal de lading. Goudgerande snake-oil.......

Anoniem 00:58 Als je geen idee hebt van de rol van een auditor dan kun je beter niets roeptoeteren. Een auditor is (intern of extern) volledig onafhankelijk onderzoek met aanbevelingen wat te verbeteren. Het hoe is de zaak van de architect en zeker niet van de auditor, die geeft anders zijn onafhankelijke rol op.

Als dit voor die bedrijven een risico is voor de bedrijfsvoering, dan moet 98% van de bedrijven er iets aan doen. Echter de meeste bedrijven hebben geen Penetratie test en of audit nodig en is arp spoofing dus ook eventeel geen issue.

Zo werkt het niet. Er is hier gewoon een issue geconstateerd. Want wat als men wel toegang kan krijgen op het server VLAN? Wat dan.....
Trouwens als dit op het server VLAN mogelijk is, is het waarschijnlijk ook mogelijk op het werkstations VLAN. En dan kan men gewoon rustig hun gang gaan totdat men toegang krijgt tot de servers.
Ook NAC bied hier geen security oplossing voor. Immers als ik NAC toegestaande device own, kan ik gewoon alles doen wat ik wil.

Dus eigenlijk je kop in het zand steken, en zeggen dat het nooit mogelijk is? Is goed uit te leggen bij je managers.
Want als ik nu wel toegang tot de beveiligde zone van je gebouw kan komen? Hoe ga jij mij dan detecteren? En ja er zijn diverse mogelijkheden toe.

Ik lees nergens dat het een " hoog risico" bevinding is. Je loopt te veel van stapel. Het is gewoon een bevinding vanuit de audit.
Voor een bedrijf dat een audit laat uitvoeren, zijn het gewoon risico's en die moet je analyseren en eventueel mitigeren. Dit is gewoon risico analyse waar een aantal managers zich voor moeten verantwoorden.

Daarnaast moet je dit soort tegen discussies niet willen voeren in de techniek. Gewoon tegen de managers zeggen, ja dit kunnen aanpakken met de volgende mogelijkheden en kost zoveel. Eventueel met de opmerking dat het risico erg laag is.

Het zijn niet jouw centen, maar wel jouw verantwoording als het later toch een keer fout gaat. Dan moet jij je in eens verantwoorden.

Ik heb genoeg penetratie audits mee gemaakt, waarin ik mij afvraag of ze echt wel goed gekeken hebben en ben het niet altijd eens met de bevindingen. Maar dat is niet iets voor mij om te bepalen.


Hangt van de scope van de audit af. Het is een Penetratie test. Hoe je daarna de bevinden kunt oplossen is een 2de. Misschien zijn sommige issues zelfs niet te op lossen. Dat is iets voor het bedrijf om aan te pakken. Adviezen documenteren en klaar.

Kijk ook wat de mitigerende controls zijn en laat ze deze opnemen in hun rapport.
Als ze dat niet willen zijn dit geen auditors en beunhazen.

Nee dan zijn ze geen beunhazen, maar hebben ze zich waarschijnlijk gehouden aan de scope van de afspraken.
Daarnaast kunnen zo ook niet veel roepen, behalve zorg er voor dat het niet voor kan komen, of dat het gedetecteerd kan worden. Technisch kunnen ze er niets over vertellen, want dat is iets voor het bedrijf om naar te kijken.

Een vervolg opdracht zou kunnen zijn, hoe kunnen we deze bevinding aanpakken en oplossen.

De rol van de auditor en pentester eventueel geholpen via expliciet toegestaan ethisch hacken is wel degelijk bedoeld om inzicht te geven in de technische en logische kwetsbaarheden. Met alleen het benoemen van een kwetsbaarheid is er toch nog geen inzicht verschaft. Hoe wil je het dan kunnen mitigeren als dat al mogelijk zou zijn? Vaak zijn auditor en pentester een en de zelfde gekwalificeerde beveiligingsdeskundige. Met de mededeling "uw dak lekt" zonder aan te geven hoe dat dient te worden verholpen, raak je toch nog meer van de regen in de drup? Of er vervolgens wat aan het lekkende dak wordt gedaan en of daar geld en tijd voor beschikbaar is, is een volgend discussiepunt. Voorbeeld - soms werkt men nog door met RSA4 omdat andere oplossingen wel drie keer zo duur zijn en we zijn immers "zuunig" toch zo lang als het kan en het hoeft niet per se neem je het risico op de koop toe.

Maar, daar gaat het hier niet om. Met arp inspectie ingesteld, zijn er maar 15 ARP PPS op een "untrusted" poort mogelijk, dan gaat het onmiddellijk "change state to down". Een ACL kan worden aangemaakt en dan kun je arpen wat je wil, er komt niets door. Poortbeveiliging is ook een mogelijkheid met een maximum van 1 en dan hup je krijgt "switchport port-security violation shutdown". Laat daar de pentester maar eens lekker op zweten, je houdt hem zo wel even bezig hoor. Je kan echter dan nog wel redirecten en via een gewijzigde route table host teruggaan en kan het alsnog langs het ingestelde filter met "192.168.69."255"" pakketjes. Van statisch werken wil men in een bedrijfsomgeving vaak niets weten. Dus zeg het maar, wat gaan we doen?

Klinkt als een pentest waarbij de scope niet goed is neergezet v.s. hoe in jullie bedrijf prioriteiten worden gezet.

Patch management en Lifecycle management behoren natuurlijk op orde te zijn.
Dat hoor je op orde te hebben voor een pentest.

Om je even te helpen: zie de CIS Critical Security Controls top 20.
Zowel ARP als patch management staan daarop.
Zet daarmee je prioriteiten goed.

En de volgende keer dat iemand over een pentest begint voor dat op orde is vertel je de pentester dit alles. Dan komt dat ook gewoon netjes in zijn rapport met de juiste prio.