Afdrukvoorbeeld
Welke fundamentele onveiligheden in telnet doel je op ?Citaat:
Origineel geplaatst door MikeN
Mits je het over een SSL tunnel smijt en je de fundamentele onveiligheden in telnetd voor lief neemt is het idd prima te doen.
En waarvoor een SSL tunnel ?
Je haalt je mail toch niet op via je telnet sessie, of wel ? ;)
Telnetd is een zeer oude applicatie, welke veel te veel werkzaamheden als root uitvoert, iets wat in het verleden al aardig wat ernstige lekken tot gevolg heeft gehad.
En misschien haal ik m'n mail niet op via telnet, maar ik verstuur er wel het root wachtwoord overheen van de server waar m'n mail op staat, what's the difference. Jup, je kan hem uiteraard ook gewoon firewallen op IP e.d., maar het idee blijft hetzelfde, namelijk dat je via SSH wel vanaf een untrusted netwerk kan connecten, en bij een niet versleutelde telnet verbinding je maar erop moet vertrouwen dat je verkeer niet verkeerd beland.
Dan missen we nog even het stukje dat je met telnet geen enkele verificatie heb of de bak waar je naar connect ook wel werkelijk de bak is waar je naar wil connecten.
Er zijn wel telnetd's die dit probleem al geruime tijd verholpen hebben.Citaat:
Origineel geplaatst door MikeN
Telnetd is een zeer oude applicatie, welke veel te veel werkzaamheden als root uitvoert, iets wat in het verleden al aardig wat ernstige lekken tot gevolg heeft gehad.
Buitendat is er geen wezenlijk security verschil tussen het runnen van welk soorig daemon dan ook.
Security aspecten komen meer kijken bij de authenticatie procedures en de code danwel de functies van een daemon.
Of een ding nou in plaintxt communiceert of encrypted doet hier niet aan af.
Een httpd op jouw server is toch ook niet direct _de_ bottleneck qua security ?
Wie zegt dat jij je rootpass verstuurd ?Citaat:
Origineel geplaatst door MikeN
En misschien haal ik m'n mail niet op via telnet, maar ik verstuur er wel het root wachtwoord overheen van de server waar m'n mail op staat, what's the difference.
Authenticatie kan op tig aantal andere manieren.
Werken met wachtwoorden is nogal veroudert en ook weinig respectabel, iets wat door banken gelukkig ook erkent wordt.
Overigens prefereer ik persoonlijk het werken met sudo.
Raad ik je overigens wel eens te gaan lezen over hardening van je Linux systeem, omdat anders sudo nog wel eens een probleem op zich zou kunnen worden.
Whow... dan kunnen ze sniffen hoe je je nieuwe Apache httpd compiled.Citaat:
Origineel geplaatst door MikeN
Jup, je kan hem uiteraard ook gewoon firewallen op IP e.d., maar het idee blijft hetzelfde, namelijk dat je via SSH wel vanaf een untrusted netwerk kan connecten, en bij een niet versleutelde telnet verbinding je maar erop moet vertrouwen dat je verkeer niet verkeerd beland.
Neej, dat soort bedrijfsgeheimen houd je inderdaad liever voor jezelf. ;)
Verificatie depends uiteraard helemaal op hoe je het een en ander implementeerd.Citaat:
Origineel geplaatst door MikeN
Dan missen we nog even het stukje dat je met telnet geen enkele verificatie heb of de bak waar je naar connect ook wel werkelijk de bak is waar je naar wil connecten.
Misschien een stomme opmerking maar waarom moet linux zo lastig zijn. Als het net als windows (firedeamon opstarten, servertje erin adden en klaar) clickable was dan had je toch ook geen last van al die vervelende commands. Het msdos tijdperk is toch voorbij. Ik heb trouwens (wil geen discussie aangaan) slechtere ervaring met linux bakken dan met windows bakken.
Wellicht dat je hier beter een apart topic voor aan kunt maken.Citaat:
Origineel geplaatst door RebornVampie
Misschien een stomme opmerking maar waarom moet linux zo lastig zijn. Als het net als windows (firedeamon opstarten, servertje erin adden en klaar) clickable was dan had je toch ook geen last van al die vervelende commands. Het msdos tijdperk is toch voorbij. Ik heb trouwens (wil geen discussie aangaan) slechtere ervaring met linux bakken dan met windows bakken.
Allereerst is Linux niet moeilijker of lastiger als Windows.
De meeste Linux distributies houden zich aan de Filesystem Hierarchy Standard waarmee Unixes, Linux en BSD distributies en eventueel andere systemen die deze standaard adopteren, een universeel filesystem krijgen.
Data zal altijd op dezelfde plekken verkrijgbaar zijn, ongeacht het systeem.
Hierbij wordt ook weer een strikt onderscheid gemaakt in het soort data.
Vooral bij het maintainen van meerdere systemen is dit erg welkom.
Verder is iets textbased of middels een GUI doen niet hetverschil tussen moeilijk en makkelijk.
Dit is enkel de gebruikerservaring.
Wanneer deze bij jou met "grafisch" te beinvloeden valt raad ik jou aan eens te rade gaan bij jezelf.
Of iets clickable is of met commando's gedaan moet worden maakt uiteindelijk weinig uit.
We weten waar de programma's staan door de FHS, deze staat in het PATH van te doorzoeken directories en we weten hoe het programma heet.
Met een GUI heb je exact hetzelfde.. daarbij moet je ook weten hoe het programma heet.
Als Linux op de commandline een tekstverwerker zal hebben met de naam word, zal die prolly ook gewoon met het commando "word" aan te roepen zijn.
Indien we gelijk het document aan willen roepen vanuit dezelfde directory zou "word filename" in zo'n geval genoeg zijn.
In het geval van Windows zal er echter weer geklikt moeten worden.. lekker makkelijk.
Goh, je moet weten welke tekstverwerker geinstalleerd is.
Maaruhm.. is dat in Windows ook niet het geval ?
Om nog verder in te gaan op Linux vs. Windows.
Windows is qua opzet inferieur aan Linux.
Allereerst is bij Windows in beginsel te weinig rekening gehouden mbt. multiuser, wat bij Linux van meet af aan al gedaan is.
Verder depends Windows erg veel op RPC's wat erg opmerkelijk is, en waarvoor Microsoft tot op heden ook nog geen fatsoenlijke verklaring heeft kunnen geven.
Feit is ook dat daar de meeste problemen vandaan komen.
De doemdenkers onder ons zullen waarschijnlijk denken aan spionage danwel remote takeover doelen. ;)
Tja.. en Windows is ook nog eens een bijhoorlijke waste of resources op een serversysteem, als je het mij vraagt.
Overigens zeg ik op dit punt niet dat Windows qua werking inferieur is aan Linux, of BSD.
Het kan natuurlijk zijn dat de Linux en BSD kernels hevig inferieur zijn aan de Windows en meer slechte en vulnerable code bevatten als die van de Windows kernel.
Kan uiteraard ook zijn dat Microsoft dingen kan, die de Linux en BSD coders niet voor mogelijk hielden.
Alhoewel ik het persoonlijk maar even bij mn Linux systeem houd.
Ik had het hier over de standaard netkit telnetd die je normaal gesproken krijgt wanneer je telnetd installed, er zullen inderdaad wel veiligere telnetd's zijn :)Citaat:
Origineel geplaatst door M-BahZ
Er zijn wel telnetd's die dit probleem al geruime tijd verholpen hebben.
Raad ik je wel aan dat erbij te zeggen voordat je in het topic van iemand die duidelijk nieuw is met Linux gaat roepen dat hij ook telnetd kan gebruiken.Citaat:
Wie zegt dat jij je rootpass verstuurd ?
Authenticatie kan op tig aantal andere manieren.
Er gaan bij mij over sommige SSH sessies echt wel gegevens die ik niet overal zou willen laten rondslingeren. Maar dat hangt er maar net vanaf waar je je SSH voor gebruikt.Citaat:
Whow... dan kunnen ze sniffen hoe je je nieuwe Apache httpd compiled.
Vertel eens hoe je het zou implementeren met telnet, ben wel benieuwd eigenlijk :)Citaat:
Verificatie depends uiteraard helemaal op hoe je het een en ander implementeerd.
En RebornVampie, ieder OS heeft zn sterke en zwakke punten. Ik ga op de meeste punten wel met M-BahZ mee wanneer het gaat om beheer, maar vindt het design van Windows niet op alle punten inferieur aan dat van Linux. Als jij beter met Windows om kan gaan, en je kan daarop doen wat je wil, doe het dan daar gewoon op :)
Inderdaad.Citaat:
Origineel geplaatst door MikeN
Ik had het hier over de standaard netkit telnetd die je normaal gesproken krijgt wanneer je telnetd installed, er zullen inderdaad wel veiligere telnetd's zijn :)
Ik denk persoonlijk dat er meer zinnige telnetd's zijn als sshd's.
De meesten zijn ook niet vatbaar of vatbaar geweest voor de problemen die de SSHd's kennen (danwel gan kennen) of gekent hebben. ;)
Ja en nee.Citaat:
Origineel geplaatst door MikeN
Raad ik je wel aan dat erbij te zeggen voordat je in het topic van iemand die duidelijk nieuw is met Linux gaat roepen dat hij ook telnetd kan gebruiken.
Aangezien telnet in zijn oorspronkelijke vorm gewoon plaintext gebruikt zou het misschien voor de handliggend zijn hier nogmaals op te wijzen...
Aan de andere kant is het tot op zekere hoogte nutteloos om dit te melden.
We hoeven mensen toch ook niet uit te leggen dat de kernels op kernel.org vulnerable zijn, en mensen die dingen nog moeten patchen ? ;)
Correct.Citaat:
Origineel geplaatst door MikeN
Er gaan bij mij over sommige SSH sessies echt wel gegevens die ik niet overal zou willen laten rondslingeren. Maar dat hangt er maar net vanaf waar je je SSH voor gebruikt.
Doorgaans gebruiken de meesten SSH en telnet alleen voor system maintance.
Men wordt geacht de security aspecten hiervan te kennen.
Zaken als mail en dergelijke is een implementatie op zich en het is dan ook zaak dat mensen zelf hierbij overdenken hoe het een en ander aan te pakken.
Ik zal hier even een erg kort door de bocht zijnde antwoord opgeven. ;)Citaat:
Origineel geplaatst door MikeN
Vertel eens hoe je het zou implementeren met telnet, ben wel benieuwd eigenlijk :)
Een "authentication protocol" valt doorgaans met veel soorten daemons te implementeren.
Alhoewel de keuzes voor deze implementaties vaak weinig origineel zijn. ;)
Een afdoende identificatie van client/server middels keys is overigens wel gewoon mogelijk.
Een korte zoektocht op google zal je ook gelijk bruikbare alternatieven bieden.
Echter liet ik al reeds wat vallen over het niet hoeven te gebruiken van een rootpass, maar natuurlijk is sudo ook niet heilig.
Immers moet je alsnog inloggen op je systeem, en of je dat nu doet met een account welke sudo kan gebruiken of met root zelf maakt weinig verschil.
Het toverwoord hiervoor is echter "One time passwords".
De implementatie hiervan is nog niet bij iedereen bekend, maar google levert je een schat aan informatie hierover.
One time psswords laat zich in grote lijnen vergelijken met de TAN codes zoals gebruikt door de Postbank.
In principe raad ik iedereen aan een implementatie hiervan ook zeker te overwegen.
Met name voor ftp en telnet (en in mindere mate ssh) zal dit zeker wel een toegevoegde waarde kennen.
Kort samengevat leent telnet zich prima voor proffesionele toepassingen.
De meeste punten waarop SSH beter zou zijn kunnen relatief makkelijk weerlegt worden.
Verder rammelt het dusdanig vaak aan de SSH implementaties, dat ik niet lukraak SSH zal aanraden. ;)
Edit: de volgende link bevat al een beetje informatie. ;)
http://www.evilcoder.org/freebsd_htm...passwords.html
Is op zich een punt, encryptie zooi = meer code = meer kans op fouten :)Citaat:
Origineel geplaatst door M-BahZ
De meesten zijn ook niet vatbaar of vatbaar geweest voor de problemen die de SSHd's kennen (danwel gan kennen) of gekent hebben. ;)
2.6.11 is pas uit :pCitaat:
We hoeven mensen toch ook niet uit te leggen dat de kernels op kernel.org vulnerable zijn, en mensen die dingen nog moeten patchen ? ;)
Maar ik ben sowieso niet echt blij met het security beleid zoals dat op dit moment door de Linux kernel maintainers gevoerd wordt. Toevallig kwam ik een tijdje terug deze column tegen, welke op zichwel een paar goede punten heeft http://www.securityfocus.com/columnists/296
Maar we dwalen af :p
Tja, die kon ik dus niet zo snel in combinatie met telnet vinden, maar ze zullen er dus wel zijn :)Citaat:
Een afdoende identificatie van client/server middels keys is overigens wel gewoon mogelijk.
Een korte zoektocht op google zal je ook gelijk bruikbare alternatieven bieden.
Dat is mijns inziens ook een groot "probleem" aan sudo. Afgezien van het feit dat m'n huidige productieomgeving nog steeds aan veel veranderingen onderhevig is, en ik dus vaak genoeg echt een rootshell nodig heb. sudo kan echter handig zijn voor sommige (veel?) dagelijkse admin taken.Citaat:
Echter liet ik al reeds wat vallen over het niet hoeven te gebruiken van een rootpass, maar natuurlijk is sudo ook niet heilig.
Immers moet je alsnog inloggen op je systeem, en of je dat nu doet met een account welke sudo kan gebruiken of met root zelf maakt weinig verschil.
Ik dacht al dat het daarop zou uitkomen. One time passwords vindt ik aan de ene kant een goed idee, aan de andere kant moet ik altijd een lijst meeslepen (of iedere dag een nieuw lijstje in mn kop stampen ;)) wat ik gewoonweg niet handig vind. Uiteindelijk vindt ik dat je altijd een afweging moet maken tussen security en usability, welke bij mij iets meer richting de usability is gegaan. Dat het voor plaintext protocollen een grote toegevoegde waarde heeft (soms zelfs noodzakelijk) heb je volledig gelijk in.Citaat:
Het toverwoord hiervoor is echter "One time passwords".
De implementatie hiervan is nog niet bij iedereen bekend, maar google levert je een schat aan informatie hierover.
Ach, de laatste tijd is het weer rustig (*klopt af*) :DCitaat:
Verder rammelt het dusdanig vaak aan de SSH implementaties, dat ik niet lukraak SSH zal aanraden. ;)
Helaas _teveel_ fouten als je het mij vraagt. ;)Citaat:
Origineel geplaatst door MikeN
Is op zich een punt, encryptie zooi = meer code = meer kans op fouten :)
Het huidige beleid is inderdaad een punt van discussie.Citaat:
Origineel geplaatst door MikeN
2.6.11 is pas uit :p
Maar ik ben sowieso niet echt blij met het security beleid zoals dat op dit moment door de Linux kernel maintainers gevoerd wordt. Toevallig kwam ik een tijdje terug deze column tegen, welke op zichwel een paar goede punten heeft http://www.securityfocus.com/columnists/296
Maar we dwalen af :p
Overigens is hetzelf gaande bij de maintainers van andere projecten.
Gelukkig zijn er een aantal goede patchsets welke doen, wat volgens velen, de kernel maintainers hadden moeten doen.
Een aantal patchsets zijn ook uiterst experimenteel, en brengen op hun beurt weer stabiliteits en security problemen met zich mee.
In de toekomst zal het denk wellicht nog wel positief kunnen zijn voor de algehele ontwikkeling van de Linux kernel.
Maar ik denk dat het op dit moment voornamelijk een barriere opwerpt.
Verder was een announcement op kernel.org aangaande wijzigingen in het beleid bij de kernel maintainers wel op z'n plaats geweest.
Veel systeembeheerders werken namelijk al jaren volgens een vastgeroest patroon.
Ik vermoed dat een zoektocht op "secure telnet" of iets als dat wel wat hits oplevert.Citaat:
Origineel geplaatst door MikeN
Tja, die kon ik dus niet zo snel in combinatie met telnet vinden, maar ze zullen er dus wel zijn :)
Voor de meeste taken zal sudo inderdaad zondermeer voldoen.Citaat:
Origineel geplaatst door MikeN
Dat is mijns inziens ook een groot "probleem" aan sudo. Afgezien van het feit dat m'n huidige productieomgeving nog steeds aan veel veranderingen onderhevig is, en ik dus vaak genoeg echt een rootshell nodig heb. sudo kan echter handig zijn voor sommige (veel?) dagelijkse admin taken.
Verder zorgt sudo bij de meeste mensen wellicht ook voor een stukje bewustwording van het multiuser gebeuren in Linux en security in het algemeen.
Overigens geheel terzijde sta je sudo natuurlijk niet aan alle gebruikers van het systeem toe, maar enkel aan een bepaalde group.
Dit had jij al door denk ik, maar wellicht even interessant voor de mensen die meelezen. ;)
Ik denk dat one time passwords voor communicatie in plaintext de enige deftige methode is, waar security vereist is.Citaat:
Origineel geplaatst door MikeN
Ik dacht al dat het daarop zou uitkomen. One time passwords vindt ik aan de ene kant een goed idee, aan de andere kant moet ik altijd een lijst meeslepen (of iedere dag een nieuw lijstje in mn kop stampen ;)) wat ik gewoonweg niet handig vind. Uiteindelijk vindt ik dat je altijd een afweging moet maken tussen security en usability, welke bij mij iets meer richting de usability is gegaan. Dat het voor plaintext protocollen een grote toegevoegde waarde heeft (soms zelfs noodzakelijk) heb je volledig gelijk in.
Als je wat shellaccountjes host voor klanten alszijnde een shellhost maakt het natuurlijk niets uit of zo'n accountje een keer gekraakt wordt.
Immers ga je er als host toch wel vanuit dat de halve wereld toegang heeft tot je servers, omdat jij niet in kunt staan voor wat je gebruikers aan logingegevens laten lekken, of vulnerable webscripting hebben. ;)
Maar voor bijvoorbeeld FTP zie ik persoonlijk weinig goede alternatieven als je op safe wilt spelen.
Ik denk dat je voornamelijk bij bedrijven een groot aanzien zult genieten wanneer je gebruik zult maken van one time passwords.
Tuurlijk usability speelt ook een rol, maar voor je eigen accounts kan je eventueel besluiten geen one time passwords toe te passen.
Beter is het misschien gewoon een keertje opnieuw in te loggen.
Als je echt de hele dag door op het systeem aan het werk bent kan je natuurlijk gewoon ingelogt blijven.
Uiteraard lock je dan wel even de terminal, als je de pc verlaat. ;)
Stilte voor de storm ? ;)Citaat:
Origineel geplaatst door MikeN
Ach, de laatste tijd is het weer rustig (*klopt af*) :D
Probleem is overigens ook dat veel zaken nog altijd niet geraporteerd worden.
Wat wel vaker gebeurt met security related issue's.
Wie doet jou wat als jij je systeem met GPL software binnen je bedrijf volledig patcht en verder wijzigingen niet doorspeelt naar de community.
Schade lijd de community immers niet, door jouw toedoen...
Je breekt met de GPL licentie en mag het product eigenlijk niet installeren.
Maar wat als je het vervolgens wel installeerd... ze kunnen (helaas) niets beginnen.
Het is natuurlijk bij opensource wel snel zo dat je snel de concurrent op weg helpt door te doneren... ;)
Je breekt niet eens met de GPL licentie, zolang je het product binnen je bedrijf houdt :) De GPL zegt tenslotte alleen wat over de distributie van broncode/programma's en niet over het gebruik.
Maar het feit dat er security bugs zijn die niet gerapporteerd worden blijf je altijd houden. Er zijn zelfs vendors die er bewust voor kiezen security problemen niet te fixen of te melden, of ze wel te fixen, maar niet te melden. Een spijtige zaak, maar wat doe je eraan (behalve een andere vendor zoeken natuurlijk ;) )