ssh: geen security by obscurity?

[Maasluip]

Als ik op een unix host ssh gebruik (getest op FreeBSD, geen idee welke ssh en op Solaris met OpenSSH) dan moet je ssh opstarten met als argumenten je usernaam en host waar je naar wil connecten.
Als je met w kijkt welke gebruikers op een computer zitten dan zie je ook welk commando ze gestart hebben en met welke argumenten. Dus je ziet direkt wie met welke usernaam naar welke host connect. En heb je een beginpunt voor een attack.

Is er echt geen optie in OpenSSH dat die interactief vraagt naar welke host je wil gaan en als welke gebruiker je wil inloggen?

[eghie]

Ah, dus je zit in een multiuser omgeving en je wilt vanuit die multiuser omgeving (bijvoorbeeld een terminal server, of een internet cafe PC) een ander systeem benaderen via SSH. Je wilt je gebruikers gegevens en host echter niet bekend maken, via ps aux, w, who -a, of misschien zelfs niet via .bash_history.

Ik ken zelf niet echt een commandline interactieve SSH client eigenlijk. Je kunt misschien naar een alternatieve client zoeken.

Of verberg de verbinding met een SSH tunnel

[ Voor 5% gewijzigd door eghie op 25-01-2008 22:45 ]

[Verwijderd]

Al zou dit lukken dan kan je het nog wel op andere manieren achterhalen, bijvoorbeeld met netstat.

[Nvidiot]

Zelfs als de client dat zou doen zou netstat het waarschijnlijk nog weergeven, alleen dan zonder gebruikersnaam...

[Kettrick]

netstat laat je alleen zien dat je een ssh connectie hebt naar een ip, user zie je daar uiteraard niet terug. Je kan FreeBSD overigens zo instellen dat je alleen je eigen processen ziet, dan verberg je het probleem dus min of meer

[FlorisB]

putty voor linux?

[Orion84]

Je kunt die gegevens ook in een eigen ssh configfile zetten toch? Als je die dan vervolgens fatsoenlijk afschermt is het ook goed. Voor zover ik kan zien kan je gewoon per hostname opgeven met welke username ingelogd moet worden. Dus dan hoef je alleen maar de hostname op te geven, waar je trouwens niet echt onder uit gaat komen (bij OpenSSH) denk ik. Maar die is sowieso wel te achterhalen via allerlei methodes dus die afschermen is niet echt een haalbare zaak denk ik.

En ach, uiteindelijk komt het er sowieso op neer dat je gewoon een fatsoenlijk password moet kiezen en dat liefst ook nog regelmatig wijzigt.

[moto-moi]

Maasluip schreef op vrijdag 25 januari 2008 @ 22:25:
Als je met w kijkt welke gebruikers op een computer zitten dan zie je ook welk commando ze gestart hebben en met welke argumenten. Dus je ziet direkt wie met welke usernaam naar welke host connect. En heb je een beginpunt voor een attack.

..want?

Ik ken bedrijven die hun ssh daemon expres 'verbergen' door ssh op een andere poort te draaien, ik las zelfs in de PC!Active dat Henk van der Kamer dit aanraadt, en mijn vraag blijft 'but waaaii', zolang je wachtwoorden in orde zijn komt er niemand binnen met geeikte passwordlistings, en als je dat al te eng vindt kun je met keyfiles werken. Wat is dan het probleem

[Erkens]

moto-moi schreef op vrijdag 25 januari 2008 @ 23:54:
[...]

..want?

Ik ken bedrijven die hun ssh daemon expres 'verbergen' door ssh op een andere poort te draaien, ik las zelfs in de PC!Active dat Henk van der Kamer dit aanraadt, en mijn vraag blijft 'but waaaii', zolang je wachtwoorden in orde zijn komt er niemand binnen met geeikte passwordlistings, en als je dat al te eng vindt kun je met keyfiles werken. Wat is dan het probleem

Het enige voordeel wat ik zou kunnen bedenken is dat je log file minder groot wordt door dictonary attacks

[Verwijderd]

Maasluip schreef op vrijdag 25 januari 2008 @ 22:25:
...
Is er echt geen optie in OpenSSH dat die interactief vraagt naar welke host je wil gaan en als welke gebruiker je wil inloggen?

Ik denk dat je je tijd beter kan besteden aan andere dingen, maar ja natuurlijk is het mogelijk om de process titel te veranderen. Dit kan bijvoorbeeld met een simpel shellscriptje.

Ik denk trouwens als je over zulk soort informatie al zorgen maakt, dan zou ik maar snel eens naar de MAC policies van FreeBSD gaan kijken. Standaard hebben gebruikens de rechten om bijvoorbeeld in /proc te kijken, netstat, pstat, vmstat, iostat (een aantal van deze commando's zijn wel enigszins gelimiteerd als standaard gebruiker)

[leuk_he]

moto-moi schreef op vrijdag 25 januari 2008 @ 23:54:
[...]
Ik ken bedrijven die hun ssh daemon expres 'verbergen' door ssh op een andere poort te draaien, ik las zelfs in de PC!Active dat Henk van der Kamer dit aanraadt, en mijn vraag blijft 'but waaaii',

Als je op een niet standaard poort draait krijg je veel minder poort scans, logvervuiling, en als er een keer een vulnerability is, dan is de kans dat de bots bij je binnenkomen kleiner. Gewoon een beetje obscurity erbij.

[CyBeR]

leuk_he schreef op zaterdag 26 januari 2008 @ 00:38:
[...]

Gewoon een beetje obscurity erbij.

Ik dacht dat de algemene consensus was dat dat niet werkte?

[Osiris]

moto-moi schreef op vrijdag 25 januari 2008 @ 23:54:
[...]

..want?

Ik ken bedrijven die hun ssh daemon expres 'verbergen' door ssh op een andere poort te draaien, ik las zelfs in de PC!Active dat Henk van der Kamer dit aanraadt, en mijn vraag blijft 'but waaaii', zolang je wachtwoorden in orde zijn komt er niemand binnen met geeikte passwordlistings, en als je dat al te eng vindt kun je met keyfiles werken. Wat is dan het probleem

Volgens mij ging 't meer om bijv het commando wat die user aan 't uitvoeren is. Als je bijv met `blaat -p geheimpassword` het process 'blaat' opstart, dan kan je password nog zo'n goeie zijn, hij staat er wel

[CyBeR]

Osiris schreef op zaterdag 26 januari 2008 @ 00:56:
[...]

Volgens mij ging 't meer om bijv het commando wat die user aan 't uitvoeren is. Als je bijv met `blaat -p geheimpassword` het process 'blaat' opstart, dan kan je password nog zo'n goeie zijn, hij staat er wel

Processen die dat ondersteunen (denk aan mysql) die halen dat ook weer weg. True, er bestaat een korte periode dat 't zichtbaar is, maar imo moet je dit soort dingen ook niet op deze manier doen met belangrijke wachtwoorden.

[Jungian]

leuk_he schreef op zaterdag 26 januari 2008 @ 00:38:
Als je op een niet standaard poort draait krijg je veel minder poort scans, logvervuiling, en als er een keer een vulnerability is, dan is de kans dat de bots bij je binnenkomen kleiner. Gewoon een beetje obscurity erbij.

Kleine moeite, groot plezier inderdaad. Mocht er al een script-kiddy slim genoeg zijn om eens een andere poort dan 22 te proberen en ook nog eens op mysterieuze wijze mijn key verkregen hebben, dan alsnog zal het zonder bijzonder leuke exploit langer duren dan hij leeft voordat hij eindelijk binnenkomt. En dan heb ik nog niet eens over iptables en port knocking.

CyBeR schreef op zaterdag 26 januari 2008 @ 00:54:
Ik dacht dat de algemene consensus was dat dat niet werkte?

Een huis met een deuren/ramen op de gebruikelijke plekken is makkelijker binnen te komen dan een huis zonder/waar zij zich op ongebruikelijke plekken bevinden.

offtopic:
Dit is verder geheel off-topic natuurlijk

[ Voor 6% gewijzigd door Jungian op 26-01-2008 01:07 . Reden: brakke bak iets minder brak gemaakt ]

[Osiris]

CyBeR schreef op zaterdag 26 januari 2008 @ 00:59:
[...]


Processen die dat ondersteunen (denk aan mysql) die halen dat ook weer weg. True, er bestaat een korte periode dat 't zichtbaar is, maar imo moet je dit soort dingen ook niet op deze manier doen met belangrijke wachtwoorden.

MySQL vraagt gelukkig om 't password als je een 'lege' -p opvraagt, maarja, hoe lossen andere processen dat op? Daar moet je gewoonweg allemaal aan denken als je op een multi-user-bak ingelogd bent.

Maar in principe heeft de TS wel gelijk IMO: alsof het andere users het wat aan gaat wat ik aan het draaien ben? W.m.b. heeft alleen root daar toegang toe. De `ps aux` op bijv. de publieke SSH-bakken van XS4ALL zijn ook best grappig. OK, je weet alsnog geen moer, maar dat komt meer omdat niemand wat spannends doet Als je bijv een irssi opstart met -c, -n en -w et cetera, om naar een IRC-server te connecten, dan weet jan-en-alleman dat dus ook mooi meteen

edit:

Zie ook een `ssh user@host` staan. Sure, moto-moi heeft uiteraard gelijk met z'n sterke wachtwoorden en eventueel keys e.d., maar het maakt een klooio die kwaad in de zin heeft 't toch een stuk makkelijker.

[ Voor 9% gewijzigd door Osiris op 26-01-2008 01:06 ]

[laurencevde]

Niet voor gerichte aanvallen nee, maar het is gewoon een feit dat de hoeveelheid inlogpogingen (en daarmee ook de kans op een geslaagde inlogpoging, de systeembelasting, en gevoeligheid voor een lek) dramatisch afneemt als je ssh op een andere poort zet. Er zijn nogal wat bots die bij je binnen proberen te komen, en die leid je hiermee wel mooi om de tuin.
Daarnaast zit er geen enkel echt nadeel aan ssh op een andere poort.
Security dien je in zoveel mogelijk (werkbare) lagen te doen, zodat zelfs al wordt er een laag doorbroken, dat de aanvaller nog nauwelijks verder is. Dit is simpelweg een extra, alhoewel dunne, laag.

[Verwijderd]

laurencevde schreef op zaterdag 26 januari 2008 @ 01:06:
Daarnaast zit er geen enkel echt nadeel aan ssh op een andere poort.
Security dien je in zoveel mogelijk (werkbare) lagen te doen, zodat zelfs al wordt er een laag doorbroken, dat de aanvaller nog nauwelijks verder is. Dit is simpelweg een extra, alhoewel dunne, laag.

Enige nadeel is dat veel gebruikers het niet gewend zijn om naar een niet-standaard poort te verbinden. Dit is alleen een probleem met een hele hoop gebruikers natuurlijk.

[Osiris]

Laten we dan ook meteen Apache niet meer op poort 80 draaien, stel je voor dat er opeens een exploit in Apache, PHP of wat dan ook zit!

Gewoon je zaakjes goed voor elkaar hebben, is dat nou zo moeilijk? Standaarden en standaardpoortnummers zijn d'r in principe natuurlijk niet voor niets.

[CyBeR]

Jungian schreef op zaterdag 26 januari 2008 @ 01:03:
[...]

Een huis met een deuren/ramen op de gebruikelijke plekken is makkelijker binnen te komen dan een huis zonder/waar zij zich op ongebruikelijke plekken bevinden.

Een huis zonder ramen of deuren is een huis waar je niet in kunt komen idd. Maar als de deur op een andere plaats zit dan bij de buren, stap je gewoon die anderhalve meter opzij en dan ben je er alsnog. (Slechte vergelijking trouwens, dit is in een oogopslag te zien.)

[phobosdeimos]

Enige OS dat ik ken dat dergelijke zaken kan verbergen is OpenBSD.
Daarom dat ze vaak ook OpenBSD kiezen als OS voor multi-user shellboxen.

[DiedX]

phobosdeimos schreef op zaterdag 26 januari 2008 @ 10:13:
Enige OS dat ik ken dat dergelijke zaken kan verbergen is OpenBSD.
Daarom dat ze vaak ook OpenBSD kiezen als OS voor multi-user shellboxen.

Zoals eerder aangegeven kan FreeBSD dat ook. Linux zelfs, alleen krijg je dan wel ongelooflijk ranzige kernelpatches uit obscure hoeken van de wereld die ik echt niet vertrouw...

TS heeft een punt. Ik vind het niet obscuur, maar eerder netjes om niet te weten waar andere mensen naar toe gaan, en ook: dat andere mensen niet weten waar ik naar toe ga. Maar op alle bakken ben ik root, en zal ik dat toch kunnen achterhalen

[_eXistenZ_]

moto-moi schreef op vrijdag 25 januari 2008 @ 23:54:
[...]

..want?

Ik ken bedrijven die hun ssh daemon expres 'verbergen' door ssh op een andere poort te draaien, ik las zelfs in de PC!Active dat Henk van der Kamer dit aanraadt, en mijn vraag blijft 'but waaaii', zolang je wachtwoorden in orde zijn komt er niemand binnen met geeikte passwordlistings, en als je dat al te eng vindt kun je met keyfiles werken. Wat is dan het probleem

En anders nog met Fail2ban \o/ Houdt ze aardig buiten de deur

[leuk_he]

CyBeR schreef op zaterdag 26 januari 2008 @ 00:54:
[...]


Ik dacht dat de algemene consensus was dat dat niet werkte?

Als je enige security de obscurity is (voorbeeld,telnet login met "root,password" op vreemde poort) nee, dan werkt het niet. Echter als kleine toevoeging aan een bestaande betrouwbare beveiliging kan geen kwaad, is een kleine moeite. Zolang je er maar niet op vertrouwd dat de obscurity vreemden buiten de deur houd.

[Verwijderd]

Ik zou het geen obscurity willen noemen. SSH op een andere poort draaien is obscurity, het is raar, maar eigenlijk niet anders. Als je de gebruikersnaam weet te verbergen, heb je het gewoon écht verstopt. Er is dan niet iemand die er alsnog achter kan komen. Het helpt maar een heel klein beetje qua beveiliging, maar op het gebied van privacy levert het veel meer op. Wie hoeft hou te weten dat ik op server X gebruikersnaam Y heb? Alleen ikzelf toch? Het is een deel van de login credentials, en dus is die kennis van mij, en voor niemand anders belangrijk.

[Michael]

phobosdeimos schreef op zaterdag 26 januari 2008 @ 10:13:
Enige OS dat ik ken dat dergelijke zaken kan verbergen is OpenBSD.
Daarom dat ze vaak ook OpenBSD kiezen als OS voor multi-user shellboxen.

Zoals gezegd kan het op FreeBSD uiterst simpel door het commando 'sysctl security.bsd.see_other_uids=0'. En niet vergeten deze waarde ook in /etc/sysctl.conf te zetten zodat het na een reboot ook weer goed staat.

[Sander]

Leuk hoor, maar wij hebben 25 servers draaien en allemaal SSH op een andere poort. Scheelt een bak in de traffic naar die machines, scheelt onze firewalls weer in het bannen van botjes en andere debielen die onze servers proberen te exploiten oid. Al met al een verdomd handig stukje obscurity...

Alleen op de ftp daemons per dag gemiddeld 400 false login pogingen per server, en dat is met een ban script erbij dat na 10 keer fout een half uur banned...

[ Voor 21% gewijzigd door Sander op 26-01-2008 12:38 ]

[Borromini]

CyBeR schreef op zaterdag 26 januari 2008 @ 00:54:
[...]


Ik dacht dat de algemene consensus was dat dat niet werkte?

Als dat de 'beste' verdediging is die je kan opwerpen - zoals bij closed source software vaak wordt aangehaald - dan werkt dat inderdaad niét. Als je het als toemaatje gebruikt, dan kan het wel helpen - het duurt wat langer voor de aanvaller je SSH daemon vindt, en de meeste bots scannen alleen op de standaardpoort. Persoonlijk vind ik een hogere poort een kleine moeite om m'n logs schoon te houden .

Jungian schreef op zaterdag 26 januari 2008 @ 01:03:
[...]

Kleine moeite, groot plezier inderdaad. Mocht er al een script-kiddy slim genoeg zijn om eens een andere poort dan 22 te proberen en ook nog eens op mysterieuze wijze mijn key verkregen hebben, dan alsnog zal het zonder bijzonder leuke exploit langer duren dan hij leeft voordat hij eindelijk binnenkomt. En dan heb ik nog niet eens over iptables en port knocking.

En denyhosts Al gaat het ook met iptables eigenlijk...

phobosdeimos schreef op zaterdag 26 januari 2008 @ 10:13:
Enige OS dat ik ken dat dergelijke zaken kan verbergen is OpenBSD.
Daarom dat ze vaak ook OpenBSD kiezen als OS voor multi-user shellboxen.

Met grsecurity patches kom je ook al een heel eind op Linux? Lijkt me toch niet zo obscuur...

Osiris schreef op zaterdag 26 januari 2008 @ 01:18:
Laten we dan ook meteen Apache niet meer op poort 80 draaien, stel je voor dat er opeens een exploit in Apache, PHP of wat dan ook zit!

Gewoon je zaakjes goed voor elkaar hebben, is dat nou zo moeilijk? Standaarden en standaardpoortnummers zijn d'r in principe natuurlijk niet voor niets.

Hoeveel plain dictionary attacks zie jij op PHP (gaat niet werken), Apache (lijkt me ook een vreemde manier van kraken), enz.?

Juist ja. Geen. Daar zet je geen botje op dat effe de halve Engelstalige woordenboek afloopt, en alle geijkte gebruikers (root, admin, blabla).

Niemand hoeft te weten dat jij of jouw bedrijf een SSH-server draaien. De mensen die 'm nodig hebben zullen ongetwijfeld weten dat hij er is en op welke poort hij draait. Ik zie nog niet zoveel doorsnee werknemers effe SSH'en naar de server op het werk .
Langs de andere kant is het meestal wel de bedoeling dat iedereen je website kan bereiken. Dus je draait dat ding op een standaard poort, of maakt het daar in ieder geval op bereikbaar.

[ Voor 71% gewijzigd door Borromini op 26-01-2008 12:58 ]

[DiedX]

[b]Borromini schreef op zaterdag 26 januari 2008 @ 12:45
Met grsecurity patches kom je ook al een heel eind op Linux? Lijkt me toch niet zo obscuur...

Klopt. Mijn excuses daarvoor. Toen ik daar mee bezig was was grsecurity nog niet zo ingevoerd. Tegenwoordig wordt het met zo'n beetje elke distro meegeleverd

[DusHmaniac]

Inderdaad, kijk eens op grsecurity.net en draai een daarmee gepatchte kernel. Zet in je kernel config /proc dicht voor iedereen behalve de groep wheel en dan kan iemand uit een andere groep dan wheel alleen nog maar zijn eigen processen zien.

Overigens zie ik het nut niet helemaal in hiervan (voor ssh). Standaard gebruiken de meeste linux distros openssh als client die je wachtwoord niet zichtbaar opslaat. Je kan hooguit zien welke username er gebruikt wordt en welke host maar als je je wachtwoorden random houdt wordt het verrekte lastig om iets met die informatie te doen.

Helemaal netjes is als je de auth baseert op certifcaten. Zolang jij dan je certificaten buiten bereik houdt van andere gebruikers is het allemaal veilig.

[Verwijderd]

Ssh keys is de beste methode om de bekende ssh aanvallen te stoppen. Mocht je geen keys willen of kunnen gebruiken dan is pam_abl echt een aanrader. Pam_abl is beschikbaar voor GNU/Linux en FreeBSD en werkt ongeloofelijk goed. Echt een aanrader

http://www.hexten.net/pam_abl/

Howto´s:

http://www.linux.com/articles/60955

http://www.ducea.com/2006...lock-brute-force-attacks/

[Jungian]

CyBeR schreef op zaterdag 26 januari 2008 @ 01:23:
Een huis zonder ramen of deuren is een huis waar je niet in kunt komen idd. Maar als de deur op een andere plaats zit dan bij de buren, stap je gewoon die anderhalve meter opzij en dan ben je er alsnog. (Slechte vergelijking trouwens, dit is in een oogopslag te zien.)

Ik dacht meer aan alleen ramen en deuren op het dak. Voor scriptkiddies (= vrijwel alle attacks) gaat de ladder pakken (portscan) te ver.

[Osiris]

Borromini schreef op zaterdag 26 januari 2008 @ 12:45:
[...]

Hoeveel plain dictionary attacks zie jij op PHP (gaat niet werken), Apache (lijkt me ook een vreemde manier van kraken), enz.?

Juist ja. Geen. Daar zet je geen botje op dat effe de halve Engelstalige woordenboek afloopt, en alle geijkte gebruikers (root, admin, blabla).

Niet te vergelijken met een dictionary-attack op SSH wellicht, maar meer dan genoeg scriptjes die at random op poort 80 uitgevoerd worden. Sure, die zijn dan gericht op IIS, maar da's slechts een detail, kan net zo goed Apache of een webapplicatie zijn.

Zou lachen zijn als je dan maar doodleuk vermeldt dat de gebruikers maar op poort 81 moeten connecten, want dat is handiger voor de security.

Borromini schreef op zaterdag 26 januari 2008 @ 12:45:
Niemand hoeft te weten dat jij of jouw bedrijf een SSH-server draaien. De mensen die 'm nodig hebben zullen ongetwijfeld weten dat hij er is en op welke poort hij draait. Ik zie nog niet zoveel doorsnee werknemers effe SSH'en naar de server op het werk .
Langs de andere kant is het meestal wel de bedoeling dat iedereen je website kan bereiken. Dus je draait dat ding op een standaard poort, of maakt het daar in ieder geval op bereikbaar.

Poortscannertje en je ziet meteen wat d'r open staat. Sure, tegen die standaard "laat ik een random IP gaan 'kraken'"-troep is 't wellicht nuttig, maar die komen toch niet binnen. En je gaat mij niet vertellen dat die paar login-pogingen totdat 't IP geblokkeerd wordt zoveel traffic vreten.
En je zou een redirect kunnen maken naar je 'verborgen' webserver @ andere poort, grote kans dat die scriptjes die toch niet volgen. Maarja, dat zie je dan weer niemand doen

Sowieso ben ik van mening dat je poorten standaard moet houden. Zou lachen zijn, ben je bij een klant die achter een dikke firewall zit, uitgaande poorten allemaal geblokkeerd enzo, behalve enkele standaardpoorten waaronder SSH. "Ff" naar 't werk/kantoor SSH-en! Oh kut, draait op andere poort, geblokkeerd, oopsie

[Verwijderd]

Het gevaar van SSH op een andere poort draaien, is dat je een complexere omgeving creëert. Complexiteit werkt fouten in de hand en moet dus te rechtvaardigen zijn. Of de bandbreedte van 400 inlogpogingen een rechtvaardiging is, bepaalt de organisatie danwel persoon in kwestie.

Doe je het toch, zorg dan dat je alles goed documenteert. Als een collega een firewall opzet, moet die wel weten wat waar draait. En maak het jezelf niet te moeilijk; "draait SSH nou op poort 12563 of 12564?" Vooral bij port knocking (rootkits anyone?) moet je wel weten waar te kloppen.

Mijn tip: speel open kaart, en richt je ICT-infrastructuur zo transparant mogelijk in.

[daft_dutch]

om ssh security by obscurity te noemen is erg dwaansaf. Natuurlijk kan obsurity worden toegevoegt. Bij voorbeeld om root niet laten inloggen. Immers root is een veel voorkomende username.


Ik vertrouw ssh. Natuurlijk moet je niet dom zijn. Bijvoorbeeld niet op elke bak waar je een shell op hebt je public keys rond zaaien.

Maar het zien van de usernames van de gebruikers in de history is meer het file systeem. of Distro
veiligheid dan ssh. Dat een gebruiker andere homes kan lezen is een optie. (bij debian wordt dit aan de gebruiker gevraagt).
veiligheid is gebruikers afhankelijk.
En wat voor veiligheid obsurity ook is, het is een extra barrere.
Om nog wat obsurity toe tevoegen. close source heeft ook obsurity. Maar opensource nog meer. Hoe veel verschilende Distro's met verschillende Kernels, kernel versies en compile varianten zijn er wel niet.

[Seth4Chaos]

Ze hetvolgende in "~/.ssh/config"

Host as
Hostname www.xxx.nl
User pietjepuk

als je vervolgens "ssh as" typed wordt zowel je username als je hostname verborgen gehouden.

ps -aux:

piet 6111 0.0 0.1 28024 1472 p3 S+ 2:58PM 0:00.20 ssh as

Overigens kan je nu alsnog zien in netstat welk ip-adres je naar connect maar iig is je username verborgen.

[Borromini]

daft_dutch schreef op zondag 27 januari 2008 @ 14:37:
om ssh security by obscurity te noemen is erg dwaansaf.

Dat was ook niet waar de TS op doelde voor zover ik weet...

Om nog wat obsurity toe tevoegen. close source heeft ook obsurity. Maar opensource nog meer.

Verklaar je nader?

Hoe veel verschilende Distro's met verschillende Kernels, kernel versies en compile varianten zijn er wel niet.

Tsja.. Hoeveel Windows-versies zijn er niet? Niet alleen de officiële releases van Microsoft, ook de gepatchte versies (niet elke versie is even up to date, etc.). Net hetzelfde. Bij FOSS is meestal bekend welke exploits met welke softwareversies werken, dus dat kan je nog zo makkelijk checken. Draai bv. Nessus, en je hebt zo al een overzichtje van wat mogelijke zwakke punten op het netwerk zijn.
Dat je code door iedereen bekeken kan worden maakt haar ook vatbaarder voor exploits, maar de bugs worden des te sneller gefikst. Zoals het 'spreekwoord' zegt: given enough eyes, all bugs are shallow. Het mes snijdt langs twee kanten - dit is iets waar closed source-software niet van kan profiteren.

[ Voor 24% gewijzigd door Borromini op 27-01-2008 15:22 ]

[GrooV]

Ach, zelfs XS4ALL schermt dit niet af op zn shell boxen, zie je gewoon ff 200users die mutt doen. Boeit het wat? Nee.

[Verwijderd]

Het is helemaal geen veiligheidsissue, het is een privacyissue. En ja, het boeit.

[Osiris]

Verwijderd schreef op maandag 28 januari 2008 @ 19:01:
Het is helemaal geen veiligheidsissue, het is een privacyissue. En ja, het boeit.

Privacy is in principe ook deels je eigen pakkie an hè. Als ik besluit om mijn persoonsgegevens overal te verspreiden, ook waar dat niet nodig is, bij wie moet ik dan gaan klagen dat mijn persoonsgegevens vervolgens op straat liggen?

[SKiLLa]

Osiris schreef op maandag 28 januari 2008 @ 19:06:
[...]

Privacy is in principe ook deels je eigen pakkie an hè. Als ik besluit om mijn persoonsgegevens overal te verspreiden, ook waar dat niet nodig is, bij wie moet ik dan gaan klagen dat mijn persoonsgegevens vervolgens op straat liggen?

Tja, maar niet iedereen "denkt eraan" of weet dat middels SSH inloggen bij XS4All je username - en mogelijk dus meteen je initialen en/of emailadres "exposed". Staat het in de login-banner, de helpdesk pagina, algemene voorwaarden ?

En b.v. sommige providers geven je altijd een emailadres als <voorletters.achternaam>@<isp>, zelfs als je er expliciet niet om vraagt. In hoeverre kun je alles van te voren uitsluiten ?

Ofwel: natuurlijk is het deels je eigen verantwoordelijkheid, maar sommige instanties gaan er nogal laconiek mee om - en gaan aan dat feit voorbij.

On-topic: SSH op een andere poort kan - afhankelijk van de context - prima te verantwoorden zijn (b.v. hobby-server), in andere gevallen is een simpele (additionele) firewall (whitelisting, port-knocking, certificaten) juist beter (b.v. groot-zakelijk).

[Osiris]

SKiLLa schreef op maandag 28 januari 2008 @ 19:48:
[...]


Tja, maar niet iedereen "denkt eraan" of weet dat middels SSH inloggen bij XS4All je username - en mogelijk dus meteen je initialen en/of emailadres "exposed". Staat het in de login-banner, de helpdesk pagina, algemene voorwaarden ?

Sja, "niet iedereen denkt eraan". Da's nogal een slecht excuus IMO. Ik ken ook niet het complete wetboek, maar toch dien ik mij er aan te houden. Heb ik nu een poot om op te staan, omdat ik "ergens niet aan dacht"? Nee toch? XS4ALL biedt een (experimentele vast ook nog) dienst. Hoe en of jij daar mee omgaat, is je eigen pakkie an. Helaas kun je niet inloggen met een extra POP-box: "This is an email-ONLY account, so you cannot log in on the unix shell." Zou ze sieren als dit wel mogelijk zou zijn.

SKiLLa schreef op maandag 28 januari 2008 @ 19:48:
En b.v. sommige providers geven je altijd een emailadres als <voorletters.achternaam>@<isp>, zelfs als je er expliciet niet om vraagt. In hoeverre kun je alles van te voren uitsluiten ?

Je hoeft natuurlijk niet per see dat emailadres te gebruiken?

SKiLLa schreef op maandag 28 januari 2008 @ 19:48:
Ofwel: natuurlijk is het deels je eigen verantwoordelijkheid, maar sommige instanties gaan er nogal laconiek mee om - en gaan aan dat feit voorbij.

Tja, 't kan altijd beter natuurlijk Gras is altijd groener bij de buren blabla IMO zou bijv XS4ALL andere usernames naast je 'hoofdaccount' in moeten kunnen laten loggen en ISP's zouden minimaal X aantal aliassen moeten geven, dan zit 't wel snor lijkt me.

[Zwerver]

daft_dutch schreef op zondag 27 januari 2008 @ 14:37:

Ik vertrouw ssh. Natuurlijk moet je niet dom zijn. Bijvoorbeeld niet op elke bak waar je een shell op hebt je public keys rond zaaien.

Uhh, waarom denk je dat die dingen public heten? Juist, omdat het geen kwaad kan ze rond te laten slingeren. Het wordt een ander verhaal als je private key op honderden machines staat....

Maar het zien van de usernames van de gebruikers in de history is meer het file systeem. of Distro
veiligheid dan ssh. Dat een gebruiker andere homes kan lezen is een optie. (bij debian wordt dit aan de gebruiker gevraagt).
veiligheid is gebruikers afhankelijk.

History? Dat is user afhankelijk, en zo goed als altijd kan je daar niet bij als een andere user (root als uitzondering).

En wat voor veiligheid obsurity ook is, het is een extra barrere.
Om nog wat obsurity toe tevoegen. close source heeft ook obsurity. Maar opensource nog meer. Hoe veel verschilende Distro's met verschillende Kernels, kernel versies en compile varianten zijn er wel niet.

Wat een BS wat je daar zegt.... verdiep je eens in obscurity?

[Verwijderd]

Osiris schreef op maandag 28 januari 2008 @ 19:06:

Privacy is in principe ook deels je eigen pakkie an hè. Als ik besluit om mijn persoonsgegevens overal te verspreiden, ook waar dat niet nodig is, bij wie moet ik dan gaan klagen dat mijn persoonsgegevens vervolgens op straat liggen?

Volgens mij zitten we aan dezelfde kant van de lijn. Het zou met OpenSSH eigenlijk ook mogelijk moeten zijn om alleen verbinding te maken met "een server" en vervolgens tegen die server vertellen welke gebruikersnaam je wilt gebruiken. Zo is in de process list in elk geval niet te zien als wie je je authenticeert op een andere server. Dat is informatie die niemand op een andere server aangaat. Dat gezien kan worden met welke server je verbindt is eigenlijk al teveel. Je zou je SSH client interactief moeten kunnen starten en daarna pas de gegevens op moeten kunnen geven. Helaas gaat dat bij de standaard OpenSSH implementatie van de client niet, voor zover ik weet.

[Osiris]

Je kunt echter wel gebruik maken van ~/.ssh/config, waarbij je meerdere servers als 'shortcut' oid op kunt geven, zoals Orion84 en Seth4Chaos ietswat concreter al opmerken.

[dragunova]

Klein kickje nu ik door mn bookmarks blader; dit is misschien interessant voor je als je meer veiligheid zoekt. Volgens de gebruiksaanwijzing werkt het met als alternatief voor portknocking en een scriptje dat er voor zorgt dat een aantal poorten op beide hosts synchroon moet lopen om contact te maken. Crypto in de moderne zin van het woord zal ik maar zeggen; lijkt me best veilig.

[ Voor 4% gewijzigd door dragunova op 03-02-2008 22:07 ]

[Verwijderd]

dragunova schreef op zondag 03 februari 2008 @ 21:54:
Crypto in de moderne zin van het woord zal ik maar zeggen; lijkt me best veilig.

This is alpha software. It's an open source rewrite of code I actually run on my own server, there could be bugs, so please report them and I'll get fixing.

Niet echt handig voor op een productie server.

imo kan je dan veel beter gebruik maken van ssh keys.