Posts by Martha

sw11 wrote:

Rufe ich sie hingegen ohne "https://" auf (also nur kreuz-kreis-joker.de/), dann wird auch meine Seite angezeigt, allerdings mit "Verbindung nicht sicher". Woran liegt das?

HTTPS schützt den Netzwerkverkehr zwischen Clients (wie z. B. deinem Webbrowser) und deinem Server. Lange Zeit war aber HTTP im Internet Standard, weshalb dein Webbrowser nach wie vor versucht, sich über HTTP (bzw. technischer TCP-Port 80) mit Servern zu verbinden.

Auf Serverseite muss nun explizit konfiguriert werden, dass HTTP-Verbindungen auf HTTPS umgeleitet werden. Dein Server sagt dann dem Webbrowser, dass er HTTPS (bzw. technischer TCP-Port 443) statt HTTP nutzen soll. Ist dies nicht eingestellt, bleibt es dem Webbrowser überlassen, ob er HTTP oder HTTPS nutzt.

Alternativ kannst du in den meisten Webbrowsern per Addon (bspw. HTTPS Everywhere) oder in den Einstellungen konfigurieren, dass sie nur HTTPS nutzen sollen (und nur im Notfall HTTP verwenden). Langfristig werden Webbrowser dies automatisch tun.

Olgsi wrote:

Sollte die Nextcloud dann so sicher wie Google Drive sein?

Die unspektakuläre Antwort: Man kann es nicht so einfach sagen.

Onlinescanner haben immer nur eine sehr eingeschränkte Möglichkeit, Sicherheit zu bewerten. SSL Labs bewertet bspw. nur die Sicherheit der transportierten Daten zwischen deinem Client und dem Server. Es kann aber an vielen anderen Stellen Sicherheitslücken und Schwachstellen geben. Und du musst beachten, dass Sicherheit kein permanenter Zustand, sondern ein kontinuierlicher Prozess ist. Du solltest also dein System stets aktuell halten.

Weitere Sicherheit bekommst du, wenn du clientseitig ver- und entschlüsselst (Ende-zu-Ende-Verschlüsselung). So liegen auf deiner Nextcloud nur verschlüsselte Daten, selbst wenn die serverseitige Verschlüsselung versagt.

DevOwl wrote:

SSH einrichten

Hier kannst du noch Zwei-Faktor-Authentifizierung nutzen (entweder via OATH-TOTP oder seit OpenSSH 8.2 mit U2F).

Sonst kann ich noch diesen Artikel empfehlen, weil er viele Grundüberlegungen anstößt: https://infosec-handbook.eu/blog/wss0-how-to-start/

tab wrote:

Und in dem Fall wird dann keine IP-Adresse gespeichert?

Es geht bei der DSGVO erst einmal nicht nur um die Speicherung von personenbezogenen Daten, sondern generell um die Verarbeitung:

Quote

Art. 4 DSGVO:

„Verarbeitung“ jeden mit oder ohne Hilfe automatisierter Verfahren ausgeführten Vorgang oder jede solche Vorgangsreihe im Zusammenhang mit personenbezogenen Daten wie das Erheben, das Erfassen, die Organisation, das Ordnen, die Speicherung, die Anpassung oder Veränderung, das Auslesen, das Abfragen, die Verwendung, die Offenlegung durch Übermittlung, Verbreitung oder eine andere Form der Bereitstellung, den Abgleich oder die Verknüpfung, die Einschränkung, das Löschen oder die Vernichtung;

Das bedeutet: Jeder Webserver verarbeitet IP-Adressen → Verantwortliche müssen Betroffene nach Artikel 12 über die Datenverarbeitung informieren (was üblicherweise bei einer Webseite über eine Datenschutzerklärung erfolgt).

Da die DSGVO nach Artikel 2 aber unter anderem KEINE „Anwendung auf die Verarbeitung personenbezogener Daten durch natürliche Personen zur Ausübung ausschließlich persönlicher oder familiärer Tätigkeiten“ findet, würde ich als juristischer Laie sagen, dass eine nicht-öffentliche Webseite (bspw. hinter einer Passwortabfrage) auch keine Datenschutzerklärung braucht. Ähnliches dürfte für das Thema Impressum gelten.

Wie immer gibt es aber nur 90 prozentige Gewissheit, wenn man die Leute fragt, die damit ihr täglich Brot verdienen. 😉

ontonautics wrote:

Ein Impressum dürfte ich nicht benötigen, wenn dort ausschließlich steht "Hier entsteht eine neue Webseite". Aber in Sachen Datenschutzerklärung könnte eine solche "Baustellen"-Seite ja ggf. schon Anforderungen nach sich ziehen.

(Bin kein Jurist.)

Ich denke, im Zweifel solltest du sowohl ein Impressum als auch eine Datenschutzerklärung online stellen. Das sollte die rechtlich beste Variante sein. Insbesondere eine Datenschutzerklärung bräuchte quasi jede öffentlich erreichbare Webseite, weil IP-Adressen als personenbezogenes Datum angesehen werden und es deshalb immer zu einer Verarbeitung personenbezogener Daten kommt. Eine „Impressumspflicht“ ist mir nur in Deutschland und Österreich bekannt.

Alternativ könntest du die Seite erst einmal hinter eine .htaccess-Datei setzen oder auf ähnliche Weise nicht öffentlich machen.

Hallo zusammen.

Vielleicht hilft auch dieser Artikel über Security-Gedanken, die man sich als Betreiber eines Servers machen sollte: https://infosec-handbook.eu/blog/wss0-how-to-start/#bsc.

Dazu kann die Serie zur Serversicherheit auch relevant sein.

Das ist der ganz normale „Wahnsinn“ im Internet und dies geschieht nicht nur über Port 22, sondern auch bspw. über Port 21, 80, 443 usw. Die Masse der Angriffe kommt aus Botnetzen. Es ist genau wie Spam: Niemand will es, aber es ist da.

Ansonsten kannst du neben den Tipps von timkoop auch noch Zwei-Faktor-Authentifizierung für SSH einrichten und die erlaubten IP-Adressen einschränken: https://infosec-handbook.eu/blog/wss1-basic-hardening/

IlijaK wrote:

Ähm... kannst du mir bitte erklären wer mit das PHP drauf installiert hat? Also hat es was mit meinem Provider zu tun oder mit Wordpress?

Wenn du Webhosting mietest, teilst du dir einen Server mit vielen Personen. Auf dem Server läuft dann Software wie Apache und PHP, die von netcup installiert und aktuell gehalten wird.

IlijaK wrote:

"PHP Version 5.6.40-0+deb8u2"

Wenn du PHP 5.6 hast, dann ist das nicht gut, weil dies seit 31.12.2018 keine Sicherheitsupdates mehr erhält. Ansonsten solltest du – soweit möglich – immer alle Softwarepakete aktuell halten. Gerade Content Management Systeme wie WordPress und PHP stellen oft Einfallstore für Angreifer dar.

Wie netcup PHP-Updates beim Webhosting ermöglicht, weiß ich aber nicht.

Edit:
Aktuell und unterstützt sind PHP 7.1.29, 7.2.18 und 7.3.5.

Manche Betriebssysteme wie Debian halten Softwarepakete aber auf altem (Feature-)Stand, bringen aber Sicherheitsupdates ein (im Rahmen von Backports). Ob dein Softwarepaket also der neuesten Version entspricht und alle Sicherheitsupdates enthält, musst du auch über dein Betriebssystem prüfen.

janxb wrote:

Doppelpostings finde ich suboptimal, allerdings muss man ihn ohne konkrete Hinweise auch nicht sofort als "Troll" darstellen.

Der Account hat in 10 Minuten fünf Posts an drei verschiedenen Stellen platziert, absolut nichts Konkretes genannt, nur „Nicht nutzen! Große Warnung! Wer kennt Alternativen zu dem Blog?“. An einer Stelle steht „vom Server ausgesperrt”, an anderer Stelle steht „kompletten Server zerschossen“.

Da fällt es schwer zu glauben, dass da nur ein Neukunde über ein Problem gestolpert ist. Abgesehen davon hat man via SCP in der Regel weiter Zugriff auf den Server, selbst wenn man sich bei SSH aussperrt. Oder man setzt den Server einfach neu auf, weil man an den Stellen, die der Blog abdeckt, quasi noch nichts eingerichtet hat.

Ohne eine konkrete Problembeschreibung kann man leider der Person nicht helfen, soweit sie überhaupt Hilfe braucht.

H6G wrote:

er hat auf die Nachfragen bisher nicht geantwortet.

Wird der Account wahrscheinlich auch nicht.

Nur zur Info, iridium ist offenbar ein Troll-Account, um InfoSec Handbook schlechtzumachen, siehe

https://forum.netcup.de/sonsti…osec-handbook/#post118402

https://forum.netcup.de/user/15099-iridium/#recentActivity

Innerhalb von 10 Minuten wurden alle Erwähnungen von der Webseite mit Warnungen versehen. Sonst hat der Account nichts getan, heute registriert.

Warum sollte jemand eine Anleitung von infosec-handbook.eu durcharbeiten und dann zufällig ins netcup Forum gehen, um dort mit nichts Konkretem rumzupöbeln?

julian-w wrote:

Irgendwie hab ich das Gefühl das iridium nur rumtrollt

Ja, ist offensichtlich, siehe seine Aktivitäten: https://forum.netcup.de/user/15099-iridium/#recentActivity

Innerhalb von 10 Minuten wurden alle Erwähnungen von dem Blog in diesem Forum mit Warnungen versehen, die alles andere als konkret oder stichhaltig sind. Sonst hat der Account nichts getan, heute registriert. Offenbar nur mit einem Ziel …

whoami0501 wrote:

Und dann bannt der auch nur für einen gewissen Zeitraum. Klar, das kann man einstellen, aber auch nicht auf für immer.

Da kannst schon Werte wie 99999999999 Sekunden Blockzeit einstellen (so über 3000 Jahre).

Ich würde den Zugriff auf alle Admin-Bereiche grundsätzlich durch die Firewall stark einschränken, sodass sich gar nicht erst jemand damit verbinden kann (evtl. mit Bastion Host).

Wenn ich keine Dienste für „Fremde“ anbiete, könnte auch das Betreiben in einem VPN sinnvoll sein, sodass man erst einmal im VPN sein muss, um den Dienst überhaupt sehen zu können.

Bei Fail2ban solltest du (unabhängig davon) beachten, dass bspw. die aktuelle unter Debian 9 verfügbare Version nur IPv4 kann. Wenn deine Serversoftware also auch IPv6 anbietet, kann Fail2ban da gar nichts machen.

VVV wrote:

Das ist schlicht falsch, jeder Admin der nicht hinterm Mond lebt hasht heutzutage Passwörter, das geht selbstverständlich auch bei XMPP-Servern.

Das bezweifle ich ja nicht. Aus dem Artikel geht aber klar hervor, wie alle Passwörter trotz SCRAM-SHA-1 auslesbar sind, indem man einfach das Log-Level hochstellt. Und das ist für Clients nicht sichtbar. Wenn sich der Nutzer registriert oder wenn er sein Passwort ändert, taucht es im Klartext in den Log-Dateien auf. Völlig unabhängig davon, wie es letztendlich in der Datenbank landet.

Ich denke, dass das Thema wesentlich komplexer ist, als einfach nur zu sagen: „Ich mache etwas und meine Daten sind jetzt sicher“.

1. Dienste/Firmen wie Apple, Facebook, WhatsApp, Google usw. sind in der Regel durch User Experience groß geworden, weil sie nicht-technischen Menschen viele Dinge einfach ermöglichen. Sie sind nicht wegen Ende-zu-Ende-Verschlüsselung oder Datenschutz nach EU-Richtlinie gewachsen. Aus meiner Sicht heißt das: Die Masse interessiert sich für diese Themen nicht. Das sieht man auch daran, dass die Firmen in einer Post-Snowden-Zeit immer mehr User haben.
2. Alternative Dienste/Protokolle usw. erfordern meiner Meinung nach schon viel technisches Verständnis, hohen Zeitaufwand und je nach Client ist die User Experience katastrophal.
   1. Beispiel: XMPP-Messenger Conversations. Dieser hat in den letzten Jahren immer mehr WhatsApp nachgeahmt (sagt sogar der Entwickler), aber potenzielle Nutzer haben ganz andere Probleme, als nur eine nachgeahmte Bedienoberfläche: Wenn Nutzer die App über Google Play beziehen wollen, müssen sie zahlen. Falls nicht, müssen sie sich F-Droid installieren, dafür aber in Android Sicherheitseinstellungen ändern. Dann hat man die App installiert. Da beginnt das nächste Problem: Welchen Server nehmen? Nicht jeder Server unterstützt benötigte Features. Der vorgeschlagene Server conversations.im kostet eine Monatsgebühr nach ein paar Monaten. Dazu kommt noch, dass einige oft empfohlene Server von Privatpersonen betrieben werden, die kaum Angaben über sich machen und die Datenschutzerklärung unvollständig halten. Wenn man dann einen Server hat, kann man sich fragen: OMEMO? OpenPGP? Was ist das? Wieder beginnt es. Dann trifft man vielleicht auf einen iOS-User, der nicht chatten kann, weil er keinen OMEMO-fähigen Client hat. Dafür kann der dann OTR. Das kann aber Conversations nicht. usw usw. Benutzerfreundlich ist etwas anderes.
   2. Beispiel: Unverschlüsselte Daten auf Servern. Ein ganz interessanter Artikel ist dieser: https://infosec-handbook.eu/blog/xmpp-aitm/ Wesentlicher Inhalt: ejabberd-Admins können alles auslesen (inkl. Klartextpasswörter der User) und modifizieren, oder sich als jemand anderes ausgeben. Das Problem besteht bei allen Diensten, die die Accountverwaltung serverseitig vornehmen. Manche Dienste wie Briar oder Signal haben eine clientseitige Accountverwaltung, wo so welche Probleme nicht auftreten. Welcher Nutzer weiß das aber? Oft versucht man ihn von einem Dienst wie WhatsApp wegzulocken, um ihm dann so etwas zu bieten.
3. Letzte Option, um seine Daten nicht großen Firmen oder unbekannten Serverbetreibern zu geben: Selbst Hosten. Ist das aber eine reale Option? Ich lese manchmal hier im netcup-Forum, wie sich Leute einfach einen Server anmieten und dann nach irgendwelchen Anleitungen zum Laufen bekommen. Wenn der Server dann läuft, wird er nie wieder angefasst … evtl. werden noch Updates installiert. Das ist aber kein sicherer Serverbetrieb. Ein eigener Server kommt mit Verantwortung, weil er viel Schaden anrichten kann. Letztendlich sind auch da dann die eigenen Daten nicht sicher. Insbesondere auch, weil der gemietete Server „irgendwo“ steht und physisch überhaupt nicht kontrolliert werden kann (man bedenke hier auch den Katalog an CPU-Schwachstellen, die auf Systemen mit geteilten Ressourcen teils ausnutzbar sind).

Zusammengefasst:

1. Große Firmen weiter nutzen ist einfach und bequem, aber teils zahlt man mit seinen Daten, was weder automatisch illegal noch in allen Ländern etwas Böses ist.
2. Alternative Dienste nutzen bedeutet Zeit und Aufwand zu investieren. Außerdem weiß man teilweise nicht, wo die eigenen Daten landen. Wenn man dann hier im Forum liest, wie manche Server gar nicht gesichert werden …
3. Selbst alles zu hosten halte ich für noch unrealistischer. Solange man den Server nicht physisch kontrolliert, gibt es auch hier nur eine begrenzte Sicherheit. Daneben ist die Option sehr teuer, sehr zeitaufwendig und erfordert mehr als nur „schnell aufsetzen … läuft doch“ und nie wieder anfassen.

Ich möchte einmal eine Empfehlung für das InfoSec Handbook aussprechen:

https://infosec-handbook.eu/

Die Webseite hat mir in den letzten Wochen mit diversen Anleitungen zur Webserver-Sicherheit weitergeholfen. Ich habe vorher nie gewusst, dass man 2FA auch bei SSH nutzen kann, oder welche HTTP-Security-Header es schon alle gibt.

Ich finde besonders gut, dass Artikel oft aktualisiert werden. Da muss man nicht immer wieder auf anderen Blogs nach Updates suchen. Die sind auch im Fediverse (Mastodon) sehr aktiv. So bekommt man die ein oder andere Sicherheitsmeldung schneller als von Heise.

Sehr gut finde ich auch, dass dort Sicherheitskonfigurationen und Datenschutz sehr ernst genommen werden.

Alles bei netcup gehostet.

Die Default-Algorithmen bei SSH ändern sich natürlich mit der Zeit. Das gilt sowohl für KexAlgorithms (Schlüsselaustausch), Ciphers (Verschlüsselungsalgorithmen), MACs (Message Authentication Code) als auch HostKeyAlgorithms (Algorithmus des Host-Schlüssels).

Bei OpenSSH 7.9 (aktuell) gibt es:

3des-cbc

aes128-cbc

aes192-cbc

aes256-cbc

aes128-ctr

aes192-ctr

aes256-ctr

aes128-gcm@openssh.com

aes256-gcm@openssh.com

chacha20-poly1305@openssh.com

Default ist:

chacha20-poly1305@openssh.com,

aes128-ctr,aes192-ctr,aes256-ctr,

aes128-gcm@openssh.com,aes256-gcm@openssh.com

Wenn man die Legacy-Ciphers (Modi CBC und CTR sowie 3DES) streicht, bleiben:

Wenn man sowohl Server als auch Client unter eigener Kontrolle hat und niemand sonst zugreifen soll, würde ich dringend sämtlichen Legacy-Kram abschalten.

Wenn sshd von außen erreichbar ist, kann man die Einstellungen auch bspw. hier testen: https://tls.imirhil.fr/ssh

MrSpock wrote:

Hallo,

habe wie in dem Thread Serversicherheit empfohlen, das Webserversecurity Handbuch angeschaut. Habe gemäß der Anleitung ein Schlüsselpaar generiert auf meinem Clientrechner und den öffentlichen Schlüssel wie im Handbuch beschrieben ssh-copy-id auf den Server geladen. Dort liegt sie auch in dem Homeverzeichnis unter .ssh in der Datei authorized_keys.

Der Artikel wurde gestern geändert. Da steht auch eine lokale Konfiguration der ssh_config weiter unten. Vielleicht hilft dir das bei den Einstellungen und beim Verständnis.

Du kannst dann beispielsweise einfach "ssh hostname" im Terminal eingeben. Keine Hostnamen, kein Username, keine ID-Datei mehr notwendig.

Nur einmal zur Klarstellung:

• BREACH ist ein Angriff auf HTTP-Kompression. Da kann man TLS-Kompression an- und ausschalten wie man will. Es ändert sich nichts. Konkret ist BREACH ein Angriff auf gzip/DEFLATE. Wie es mit dem neueren Brotli aussieht – keine Ahnung, aber nach kurzer Recherche scheint auch Brotli (teils auch als „br“ abgekürzt) angreifbar. Was man gegen BREACH machen kann, steht direkt auf der Webseite des Angriffs: http://www.breachattack.com/#mitigations
• CRIME (CVE-2012-4929) ist ein vorheriger Angriff auf TLS-Kompression, aber nur beim Zusammenspiel von SPDY (heute weiterentwickelt als HTTP/2 im Einsatz) und HTTPS nachgewiesen worden. Hier wird allgemein empfohlen, TLS-Kompression immer client- und serverseitig zu deaktivieren (ist heute oft der Standard).

pucxom wrote:

Und gibt es irgendwo Potential etwas besser zu machen oder "neuere" Best Practices anzuwenden.

Ich kann das InfoSec Handbook empfehlen:
https://infosec-handbook.eu/as-wss/

Da erscheinen neue Artikel zur Webserver-Sicherheit und alte werden ab und an aktualisiert.