"Eén van de kritieken is dat "security through obscurity" geen beveiligingsmaatregel is, maar alleen een manier om een aanvaller te vertragen en daardoor weinig waarde biedt."

Tja, sommige mensen noemen alles waardoor je niet *iedere* aanvaller afslaat als onzinnig. Ik vraag mij af of die mensen geen slot hebben op hun voordeur, omdat een slot niet per definitie iedere inbreker tegen zal houden. Ook al is de kans op een insluiper met een slot op je deur wel kleiner ;)

Ik gebruik express SSH op port 22 om op deze manier alle IP's die mij aanvallen te loggen in een database middels fail2ban.

Express port 22 gebruiken om een database te kunnen vullen, dat is een hele goeie reden.

Ik heb nog wel een paar gevulde databases voor je, kan je nog meer vullen !

Die ruis valt restricten.
Net als de users/group/remote-ip trouwens (...).

Waarom tolerenen?
Voor SSH/rsync clients die moeite hebben met niet (IANA assignde) well-known ports. Gemak dus versus een geen-probleem issue.

Kortom: meneer is een lulhannes met een button "expert" die blijk geeft dat ie z'n daemon niet weet te configureren, of gebruikt maakt van prutszooi.

Express port 22 gebruiken om een database te vullen ?

Als je je database nog groter wilt hebben probeer dit eens
http://serverfault.com/questions/647891/make-fail2ban-use-public-blacklists

Een security-through-obscurity maatregel die je op zichzelf staand gebruikt is zinloos. Sterker nog, gevaarlijk, want het biedt schijnveiligheid waardoor je aandacht voor het gevaar verslapt. Maar een security-through-obscurity als aanvulling op werkelijke beveiligingsmaatregelen kunnen nuttig zijn of deze zelfs verbeteren. Als je bij de inzet van die security-through-obscurity maatregel er maar van bewust bent dat het geen echte beveiliging biedt.

Als je in staat bent om je SSH op een andere port te draaien ben je toch ook wel in staat een firewall te configureren? Doe dat dan gewoon?

Wat een briljante mensen hebben ze daar bij het ISC rondlopen, zeg. We hadden laatst ook al zo'n licht die voorstelde om ssh maar vanuit de linux distributie standaard op een andere poort te zetten. Het enige wat dat uitmaakt is nog een poortnummer verbranden, want dat wordt dan ook standaard gescand. Als je dit soort dingen publiek zegt dan heb je toch even niet begrepen hoe security by obscurity gedacht wordt te werken, nog bovenop niet snappen waarom het toch al automatisch weggewimpeld wordt als werkt uiteindelijk toch niet.

De "standaardmethode" is om een van de beschikbare log-analyzers te pakken die meerdere mislukte pogingen in korte tijd opmerken en de bron daarvan aan je packet filter doorgeven, wellicht met een automatisch opschoonmechanisme na een paar uur. Dit werkt ook met "overduidelijke" misbruikpogingen op bijvoorbeeld http (als je het goed doet en niet toevallig legitieme bezoekers als crimineel aanmerkt vanwege een linkje aanklikken op je eigen site, bijvoorbeeld). Daarnaast geen wachtwoorden toestaan maar alleen sleutels gebruiken. En natuurlijk, bij meerdere machines geen ssh toestaan van buitenaf behalve naar die ene bastion host, vanwaar je de rest van je servers kan bereiken.

Maargoed, snappen waar het over gaat is geen prioriteit. Flink discussieren wel. Bijvoorbeeld:

Je argument klopt niet. Het is meer of je die deur een eindje verplaatst zodat'ie niet meer direct van de straat af te zien is, of je monteert de deurklink ondersteboven. Heel leuk en aardig tegen deurklinkbespringende huisdieren, maar nou niet echt handig in het dagelijkse gebruik. Zulke klinken worden dan dus ook niet standaard gemonteerd in huizen, laat staan op buitendeuren.

Op de lange duur is de kans op een insluiper niet echt kleiner, nee. Poortjes verschuiven helpt in het geval van ssh alleen maar als je toch al a) zwakke wachtwoorden bij b) toevallig door de aanvallers geprobeerde gebruikersnamen gebruikt en c) zolang aanvallers niet ook andere poortjes gaan scannen. Je deur stond dus al open en je hoopt op medewerking van je aanvaller om niet te zien dat je 'm verschoven hebt.

Laten die aanvallers dit alles nou toch al volautomatisch doen. De bochten waar jij je in wringt zal ze worst wezen; ze zetten wel een iets groter botnet op dat scannen van wat meer poortjes. Als je dit soort maatregelen nodig denkt te hebben start je dus al vrijwillig aan de verliezende kant en speel je het spelletje van de aanvaller mee. Dat is echt heel slim.

De manier om het echt op te lossen is om eerst die brutekrachtaanvallen onmogelijk te maken door sleutels ipv wachtwoorden te gebruiken. Daarmee reduceer je het probleem tot het willen afremmen van het opvullen van je logs met berichten over kansloze aanvallen. Een logalizer gekoppeld met een packet filter doet dat prima. Als je dan ook nog zonodig een andere poort wil kiezen dan moet je dat zelf maar weten, het maakt niet echt meer uit.

Blijft staan dat als je gaat roepen dat jouw extraspeciale poortjesdansje geschikt is als eenieders eerste lijn van verdediging dan je dan toch net niet gesnapt hebt hoe de materie inelkaar steekt. Waarmee je dan zo te zien toch nog in goed gezelschap blijkt te verkeren. Gefeliciteerd.

Die kritiek ben ik vaker tegengekomen, bij soortgelijke maatregelen. Wat die critici niet lijken te kunnen bevatten is dat je door een op zich zwak drempeltje toe te voegen geen beveiligingsmaatregelen uitschakelt. Als je de afwijkende poort weet te vinden kom je nog steeds een SSH-server tegen en die moet nog steeds goed geconfigureerd en up-to-date zijn.

Maar er zijn mensen die als ze iets tegenkomen dat vaag aan security-through-obscurity doet denken meteen in een kramp schieten die verder nadenken blokkeert, en die reageren alsof zo'n maatregel de echte beveiligingsmaatregelen teniet doet, en dat is flagrante onzin. Dit ís dan ook geen security-by-obscurity in mijn ogen, dat is het pas als je denkt dat het een goede vorm van toegangsbeveiliging kan vervangen, als je denkt dat je SSH niet meer nodig hebt en zo stom bent om telnet op die afwijkende poort te zetten, bijvoorbeeld, maar daar is hier geen sprake van.

Wat het oplevert is dat de aanvallers die via internetbrede scans servers zoeken minder kans hebben je te vinden, en als je geluk hebt kan dat nét betekenen dat misbruik van een nog niet gepatcht lek in SSH voorkomen wordt, dus in dat opzicht kan het verschil maken. Maar wat in mijn ogen de grootste verdienste van dit soort maatregelen is dat je logbestanden niet worden volgeschreven met al die mislukte pogingen om bij je aan te loggen, en ondanks tools om dat weer uit te filteren vind ik het erg prettig dat al die ruis om te beginnen niet eens geproduceerd wordt. Dat heeft in mijn ogen een positieve impact op de beveiliging omdat het informatie-overload helpt voorkomen als je de ongefilterde logfiles inspecteert, de kans dat het je gaat duizelen wordt verkleind en daarmee de kans dat je relevante zaken over het hoofd ziet.

Het effect is vergelijkbaar met dat van tools als fail2ban. Maar daarmee ben ik inmiddels heel wat jaren geleden gestopt toen botnets zo groot werden dat elke aanlogpoging van een ander IP-adres kwam en dat kon de toenmalige versie van fail2ban niet aan. Ik weet niet of daar inmiddels een antwoord op is bedacht, maar ik vermoed het wel aangezien fail2ban nog steeds wordt aangeprezen door mensen.

Wat ik in plaats daarvan heb gedaan is op een webserver die ook via SSH te benaderen is de SSH-poort pas open te zetten voor een IP-adres als van daaruit een specifieke URL die geen enkel ander doel dient is opgevraagd op de webserver. Die geeft trouwens een 404/not found af, maar stiekem gebeurt er toch iets. Dat zit ongeveer op hetzelfde niveau als port knocking (wat ik in plaats daarvan zou gebruiken als er niet al een service op die machine een poort open had staan voor de buitenwereld), en daar heb ik behoorlijk felle kritiek op gehad van magisch denkende mensen die maar niet tot hun brein laten doordringen dat er geen enkele beveiligingsmaatregel mee wordt uitgeschakeld.

Ik zet mijn poorten standaard buiten het bereik van een standaard nmap-scan. Geeft mij als privegebruiker net iets meer stealth-modus aangezien een snelle scan aangeeft dat mijn systeem ogenschijnlijk uitstaat. Daarmee dus wel enige toegenomen security.
En in paranoid-modus: stel dat de boefjes een database maken met alle poort 22 systemen die ze inzetten op het moment dat ze een zeroday hebben voor SSH. Dan zit ik liever niet in die database.

Minimaal veiliger, maar wel wat dus artikel klopt mijn inziens.

Dat hele zwakke drempeltje gooi je op "uit naam van de veiligheid" en aangezien het geen enkele beveiliging biedt, hooguit in je eigen gedachten, ben je vooral bezig jezelf te misleiden. Het gevaar dreigt dat je je ermee veilig gaat voelen terwijl je het niet bent, en dat is erger dan niet veilig zijn en dat wel te weten. De kritiek is dus ook vooral tegen die zelfmisleiding gericht.

En het is (niet alleen zelf-)misleiding als je oproept tot een poortjesdans. Zelfs de zeggens milde vorm die jij hier als toch wel acceptabel probeert te presenteren, onder verwijzing naar al die "verkrampte" mensen die zeggen dat je niet zulke domme dingen moet doen want we weten ondertussen al lang waar het toe leidt, want die zijn maar gemeen dus zo een slecht idee is het jouwe toch nog echt maar niet. Het is de redenering die je de das om doet.

Als jij zonodig ingewikkelde truuks wil uithalen die vooral het jezelf lastiger maken, goed, als jij daar moeite in wil steken dan doe je dat maar op jouw systemen, en dan ben ik blij dat ik er geen gebruiker van ben want al dat gedoe waar je uiteindelijk makkelijk minder dan niets voor koopt blijf ik graag van verschoond. Maar omdat het in essentie "security by obscurity" is, (en dus nog steeds snake oil) heb je (twee) hele goede redenen het netjes voor je te houden.

Het wordt dan ook direct iets anders als je oproept dat maar in z'n algemeenheid met z'n allen te doen. Dan heb je het toch even niet gesnopen en ben je gewoon en plein public alom zichtbaar dom bezig. En dat mag best gezegd worden.

Lastig als je overal ter wereld bij je SSH server wilt.
SSH is btw goed dicht te timmeren en fail2ban zal een remote exploit van (open)SSH nooit stoppen wel brute force attacks.
Het grappige is dat ik denk dat je dit eigenlijk voor bijna alles kan doen als je wilt dat ea veiliger is: HTTP op een random port draaien etc.
SMTP wordt een lastig verhaal als je mail verwacht ;)

Ik heb SSH gewoon op port 22 maar gebruik AllowUsers en een ACL zodat ik vanaf een jumpbox (die ik redelijk/goed vertrouw) er altijd bij kan.

How to Secure SSH with Google Authenticator’s Two-Factor Authentication:
http://www.howtogeek.com/121650/how-to-secure-ssh-with-google-authenticators-two-factor-authentication/

In mijn werk als security adviseur kom ik dit soort redenaties vaker tegen: "als het alleen maar vertraagt is het alleen een drempeltje wat geen beveiliging biedt".
Een hele vreemde redenatie, en ik ben ook benieuwd hoe je je huis hebt beveiligd:geen sloten, of SKG3, of sloten en grendels en alarmen en secustrips en tralies en... ?
Het lijkt maar niet tot mensen door te dringen dat drempels en vertragingen wel zeker helpen: er is GEEN 100% beveiliging, maar je moet maatregelen nemen in relatie tot het risico. Het is puur een kosten versus risico discussie. Een drempel als het verplaatsen van je SSH port naar een niet-standaard poortnummer is als het zorgen dat je net een beter slot op je voordeur hebt als je buurman: een willekeurige insluiper zal bij de buurman inbreken, en een script kiddie zal je SSH server niet vinden.
Maar net als in de echte wereld geeft het geen bescherming tegen gerichte aanvallen: als jij een friese staartklok hebt, en die is in het plaatselijke café besteld, dan wordt er niet bij de buurman maar bij jou ingebroken: SKG3 sloten, grendels, alarmen, en wat dan ook helpen niet meer. Op diezelfde manier zal het verplaatsen van de SSH poort geen enkele bescherming bieden tegen een gerichte aanval op jou: men heeft tijd genoeg om alle poorten te scannen, dus die vinden ze wel. Daarom moet je natuurlijk wel je additionele maatregelen nemen, zoals patches, keys, monitoring (er is eerder al van alles genoemd dus dat zal ik niet herhalen).



Dit heb ik een paar keer gelezen om te begrijpen wat ik mis...
Dus je vindt het simpel verplaatsen van een poort "ingewikkelde truuks wil uithalen die vooral het jezelf lastiger maken" maar noemt niet het grote voordeel, nl. dat je beheer inspanningen veel lager zijn omdat je alleen maar meldingen ziet van een gerichte aanval (waar je dus snel op moet reageren) in plaats van honderden meldingen van allemaal ongerichte aanvallen (waar je niets mee hoeft te doen)? Hmm...

Ik neem aan dat je ook altijd alle logging op maximaal zet, zodat je in plaats van alleen relevante meldingen te zien je dagelijks door megabytes aan onzinnige logregels moet lopen? Eerlijk gezegd denk ik dan dat er hier maar 1 persoon is die het zichzelf erg lastig maakt, en dat is niet degene die het SSH poortje verandert...



Hahaha, geen verder commentaar

P.S., een "andere" Anoniem dan de oorspronkelijke poster :-)

Tja de vele "specialisten" hier zullen er uiteraard wel weer over vallen, maar ik vindt dat Rick Wanner absoluut gelijk heeft.

En nee, ik denk evenmin dat het gebruik van een andere poort dan poort 22 beduidend meer veiligheid biedt. Maar het is wel heel wat rustiger.

Om de toegang tot mijn site te beveiligen gebruik ik alleen sleutels, en sta ik geen passwords en geen root toe.

Op Linux gebruik ik graag CSF omdat je dat heel eenvoudig zo in kan stellen dat alleen een beperkt aantal landen, b.v. alleen ip's uit Nederland toegang krijgen. Dat biedt op zich ook geen extra beveiliging, maar beperkt uiteraard wel een enorm aantal potentiële aanvallers.

CSF is jammer genoeg niet beschikbaar op Freebsd, waar ik recent op ben overgestapt en werd ik vervolgens voortdurend belaagd door voornamelijk Chinese scriptkiddies die met brute force attacks, vaak urenlang, mijn root password proberen te vinden. Of grote aantallen naam/password combinaties uitproberen.

Volstrekt zinloos natuurlijk omdat ik passwords sowieso uit heb staan en root al helemaal niet toe sta. Maar mijn logfiles zaten wel steeds tot de nok toe vol en dat maakt het een stuk lastiger om alle echte aanvallen uit die brij van zinloze aanvallen te halen.

Vervolgens heb ik daarom SSHGuard geïnstalleerd, die na een x aantal foute inlogpogingen, de aanvaller voor een bepaalde tijdsduur blokkeert. Die tijd wordt na iedere aanval daarna door dezelfde aanvaller steeds meer verlengd, totdat de aanvaller voor altijd wordt geblokkeerd.

Dat hielp al enorm, omdat een aanvaller al na een paar foute inlogpogingen wordt geblokkeerd. Maar er bleven desondanks nog altijd vele honderden aanvallen per dag plaats vinden, waarop ik mijn ssh poort toen maar heb gewijzigd.

En oh wonder, sindsdien (nu al sinds 4 maanden) heb ik niet 1 aanval meer te verduren gehad.

En als je echt iets van beveiliging weet, weet je ook dat niets 100% is te beveiligen. Maar dat het er om gaat een dusdanige barrière op te werpen dat het niet meer opweegt tegen de inspanning die moet worden verricht om door die beveiliging heen te komen.

En natuurlijk kan een serieuze aanvaller, bijvoorbeeld met nmap de juist SSH poort vinden. Maar een andere poort dan poort 22 beperkt ook het aantal aanvallers enorm. Dit omdat de meeste scriptkiddies het teveel werk vinden en het teveel tijd kost om de juiste SSH poort te vinden. En dan nog kunnen ze nog steeds alleen maar een brute force attack uitvoeren.

Dus die gaan veel liever door naar het volgende IP adres in de hoop dat daar wel wat te halen valt.

Wat de geldigheid van de barrière vs inspanning theorie onomstotelijk aantoont en bewijst dat "security through obscurity" dus wel degelijk zinvol is.

Uiteraard wel alleen als aanvulling op je normale beveiliging. En als extra bonus heb je nu ook een veel duidelijker zicht op echt serieuze (pogingen tot) aanvallen omdat je logfiles nu niet langer worden vervuild door scriptkiddies.

Nee, ik werp dat drempeltje niet op uit naam van de veiligheid. Ik denk wel dat het een bescheiden bijdrage levert, maar je mist de essentie: ik heb geen enkele maatregel die ik niet voor een publiek zichtbare poort zou toepassen achterwege gelaten. Dát doe ik uit naam van de veiligheid. En als die maatregelen goed genoeg zijn voor een poort die gewoon zichtbaar is, welk risico kan ik dan lopen door die poort enigzins te verbergen? Dat komt, zoals ik al duidelijk maakte, niet in plaats van andere maatregelen.
Ah, het risico van zelfmisleiding en daardoor optredende verslapping van de aandacht. Het probleem is hier niet dat dat optreedt, maar dat jij veronderstelt dat dat optreedt. Het is net andersom: juist omdat ik niet geconfronteerd wordt met duizenden meldingen in logfiles die er eigenlijk niet toe doen is het makkelijker mijn aandacht te houden bij wat er wel toe doet.
Stop alsjeblieft met redeneren vanuit aannames. Je loopt risico als je beveiligingsmaatregelen laat verslappen, niet als je iets erbij doet zonder die te laten verslappen. Je beschouwt het kennelijk als onvermijdelijk dat iemand die een poort verbergt geen oog heeft voor meer essentiële dingen. Da's precies het soort magisch denken waar ik kritiek op heb. Je kijkt niet naar wat er werkelijk gebeurt maar naar ongefundeerde aannames over wat er gebeurt.
En als de SSH-server erachter nou gewoon goed is geconfigureerd en de software gewoon up-to-date is? Wat blijft er dan over van jouw aannames?
Het heeft letterlijk twee regels code gekost om deze beveiliging in te bouwen, en het vergt een scriptje van twee regels om binnen te komen. Waar heb je het over?
Als je SSH op een niet-standaard poort zet hoef je maar een kleinigheid aan je ~/.ssh/config toe te voegen en je hoeft die poort nooit meer in te typen, je hebt er geen omkijken meer naar. Je kan zelfs aliasnamen voor servers instellen zodat je niet de hele domeinnaam hoeft in te typen, en ook alle andere opties die je voor de SSH-verbinding naar die machine handig vindt. Het is niet moeilijk.
Security by obscurity is volgens mij denken dat iets geheim houden zo'n goede bescherming oplevert dat je maatregelen die werkelijk bescherming opleveren achterwege laat. Aangezien ik die niet achterwege laat, en degene die waar het artikel over gaat trouwens ook niet, vind ik dat dit iets wezenlijk anders dan security by obscurity. Jouw aanname dat iets onzichtbaar maken meteen impliceert dat alle nadelen van echte security by obscurity in werking treden is, zoals ik al schreef, magisch denken. Die nadelen treden op als je je beveiliging laat versloffen, niet als je een kleinigheid regelt die geen enkele invloed heeft op hoe die SSH-server zijn authenticatie en encryptie afhandelt, en al evenmin op je SSH-configuratie, en ook niet op het up-to-date houden van je software. Zoals jij redeneert is het alsof het slot van je voordeur spontaan openspringt als je je heg door laat groeien. Lariekoek, da's echt magisch denken.
Dan hoop ik het dat je het me niet kwalijk neemt dat ik jouw domheid in redelijk harde bewoordingen heb weersproken.

Uiteindelijk is alles gebaseerd op security thourgh obscurity gezien een wachtwoord of een private key geheim moeten blijven.

bij mij heeft het maar 1 doel: de logs schoon houden. Dat werkt voortreffelijk. Het is niet als beveiligingsmaatregel bedoeld. Daarvoor gebruik ik rsakey+yubikey (2factor dus, en dan nog in een heel sterke vorm) en patchen, patchen, patchen.

Een verschil in poortnummer is nou niet echt het verschil of er wel of geen slot op de deur zit, of hoeveel sterren er op dat slot gegraveerd staan.

Beveiligen in deze (wereldwijd vernetwerkte digitale) ruimte is wezenlijk anders dan beveiligen in de fysieke wereld in de zin dat "aan de deur rammelen" vrijwel gratis is en effectief eindeloos opnieuw geprobeerd kan worden, vanaf schier eindeloze alternatieve locaties. Dat heeft verregaande gevolgen voor hoeveel zin "vertraging" nog heeft. Aangezien je dat maar vreemd vindt: Hou maar op met dat werk als "adviseur". Leg je maar toe op huisbeveiliging, dat snap je tenminste. Hopelijk.

Het zou wel fijn zijn als die maatregelen ook wezenlijk iets aan dat risico veranderen.

Dat moge zo zijn, maar de voortvarendheid waar jij kosten over het hoofd ziet helpt je argument niet echt.

Dat hoop je dan maar--je leunt effectief op de welwillendheid van dat scriptkiddie niet ook de andere paar veelgebruikte poortjes even te bekijken. In totaal zijn het er ook maar ~64k, en staan ssh servers voor lange tijd open en zijn dus prima scanbaar. Ook over het hele internet.

Je koopt er dus niet zoveel voor. Dat het jou weinig kost ("even" de configuratie aanpassen, mits en maar en zolang jij de enige bent die dat moet doen, zijn het er meer dan lopen de ondersteuningskosten snel op) mag dan zo zijn, het wordt snel wat anders als we met z'n allen afspreken (bijvoorbeeld doordat een linuxdistributie het "standaard" doet) om naar een nieuw poortje te verhuizen. Dat werkt wellicht een hele seconde, en daarna hebben we een poortnummer verbrand zonder dat het meer oplevert dan extra werk: Soms moet je de configuratie wel aanpassen, soms niet, en dat kan irritant worden als je veel machines in je configuratie moet bijhouden.

Vandaar dus, als je het zonodig zelf wil doen moet je dat zelf weten. Jouw afweging, die je op eigen kennis en kunde moet maken. In z'n algemeenheid is het te dom voor woorden. Moet je het iemand anders vragen dan heb je niet de benodigde kennis in huis om zo'n beslissing te maken en er beter van te worden. In jouw geval lijkt het er sterk op dat je betaald wordt om koning eenoog te spelen. Nou, gefeliciteerd dan maar.

En hoe weet jij dat een ander poortje gebruiken een gerichte aanval is? Wellicht heeft de aanvaller die ook maar gescand. Dat weet je niet dus moet je alles wat binnenkomt toch "onmiddelijk" bekijken om die afweging te maken.

Als je dat toch uit de data wil proberen te halen kan je beter die logs filteren op bestaande gebruikersnamen en correleren met ongeldige gebruikersnamen om te kijken of het niet toevalstreffers zijn.

En ja, alles wat niet standaard is, is extra configureerwerk, en moet dus gedocumenteerd en bijgehouden worden. Dat wordt extra leuk als je veel machines hebt, die wellicht allemaal net een ander poortje gebruiken dat je weer ergens moet configureren en zo verder. Valt me tegen dat je als zelfverklaard adviseur zo weinig fidusie van de effecten van grotere schaal hebt.

Als je dat echt gedaan had, dan had ik je mischien niet gefeliciteerd maar dan had ik je wellicht schorvoetend en met frisse tegenzin gelijk moeten geven. Maar dat heb je niet bereikt. Je hebt mij beschuldigd van vanuit aannames te redeneren en dat vervolgens minstens net zo hard zelf gedaan. Als je dat weerspreken nog eens wil proberen dan mag dat.

Ok, laatste poging ;-)

Een analogie. Stel, je hebt een kluis in een muur ingebouwd. Een robuuste kluis waar je niet zomaar in kan komen, robuust ingebouwd in een robuuste muur waar je hem niet zomaar uit krijgt. Je kan dat ding open en bloot in het zicht hebben, dieven moeten bijzondere vaardigheden op dit gebied hebben en er echt moeite voor willen doen om een kans te maken. De kluis staat voor de SSH-server.

Nou vind je het toch niet helemaal lekker dat dat ding open en bloot in het zicht hangt, je ziet er mensen vanaf de straat toch wel regelmatig naar kijken en je besluit er een schilderij voor te hangen. Geeft dat echte bescherming? Welnee, als iemand een kluis zoekt dan kijkt hij achter schilderijen, daar zitten ze in de film altijd tenslotte. Het schilderij staat voor de verborgen of alternatieve SSH-poort.

Maakt het schilderij de kluis minder robuust? Kan een inbreker hem makkelijker kraken dan wanneer er geen schilderij voor hangt? Natuurlijk niet, het is precies dezelfde kluis, en hij is precies even degelijk als hij zonder schilderij ervoor is. Vreemde gedachtenkronkel om te denken dat dat schilderij iets uitmaakt voor de robuustheid van de kluis.

Is dat schilderij security by obscurity? Ik vind van niet. Het is security by obscurity als je een schilderij voor een open nis in de muur hangt en aanneemt dat je zo tegen inbrekers beschermd bent. Maar er zit een kluis achter. Een degelijke. En die stopt niet opeens met degelijk zijn omdat je er iets voor hebt gehangen.

Voegt dat schilderij voor de kluis toch iets toe? Wel in de zin dat je minder aandacht trekt en wellicht minder kwaadwillenden zullen proberen in die kluis te komen, al weet je dat het ze hoogstwaarschijnlijk toch niet zal lukken. En dat staat voor al die hinderlijke aanlogpogingen in je logbestanden. Maar het is de kluis achter het schilderij die de echte veiligheid biedt.

Hoe jij redeneert: security by obscurity is per definitie riskant, ergens iets voor hangen is obscurity, dus als je een schilderij voor een kluis hangt introduceer je een risico. Pardon? Houdt die kluis spontaan op te bestaan als je er iets voor hangt? Nee, natuurlijk niet. Je neemt wel aan dat hij gammeler wordt omdat je er kennelijk van overtuigd bent dat veiligheidsinspecties en onderhoud slecht worden uitgevoerd als hij uit het zicht is. Onzin, die kluis is nog precies even zichtbaar als hij altijd was voor de mensen die hem regelmatig gebruiken.

Alleen bots en automated scanners voorkom je hiermee zo wat. Maar niet iemand die een nmap doet en als volgt een brute force attack met hydra erop loslaat... Tenzij je certificaten gebruikt i.p.v. wachtwoorden ;)
Dan ineens moet de aanvaller hopen op een 0day of er zelf een gaan zoeken..

@ anoniem, 14:37

Ik heb je reactie nogmaals gelezen en krijg de indruk dat we over verschillende zaken praten:
Het verplaatsen van een SSH poort is natuurlijk alleen interessant voor een thuis oplossing, en niet voor een bedrijf. Ik heb SSH toegang thuis, maar op een afwijkende poort, die ik alleen maar weet. Dus geen extra ondersteuningskosten, maar wel veel minder ellende in de logs. En niet iedere script kiddie jal een nmap scan van alle 65K poorten doen als ze niet ergens naar op zoek zijn: in diezelfde tijd kan hij/zij namelijk 65K aan IP adressen scannen op poort 22
Het gebruik van SSH in een bedrijfsomgeving moet sowieso anders: geen verschillende IP adressen en poorten, maar een enkele toegang tot een stepping stone, en daarvandaan op basis van credentials door kunnen stappen naar de betreffende omgevingen. Je kan dan bv. leveranciers of klanten vertellen hoe dat werkt, maar je hebt maar 1 toegangspunt. En natuurlijk ga je daar expliciet je logs analyseren en opvolgen bij specifieke meldingen.

Agree