Security-Tools für Netzwerker

Wenn man als Netzwerker oder Admin länger unterwegs ist, begegnet man irgendwann denselben Tool-Namen immer wieder: Nmap, Wireshark, tcpdump, Nessus, Greenbone, Burp Suite, Shodan, Suricata, Snort, Kali Linux, Metasploit, Hashcat, Cobalt Strike und viele mehr.

Manche davon gehören für mich zur Grundausstattung. Andere sind Spezialwerkzeuge für AppSec, Forensik, Blue Team oder Red Team. Wieder andere sollte man kennen, damit man sie richtig einordnet, auch wenn man sie selbst nie produktiv einsetzen würde.

Der entscheidende Punkt ist: Ein Security-Tool ist nicht automatisch ein Hacker-Tool. Es kommt auf Auftrag, Zielsystem, Berechtigung, Dokumentation und Zweck an.

Dieser Artikel ist deshalb kein Ranking und keine Angriffs-Anleitung. Ich schreibe ihn aus der Perspektive eines Netzwerkers, der verstehen will, welche Werkzeuge im Alltag helfen, welche eher in Security-Teams gehören und wo man bewusst vorsichtig sein muss.

Alle Beispiele in diesem Artikel gehören in eigene Systeme, Lab-Umgebungen, Staging-Systeme oder ausdrücklich autorisierte Tests. Sobald ein fremdes Ziel ohne Erlaubnis im Spiel ist, ist die Grenze überschritten.

Die Installationsbeispiele sind bewusst auf Linux ausgelegt, konkret auf Debian, Ubuntu, Kali oder ähnliche Systeme mit apt. Andere Plattformen lasse ich hier bewusst aus, weil ein professionelles Analyse-Setup klarer wird, wenn die Basis ein sauber getrenntes Linux-System ist.

Die richtige Arbeitsumgebung

Für ernsthafte Netzwerk-Analysen würde ich nicht mein normales MacBook Air nehmen. Ein Alltagsgerät ist für Mail, Kundendaten, Browser-Sessions, Passwörter, private Dateien und produktive Zugänge viel zu nah an Dingen, die ich bei Security-Tests sauber trennen will.

Professioneller ist ein dedizierter Linux-Rechner oder eine dedizierte Linux-Workstation. Darauf laufen die Werkzeuge nativ, Netzwerkkarten lassen sich sauber ansprechen, Paketmitschnitte sind einfacher, und man kann Interfaces, Routing, VLANs und Capture-Rechte viel direkter kontrollieren. Viele Tools gehören trotzdem in VMs, weil Snapshots, getrennte Projekte und saubere Rücksetzpunkte im Security-Alltag enorm viel Ärger sparen.

Ein realistisches Setup für professionelle Analysen wäre für mich:

• Alltagsgerät: Kommunikation, Dokumentation, Tickets, Passwortmanager, Admin-Portale.
• Linux-Analyse-Rechner: verschlüsselte Datenträger, Paketmitschnitte, Netzwerkdiagnose, lokale Labs, längere Scans, genug RAM für mehrere VMs.
• Security-VMs: Kali oder Parrot für Red-Team-/AppSec-Werkzeuge, Debian/Ubuntu für Admin- und Blue-Team-Arbeit, Snapshots vor riskanten Tests.
• Netzwerk-Hardware: zusätzlicher USB-Ethernet-Adapter, bei Bedarf 2.5G/10G, ein kleiner managed Switch mit VLANs und Mirror-/SPAN-Port.
• WLAN-Hardware: USB-WLAN-Adapter mit Linux-Support für Monitor Mode und Packet Injection, nur für autorisierte WLAN-Tests.
• Isoliertes Lab: Testziele, absichtlich verwundbare Systeme, eigene Domains, eigene Staging-Websites, getrennte Projektordner.
• Kundenumgebung: nur mit Freigabe, dokumentiertem Scope, definiertem Zeitfenster und klarer Kontaktperson.

Wenn man es sehr professionell aufzieht, hat man zusätzlich separate Netzwerksegmente: ein Management-Netz, ein Lab-Netz, einen Sensor mit Suricata oder Zeek, und eine zentrale Logplattform. Das klingt nach Overkill, ist aber genau der Punkt: Gute Security-Arbeit entsteht nicht nur durch Tools, sondern durch saubere Trennung.

Für WLAN-Analysen ist eine VM oft nur die halbe Lösung; entscheidend ist sauberer USB-Passthrough zum richtigen Adapter.

Das ist näher an dem, was professionelle Security-Leute wirklich nutzen: nicht ein magisches “Hacker-Laptop”, sondern ein kontrollierbares Linux-Setup mit getrennten Arbeitsbereichen, reproduzierbaren Labs und Werkzeugen, die man wieder sauber entfernen oder zurücksetzen kann.

Erst die Ebenen trennen

Bevor man über einzelne Namen spricht, muss man die Ebenen sauber trennen. Sonst klingt alles gleich, obwohl es völlig unterschiedliche Dinge sind.

Ein Tool ist ein einzelnes Werkzeug mit klarer Aufgabe. Nmap scannt Netze, tcpdump zeichnet Pakete auf, Lynis prüft ein System auf Hardening-Punkte.

Ein Framework ist ein erweiterbarer Werkzeugrahmen. Metasploit, Recon-ng oder Volatility bringen Module, Workflows und eine eigene Logik mit.

Eine Plattform bündelt mehrere Funktionen, Benutzer, Datenquellen, Reporting und Integrationen. Beispiele sind Splunk, Censys, Maltego, Nessus, InsightVM, Core Impact oder Cobalt Strike.

Eine Distribution ist ein komplettes Betriebssystem mit vielen vorinstallierten Werkzeugen. Kali Linux und Parrot OS sind keine einzelnen Tools, sondern Arbeitsumgebungen.

Ein Sicherheitskonzept ist noch abstrakter. SIEM und IDS/IPS sind keine Programme, sondern Systemklassen. Splunk kann SIEM-Funktionen liefern, Snort und Suricata sind konkrete IDS/IPS-Engines.

Sichtbarkeit: die wichtigste Grundlage

Als Netzwerker fange ich nicht bei Exploits an. Ich fange bei Sichtbarkeit an. Welche Systeme existieren? Welche Ports sind offen? Welche Pakete gehen wirklich über die Leitung? Welche Dienste antworten? Welche Logs habe ich überhaupt?

Nmap

Nmap ist für mich eines der wichtigsten Werkzeuge überhaupt. Nicht, weil es spektakulär ist, sondern weil es eine simple Frage beantwortet: Was ist im Netz erreichbar?

Auf Debian, Ubuntu oder Kali installiere ich Nmap über die Paketverwaltung.

sudo apt install nmap

In der Praxis nutze ich Nmap für Inventarisierung, Firewall-Checks und Service-Verifikation. Ich will wissen, ob ein Host wirklich nur die erwarteten Ports offen hat, ob ein Dienst nach einer Änderung noch erreichbar ist oder ob irgendwo ein alter Testdienst vergessen wurde.

# Versionscheck gegen ein explizit freigegebenes Testziel von Nmap
nmap -sV scanme.nmap.org

# Nur bestimmte Ports prüfen
nmap -Pn -p 22,80,443 scanme.nmap.org

# Ergebnis sauber für spätere Vergleiche speichern
mkdir -p scans
nmap -sV -oA scans/scanme-baseline scanme.nmap.org

# Eigenes internes Netz nur mit Berechtigung scannen
nmap -sV 192.168.1.0/24

Ich würde Nmap nie einfach blind gegen fremde Netze laufen lassen. Aber im eigenen Netz ist es ein sehr gutes Werkzeug, um Annahmen durch Fakten zu ersetzen.

tcpdump

tcpdump ist die schlichte, direkte Form der Paketaufzeichnung. Wenn ich auf einem Server oder einer Firewall schnell sehen will, ob Pakete ankommen, ist tcpdump oft schneller als jede GUI.

Auf vielen Linux-Systemen ist tcpdump bereits installiert. Sonst kommt es über die Paketverwaltung.

sudo apt install tcpdump

Typische Anwendungen sind DNS-Debugging, Routing-Probleme, Firewall-Regeln, MTU-Probleme oder die Frage: “Kommt der Client überhaupt bis zum Server?”

# Interfaces anzeigen
sudo tcpdump -D

# DNS-Verkehr auf einem Interface beobachten
# Interface-Namen sind je nach Linux-System z. B. eth0, ens18 oder wlan0
sudo tcpdump -i eth0 -nn port 53

# Traffic zu einem bestimmten Host mitschneiden
sudo tcpdump -i eth0 -nn host 192.0.2.10

# Capture für Wireshark speichern
sudo tcpdump -i eth0 -nn -w debug.pcap

Der wichtigste operative Punkt: Captures enthalten schnell sensible Daten. Ich speichere sie nur so lange wie nötig, teile sie nicht unüberlegt und filtere lieber eng als breit.

Wireshark

Wireshark ist für mich das Werkzeug, wenn tcpdump nicht mehr reicht. tcpdump zeigt mir, dass Pakete da sind. Wireshark hilft mir zu verstehen, was in den Protokollen passiert.

Auf Debian, Ubuntu oder Kali installiere ich Wireshark über die Paketverwaltung. Auf Analyse-Rechnern muss man bewusst entscheiden, wer Capture-Rechte bekommt, weil Paketmitschnitte mächtig sind.

sudo apt install wireshark

Ich verwende Wireshark vor allem für HTTP/TLS-Fehler, DNS-Probleme, TCP-Retransmissions, VoIP-Probleme, SMB- oder LDAP-Debugging und zur Analyse von pcaps aus Firewalls oder Servern.

Praktisch arbeite ich oft so: erst mit tcpdump eng mitschneiden, dann die Datei in Wireshark öffnen. Das reduziert Rauschen und verhindert, dass man riesige Captures analysieren muss.

Shodan

Shodan ist keine klassische lokale Software, sondern eine Suchmaschine für exponierte Internet-Systeme. Aus Netzwerker-Sicht ist Shodan spannend, weil es einem zeigt, wie die eigene Infrastruktur von außen aussehen kann.

Man nutzt Shodan über die Weboberfläche oder API. Für ernsthafte Nutzung braucht man einen Account. Ich würde Shodan nicht als “Angriffswerkzeug” sehen, sondern als Spiegel: Welche Systeme tauchen öffentlich auf, obwohl sie vielleicht nicht öffentlich sein sollten?

Praktisch suche ich damit nach eigenen Domains, eigenen IP-Ranges, Zertifikaten, Produkt-Bannern oder vergessenen Services. Besonders interessant ist Shodan für VPN-Gateways, Remote-Access-Systeme, ICS/IoT, alte Webserver und falsch exponierte Management-Oberflächen.

Censys

Censys spielt in einer ähnlichen Liga wie Shodan, ist aber stärker auf Internet-Exposure, Zertifikate, Hosts und Attack-Surface-Management ausgerichtet.

Man kommt über die Webplattform oder API dazu. Für Security-Teams ist Censys nützlich, wenn man nachvollziehen will, welche Zertifikate, IPs, Dienste oder Domains öffentlich sichtbar sind.

Der praktische Wert liegt weniger im “Suchen um des Suchens willen”, sondern im Abgleich: Passt das, was extern sichtbar ist, zu unserem Inventar? Wenn Censys Systeme findet, die im internen Asset-Management nicht existieren, hat man ein Prozessproblem.

Maltego

Maltego ist eine OSINT- und Link-Analyse-Plattform. Es ist kein Scanner, sondern eher ein Werkzeug, um Beziehungen sichtbar zu machen: Domains, IPs, Personen, Organisationen, E-Mail-Adressen, Social-Profile, Infrastruktur.

Man installiert Maltego als Desktop-Anwendung und nutzt je nach Edition unterschiedliche Datenquellen und Transforms. Für reine Netzwerkadministration brauche ich es selten. Für Threat Intelligence, Fraud, Ermittlungen oder komplexere OSINT-Fragen ist es aber sehr stark.

In der Anwendung geht es weniger um einzelne Befehle und mehr um saubere Fragestellungen: Welche Domains hängen an einer Organisation? Welche Zertifikate und Nameserver tauchen auf? Welche Infrastruktur wiederholt sich? Wo sind Beziehungen, die in einer Tabelle verborgen bleiben?

theHarvester

theHarvester ist ein klassisches OSINT- und Recon-Werkzeug. Es sammelt öffentlich sichtbare Informationen wie E-Mail-Adressen, Hosts, Subdomains oder Banner aus verschiedenen Quellen.

Auf Kali ist es meist direkt verfügbar. Sonst installiert man es über das Projekt-Repository oder die Paketquellen der eigenen Distribution.

# Nur gegen eigene oder autorisierte Domains verwenden
theHarvester -d example.com -b crtsh

Die Datenquellen ändern sich regelmäßig. Manche Quellen liefern irgendwann keine Ergebnisse mehr, andere brauchen API-Keys oder haben Rate Limits. Wenn ein Beispielbefehl leer zurückkommt, heißt das nicht automatisch, dass es keine extern sichtbaren Spuren gibt.

Ich würde theHarvester vor allem nutzen, um die eigene externe Sicht zu prüfen: Welche E-Mail-Adressen hängen öffentlich an einer Domain? Welche Subdomains tauchen auf? Was könnte ein Angreifer ohne Login schon sehen?

Recon-ng

Recon-ng ist ein OSINT-Framework mit Workspaces, Modulen und einer Arbeitsweise, die an Metasploit erinnert, aber für Reconnaissance gedacht ist.

Man installiert es typischerweise über Git oder nutzt es in Security-Distributionen. Der Unterschied zu einem Einzeltool ist die Struktur: Man legt Workspaces an, nutzt Module, sammelt Daten und kann Ergebnisse systematischer weiterverarbeiten.

Ich sehe Recon-ng eher bei OSINT-Analysten, Red Teams und Security Engineers als im normalen Admin-Alltag. Es lohnt sich, wenn man wiederholbare Recon-Workflows braucht und nicht nur einmalig eine Domain nachschlägt.

Amass

Amass ist für externe Asset-Discovery und Subdomain-Enumeration sehr nützlich. Gerade bei größeren Umgebungen ist das wichtig, weil vergessene Subdomains oft interessanter sind als die Hauptseite.

Man bekommt Amass über OWASP, GitHub, Paketmanager oder Security-Distributionen. Ich würde mit passiver Enumeration anfangen, weil sie weniger invasiv ist.

# Passive Enumeration einer eigenen oder autorisierten Domain
amass enum -passive -d example.com

Bei Amass würde ich immer kurz die lokale Version und die aktuelle Syntax prüfen. Das Projekt wird gepflegt, und über größere Versionen hinweg können sich Flags, Datenquellen und Workflows ändern.

Praktisch ist Amass interessant, wenn man wissen will, ob alte Testumgebungen, vergessene Staging-Systeme oder verwaiste DNS-Einträge noch öffentlich sichtbar sind.

OSINT Framework

OSINT Framework ist kein Programm, sondern eine kuratierte Link-Sammlung. Genau das macht es nützlich: Man findet schnell passende Quellen für Domains, E-Mail-Adressen, Social Media, Bilder, Telefonnummern, öffentliche Register und viele andere OSINT-Bereiche.

Man installiert nichts. Man nutzt die Website als Orientierung.

Für Netzwerker ist es nicht täglich relevant. Aber wenn man externe Spuren einer Organisation verstehen will, hilft es, die richtigen Quellen zu finden, statt zufällig Suchmaschinenabfragen zusammenzubauen.

Gobuster

Gobuster ist ein Enumerierungswerkzeug für Webpfade, DNS, virtuelle Hosts und ähnliche Strukturen. In Web- und Infrastrukturtests ist es nützlich, um vergessene Pfade oder Subdomains zu finden.

Ich führe es hier unter Sichtbarkeit, weil es genau diese Frage beantwortet: Was ist erreichbar, obwohl es vielleicht nicht dokumentiert ist? Inhaltlich berührt es natürlich auch Web Application Security.

Auf Debian, Ubuntu oder Kali kommt Gobuster über die Paketverwaltung oder über Go, wenn man eine neuere Version braucht.

sudo apt install gobuster

Ein sinnvolles Beispiel gehört gegen ein eigenes Staging-System oder Lab:

# Lab- oder Staging-Ziel, nicht fremde Websites
gobuster dir -u https://staging.example.test -w wordlists/small.txt

# VHost-Enumeration im eigenen Lab
gobuster vhost -u https://example.test -w wordlists/vhosts.txt

Ich würde Gobuster nie gegen fremde Websites laufen lassen. Gegen eigene Webanwendungen ist es aber ein sehr guter Realitätscheck: Was ist erreichbar, obwohl es niemand mehr auf dem Schirm hatte?

Schwachstellen und Hardening

Wenn Sichtbarkeit steht, kommt der nächste Schritt: Was ist verwundbar, veraltet oder schlecht konfiguriert?

Wichtig ist dabei Priorisierung. Ein CVSS-Score beschreibt vor allem technische Schwere. EPSS hilft einzuschätzen, wie wahrscheinlich Ausnutzung in der Praxis ist. Die CISA-KEV-Liste zeigt, welche Schwachstellen bereits bekannt ausgenutzt werden. Gute Teams kombinieren solche Signale mit eigener Exponierung: Internet-facing schlägt Laborserver, produktiv schlägt Testsystem, kritischer Dienst schlägt Randnotiz.

Greenbone / OpenVAS

OpenVAS gehört heute in den Greenbone-Kontext. Praktisch meint man meist Greenbone Community Edition oder Greenbone Vulnerability Management.

Man installiert Greenbone nicht mal eben wie ein kleines CLI-Tool. Es ist ein Scanner- und Management-Stack mit Feeds, Weboberfläche, Datenbank und Diensten. Ich würde dafür die offiziellen Community-Container oder Pakete der Distribution nutzen und es nicht auf irgendeinem Produktivserver “nebenbei” installieren.

In der Anwendung geht es um wiederkehrende Scans, authentifizierte Checks, Reportings und Priorisierung. Wichtig ist: Ein Scanner ist kein Ersatz für Patch-Management. Er zeigt nur, wo man hinschauen muss.

Nessus

Nessus ist ein kommerzieller Vulnerability Scanner von Tenable. Viele Admins kennen ihn aus Audits, Compliance-Prüfungen oder regelmäßigen Schwachstellen-Scans.

Man bekommt Nessus über Tenable als Installer für die jeweilige Plattform. Danach läuft ein lokaler Dienst mit Weboberfläche.

Ich würde Nessus in einem klaren Scan-Fenster einsetzen, mit sauber definierten Zielbereichen und möglichst authentifizierten Scans. Authentifizierte Scans sind oft wertvoller, weil sie nicht nur von außen raten, sondern Softwarestände und Konfigurationen genauer prüfen können.

Lynis

Lynis ist ein sehr praktisches Hardening- und Audit-Tool für Linux und andere Unix-artige Systeme. In diesem Artikel denke ich es aber klar aus Linux-Sicht.

Installation ist einfach:

sudo apt install lynis

Ein typischer Audit läuft so:

sudo lynis audit system

Lynis liefert viele Hinweise zu Logging, Kernel-Parametern, SSH, Dateirechten, Paketständen, Malware-Scannern und Baseline-Hardening. Ich sehe es nicht als Tool, das “alles fixt”, sondern als Checkliste mit technischer Tiefe.

HCL AppScan

HCL AppScan ist eine AppSec-Produktlinie für Web-, API- und Software-Security-Tests. Wer den Namen noch als IBM AppScan kennt, sollte den Produktwechsel zu HCL im Hinterkopf behalten.

Man kommt über HCL zu den kommerziellen Editionen. In der Praxis gehört AppScan eher in AppSec- und DevSecOps-Teams als in den klassischen Netzwerkbetrieb.

Wichtig ist der Einsatz im Software-Lifecycle: Scans in Testumgebungen, API-Prüfungen, Reporting für Entwicklerteams und Nachverfolgung von Findings. Ohne Einbindung in Entwicklung und Remediation wird jedes AppSec-Tool schnell nur zu einem weiteren PDF-Generator.

InsightVM / Nexpose

Rapid7 Nexpose und InsightVM gehören in die Vulnerability-Management-Welt. Nexpose ist der bekannte ältere Name, InsightVM die modernere Plattformperspektive mit Risiko, Priorisierung und Integrationen.

Man installiert oder bezieht es über Rapid7. Der eigentliche Wert liegt nicht im Scan allein, sondern in Priorisierung: Was ist wirklich kritisch, internetexponiert, ausnutzbar oder geschäftsrelevant?

Für Netzwerker ist InsightVM interessant, weil Netzwerksegmentierung, Exponierung und Erreichbarkeit direkt beeinflussen, wie gefährlich eine Schwachstelle ist.

Retina

Retina war ein bekannter kommerzieller Vulnerability Scanner. Heute ist es für mich vor allem ein Legacy-Begriff. BeyondTrust hat 2020 den Rückzug aus diesem Markt und das End-of-Life für das frühere Retina-Portfolio angekündigt.

Ich würde es nicht als aktuelles Werkzeug einplanen. Interessant ist Retina höchstens historisch oder wenn man Altumgebungen dokumentiert, in denen alte Reports oder Installationen noch herumliegen.

Der praktische Rat ist simpel: Wenn ein Vulnerability-Management-Prozess heute noch auf einem abgekündigten Scanner hängt, sollte man nicht nur das Tool ersetzen, sondern gleich den ganzen Prozess prüfen.

Web Application Security

Web-Tools sind besonders dual-use. Dieselbe Technik, mit der man eine eigene Anwendung prüft, kann gegen fremde Anwendungen missbraucht werden. Deshalb gehören klare Scopes, Testfenster und Berechtigungen immer dazu.

Burp Suite

Burp Suite ist eines der wichtigsten Werkzeuge für Web Application Security. Es sitzt als Proxy zwischen Browser und Anwendung, macht HTTP-Anfragen sichtbar und erlaubt Tests, Wiederholungen und Analyse.

Man installiert Burp über PortSwigger. Die Community Edition reicht zum Lernen und für manuelle Basics. Professional ist deutlich stärker für professionelle Tests.

Typisch ist dieser Ablauf: Browser auf Burp als Proxy konfigurieren, Testzertifikat im Browser installieren, Anwendung in einer Testumgebung öffnen und Requests analysieren. Ich würde im Artikel keine Angriffsketten zeigen, aber für legitime AppSec-Arbeit ist Burp fast Standard.

ZAP

ZAP ist ein freier Web-App-Scanner und Intercepting Proxy. Früher war “OWASP ZAP” der geläufige Name; heute weist das Projekt selbst darauf hin, dass es schlicht ZAP beziehungsweise ZAP by Checkmarx heißt.

Man installiert ZAP als Desktop-Anwendung oder nutzt es in CI/CD-nahen Setups. Für Teams mit Open-Source-Fokus ist es ein sehr guter Einstieg in DAST.

In der Praxis nutze ich ZAP für Lernumgebungen, interne Web-Checks und automatisierte Basistests gegen Staging-Systeme. Aktive Scans gehören nie gegen fremde Ziele.

Nikto

Nikto ist ein Webserver-Scanner für bekannte Fehlkonfigurationen, gefährliche Dateien, alte Serverstände und typische Webserver-Probleme.

Es ist in vielen Distributionen verfügbar:

sudo apt install nikto

Ein Beispiel gehört in ein eigenes Lab oder Staging:

nikto -host https://staging.example.test

Nikto ist oft laut und nicht besonders subtil. Genau deshalb mag ich es für Baseline-Checks: Wenn Nikto auf einem eigenen Webserver Dinge findet, sollte man sie ernst nehmen.

WPScan

WPScan ist auf WordPress spezialisiert. Für Betreiber von WordPress-Seiten ist es interessant, weil WordPress-Sicherheit stark von Core, Plugins, Themes und Konfiguration abhängt.

Auf Linux installiert man WPScan typischerweise über RubyGems, als Container oder über bereitgestellte Pakete. Für sinnvolle Ergebnisse braucht man oft API-Zugriff auf die Vulnerability-Datenbank.

Ein defensives Beispiel gehört gegen die eigene Staging- oder Produktionsseite mit Erlaubnis:

wpscan --url https://wp-staging.example.test

Ich würde WPScan besonders nach Plugin-Änderungen, größeren Updates oder vor Go-Lives einsetzen. Danach muss aber jemand die Ergebnisse bewerten. Scanner-Ausgaben sind keine fertigen Entscheidungen.

SQLMap

SQLMap automatisiert SQL-Injection-Tests. Das ist ein mächtiges Werkzeug mit sehr klarer Missbrauchsgefahr.

Man bekommt SQLMap über das offizielle Projekt, GitHub, Kali oder Paketmanager. Ich würde in einem öffentlichen Blog bewusst keine operativen SQLMap-Beispiele zeigen. Das Tool ist zu nah an echter Ausnutzung.

Legitim ist SQLMap in einem autorisierten AppSec-Test, wenn eine Anwendung im Scope ist und der Tester prüfen muss, ob eine vermutete SQL-Injection tatsächlich ausnutzbar ist. Für normale Admins ist es meist wichtiger zu verstehen, was SQLMap prüft, als es selbst auszuführen.

AppSpider

AppSpider ist ein DAST-Produkt aus der Rapid7-Welt. Es gehört eher in Enterprise-AppSec als in den kleinen Werkzeugkasten eines Netzwerkadmins.

Man bezieht es über Rapid7. In der Anwendung geht es um Crawling, Scans, Authentifizierung, Reporting und Integration in Security-Prozesse.

Der praktische Wert liegt darin, Web- und Mobile-Anwendungen wiederholbar zu testen. Wie bei AppScan gilt: Das Tool ist nur so gut wie der Prozess, der Findings an Entwickler zurückführt.

Passwort- und Authentifizierungsprüfungen

Passwort-Tools sind heikel, weil sie in legitimen Audits sehr nützlich sind, aber direkt missbraucht werden können. Ich würde sie nur mit sauberer Autorisierung, isolierten Daten und klarer Dokumentation einsetzen.

John the Ripper

John the Ripper ist ein Klassiker für Passwort-Audits und Recovery. In legitimen Szenarien prüft man damit, ob eigene Passwort-Hashes mit einfachen Wortlisten oder Regeln schnell gebrochen werden können.

Installation:

sudo apt install john

Ein defensives Lab-Beispiel:

# Nur mit autorisierten Test-Hashes verwenden
john --wordlist=policy-test.txt hashes.txt
john --show hashes.txt

Für mich ist John nützlich, um Passwort-Policies realistisch zu prüfen. Eine Policy ist erst dann überzeugend, wenn sie gegen einfache Cracking-Tests besteht.

Hashcat

Hashcat ist stark, wenn GPU-Leistung ins Spiel kommt. Es ist für große Passwort-Audits, Recovery-Fälle und Security-Teams relevant.

Installation ist je nach Plattform unterschiedlich. Auf vielen Systemen kommt Hashcat über Paketmanager; ernsthafte GPU-Setups brauchen passende Treiber.

sudo apt install hashcat

Ein Beispiel gehört nur in ein autorisiertes Lab:

# Beispielmodus nur mit eigenen Test-Hashes und eigener Wortliste
hashcat -m 0 hashes.txt policy-test.txt

Der operative Punkt ist weniger der Befehl als die Konsequenz: Wenn Hashcat schwache Passwörter schnell findet, ist das ein Signal für bessere MFA, bessere Passwortregeln, Password-Blocklists und weniger Passwortabhängigkeit.

Ophcrack

Ophcrack arbeitet mit Rainbow Tables und ist vor allem historisch für ältere Windows-Hash-Szenarien relevant.

Man bekommt es über die Projektseite beziehungsweise alte Pakete. In modernen Umgebungen würde ich es nicht als primäres Audit-Werkzeug wählen.

Ich erwähne Ophcrack eher, um zu zeigen, wie sich Passwort-Audits entwickelt haben. Moderne Passwörter, moderne Hashing-Verfahren und lange Passphrasen verschieben den Fokus stark Richtung John, Hashcat, MFA und Credential-Hygiene.

Hydra / THC-Hydra

Hydra beziehungsweise THC-Hydra ist ein Online-Login-Audit-Tool. Es testet Zugangsdaten gegen Netzwerkdienste.

Man bekommt es über Kali, Paketmanager oder das Projekt-Repository. Ich würde hier bewusst keine Beispielbefehle veröffentlichen. Online-Login-Tests sind sehr nah an Credential-Angriffen, erzeugen Logs, können Accounts sperren und sind ohne Auftrag eindeutig problematisch.

Legitim ist Hydra nur in engen Tests: eigene Systeme, definierte Accounts, klare Rate Limits, Testfenster, Freigabe vom Systemverantwortlichen und Monitoring. In der normalen Admin-Arbeit ist es oft sinnvoller, schwache Passwörter offline über Hash-Audits und zentral über Identity-Controls zu bekämpfen.

Medusa

Medusa liegt in derselben Kategorie wie Hydra: parallelisierte Login-Tests gegen Netzwerkdienste.

Installation erfolgt über Paketmanager oder das Repository. Auch hier gilt für mich: keine öffentlichen Beispielbefehle für echte Protokolle und Logins.

Wenn ein Red Team Medusa nutzt, dann nur im Scope und mit klarer Absprache. Für Blue Teams ist wichtiger, solche Muster zu erkennen: viele fehlgeschlagene Logins, verteilte Quellen, ungewöhnliche Protokolle, Account-Lockouts, MFA-Prompts.

Cain & Abel

Cain & Abel ist ein historisches Windows-Tool für Passwort-Recovery, Sniffing und ARP-Spoofing. Heute würde ich es nicht mehr als praktisches Werkzeug empfehlen.

Wenn man dazu kommt, dann eher in alten Schulungsunterlagen, historischen Tool-Listen oder sehr alten Lab-Umgebungen. Für moderne Arbeit ist es durch bessere, gepflegte und sicherer einzuordnende Werkzeuge ersetzt.

Der Wert liegt heute eher in der Geschichte: Es zeigt, wie sehr sich Windows-Sicherheit, Netzwerksegmentierung, EDR und Passwortschutz verändert haben.

Wireless Security

Wireless-Tools sind besonders abhängig von Hardware, Treibern, Funkumgebung und Recht. Ich würde WLAN-Audits nur in eigenen Netzen oder klar autorisierten Kundenumgebungen durchführen.

Aircrack-ng

Aircrack-ng ist eine Suite für WLAN-Security-Audits. Sie kann Captures analysieren, WLAN-Konfigurationen prüfen und Schwächen sichtbar machen.

Man bekommt Aircrack-ng über Paketmanager, Kali oder die Projektseite.

sudo apt install aircrack-ng

Ich würde hier keine Angriffsschritte gegen Access Points zeigen. Sinnvoll ist Aircrack-ng in einem eigenen Lab, um zu verstehen, warum schwache WLAN-Passwörter, alte Verschlüsselung oder schlecht konfigurierte WPS-Funktionen problematisch sind.

Wifite

Wifite automatisiert WLAN-Audit-Workflows und nutzt im Hintergrund andere Werkzeuge. Genau deshalb ist es bequem, aber auch heikel.

Man bekommt es über Kali oder das Projekt-Repository. Für Lernumgebungen kann es helfen, Abläufe zu verstehen. Für professionelle Audits würde ich trotzdem wissen wollen, welche Tools im Hintergrund was genau tun.

Ich sehe Wifite nicht als Admin-Alltagswerkzeug, sondern als Lab- oder Red-Team-Werkzeug mit sehr klarem Scope.

Kismet

Kismet ist für Wireless Monitoring, Survey und Detection interessant. Es erkennt WLANs, Clients, Funkaktivität und kann beim Auffinden von Rogue Access Points helfen.

Installation läuft über Pakete oder Projektquellen. Je nach Setup braucht man passende WLAN-Hardware und Treiber.

In der Praxis ist Kismet für Blue Teams und Wireless Engineers nützlich: Welche Access Points tauchen auf? Gibt es unbekannte Geräte? Wie sieht die Funkumgebung aus? Welche Clients sprechen wo?

AirSnort

AirSnort gehört in die WEP-Geschichte. Es war eines der Werkzeuge, die gezeigt haben, warum WEP kryptografisch nicht tragfähig war.

Heute würde ich AirSnort nicht installieren, außer für historische Forschung. Moderne WLAN-Security hat andere Baustellen: WPA2/WPA3, schwache Passphrasen, Enterprise-Auth, Zertifikate, Rogue APs, Evil Twins, Segmentierung.

Der praktische Nutzen ist deshalb nicht “verwenden”, sondern “verstehen, warum alte Sicherheit nicht ewig Sicherheit bleibt”.

NetStumbler

NetStumbler war ein Windows-Werkzeug für frühe WLAN-Erkennung und Site-Survey-Szenarien.

Heute ist es vor allem Legacy. Moderne Betriebssysteme, WLAN-Standards und Treibermodelle haben die Relevanz stark reduziert.

Wenn ich WLAN-Umgebungen heute analysiere, würde ich eher auf aktuelle Survey-Werkzeuge, Kismet, Hersteller-Tools oder professionelle WLAN-Planungssoftware schauen.

Reaver

Reaver gehört in den WPS-Kontext. WPS war bequem, aber sicherheitlich problematisch, besonders bei PIN-basierten Verfahren.

Man bekommt Reaver über Kali oder Forks. Ich würde keine operativen WPS-Angriffsbeispiele veröffentlichen.

Praktisch ist die Lehre klar: WPS deaktivieren, Router aktuell halten, starke WLAN-Passphrasen nutzen und WLAN-Clients sinnvoll segmentieren. Man muss Reaver nicht im Alltag nutzen, um die Konsequenz zu verstehen.

Blue Team, Monitoring und Detection

Blue-Team-Werkzeuge sehen weniger spektakulär aus als Red-Team-Tools, aber sie entscheiden, ob man einen Vorfall überhaupt bemerkt.

SIEM

SIEM ist kein einzelnes Tool, sondern eine Systemklasse: Logs sammeln, normalisieren, korrelieren, durchsuchen, alarmieren und für Untersuchungen verfügbar machen.

Man “installiert” also nicht SIEM, sondern wählt eine Plattform: Splunk, Elastic Security, Microsoft Sentinel, QRadar, LogRhythm oder andere.

Für Netzwerker ist SIEM relevant, weil Netzwerkgeräte, Firewalls, VPNs, DNS, Proxies und IDS/IPS enorme Signalquellen sind. Ohne diese Daten sieht man viele Angriffe nur als Bauchgefühl.

Splunk

Splunk ist eine Daten- und Analyseplattform, die in Security-Umgebungen häufig als SIEM-Basis oder mit Splunk Enterprise Security genutzt wird.

Man installiert Splunk als Server/Indexer/Search-Head-Architektur oder nutzt Cloud-Angebote. In der Praxis beginnt alles mit Daten: Welche Logs kommen rein? Sind sie zeitlich korrekt? Sind Felder normalisiert? Gibt es brauchbare Dashboards und Alarme?

Für Netzwerker sind Firewall-Logs, VPN-Logs, DNS-Logs, Proxy-Logs und Authentifizierungsdaten besonders wertvoll.

Elastic Stack

Der Elastic Stack besteht klassisch aus Elasticsearch, Logstash und Kibana, heute mit Beats, Agenten und Elastic Security erweitert.

Man installiert ihn selbst, nutzt Container oder Elastic Cloud. Der Stack ist mächtig, aber Betrieb, Speicher, Retention, Parsing und Berechtigungen müssen sauber geplant sein.

Ich sehe Elastic oft als flexiblere, engineering-lastigere Alternative für Logs, Suche, Dashboards und Security-Use-Cases. Man bekommt viel Kontrolle, aber auch viel Betriebsverantwortung.

IDS/IPS

IDS und IPS sind Systemklassen. IDS erkennt, IPS kann zusätzlich blockieren.

Für Netzwerker ist wichtig: Ein IDS/IPS ist nur so gut wie Platzierung, Regeln, Tuning und Telemetrie. Ein Sensor an der falschen Stelle sieht nichts. Ein schlecht getuntes System produziert nur Rauschen.

Ich würde zuerst klären: Welche Links sollen überwacht werden? North-South oder East-West? Nur Alerts oder Inline-Blocking? Wer pflegt Regeln? Wer reagiert auf Treffer?

Suricata

Suricata ist eine moderne IDS/IPS/NSM-Engine. Sie ist stark bei Netzwerk-Telemetrie, Protokollanalyse und EVE-JSON-Logs.

Installation:

sudo apt install suricata

Ein ungefährliches Beispiel ist die Analyse einer vorhandenen pcap-Datei:

mkdir -p suricata-logs
suricata -r sample.pcap -k none -l ./suricata-logs

In produktiven Umgebungen geht es um Sensorplatzierung, Regelquellen, Performance, False Positives und die Übergabe an SIEM oder Logplattform.

Snort

Snort ist ein bekannter IDS/IPS-Klassiker. Viele Security-Leute haben mit Snort-Regeln und Signaturen angefangen.

Installation erfolgt über Pakete oder die offiziellen Quellen. Ein sicherer Einstieg ist auch hier die pcap-Analyse im Lab, nicht direkt Inline-Blocking in Produktion. Wichtig: Moderne Snort-3-Setups nutzen Lua-Konfigurationen wie snort.lua; alte Snort-2-Beispiele mit snort.conf sollte man nicht ungeprüft übernehmen.

# Einfacher Snort-3-Einstieg mit einer pcap-Datei
snort -r sample.pcap

# Beispiel mit Alert-Ausgabe und Snort-3-Konfiguration
snort -c /usr/local/etc/snort/snort.lua -r sample.pcap -A alert_fast

# Alternativ im Lab mit einer expliziten lokalen Regeldatei
snort -R local.rules -r sample.pcap -A alert_fast

Snort hilft besonders beim Verständnis von Signaturen: Welche Muster erkenne ich im Traffic? Was ist ein echter Treffer? Was ist ein False Positive?

Zeek

Zeek ist kein klassisches IDS, das primär Signaturtreffer ausspuckt. Es ist ein Network-Security-Monitoring-Framework, das Netzwerkverkehr in strukturierte Logs übersetzt: Verbindungen, DNS, HTTP, TLS, Dateien, Zertifikate, SSH, DHCP und vieles mehr.

Man installiert Zeek über Pakete, offizielle Repositories oder als Teil größerer Sensor-Setups. Ein einfacher Lab-Einstieg ist die Analyse einer pcap-Datei:

zeek -r sample.pcap
ls *.log

Für Netzwerker ist Zeek extrem wertvoll, weil es aus Paketverkehr eine untersuchbare Zeitleiste macht. Suricata liefert ebenfalls starke Protokoll-Metadaten über EVE-JSON, ist aber häufiger regel- und alertzentriert gedacht. Zeek ist stärker dort, wo man Netzwerkverhalten über Zeit verstehen, jagen und korrelieren will.

NetFlow / IPFIX

NetFlow und IPFIX sind keine Paketmitschnitte, sondern Flow-Metadaten. Man sieht zum Beispiel Quelle, Ziel, Ports, Protokoll, Dauer und Datenmenge einer Verbindung, aber nicht den eigentlichen Paketinhalt.

Für Netzwerker ist das extrem wertvoll, weil man damit große Netze beobachten kann, ohne alles vollständig mitzuschneiden. Typische Fragen sind: Welche Systeme sprechen plötzlich ungewöhnlich viel nach außen? Welche internen Hosts bauen Verbindungen in fremde Länder auf? Wo entsteht Ost-West-Traffic, der eigentlich nicht erwartet war?

Man bekommt solche Daten je nach Umgebung aus Routern, Switches, Firewalls, Sensoren oder dedizierten Flow-Collectors. Für Security ist Flow-Telemetrie oft der Mittelweg zwischen “ich habe nur Logs” und “ich speichere jedes Paket”.

Full Packet Capture

Full Packet Capture bedeutet, dass Netzwerkverkehr vollständig als pcap oder in einer spezialisierten Plattform aufgezeichnet wird. Das ist mächtig, aber teuer in Speicher, Datenschutz und Betrieb.

Ich würde Full-PCAP nicht überall dauerhaft einschalten. Sinnvoll ist es an ausgewählten Punkten: Internet-Übergang, kritische Serversegmente, Lab, Incident-Response-Fenster oder Hochrisiko-Umgebungen. Werkzeuge und Plattformen wie Arkime, Stenographer oder Security Onion können dabei helfen, Mitschnitte durchsuchbar und operativ nutzbar zu machen.

Der große Vorteil: Wenn ein Vorfall passiert, muss man nicht nur aus Logs rekonstruieren, sondern kann ausgewählte Sessions wirklich nachträglich ansehen. Der große Nachteil: Man trägt Verantwortung für sehr sensible Daten.

OSSEC

OSSEC ist ein hostbasiertes Intrusion-Detection-System. Es schaut auf Hosts: Logs, File Integrity Monitoring, Rootkit Detection, Policy Checks und Active Response.

Man installiert OSSEC über Pakete oder Projektquellen. Für produktive Nutzung braucht man Architektur: Manager, Agenten, Regeln, Alerts und Prozesse.

Für mich ist OSSEC interessant, weil es nicht nur Netzwerkverkehr betrachtet. Viele Angriffe werden erst auf dem Host wirklich sichtbar: neue Dateien, Logins, verdächtige Prozesse, veränderte Konfigurationen.

Kurzer Exkurs: OSCO, OSSEC oder OSSIM?

OSCO ist in diesem Werkzeugkontext kein Name, den ich als etabliertes Security-Tool verwenden würde. Wenn jemand im Umfeld von SIEM, IDS/IPS, Snort, Suricata und Splunk “OSCO” sagt, würde ich zuerst prüfen, ob OSSEC oder vielleicht OSSIM gemeint ist.

Ich würde OSCO deshalb nicht installieren oder empfehlen, sondern den Begriff klären. In Security ist das kein Detail: Ein falscher Tool-Name kann bedeuten, dass jemand eine Quelle ungeprüft übernimmt.

Forensik und Incident Response

Forensik-Tools sind nicht dafür da, “anzugreifen”. Sie helfen, nach einem Vorfall zu verstehen, was passiert ist.

The Sleuth Kit

The Sleuth Kit ist eine Sammlung von Kommandozeilenwerkzeugen für Dateisystem- und Datenträgeranalyse.

Installation:

sudo apt install sleuthkit

Man nutzt es in DFIR-Fällen, um Images zu untersuchen, Dateisystemstrukturen zu analysieren und Artefakte zu extrahieren. Es ist eher Werkzeugkasten als hübsche Oberfläche.

Autopsy

Autopsy ist die grafische Plattform rund um digitale Forensik und baut stark auf The Sleuth Kit auf.

Man installiert Autopsy über die Projektseite oder Pakete. In der Anwendung legt man Cases an, importiert Images, analysiert Artefakte, Zeitleisten, Dateien, Browserdaten und viele andere Spuren.

Für Admins ist Autopsy nicht täglich nötig, aber im Incident-Response-Kontext sehr wertvoll.

Volatility

Volatility ist ein Framework für Memory Forensics. Es analysiert RAM-Abbilder und hilft, Prozesse, Netzwerkverbindungen, DLLs, Handles, Malware-Spuren oder andere Artefakte zu finden.

Installation erfolgt heute typischerweise über Python/Pip oder Pakete, je nach Version.

Ein typisches Lab-Beispiel:

vol -f memory.raw windows.info
vol -f memory.raw windows.pslist

Der Wert liegt darin, dass manche Angriffe im Speicher sichtbarer sind als auf der Festplatte.

Guymager

Guymager ist ein forensisches Imaging-Tool. Es erstellt bitgenaue Abbilder von Datenträgern.

Man findet es häufig in forensischen Linux-Distributionen oder Paketquellen. In produktiven Beweissituationen ist nicht nur das Tool wichtig, sondern auch Chain of Custody, Schreibschutz, Hashes und Dokumentation.

Für normale Admins ist Guymager selten Alltag. Für DFIR ist es Basisarbeit.

Foremost

Foremost ist ein File-Carving-Tool. Es kann Dateien anhand von Headern und Footern aus Rohdaten rekonstruieren.

Installation:

sudo apt install foremost

Ein Lab-Beispiel:

foremost -i disk-image.raw -o recovered-files

Das ist nützlich, wenn Dateien gelöscht wurden oder Dateisystem-Metadaten beschädigt sind. Es ersetzt aber keine saubere forensische Methodik.

Binwalk

Binwalk ist stark bei Firmware-Analyse. Für Router, IoT-Geräte und Embedded-Systeme ist das spannend, weil Firmware oft Dateisysteme, Konfigurationen oder Schlüsselmaterial enthält.

Installation:

sudo apt install binwalk

Lab-Beispiel:

binwalk firmware.bin
binwalk -e firmware.bin

Für Netzwerker ist Binwalk interessant, wenn man Geräte-Security verstehen will. Für Produktivarbeit braucht man aber rechtliche Klarheit: Firmware fremder Geräte einfach zu zerlegen, ist nicht automatisch unproblematisch.

Red Team und High-Risk-Dual-Use

Diese Werkzeuge können in professionellen Red-Team-Engagements legitim sein. Gleichzeitig sind sie näher an echter Ausnutzung, Phishing oder Command-and-Control. Deshalb erkläre ich sie, aber ich mache daraus keine Bedienungsanleitung.

Metasploit Framework

Metasploit ist ein Exploitation-Framework. Es hilft, Schwachstellen in einem kontrollierten Test zu verifizieren und Angriffspfade nachzustellen.

Man bekommt Metasploit über Rapid7, Kali oder Paketquellen.

msfconsole

Mehr würde ich in einem allgemeinen Blogpost bewusst nicht als Workflow zeigen. Professionell eingesetzt gehört Metasploit in ein Lab oder einen klaren Pentest-Scope. Für Blue Teams ist es außerdem nützlich, um Detection gegen bekannte Techniken zu testen.

ExploitDB

ExploitDB ist keine Software-Suite, sondern eine Datenbank für Exploits und Proofs of Concept.

Man nutzt sie über die Website oder über Suchwerkzeuge wie searchsploit in Kali.

Der defensive Wert ist groß: Wenn für eine Schwachstelle öffentlicher Exploit-Code existiert, beeinflusst das Patch-Priorität, Exposure-Bewertung und Detection. Man muss nicht jeden Exploit ausführen, um seinen Risikowert zu verstehen.

Core Impact

Core Impact ist eine kommerzielle Pentest-Plattform. Sie richtet sich an professionelle Teams, die strukturierte, autorisierte Tests durchführen.

Man bezieht sie über den Hersteller. Installation, Lizenzierung und Nutzung sind Enterprise-Themen, nicht “mal schnell ein Tool installieren”.

Ich würde Core Impact eher als Plattform für organisierte Tests sehen: Planung, Durchführung, Reporting und Nachverfolgung. Der Wert liegt in Prozess und Nachweisbarkeit.

Cobalt Strike

Cobalt Strike ist eine Plattform für Adversary Simulation und Red-Team-Operationen. Es ist eines der sensibelsten Werkzeuge in diesem Artikel.

Man kommt offiziell nur über den Hersteller und Lizenzierung dazu. Genau so sollte es auch sein. Cobalt Strike gehört nicht auf private Bastelmaschinen und nicht in unklare Lab-Umgebungen.

Ich würde keine Befehle oder Einsatzmuster veröffentlichen. Wichtig ist die Einordnung: In professionellen Händen kann Cobalt Strike helfen, Blue-Team-Erkennung realistisch zu prüfen. In falschen Händen ist es ein ernstes Missbrauchswerkzeug.

GoPhish

GoPhish ist ein Framework für Phishing-Simulationen und Awareness-Trainings.

Man installiert es als Server-Anwendung, oft in einer isolierten Umgebung. Vor produktiver Nutzung braucht man Freigaben, Datenschutzklärung, Zielgruppen, Kommunikationsplan und klare Auswertung.

Ich würde GoPhish nicht als “Phishing-Tool” im einfachen Sinn sehen, sondern als Awareness-Messwerkzeug. Es ist nur dann seriös, wenn die Organisation weiß, was getestet wird und wie mit Ergebnissen umgegangen wird.

HiddenEye

HiddenEye ist ein Phishing-Toolkit mit stark missbrauchsnaher Ausrichtung.

Ich würde es nicht als normales Unternehmenswerkzeug empfehlen. Wenn es überhaupt vorkommt, dann in Malware-/Phishing-Forschung oder in sehr kontrollierten Schulungsumgebungen.

Für Admins ist wichtiger zu wissen, dass solche Toolkits existieren, als sie zu installieren. Die Verteidigung heißt: MFA, phishing-resistente Verfahren, gute Mail-Filter, Browser-Isolation, Reporting-Prozesse und Awareness.

SocialFish

SocialFish liegt ähnlich wie HiddenEye im Bereich Phishing-Toolkit.

Auch hier sehe ich kaum legitimen normalen Admin-Nutzen. In einem seriösen Awareness-Programm würde ich eher zu GoPhish oder kommerziellen Awareness-Plattformen greifen, weil dort Reporting, Einwilligung, Templates und Prozesse sauberer sind.

Der Sicherheitswert liegt in der Einordnung: Wenn Blue Teams wissen, wie einfach solche Toolkits existieren, verstehen sie besser, warum reine Passwort-MFA und reine Mitarbeiterschulung nicht reichen.

EvilURL

EvilURL beschäftigt sich mit Homograph- und Lookalike-Domains. Das Thema ist für Brand Protection und Phishing-Abwehr relevant.

Man kann solche Werkzeuge defensiv nutzen, um mögliche Täuschungsdomains zu erkennen oder Awareness-Beispiele zu bauen. Operativ muss man sehr vorsichtig sein, weil das Generieren täuschender Domains auch missbraucht werden kann.

Für Netzwerker und Admins ist die wichtigste Konsequenz: DNS-Monitoring, Domain-Monitoring, DMARC/DKIM/SPF, klare Kommunikationsdomänen und gute Benutzerführung.

Evilginx

Evilginx ist ein Adversary-in-the-Middle-Phishing-Framework. Es kann zeigen, warum klassische MFA nicht automatisch phishing-resistent ist.

Ich würde keine Installations- oder Einsatzbefehle veröffentlichen. Das Tool ist zu nah an echten Credential- und Session-Angriffen.

Legitim ist es in sehr kontrollierten Red-Team-Tests, wenn ein Unternehmen prüfen will, ob seine Identitäts- und Session-Schutzmaßnahmen halten. Für die Verteidigung ist die Lehre klar: FIDO2/WebAuthn, Conditional Access, Gerätebindung, Token-Schutz, gute Login-Telemetrie und schnelle Reaktion auf verdächtige Sessions.

Distributionen als Arbeitsumgebung

Eine Distribution ist kein Tool. Sie ist die Werkbank.

Kali Linux

Kali Linux ist eine Security-Distribution mit vielen vorinstallierten Werkzeugen für Pentesting, Forensik, Reverse Engineering und Security Research.

Man installiert Kali als VM, Live-System oder auf dedizierter Hardware. Ich würde es für die meisten Fälle als VM auf einem Linux-Host nutzen, nicht als normales Alltagsbetriebssystem.

Der praktische Wert liegt darin, dass viele Tools bereits installiert und abgestimmt sind. Der Nachteil: Genau dadurch wirkt es verführerisch, Dinge auszuführen, die man nicht verstanden hat. Kali ersetzt kein Verständnis.

Parrot OS

Parrot OS ist ebenfalls eine Security- und Privacy-orientierte Distribution. Sie eignet sich für Pentesting, OSINT, Forensik und allgemeine Security-Arbeit.

Wie bei Kali würde ich Parrot eher als isolierte Arbeitsumgebung sehen: VM, Lab, klare Snapshots, keine Vermischung mit privaten Daten oder produktiven Kundenzugängen.

Der Unterschied zwischen Kali und Parrot ist weniger wichtig als die Frage, ob man die Werkzeuge darin verantwortungsvoll nutzt.

Security Onion

Security Onion ist die defensive Schwester in dieser Werkzeugwelt. Während Kali und Parrot stark mit Pentesting und Security Research verbunden sind, ist Security Onion auf Network Security Monitoring, Threat Hunting, Log Management und Incident Response ausgerichtet.

Man installiert Security Onion nicht als normales Desktop-Spielzeug. Es ist eher eine Sensor- und Monitoring-Plattform für Labs oder produktive Security-Umgebungen. Typisch sind Netzwerk-Sensoren, Suricata, Zeek, Logdaten, Dashboards und Workflows für Alarmierung und Untersuchung.

Für Netzwerker ist Security Onion interessant, weil es zeigt, wie aus einzelnen Tools ein Detection-Setup wird. Ein einzelnes tcpdump beantwortet eine Momentfrage. Ein gut platzierter Sensor beantwortet über Tage und Wochen, was im Netz wirklich passiert.

Was ich als Netzwerker wirklich mitnehmen würde

Wenn ich einen kompakten Werkzeugkasten für Netzwerker bauen müsste, sähe er ungefähr so aus:

Für Sichtbarkeit: Nmap, tcpdump, Wireshark.

Für externe Angriffsfläche: Shodan, Censys, Amass, theHarvester.

Für Hardening und Schwachstellen: Lynis, Greenbone/OpenVAS, Nessus oder eine vergleichbare Vulnerability-Management-Plattform.

Für Web-Anwendungen: Burp Suite, ZAP, Nikto, WPScan.

Für Detection: Suricata, Snort, OSSEC, plus ein brauchbares SIEM oder Log-Stack.

Für Network Security Monitoring: Zeek, Security Onion, NetFlow/IPFIX und bei Bedarf Full Packet Capture.

Für Forensik: Autopsy, The Sleuth Kit, Volatility, Guymager, Foremost, Binwalk.

Für Red-Team-Arbeit: Metasploit, Cobalt Strike, Core Impact, SQLMap, GoPhish, Evilginx nur mit Auftrag, Scope und Erfahrung.

Und für historische Einordnung: Cain & Abel, AirSnort, NetStumbler, Retina, Ophcrack mit klarem Legacy-Kontext.

Fazit

Der beste Security-Werkzeugkasten ist nicht der längste. Er ist der, bei dem man weiß, warum jedes Werkzeug darin liegt.

Nmap und Wireshark helfen mir, ein Netz zu verstehen. Lynis, Nessus und Greenbone helfen mir, Schwächen sichtbar zu machen. Snort, Suricata, OSSEC und ein SIEM helfen mir, nicht blind zu sein. Burp, ZAP und WPScan helfen bei Web-Security. Forensik-Tools helfen, nach einem Vorfall nicht nur zu raten. Red-Team-Werkzeuge helfen, Verteidigung realistisch zu prüfen, aber nur mit sauberem Auftrag.

Das ist für mich die eigentliche Grenze: Nicht “Admin-Tool” gegen “Hacker-Tool”, sondern verantwortlicher Betrieb gegen unautorisierten Einsatz.

Bis zum nächsten Mal,
Euer Joe