Posts by Martha

floh79 wrote:

Ebenso ist mir bekannt, daß Newsletterversand (bzw. Info-Mails an mehrere Personen die bei einer Verein üblich ist) mit Hosting-Produkte nicht erlaubt ist (wo steht das eigentlich?)

Siehe netcup AGB, unter „5. Pflichten des Kunden“:

Der Kunde verpflichtet sich, bei der Nutzung der von netcup zur Verfügung gestellten Dienste die maßgeblichen gesetzlichen Vorschriften einzuhalten und Maßnahmen zu unterlassen, die zu einer Störung des Betriebs der Server von netcup führen könnten. Untersagt sind insbesondere folgende Handlungen:

• massenhafter Versand von Emails

Explizit von Newslettern oder Hosting-Produkten ist hier nicht die Rede.

Der massenhafte Versand von E-Mails ist bei netcup verboten, siehe AGB (Punkt 5.5):

Quote

Der Kunde verpflichtet sich, bei der Nutzung der von netcup zur Verfügung gestellten Dienste die maßgeblichen gesetzlichen Vorschriften einzuhalten und Maßnahmen zu unterlassen, die zu einer Störung des Betriebs der Server von netcup führen könnten. Untersagt sind insbesondere folgende Handlungen:

• massenhafter Versand von Emails
• …

TBT wrote:

Windows 7 wird seit 14.01.2020 (!) nicht mehr supported und befindet sich deswegen im "end of life".

Kleine Ergänzung (auch wenn vermutlich in diesem Fall nicht zutreffend):

Je nach Windows 7 Edition kann man noch bis 2023 via ESU offiziell gegen viel Geld Sicherheitsupdates von Microsoft bekommen. Es ist also nicht pauschal so, dass Windows 7 = EOL = keine Sicherheitsupdates mehr.

whoami0501 wrote:

Ist dir hier etwas von einem Ersatz o.Ä. bekannt?

Wie m_ueberall schon schrieb, Expect-CT wird überflüssig, weil es keine ausgestellten/gültigen Zertifikate ohne SCT ab Juni 2021 mehr geben kann. Siehe auch: Expect-CT (MDN Web Docs) (Wenn man da übrigens die Kompatibilitätsmatrix anschaut, scheint Expect-CT von nur wenigen Webbrowsern überhaupt unterstützt worden sein.)

Quote

The Expect-CT will likely become obsolete in June 2021. Since May 2018 new certificates are expected to support SCTs by default. Certificates before March 2018 were allowed to have a lifetime of 39 months, those will all be expired in June 2021.

Hallo zusammen, Textwand folgt.

Ich lese im Internet immer wieder Mythen über sicherheitsrelevante HTTP Response Header (aka HTTP Security Header). Beispielsweise schreiben manche Blogger, man brauche eine lange Liste an Security Headern, damit die Webseite „sicher“ sei. Andere empfehlen Header, die entweder kaum ein Webbrowser spricht (da zu neu) oder welche die seit Jahren gar nicht mehr unterstützt werden (da permanent entfernt).

Ich teile nachfolgend ein paar Informationen, die ich herausgefunden habe. Vielleicht ist das für ein paar Admins/Neulinge interessant zu wissen (Achtung: Ist weder abschließend vollständig noch alles ganz neues Wissen):

• Security Header sollten eine weitere Schutzschicht und nicht die einzige Schicht bei eurer Webapplikation sein (Stichwort: Defense in depth). Wenn eure Webapplikation anfällig für Cross-Site-Scripting (XSS) ist, können euch HTTP Security Header nicht retten. Deshalb gilt: Die darunterliegende Webapplikation oder der Webserver müssen bereits kontinuierlich aktuell gehalten und ausreichend abgesichert werden. Einen Security Header on top auf eine unsichere Webapplikation zu klatschen, ist wie ein Pflaster auf ein gebrochenes Bein.
• Security Header müssen clientseitig unterstützt und befolgt werden. Das heißt ganz konkret: Die gängigsten Webbrowser unterstützen die meisten Security Header und können damit umgehen. Viele nicht so bekannte Webbrowser, Apps oder irgendwelche anderen Webclients (wie bspw. über Python, Java) können nur einen Ausschnitt der möglichen Security Header. Das bedeutet, bei diesen Clients sind die gesetzten Security Header wirkungslos, da sie für den Client praktisch nicht da sind. Dazu kommt, dass gerade die experimentellen Security Header immer wieder modifiziert werden und deshalb auch die gängigsten Webbrowser nicht unbedingt alles unterstützen (Beispiel folgt). Siehe vor allem die Webseite caniuse.com bzw. developer.mozilla.org/de/docs/Web/HTTP/Headers für unterstützte Header. Und natürlich ist die Clientseite aus Security-Sicht nicht mehr unter Kontrolle des Serverbetreibers. Angreifer könnten Clients so modifizieren, dass diese die Security Header einfach ignorieren und damit komplett wirkungslos machen.
• Nur weil irgendein Webtool (z.B. securityheaders.com) sagt, bestimmte Header fehlten, heißt das noch lange nicht, dass man diese Header auch braucht. Teils schlagen diese Tools Header vor, die kaum ein Webbrowser versteht oder sie bringen kaum „echte“ Sicherheit. (Auch hier gleich Beispiele)
• Und noch etwas zu report-to, report-uri, Reporting API, Reporting-Endpoints: Einige der gleich genannten Security Header erlauben das Setzen eines Reporting Endpoints. Das bedeutet, wenn der Client (Webbrowser) nach Empfangen des Headers diesen verarbeitet und irgendein Verstoß auftritt, kann der Webbrowser einen Report an den Endpoint schicken. Der Betreiber des Endpoints (eben bspw. derselbe Betreiber wie der der Webseite) kann dann diesen Report ansehen und entsprechend agieren. Ich habe mir Reports über mehrere Monate schicken lassen. Aus meiner Sicht ist das Thema nur sinnvoll, wenn man selbst Entwickler der Webapplikation ist und diese Reports für Debugging bzw. Anpassen der Header braucht. Für eine Standardwebseite™ sollte man keine Gründe haben, dieses Feature zu nutzen. Insbesondere, weil man bei sicherheitsrelevanten Verstößen auf Clientseite im Regelfall als Serverbetreiber sowieso gar nichts machen kann. Und natürlich kann man bspw. mit uBlock Origin solche Reports im Client abschalten oder die Endpoint-Domain irgendwo blockieren.

Security Header, die man aktuell (Mai 2021) setzen sollte:

• HTTP Strict Transport Security (HSTS): Dieser Header signalisiert dem Client, dass er die Webseite zukünftig über HTTPS statt HTTP aufrufen soll. Dies gilt aktuell als Best Practice. Die gängigsten Webbrowser sollen sogar in naher Zukunft erst über HTTPS und dann via HTTP verbinden (HTTPS by default), wodurch dieser Header an Bedeutung verlieren könnte.
• Referrer-Policy: Dieser Header signalisiert dem Client, was er mit dem „Referrer“-Feld machen soll. Der Client inkludiert den Referrer in seinen HTTP Requests an den Server. Angreifer könnten theoretisch vertrauliche Informationen über den Referrer auslesen. Deshalb kann man den Referrer hier abschalten. Auch das muss natürlich der Client verstehen und auch tun. Natürlich muss man aufpassen, falls die Webapplikation den Referrer braucht.
• X-Content-Type-Options: Dieser Header signalisiert dem Client, dass er die vom Server gesetzten MIME Typen bei CSS und JavaScript beachten soll. Hier gab es früher das Problem, dass Clients den MIME Typen eventuell geraten haben und hier Angriffe möglich waren. Bei diesem Header gibt es nur eine einzige Konfigurationsmöglichkeit. Da kann man eigentlich nicht viel falsch machen.
• Content Security Policy: Dieser Header ist recht mächtig und signalisiert dem Client verschiedene Dinge. Beispielsweise woher der Client JavaScript und CSS laden und ausführen darf, aber auch, ob eine Webseite als iframe geladen werden darf. Hier wird man in der Praxis viele Schwierigkeiten haben, weil man oft nicht weiß, was man denn alles verbieten darf, ohne dass die Webapplikation nicht mehr korrekt funktioniert. Aus meiner Sicht ist eine superstrikte CSP in der Praxis kaum möglich. Das sollte andererseits auch kein Problem sein, wenn die Webapplikation aktuell gehalten und abgesichert wird.

Security Header, die man aktuell (Mai 2021) nicht mehr setzen braucht:

• HTTP Public Key Pinning (deprecated): Dieser Header wird von keinem gängigen Webbrowser mehr unterstützt und dementsprechend ignoriert.
• X-Xss-Protection (deprecated): Dieser Header wird von keinem gängigen Webbrowser mehr unterstützt und dementsprechend ignoriert.
• Expect-CT (deprecated): Dieser Header soll schon nächsten Monat (Juni 2021) offiziell beerdigt werden und fliegt dann aus den Webbrowsern raus.
• Expect-Staple (unklar): Dieser Header ist laut meiner Recherche nie wirklich in gängigen Webbrowsern angekommen, sondern ein Entwurf von Scott Helme, weshalb der Header in seinem Tools securityheaders.com auch empfohlen wird. Ich würde den Header nicht setzen, gerade weil er eben nichts bringt. Er ist einfach nur da.
• X-Frame-Options (Legacy): Dieser Header wird heutzutage über die frame-ancestors Direktive der Content Security Policy gesetzt. Man sollte X-Frame-Options nur setzen, wenn man auch veraltete Clients unterstützen muss, die Probleme mit der Content Security Policy haben (Beispiel: Internet Explorer 11).

Security Header, die man aktuell (Mai 2021) nicht setzen aber im Auge behalten sollte:

• Permissions-Policy (Entwurfsstatus): Dieser Header hieß vormals Feature-Policy. Ähnlich der Content Security Policy kann man hier recht viele Features des Webbrowsers ausschalten, wenn man sie nicht braucht. Das Problem ist aber, dass dieser Header durch den neuen Namen und die vielen unterschiedlichen Features in jedem Webbrowser einen Wildwuchs an Optionen hat und weitestgehend ignoriert wird. Ihn zu setzen, ergibt aktuell keinen Sinn.
• Cross-Origin-Embedder-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy (Living Standard): Diese Familie an Headern adressiert Cross-Origin-Isolation, was nach Spectre und Meltdown relevant ist. Diese sollte man sich definitiv anschauen, aber auch beachten, dass nur die modernsten Webbrowser-Versionen damit umgehen können. Außerdem basteln Mozilla und Google gerade mehr und mehr Isolation by default in ihre Webbrowser.
• Clear Site Data (Entwurfsstatus): Dieser Header ermöglicht lokale Daten der jeweiligen Webseite löschen zu lassen (z.B. Cookies, LocalStorage, Cache). Neuere Webbrowser sollten damit bereits umgehen können. Kann man sich auch anschauen, falls relevant.

So viel zu meiner Recherche. Ich hoffe, es hilft euch.

TL;DR: Diverse Blogs und Tools empfehlen alle paar Wochen, dass man sämtliche HTTP Security Header von A bis Z setzen solle, weil eine Webseite sonst unsicher sei. In der Praxis werden viele dieser ständig empfohlenen Header aber entweder gar nicht mehr oder noch nicht unterstützt, weshalb sie nur subjektiv gefühlt mehr Sicherheit bringen, aber nicht objektiv praktisch.

wimo wrote:

http Zugriff auf seine Webseite/Domain zuzugreifen deaktivieren

Hallo,

HTTP deaktivieren würde ich nicht empfehlen, da immer noch viele Clients standardmäßig zuerst oder nur über TCP Port 80 (HTTP) zu deiner Webseite navigieren.

Das bedeutet, wenn du im Client (bspw. Webbrowser) nicht explizit https:// vor deinen Domainnamen schreibst, wird der Client http:// versuchen und einen Fehler anzeigen, weil auf Port 80 niemand erreichbar ist.

Das ändert sich allerdings gerade, da Chrome, Firefox und Co. https:// zum Standard machen. Das bedeutet, zukünftig werden Webbrowser zuerst über TCP Port 443 (HTTPS) kommen und erst wenn das fehlschlägt, auf http:// zurückfallen. Wichtig ist aber: Das betrifft eben nur die allerneusten Versionen von wenigen Webbrowsern. Wenn deine Besucher bspw. RSS Feed Reader oder irgendwelche anderen Clients/Bibliotheken nutzen (z. B. Go-NEB) trifft das nicht zu.

Best Practice ist aktuell:

• HTTP (TCP Port 80) und HTTPS (TCP Port 443) aktivieren
• Von HTTP mit 301 auf HTTPS umleiten
• Einen HSTS Response Header setzen, sodass Clients mit HSTS Unterstützung sich für die Zukunft merken, deine Webseite nur via HTTPS aufzurufen
• Ggf. in die HSTS Preload List eintragen lassen, sodass Clients mit HSTS Unterstützung auch beim allerersten Aufruf deine Webseite nur via HTTPS aufrufen

Hinweis: Mit HTTP/3 kommt dann noch UDP statt TCP ins Spiel. Aber das ist noch Zukunftsmusik.

@flx wrote:

Als Antwort kam, dass ich (was ich auch vorher schon getan hatte) das OTP-Secret irgendwo aufheben soll um im Falle eines Verlustes des zweiten Faktors OTP neu einrichten zu können.

Das ist in der Regel der Weg, ein Backup für OATH-TOTP anzulegen. Bei TOTP kennen Client und Server dasselbe Geheimnis, von dem (mit ein paar anderen Parametern wie der aktuelle Zeiten) das Einmalpasswort abgeleitet wird. Wenn man sich ein Backup erstellen will, muss man „nur“ dieses Geheimnis aufbewahren, was oft als QR-Code präsentiert wird.

"Backup-Codes" müssen eben auch wieder im Klartext auf dem Server gespeichert werden. Das ist keine schöne Variante.

@flx wrote:

Keine U2F (z.B. Yubikey) unterstützung

U2F gilt bei Webapplikationen bereits als veraltet. WebAuthn (aka FIDO2) ist der aktuelle Stand. Das hat diverse Vorteile, unter anderem muss im Gegensatz zu OATH-TOTP kein Geheimnis auf Serverseite gespeichert werden. Aber auch bei WebAuthn gibt es keinen standardisierten Ansatz, Backups zu erstellen (siehe https://github.com/Yubico/webauthn-recovery-extension).

SMS-basierte Einmalpasswörter sind grundsätzlich unsicherer, aufgrund verschiedener Angriffsszenarien, die es so bei OATH-TOTP nicht gibt. Meiner Meinung nach sollte man das nicht anstreben.

stephanmg wrote:

Das gleiche gilt wohl für einen öffentlichen Blog richtig?

• Impressum: Ja, denn wie schon geschrieben wird es schwer sein, den rein privaten Charakter einer öffentlichen Webseite nachzuweisen, wenn diese für jeden öffentlich erreichbar ist. Wie andere schon hier schrieben: Die Idee des (deutschen/österreichischen) Impressums ist auch eine Art Verbraucherschutz, um die Partei hinter der Webseite identifizieren zu können. (Und natürlich gibt es auch andere Wege, deine „wahre“ Identität als Webseitenbetreiber bei Rechtsstreitigkeiten zu ermitteln, wie bspw. über den Domain Registrar oder Serverhoster.)
• Datenschutzerklärung: Ja, denn wie schon geschrieben, verarbeitet der Webserver mindestens die IP-Adresse, die weitreichend als personenbezogenes/personenbeziehbares Datum gesehen wird.

stephanmg wrote:

Streng genommen auch für öffentliche Social Media Profile? Wenn die Social Media Profile privat sind, wiederum kein Problem?

• Impressum: Nach deutschem Recht müsste dein Social Media Profil ebenso ein Impressum vorweisen, wenn die Punkte des TMG oder MStV greifen. Ob das bei dir der Fall ist, kann dir seriös nur ein Anwalt sagen.
• Datenschutzerklärung: Hier kommt es meiner Ansicht nach darauf an, wer denn eigentlich der Verantwortliche im Sinne der DSGVO ist. Wenn du ein Profil bei Twitter hast, bist du das nicht, sondern Twitter. Dementsprechend muss Twitter darlegen, wie es personenbezogene Daten verarbeitet.

Und ja, die DSGVO und das „alte“ deutsche BDSG oder das „alte“ österreichische DSG 2000 stimmen in vielen Punkten überein. Eine Datenschutzerklärung brauchte man auch schon vor Mai 2018. Das Thema ist seitdem aber mit seinen guten und schlechten Seiten viel stärker in die Medien gekommen.

Und noch ein genereller Hinweis für deutsche Webseitenbetreiber:

Seit November 2020 hat in Deutschland der Medienstaatsvertrag (MStV) den Rundfunkstaatsvertrag (RStV) von 1991 abgelöst. Dementsprechend muss man in seinem Impressum den Satz „Verantwortlicher im Sinne von § 55 Abs. 2 RStV“ in „Verantwortlicher im Sinne von § 18 Abs. 2 MStV“ ändern. Der § 55 RStV und das ganze RStV sind außer Kraft. Einzelne Anwälte empfehlen auf ihren Webseiten auch, diesen Satz auf „Verantwortlich für Inhalte“ o.ä. abzukürzen.

Wichtig: Das ist keine Rechtsberatung. Im Zweifel bitte einen Anwalt mit entsprechender Spezialisierung hinzuziehen.

Meine Meinungen:

stephanmg wrote:

Benötige ich dann ein Impressum? So wie ich das im § 5 TMG lese sollte das nicht der Fall sein.

Ja, du benötigst ein Impressum.

In Deutschland (und bspw. auch in Österreich) ergibt sich die Pflicht eines Impressums aus diversen Gesetzen und Verordnungen, nicht nur aus dem TMG.

• Ob eine Webseite „rein privat“ ist, lässt sich im Zweifel schlecht nachweisen, weil eine Webseite erst einmal öffentlich für jeden erreichbar ist. Anders wäre es nur, wenn du eine rein private Webseite hinter einer Passwortmaske o. Ä. packst, sodass man absolut nichts sieht, außer eben diese Eingabe.
• Ob mit einer Webseite ein wirtschaftliches Interesse verfolgt wird, ergibt sich auch aus vielen verschiedenen Ansichten. Bspw. kann eine Buchempfehlung schon als wirtschaftliches Interesse gesehen werden, wenn du daran auch verdienst (bspw. du erstellst eine Webseite für ein von dir selbst verlegtes Buch). Auch Affiliate-Links können als wirtschaftliches Interesse gesehen werden, genau wie „Spendenbuttons“.

Bei deinem Impressum solltest du auf jeden Fall auch beachten, dass dies immer leicht auffindbar ist (bspw. über den Footer deiner Webseite, den man auf jeder Seite sieht) und die notwendigen Angaben enthält (bspw. Vollständiger Name, postalische Adresse, E-Mail-Adresse oder gleichwertiges wie Telefonnummer, …). Wenn ein Impressum absichtlich nur als Grafik oder hinter JavaScript versteckt wird, kann dies u. U. bei rechtlichen Streitigkeiten zu deinem Nachteil ausgelegt werden.

Bei der Offenlegung („kleines Impressum“, Österreich) sind diese Pflichtangaben übersichtlicher, es muss aber trotzdem leicht auffindbar und zugänglich bleiben.

stephanmg wrote:

Bei einer Auskunft nach DSVGO bin ich wohl verpflichtet auch ohne Cookies?

Ja, du benötigst eine Datenschutzerklärung.

Datenschutz gab es auch schon vor der DSGVO. Die DSGVO verpflichtet dich, „Betroffenen“ zu erklären, wie du ihre personenbezogenen Daten verarbeitest. Eine IP-Adresse wird heute weitgehend als personenbezogenes Datum gesehen. Da dein Webserver immer IP-Adressen verarbeitet, um den Seiteninhalt an den Webbrowser schicken zu können, verarbeitest du auch Daten.

Hier ist Artikel 12 der DSGVO als Einstieg relevant. Er sagt, dass du Betroffenen „in präziser, transparenter, verständlicher und leicht zugänglicher Form in einer klaren und einfachen Sprache“ mitteilen musst, welche ihrer Daten du für welche Zwecke und auf welcher rechtlichen Grundlage verarbeitest. Daneben müssen Betroffene auf ihre Rechte gem. DSGVO hingewiesen werden. Siehe unter anderem Artikel 13 für Pflichtangaben, in denen übrigens auch wieder deine persönlichen Angaben wie Name auftauchen müssen.

Ein 08/15 Generator kann ausreichen, allerdings solltest du dringend prüfen, ob der Inhalt passt. Bei Unternehmen ist einer der kritischen Punkte bspw. das Löschen von personenbezogenen Daten. Wenn du die IP-Adressen von jedem für immer speicherst (was 1) nicht toll und 2) rechtlich fragwürdig ist), sollte in deiner Datenschutzerklärung nicht stehen, dass du sie nach einer Woche löscht. Backups deiner Log-Dateien musst du auch bedenken. Dazu kommen natürlich Infos zur Datenverarbeitung von Dritten (wie bspw. Auftragsverarbeiter). Aufpassen, wenn du externe Ressourcen wie Google Fonts, Analytics usw. einbindest.

Quote

Haut mir jemand auf die Finger, wenn ich eins oder beides nicht habe?

Eher unwahrscheinlich. Bei einer „rein privaten“ Webseite mit keinem/geringem wirtschaftlichen Interesse kommt wahrscheinlich niemand zufällig vorbei und zeigt dich an. Anders kann es schnell werden, wenn du bspw. das Urheberrecht verletzt oder unwahre Äußerungen zu Firmen oder Personen verbreitest.

Deshalb immer sicher fahren mit einem Impressum und einer Datenschutzerklärung. Selbst wenn die nicht 100 % perfekt sind, wird man schwerer argumentieren können, dass du gesetzliche Vorgaben missachtet hättest.

Wichtig: Das ist keine Rechtsberatung. Im Zweifel bitte einen Anwalt mit entsprechender Spezialisierung hinzuziehen.

goudi wrote:

unter zusätzliche Header diesen Wert eingetragen: "Cache-Control: public Strict-Transport-Security: max-age=63072000 X-Frame-Options: DENY"

Es sieht so aus, als wenn du drei verschiedene HTTP Response Header als einen einzigen eingetragen hast. Wie Nano schon schrieb, musst du den HSTS Header einzeln setzen.

Wenn du HSTS nicht gesetzt kriegst, aber deine Nextcloud-Instanz sowieso nur über HTTPS (nicht über HTTP) erreichbar ist, ist der Sicherheitsgewinn hier minimal. HSTS sagt dem Client nur „Hey, wenn du innerhalb der nächsten x Sekunden wiederkommst, nutze HTTPS statt HTTP“. Der Client sieht die Anweisung aber sowieso erst beim ersten Verbindungsaufbau. Wenn du in deinen Clients bspw. HTTPS-only erzwingst oder HTTPS Everywhere nutzt, ist das von der Sicherheit gleich.

„X-Frame-Options“ ist ein Legacy-Header. Den kannst du weglassen und stattdessen eine Content Security Policy setzen. Siehe auch: https://infosec-handbook.eu/blog/wss3-tls-headers/#header

SimonB wrote:

Generelle Server Sicherheit hab ich mir bisher so überlegt:

fail2ban

ufw

unattended-upgrades

root account auf /sbin/nologin

faillog

evtl. IPv6 deaktivieren

Display More

Du bist sehr in der Kategorie „Prävention“ unterwegs. Nicht vergessen, dass Informationssicherheit aus mehr besteht:

• Identifiziere und definiere, was du gegen wen schützen willst: Gegen welche Angreifer willst du dich schützen? Wie wichtig sind einzelne Dienste auf deinem Server? Welche Dienste sollen überhaupt laufen? Welche Ports brauchen die? Unter welchem Account laufen die? Brauchen die Upstream-Server? …
• Implementiere präventive Maßnahmen: Das hast du quasi schon aufgeschrieben. Bedenke, dass du diese Maßnahmen gezielt einsetzt. Gegen was sollen sie schützen? Was sind ihre Grenzen? Was passiert, wenn sie falsch konfiguriert sind?
• Implementiere detektierende Maßnahmen: Viele „Hardening Guides“ kommen mit langen Listen präventiver Maßnahmen. Präventive Maßnahmen helfen aber nicht für immer. Stell dir die präventiven Maßnahmen wie einen Burgwall vor: Irgendein Angreifer kann den immer überwinden. Du brauchst etwas, was Angriffe detektiert. Beispiele: 1) Monitoring von sicherheitsrelevanten Log-Dateien und Benachrichtigung an dich, wenn etwas Seltsames passiert. 2) Integritätsüberwachung wichtiger Systemdateien und regelmäßiger Check, ob die noch alle so sind, wie du sie konfiguriert hast. 3) Benachrichtigung bei SSH-Logins …
• Implementiere reaktive Maßnahmen: Was passiert, wenn der Angreifer deine präventiven Maßnahmen überwindet und die Detektion anschlägt? Stell dir vor, du bist bei der Arbeit/an der Uni/auf dem Klo und wirst über einen SSH-Login benachrichtigt. Was machst du? Gibt es einen Plan, was du prüfst? Gibt es einen Plan, was du abschaltest? Wo ist dein Passwort für den Notfallzugriff unterwegs? …
• Implementiere wiederherstellende Maßnahmen: Was passiert nach dem Brand? Der Angreifer war auf deinem System, du konntest ihn abwehren oder auch nicht. Auf jeden Fall stehst du jetzt da. Was jetzt? Hast du Backups wichtiger Daten? Hast du eine Liste, was auf dem System installiert war? Hast du Backups von Konfigurationsdateien? Hast du eine Liste der Firewalleinstellungen? …

Und bedenke, dass du all diese Maßnahmen regelmäßig auf Wirkung prüfen solltest. Eine eingeschaltete Firewall, die aber nichts blockt, ist nutzlos. Log-Dateien, die niemand überwacht und im Zweifel vom Angreifer bereinigt werden, sind nutzlos. 5 Jahre Backups sind nutzlos, wenn sie alle defekt sind und eine Wiederherstellung nicht funktioniert.

Ich hoffe, dass die Denkanstöße der/dem einen oder anderen noch weiterhelfen. Nie nur an Prävention denken!

Ich vermute mal, dass es hier um den "google-authenticator" für SSH 2FA auf einem Server geht?

jo-so wrote:

In der URL steht ja das Secret für die 2FA drin und als normaler Query-Parameter landet das dann bei Google in den Logs.

Das stimmt natürlich (falls man den Link aufruft und annimmt, dass Google das loggt).

SilSte wrote:

So ein QR-Code sollte doch auch lokal erzeugbar sein.

Klar, da gibt es CLI Tools wie qrencode. Man müsste eben den Inhalt des QR-Codes aus den Einzelparametern zusammenbasteln und dann als Input an qrencode schicken. Das TOTP-Secret sollte auf dem Server in der ~/.google_authenticator liegen.

SilSte wrote:

Geben das denn die Datenschutzbedingungen her? Gerade auch nach Schrems II?

(Keine Rechtsberatung durch mich) Ein TOTP-Secret sollte erst einmal kein personenbezogenes oder personenbeziehbares Datum sein. Also fraglich, ob dies aus Sicht Datenschutz relevant ist. Informationssicherheit ist etwas anderes.

Und nebenbei: Die DSGVO schreibt nicht vor, dass man jede einzelne Datenübermittlung und jeden einzelnen Empfänger von Daten nennt – es reichen Kategorien. Es muss also nicht zwingend Google hier irgendwie genannt werden, falls es eben überhaupt relevant ist.

Ich habe kein Webhosting, aber das liest sich, als sei das Directory Listing beim Webserver deaktiviert.

Du brauchst also entweder konkrete Dateien in deinem Verzeichnis, auf die du verlinkst, oder du versucht über eine .htaccess-Datei in dem Verzeichnis das Directory Listing zu aktivieren: "Options +Indexes".

Edit: Gut, dass wir drei gleichzeitig geantwortet haben. 😁

BrianYT wrote:

Das passiert, wenn ich Java 8 auswähle und ich das Programm starte.

Was steht in der Log-Datei?

BrianYT wrote:

Ist es damit eig. getan, dass er genau die gleichen Rechte wie root hat oder wie läuft das genau ab?

Grundsätzlich legst du einen neuen Nutzer an (adduser [username]). Dieser neue Nutzer kann standardmäßig nichts installieren, deinstallieren oder irgend etwas außerhalb des eigenen home-Ordners machen (/home/[username]/). Der root-Nutzer hingegen, kann „einfach“ alles ändern – da gibt es keinen Mechanismus, der dich davon abhält.

Um als neuer Nutzer auch administrative Tätigkeiten ausführen zu können, muss dieser Nutzer zur „sudo“-Gruppe hinzugefügt werden. Dies machst du mit „usermod -aG sudo [username]“. Sobald du dies gemacht hast, kannst du mit diesem neuen Nutzer administrative Befehle ausführen. Dazu schreibst du dann „sudo [command]“. Der Schutz ist jetzt, dass du nur dann „sudo“ eintippst, wenn du das unbedingt brauchst. Sonst werden Befehle nur mit niedrigen Privilegien ausgeführt. Einen weiteren Schutz hast du dadurch, dass Dritte sich nicht mehr als root-Nutzer bei SSH anmelden können (hier gibt es viele Bots im Internet, die das vollautomatisch Tausende Male pro Minute versuchen). Diese Dritten müssen jetzt auch den Nutzernamen wissen. Das erhöht den Aufwand.

(Das war jetzt eine ganz grobe Erklärung.)

Hi, erst einmal ein „Sicherheitshinweis“:

Du loggst dich offensichtlich als root-Nutzer ein. Du solltest definitiv einen weiteren Nutzer auf deinem System einrichten (adduser [username]) und diesen zur sudo-Gruppe hinzufügen (usermod -aG sudo [username]). Im Anschluss musst du deine SSH-Konfiguration ändern (nano /etc/ssh/sshd_config) und dort das Einloggen mit root verbieten „PermitRootLogin no”.

Da du „sudo“ auch beim root-User eintippst, vermute ich, dass du dich mit Linux noch nicht gut auskennst. Ich empfehle dir, dass du Linux erst einmal lokal in einer VM (bspw. in VirtualBox) installierst und Basis-Befehle lernst. Dies auf einem exponierten Remote-System zu lernen, kann schnell nach hinten losgehen.

Zu deiner Frage:

Welchen Fehler gibt dein Problem aus? Auf dem zweiten Screenshot sieht es so aus, als wenn du Java 11 auswählst. Ist das so gewollt?

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.