Posts by Martha

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.

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 …