Paket-Tools wenn nichts installiert werden darf
tcpdump-Filter und netcat-Muster auf gesperrten Hosts ohne volles Toolkit.
Server-Team sagt nein zu neuen Binaries. Trotzdem muss klar werden wohin Traffic geht wenn die App "die DB nicht erreicht."
tcpdump und netcat sind oft schon da weil Ops sie zuerst nutzte. Wenn die App "DB unreachable" meldet aber niemand einen neuen Binary installieren darf, brauchst du Beweise für ein Netzwerk-Ticket. Nicht noch ein Tool. tcpdump und nc sind alt genug dass Ops sie oft toleriert.
Volle Interface-Captures füllen Disk und können fremde Pakete mitschneiden. Filter früh setzen. Rotation mit -C und -W wenn du länger lauschen musst. Danach aufräumen. Blue Team sieht PCAPs auch.
tcpdump: weniger capturen
DNS kaputt:
tcpdump -i any -n udp port 53 -c 50
SYN zur DB:
tcpdump -i eth0 -n host db.internal and tcp port 1433 -c 20
Rotation:
tcpdump -i eth0 -w /tmp/cap.pcap -C 50 -W 5 'tcp port 443'
Aufräumen. Blue Team sieht PCAPs auch.
netcat
nc -vz target.host 443
echo "" | nc -w 3 target 25
nc -h prüfen. Builds unterscheiden sich.
Ohne Tools
ss oder netstat anfragen. Minimal-Socket in Python oder PowerShell.
Blue Team
Passive Capture im Testplan nennen. PCAPs nach Review löschen.
Kurz auf Wire lesen wenn erlaubt: tcpdump -i eth0 -n -A 'tcp port 80' -c 10. Zehn Pakete, nicht das ganze Engagement.
Ohne nc/tcpdump: ss -tlnp vom App-User. Minimal-Socket Python oder PowerShell. Interface und localhost-Binding dokumentieren.
Passive Capture im Testplan. PCAPs nach Review mit Blue Team löschen.
Alte Tools überleben Lockdowns.
Relais und Banner-Grabs sind langweilig bis sie der einzige Weg sind. nc -h prüfen: OpenBSD, traditional, ncat. -e fehlt oft. Port-Forward-Szenarien hängen vom Build ab. Dokumentiere Interface-Namen und ob der Dienst nur auf localhost bindet. Connection refused von außen ist oft Binding-Policy, nicht mysteriöse Firewall-Magie.