Gevaar van een Knoppix cd en een linux systeem

[deepbass909]

Onlangs was ik bij een vriend van mij met een servertje bezig om daar Gentoo op te zetten. Omdat het al laat was, en die machine nogal traag (een Dual Pentium 200 MMX), besloten we te stoppen. Het gevolg was dat toen we weer tijd hadden, we beide geen flauw idee hadden van wat het root-password ook al weer was.
Omdat Gentoo opnieuw erop zetten (dus het uitpakken van de Stage3, distfiles en het compileren en configureren van het systeem) al gauw een avond werk was op die machine, bedachten we een andere strategie, namelijk booten met knoppix en kijken wat we dan allemaal konden bereiken.

Zo gezegt, zo gedaan.

Knoppix gestart, en naar een tekst-terminal gegaan (kde schoot op die machine niet echt op namelijk).

Ik herinnerde mij een opmerking uit de Gentoo install manual, over CHROOT, namelijk dat je dan overstapt in je nieuwe opgeving. Dus wij proberen of dat ook wou vanuit Knoppix naar een reeds geïnstalleerde omgeving, met een wachtwoord voor de root gebruiker.

Dus eerst zorgen dat we root waren onder knoppix, maar dat was makkelijk, gewoon su uitvoeren op de commandline,
vervolgens chroot /mnt/hda3/ /bin/bash om in de gentoo omgeving te komen.

En tot ons verbazing (en een beetje geschrokken eigenlijk), zaten we als root in de Gentoo omgeving, en konden we met passwd zo het root password veranderen, zonder verdere controlles.

Kortom, dat betekend dus dat als ik kan booten vanaf een cd, ik mezelf volledige toegang tot een systeem kan geven, door simpelweg een gebruiker te creëren met root permissies, of simpelweg het root wachtwoord veranderen.

Konden wij dit doordat we ergens een beveiliging open hadden staan, of is dit serieus een beveiligings lek?

[mocean]

Volgens mij is een linux systeem áltijd makkelijk over te nemen als je fysieke toegang hebt. Dat geld trouwens ook voor windows systemen.

Wat je kan doen, is CD-boot uitzetten en password op de bios, maar ja, als je fysieke toegang hebt trek je ook zo de harde schijf eruit.

[Rukapul]

deepbass909 schreef op zondag 20 maart 2005 @ 21:08:
Konden wij dit doordat we ergens een beveiliging open hadden staan, of is dit serieus een beveiligings lek?

Je kunt het evt. een beveiligingslek noemen, maar je kunt het beter omschrijven dat het threat model van computers / operating systems er op dit moment vanuit gaat dat een aanvaller geen fysieke toegang heeft tot de machine. Bedenk ook maar eens hoe voorkomen zou moeten worden dat een oud account/wachtwoord overschreven kan worden. Het is immers slechts een stuk informatie op disk, database of ergens anders.
Uiteraard is dit wel te verbeteren door encrypted file systems ed. te gebruiken zodat tenminste opgeslagen data niet toegankelijk is.

Onder windows werken soortgelijke methodes overigens uitstekend om data van NTFS partities te halen waarvoor de rechten onvoldoende zijn

[SyS_ErroR]

deepbass909, op zich erg apart dat dit op deze manier zo lukt.. niet echt wat je qua beveiliging verwacht van Gentoo (of welke *nix versie dan ook)

Maar idd, als je fysieke toegang hebt is het een stuk makkelijker...

[RedLizard]

SyS_ErroR schreef op zondag 20 maart 2005 @ 21:15:
deepbass909, op zich erg apart dat dit op deze manier zo lukt.. niet echt wat je qua beveiliging verwacht van Gentoo (of welke *nix versie dan ook)

Maar idd, als je fysieke toegang hebt is het een stuk makkelijker...

De beveiliging van gentoo heeft hier niks mee te maken. Gentoo was namelijk niet actief, en beveiligingen werken (uiteraard) alleen als ze actief zijn.

Het is heel simpel: als je fysieke toegang hebt tot een machine, kun je er alles mee doen wat je wilt, en is iedere verdere beveiliging zinloos.

[CyBeR]

Fysiek toegang tot systeem == r00tbare box. Zo is 't eigenlijk altijd, tenzij je een encrypted filesystem gebruikt. Geen beveiligingslek dus, maar meer iets wat gewoon niet te voorkomen is zonder je hele hdd te encrypten.

[deepbass909]

Wat ik dus alleen een beetje eng vind is dat je zonder problemen een chroot kan doen, zonder dat er blijkbaar gecheckt wordt of de gebruiker root op het betreffende systeem een wachtwoord heeft of niet. Dat lijkt mij om eerlijk te zijn niet de grootste uitdaging.

Ik weet ook wel dat fysieke toegang inbreken een stuk makkelijker maakt, maar ik vond dit te makkelijk, helemaal omdat ik wat Linux betreft nog echt een noob ben...

Ik weet dat ik bij mij op de universiteit in bepaalde zalen gewoon met cd kan opstarten, als ik dat zou willen, waarschijnlijk omdat de beheerders zich ook niet bewust zijn van een dergelijk risico.

Daarnaast snap ik nu wel ineens een stuk beter waarom mijn IBM ServeRAID een deur met slot voor al z'n drive's heeft zitten. Helaas heb ik daar de sleutel niet meer van.

[Verwijderd]

deepbass909 schreef op zondag 20 maart 2005 @ 21:46:
Wat ik dus alleen een beetje eng vind is dat je zonder problemen een chroot kan doen, zonder dat er blijkbaar gecheckt wordt of de gebruiker root op het betreffende systeem een wachtwoord heeft of niet. Dat lijkt mij om eerlijk te zijn niet de grootste uitdaging.

Ik weet ook wel dat fysieke toegang inbreken een stuk makkelijker maakt, maar ik vond dit te makkelijk, helemaal omdat ik wat Linux betreft nog echt een noob ben...

Ik weet dat ik bij mij op de universiteit in bepaalde zalen gewoon met cd kan opstarten, als ik dat zou willen, waarschijnlijk omdat de beheerders zich ook niet bewust zijn van een dergelijk risico.

Daarnaast snap ik nu wel ineens een stuk beter waarom mijn IBM ServeRAID een deur met slot voor al z'n drive's heeft zitten. Helaas heb ik daar de sleutel niet meer van.

Je kan altijd nog een BIOS wachtwoord erop zetten of je hele HD encrypten, met windows gaat dat laatste niet. Zo ver ik weet kan je elk besturingssysteem makkelijk aan de admin-rechten komen. Voor windows kan je met een linuxcd booten en wachtwoorden gewoon wijzigen.

De rechten worden beheerd door knoppix als je ermee boot en dan de hd benaderd en niet door gentoo. Hetzelfde heb je als je een ntfs schijf van de ene pc in de andere gooit, dan kan je er ook alles mee behalve delen die encrypted zijn.

Je moet je dit afvragen: Als er gecontroleerd moest worden bij chrooten wat zou er dan gecontrolleerd moeten worden?

[deepbass909]

Ik ken Linux helaas nog te slecht om direct te locatie op te kunnen dreunen, maar of die locatie relatief (dus een vergelijkbare mappen-boom) bestaat, en of er op die locatie een PAM of ander wachtwoorden bestand is. Ik ga er daarbij vanuit dat het root wachtwoord altijd lokaal is opgeslagen.

Deze moet volgens mij ook door knoppix te gebruiken zijn om wachtwoord beperking op te leggen aan de gebruiker die probeert in te loggen als root.

Of is dit te simpel gedacht?

[_JGC_]

Mja, je moet chroot eigenlijk meer zien als iets waar je in stapt als subsysteem van je huidige systeem. Stel, je kernel:
- ding start met uid 0 en mount je rootfs aan
- ding start init welke de nodige services start
- init start getty en misschien een sshd, waarop jij mag inloggen.

Zou jij het handig vinden als voor elke boot van die machine aan de kernel gevraagd wordt om een wachtwoord? Je stapt met UID 0 die chroot binnen, en dus ben je root en mag je alles doen.

Verder kan je nog veel makkelijker inbreken op een systeem:
je pakt de bootloader, onderbreekt em en pakt commandline, vervolgens gooi je achter de bootloader commandline iets als "init=/bin/bash". Je bak boot met die opties, en ipv /sbin/init pakt de kernel dan /bin/bash en heb je een rootshell te pakken meteen nadat de kernel het rootfs heeft gemount.

Fysieke toegang betekent nou eenmaal onveilig. Bovenstaande lukt je met een windows bak, met een linux bak, etc. Enige wat je ertegen kunt doen is de hele disk encrypten, zodat een knoppix bootcd niet weet welke key er nodig is om de hdd te kunnen mounten. Encrypted rootfs is niet mogelijk, maar je kunt dus wel met chroot methode vanaf unencrypted rootfs starten, dan om key vragen, de encrypted partitie mounten en dan erin chrooten.

[Gondor]

_JGC_ schreef op zondag 20 maart 2005 @ 23:02:
...
Verder kan je nog veel makkelijker inbreken op een systeem:
je pakt de bootloader, onderbreekt em en pakt commandline, vervolgens gooi je achter de bootloader commandline iets als "init=/bin/bash". Je bak boot met die opties, en ipv /sbin/init pakt de kernel dan /bin/bash en heb je een rootshell te pakken meteen nadat de kernel het rootfs heeft gemount.
...

Volgens mij voorkom je dit door een wachtwoord op je bootloader te zetten.

Wachtwoord op je bootloader en bios. Geen cd of floppy aansluiten en ook geen entry hiervoor in je fstab. Zijn paar dingen wat als eerst bij mij opkomen.

Hiermee en met andere maatregelen kan je het behoorlijk moeilijk maken. Maar zoals eerder gezegd, fysieke toegang is en blijft het grootste risico.

[CyBeR]

't is heel simpel: fysieke toegang == schijf kunnen mounten en files (waaronder passwd file) aan kunnen passen. Als je tooltjes als chroot enzo vervolgens dit soort dingen laat checken ga je richting de Windows-achtige oplossingen die UNIX gebruikers nu juist ontlopen door geen windows te gebruiken.

En dit alles valt te voorkomen door encrypted filesystems te gebruiken of de computer niet fysiek toegankelijk te maken.

[Wilke]

deepbass909 schreef op zondag 20 maart 2005 @ 21:08:
Kortom, dat betekend dus dat als ik kan booten vanaf een cd, ik mezelf volledige toegang tot een systeem kan geven, door simpelweg een gebruiker te creëren met root permissies, of simpelweg het root wachtwoord veranderen.

Inderdaad, maar maak je vooral ook geen illusies dat dat bij willekeurig welk ander OS veel ingewikkelder is. Inderdaad laat de Windows installatie-cd het zelf niet rechtstreeks toe, maar je kunt denk ik in Windows Operating Systems binnen 3 minuten wel vinden hoe je in een systeem komt waarvan je het administrator pass kwijt bent geraakt (als je fysieke toegang hebt).

Konden wij dit doordat we ergens een beveiliging open hadden staan, of is dit serieus een beveiligings lek?

Nee en nee. Dit is gewoon zoals het hoort te zijn (hoe zou je bv. anders uberhaupt in je systeem willen komen als het stuk is, en je geen root-rechten zou hebben zodat je het kunt fixen?). Elke willekeurige computer is heel lastig te beveiligen tegen mensen met fysieke toegang. Je kunt wel wat dingen doen, bv. zorgen dat er gewoon geen CD-ROM drives e.d. in zitten, of dat je er niet van kunt booten (BIOS-setting, en password er op). Maar veel zal het allemaal niet echt helpen. Hetzelfde geldt overigens voor USB devices.

Een encrypted filesystem zou hier trouwens zeker tegen helpen (maar is dus ook dolle pret als je het pwd kwijt raakt).

[M-ThijZ]

_JGC_ schreef op zondag 20 maart 2005 @ 23:02:
Verder kan je nog veel makkelijker inbreken op een systeem:
je pakt de bootloader, onderbreekt em en pakt commandline, vervolgens gooi je achter de bootloader commandline iets als "init=/bin/bash". Je bak boot met die opties, en ipv /sbin/init pakt de kernel dan /bin/bash en heb je een rootshell te pakken meteen nadat de kernel het rootfs heeft gemount.
.

Dat is niet mogelijk wanneer je een aparte /boot partitie hebt of wel? In mijn grub.conf laad hij de kernel en initrd namelijk relatief vanaf /boot.
Eigenlijk is dat dan wel vreselijk kwestbaar, je kunt toch vanalles achter init= plakken. 'init=/bin/bash -c rm -rf /', dat zou wel heel erg lame zijn.

[CyBeR]

M-ThijZ schreef op zondag 20 maart 2005 @ 23:59:
[...]

Dat is niet mogelijk wanneer je een aparte /boot partitie hebt of wel? In mijn grub.conf laad hij de kernel en initrd namelijk relatief vanaf /boot.
Eigenlijk is dat dan wel vreselijk kwestbaar, je kunt toch vanalles achter init= plakken. 'init=/bin/bash -c rm -rf /', dat zou wel heel erg lame zijn.

Op die manier kan 't iig niet (spaties) maar ik weet niet hoe ver je zou komen met quotes enzo. Als 't werkt: mooi. Waarom zou het systeem je tegen je eigen domheid moeten beschermen? En als je dan zeker weet dat je dat wilt doen, houdt het je tegen alsof je dom bent. Klinkt als een OS waar ik niet mee wil werken.

[Wilke]

ik denk niet dat je het init-proces command-line parameters kunt meegeven, maar ik weet het niet zeker eigenlijk Dat zou inderdaad wel wat erg onhandig zijn als het kon.

[_JGC_]

Mocht je het wel voorelkaar krijgen om bash een rm -rf / uit te laten voeren door het ding op te geven als init= parameter, is er nog niets aan de hand: je kernel mount je rootfs altijd readonly, deze moet je met de hand, of met init scripts dus zelf nog r/w mounten

[laurencevde]

rw als kernel param opgeven werkt anders ook goed hoor
dus dan wordt het 'rw init="/bin/bash "rm -rf /"" o.i.d

[Verwijderd]

Nog even afgezien van het feit dat alle OSen bij fysieke toegang tot de machine relatief makkelijk te benaderen zijn of je het password nu wel of niet kan, is het sowieso geen issue. Als je een machine fysiek kunt benaderen en er staat info op die je wilt hebben, kun je die dus ook meenemen en op je gemakje gaan zitten hacken op een plaats van je eigen keuze (thuis voor de buis oid). Een ge-encrypte schijf heeft dan ook beperkt nut. Met voldoende CPU kracht is veel voor elkaar te krijgen, zelfs als alles ge-encrypt is.

Ooit jezelf afgevraagd waarom je (bijv.) in het KPN Cybercenter zo lastig naar binnen komt? Da's dus om te voorkomen dat je zomaar fysieke toegang krijgt tot machines waar je niet bij hoort...

[urk_forever]

Tja, dit kan ik ook met een CIA Commander diskette en een Windows XP/2K/2K3 machine. Dan heb ik ook binnen 2 minuten het Administrator password aangepast.
Dus dit is zo bij alle OS'en.

[deepbass909]

Dat het makkelijkgaat heb ik dus gemerkt, maar ik stond echt even te kijke over het punt dat alle tijd die nodig was, de tijd was die het kost om Knoppix te booten...

Ik had er eigenlijk nooit bij stil gestaan...

@Shoikan, waar jij het nu over hebt, dat is echt data kraken op een schijf, wat ik eigenlijk bemerkte was dat het toekennen van root-rechten op deze manier wel erg makkelijk ging...

[Wilke]

Als je nog wilt weten hoe simpel het in Windows is:

[rml][ 2000] Password kwijt - ntpasswd boot niet*[/rml]

Maakt niet zo veel uit dus, met de juiste CD ben je in elk system binnen 10 seconden binnen. Het is dat Knoppix geen NTFS kan schrijven, want anders had je ook zo de password file van Windows kunnen vervangen (vrijwel net zo makkelijk als in Linux dus, met het verschil dat het in Windows ongetwijfeld een of ander ranzig, onleesbaar binary formaat is, dus dat je iets meer moeite moet doen wellicht)

[smokalot]

Dat ntpasswd is linux

Schrijven naar NTFS kan wel, als je maar de bestandsgrootte niet verandert.

Knoppix zou dus wel de XP-paswoordfile kunnen aanpassen, maar ntpasswd heeft dit hele proces wat geautomatiseerd.

Ik hoop dat een heleboel mensen dit soort topics lezen, ik blijf het frapant vinden dat sommige Windowsgebruikers denken dat ze veilig zijn omdat ze als ze de NT-installatieCD gebruiken ze het Administrator-wachtwoord in moeten tikken. Mijn ervaring met *n?x-gebruikers is dat die veeeel beter snappen wat er eigenlijk gebeurt bij authenticatie.

Overigens heeft BIOS aanpassen ook niet veel zin, CMOS resetten is meestal voldoende. Net zoals het uitzetten van CD-booten dus.

[Verwijderd]

Op sommige distributies kun je zonder het root-wachtwoord in te voeren op runlevel 1 booten en werken. Het eerste dat je dan doet is "passwd" en het systeem is van jou. Heb je geeneens een Knoppix CD oid. voor nodig.

[VROEM!]

Waar je ook aan moet denken is dat het eigenlijk wel een beetje zo moet zijn. Een PC moet in noodgevallen gewoon te "redden" zijn zodat je er weer bij kunt. Op gegeven moment moet je dan maar toelaten dat iemand met fysieke toegang alles kan.

[CyBeR]

Verwijderd schreef op dinsdag 22 maart 2005 @ 23:13:
Op sommige distributies kun je zonder het root-wachtwoord in te voeren op runlevel 1 booten en werken. Het eerste dat je dan doet is "passwd" en het systeem is van jou. Heb je geeneens een Knoppix CD oid. voor nodig.

Daar was een tijdje geleden nogal heibel over ja. Nu moet je bij de meeste distro's ook in single user mode het root passwd in voeren. Totaal nutteloos, want als je init=/bin/bash doet heb je hetzelfde bereikt zonder paswoord. En inloggen in single user mode zodat je 't root password dat je bent vergeten kunt resetten is ook zo lastig op deze manier.

[Ronald]

Gondor schreef op zondag 20 maart 2005 @ 23:35:
[...]
Volgens mij voorkom je dit door een wachtwoord op je bootloader te zetten.

Wachtwoord op je bootloader en bios. Geen cd of floppy aansluiten en ook geen entry hiervoor in je fstab. Zijn paar dingen wat als eerst bij mij opkomen.

Hiermee en met andere maatregelen kan je het behoorlijk moeilijk maken. Maar zoals eerder gezegd, fysieke toegang is en blijft het grootste risico.

Moeilijk?

* Ronald pakt atapi cd device, floppy device, grub op floppy, grub op cd

Neem gewoon me eigen bootloader mee, en voor het geval dat, iets wat die bootloader in geheugen gaat laden :-)

Zelfs een password op de BIOS kan je simpel omheen, pak een andere flashchip voor dat moederbord en gaan, als een simpele bios hardreset niet simpeler is =)

[killercow]

Ik snap jullie niet echt eigenlijk,

Je bent root of wie dan ook op je knoppix cd, en je bent niet root op je gentoo machine.

door te chrooten kun je er echter voor zorgen dat je de gegevens van de users op je gentoo disk aanpast met eventueel ook de binary's op je gentoo disk. Nogal logisch dat dat gewoon kan.

Als je echt 100% zeker wilt zijn dat niemand bij je files kan moet je verder gaan, je moet dan je data encrypted opslaan op je disk.
Linux security houdt gewoon bij welke gebruiker je bent, (en je bent root), dus mag je bij de files,
als je echter je root partitie encrypt moet je echt de sleutel hebben.

Mensen die dit als een security bug/fout/eng zien snappen niet helemaal hoe de wereld in elkaar steekt denk ik.

Als je gebruikers zo hostile zijn dat ze je bak gaan open maken om vanaf een cd te kunnen booten, dan moet je niet gaan berusten op software om de boel veilig te houden. Maar moet je een kooi om je pc zetten (zoals bijvoorbeeld in alle data centra gebeurd.)

software beveiligt in principe alleen toegang vanuit de software, niet vanuit de hardware, en hardware beveiligt alleen de hardwarematige toegang en niet de software matige toegang.

[Verwijderd]

En da's nou precies en van de redenen waarom vaak alleen beheerders toegang hebben tot serverruimtes. Zodat er geen vreemden aan het ijzer kunnen komen.

(moet er niet aan denken dat er iemand lekker aan de touwtjes van een server gaat zitten frommelen)

[Verwijderd]

Ik wil hier nog ff aan toevoegen, dat er bepaalde types moederborden zijn (IBM maakt ze geloof ik), waarin de bios chip hard op het bord is gesoldeerd. Je kunt de bios wel flashen/resetten, maar niet het wachtwoord veranderen. De enige manier om dat ge-reset te krijgen, is om het bord naar IBM op te sturen, zodat zij het voor je kunnen doen (vermoedelijk door het bord in z'n geheel te vervangen). Niet dat dat veel uitmaakt als je de disk gewoon kunt loskoppelen en in een andere bak kunt stoppen

[Roel]

Verwijderd schreef op woensdag 23 maart 2005 @ 14:45:
Ik wil hier nog ff aan toevoegen, dat er bepaalde types moederborden zijn (IBM maakt ze geloof ik), waarin de bios chip hard op het bord is gesoldeerd. Je kunt de bios wel flashen/resetten, maar niet het wachtwoord veranderen. De enige manier om dat ge-reset te krijgen, is om het bord naar IBM op te sturen, zodat zij het voor je kunnen doen (vermoedelijk door het bord in z'n geheel te vervangen).

Ik denk dat dat een beetje erg simpel gedacht is.. Een bord van een paar honderd euro vervangen omdat 't bios password kwijt is..

Waarschijnlijk zetten we op een paar pinnetjes stroom die de bios resetten oid.. Maar 't bord weggooien is een beetje overdreven

[Verwijderd]

Als je zover bent kun je toch beter die disk(en) uitbouwen en in je eigen systeem zetten?

[Wolfboy]

Verwijderd schreef op woensdag 23 maart 2005 @ 14:45:
Ik wil hier nog ff aan toevoegen, dat er bepaalde types moederborden zijn (IBM maakt ze geloof ik), waarin de bios chip hard op het bord is gesoldeerd. Je kunt de bios wel flashen/resetten, maar niet het wachtwoord veranderen. De enige manier om dat ge-reset te krijgen, is om het bord naar IBM op te sturen, zodat zij het voor je kunnen doen (vermoedelijk door het bord in z'n geheel te vervangen).

Bij heel wat systemen is er ook een master wachtwoord voor de bios, dan kan je met dat wachtwoord gewoon altijd inloggen (onafhankelijk van wat het wachtwoord was)
Ik zeg niet dat het hierbij ook het geval is maar dat komt iig ook voor.

[Verwijderd]

Wilke schreef op zondag 20 maart 2005 @ 23:40:
Een encrypted filesystem zou hier trouwens zeker tegen helpen (maar is dus ook dolle pret als je het pwd kwijt raakt).

Daar zijn mooie oplossingen voor om meerdere keys te gebruiken voor toegang (LUKS).

Op die manier kan je standaard een bepaald wachtwoord gebruiken en daarnaast bijvoorbeeld een tweede wachtwoord gebruiken dat je op een fysiek andere locatie bewaart (beveiligd uiteraard).

Tja vergeet je alle wachtwoorden dan ben je behoorlijk screwed

[Gerco]

Verwijderd schreef op donderdag 24 maart 2005 @ 00:40:
Tja vergeet je alle wachtwoorden dan ben je behoorlijk screwed

Of je vergeet het wachtwoord niet, maar raakt wel de keyfile kwijt (zie het zoveelste EFS - Reinstall - HELP! topic).

[deepbass909]

Wolfboy schreef op woensdag 23 maart 2005 @ 23:51:
[...]
Bij heel wat systemen is er ook een master wachtwoord voor de bios, dan kan je met dat wachtwoord gewoon altijd inloggen (onafhankelijk van wat het wachtwoord was)
Ik zeg niet dat het hierbij ook het geval is maar dat komt iig ook voor.

IBM heeft in zijn Thinkpads de BIOS iid zo beveiligd dat bij het kwijtraken van het wachtwoord, de BIOS chip vervangen moet worden. En aangezien die gesoldeerd zit, is het vervangen van de printplaat waar hij op zit de enige mogelijkheid.
IBM heeft dit waarschijnlijk als anti diefstal maatregel ingesteld. Een gestolen laptop is als het goed is bekent bij de service centra, en als zo'n laptop binnen komt, wordt deze in beslaggenomen en eventulee geretouneerd aan de eigenaar.

[Verwijderd]

Ik heb eens een stukje gelezen over de verschillen tussen Windows en Linux met het oog op security. In dat verhaaltje werd een van de "beveiligings issues" die tegen *nix gericht is onderuit gehaald...
Dat was juist dit verhaal... Inloggen als root zonder password....

Het tegenantwoord is toch eigenlijk net als vaak hierboven verteld is... Fysieke access...
Thuis zou ligt het wel iets anders... Maar bij mij op het werk zijn toch wel een aantal opstakels op je weg naar de fysieke access.

- De grote boze bewaker, die als portier werkt...
- Een pasje met je juiste autorisatie....

Dus ik denk dat dit toch meestal niet een heel groot probleem is....
Ik denk dat dit een feature is en zeker geen bug... (Blijkbaar werkt het met windows ook zo, uit reactie van andere hierboven)

[Hmzaniac]

Mocht je niet willen dat mensen met fysieke toegang bij je systeem kunnen, zal je een encrypted filesystems moeten gebruiken, wachtwoord op je bootloader, wachtwoord op je bios, en geen mogelijkheden tot het booten van een extern device (flop, cd, usb, pxe).

Anders is het gewoon een feature van je systeem. Een OS waar niet daadwerkelijk van geboot is is immers niets meer dan een verzameling bestandjes op een harddisk.

Bovendien moet je er gewoon voor zorgen dat mensen geen fysisieke toegang tot je computer hebben als er echt zulke gevoelige informatie op staat. Zet een slot op het frontje wat voor de knoppen en drives zit, zet hem in een 19" kast en mount die in een rack, of als je echt goed bezig wil gaan: Zet hem in een datacenter zoals een van die van KPN. Zonder geldig pasje voor jouw verdieping en de cijfercode voor het slot van je rack kom je daar gewoon niet in.

[Verwijderd]

Ik zie hier meerdere mensen 'wachtwoord op bootloader' noemen, evenals 'wachtwoord op bios'.

Dit kan alleen nuttig zijn, als je de kast van de computer in kwestie zo dicht kunt maken dat hij niet te openen is. Anders is dit uiteraard volslagen nutteloos. Het wachtwoord op de bootloader is sowieso een onzinsuggestie, immers voordat je bij de bootloader komt moet je al een bios wachtwoord ingegeven hebben. Heb je geen bios-wachtwoord, dan boot je gewoon van flop/cd/whatever en mount de schijf die je hebben moet, ongeacht het wachtwoord in de bootloader.

[RedLizard]

Met "wachtwoord op BIOS" wordt waarschijnlijk bedoeld een wachtwoord om het BIOS te editen, niet om te booten.

[Verwijderd]

Kan in sommige gevallen beide (sommige notebooks ondersteunen dit), verschillende wachtwoorden zelfs (eentje om te booten, en de ander om het bios te editen). Resetten hiervan is bij notebooks vaak retour zenden fabrikant, en zeker niet simpel een jumpertje op de printplaat.

Voor zakeliijk gebruik lijkt me dit wel handig.

[deepbass909]

Hmzaniac schreef op vrijdag 25 maart 2005 @ 00:26:
Anders is het gewoon een feature van je systeem. Een OS waar niet daadwerkelijk van geboot is is immers niets meer dan een verzameling bestandjes op een harddisk.

Daar zat hem juist het punt van mijn verbazing, met chroot kon ik van die verzameling bestandjes het active systeem maken, en het wachtwoord wijzigen van de root. Het was dus met 1 commando invoeren niet langer meer een verzameling bestandjes, maar een werkend OS waar ik ongeautoriseerd toegang tot had gekregen.

Natuurlijk zijn dergelijke systemen fysiek goed te beveiligen, als ik bijvoorbeeld de sleutel van de systeemkast van mijn server had gehad (is helaas zoek), dan kon niemand meer bij de cd-rom en powerknop zonder het front te beschadigen. En daarnaast wil mijn server ook niet booten vanaf een knoppix cd (heeft iets te maken met dat Adaptec op de oude controllers niet het volledige El-Torino protocol ondersteunt, maar alleen floppy-emulatie, wat nog maar weinig gebruikt wordt).

[TrailBlazer]

in mijn server zit geen cd-rom speler/floppy drive een keer er aan gehangen voor het installeren. Daarna nooit meer nodig gehad. Verder is het een \beetje een doodoenet maar zoals al zo vaak gezegd als er iemand naast je server staat ben je al te laat

[Hmzaniac]

Verwijderd schreef op vrijdag 25 maart 2005 @ 00:34:
Ik zie hier meerdere mensen 'wachtwoord op bootloader' noemen, evenals 'wachtwoord op bios'.

Dit kan alleen nuttig zijn, als je de kast van de computer in kwestie zo dicht kunt maken dat hij niet te openen is.

Das een kwestie van je kast in een rack in een datacenter te plaatsen... daar kom je niet zomaar in, en als je er al in komt sta je op zo ongeveer iedere camera in het gebouw.

Anders is dit uiteraard volslagen nutteloos. Het wachtwoord op de bootloader is sowieso een onzinsuggestie, immers voordat je bij de bootloader komt moet je al een bios wachtwoord ingegeven hebben. Heb je geen bios-wachtwoord, dan boot je gewoon van flop/cd/whatever en mount de schijf die je hebben moet, ongeacht het wachtwoord in de bootloader.

WW op je bios voor het wijzigen, WW op je bootloader voor het laden van custom parameters. Bovendien gaat er bij iedere server die ik in beheer heb grote rinkelende bellen af van mn Nagios

deepbass909 schreef op woensdag 30 maart 2005 @ 13:55:
[...]
Daar zat hem juist het punt van mijn verbazing, met chroot kon ik van die verzameling bestandjes het active systeem maken, en het wachtwoord wijzigen van de root. Het was dus met 1 commando invoeren niet langer meer een verzameling bestandjes, maar een werkend OS waar ik ongeautoriseerd toegang tot had gekregen.

Dat is zeker waar, daarentegen: als je data zo belangrijk voor je is dat je niet wil dat iemand er zomaar bij kan kan je, in oplopende gradaties dingen doen als een wachtwoord op je bios settings, wachtwoord op je bootloader, kast op een fysiek beschermde locatie zetten (in een afgesloten rack, al dan niet in een datacenter), een rack met een flinke gietijzeren deur en die zelf ook nog eens met een zwaar slot dichtmaken.

En als je data echt zo belangrijk is voor de wereldvrede, kan je het altijd op een encrypted filesystem zetten met een passphrase van minstens 128 tekens die in een verzegelde envelop in een kluis ligt waarvan alleen jij de combinatie kent. Betekent wel dat je de sjaak bent als je dat ding ooit mag rebooten, maar dat is de prijs die je betaalt voor veiligheid.

[CyBeR]

deepbass909 schreef op woensdag 30 maart 2005 @ 13:55:
[...]


Daar zat hem juist het punt van mijn verbazing, met chroot kon ik van die verzameling bestandjes het active systeem maken, en het wachtwoord wijzigen van de root. Het was dus met 1 commando invoeren niet langer meer een verzameling bestandjes, maar een werkend OS waar ik ongeautoriseerd toegang tot had gekregen.

Je maakt er niet het actieve systeem van. Je doet alleen alsof het je root filesystem is. Dat wachtwoord is zonder te chrooten ook wel te veranderen.

[Wolfboy]

CyBeR schreef op dinsdag 05 april 2005 @ 19:53:
[...]
Je maakt er niet het actieve systeem van. Je doet alleen alsof het je root filesystem is. Dat wachtwoord is zonder te chrooten ook wel te veranderen.

Idd, dat merk je ook wel als je echt iets met de devices wil gaan doen, probeer bijvoorbeeld maar eens te rebooten als je in een chrooted omgeving zit, dat gaat dus absoluut niet werken.

Dat het lijkt alsof het je root filesystem is wil niet zeggen dat het ook zo is.

Je kan gewoon net als bij windows het bestandje met wachtwoorden aanpassen via een bootcd(flop/usbstick/etc.)