security -> shell account en shadow-file

[anoniem]

Hallo, Ik ben nu al een tijdje bezig met linux op een servertje. Daarbij maak ik danbaar gebruik van ssh, maar nu heb ik een vraag omtrend de beveiliging. De paswordfile word 'geshadowd' in een shadow file. Deze kan als het goed is alleen door de root worden gelezen toch ? Een gast gebruiker met shellacces kan deze niet achterhalen toch ? Ik overweeg om anderen (tijdelijk) gebruik te laten maken van mijn systeempje voor webhosting... Nu wil ik natuurlijk niet dat (onbedoeld) iemand met de shadow file aan de haal gaat.

[anoniem]

Overtuig jezelf..... kijk naar de permissies op dat bestand :D Je moet ze niet root maken uiteraard ;)

[anoniem]

Nee dat bedoel ik, alleen de root kan aan het bestand komen. Je hoeft dus verder geen extra voorzorgmaatregelen te treffen ? Het shadow-file een andere naam geven b.v. ? Je weet maar nooit, want het is de bedoeling dat enkele kennissen tijdelijk websites (met php) gaan draaien. Nu kan ik niet 24/7 controleren of dat goed gaat... Oké...bedankt i.i.g., ik zal eens gaan zoeken naar de mogelijkheden voor het veilig maken van mij boxje :D Zal eens met grsecurity gaan spelen (eerst op een andere pc natuurlijk).

[anoniem]

Ik zou de gebruikers zoiezo niet de mogelijkheid geven om over ssh in te loggen. Dat is namelijk nergens voor nodig en geeft hen alleen maar extra mogelijkheden op de machine. Maak liever accounts aan die als shell /dev/null hebben en laat ze de website via (s)ftp beheren.

[anoniem]

[quote:da4124b365="Marcel de Reus"]Ik zou de gebruikers zoiezo niet de mogelijkheid geven om over ssh in te loggen. Dat is namelijk nergens voor nodig en geeft hen alleen maar extra mogelijkheden op de machine. Maak liever accounts aan die als shell /dev/null hebben en laat ze de website via (s)ftp beheren.[/quote:da4124b365] Is /dev/null als shell veiliger dan geen shell?

[anoniem]

/dev/null is ongeveer vergelijkbaar als noshell of /bin/false noshell kun je overiigens zelf maken (banner bestandje in /etc mikken en deze toevoegen aan /etc/shells

[anoniem]

Je bent toch niet verplicht een shell op te geven als je een user aanmaakt? Of wel?

[anoniem]

Dus de gebruikers die je op het systeem toelaat ken je in een aparte groep plaatsen, zonder shell toegang ? Net zoals bv apche (en dergelijke programma's) doet ? Dat is een 'gebruiker' met een eigen groep, maar je kunt er niet mee inloggen...toch ? Hoe kan ik bestaande gebruikers hun shellaccess ontnemen ?

[anoniem]

Door hun huidige shell, ws /bin/bash te veranderen naar /dev/null of /bin/false in /etc/passwd.

[anoniem]

[quote:9b4dd3370a="bvvelde"] Je hoeft dus verder geen extra voorzorgmaatregelen te treffen ? Het shadow-file een andere naam geven b.v. ? [/quote:9b4dd3370a] Security through obscurity is niet de oplossing. Met een simpele grep zou je nog steeds die hernoemde shadow file kunnen vinden. Laat permissies gewoon het werk doen, niemand anders kan het lezen. Daar komt bij dat vrijwel alle distributies de wachtwoorden hashen (bijv. met MD5). Zelfs als iemand de shadow file heeft kunnen krijgen door onveiligheid heeft hij/zij alleen de hashes, niet de wachtwoorden. Aangezien een wachtwoord eerst vaak geXORed wordt met wat "salt", zal de hash weer anders zijn na het opnieuw "aanmaken" van de wachtwoorden met passwd.

[anoniem]

Wordt een passwd file met elke boot opnieuw gegenereerd ? Dat wist ik niet... Salt dat is een random getal dat het aantal mogelijke hashes naar 4096 mogellijkheden uitbereid en zorgt voor meer veiligheid. Zoals danieldk schreef wordt het ' geXORed' , dat betekend dat het wachtwoord met een random getal (het salt) wordt ge-exclusive-ord. De hash is dus niet een hash van het wachtwoord, maar een hash van het product van de exclusive-or operatie. Dus zonder de salt waarde op het moment dat die passwd file is geript hebben ze er nog zo goed als niets aan. Goh, weer wat geleerd :D. Ik wist niet dat bij elke boot de passwd file opnieuw werd gemaakt...op zich best wel logisch nu ik er zo aan denk.

[anoniem]

Fout! De salt waarde staat in de password file. Dat is het leuke [b:91de1903d4]met[/b:91de1903d4] salt waarde heb je er niets aan. Aangezien het wachtwoord wordt geXORed met de salt voor de one-way hash. Het zou niet best zijn als de salt niet in het shadow bestand staat, anders zou je een wachtwoord simpelweg niet kunnen controleren. Bovendien heeft het weinig met mogelijkheden te maken. Het aantal mogelijkheden van de hash is nl. gelijk aan de lengte van de hash (afgezien van zwakheden in hashes, waardoor niet de volledig mogelijke ruimte gebruikt wordt).

[anoniem]

Oh zo, ik vond het al een beetje vreemd ;) Ja, zo kan het natuurlijk ook. Door jouw uitspraak : [quote:b719cf80b2]"Aangezien een wachtwoord eerst vaak geXORed wordt met wat "salt", zal de hash weer [b:b719cf80b2]anders zijn na het opnieuw "aanmaken"[/b:b719cf80b2] van de wachtwoorden met passwd."[/quote:b719cf80b2] Daarom dacht ik dat bij elke boot de passwords opnieuw werden gemaakt m.b.v. een random 'salt' waarde op dat moment. Maar zoals je het nu zegt klinkt het idd logischer. Had het even verkeerd geïnterperteerd dus :oops: . Ik had het zelf ook ff gechecked thuis en daar bleef de shadow file gewoon hetzelfde aan voor de reboot dus...twijfelde ik zelf ook al aan mijn aaname... Best wel goed bedacht dat shadow systeem, maar is het niet gek dat de salt-waarde bij het shadow-file in staat ? Ik zie die salt-waarde trouwens niet staan in de shadow-file...

[anoniem]

Hoe wou je de salt anders opslaan? Het is nodig bij de verificatie van een wachtwoord. Maar het is geen probleem, aangezien het wachtwoord geXORed wordt met de salt voor de hash. De hash is one-way, dus het is niet mogelijk in combinatie met de salt iets met de hash te doen. Schematisch ziet het er als volgt uit: Wachtwoord XOR Salt <==> "SaltedWachtwoord" OneWayHash("SaltedWachtwoord") ==> Hash Aangezien er geen mogelijkheid meer is van hash naar saltedwachtwoord, en XOR niets anders is dan bits flippen. Heb je dus weinig aan Salt + Hash. De salt zie je inderdaad niet in shadow, omdat het gewoon in het wachtwoordveld opgenomen is. Vaak is het wachtwoord veld een samenvoeging van <gebruikte cipher/one way hash><salt><hashed wachtwoord>.

[anoniem]

Als het zo wordt opgeslagen, is dan het salt niet gewoon 'plain' ? <gebruikte cipher/one way hash><salt><hashed wachtwoord>. Want wanneer je het wachtwoord van een user op waarheid moet controleren, dan moet deze dus worden ge-x-ord met het salt en vervolgens gehashed. Het produkt van deze hash moet gelijk zijn aan de hash die is opgeslagen in het shadow file. Dus moet op de een of andere mannier de oorspronkelijke salt waarde tevoorschijn worden getoverd, hoe doen ze dat ?

[anoniem]

[quote:bbcf9fca59="yohanman"]Als het zo wordt opgeslagen, is dan het salt niet gewoon 'plain' ?[/quote:bbcf9fca59] ? [quote:bbcf9fca59] Want wanneer je het wachtwoord van een user op waarheid moet controleren, dan moet deze dus worden ge-x-ord met het salt en vervolgens gehashed. Het produkt van deze hash moet gelijk zijn aan de hash die is opgeslagen in het shadow file. [/quote:bbcf9fca59] Yep, you got it. [quote:bbcf9fca59]Dus moet op de een of andere mannier de oorspronkelijke salt waarde tevoorschijn worden getoverd, hoe doen ze dat ?[/quote:bbcf9fca59] Die staat in de passwd string in /etc/shadow.

[anoniem]

Maar hoe wordt hij dan opgeslagen ? Toch niet ge-X-ord met een salt-waarde mag ik hopen ;) Kijk dat is mijn punt, het wordt vast wel geencrypt, maar het moet wel zijn terug te halen naar zijn oorspronkelijke waarde, want anders kun je de salt niet gebruiken om user passwords te controleren. m.a.w. het salt wordt niet met behulp van one-way-encryptie opgeslagen (hash) of wel ?

[anoniem]

Jawel, one-way encryptie. Voor zover ik weet wordt het wachtwoord dat je opgeeft bij het inloggen met dezelfde salt geencrypt en vergeleken met wat er in de shadow-file staat. Vandaar dat John the Ripper er vaak ook zo lang over doet om wachtwoorden te vinden: op elke combinatie wordt encryptie toegepast en de uitkomst wordt vergeleken met de oorspronkelijke hash. -Roeland

[anoniem]

Ik snap het ook nog niet helemaal: wachtwoord wordt ingetoetst (=plain), als nu het Salt versleuteld is, hoe weet dan het programma dat het inloggen verwerkt (is dat pam?), wat het salt is? Of zitten de karakters van het Salt plain tussen de andere karakters in /etc/shadow?

[anoniem]

Ja, de salt staat er onversleuteld tussen. Dus in de string heb je de "plain" salt en de hashed wachtwoord. Als een wachtwoord gecontroleerd moet worden, wordt het ingevoerde wachtwoord dus eerst geXORed met het salt, en vervolgens gehashed met een one-way hash. Als de resulterende hash gelijk is aan die in /etc/shadow klopt het wachtwoord.