Hallo Ich bin neu beim Raspberry Pi und möchte ihn gerne rooten, also mich per SSH als Root anmelden. Wenn ich das richtig verstanden habe, gibt es die sshd Konfigurationsdatei. Reicht es, wenn ich PermitRootLogin auf yes setze? Ich möchte mich auf keinen Fall aussperren. Deshalb frage ich lieber vorher.
Man sollte nur einzelne Befehle per root durchführen und nicht dauerhaft als root arbeiten.
Thomas O. schrieb: > Man sollte nur einzelne Befehle per root durchführen und nicht dauerhaft > als root arbeiten. Das ist reine Pseudo-Sicherheit. Genauso Schlangenöl wie Viren-Scanner und ähnliches. Sprich: effektiv Schwachsinn.
c-hater schrieb: > effektiv Schwachsinn. Und wieder etwas, was der Rest der Welt anders sieht als Du. Man müssen die alle dumm sein.
ssh root@<ip-adresse-raspberry-pi> Mit diesem Befehl kannst du dich als roof einloggen. Ich logge mich aber auch mit einem normalen User ein und wechsle bei Bedarf auf der Kommandozeile auf roof.
Thomas O. schrieb: > Man sollte nur einzelne Befehle per root durchführen und nicht > dauerhaft als root arbeiten. ist das ein neuer Arbeitsschutzparagraph? Sowas wie Zwangspausen? Nach wieviel Befehlen muss ich mich denn jeweils neu anmelden?
Bauform B. schrieb: > Thomas O. schrieb: >> Man sollte nur einzelne Befehle per root durchführen und nicht >> dauerhaft als root arbeiten. > > ist das ein neuer Arbeitsschutzparagraph? Sowas wie Zwangspausen? Nach > wieviel Befehlen muss ich mich denn jeweils neu anmelden? Unwissenheit, Ignoranz und Selbstüberschätzung sind Grundlage für erfolgreiche Angriffe auf Computersysteme. Aber ja, muss jeder selber wissen…
J0h4nn35 schrieb: > Reicht es, wenn ich PermitRootLogin auf yes > setze? Ja, reicht. Aber warum willst Du Dich direkt als root und mit Passwort einloggen? Natürlich wird so ein Raspi selten als NAS für Staatsgeheimnisse eingesetzt, und vielleicht hat er ja nicht einmal Internet-Zugang. Aber "eigentlich" macht man das eine Nummer sicherer, selbst dann, wenn man es "eigentlich" nicht braucht. (Zumindest weiß man dann, wie's geht.) Z.B.: Einloggen als user (gerne mit ssh Key) und dann Wechsel nach root. Oder, wenn man denn unbedingt direkt als root einloggen will: PermitRootLogin prohibit-password PubkeyAuthentication yes #ist Standard und den eigenen ssh public key auf dem raspi in
1 | /root/.ssh/authorized_keys |
.
:
Bearbeitet durch User
Np R. schrieb: > Aber warum willst Du Dich direkt als root und mit Passwort einloggen? Gegen den direkten Root-Login spricht aus Sicherheitssicht nichts, sofern man a) dafür Sorge trägt, dass der adäquat abgesichert ist (lies: mit einem Schlüsselpaar, dessen privater Teil seinerseits mit einer ordentlichen Passphrase gesichert ist) und b) sich beim Hantieren mit dieser UID auf Sachen beschränkt, für die die damit einhergehenden Rechte notwendig sind (i.e. keinen normalen Userkram wie Downloader und Bastelsachen und so als Root ausführt). Je nach Sichtweise könnte es gar der sicherere Weg sein, wenn man nur den direkten Login von Root mittels Schlüssel erlaubt, und lokal auf der Maschine sowohl das Passwort für Root unbrauchbar macht, als auch die unsägliche Defaultkonfiguration (beim RaspberryOS) von ›sudo‹ so fixt, dass kein User überhaupt irgendwie irgendwas mit Rootrechten ausführen kann. Immerhin kommen die meisten Angreifer zunächst über einen weniger privilegierten Account auf die Kiste.
Np R. schrieb: > und den eigenen ssh public key auf dem raspi in > root.ssh/authorized_keys. ssh-copy-id; ich weiß noch immer nicht, wieso so viele immer die Keys händisch übertragen wollen... sudo bringt nicht wirklich Sicherheit mit sich und ist für viele auch verwirrend. Klassiker wie "sudo echo 32 > /sys/class/gpio/export" füllen Foren. Ich sehe alle paar Wochen einen PR mit so einem Aufruf.
wenn die Kiste so konfiguriert ist das jeder user sudo ohne Passwortabfrage verwenden kann, ja dann kann man gleich als admin mit Rootrechten arbeiten.
Marcus schrieb: > Mit diesem Befehl kannst du dich als roof einloggen. Allerdings nur, wenn du ein Dachdeckermeister oder Schornsteinfeger bist...
Jochen schrieb: > c-hater schrieb: >> effektiv Schwachsinn. > > Und wieder etwas, was der Rest der Welt anders sieht als Du. Man müssen > die alle dumm sein. Esst mehr Mist, Milliarden Fliegen können nicht irren.
Jack V. schrieb: > Immerhin kommen die meisten Angreifer zunächst über einen weniger > privilegierten Account auf die Kiste. Das ist der Punkt. Besser ein wirklich gut abgesicherter root-Zugang (der dann natürlich auch nur auschließlich zu administrativen Zwecken verwendet wird) als dieses schwachsinnige Gewichse mit sudo. Das Problem ist halt nur, dass selbst dieses Grundkonzept nicht wirklich die Lösung für alle Probleme sein kann. Immer dann, wenn teilweise "Delegierungen" von administrativen Aufgaben erforderlich werden, muss man zwangsweise auf sudo und Konsorten zurückgreifen. Was natürlich das Sicherheitskonzept massiv aufweicht. Hier zeigen sich dann die Vorteile des Windows-NT-Systems, was sowas bereits vom Konzept her vorsah. Leider aber über lange Zeit nicht konsequent umgesetzt hat. Insbesondere der "Hauptbenutzer" von Windows2000/XP hatte viel zu viele Rechte und Privilegien. Ist sicherheitstechnisch betrachtet grob in etwa mit dem Admin-User eines Debian-Systems vergleichbar (und natürlich dessen Derivaten bis hin zum Raspi-OS). Das Problem ist: ein wirklich einigermaßen sicheres System ist für Normaluser (die es auch selber administrieren müssen) entweder vollkommen unbenutzbar oder zumindest überaus nervig. Sowohl Windows als auch Linux-Distries haben hier über die Jahre deutlich nachgebessert, aber letztlich: Bisher hat noch NIEMAND eine wirklich brauchbare Lösung für das Problem gefunden, Sicherheit und Benutzbarkeit unter einen Hut zu bringen. Ich neige inzwischen dazu, das für einen unauflösbaren Widerspruch zu halten.
c-hater schrieb: > Das ist der Punkt. Besser ein wirklich gut abgesicherter root-Zugang > (der dann natürlich auch nur auschließlich zu administrativen Zwecken > verwendet wird) als dieses schwachsinnige Gewichse mit sudo. Auf Systemen, die keinen besonderen Sicherheitsanforderungen genügen müssen, ist sudo(1) eine sehr feine Sache. Allerdings wissen auch erfahrene UNIX-Sysops oft nicht, was damit alles möglich ist. Obendrein ist heutzutage ohnehin der Nutzer meistens die mit Abstand größte aller Schwachstellen. > Das Problem ist halt nur, dass selbst dieses Grundkonzept nicht wirklich > die Lösung für alle Probleme sein kann. Immer dann, wenn teilweise > "Delegierungen" von administrativen Aufgaben erforderlich werden, muss > man zwangsweise auf sudo und Konsorten zurückgreifen. Technologien wie RSBAC, SE-Linux, AppArmor, Contol Groups, Namespaces, File Access Control Lists und Extended File Attributes existieren. Man müßte sie nur benutzen, aber meistens ist das gar nicht nötig. Ansonsten erhöht das Einhalten der Best Common Practices das Sicherheitsniveau (nicht nur, aber auch von Linux-Systemen) deutlich. Zu diesen Best Common Practices gehört, daß der privilegierte Benutzer root sich niemals und unter keinen Umständen unmittelbar von einem Remotesystem aus anmelden darf, und nein, auch nicht mit einer stark verschlüsselten Verbindungstechnologie wie SSH. Für einen direkten Remote-Login als privilegierter Benutzer root gibt es auch keinen Bedarf. Wie bereits erwähnt, gibt es vorhandene und funktionierende Technlogien zur Privilegienseparation und -Erweiterung. Man muß sie halt konfigurieren und nutzen, wenn man glaubt, ein solch hohes Sicherheitsniveau zu benötigen.
Ein T. schrieb: > Ansonsten erhöht das Einhalten der Best Common Practices das > Sicherheitsniveau (nicht nur, aber auch von Linux-Systemen) deutlich. Zu > diesen Best Common Practices gehört, daß der privilegierte Benutzer root > sich niemals und unter keinen Umständen unmittelbar von einem > Remotesystem aus anmelden darf, und nein, auch nicht mit einer stark > verschlüsselten Verbindungstechnologie wie SSH. Nenn mir doch bitte das Risiko eines root Zugangs per SSH Key mit einem sauber konfigurierten SSH Server.
Ein T. schrieb: > wenn man glaubt, ein solch hohes Sicherheitsniveau zu benötigen. Geglaubt wird in der Kirche. Als alleiniger Benutzer meiner Geräte (also, als Privatuser) braucht man "ein solch hohes Sicherheitsniveau" (frei nach Guttenberg: umgangssprachlich kann man auch root-Rechte sagen). Außer ich gebe mich mit dem Auslieferungszustand meiner Distribution zufrieden. Ein T. schrieb: > Zu diesen Best Common Practices gehört, daß der privilegierte Benutzer > root sich niemals und unter keinen Umständen unmittelbar von einem > Remotesystem aus anmelden darf, Ich bin ja ein Fan von BestPractises, aber in dem konkreten Fall seh ich den Nachteil nicht. Wir reden von einem Pi wo per default sudo kein PW braucht. Ist halt die Frage: willst du Admin-Fachsimpelei im Elfenbeinturm führen oder dem TE weiterhelfen?
Angehängte Dateien:
-
ab-ins-bett.jpg
68 KB
Hans schrieb: > Nur_ein_schaumschläger sondert mal wieder seinen Sondermüll ab Hans schrieb: > Willst du uns gleich wieder was von deinem poor man’s 2FA erzählen? Sieh an, mein Stalker darf heute länger aufbleiben.
Peter Pan schrieb: > Nenn mir doch bitte das Risiko eines root Zugangs per SSH Key mit einem > sauber konfigurierten SSH Server. 1. Der "sauber konfigurierte SSH Server". 2. Mögliche Schwachstellen in der Verschlüsselung des SSH Private Key. 3. Mögliche Schwachstellen in der Verschlüsselung des SSH-Protokolls. 4. Mögliche Kompromittierung des Admin-Desktops. Zu 2. und 3.: es ist schon sehr erstaunlich, wie schnell die Community die Lehren aus der Heartbleed-Geschichte vergessen hat. :-( Leute, Leute, Leute... seid mir nicht böse, aber bei einem direkten Root-Login über SSH steht und fällt die Sicherheit der Sache in einer einzigen Schicht. "Richtige" Sicherheit geht aber davon aus, daß Sicherheitsschichten versagen können, deswegen ist ein mehrschichtiger Ansatz sinnvoller, um das Sicherheitsniveau zu erhöhen.
Le X. schrieb: > Ein T. schrieb: >> wenn man glaubt, ein solch hohes Sicherheitsniveau zu benötigen. > > Geglaubt wird in der Kirche. Gut erkannt, genau deswegen hatte ich diese Formulierung gewählt. > Als alleiniger Benutzer meiner Geräte (also, als Privatuser) braucht man > "ein solch hohes Sicherheitsniveau" (frei nach Guttenberg: > umgangssprachlich kann man auch root-Rechte sagen). Ja, schon klar, alle wollen total sicher sein. Aus meiner Perspektive beginnt Sicherheit aber mit einer Risikoanalyse. Bitte korrigiere mich, wenn ich falsch liege, aber das Sicherheitsniveau eines Paketfilter- oder Proxy-Firewall, oder eines Onlinebanking-Servers mit PCI-DSS, oder eines Systems, das den Regelungen der BaFin oder des HIPAA Act unterliegt, wirst Du auf Deinem Desktop wohl nicht benötigen, oder? > Ich bin ja ein Fan von BestPractises, aber in dem konkreten Fall seh ich > den Nachteil nicht. > Wir reden von einem Pi wo per default sudo kein PW braucht. Das halte ich tatsächlich für eine Fehlkonfiguration, ist aber sicherlich dem Umstand geschuldet, daß ein überwiegender Teil der RasPi-Nutzer keine erfahrenen UNIX- oder Linux-Experten sind. Ich selbst ändere diese Konfiguration schon vor einem ersten Login, meist sogar direkt nach dem Beschreiben der SD-Karte mit dem gewünschten Betriebssystemimage. > Ist halt die Frage: willst du Admin-Fachsimpelei im Elfenbeinturm führen > oder dem TE weiterhelfen? Es erscheint mir durchaus hilfreich für den TO, ihm den Rat zu geben, das, was er sich da vorstellt, nicht zu machen. Dies insbesondere auch, weil es hier so viele "Experten" wie c-hater und sogar echte Fachleute wie Jack gibt, die kein Problem in einer solchen Konfiguration sehen können oder wollen. Dabei liegt zumindest Jack nicht vollkommen daneben, setzt aber leider voraus, daß der TO ein erfahrener Admin sei und die von ihm erwähnten zusätzlichen Maßnahmen zur Absicherung durchführen könne. Diese Prämisse halte ich für problematisch, weil die Frage des TO und seine ausdrückliche Aussage, er sei Linux-Anfänger, eine derartige Expertise keinesfalls vermuten läßt. Insofern finde ich, ja, ein Hinweis auf die Best Common Practices, nämlich sein Vorhaben nicht umzusetzen und keinen direkten Remote-Login als privilegierter Benutzer root zuzulassen, wie das aus guten Gründen ja auch auf vielen anderen Linux- und UNIX-Systemen die Standardeinstellung ist, stellt für den TO eine sinnvolle Hilfestellung dar. Edit: vergessenes Wort ergänzt.
:
Bearbeitet durch User
Ein T. schrieb: > Leute, Leute, Leute... seid mir nicht böse, aber bei einem direkten > Root-Login über SSH steht und fällt die Sicherheit der Sache in einer > einzigen Schicht. Dank der bei den einschlägigen Distris verwendeten kaputten sudo-Config wäre die „zweite Schicht“ in dem von dir gezeichneten Szenario, in dem SSH selbst der Einfallsvektor ist, halt auch eher Dekoration als echter Schutz: Jemand, der erstmal Zugriff mit Userrechten auf so einem System erlangt hat, kann im nächsten Schritt im Normalfall problemlos das für ›sudo‹ genutzte Passwort (üblicherweise ja das Userpasswort) abgreifen, und hat (in der kaputten Config, wohlgemerkt) dann direkt volle Rootrechte – so what? Ein noch schlechterer Schutz als ein nichtvorhandener Schutz ist ein eingebildeter Schutz. Und im Gegensatz zu der Variante, bei der sich Root nur von außen einloggen kann, ist’s bei der Variante, den Root-Login zu verbieten und die Rechte nur lokal zu erlangen, dann auch egal, wie der Bösling Zugriff mit den Userrechten erlangt hat – reicht, dass er drauf ist. Wenn ich abschätzen sollte, ob „Useraccount kompromittiert“ oder „SSH kaputt“ häufiger vorkommt, würde ich dann doch deutlich zu Ersterem tendieren. Best Practice hängt jedoch immer auch ein wenig vom Kontext ab. Einen normalen Pi im LAN, der vielleicht noch etwas Wölkchen für unterwegs anbietet und daher exponiert ist, wird man ganz sicher nicht mit der vollen Packung Sicherheitskonzept belegen, die ein Admin auffahren kann, der geschäftskritische Firmen-IT betreut, und für die Zeit Geld bekommt. Letztlich gibt es auch nicht das eine Konzept, das für jeden passt. OT: warum hast du dir eigentlich ’nen neuen Account geklickt? Ich fand die Verwechselungen eigentlich immer recht witzig
:
Bearbeitet durch User
Ein T. schrieb: > Hans schrieb: >> Nur_ein_schaumschläger sondert mal wieder seinen Sondermüll ab > > Hans schrieb: >> Willst du uns gleich wieder was von deinem poor man’s 2FA erzählen? > > Sieh an, mein Stalker darf heute länger aufbleiben. Und das war eine Urheberrechtsverletzung, herzlichen Glückwunsch. Ich empfehle mich.
> Jemand, der erstmal Zugriff mit Userrechten auf so einem System > erlangt hat, kann im nächsten Schritt im Normalfall problemlos das für > ›sudo‹ genutzte Passwort (üblicherweise ja das Userpasswort) abgreifen, > und hat (in der kaputten Config, wohlgemerkt) dann direkt volle > Rootrechte – so what? Für sudo muss man aber (zumindest ist es bei mir so) das Root-Passwort eingeben. Bei meinem Server geht das SSH Login auch nicht mit root, allerdings nutze ich sudo eher selten und wechsle meist mit "su -" zum Root-Account. Jörg
Joerg W. schrieb: > Für sudo muss man aber (zumindest ist es bei mir so) das Root-Passwort > eingeben. > Bei meinem Server geht das SSH Login auch nicht mit root, allerdings > nutze ich sudo eher selten und wechsle meist mit "su -" zum > Root-Account. Der Punkt ist aber, dass ein Angreifer, der bereits als User angemeldet ist, auch die PATH Variable deiner Shell ändern kann. Damit könnte er ein falsches sudo ablegen, das das eingegebene Passwort im Klartext speichert. Der Angreifer muss zwar warten, bis sich der Admin wieder anmeldet, ab dann hilft das aber auch nicht mehr.
Joerg W. schrieb: >> Jemand, der erstmal Zugriff mit Userrechten auf so einem System >> erlangt hat, kann im nächsten Schritt im Normalfall problemlos das für >> ›sudo‹ genutzte Passwort (üblicherweise ja das Userpasswort) abgreifen, >> und hat (in der kaputten Config, wohlgemerkt) dann direkt volle >> Rootrechte – so what? > > Für sudo muss man aber (zumindest ist es bei mir so) das Root-Passwort > eingeben. > Bei meinem Server geht das SSH Login auch nicht mit root, allerdings > nutze ich sudo eher selten und wechsle meist mit "su -" zum > Root-Account. > Jörg Dann passt der Angreifer die .bashrc an und schon tippst du für ihn bei der nächsten Gelegenheit dein Passwort ein. Toll!
Es kommt wie immer darauf an, was man haben will und wie viel Paranoia der Systemverantwortliche bei seinen Raspberry Pi hat. Ich denke, die Idee sich direkt per SSH als Root per Passwort anzumelden, ist vom Tisch und entspricht nicht dem Stand der Technik. Schon aus praktischen Überlegungen sollte man das verhindern und sei es nur um zu unterbinden, dass ein Angreifer Wörterbuch Attacken auf das Root Passwort versucht. Der Zugang auf dem Raspberry Pi über SSH als Root via Private/Public Keys, kann man machen und es gibt durchaus fälle in den das sinnvoll ist. Hierbei sollte man aber den privaten auf den Rechner des Admins mit einer guten starken Passphrase sicher und idealerweise ein Key-Agent verwenden. Problematisch können in diesem Szenario werden, wenn man als Root ein Agent-Forward über mehrere Maschinen macht und die Gefahr besteht, dass auf der Strecke eine Maschine kompromittiert ist, auf der Maschine könnte ein Angreifer den Socket des Agenten relativ einfach kapern und bei den nachgestalten Systemen so den gleichen Zugang wie der Besitzer des Keys erhalten. Auf der anderen Seite bietet sich ein Key basierter SSH Zugang für Root, vor allen dann an, wenn es regelmäßig automatisierte Aufgaben gibt, welche ein Remote Server auf den Raspberry Pi erledigen muss. Der Klassiker hier wäre eine Backuplösung auf der Basis von rsync & SSH. Eine weitere Lösung, die auch schon hier besprochen wurde, ist, dass sich jeder erstmal als normaler Benutzer zu dem Raspberry Pi verbindet. Vorzugsweise auch ausschließlich per SSH/Key Infrastruktur und dann bei Bedarf für einzelne Befehle sich erweitere Rechte geben lässt. Ich persönlich wähle meisten diesen Ansatz, aber auch hier kann man viel Falsch machen. Es steigert zum Beispiel nicht die Sicherheit, wenn jeder Benutzer via sudo beliebige Befehle ohne Password ausführen darf, also ist es wichtig, dass sudo richtig konfiguriert wird. Wenn man dazu neigt in der Abwägung zwischen Security und Bequemlichkeit, zu Bequemlichkeit tendiert, es gibt ein PAM Modul für sudo, das es erlaubt sudo, ohne Password zu verwenden, wenn man einen gültigen SSH-Key hat. Auf der anderen Seite gibt es auch einige Security Experten, welche das Programm sudo als zu Komplex ablehnen und die Empfehlung aussprechen nur das schlankere su zu verwenden. Der Vorteil von Systemen die nur mit su betrieben werden ist, su kann deutlich weniger als sudo, das macht aber das Audit von su leichter. Bei sudo gab es auch schon CVS, die zu Exploits eskalierten, während bei su alle benutzer das gleiche Passwort verwenden müssen, um root zu werden. Was das für den eigenen Einsatzzweck bedeutet muss jeder selbst abwägen, aber vermutlich ist das shared Passwort im privaten Bereich kein großes Problem, anders könnte es bei einer Firma aussehen. Ich persönlich, bin jedenfalls Fan davon beim täglichen Arbeiten so wenig rechte wie möglich standardmäßig zu besitzen und nur bei Bedarf weitere rechte mit sudo/su anzufordern. Schon, um mich gegen eigene Dummheit abzusichern. Daher werde ich nur für ausgewählte Aktionen kurz mal zu Root und finde die Lösung SSH via Key als User und dann mit sudo/su Root werden am praktikabelsten.
Mal drei Gründe FÜR sudo: - Es ist nachvollziehbar von welchem Useraccount privilegierte Kommandos ausgeführt wurden. - Wird Userzugriff über eine Schwachstelle erlangt ist das Userkennwort i.d.R. nicht bekannt - Speziellen Usern kann Subset privilegierter Kommandos eingeräumt werden (z.B. Dienste neu starten für diverse Supporter/Entwickler)
Joerg W. schrieb: > Für sudo muss man aber (zumindest ist es bei mir so) das Root-Passwort > eingeben. Hier gehts um Raspberry Pi OS (ehemals Raspbian). Da erfordert sudo im default kein PW.
Dave schrieb: > Mal drei Gründe FÜR sudo: > […] Der erste und der letzte Punkt setzen voraus, dass jemand sudo konfiguriert hat, der sich damit auskennt – und dann ist’s, wie sudo tatsächlich gedacht war und auch genutzt werden sollte. Und dann kann sudo tatsächlich einen Sicherheitsgewinn mit sich bringen. Der mittlere Punkt ist hingegen alleinestehend untauglich: wer Userzugriff hat, kann auch das Passwort abgreifen. Nicht sofort, aber sobald der User sudo das nächste Mal ausführt. Wenn der dritte Punkt jedoch sauber umgesetzt worden ist, hält sich der Schaden auch hier in Grenzen. Gibt halt kein Setup, das für jeden gleichermaßen passt. Gibt aber welche, die aus Sicherheitssicht universell untauglich sind, und einem User via sudo sämtliche Rechte einzuräumen, gehört dazu – aber darum ging’s hier ja eigentlich gar nicht, und diese Diskussion gab’s ja auch schon oft genug.
Jack V. schrieb: > Jemand, der erstmal Zugriff mit Userrechten auf so einem System > erlangt hat, kann im nächsten Schritt im Normalfall problemlos das für > ›sudo‹ genutzte Passwort (üblicherweise ja das Userpasswort) abgreifen, Erstmal muß er Benutzerrechte auf dem System bekommen, und dann muß er auch noch unbemerkt das Paßwort abgreifen. Beides ist keineswegs so trivial, wie es sich bei Dir liest, insbesondere dann, wenn es unbemerkt geschehen muß. > Ein noch schlechterer Schutz als ein nichtvorhandener Schutz ist ein > eingebildeter Schutz. Das ist zweifellos richtig, Stichwort Risikokompensation, aber sudo(1) IST in dem hier diskutierten Fall eine vorhandene Hürde, die ein Angreifer erst einmal unter überwinden muß. Jede zusätzliche Hürde, auch eine niedrige, erhöht für den Angreifer das Entdeckungsrisiko und den Aufwand -- und damit die Wahrscheinlichkeit, daß er sich ein leichteres Opfer sucht. Ob Du mit der Default-Konfiguration von sudo(1) in den verbreiteten Distributionen glücklich bist, spielt dabei keine Rolle, und wenn Du sicherheitsbewußt und -informiert bist, diese Konfiguration zu kennen, kannst Du sie binnen weniger Sekunden nach Deinen Wünschen ändern. > Und im Gegensatz zu der Variante, bei der sich Root nur von außen > einloggen kann, ist’s bei der Variante, den Root-Login zu verbieten und > die Rechte nur lokal zu erlangen, dann auch egal, wie der Bösling > Zugriff mit den Userrechten erlangt hat – reicht, dass er drauf ist. Ganz so egal ist das nicht, wie der User die Userrechte erlangt hat, und wenn er die erlangt hat, ist es ohnehin zu spät und das Kind liegt tot im Brunnen. Zudem wird ein Angreifer, der Userrechte auf dem System erlangt hat, sich vermutlich nicht zu lange mit dem Abgreifen von Paßworten aufhalten, sondern die Privilegienerweiterung über einen lokalen Exploit zu erlangen versuchen. > Wenn ich abschätzen sollte, ob „Useraccount kompromittiert“ oder „SSH > kaputt“ häufiger vorkommt, würde ich dann doch deutlich zu Ersterem > tendieren. Da bin ich ganz bei Dir, keine Frage. Hatte ich ja oben schon geschrieben: das mit Abstand größte Sicherheitsrisiko sind die Benutzer. > Best Practice hängt jedoch immer auch ein wenig vom Kontext ab. Einen > normalen Pi im LAN, der vielleicht noch etwas Wölkchen für unterwegs > anbietet und daher exponiert ist, wird man ganz sicher nicht mit der > vollen Packung Sicherheitskonzept belegen, die ein Admin auffahren kann, > der geschäftskritische Firmen-IT betreut, und für die Zeit Geld bekommt. > Letztlich gibt es auch nicht das eine Konzept, das für jeden passt. Ja, natürlich -- aber wenn das Maschinchen sogar von extern erreichbar ist, dann gelten erhöhte Sicherheitsanforderungen -- wie bei jedem System, das von extern erreichbar ist. Deswegen steckt man solche Systeme üblicherweise in ein eigenes Netzwerksegment, die Demilitarisierte Zone (DMZ). Aber das weißt Du ja selbst.
Joerg W. schrieb: > Für sudo muss man aber (zumindest ist es bei mir so) das Root-Passwort > eingeben. ...oder halt das Nutzerpaßwort, das ist bei vielen Distributionen heute bereits so voreingestellt. Ich persönlich finde das bei Weitem nicht so schlimm wie andere Benutzer hier und sehe zumindest noch einen zweiten Vorteil: durch die Abfrage des Paßwortes wird unbedarften und / oder unkonzentrierten Benutzern noch einmal klar verdeutlicht, daß sie jetzt den Komfortbereich verlassen und aufpassen müssen, was sie tun.
Matthias schrieb: > Joerg W. schrieb: >> Für sudo muss man aber (zumindest ist es bei mir so) das Root-Passwort >> eingeben. >> Bei meinem Server geht das SSH Login auch nicht mit root, allerdings >> nutze ich sudo eher selten und wechsle meist mit "su -" zum >> Root-Account. > > Der Punkt ist aber, dass ein Angreifer, der bereits als User angemeldet > ist, auch die PATH Variable deiner Shell ändern kann. Nein, kann er nicht. Als User kann er höchstens SEINE PATH-Variable manipulieren. MEINE kann er nur dann manipulieren, wenn er MEINEN Benutzeraccount übernommen hat, und das sudo(1) (oder, angelegentlich: das SSH-Binary) kann er dann durch eine manipulierte Version ersetzen, wenn er bereits root-Privilegien hat und die Sache ohnehin schon aus meiner Sicht maximal verkackt ist. > Damit könnte er > ein falsches sudo ablegen, das das eingegebene Passwort im Klartext > speichert. Der Angreifer muss zwar warten, bis sich der Admin wieder > anmeldet, ab dann hilft das aber auch nicht mehr. All diese Annahmen gehen davon aus, daß ein Angreifer meinen User-Account knacken und an meinem Environment herumfummeln konnte. Aber so einfach ist das gar nicht, den Useraccount auf einem Linux zu übernehmen, langfristig zu behalten, dann auch noch die gewünschte Information (das Paßwort) irgendwohin zu verschieben oder abzugreifen -- und das alles, ohne daß der User etwas davon mitbekommt. Und dann, wie schon eben erwähnt: wenn ein User MEINEN Account auf MEINEM System knacken konnte, ist sicherheitstechnisch schon sehr massiv etwas schiefgelaufen und meine RasPis mein allerkleinstes Problem.
Ein T. schrieb: > durch die Abfrage des Paßwortes wird unbedarften und / oder > unkonzentrierten Benutzern noch einmal klar verdeutlicht, daß sie jetzt > den Komfortbereich verlassen und aufpassen müssen, was sie tun. Wenn’s denn so wäre: in der Praxis geben die Buntu-User (mal stellvertretend, weil Ubuntu das nunmal salonfähig gemacht hat) beim ersten Befehl ihr Passwort ein, und schreiben dann vor jedem Befehl ihr ›sudo‹ – für die scheint es für „führe aus:“ zu stehen, und nach dem Passwort wird dann auch erstmal nicht mehr gefragt. Und es ist auch absolut nicht schwer, die .bashrc (oder das Äquivalent der benutzten Shell) so zu erweitern, dass das beim Aufruf von sudo eingegebene Passwort ausgeleitet wird, ohne dass der User es merkt – einen Proof of Concept hat mir ein User vor Jahren schon in einem anderen Forum geschickt, mögliche Wege sind weiter oben hier im Thread skizziert. Man muss es nicht mal sonderlich verstecken, weil diese Usergruppe, die ›sudo‹ selbst vor ›ls‹ im ~ schreibt, sicher nicht in die entsprechenen Files guckt, oder gar ein IDS laufen hat, das bei solchen Änderungen Alarm schlagen würde. Aber wie gesagt – die sudo-Diskussion hatten wir schon. Da warst du noch mit dem anderen Account unterwegs. Da gab’s damals keinen Konsens, und so wird es auch hier keinen geben.
imonbln schrieb: > Auf der anderen Seite bietet sich ein Key basierter SSH Zugang für Root, > vor allen dann an, wenn es regelmäßig automatisierte Aufgaben gibt, > welche ein Remote Server auf den Raspberry Pi erledigen muss. Für so etwas gibt es Lösungen wie Ansible oder Fabric, die sich als unprivilegierter Benutzer einloggen und dann per sudo(1) die nötigen Privilegien verschaffen können.
Le X. schrieb: > Joerg W. schrieb: >> Für sudo muss man aber (zumindest ist es bei mir so) das Root-Passwort >> eingeben. > > Hier gehts um Raspberry Pi OS (ehemals Raspbian). > Da erfordert sudo im default kein PW. ...und die Credentials des Standardbenutzers sind bekannt. Aus Sicherheitssicht ist das keine besonders sinnvolle Konfiguration, nein. Aber die Antwort darauf kann ja nicht sein, die Best Common Practices einfach mal komplett über Bord zu werden, und die Konfiguration noch unsicherer zu machen.
Jack V. schrieb: > Der erste und der letzte Punkt setzen voraus, dass jemand sudo > konfiguriert hat, der sich damit auskennt Dein Vorschlag setzt aber voraus, daß sich jemand mit SSH inklusive ssh-keygen(1) und ssh-agent(1) auskennt und das konfiguriert. Wenn das nicht gegeben, reißt Du mit Deiner Empfehlung eine zusätzliche Sicherheitslücke auf, ohne die vorhandene -- die schwache sudo(1)-Konfiguration zu beheben. Am Ende hat der User also zwei Probleme anstatt nur eines Problems... ob das so eine gute Idee ist?
Jack V. schrieb: > Wenn’s denn so wäre: in der Praxis geben die Buntu-User (mal > stellvertretend, weil Ubuntu das nunmal salonfähig gemacht hat) beim > ersten Befehl ihr Passwort ein, und schreiben dann vor jedem Befehl ihr > ›sudo‹ – für die scheint es für „führe aus:“ zu stehen, und nach dem > Passwort wird dann auch erstmal nicht mehr gefragt. Das ist nicht schön, und noch viel schlimmer: wenn sie solcherart über sudo(1) Dateien oder Verzeichnisse anlegen, gehören die root und sie brauchen dann immer wieder sudo(1), um sie zu bearbeiten. > Und es ist auch absolut nicht schwer, die .bashrc (oder das Äquivalent > der benutzten Shell) so zu erweitern, dass das beim Aufruf von sudo > eingegebene Passwort ausgeleitet wird, ohne dass der User es merkt – > einen Proof of Concept hat mir ein User vor Jahren schon in einem > anderen Forum geschickt, mögliche Wege sind weiter oben hier im Thread > skizziert. Doch, das ist ziemlich schwer, sonst würde es ja alle naselang passieren, und die Blogs, Zeitungen, Fernsehnachrichten, Twitter und Youtube wären voll mit Idioten, die "Linux ist unsicher" schreien würden. Das ist aber nicht so -- und jetzt rate, warum? Genau: weil es gar nicht so einfach ist, einen Useraccount auf einem Linux unbemerkt zu kompromittieren, dort Dat(ei)en zu manipulieren, Daten auszuleiten, und so weiter -- und da alles dauerhaft zumindest so lange, bis der User sich wieder mal erweiterte Privilegien verschafft. Übrigens: wenn ich $PATH manipulieren kann, greif ich das Paßwort mit einem manipulierten su(1) ab... auch nix gewonnen, oder? > Aber wie gesagt – die sudo-Diskussion hatten wir schon. Da warst du noch > mit dem anderen Account unterwegs. Da gab’s damals keinen Konsens, und > so wird es auch hier keinen geben. Hier geht es ja um den privilegierten Remote-Zugang. Warum einige User das jetzt wieder zu einer Diskussion über sudo(1) gemacht haben, ist mir schleierhaft. Und diese sudo(1)-Diskussion spielt auch keine Rolle, denn die Aussage "also dies und jenes ist unsicher, da kann der Rest ruhig auch noch unsicherer gemacht und der übliche Stand der Technik ignoriert werden" ist ja wohl nicht ernst gemeint.
Ein T. schrieb: > Hier geht es ja um den privilegierten Remote-Zugang. Genau, und deswegen: Ein T. schrieb: > Übrigens: wenn ich > $PATH manipulieren kann, greif ich das Paßwort mit einem manipulierten > su(1) ab... auch nix gewonnen, oder? → wenn ich aber vollständig verhindere, dass ein User lokal via Passwort Rootrechte erlangen kann, indem ich nämlich root nur den direkten Login mit sicherem Schlüssel erlaube, dann bin ich all diese Szenarien, in denen ein kompromittierter Useraccount durch Abgreifen des Passworts als Sprungbrett dient, schonmal los. Denn entgegen deiner Darstellung ist’s eben nicht schwer: wer Userrechte erlangt hat, kann die entsprechenden Änderungen vornehmen – ob nun PATH, ~/.bashrc oder irgendwas Anderes, ist dabei egal. Und wenn der User lokal zu Root werden kann, kann der Angreifer, der den Useraccount kompromittiert hat, das nunmal auch. Dass es nicht alle Nase lang passiert, liegt eher daran, dass es häufig nicht gar so leicht ist, überhaupt erstmal an den Useraccount zu kommen. Dass man kaum was über die Fälle liest, in denen es doch passiert ist, liegt dann wieder eher daran, dass die betreffenden User das gar nicht mitbekommen. Damals™, in längst verjährter Zeit, hatte ich ’nen Stapel dedizierter Server zur Hand, für die andere Leute bezahlt haben. So Leute vom Typ „ich hab zwar gar keine Ahnung von Linux, aber ich kann mir ja einfach ’nen eigenen Gameserver klicken – muss man ja gar nix für können!!k“. Solange man nicht übertrieben hat und vor allem keine „unerklärlichen” Fehler oder gar Abuse-Mails an den Provider provoziert hat, ist’s denen nie aufgefallen.
Jack V. schrieb: > → wenn ich aber vollständig verhindere, dass ein User lokal via Passwort > Rootrechte erlangen kann, indem ich nämlich root nur den direkten Login > mit sicherem Schlüssel erlaube, dann bin ich all diese Szenarien, in > denen ein kompromittierter Useraccount durch Abgreifen des Passworts als > Sprungbrett dient, schonmal los. Dann benutzt der Angreifer eben einen lokalen Exploit, die sind ja auch nicht sooo selten. Daher, wie gesagt: wenn ein Useraccount kompromittiert wurde, ist der Drops schon gelutscht, und es ist zu spät! > Denn entgegen deiner Darstellung ist’s > eben nicht schwer: wer Userrechte erlangt hat, kann die entsprechenden > Änderungen vornehmen – ob nun PATH, ~/.bashrc oder irgendwas Anderes, > ist dabei egal. Und wenn der User lokal zu Root werden kann, kann der > Angreifer, der den Useraccount kompromittiert hat, das nunmal auch. Der Angreifer muß erstmal die Rechte des richtigen Users erlangen. Und wenn der Angreifer $PATH manipulieren kann und Du sicherheitssensitive Programme nicht über deren absoluten Pfad aufrufst, die Shell also $PATH benutzt, dann kann er Dir auch ein gefaketes ssh(1)-, ssh-keygen(1), ssh-agent(1), gtksu(1), kdesu(1) oder <you name it> unterjubeln, und auf diese Weise Deine Paßworte oder eventuell sogar eine entschlüsselte Kopie Deines privaten SSH-Schlüssels abgreifen. Die Sicherheit der ganzen Angelegenheit steht und fällt also offensichtlich mit Deinem Useraccount -- und sudo(1) spielt dabei nur eine sehr überschaubare Rolle. > Dass es nicht alle Nase lang passiert, liegt eher daran, dass es häufig > nicht gar so leicht ist, überhaupt erstmal an den Useraccount zu kommen. Mein Reden... ;-) ...und genau darum geht's ja. Außerdem dürfen wir ja nicht vergessen, daß wir hier von zwei (2) Systemen reden: vom lokalen Admin-Desktop und vom Remote-Server, hier dem RasPi. Wenn der Desktop des Admins geknackt ist, ist es ohnehin vorbei mit der Sicherheit, denn wie oben schon gesagt: die Möglichkeiten des Angreifers zum Abgreifen von Paßworten sind in diesem Fall nahezu unbegrenzt und beileibe nicht auf sudo(1) beschränkt. Und mit Deiner Idee, root nur remote mit verschlüsseltem SSH Private Key reinzulassen, ist der Sicherheit deswegen nicht gedient. Etwas anderes wäre es mit einer MFA -- mit einem externen Authentifikator, in diesem Fall... Übrigens wird der RasPi meines Wissens mit einem Standardbenutzer "pi" und einem Standardpaßwort "raspberry" ausgeliefert. Das finde ich wesentlich gravierender als die sudo(1)-Konfiguration, insbesondere aber in Kombination damit...
Beitrag #7143624 wurde von einem Moderator gelöscht.
Hans schrieb im Beitrag #7143624: > Da lieferst du gerade selbst das beste Argument dafür, dass ein direkter > root Login gar kein Problem ist, da die zusätzliche Schickt eines > Useraccounts nichts bringt. Aha: weil es für den Angreifer mehrere Möglichkeiten zur Privilegienerweiterung gibt, wenn er bereits einen Useraccount kapern konnte, verzichten wir einfach anderswo auch noch auf ein höheres Schutzniveau... > Ein T. schrieb: >> sudo(1) > > Was soll eigentlich die schwachsinnige (1)? Richtig wäre sudo(8). Auch wenn die meisten Linux-Distributoren die Manpage in die Sektion 8 installieren, würde sie korrekt in Sektion 1 einsortiert -- wie die Manpage von su(1).
Ein T. schrieb: >> Ein T. schrieb: >>> sudo(1) >> >> Was soll eigentlich die schwachsinnige (1)? Richtig wäre sudo(8). > > Auch wenn die meisten Linux-Distributoren die Manpage in die Sektion 8 > installieren, würde sie korrekt in Sektion 1 einsortiert -- wie die > Manpage von su(1). Nö. Wir haben doch gerade gelernt, dass nur ein sorgfältig konfiguriertes sudo ein gutes sudo ist. Also (8). Ganz richtig wäre (1) und (8), wozu gibt es SEE ALSO.
Merkt denn hier keiner, das der TO nach dem Werfen des Stöckchens sich nie wieder gemeldet hat und ihr hier nur noch alleine zum x-ten Mal über Sinn oder Unsinn eines (Remote-) root-Login debattiert.
Und? Ich bin sicher, dass auch andere Leute als der TE aus diesem Thread Nutzen ziehen konnten.
Bauform B. schrieb: > Nö. Wir haben doch gerade gelernt, dass nur ein sorgfältig > konfiguriertes sudo ein gutes sudo ist. Also (8). Ganz richtig wäre (1) > und (8), wozu gibt es SEE ALSO. IMHO wären die Sektionen 1 für sudo(1) und sudoreplay(1), sowie 8 für visudo(8) korrekt. Aber ich glaube, das hat in diesem Thread nicht viel zu suchen.
Ein T. schrieb: > Bauform B. schrieb: >> Nö. Wir haben doch gerade gelernt, dass nur ein sorgfältig >> konfiguriertes sudo ein gutes sudo ist. Also (8). Ganz richtig wäre (1) >> und (8), wozu gibt es SEE ALSO. > > IMHO wären die Sektionen 1 für sudo(1) und sudoreplay(1), sowie 8 für > visudo(8) korrekt. Aber ich glaube, das hat in diesem Thread nicht viel > zu suchen. Ach wieso, du hast den thread doch sowieso schon für deine Ergüsse und die Urheberrechtsverletzung gekapert. Ob du da noch mehr von YHO dazugibst, ist auch schon egal.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.