Raspberry Pi Foundation haalt standaardgebruiker 'pi' uit Raspberry Pi OS

Raspberry Pi OS wordt voortaan niet meer geleverd met de standaarduser 'pi'. De aanwezigheid daarvan kan het makkelijker maken om een brute force-aanval op het os uit te voeren. Ook wordt in sommige landen gewerkt aan verboden op dergelijke default credentials op internetapparaten.

In plaats van de standaardgebruiker in het systeem moet Raspberry Pi OS nu de gebruiker de gelegenheid geven om van meet af aan zelf een user aan te maken. Dit is mogelijk ongeacht wat voor vorm de installatie aanneemt. Wie voor een standaard-install gaat, zal bij de eerste boot-up een wizard te zien krijgen die dit faciliteert.

Wie Pi OS Lite installeert, zal ook een prompt hiervoor zien, zij het een grafisch minder indrukwekkende. Wie met een headless Pi werkt, zal zijn gebruikersnaam in kunnen stellen in de Raspberry Pi Imager, of handmatig met een tekstbestand waar een gebruikersnaam en versleuteld wachtwoord in geplakt moeten worden.

Wie tot slot door deze wijziging gemotiveerd is om de pi-user in zijn bestaande installatie een andere naam te geven, kan dat ook, met ingang van deze nieuwe versie. Die heeft geen versienummer, maar een datum: 2022-04-04.

De reden dat een installatie van dit os kwetsbaarder is voor een aanval met een standaardgebruikersnaam is dat, als de aanvaller de inloggegevens gaat 'raden', hij of zij de gebruikersnaam al weet. Dat is de helft van de credentials die nodig zijn om binnen te komen.

De Raspberry Pi-makers melden verder dat het met deze nieuwe update ook niet meer nodig is om usb-muizen en keyboards te gebruiken om bluetooth-muizen en keyboards te koppelen. Op de eerste pagina van de installatiewizard zal de Pi, indien daartoe in staat, in pairing mode gaan. Het zal automatisch aan het eerste muis en toetsenbord koppelen dat het vindt.

Reacties (116)

Ook zijn dergelijke default credentials op internetapparaten verboden.

Door wie dan? Begrijp me goed, goed idee en zo maar daar was ik me niet van bewust.

Europa, maar dan wel pas 2024:
https://www.rijksoverheid...iligheid-slimme-apparaten

Gaat overigens over consumenten apparaten met voorgeinstallereede software, vermoedelijk niet echt voor de Pi dus.

[Reactie gewijzigd door FuaZe op 10 april 2022 09:23]

Ik vind niet dat er veel mis is met standaard inloggegevens meeleveren, maar wel met de manier waarop. Ze zouden mijns inziens OTP's moeten zijn.

In het geval van een OTP zou het dan wel prettig zijn dat apparaat in kwestie pas volledig functioneel wordt nadat het OTP is gewijzigd.
Dit om te voorkomen dat je een apparaat alsnog X jaar met default credentials kunt gebruiken.

Daar ben ik het mee eens.

Deze tendens is er al een tijdje, maar het zal nog even duren voordat er daadwerkelijk algemene wetgeving is.

De basis voor Europa is inmiddels gelegd met de beschikbaarheid van EN 303 645, die mogelijk in de toekomst voor verschillende apparaatgroepen van toepassing zal zijn.

En hiermee zijn alle boeken, magazines en online tutorials over de Raspberry Pi EOL

[Reactie gewijzigd door RoestVrijStaal op 9 april 2022 13:40]

En belangrijker (voor mij), mijn eigen notities erover

Ik heb die notities er nog even bijgepakt, eigenlijk is nu die raspberry pi initial config best wel gek, want je moet juist beginnen met in te loggen met gebruiker pi, en dan moet je zelf weten dat je het commando sudo raspi-config moet draaien. Dus als dat een betere stappen-wizard wordt is het wel een verbetering.

(hoewel ik het zelf eigenlijk irritant vindt dat je altijd verplicht bent er een toetsenbord en beeldscherm aan te hangen voor die initiële installatie, voor een apparaat wat toch 90+% van de mensen headless gebruikt)

Voor een headless setup kan je op de fat32 partitie van het SD kaart de volgende bestanden aanmaken.

1. Een leeg text bestand genaamd "ssh" om SSH aan te zetten (vgm kan je daar ook sshd config parameters in zetten, maar nog nooit gedaan. Doe na boot direct de SSH config aanpassen en keys erin zetten).
2. Een text bestand genaamd "wpa_supplicant.conf" als je WIFI nodig hebt.
3. een text bestand genaamd "userconf.txt" met de default username en password.

Let wel dat alle bestanden UNIX formatted moeten zijn, dus met notepad van Windows kom je niet ver.

https://pimylifeup.com/headless-raspberry-pi-setup/

Er is ook een GUI tool, maar die heb ik nog nooit gebruikt. Ben nog van de oude stempel, alles met de hand.

[Reactie gewijzigd door TechSupreme op 9 april 2022 22:20]

Voor het bewerken van UNIX formatted bestanden kun je Notepad++ gebruiken. (En ongetwijfeld nog een berg andere text editors). Op mijn windows machines heeft N++ Notepad.exe zo goed als vervangen. Alleen als ik snel even iets wil aanpassen start ik de oude Notepad.exe ipv. N++

Je kunt het kopje "headless setup" lezen in de aankondiging hierover. Je kunt in de image ook gewoon een gebruikernaam en hash stoppen om zo je account zonder toetsenbord aan te maken!

Ja, bedankt voor die info.
Ik weet niet of dat het er dan al langer in zit en dat ik gewoon niet doorhad dat je dat kon instellen (ik heb minder dan een half jaar geleden nog een installatie gedaan), maar ik heb nu net even die imager gedownload en inderdaad daarin kun je ssh aanzetten onder de geavanceerde opties.

Als dat al langer kon wist ik dat niet, ik ga mijn notities aanpassen!

Dat kon al heel lang

Thanks! Daar was ik naar opzoek. Als ik weer een nieuwe Pi (Zero) ergens aanslinger, dan installeer ik 'm altijd headless. Ik gooi een leeg ssh bestandje op de SD-kaart en ik copy/paste mijn wpa_supplicant.conf voor de wifi configuratie. Dan is 't wachten tot ie online komt en kan ik erbij. Nu komt daar een extra stap bij voor de username/password.

Edit: zo te zien kan ik de wpa_supplicant.conf nu overslaan, omdat dat al in de Pi Imager ingebakken zit. Mooi. Scheelt weer.

[Reactie gewijzigd door Bas_f op 9 april 2022 21:04]

En hiermee zijn alle boeken, magazines en online tutorials over de Raspberry Pi EOL

Hoezo? Je kan jouw accountnaam tijdens de installatie toch nog steeds "pi" geven. Dan veranderd er praktisch niks.

Ja maar de meeste hobby gebruikers zullen zich dat niet realiseren bij installatie. Persoonlijk zie ik het probleem niet zozeer. Je moet dus de naam pi veranderen naar de gewenste gebruiker in de tutorials die je leest. Als men die kennis niet bezig dan vind ik persoonlijk dat men zich toch eerst wat meer in moet lezen in een op Linux gebaseerd operating system alvorens ze ermee aan de slag gaan.

Dan kun je nog steeds als de tutorial de gebruikersnaam 'pi' opgeeft deze wijzigen naar user die je zelf hebt ingesteld.
Of je voegt als nog de user 'pi' toe.

Ja, dat is dus wat ik zei.

Tutorials kom je zelf wel uit. In een hoop tutorials voor andere systemen gebruiken ze al vaak een voorbeeld gebruikersnaam en vertellen je dat je ipv daarvan je eigen gebruikersnaam moet gebruiken.

Wat erger is, zijn die installatiescripts die er vanuit gaan dat je een “pi” gebruiker op je systeem hebt, en daar onder werkt. Ik heb nooit veel met m’n Pi gedaan, maar ik ergerde me al groen en geel toen ik geen installatiepad kon kiezen, en het gewoon in de root van je home werd neergezet (waar ik nooit software wil hebben staan). Nu is het een irritatie, maar met een ontbrekende “pi” gebruiker is het script stuk. Voor een simpel script niet zo erg (doe je het gewoon handmatig), maar voor iets complex een drama.

Daarmee wil ik verder niet zeggen dat ik dit geen goede stap vind ofzo. Ik vond die standaard gebruikersnaam altijd al bizar. De standaard onder Linux is al een paar decennia lang dat je bij de eerste boot een gebruikersnaam en wachtwoord moet kiezen. Misschien gaan ze die hacky installatiescripts met hardcoded paths eindelijk eens netjes maken…

Ze hebben mij altijd geleerd dat niet de username maar het wachtwoord de kracht van de authenticatie bepaald. De username zwerft immers overal rond.

Maar verder denkend dan dat: is het dan uberhaupt voor applicatie nog simpel om te controleren of je onder een root-account wordt gerund (bad smell)? Is onder Linux het UID vast voor de root-gebruiker?

Kun je username achterhalen als je probeert een Pi te hacken? Stel je ziet een Pi, hangt je laptop met hacktools eraan .. als je een SSH-verbinding opzet, moet je als eerste een gebruikersnaam intoetsen. En dan is HenkPiMeterkast moeilijker te raden dan het standaard 'Pi'

Kun je username achterhalen als je probeert een Pi te hacken?

Het punt is dat een username by design niet door het OS geheim wordt gehouden. Erger nog, er zijn in een OS talloze manieren om uit te vinden wie de andere gebruikers zijn. Dus je mag er niet vanuit gaan dat een applicatie die niet lekt.

Meer praktisch, soms lekt die door e-mail clients (afzender pi@meterkast), soms door andere oorzaken. Als je al op het OS toegang hebt (lekke applicatie) dan zie je dat al die bestanden waar je niet bij mag van HenkPiMeterkast zijn. Kern voor mij is dat men geheimzinnig gaat doen over iets waar het OS (en de rest van de security wereld) van besloten heeft dat het toch niet geheim zal zijn, en je dus schijnzekerheid aan het bieden bent.

Je verhoogt inderdaad de entropie, maar volgens mij is dat een doekje voor het bloeden. Laten ze als Raspberry gewoon default een goede fail2ban install en config installeren, of standaard alleen SSH toegang vanuit interne ip-adressen, dat zet veel meer zoden aan de dijk.

Zoals altijd is het met beveiliging een kwestie van lagen. Je voorstel om fail2ban te installeren en te configureren vanuit default is zeker geen slecht idee, maar geen totaal-oplossing, niks is 1 oplossing voor security behalve geen computer hebben

Gaat niet over 'geheimzinning' doen, maar over niet je naam de hele wereld over schreeuwen. Je logt in met een gebruikersnaam, waarom zou dat altijd standaard 'pi' moeten zijn, misschien heet jij wel 'pi' maar ik heet anders
Zoals in het artikel uitgelegt gaat dit er vooral over om brute-force aanvallen op SSH te voorkomen, lekken enz. in het OS waar de gebruikersnaam getoont wordt in emails, het lockscreen enz. gaat hier dus niet op.
Ook standaard alleen SSH toegang vanuit interne IP-addressen is leuk, totdat je het op een groter netwerk gebruikt zoals op een school en een leerling de Raspberry hackt, daar helpt jouw 'interne IP whitelist' niet tegen
Een betere optie: fail2ban EN IP whitelist EN een persoonlijke gebruikersnaam.

Waarom dit zo lang bij Raspberry Pi's de default was begrijp ik sowieso niet, mijn Windows 10 computer maakt ook niet standaard een gebruiker 'B.Gates' of 'MS' aan maar laat mij zelf mijn naam kiezen.

In 2012 werd de simpele beveiliging nog als voldoende gezien voor een heel simpel computertje. Inmiddels is de PI uitgegroeid tot een meer serieus platform. Een standaard gebruikersnaam en wachtwoord kan in deze tijd echt niet meer. De serieuze gebruikers passen dat ook altijd aan zodra het OS voor de eerste keer opstart, zeker als het in het netwerk hangt.

Euh, Administrator wordt toch ook als account op Windows standaard aangemaakt? Ik zou dus niet zomaar zeggen dat het op Windows beter is. Of het Guest account…

Euh, Administrator, Guest en DefaultAccount zijn default disabled oftewel uitgeschakeld
Tenzij jouw Raspberry Pi voor deze update default een user 'Pi' aanmaakte die standaard uitgeschakeld staat?...

Wat ik zei was dat je op Windows al hoeveel jaren je account standaard tijdens de OOBE een naam mag geven terwijl dit op de Raspberry Pi al zo'n 10 jaar lang niet zomaar kon. Dan kan je dus heel makkelijk zeggen dat het beter kan kwa gebruikersgemak en beveiliging

Tenzij er met een encrypted disk gewerkt wordt kun je gewoon de micro SD in je laptop steken en /etc/passwd uitlezen om te zien welke gebruikers aanwezig zijn, en op basis van UID/GID raden welke de 'standaard admin' is

Klopt, maar het gokken naar de gebruikersnaam komt bovenop het wachtwoord. Dus al heeft het effectief maar 4 of 5 bits entropie, dan wordt het hacken van een account nog steeds 16-32x zo moeilijk.

Root is slechts een naam, het ID voor het account met alle rechten is 0.

Ze hebben mij altijd geleerd dat niet de username maar het wachtwoord de kracht van de authenticatie bepaald. De username zwerft immers overal rond.

Drie maal raden wat het standaard wachtwoord is ...

en er was geen verplichting om dat te veranderen.

Weet ik, maar moet je nu die username aanpassen, of kun je hem ook gewoon op pi laten staan? Want elke tutorial op het internet gebruikt pi als username...

[Reactie gewijzigd door J_van_Ekris op 9 april 2022 14:29]

Ach, ik vind het wel fijn eigenlijk. Bij een pi was mijn eerste stap altijd een riedeltje om de pi user te verwijderen en een nieuw account met een echte naam aan te maken. Mensen die de handleidingen willen volgen mogen nog steeds "pi" gebruiken, natuurlijk.

Als de handleiding je een username laat invullen zonder dat je deze uitlegt dat dat het een username is, heb ik mijn twijfels bij de kwaliteit van die handleiding, eigenlijk.

Als je via internet een pi vind die ssh open heeft staan dan weet je de gebruikersnaam natuurlijk nog niet. Maar als het os een standaard username heeft dan hoef je dat al niet meer te raden.
Dat is dus ook een reden dat je root logins via ssh niet toe moet staan. Dan weet een hacker al 1 van de 2 dingen om in te loggen.

De rootuser heeft altijd UID 0 verder, dus dat is te checken in een script. Maar met het whoami commando krijg je altijd een username terug en niet een uid, dus dat kan je altijd gebruiken ongeacht het uid dus

Hoe doe je dan veilig root operaties op een headless set-up?

Door in te loggen op de pi met ssh met een username die je zelf hebt aangemaakt. Je staat alleen toe dat je met ssh keys in mag loggen. Eventueel zet je nog een firewall op poort 22 die alleen connecties vanaf bepaalde locaties toestaat.
Als je dan ingelogd bent gebruik je sudo om met een wachtwoord root te worden en te doen wat je moet doen.

Ah zo, had gewoon even root gebruiker en sudo door elkaar gehaald

Ze hebben mij altijd geleerd dat niet de username maar het wachtwoord de kracht van de authenticatie bepaald.

Ze hebben mij nou net geleerd om nooit de standaard user actief te laten. Het heeft geen nut en is een potentieel extra risico. Waarom zou je dat potentieel risico nemen? Wie heeft je dat geleerd?

Beiden zijn het geval. Het standaard adminaccount zou je moeten hernoemen om het de aanvaller niet té gemakkelijk te maken, maar de username wordt ook beschouwd als openbare informatie, niet als secret.

Nou nog een stapje verder en secure login met SSH key based authentication via een prompt aanbieden en het wordt nog eens wat.

Edit: Er stond SSL-certificaat. Even aangepast naar wat ik daadwerkelijk bedoelde. Brain fart....

[Reactie gewijzigd door Korvaag op 9 april 2022 15:24]

Is toch makkelijk te regelen? Out of the box wil je dit niet, het gaat te ver voor de doorsnee gebruiker.

Ook een nieuwe user aanmaken en de user Pi wissen is makkelijk te regelen en toch komt daar momenteel een andere manier voor. Feit is dat als het niet aangeboden wordt het blijkbaar niet gebeurt. Biedt een manier aan om bij installatie via 2 opties of een eigen user aan te maken of een SSL-certificaat en je hebt zo'n prompt compleet.

Maar dan moet je wel naar een IPv6 situatie toe, waarbij ieder apparaat is verbonden aan het internet.
Het heeft weinig zin om lokaal je certificaten te signen (het is beter dan niets - en ik doe dit toch zoveel mogelijk), maar de kracht van SSL is juist dat het vertrouwd wordt door een chain en je deze kan intrekken/vernieuwen.

Met dergelijke opmerkingen heb je ergens en paar punten gemist: het gebruik van ssl is echt niet gebonden aan ipv6, het kan heel goed met ipv4, ook in een nat omgeving.

Zoals je als stelt, het vertrouwen is in de keten. Je kan een eigen root-ca draaien of een eigen ca die gekoppeld is aan een internet-gebaseerde root-ca of ca-keten. Uiteindelijk hoeft alleen de machine waarvan je vandaan komt internet toegang te hebben, naar internet toe, om de ca-keten te testen. De machine waar je naar toe gaat hoeft helemaal niet op internet te kunnen, die hoeft alleen maar een certificaat te hebben dat via een andere route op die machine kan komen.

Enneh, lokaal signen kan heel goed, misschien zelfs beter. Hoe minder verkeer naar internet hoe beter.

We zijn het volgens mij met elkaar eens.

Het makkelijkste is dat apparaten aan het internet hangen en je deze bijvoorbeeld kan signen met Let's Encrypt of gewoon een globaal certificaat die je inderdaad steeds vernieuwd met de machine die aan het internet hangt.

Voor remote login, ben je wellicht beter uit met SSH-keys/VPN's en andere tools, als deze enkel CLI gebruiken.

Ja ik ben het met je eens dat je een CRL check zou moeten kunnen doen voor maximale veiligheid, maar wat je zegt: het is beter dan niets.

Wat heb je aan TLS in deze context? Het gaat hier toch alleen om een popup tijdens de installatie?

Misschien dat een SSH host key en pubkeys opgeven tijdens het imagen hier handig zou zijn zodat je de setup veilig remote kan doen, maar een TLS-certificaat lijkt me een raar iets om zomaar mee te nemen. Kan wel, wellicht, maar niet veilig.

Ja ik heb het wat idioot verwoord. Ik bedoelde natuurlijk SSH key based authentication. Zal het even aanpassen. Geen idee hoe dit er zo uitgekomen is

Theoretisch kun je x509 certificaten gebruiken voor SSH, maar of je dat nou wilt

Haha. Het antwoord wordt al gegegeven:

Should I use this?
No

Ik denk dat er dan veel gebruikers zullen zijn die niet weten wat ssh is, laat staan hoe ze aan een key komen om toe te voegen voor key based login.

>Nou nog een stapje verder en secure login met SSH key based authentication via een prompt aanbieden
>en het wordt nog eens wat.

Dat is bij het aanbevolen SD kaart schrijf programma "Raspberry Pi Imager" een kwestie van in de instellingen (tandwiel icoontje), "Enable SSH" aanvinken -> "Allow public-key authentication only" kiezen.

(De SSH key uit ~/.ssh/id_rsa.pub wordt al voor je ingevuld mits je het draait op een Linux of Mac OS X systeem. Zo niet, dan moet je die ook nog even copy & pasten).

[Reactie gewijzigd door maxnl op 10 april 2022 00:21]

Nice. Dat heb ik dan de vorige keer bij het installeren volledig over het hoofd gezien.

Ik kwam hier een paar dagen geleden toevallig achter in de Raspberry Pi imager. Het werkt echt ideaal! Je kan alvast een draadloos netwerk opgeven, een gebruikersaccount aanpassen en zelfs inloggen met public key authentication, door simpelweg je .authorized_keys string in Imager te plakken. Da's nog eens makkelijk opzetten, als je je Raspberry Pi's headless gebruikt. Ben er heel blij mee.

Kun je ook alvast sshd aanslingeren, of moet dat nog steeds met een leeg ssh bestandje op de SD-kaart?

Ik hoefde niets meer aan te passen na het flashen, zoals voorheen met een bestandje Idd. Ideaal. Ook stond password authentication net SSH dys uit omdat ik alleen key-based auth aanvinkte

[Reactie gewijzigd door Helium-3 op 9 april 2022 21:12]

Kun je ook alvast sshd aanslingeren, of moet dat nog steeds met een leeg ssh bestandje op de SD-kaart?

Je kunt bij de nieuwe versie van de imager gewoon aanklikken dat je SSH enabled wil hebben (waarschijnlijk maakt die op de achtergrond dat bestandje dan aan)

https://www.cnx-software....raspberry-pi-imager-v1-6/

Logisch.
Ik ben zo'n slechte gebruiker die z'n pi wachtwoord nooit heeft aangepast (want alleen intern in het netwerk, geen verbinding met buiten etc etc etc) maar eigenlijk moet ik dat ook gewoon doen want het is wel degelijk een gevaar.

Goed om te weten dat je pi wachtwoord nooit aan past.

En jij weet toevallig zijn ip adres ed?

Ik snap dat ze dit willen veranderen, maar voor de doorsnee applicatie gaat het praktisch gezien nergens over.
Je zult eerst moeten weten dat een target überhaupt een rasp pi gebruikt, dan zul je interne ip adres moeten weten, vervolgens externe ip adres en daarna moet je nog zeer waarschijnlijk door een paar firewalls worstelen.
Dan nog is de kans dat je echt noemenswaardig schade kan aanrichten vrij gering.

Je kunt heel eenvoudig aan het interne ipadres komen als je op het netwerk zit, maar dan heeft de eigenaar ook een ander probleem. Dan moet de gebruiker al een port forwarding hebben ingesteld naar die raspberry pi, en dan heb je het interne ipadres al niet meer nodig.

[Reactie gewijzigd door mjz2cool op 9 april 2022 16:53]

Ja precies, zonder portforwarding wordt het een beetje lastig zomaar in iemands pi te komen.
Dan zul je eerst te router moeten hacken, en alvorens je daar doorheen bent, moet je nog meer trucs uithalen. Lijkt me wel erg veel werk.

Binnen een lokaal netwerk is dat een ander verhaal. Als het echter zo gevoel ligt, dan is het wellicht slimmer om een sub-net te maken waar de pi dan achter zit.

Een ander subnet/vlan is niet direct veiliger zonder een degelijke inrichting

Jij zet al je apparaten op een apart VLAN?

Entrypoint hoeft niet de Pi te zijn:

Stel dat ik een soort game (of andere applicatie die zich voordoet als iets anders) maak, die op de achtergrond je netwerk afstruint naar Pi's met default password en deze infecteert.
(Ik zeg een game, omdat het hierbij niet raar is om netwerk permissies te vragen, maar d'r zijn verschillende dingen te bedenken.)

De Pi is nu gecompromitteerd en maakt een verbinding naar buiten (firewall vindt dat vaak prima), naar een C&C server om een taak te ontvangen zoals bitcoins minen of een IP adres DDoS'en.

Wel handig, mocht je je wachtwoord kwijt zijn, zijn er genoeg die je kunnen helpen

uiteraard direct aangepast

Jaja dat zou ik ook zeggen

Hoe zit het dan met de gebruiker 'root' op de meeste linux distributies (en onder linux)?
Hoe zit het dan met de gebruiker 'administrator', 'admin' en dergelijke op andere systemen?

Voor het unix/linux root account weet ik ook wel dat standaard het wachtwoord zodanig is ingesteld dat het technisch nooit matcht, maar dat kan voor het account 'pi' ook zo zijn ingesteld.

Het zou completer zijn als je naast de account naam ook kan kiezen voor ssh-keys en het wachtwoord dan ook op een onmogelijk iets laten staan.

Je zegt het zelf al. Op elk modern Linux systeem kan user 'root' standaard niet op afstand inloggen. Dat moet met een reguliere gebruiker, die dan eventueel kan sudo'en naar het root account.

Het hele idee van die user 'pi' is juist dat deze wel op afstand kan inloggen, bijvoorbeeld op headless installaties (Pi's zonder monitor). Het helpt dan niet als die user een standaard wachtwoord gebruikt die niet iedereen zal wijzigen.

Het is wel wat genuanceerder. Als de public SSH-key gekoppeld is aan het root account, kun je prima direct inloggen via bijvoorbeeld SSH, als zijnde root. Je kunt alleen het inloggen met de credentials van root uitschakelen, zodat je dus enkel SSH-keys accepteerd.

Het ligt nog wel wat genuanceerder. Je bepaalt zelf wie en hoe je laat inloggen via SSH door configuratie in je /etc/ssh/sshd_config bestand.

Daar kun je bepalen dat niemand kan inloggen via ssh (hoewel je dan beter de service uit kunt zetten denk ik), of je gebruikers toestaat om via ssh in te loggen (en wie wel en wie niet, en of dat met wachtwoord kan of alleen met key) en hetzelfde geldt voor root.

Voor een systeem dat via internet bereikbaar is zet ik root toegang uit en maak ik aanvullend gebruik van fail2ban om bruteforcen te voorkomen.

Alleen gedefinieerde gebruikers kunnen met de juiste key en 2FA inloggen.

Op die manier kun je dan ook nog andere services aanbieden via ssh-tunnels (MobaXterm is dan erg handig om te gebruiken).

Als extra veiligheid gebruik ik ook nog naast fail2ban en ssh keys, knockd een poort opener voor ssh en andere poorten.

Dat is ook nog een mogelijkheid maar ik vind het voldoende beveiligd met key-only, 2FA en fail2ban.

Nog een mogelijkheid is om een afwijkende poort te gebruiken (ik weet het; obscurity != security maar het zorgt er toch voor dat je minder bots hebt die de deur proberen).

Die 'afwijkende poort' methode is ondertussen al lang niet meer relevant; als ik de stats bekijk op wat er hier op mijn /24 binnen komt is het gewoon 1-65535. Bandbreedte voor scans is ondertussen groot genoeg om dat te doen.

Hoe houd jij fail2ban onder controle?

Ik heb dat van mijn server af moeten halen want op een moment was de fail2ban database zo groot geworden dan het te veel server resources in beslag nam.

er zat een fout in oudere versies van fail2ban, waarbij de dbpurgeage parameter gewoon niks deed.
resultaat: je database die meestal maar een dag ofzo aan inhoud heeft (10mb ofzo) bleef exponentieel groeien.

is opgelost ergens in de 0.11.x versies

Daar ben ik nog nooit tegen aan gelopen. Misschien heeft het te maken met logrotate?

Volgens mij is in vrijwel alle desktop Linux distro's het direct inloggen met root in SSH uitgezet, zowel met password als met key (in ieder geval Ubuntu). Uiteraard kun je dit aanzetten, het is gewoon een instelling die in je SSH server config file staat.

PermitRootLogin no

Je moet wel door wat hoepels springen om met root via ssh in te loggen. Dan ben je jezelf dus actief aan het saboteren, en verdien je alles wat je vervolgens toekomt als je het ding aan het internet hangt.

Het is heel overdreven gemaakt, met als uitganspunt het idee dat iedereen weet wat root betekent. Wat is het technische verschil met een andere gebruiker met dezelfde permissies?

Want in sudo kun je een non-root user niet dezelfde toegang geven? Dan hoef je dus alleen sudo voor het commando te zetten en ben je klaar.

Dus inloggen met
username: pi
password: raspberry
En dan:
sudo su root?

Dan heeft het niet gebruiken van root ook weinig nut.

Zo had Oracle altijd z’n mooi ww change_on_install. Dat werd ook veel misbruikt in het verleden.

De meeste systemen die ik gezien heb, hebben na de installatie geen standaardwachtwoord. Ook de Pi heeft een root user.

De moderne aanpak is dat je naast een root-account een beheerdersaccount aanmaakt dat met doas/sudo rechten kan verkrijgen. Dat account geef je tijdens de installatie een naam, zoals hier ook het geval is. Al sinds Windows 95 moet je hij de installatie van je OS een username kiezen, dat de pi zo lang met een standaardaccount kwam is eigenlijk best gek.

Public key authentication standaard uitrollen (zoals Ubuntu dit aanbied in hun installer, namelijk de pubkeys uit github trekken) zou voor Pi's die gebruikt worden over SSH een mooie toevoeging zijn. Ik weet alleen niet wat dit doet voor de mensen die de Pi gebruiken voor zijn oorspronkelijke doel, namelijk mensen leren hoe computers werken. Als je weet wat public keys zijn, kun je die ook zelf toevoegen.

Mocht je images willen distribueren met een gehardcode wachtwoord, dan kun je op de FAT-partitie van de rpi sd-kaart een bestand plaatsen met daarin de gewenste gegevens voor een standaardgebruiker. Hier zul je wel zelf een naam en een wachtwoord moeten invullen. Zet een bestand genaamd userconf.txt in de bootpartitie met daarin username:gehashtwachtwoord (echo 'wachtwoord' | openssl passwd -6 -stdin om de hash te genereren) en bij de eerste installatie zullen die gegevens worden gebruikt om een account aan te maken in plaats dat het van je gevraagd wordt.

‘This file should contain a single line of text, consisting of username:encrypted- password – so your desired username, followed immediately by a colon, followed immediately by an encrypted representation of the password you want to use.’

Het zou makkelijker zijn om bij een nieuwe installatie en aanmelding de wachtwoord op te geven. Dit in combinatie met het plaatsen van userconfig.txt. Zowel bij headless en desktop. Is het mogelijk om alleen een username op te geven, en dan testen of dat gaat werken? Nu nog de nieuwste images binnenhalen. En ben benieuwd wat ‘ sudo rename-user’ gaat doen bij headless inloggen.

Wat positief is, dat het redelijk vlot gaat om een RP_PI van een verse os te voorzien mits niet al te ingewikkelde programmeer werk na. De wisseling van user kan dan wel voor wat obstakels gezet worden.

Ik mag toch hopen dat je Administrator op Windows systemen standaard uitgeschakeld staat en je het echte admin account een onopvallende naam gegeven hebt.

(Dus hernoem de échte Administrator iets lastig vindbaars, en maak een dummy account Administrator aan en lock die).

Ja je kan dan nog zoeken op SID ipv username maar je werpt een extra barricade op.

[Reactie gewijzigd door DigitalExorcist op 9 april 2022 13:32]

Over het hernoemen van het administrator account onder mswindows zijn verschillende redenen om dat wel of niet te doen.
Ook het gebruik van een ander adminstrator account heeft voor en nadelen.
Zeker als je ook andere 'gebruiken' hebt zoals het aanpassen van de profiel-lokatie en dergelijke.

Die admin en root accounts zijn standaard niet op in te loggen.
Ssh kun je om het veiliger te maken instellen dat je alleen met ssh keys in kunt loggen.

Je username is toch geen password? Deze wordt toch ook niet beveiligd opgeslagen?

Dit is een soort schijnveiligheid.

Je kunt beter enkel een password hebben van 10 random karakters dan een username van 5 en een password van 5.

Het klinkt alsof een username en password samen 'moeilijker' is, maar in de praktijk is het nog steeds een unieke combinatie van 10 karakters. Waarbij een username makkelijker te herleiden is.

Het enige waar ze wel gelijk in hebben is dat user Pi met 5 karakters password t.o.v user random met 5 karakters in praktijk iets veiliger is, maar je username is simpelweg niet bedoeld als je password...

pi / 123456
wel zo makkelijk toch?

maak er dan pi / 31415 van....

Volgens de regels der afronding zou dat dan 31416 moeten worden

Tenzij je bewust naar beneden afrond, maar dat gebeurt maar zeer zelden.

Tenzij je bewust naar beneden afrond, maar dat gebeurt maar zeer zelden.

Dat zou hier security by obscurity zijn.

pi / 314159 dan maar.

Doe dan tenminste pi / 314159

nice, ik denk dat ik voor de gebruikersnaam pi kies en het wachtwoord "raspberry" makkelijk te onthouden

Dat is te makkelijk hoor. Ik zou als gebruikersnaam `raspberry` kiezen en wachtwoord `pi`.

Dat is te makkelijk hoor. Ik zou als gebruikersnaam `raspberry` kiezen en wachtwoord `pi`.

Rapsberry, om kaas mee te rapsen.