News Raspberry Pi: Distribution Raspbian gegen Angriffe abgesichert

Hm, mein raspbian bietet mir nur Updats für imagemagick an, wenn ich dist-upgrade ausführe... Staged Rollout oder doch eher config Problem meinerseits?
 
Ich bin noch ein Neuling und habe gerade gestern nach dem installieren vom Webserver, dyndns und Portweiterleitung das Passwort geändert. Empfohlen wurde auch den Benutzername zu wechseln.
Ich fragte mich einfach, ist es nicht sehr einfach als Hacker, an den neuen Benutzername zu kommen?
Jedenfalls ist der bei mir jetzt noch auf "pi".

So weit bin ich noch nicht. Aber ich bin auch auf ein Packet gestossen, dass den PI Automatisch immer Updatet. Wäre ja eigentlich sinnvoll und wird bei mir vermutlich bald installiert.
 
Zuletzt bearbeitet:
DeusoftheWired schrieb:
Mmh … das Sicherheitsdenken in allen Ehren, aber extra ’nen Moni anklemmen ist doch etwas nervig. Hätte man auch lösen können, indem auf den ssh-Zugang standardmäßig erst mal nur von lokalen IPs zugegriffen werden kann. Lösen einige Medienzentrumsdistris für den Raspi auch so.
Es geht, wie im Artikel beschrieben, auch ohne Monitor.

Artikel schrieb:
Von jetzt an muss der SSH-Zugang im Einstellungsdialog raspi-config erst eingeschaltet werden. Das ist bei Verwendung eines Monitors kein Problem, erweist sich aber für Einsatzszenarien ohne eigenes Display und Tastatur als untauglich. Hier mussten sich die Entwickler etwas einfallen lassen. Anwender müssen auf der SD-Karte im Verzeichnis /boot eine leere Datei namens ssh anlegen. Wird diese Datei beim Booten entdeckt, wird SSH automatisch eingeschaltet.
 
GIGU schrieb:
Ich bin noch ein Neuling und habe gerade gestern nach dem installieren vom Webserver, dyndns und Portweiterleitung das Passwort geändert. Empfohlen wurde auch den Benutzername zu wechseln.
Ich fragte mich einfach, ist es nicht sehr einfach als Hacker, an den neuen Benutzername zu kommen?
Jedenfalls ist der bei mir jetzt noch auf "pi".

So weit bin ich noch nicht. Aber ich bin auch auf ein Packet gestossen, dass den PI Automatisch immer Updatet. Wäre ja eigentlich sinnvoll und wird bei mir vermutlich bald installiert.

Der Username ist relativ egal, damit kann man nichts anfangen. Ob man will, dass sich das Ding automatisch updated wage ich zu bezweifeln. Wozu hab ich ein Linux wenn ich dessen Freiheiten wie die volle Kontrolle auch über den Upgradeprozess zu haben, nicht nutze?
 
Autoupdate als Standardeinstellung ist für IT Produkte die tendenziell vom Internet aus erreichbar sind und in Hände von Fachfremden gelangen nicht unbedingt verkehrt. Das hat meinen Augen dann auch nichts mit Linux oder anderen Betriebssystemen / Kerneln zu tun. Mann kann es unter Linux ja dann recht fix an eigene Vorstellungen anpassen.
 
Unter "gegen Angriffe absichern" verstehe ich was anderes / mehr als nen Service nicht zu starten.
Nach der Logik kann ich ein System auch maximal absichern indem ich es einfach ausschalte.
 
Verwirrter schrieb:
@holle231: RaspberryPi als produktives System? Dafuer ist es doch eigentlich nicht gedacht :D (jaja ich weiss, nutzen viele als NAS/Media Player/irgendwas)

Pihole? Ist ein DNS-Server ergo produktiv ;)
 
Capet schrieb:
Wenn SSH, dann nur mit Anmeldung per Public-Key.

Ich habe das schon mehrmals gelesen, aber derzeit melde ich mich mit einem (meiner Meinung nach) sicheren Kennwort an, was grundsätzlch von jedem Rechner aus funktioniert, egal bei wem (Freunde, Verwandte, usw.) ich gerade bin, weil ich mir einfach nur das Passwort merken muss und sonst nichts brauche. Wie ist es dann mit dem Public-Key? Den hab ich ja nicht gerade so zur Hand.
 
Darum hab ich meine Keys bei den anderen Schlüsseln ;-) Kingston Data Traveler SE9 passt an jeden Schlüsselbund und beinhaltet bei mir meine 6, 7 Keys für SSH, Keepass etc., natürlich gibts davon ein Backup. Solange man die Keys nicht in unmissverständlichem Klartext beschriftet ist auch ein allfälliger physischer Verlust nicht besonders tragisch.

Et voilà, Private/Public Key immer dabei :-)
 
Zuletzt bearbeitet von einem Moderator:
zonediver schrieb:
Pihole? Ist ein DNS-Server ergo produktiv ;)
Den Bloat würde ich mir ersparen und Dnsmasq selber einrichten. Das Projekt ist meiner Meinung nach aus den Fugen geraten. Wo wir beim Thema Sicherheit sind, würde ich mich auch nicht darauf verlassen, dass externe Hosts-Files vollständig auf Gefahren abgeklopft und entsprechend sicher bearbeitet werden. Der Code ist mir für das, was im Endeffekt passieren soll, mittlerweile zu aufgebläht. Dann lieber ein eigenes kleines Hosts-Update-Script mit wenigen Zeilen schreiben und somit neben Ruhe wohl auch mehr freie Ressourcen haben.
 
Wie will überhaupt ein Angreifer einen Bruteforce-Angriff auf mein (sicheres) Passwort machen? Dazu muss er erstmal an den Hashcode des Passworts kommen.
 
Wenn Autoupgrade dann bitte nicht einfach in die Chron, dafür gibt (mittlerweile) es ein richtig gutes UnattendetUpgrade Plugin.
 
Capet schrieb:
Wenn SSH, dann nur mit Anmeldung per Public-Key.

Punkt 2 auf der Liste ist dann natürlich noch, den Login als root zu verbieten.
 
Aber teste das bitte ordentlich, wärst nicht der erste der root login verbietet und sich damit aus sperrt. Geht zwar schnell zu fixen, ist trotzen ärgerlich :)
 
Seit Debian Jessie ist doch standardmäßig ein direkter Login über Root und Passwort nicht mehr möglich. Man muss sich erst als User anmelden und dann zum Root ummelden.
 
FANATLA schrieb:
Wie will überhaupt ein Angreifer einen Bruteforce-Angriff auf mein (sicheres) Passwort machen? Dazu muss er erstmal an den Hashcode des Passworts kommen.

da fliegt eh zuerst die Fritzbox weg bevor das 30te Password angekommen ist xD

einen Webserver auf Raspi zu betreiben ist schon mutig; gibt es fail2ban für raspi ?


zum SSH: am besten ist eh noch immer den standardport vom SSH von 22 auf was anderes zu tun, dann ist man 99% der Scriptkiddies los.
 
@phreeze

Da Raspbian auf Debian basiert sollte fail2ban ohne Probleme laufen.
 
phreeze schrieb:
[...]

zum SSH: am besten ist eh noch immer den standardport vom SSH von 22 auf was anderes zu tun, dann ist man 99% der Scriptkiddies los.

Das ist weit weg "von am Besten" real macht es annähernd keinen Unterschied. Es muss trotzdem jede Sicherheitsvorkehrung getroffen werden und ob die Massenanfragen am falschem Port oder an der eigentlichen Absicherung zerschellen ist egal.
 
Sehe ich auch so. Die Mühe extra Ports umzumappen mache ich schon lange nicht mehr.
 
Zurück
Oben