[SEC] Security through obscurity - slecht of niet

[Bor]

Security through obscurity, vaak aangeduid als "Security through obscurity is no security at all". Een term die je ook hier op het forum wel tegen komt. Klopt dit echter wel. Een eerste lijn van afweer kan immers zijn het onzichtbaar / onherkenbaar maken van de beveiligingsmaatregelen.

Wikipedia geeft het volgende aan:

Security through obscurity is een beginsel uit de Informatiebeveiliging, dat beoogt beveiligingsrisico's te beperken door de werking van beveiligingsmaatregelen geheim te houden. Achterliggende gedachte is dat het niet mogelijk is om de beveiliging van een systeem te doorbreken als je niet weet hoe een systeem in elkaar zit. Hierdoor zullen kwetsbaarheden die binnen het mechanisme bestaan niet misbruikt kunnen worden.

Wat vinden jullie? Is Security through obscurity een goed idee en onder welke voorwaarden kan het principe bv wel of niet gebruikt worden? Hoe kijkt de tweaker hier tegen aan?

Meer info incl een aantal argumenten voor en tegen: wikipedia

[Meauses]

Bor de Wollef schreef op dinsdag 17 februari 2009 @ 23:01:
Security through obscurity, vaak aangeduid als "Security through obscurity is no security at all". Een term die je ook hier op het forum wel tegen komt. Klopt dit echter wel. Een eerste lijn van afweer kan immers zijn het onzichtbaar / onherkenbaar maken van de beveiligingsmaatregelen.

Wikipedia geeft het volgende aan:


[...]


Wat vinden jullie? Is Security through obscurity een goed idee en onder welke voorwaarden kan het principe bv wel of niet gebruikt worden? Hoe kijkt de tweaker hier tegen aan?

Meer info incl een aantal argumenten voor en tegen: wikipedia

Het eerste wat bij me opkomt hierbij is dat de uitdaging dan des te groter zal zijn voor de persoon die binnen wil komen. Deze zal dan op allerlei manier proberen informatie in te winnen om zichzelf toegang te verlenen o.a. social engineering, de systemen verbonden aan dat netwerk die wel bekende zwakheden hebben etc.

Aan de andere kant, wil je wel het achterste van je tong laten zien met dit soort dingen. Als men weet wat voor beveiliging je hebt kan men helpen door aan te geven wat er wel of niet veilig aan is. Je hebt er natuurlijk altijd wel een paar tussen zitten die de zwakheden voor zich zullen houden en hier misbruik van proberen te maken.

Dus ik denk zelf dat als je security through obscurity niet al te nauw neemt maar ook niet al te losjes, je minder kwetsbaar bent en beter kan sturen op vulnerabilities/zwakheden in je netwerk/systemen.

[frickY]

Het voornaamste probleem met security through obscurity is dat het een vals gevoel van veiligheid geeft, en de ontwikkelaar de echte gaten sneller over het hoofd ziet.
Bovenop een goed beveiligd systeem kan het uiteraard geen kwaad, maar in basis is het nutteloos extra werk.

[ Voor 8% gewijzigd door frickY op 18-02-2009 08:28 ]

[Equator]

Wat FrickY zegt: Een vals gevoel van veiligheid inderdaad. Een FTP server draaien op poort 8021 is leuk, maar met moderne poortscanners zijn ook die snel genoeg gevonden.

Het zelfde voor een onbekend encryptie-protocol. Kijk naar de OV pas. Een ding dat goedkoop gehouden is door inferieure encryptie-technieken te gebruiken waarvan alleen de maker wist hoe het werkte, en dus veilig geacht werd. Nou welk een wassen neus bleek dat

Liever een goed beveiligde service met een bewezen techniek, dan een slecht beveiligde service op een onbekende techniek..

[LuckY]

een Security trough obscrurity is af en toe handig voor je niet doorgewinterde hacker en scriptkiddie.
Een Nessus detecteert gewoon wat er achter de poort zit en of het vunereable is.
Het kan redelijk simpel zijn door iets te hiden, dan houd je de massa scan's tegen, maar niet de gerichte aanvallers.

[sh4d0wman]

Ik denk dat je een beetje uitkomt bij kosten/baten. Sommige systemen rechtvaardigen geen grote investering in beveiliging. Om het dan toch iets moeilijker te maken voor scriptkiddo's is security through obscurity zinvol. Bij meer belangrijke systemen zou het een laag moeten zijn bovenop andere maatregelen en niet een maatregel opzich aangezien men met voldoende tijd, middelen en kennis alles kan uitpluizen en het dus slechts schijnveiligheid bied.

[Equator]

Sommige systemen rechtvaardigen geen grote investering in beveiliging. Om het dan toch iets moeilijker te maken voor scriptkiddo's is security through obscurity zinvol

True, maar meestal wijk je dan af van gevestigde standaarden (ergo: andere poorten gebruiken voor services) wat de bruikbaarheid niet echt ten goede komt.

Voorbeeld: De FTP server op poort 8021, of een http(s) service op poort 8443, is allemaal heel leuk, maar de vanuit de meeste bedrijfsomgevingen, mag je niet naar externe services op die poorten connecten.
Bijvoorbeeld MS ISA server laat echt niet zomaar toe dat je een https sessie opzet naar een poort, anders dan 443, die poort moet je als beheerder dan expliciet toevoegen en toestaan.
Gevolg, je maakt het niet makkelijker, juist moeilijker. Ook voor de valide gebruiker.

Een goed beheerde FTP server, met voldoende logging, etc kan prima op poort 21 draaien. Big deal dat een poortscan hem ziet, en dat er een dictionary attack tegen aan wordt gegooid. Als de beheerder niet zit te slapen, en er wordt op een gedegen manier gelogd, dan is er niets aan de hand.

[LuckY]

Equator schreef op woensdag 18 februari 2009 @ 10:19:
[...]

True, maar meestal wijk je dan af van gevestigde standaarden (ergo: andere poorten gebruiken voor services) wat de bruikbaarheid niet echt ten goede komt.

Voorbeeld: De FTP server op poort 8021, of een http(s) service op poort 8443, is allemaal heel leuk, maar de vanuit de meeste bedrijfsomgevingen, mag je niet naar externe services op die poorten connecten.
Bijvoorbeeld MS ISA server laat echt niet zomaar toe dat je een https sessie opzet naar een poort, anders dan 443, die poort moet je als beheerder dan expliciet toevoegen en toestaan.
Gevolg, je maakt het niet makkelijker, juist moeilijker. Ook voor de valide gebruiker.

Een goed beheerde FTP server, met voldoende logging, etc kan prima op poort 21 draaien. Big deal dat een poortscan hem ziet, en dat er een dictionary attack tegen aan wordt gegooid. Als de beheerder niet zit te slapen, en er wordt op een gedegen manier gelogd, dan is er niets aan de hand.

Zijn er ook tools voor Windows met bijvoorbeeld fail2ban of andere meuk.
In de Windows logging en GPO kan je redelijk wat ook voor RDP maar het is nog niet ideaal.

[Equator]

Er zijn natuurlijk IDS systemen die samenwerken met IPS systemen of firewall's zodat er bij het detecteren van een intrusion, het originating IP adres direct geblocked wordt.
Het probleem is, hoe leer je die IDS wat wel mag, en wat niet mag

Je kan natuurlijk op een goede firewall ook aangeven wat er wel en niet mag op poort 3389, maar of en firewall kan acteren op een plotseling grote hoeveelheid sessies (waarvan hij niets weet wat er in de sessie gebeurt) dat durf ik je niet te zeggen. * Equator is niet zo'n firewall kenner. Ik weet er wel wat van, maar ben geen guru in deze

[Anoniem: 165232]

...

[ Voor 99% gewijzigd door Anoniem: 165232 op 23-05-2018 15:36 ]

[Zwerver]

Security through obscurity is handig op het moment dat je bijv. een hele rits met servers zal moeten voorzien van een patch die je nog hebt kunnen testen. In zo'n geval is het doorvoeren van een port-wissel e.d. een goede eerste stap, zodat je de bulk aan crack-attempts tegen kan houden. Je houdt er echter geen "echte" hackers mee tegen, alleen de scriptkiddies.

Daarnaast is StO handig als je af wil van de vollopende logs met hackattempts (denk aan ssh), je houdt alleen de echte hackattempts over. Het is alleen geen security op zich en je zult het naar mijn mening altijd moeten combineren met echte security meassures zoals patching van lekke applicaties/daemons en het inzetten van IDS/IPS achtige systemen zodra je praat over internet connected servers.

Het obscuren van versienummers en banners e.d. is opzich een redelijke manier van StO, een echte hacker heeft alleen wel andere manieren om te zien of een bepaalde server van een bepaalde versie is; een hackpoging die lukt tegen versie X en niet tegen versie Y verteld een echte hacker meer dan een banner.

[Bor]

Anoniem: 165232 schreef op woensdag 18 februari 2009 @ 12:41:
Ik denk dat het zowiezo belangrijk is voor de systemen die zwaar beveiligd moeten worden om zo min mogelijk informatie over zichzelf prijs te geven. B.v. Een FTP server kan als melding geven:

Welkom bij ProFTPD 1.12.

Hierbij geef je het versie nummer weer. Je kan de header ook veranderen naar:

Deze server is persoonlijk eigendom en mag alleen door de beheerder van het netwerk gebruikt worden blablablabla.

Dan geef je geen informatie weg en maak je een statement. Maar als je nu denkt dat je niet meer hoeft te patchen omdat je versie nummer niet te achterhalen valt dan heb je het weer mis

Helemaal mee eens. Je combineert als ware security through obsucity met securioty by design door simpelweg gewoon zo weinig mogelijk indentificeerbare informatie naar buiten te gooien. Natuurlijk stop je een poortscan niet maar voor scriptkiddies word't al minder interessant op die manier.

Security through obscurtiy alleen is bijna geen beveilging te noemen maar in combi met security trough design vind ik het vaak een prima maatregel.

[Anoniem: 165232]

...

[ Voor 99% gewijzigd door Anoniem: 165232 op 23-05-2018 15:37 ]

[Bor]

Anoniem: 165232 schreef op woensdag 18 februari 2009 @ 18:19:
Je kan er zelfs nog een stap verder in gaan door foutieve informatie te geven. B.v. met de freebsdtool portsentry. Deze zet willekeurig poorten open met geen service erachter. Maar een aanvaller zal wel 20 poorten vinden bij een poortscan, met een beetje creativiteit zou je de aanvaller zelfs kunnen laten denken dat die met ssh oid te maken heeft en daar exploits op zal gaan afvuren. Met een goede IPS zou je dan het ip van de aanvaller kunnen laten blokeren. Echter voegt het niks toe aan de beveiliging zelf + als een hacker het gevoel krijgt dat er met hem gespeelt wordt kan dat hem wel extra motivatie geven.

Je doelt op honeypot achtige functionaliteit?

[Anoniem: 165232]

...

[ Voor 98% gewijzigd door Anoniem: 165232 op 23-05-2018 15:37 ]

[Bor]

Een goede honeypot is niet lek maar simuleert lekken om ten eerste alarmen te genereren en ten tweede de aandacht af te leiden van de aandacht van de echte machines.