Beiträge von Martha

Zitat von vmk

Ist der Apache vom dem System selbst aus per IPv6 erreichbar?

Ja.

Problem erledigt durch einen bekannten Geheimtipp: Server neustarten.

Hallo, ich versuche aktuell IPv6 mit Apache auf dem Server zum Laufen zu bekommen.

Was funktioniert (getestet):

• DNS-Eintrag (AAAA) vorhanden, wird auch extern gefunden
• IPv6 ist in der Firewall für Ports 80 und 443 freigegeben
• Man kann via Ping die IPv6-Adresse des Servers erfolgreich anpingen
• Der Server kann andere Server via IPv6 anpingen
• Apache lauscht (listen) auf den Ports 80 und 443 sowohl über IPv4 als auch über IPv6
• Über IPv4 erreicht man Apache problemlos

Was nicht funktioniert:

• Über IPv6 den Server erreichen

Ich habe die "Listen"-Einstellung in allen Varianten ausprobiert (nur Ports 80/443, explizit mit IP-Adressen, explizit mit [::] davor). Ich habe auch alle "VirtualHost"-Varianten ausprobiert (*, explizit in einer Regel definiert, für IPv4 und IPv6 getrennte Definitionen sowie IPv4 einzeln, IPv6 einzeln und IPv4+IPv6).

Jedes Mal ist Apache via IPv4 verfügbar, aber nicht via IPv6. sudo netstat -lnptu zeigt aber, dass Apache korrekt horcht (IPv4 + IPv6) und die Firewall sollte es durchlassen. Wo ist mein Denkfehler?

Noch einmal zusammengefasst (steht ja eigentlich schon da):

1. Du hast ein Schlüsselpaar aus Private Key und Public Key auf dem lokalen Rechner
2. Du kopierst den Public Key auf deinen Server. Der Private Key bleibt auf dem lokalen Rechner
   1. Jedes Mal, wenn du den Private Key nutzen willst, musst du ein Passwort lokal eingeben. Das liegt daran, dass der Private Key verschlüsselt auf deinem lokalen Rechner gespeichert ist und sozusagen entsperrt werden muss, bevor du ihn für irgendetwas nutzen kannst.
3. Du richtest einen TOTP-Client ein, der dir die Verification Codes (zeitbasierte Einmalpasswörter) generiert

Wenn du dich verbindest:

1. Verbindungsaufbau
2. Dein lokaler Rechner weist sich gegenüber deinem Server mit einer Signatur aus (dazu ist der Private Key notwendig und den entsperrst du eben lokal mit deinem lokalen SSH-Key-Passwort)
3. Der Server prüft die Signatur anhand des Public Keys
4. Wenn alles passt, musst du den zweiten Faktor (TOTP) eingeben
5. Dann zwei Möglichkeiten:
   1. Du gibst das Einmalpasswort korrekt ein → eingeloggt
   2. Du gibst das Einmalpasswort x-Mal falsch ein → Fail2ban erkennt das anhand der Log-Files → Fail2ban sperrt dich gemäß den Einstellungen deines sshd-Jails

Zitat von Kmdt.Brandt

Gibt es eine Möglichkeit über eine neue Jail den google-authenticator hinzuzufügen, und somit einstellen zu können nach wie vielen Versuchen man gelockt wird oder hängt gerade das mit der sshd Jail zusammen?

Das hängt direkt damit zusammen. Da definierst du, wie viele Fehlversuche bis zur Sperrung erlaubt sind und wie lange gesperrt wird.

Zitat von Kmdt.Brandt

Ist damit gemeint dass wenn ich nur AuthenticationMethods publickey,keyboard-interactive verwende, das denn beim erneuten SSH Login nur Verification code: angezeigt wird und der Public Key im Hintergrund "abgefragt" wird nur ohne eine Passwort Aufforderung bzw. Eingabe?

Du musst in deiner sshd Konfiguration nur aktivieren: AuthenticationMethods publickey,keyboard-interactive

• publickey = Authentifizierung mit Public Key erlaubt
• keyboard-interactive = Ist notwendig, damit du den Verification Code eingeben kannst; sozusagen interaktiver Eingabemodus erlaubt

Wenn da noch "password" steht, dann ist damit nicht das Passwort zum Entsperren deines lokalen SSH Private Keys gemeint, sondern die Möglichkeit, sich via SSH mit einem Passwort + Nutzernamen anzumelden. Das willst du aber nicht. Also kein "password". Siehe auch den von mir verlinkten Blog-Artikel.

Zitat von Kmdt.Brandt

Meinst du damit, wenn ich den Befehl etc/init.d/fail2ban status eingebe und etwas weiter unten

Active: active (running) steht?

Dann hast du ziemlich sicher ein Jail für SSH in Fail2ban aktiv und deshalb wirst du geblockt. Entweder deaktivierst du Fail2ban oder du setzt deine IP auf eine Whitelist (bei dynamischer IP sinnlos) oder du entblockst dich via VNC über Server Control Panel (fail2ban-client set ssh unbanip IPADDRESSHERE).

Zitat von Kmdt.Brandt

Was ist hier mit password publickey, ist das nicht für die Eingabe der Passphrase des Benutzers? Oder wozu?

Wenn du password aktiv lässt, kann man sich nicht nur mit dem Public Key anmelden (das ist der wünschenswerte Zustand) sondern auch mit einem Passwort (das sollte deaktiviert sein). Da sollte nur AuthenticationMethods publickey,keyboard-interactive stehen. keyboard-interactive ist für Eingabe des Verification Codes notwendig.

Zitat von Kmdt.Brandt

Also wenn ich mich per SSH anmelde muss ich das Passwort für Passphrase for key "Brandt@server": und Verification code: eingeben.

Dann hast du deinen SSH-Key auf deinem lokalen Rechner mit einem Passwort geschützt. Jedes Mal, wenn du ihn nutzen willst, musst du ihn mit einem Passwort entschlüsseln. Das hat aber nichts mit dem eigentlichen SSH-Zugriff zu tun und passiert nur lokal.

Die Idee ist:

1. Verbindungsaufbau zum Server
2. Nachweis der Client-Identität mit Public Key
3. Bestätigung mit zweitem Faktor (OATH-TOTP)
4. Verbunden

Zitat

AuthenticationMethods publickey,password publickey,keyboard-interactive

Die Zeile sieht seltsam aus. Ansonsten, ist Fail2ban aktiv? Das erkennt so etwas und blockiert dich.

Siehe auch dieser Blog:

https://infosec-handbook.eu/blog/wss1-basic-hardening/#s4

AuthenticationMethods publickey,keyboard-interactive

Normalerweise wird der Public Key ohne Eingabe automatisch erkannt (oder hast du ein Passwort für die Nutzung des Keys vergeben?). Du musst nur den Verification Code eingeben.

Zitat von Georg

Muss der Link/Ziel auch als Text angezeigt werden, also so https://website.tld/unterseite oder kann man auch einen anderen Text nehmen z.B. Besucherinfos und der Link steht im href?

Ich habe noch nie gehört, dass man den Link sichtbar anzeigen muss und das hat auch nichts mit der DSGVO zu tun.

Zitat von Georg

Hallo,

mal so ein paar allgemeine Fragen zur DSGVO eingeworfen:

1. Wenn ich eine Seite über mich betreibe, muss ich mich nicht an die DSGVO halten? Ich dachte auch rein weiße Seiten benötigen eine.

2. Darf Google Maps noch direkt in der Seite eingebunden werden, wenn in der Datenschutzerklärung darauf hingewiesen werden oder bedarf das zwei Klick Verfahren bzw. Einverstädnnis des Nutzers (Checkbox)?

3. Wie sieht es mit weiteren iFrames aus? Muss dies in der Datenschutzerklärung erläutert werden? Benötigt es ein Einverstädnnis?

4. Muss bei einem Kontaktformular eine Checkbox existieren oder reicht es über oder unter "senden" Button ein hinweis anzubringen?

Alles anzeigen

Zweifelsfrei wird dir das alles nur ein Anwalt für Datenschutzrecht erklären können und auch dort hört und liest man immer wieder andere Aussagen.

Grundsätzlich (meine Meinung, bin kein Rechtsanwalt) gehört eine Datenschutzerklärung immer auf eine Webseite, und zwar so, wie es auch schon nach „altem“ Datenschutzrecht vor der DSGVO vorgesehen war. Das ist alles nichts Neues.

Ich würde auch empfehlen, einfach alle Drittquellen in der Datenschutzerklärung anzugeben.

Zum letzten Punkt:

https://www.datenschutz-guru.d…ular-jetzt-eine-checkbox/

Ich würde gerne in dem Thread noch eine Frage ergänzen:

Zitat

Uns reicht zum Abschluss Ihre elektronische Unterschrift.

Was ist darunter zu verstehen? Kryptografische Signatur oder die Tatsache, dass man den AV-Vertrag via CCP generiert hat, also eingeloggt war?

Der Hinweis (oder besser „bewusster Spaß“) dürfte völlig irrelevant sein, da Artikel 2 (1) der DSGVO sagt:

Zitat

1. Diese Verordnung gilt für die ganz oder teilweise automatisierte Verarbeitung personenbezogener Daten sowie für die nichtautomatisierte Verarbeitung personenbezogener Daten, die in einem Dateisystem gespeichert sind oder gespeichert werden sollen.

Ein Fleischer führt mit seinem Gehirn keine ganz oder teilweise automatisierte Verarbeitung durch und sein Gehirn ist auch kein Dateisystem. Das DSG2000, welches hier zusätzlich gilt, da diese Fleischerei in Salzburg sitzt, regelt dies genauso in Art. 2 §4 (1).

Zitat von Trimilur

Wie lange darf ich die IPs (nicht anonymisiert) jetzt speichern, wenn ich sie nicht mit anderen Daten verknüpfe? 7 Tage oder länger?

Solange es für deinen definierten Verarbeitungszweck notwendig ist, wie Mordor schon schrieb.

Und wie in meinem Beispiel schon genannt: Wenn du bspw. illegale Zugriffe auf einen Webserver blockst, wirst du die IP-Adresse logischerweise „für immer“ blockieren wollen. Es wäre absolut unsinnig, nach 7 Tagen IP-Adressen wieder aus den Firewall-Regeln zu entfernen, weil das irgendwo im Internet steht. Es wäre technisch auch unsinnig, diese IP-Adressen zu anonymisieren, sodass die Firewall dann gar nichts mehr damit anfangen kann.

Eine FAQ zu dem Thema „Aufbewahrungsfristen und Löschung nach EU-Datenschutz-Grundverordnung“ findet sich bspw. bei der WKO.

Aber: Bevor Panik ausbricht, sollte beachtet werden, dass einige Aspekte der DSGVO von Land zu Land unterschiedlich sind (siehe bspw. Zusatzregelungen im BDSG und anderen Datenschutzgesetzen in Deutschland) und einige Aspekte der DSGVO erst ab einer bestimmten Mitarbeiteranzahl gelten (bspw. Bestellung DSB).

Von daher: Keine Panik und nicht alles glauben, was irgendwo im Internet steht. Selbst Anwälte, die seit Jahren im Datenschutzrecht tätig sind, widersprechen sich teilweise oder warten die ersten Urteile ab, um mehr Rechtssicherheit zu schaffen. Eine Panikreaktion gem. „Ich darf gar nichts mehr“ hilft niemandem weiter. Wenn man die notwendigen Angaben gem. Artikel 13 und unter Umständen Artikel 14 der DSGVO bereitstellt und weiß, welche personenbezogenen Daten man eigentlich wofür verarbeitet, hat man schon viel „richtig“ gemacht.

Zitat von Andi K

Ich hingegen kann, als einfacher Betreiber größtenteils statischer Webseiten, mit den IPs im Grunde nichts anfangen; habe demnach eigentlich kein Recht dazu IPs grundsätzlich immer zu speichern/speichern zu lassen. Nur bei bedarf z.B. zur Absicherung des Backendes/Kontaktformulars, sehe ich die Speicherung als DSGVo-Konform an; geschieht dann aber nicht über die Logs. Die restlichen Daten aus den Logs brauche ich dennoch.

Auch wenn man statische Webseiten hat, können Angreifer bspw. mit entsprechenden GET-Requests oder POSTs den darunterliegenden Webserver angreifen. Darüber hinaus sehe ich keinen Grund, IP-Adressen, die bspw. versuchen, wp-login.php abzufragen (obwohl es dafür keinerlei Gründe gibt) oder nach Dateien suchen, die es auf dem Webserver gar nicht gibt, dauerhaft zu blockieren.

Im Rahmen des berechtigten Interesses von dir als Serverbetreiber/Anbieter des Contents hast du schon ein Recht, IP-Adressen hierzu zu speichern. Man stelle sich vor, jemand greift munter jeden Tag Webserver an und widerspricht dann der Speicherung seiner IP-Adresse in entsprechenden Firewall-Regeln. Dass das nicht so sinnvoll sein kann, erkennt man hoffentlich schnell.

Zitat von M--

Laut DSGVO (oder einer zuvor beschlossenen Regelung) zählen auch IP-Adressen zu personenbezogenen Daten. Das ist ja ganz wunderbar, denn für die Speicherung selbiger in einer Log kann ich mir eben nicht zuvor eine Zustimmung einholen (wie auch...). Wenn diese nun anonymisiert wären (z.B. in Form eines nicht rekonstruierbaren Hash), dann müssten ich (und viele, viele andere Webseiten-Betreiber) sich nur um die konforme Speicherung von Daten in den eigenen Scripten kümmern.

Das schlimme ist ja auch, dass (nach meinem Wissensstand) selbst private Blogs DSGVO konform umgesetzt werden müssen, da die Besucher von solchen Seiten ihre Daten (IP-Adresse) an Netcup übermitteln. Netcup wiederum ist ein kommerzielles Unternehmen.

• IP-Adressen zählen nicht erst seit DSGVO zu den personenbezogenen Daten.
• In der DSGVO fällt so gut wie jede vorstellbare Aktion im Zusammenhang mit personenbezogenen Daten unter den Sammelbegriff „Verarbeitung“/„Processing“. Es geht da bei Weitem nicht nur um „Speicherung“.
• Daneben lese ich immer wieder, dass man für jedwede Verarbeitung im Sinne der DSGVO die Zustimmung des Betroffenen einholen müsse. Das ist Blödsinn. Es gibt noch ein halbes Dutzend weiterer Rechtsgrundlagen, bspw. das Vorliegen von berechtigtem Interesse. Und die Abwehr von Cyberangriffen auf den eigenen Server zählt ja wohl eindeutig in diese Kategorie (siehe auch Muster-Vorlagen von diversen staatlichen Stellen).
• Hashen von etwas ist Pseudonymisieren (wurde auch mehrfach angesprochen)
• Wenn ein „privater“ Blog personenbezogene Daten zu nicht ausschließlich persönlich/familiären Zwecken verarbeitet, muss er die DSGVO umsetzen – völlig egal, was netcup noch darüber hinaus macht und auch völlig egal, ob man selbst eine Privatperson oder ein Unternehmen ist. Das war faktisch schon jahrelang vorher der Fall, bspw. im deutschen BDSG oder österreichischen DSG2000 und ist nichts Neues. Wie extrem strikt die Begriffe „persönlich/familiäre Zwecke“ gesehen werden, lässt sich bspw. aus der Kommentarliteratur zum BDSG entnehmen. In der Regel fällt ein öffentlich abrufbarer Blog nicht mehr in die Kategorie „persönlich/familiäre Zwecke“. Absolute Rechtssicherheit schafft aber erst eine Klärung durch einen Anwalt, der sich im Datenschutzrecht auskennt und selbst dann gibt es dank ungenauer Floskeln in der DSGVO noch viele Fragezeichen.

Zitat von 8bit

Ich kann hier deiner Logik nicht folgen, warum dies in diesem Fall einen Vertrag zur Auftragsdatenverarbeitung bei netcup erfordern muss. Die Datenhoheit liegt doch bei Dir und nicht bei netcup.

Das ist auch nicht meine Logik, sondern entweder bereits im BDSG-alt geregelt, Ansicht von Rechtsanwälten oder ziemlich eindeutig in der DS-GVO/BDSG-neu.

Gerade bezüglich Webhosting hat das BayLDA schon im Tätigkeitsbericht 2015/2016 festgestellt, dass das Webhosting im Zusammenhang mit personenbezogenen Daten einen Vertrag zur Auftragsdatenverarbeitung nach § 11 BDSG erfordert (https://www.lda.bayern.de/media/baylda_report_07.pdf, ab Seite 39, Punkt 5.2). Zu beachten ist hier, dass erst seit 2017 EuGH/BGH bereits dynamische IP-Adressen als personenbezogen ansehen. Das konnte also in dem Bericht nicht berücksichtigt werden.

Allerdings steht dazu in der iX 1/2018 ab Seite 40 ausführlich, welche neuen Herausforderungen auf Webseitenbetreiber zukommen. Darunter auch, dass ein Vertrag zur Auftragsverarbeitung aufgrund der IP-Adressen mit dem Hostinganbieter notwendig ist, weil diese personenbezogenen Daten bei einem anderen Unternehmen gespeichert werden (bspw. bei netcup).

Zitat von 8bit

Im Falle eines einfachen Webhostings kann dies auf das (technische) protokollieren reduziert werden. Und hier genügt es IMHO den Nutzer über die Nutzung der Daten zu informieren und die Daten nach einer angemessenen Frist zu löschen.

Wenn Nutzerdaten gespeichert werden, z.b. für einen EMail-Adresse für Newsletter, musst du den Nutzer informieren, für einen entsprechenden Schutz sorgen, die Löschbarkeit regeln und im Falle dass die Daten abhanden kommen fristgerecht informieren.

Laut DS-GVO (Artikel 13) müssen dem Betroffenen weitere Informationen bereitgestellt werden, als nur die, die man derzeit noch in gängigen Datenschutzerklärungen findet. Beispielsweise muss diese nun auch Kontaktdaten des Verantwortlichen, die Rechtsgrundlage(n) der Verarbeitung und sämtliche Rechte des Betroffenen enthalten.

Zitat von [netcup] Felix

Ich kann nur nochmals dazu raten sich nicht in Panik versetzen zu lassen und auf keinen Fall auf überteuerte Pauschalangebot von Rechtsanwälten hereinzufallen.

Sehe ich genauso. Aufgrund der wesentlich höheren Bußgelder und der weit bekannten Abmahnwelle im Zusammenhang mit fehlendem Impressum sollte man dies aber auch nicht aus den Augen verlieren.

Zitat von ___

Wenn ich meinen Server kündige sollte, können dennoch Pakete an dessen IP-Adresse geschickt werden und Verbindungsversuche erfolgen. Also erhält Netcup die IP-Adresse des Angreifers bzw. Aufrufers auch ohne mich und ohne Vertrag.

Ich verstehe deinen Einwand (?) nicht ganz. Das wäre so wie: Wenn ich mein Auto verkaufe, kann der nachfolgende Eigentümer ohne mich damit Verkehrsverstöße begehen. Das ändert aber nichts daran, dass du vorher dafür verantwortlich bist.

Genauso ist es beim Server. Das betrifft natürlich nicht nur Webserver, sondern auch Mailserver und jede andere Art von Server, es sei denn, die Datenverarbeitung von dir als Verantwortlicher erfolgt ausschließlich im Rahmen von persönlichen oder familiären Tätigkeiten.

Beispiel: Person A speichert Kontaktdaten von seinem Freundeskreis und Familie in Nextcloud, das bei netcup auf einem vServer gehostet wird. Hierbei muss Person A die Datenschutzgesetze nicht beachten.

Da nun bis zu 20 Millionen Euro Bußgeld bzw. 4 % vom weltweit erzielten Umsatz im vorherigen Geschäftsjahr eines Unternehmens (je nachdem, was höher ist) vorgesehen sind (war vorher max. 50000 €), würde ich da lieber nichts riskieren wollen.

Zitat

ist nicht neu

In dem anderen Beitrag geht es um die Auftragsdatenverarbeitung nach § 11 BDSG alt, ab Mai gilt jedoch die Auftragsverarbeitung nach § 62 BDSG neu/Artikel 28 DS-GVO. Diese neue Regelung überträgt auch wesentliche Pflichten auf den Auftragnehmer (netcup), weil Betroffene nun über die Aufsichtsbehörden auch den Auftragnehmer in die Mangel nehmen können. Das war vorher nicht so.

Darüber hinaus muss jeder Webseitenbetreiber wesentlich mehr Informationen in der Datenschutzerklärung bereithalten, als es derzeit der Fall ist. Ich denke, dass das vielen Leuten nicht klar ist.

Was mir bisher nicht so bewusst war: Jeder Betreiber einer nicht ausschließlich familiär/persönlichen Webseite unterliegt der DS-GVO. Nachdem die IP-Adresse inzwischen als personenbezogenes Datum gilt, erfolgt eine Verarbeitung personenbezogener Daten bereits dann, wenn ein Client die Domain aufruft.

Logischerweise erfordert dies einen Vertrag zur Auftragsverarbeitung mit netcup, da im Falle von Webhosting/vServer/Rootserver personenbezogene Daten bei netcup verarbeitet werden. Gibt es dazu irgendwelche Infos von Seiten netcups? Schließlich ist ja auch der Auftragnehmer nach der DS-GVO wesentlich stärker bei den Pflichten eingebunden.

Problem wohl gefunden:

ldd /usr/lib/apache2/modules/mod_ssl.so

…

libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 (…)

libcrypto.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 (…)

…

Da sollten libssl/libcrypto 1.1 stehen. Es ist auch nur OpenSSL 1.1.0 installiert. Ohne Neukompilieren von Apache wird das nichts. Die Stretch-Version von Apache nutzt noch kein OpenSSL 1.1, nur die unstable …

Oh, vergessen …

Apache-Webserver 2.4.x, OpenSSL 1.1.0. Alle anderen Cipher-Suites aus der Mozilla Modern-Compatibility funktionieren, nur die beiden mit ChaCha20-Poly1305 nicht.

Alle Cipher-Suites sind normal über SSLCipherSuite definiert.

Hallo,

ich besitze einen Debian 9 Rootserver, habe OpenSSL 1.1.0. Alle modernen TLS 1.2 Cipher Suiten sind aktiv, außer die beiden, die ChaCha20 nutzen:

ECDHE-ECDSA-CHACHA20-POLY1305

ECDHE-RSA-CHACHA20-POLY1305

Konnte jemand erfolgreich diese beiden aktivieren? Der Server hat ein ECDSA-/RSA-Zertifikat, die Cipher Suiten sind auch in der Konfiguration eingetragen. Meiner Meinung nach sollten also alle Voraussetzungen erfüllt sein.

Hallo Georg,

das würde ich gerne, wurde mir vom Support aber nicht verraten.