SFTP mit root rechten?

[AlexD]

Vorweg: Es geht nicht um Sinn oder Unsinn, oder braucht man oder braucht man nicht. Mich interessiert dazu die Lösung.

Auf meinem System darf root sich nicht per SSH einloggen. Wenn ich per SSH root benötige mache ich mich zum root. Soweit so einfach.

Jetzt nutze ich für die SFTP Verbindung natürlich ich den gleichen Benutzer. Wie bekomme ich jetzt aber auch per SFTP root Rechte?

[bluestar]

Wie bekomme ich jetzt aber auch per SFTP root Rechte?

Gar nicht!

[uname]

root muss sich direkt einloggen können.

Code: Alles auswählen

PermitRootLogin yes

[AlexD]

root muss sich direkt einloggen können.

Code: Alles auswählen

PermitRootLogin yes

Genau das habe ich ja aus Sicherheitsgründen deaktiviert.

Also das was per ssh geht, den user zu wechseln, kann man per sftp im zweiten Schritt nicht machen.

[DeletedUserReAsG]

Genau das habe ich ja aus Sicherheitsgründen deaktiviert.

Wenn du sowieso sftp für Root zulassen willst, kannst du den Shell-Login auch zulassen. Sicherheitstechnisch hängt’s dann beides gleichermaßen an der Authentifikation (guter Schlüssel mit ordentlicher Passphrase vs. „passwort123“) und nimmt sich sonst nix.

[AlexD]

Wenn du sowieso sftp für Root zulassen willst...

Will ich nicht. Hatte gehofft/gedacht, dass ich, wie bei ssh, im zweiten Schritt mich zu root machen kann.

[uname]

Ich glaube auch, dass es falsch ist anzunehmen, dass eine Anmeldung als normaler Benutzer und dann Wechsel zu root sicherer als die direkte Anmeldung als root wäre. Vor allen dann, wenn man entweder das selbe Passwort (sudo) oder das gleiche Passwort (su) verwendet.
Es ist vollkommen normal, dass man wo notwendig, sich direkt per root über SSH oder SFTP anmeldet. Natürlich verwendet man dann SSH-Keys. Sicherer als irgendwelche komischen, einfachen persönlichen Passwörter in Verbindung mit Ubuntu-sudo-Konstrukten ohne zustäzliches, sicheres und abweichendes root-Passwort ist es aber allemal.

[TomL]

Ich glaube auch, dass es falsch ist anzunehmen, dass eine Anmeldung als normaler Benutzer und dann Wechsel zu root sicherer als die direkte Anmeldung als root wäre.

Es gibt da imho schon noch Einflussgrößen, die für mich bei weiterem Abwägen dann ausreichender Anlass waren, keine direkte root-Anmeldung zuzulassen. Tatsache ist, man muss die Key-Files für die root-Anmeldung deutlich zugriffsgeschützter aufbewahren, als man das für die Keyfiles eines unberechtigten Benutzers tun muss, der erst lokal auf dem Server mit eigenem root-Password 'root' wird. Werden User-Keyfiles entführt, kann nicht viel passieren, weil der User eh unberechtigt ist, mit root-Keyfiles hingegen wars das.....

[DeletedUserReAsG]

Das ist aber auch eher ’ne philosophische, als ’ne technische Frage. Man kann’s auch so sehen: wenn der Schlüssel so ungeschützt ist, dass er abhandenkommen könnte, dann ist’s auch das Passwort, welches man eingibt, wenn man mit ›su‹ hantiert.

Auf der anderen Seite würde ein Schlüssel bedingen, dass der Angreifer gleich zwei Dinge in seinen Besitz bringen muss, wenn er damit auf den Server kommen will: den Schlüssel selbst, und die Passphrase. Wenn man dann noch das Root-Passwort auf dem Server auf etwas im Bereich „128 Zeichen, quer durch UTF8“ setzt und lokal sicher(! – also nicht auf der Kiste, von der man sich verbindet) speichert (nur für den Notfall, wird ja normalerweise nie genutzt – man könnte auch das Passwort direkt aus /dev/urandom vergeben und selbst nicht wissen, wenn man mag), hätte auch ’n langsamer Brute&Force- oder auch Keylogging-Angriff eines Angreifers, der bereits als User auf der Kiste ist, keine Aussicht auf Erfolg mehr. Unterm Strich würde ich also sagen, dass der Zugriff direkt als Root via Schlüssel/Passphrase als sicherer einzuschätzen wäre, als der Zugriff als User (womöglich noch nur mit Passwort, ohne Schlüssel) und anschließendem ›su‹ (zwangsweise mit Passwort).

[MSfree]

Auf der anderen Seite würde ein Schlüssel bedingen, dass der Angreifer gleich zwei Dinge in seinen Besitz bringen muss, wenn er damit auf den Server kommen will: den Schlüssel selbst, und die Passphrase.

Es sei denn, man verwendet aus Bequemlichkeit Schlüssel ohne Passphrase.

[TomL]

Unterm Strich würde ich also sagen, dass der Zugriff direkt als Root via Schlüssel/Passphrase als sicherer einzuschätzen wäre, als der Zugriff als User (womöglich noch nur mit Passwort, ohne Schlüssel) und anschließendem ›su‹ (zwangsweise mit Passwort).

Ja, unbedingt, dem stimme ich natürlich zu. Ich verwende auch Keyfiles MIT Passphrase, aber grundsätzlich nur für den unberechtigten User. Das root-Pwd selber auf dem Server ist eines, da bin ich mir absolut sicher, was nicht mit nem Wörterbuch zu knacken ist, nicht mal mit Phantasie. Das Problem ist, dass ich die Keyfiles auf mehreren Laptops installieren muss, damit ich bei Wartungsarbeiten am Laptop mit meinem lokalen Account Zugang zu meinen Ressourcen oder den laufenden Services auf dem Server habe, Aber da ist das Problem... die Laptops befinden sich nicht durchgängig in meiner Kontrolle.

[DeletedUserReAsG]

Das Problem ist, dass ich die Keyfiles auf mehreren Laptops installieren muss, damit ich bei Wartungsarbeiten am Laptop mit meinem lokalen Account Zugang zu meinen Ressourcen oder den laufenden Services auf dem Server habe, Aber da ist das Problem... die Laptops befinden sich nicht durchgängig in meiner Kontrolle.

Das ist in der Tat ’n Problem, gerade die letzte Aussage: dann kannst du also auch nicht sicher sein, ob nicht in der Zeit, in der’s nicht unter deiner Kontrolle ist, so manipuliert wird, dass das Passwort abgefangen werden kann. In dem Szenario ist eigentlich nichts mehr sicher – für die höchste relative Sicherheit würde ich dann wieder auf passphrasegeschützten Schlüssel setzen, den aber extern auf ’nem USB-Stick (gerne auch selbst verschlüsselt) vorhalten. Oder eines dieser 2FA-Verfahren (Yubikey et al) nutzen – wenn das sauber funktioniert, könnte das sogar den Teil ausgleichen, bei dem die Kiste außer Kontrolle ist. Müsste man mal schauen, inwieweit es sich mit SSH vertragen würde.

[TomL]

dann kannst du also auch nicht sicher sein, ob nicht in der Zeit, in der’s nicht unter deiner Kontrolle ist, so manipuliert wird, dass das Passwort abgefangen werden kann.

Ja, genau so ist es. Aber an der Stelle ist wieder ein Punkt erreicht, wo nicht mal mehr der Aluhut hilft, sondern eher die Paranoia behandlungswürdig wird Ich stehe ja Gsd nicht im Fokus irgendwelcher Überwachungsorgane, sondern höchstens im Interesse irgendwelcher digitalen Gelegenheitsdiebe, die keine Chance auslassen, mich abzuzocken. Insofern bin ich da jetzt etwas entspannter und denke, wir sind sicher (...eben so sicher wie ein Laie sein kann).

[OT]
BTW, heute habe ich ne nette Mail bekommen... und alle Achtung... eine höfliche Brgrüßung am Anfang, ein gutgemeinter Rat, eine Entschuldigung und freundliche Verabschiedung am Ende.. hat mir richtig Spaß gemacht, das zu lesen.... ... der Gute hat sich doch viel Mühe mit dem eindeutschen gemacht. Das jetzt hier nur stelltvertretend, für all die, vor denen ich mich eigentlich wirklich schützen will.

"Ich grüße Sie!

Ich habe schlechte Nachrichten für dich.
28.03.2019 - an diesem Tag habe ich Ihr Betriebssystem gehackt und vollen Zugriff auf Ihr Konto erhalten toml@web.de .

Wie war es:
In der Software des Routers, mit der Sie an diesem Tag verbunden waren, gab es eine Sicherheitsanfälligkeit.
Ich habe diesen Router zuerst gehackt und meinen bösartigen Code darauf abgelegt.
Bei der Eingabe im Internet wurde mein Trojaner auf dem Betriebssystem Ihres Geräts installiert.

Danach habe ich alle Daten auf Ihrer Festplatte gespeichert (ich habe Ihr gesamtes Adressbuch, den Verlauf der angezeigten Websites, alle Dateien, Telefonnummern und Adressen aller Ihrer Kontakte).

Ich wollte dein Gerät sperren. Und benötigen Sie eine kleine Menge Geld für das Entsperren.
Aber ich habe mir die Websites angesehen, die Sie regelmäßig besuchen, und kam zu dem großen Schock Ihrer Lieblingsressourcen.
Ich spreche von Websites für Erwachsene.

Ich möchte sagen - du bist ein großer Perverser. Sie haben ungezügelte Fantasie!

Danach kam mir eine Idee in den Sinn.
Ich habe einen Screenshot der intimen Website gemacht, auf der Sie Spaß haben (Sie wissen, worum es geht, oder?).
Danach nahm ich Ihre Freuden ab (mit der Kamera Ihres Geräts). Es stellte sich wunderbar heraus, zögern Sie nicht.

Ich bin fest davon überzeugt, dass Sie diese Bilder Ihren Verwandten, Freunden oder Kollegen nicht zeigen möchten.
Ich denke, 400€ sind ein sehr kleiner Betrag für mein Schweigen.
Außerdem habe ich viel Zeit mit dir verbracht!

Ich akzeptiere nur Bitcoins.
Meine BTC-Geldbörse: 3M4Msm5e61BRLk9bsekEG7SY4AyhYKxTJe

Sie wissen nicht, wie Sie die Bitcoins senden sollen?
Schreiben Sie in einer Suchmaschine "wie Sie Geld an die BTC-Geldbörse senden".
Es ist einfacher als Geld an eine Kreditkarte zu senden!

Für die Bezahlung gebe ich Ihnen etwas mehr als zwei Tage (genau 50 Stunden).
Keine Sorge, der Timer startet in dem Moment, in dem Sie diesen Brief öffnen. Ja, ja .. es hat schon angefangen!

Nach Zahlungseingang zerstören sich meine Viren und schmutzigen Fotos automatisch.
Wenn ich die angegebene Menge nicht von Ihnen erhalte, wird Ihr Gerät gesperrt, und alle Ihre Kontakte erhalten ein Foto mit Ihren "Freuden".

Ich möchte, dass du umsichtig bist.
- Versuchen Sie nicht, mein Virus zu finden und zu zerstören! (Alle Ihre Daten sind bereits auf einen Remote-Server hochgeladen.)
- Versuchen Sie nicht, mich zu kontaktieren (Dies ist nicht möglich, die Absenderadresse wurde zufällig generiert.).
- Verschiedene Sicherheitsdienste helfen Ihnen nicht weiter; Auch das Formatieren einer Festplatte oder das Zerstören eines Geräts ist nicht hilfreich, da sich Ihre Daten bereits auf einem Remote-Server befinden.

P.S. Ich garantiere Ihnen, dass ich Sie nach der Bezahlung nicht mehr stören werde, da Sie nicht mein einziges Opfer sind.
Dies ist ein Hacker-Ehrenkodex.

Ich empfehle Ihnen von nun an, gute Antiviren-Programme zu verwenden und regelmäßig (mehrmals täglich) zu aktualisieren!

Sei nicht böse auf mich, jeder hat seine eigene Arbeit.
Abschied."

[DeletedUserReAsG]

Aber an der Stelle ist wieder ein Punkt erreicht, wo nicht mal mehr der Aluhut hilft, sondern eher die Paranoia behandlungswürdig wird Ich stehe ja Gsd nicht im Fokus irgendwelcher Überwachungsorgane, sondern höchstens im Interesse irgendwelcher digitalen Gelegenheitsdiebe, die keine Chance auslassen, mich abzuzocken.

Aber dann nicht weinen, wenn dann doch der Bot irgendeines Scriptkids mit Exploitz aus’m Dunkelnetz ’nen Keylogger auf deinen Laptop bringt, der dann artig alle Passwörter mitmalt und nach Hause schickt, woraufhin der betreffende Server übernommen und kompromittiert wird, und fortan dem eingangs erwähnten Scriptkid devot zur Verfügung steht.

Setzt natürlich voraus, dass du überhaupt ’nen Server fährst, aber auch andere Szenarien sind denkbar. Das Problem, das ich hier sehe: es ist ’ne Ableitung von „Ich hab doch nix zu verbergen / Ich bin doch nicht wichtig genug“, gepaart mit dem Bild, welches gewisse Mainstreammedien vermitteln, nach dem so ein Angriff aktiv Ressourcen des Angreifers brauchen würde (also dass da ’ne Person wäre, die Zeit und Aufwand in das Aufmachen deiner Kiste stecken würde). Besser wär’s, mit „Alle Maschinen sind gleichermaßen ein gutes Ziel – weil: kostet ja nix, das Script läuft eh schon auf gekaperten Maschinen“ im Hinterkopf zu agieren, und zusehen, dass es diesen Scripten so schwer, wie möglich gemacht wird. Ist aber nur meine persönliche Meinung.

[TomL]

Das Problem, das ich hier sehe: es ist ’ne Ableitung von „Ich hab doch nix zu verbergen / Ich bin doch nicht wichtig genug“,

Das ist natürlich Quatsch... ich bin da schon sehr sensibel und achte genau darauf. Ich bewerte unsere (diese spezielle) Situation jedoch in Kombination mit allen anderen von mir ergriffenen Maßnahmen.... wobei die wichtigsten sind, dass es kein "sudo" gibt, kein Anwender root-Rechte erlangen kann und alle relevanten Dirs mit noexec remountet sind. So einfach geht das also alles nicht. Da muss schon wirklich jemand mit Sachverstand dergestalt Hand anlegen, mit zweifelsfrei auf meine Familie gerichteten Absichten, dass Maßnahmen auch wirklich erfolgreich sind. Irgendwelche Dilettanten bleiben ganz sicher erfolglos, und zufallstreffer sind auch ausgeschlossen.

Die Auswertung meiner Logs hat mir lange gezeigt, dass da keine Menschen hacken... so wie das abläuft, sind es Maschinen. Und denen begegnet meine Firewall mit brachialer Kompromisslosigkeit. *fg*

Code: Alles auswählen

Journal yesterday:
Aug 06 04:04:49 server kernel: Blacklisted IP: IN=eno1 OUT= MAC= SRC=184.105.247.252 
Aug 06 11:11:05 server kernel: Blacklisted IP: IN=eno1 OUT= MAC= SRC=139.162.125.159 
Aug 06 12:17:04 server kernel: Blacklisted IP: IN=eno1 OUT= MAC= SRC=198.108.66.43 
Aug 06 13:26:05 server kernel: Temp.banned IP: IN=eno1 OUT= MAC= SRC=77.247.110.37 
Aug 06 13:26:06 server kernel: Temp.banned IP: IN=eno1 OUT= MAC= SRC=77.247.110.37 
Aug 06 13:26:08 server kernel: Temp.banned IP: IN=eno1 OUT= MAC= SRC=77.247.110.37 
Aug 06 15:52:47 server kernel: Blacklisted IP: IN=eno1 OUT= MAC= SRC=185.53.91.69 
Aug 06 19:22:29 server kernel: Temp.banned IP: IN=eno1 OUT= MAC= SRC=184.154.47.2 
Aug 06 19:22:30 server kernel: Temp.banned IP: IN=eno1 OUT= MAC= SRC=184.154.47.2 
Aug 06 19:22:32 server kernel: Temp.banned IP: IN=eno1 OUT= MAC= SRC=184.154.47.2 
Aug 06 19:22:35 server kernel: Temp.banned IP: IN=eno1 OUT= MAC= SRC=184.154.47.2 
Aug 06 19:22:36 server kernel: Temp.banned IP: IN=eno1 OUT= MAC= SRC=184.154.47.2 
Aug 06 19:22:38 server kernel: Temp.banned IP: IN=eno1 OUT= MAC= SRC=184.154.47.2 
Aug 06 19:22:43 server kernel: Temp.banned IP: IN=eno1 OUT= MAC= SRC=184.154.47.2 
Aug 06 19:22:43 server kernel: Temp.banned IP: IN=eno1 OUT= MAC= SRC=184.154.47.2 
Aug 06 19:22:46 server kernel: Temp.banned IP: IN=eno1 OUT= MAC= SRC=184.154.47.2 
Aug 06 19:22:50 server kernel: Temp.banned IP: IN=eno1 OUT= MAC= SRC=184.154.47.2 
Aug 06 19:22:51 server kernel: Temp.banned IP: IN=eno1 OUT= MAC= SRC=184.154.47.2 
Aug 06 19:22:53 server kernel: Temp.banned IP: IN=eno1 OUT= MAC= SRC=184.154.47.2 
Aug 06 19:22:57 server kernel: Temp.banned IP: IN=eno1 OUT= MAC= SRC=184.154.47.2 
Aug 06 19:22:58 server kernel: Temp.banned IP: IN=eno1 OUT= MAC= SRC=184.154.47.2 
Aug 06 19:23:00 server kernel: Temp.banned IP: IN=eno1 OUT= MAC= SRC=184.154.47.2 
Aug 06 21:52:12 server kernel: Blacklisted IP: IN=eno1 OUT= MAC= SRC=185.53.91.69 

Ich halte es eher für kritisch, wenn Keyfiles auf Android-Smartphones hinterlegt werden... über deren Verbleib hat man wirklich keine Kontrolle. Deswegen mach ich das heute nicht mehr, sondern verwende Android-Geräte nur noch als Router für die Laptops.

[DeletedUserReAsG]

Wenn ein ausnutzbarer Fehler in einem der exponierten Teile des Systems vorliegt, muss der Angreifer es eben nicht mit Sachverstand und direkt auf dich/dein Umfeld zugeschnitten agieren, sondern das Modul in sein Framework einbinden und das Script machen lassen. Konfigurationsfehler/Fehlkonfigurationen sind ja nun wahrlich nicht das einzige Einfallstor (zugegebenermaßen jedoch das, auf welches man selbst noch am meisten Einfluss hat).

Edit zu deinem Edit: deine Firewall nutzt dir überhaupt nix, wenn das Angreiferscript z.B. über manipulierte Mediendateien eine Schwachstelle in einer dazugehörigen Lib nutzt, um zunächst mal Userrechte zu erlangen, und von da aus allerhand andere Sachen durchprobiert.

[TomL]

Ja, richtig, ich leugne das ja auch gar nicht. Ich sage nur, für uns liegt da der Unterschied zwischen Theorie und Praxis. Mit Zugriff von außen ist auf unseren Linux-Systemen definitiv nix zu machen, auf den mit Server-Funkionen laufenden Installationen schon mal gar nicht, das geht -wenn überhaupt- alles nur mit direktem Zugriff über Tastatur und Bildschirm. Und ja, wenn das jemand direkt an der Tastatur tut, kann er erfolgreich sein. Aber wenn das jemand über phsyischen Zugriff auf unsere Hardware tut, zielgerichtet gegen meine Familie, dann habe ich vermutlich größere und bisher unerkannte Probleme, als nur ein gehacktes Password. Bei von außen hackenden Bots und Scripte bin ich jedenfalls völlig entspannt, eben weil die lokal nix unerlaubtes ans Laufen bringen können... und der lokale Anwender kanns (mangels Wissen) auch nicht.

Edit zu deinem Edit: deine Firewall nutzt dir überhaupt nix, wenn das Angreiferscript z.B. über manipulierte Mediendateien eine Schwachstelle in einer dazugehörigen Lib nutzt, um zunächst mal Userrechte zu erlangen, und von da aus allerhand andere Sachen durchprobiert.

Ja, wenn das passieren könnte, dann hätte man den Schaden.... was ich aber hier wegen meiner Maßnahmen für ausgeschlossen halte. Wo soll dieses Angreiferscript herkommen? Wie kommt es auf den Rechner? Wer führt es aus? Dem Anwender fehlende die Rechte zum Starten eines solchen Scriptes. Ohne weitergehende Sachkenntnis kann er den remount auch nicht umgehen. Und keiner von denen kennt das Wort "bash"

[DeletedUserReAsG]

Wo soll dieses Angreiferscript herkommen? Wie kommt es auf den Rechner? Wer führt es aus? Dem Anwender fehlende die Rechte zum Starten eines solchen Scriptes. Ohne weitergehende Sachkenntnis kann er den remount auch nicht umgehen. Und keiner von denen kennt das Wort "bash"

a) aus dem Internetz
b) jemand lädt eine manipulierte Mediendatei (Bild, Video, Audio)
c) der Kernel, nachdem die Lib diesem den Code als ihren, und damit legitim ausführbaren Code präsentiert

Remount ist unerheblich, noexec wirkungslos (der Player/Viewer oder auch Browser läuft ja), ’ne Shell braucht’s dafür auch nicht.

Das Beispiel, was mir gerade einfällt: suche mal nach „Stagefright“ – betraf zwar Android, ist aber im Grunde das gleiche Prinzip. Vor Kurzem gab’s genau so eine Konstellation auch für VLC in Verbindung mit bestimmten Versionen einer externen Lib.

[uname]

Das root-Pwd selber auf dem Server ist eines, da bin ich mir absolut sicher, was nicht mit nem Wörterbuch zu knacken ist, nicht mal mit Phantasie.

Niemand errät komplexe Passwörter oder probiert sie auch. Wenn dein Zugriff per SSH-Key mit Passphrase und noch Passwort für root bei su gehackt wird, dann weil ein Client-Rechner mit Malware vereucht ist, der Key entführt und die beiden Passwörter mitgelesen werden. Besser wäre hier OTP gewesen Auch kann man natürlich den verwendeten SSH-Key in authorized_keys auf spezielle Rechner bzw. IP-Ranges einschränken, sofern der Zugriff aus dem Internet erfolgt.

[TomL]

a) aus dem Internetz
b) jemand lädt eine manipulierte Mediendatei (Bild, Video, Audio)
c) der Kernel, nachdem die Lib diesem den Code als ihren, und damit legitim ausführbaren Code präsentiert

Oh mann... ... das ist doch jetzt ein Szenario, gegen das man sich ja eigentlich gar nicht mehr wehren kann... was mich auch so richtig wütend macht. Das ganze Pwd- und Keyfile-Heckmeck soll doch eigentlich verhindern, das fremde Leute auf unseren Rechnern ihre Programme ausführen können... aber genau das passiert doch dabei... im übertragenen Sinne führen wir den Schadcode sogar selber aus. Um aber wieder aufs Thema zurückzukommen, wenn das passiert ist, ist die Frage nach Keyfile oder Passwort für den SSH-Zugang sowieso irrelevant, weil dann der Einbrecher schon im Haus ist. Und hat er einmal die Kontrolle über das System, braucht er diese Zugangsdaten gar nicht mehr, sondern generiert sich eigene und ist dann nicht mehr Gast, sondern Herr im digitalen Haus.

Meine Anstrengen konzentrieren sich also darauf, den Anwendern keine Rechte zu geben, mit denen sie das System an sich verändern können, und nach Möglichkeit zu verhindern, dass fremde Programme ausgeführt werden können. Wenn allerdings wirklich Schadcode über Youtube oder eine beliebige andere Streaming-Plattform hereinkommen kann, sehe ich mich außerstande, das zu verhindern. Ich weiss auch gar nicht, ob es überhaupt ein Mittel dagegen gibt.

....dann weil ein Client-Rechner mit Malware vereucht ist, der Key entführt und die beiden Passwörter mitgelesen werden.

Ja, kein Widerspruch.... aber wieder die Frage im Zusammenhang mit dem zuvor von mir beschriebenen.... wie kommt diese Schadsoftware auf den Rechner drauf und wer hat sie gestartet? Die Anwender könnens und dürfens nicht, sondern müssten das über den Umweg eines Bash-Execute's tun, was sie aber gar nicht wissen. Ich gehe zur Zeit immer davon aus, dass alle unsere Rechner selbstverständlich die obligatorischen Exploits haben, deswegen gilt auf allen Systemen auch die Devise "nur benötigte Software und Services, keine kompletten Desktop-Environments als rund-um-für-alles-wohlfühl-lösungen", aber das sie jetzt im Moment frei von Malware sind.

Deswegen verzichte ich nach Möglichkeit auch auf den Komfort eigentlich unnötiger grafischer Dialoge zum Einstellen von laufenden Services und Programmen und tue alles notwendige im Terminal. Umso größer die Menge ist, auf die ich verzichte kann, umso kleiner wird die installierte Software-Basis, umso sicherer wird es. Und da behaupte ich, die Infektion geht entweder über physischen Zugriff, vermutlich mit einem Livesystem vom Stick, oder über solche Horror-Szenarios wie sie niemand gerade beschrieben hat.... aber genau gegen diese beiden Angriffe bin ich vermutlich sowieso machtlos.

Wie sieht denn für so ein Dilemma überhaupt eine Lösung aus? Und wie verhält sich der Aufwand und die Wirksamkeit für die Lösung zum Grad der tatsächlichen Bedrohung? Wobei die Relevanz der Bedrohung aber eher nicht dem Wahrscheinlichkeits-Verhältnis eines 6ers im 49'er-Lotto entsprechen sollte.