„SERVER-WEBAPP — no user agent“: Was die SIEM-Warnung bedeutet und wie ihr richtig reagiert - open-how2

Einleitung

Taucht im SIEM die Meldung „SERVER-WEBAPP no user agent“ auf, ist das erst einmal ein Hinweis: Ein HTTP-Request erreichte eure Webanwendung ohne einen gesetzten User-Agent-Header – und das ist ungewöhnlich genug, dass Überwachungsregeln anschlagen. In diesem Artikel erkläre ich detailliert, warum das auffällig ist, welche harmlosen und bösartigen Ursachen es haben kann, wie ihr den Vorfall sinnvoll untersucht und welche technischen Gegenmaßnahmen langfristig helfen.

Was ist der User-Agent-Header und warum ist er wichtig?

Der User-Agent-Header wird von Clients bei HTTP-Requests mitgeschickt und beschreibt kurz, wer anfragt — typischer Browser, Crawler, Monitoring-Tool oder ein Script. Beispiele sind typische Browser-Strings (Chrome, Firefox), Bots (Googlebot) oder Tools (curl/7.88.1, python-requests/2.x). Server, WAFs und SIEMs nutzen diese Information zur Klassifikation des Traffics und zur Erkennung ungewöhnlicher Muster.

Fehlt dieser Header ganz oder ist er leer, weicht das Verhalten vom „normalen“ Browser-Traffic ab — und das kann sowohl harmlos als auch verdächtig sein.

Was genau bedeutet die Meldung „SERVER-WEBAPP no user agent“?

SERVER-WEBAPP: Die Kategorie der Regel — es geht um HTTP/HTTPS-Traffic, also Webserver bzw. Webanwendung.
no user agent: Der Request hatte keinen User-Agent-Header oder der Header war leer/ungenutzt.

Die SIEM-Regel markiert dies als Auffälligkeit, weil praktisch alle Standard-Browser einen User-Agent senden. Ein fehlender User-Agent ist daher ein guter Indikator für automatisierte oder ungewöhnliche Clients.

Mögliche Ursachen — von harmlos bis bösartig

Harmlos / erwartbar

Interne Cronjobs / Skripte ohne konfigurierten User-Agent (z. B. einfache curl-Aufrufe in Shell-Skripten oder Python-Scripts).
Monitoring / Health-Checks (z. B. aus älteren Tools oder Embedded-Devices), die minimalistische HTTP-Anfragen senden.
Proxy-/Gateway-Verhalten: Manche Gateways/Proxies verändern oder entfernen Header.

Verdächtig / potentiell bösartig

Scanner / Recon-Tools (selbstgeschriebene oder schlecht konfigurierte Scanner, die den Header weglassen).
Bots / Malware mit minimaler HTTP-Implementierung.
Evasion-Versuche: Angreifer lassen bewusst Header weg, um Signaturen zu umgehen, die bekannte böse User-Agents (z. B. sqlmap) filtern.

Wie gefährlich ist das? (Kurzbewertung)

Alleine ist die Meldung kein Beweis für einen erfolgreichen Angriff — sie ist ein Indikator. Gefährlich wird es, wenn:

Die Quell-IP in Zusammenhang mit weiteren Alerts steht (Portscans, fehlgeschlagene Logins).
Viele Requests in kurzer Zeit kommen (automatischer Scan).
Zielpfade typisch für Angriffe sind (z. B. /wp-admin, /phpmyadmin, /login, xmlrpc.php).
Es Anzeichen für erfolgreiche Exploits oder unautorisierte Zugriffe gibt.

Schritt-für-Schritt-Untersuchung (Praktische Checkliste)

Event im SIEM öffnen und sichern

Vollständiger HTTP-Request (Headers + Body) sichern.
Zeitstempel, HTTP-Methode, Response-Code notieren.

Quell-IP analysieren

Intern oder extern?
WHOIS / Reverse-DNS prüfen (Cloud-Provider, TOR Exit, Hosting-Provider).
In anderen Logs nach weiteren Aktivitäten suchen.

Ziel-URL & Pfad prüfen

War es nur / oder /health? → eher harmless.
War es /login, Admin-Pfad oder bekannte Exploit-URLs? → erhöhtes Risiko.

Frequenz & Pattern

Einzelner Request → wahrscheinlich Test / Monitoring.
Viele, schnell hintereinander → Scan/Bruteforce.

Korrelation mit anderen Logs

Webserver-, Applikations-, Datenbank- und Firewall-Logs abgleichen.
Gab es Fehlermeldungen, 4xx/5xx Codes, oder nachfolgende Aktivitäten?

Identifikation interner Quellen

Ist die IP bekannt (Monitoring, Loadbalancer, CI/CD Runner)?
Falls ja: Tool konfigurieren, damit es einen eindeutigen User-Agent sendet.

Entscheidung treffen

Harmlos: dokumentieren und ggf. whitelisten.
Verdächtig: IP temporär blockieren, WAF-Regeln verschärfen, Incident Response einleiten.

Sofortmaßnahmen & empfohlene Reaktionen

Kurzfristig: IP-Rate-Limit setzen, verdächtige IPs temporär blocken (bei hoher Frequenz), WAF-Regeln prüfen.
Mittelfristig: Quellen identifizieren, interne Tools konfigurieren (eindeutiger UA).
Langfristig: Monitoring- und SIEM-Regeln anpassen, damit bekannte interne UAs nicht ständig Alarme auslösen, ohne die Erkennungsfähigkeit für echte Bedrohungen zu senken.

Präventive Maßnahmen (Best Practices)

Eigene Clients heben sich klar hervor: Monitoring- und Cronjobs immer mit einem aussagekräftigen User-Agent betreiben (z. B. company-monitor/1.2), damit sie in SIEM/WAF erkennbar sind.
WAF/Rate Limiting: Regeln so definieren, dass fehlender UA in Kombination mit externen IPs, hoher Frequenz oder Zugriff auf sensitive Pfade zu Block/Challenge führt.
Logging & Korrelation verbessern: Alerts mit Kontext (Geolocation, Referer, Response Codes) anreichern.
Harden Applikation: Sichere Authentifizierung, Input-Validation, MFA, Least Privilege — damit ein erfolgreicher Scan nicht automatisch kompromittiert.
Regelmäßige Reviews: Whitelist/Blacklist und Erkennungslogiken regelmäßig prüfen, um False Positives zu minimieren.

Fertiger Text für Ticket / Dokumentation (Copy & Paste)

SERVER-WEBAPP no user agent Ein HTTP-Request an unsere Webanwendung wurde ohne oder mit leerem User-Agent-Header empfangen. Da Browser standardmäßig einen User-Agent senden, deutet dies häufig auf automatisierte Skripte, Scanner, Bots oder rudimentäre interne Tools hin. Die Meldung ist ein Indikator für ungewöhnlichen Webtraffic und muss im Kontext (Quell-IP, Ziel-URL, Häufigkeit) bewertet werden. Interne Überwachungs- oder Health-Check-Tools sollten einen expliziten User-Agent setzen, um Fehlalarme zu vermeiden.

Die SIEM-Warnung „SERVER-WEBAPP no user agent“ ist kein Grund zur Panik — aber zur Sorgfalt. Sie signalisiert: „Hier verhält sich ein Client nicht wie ein normaler Browser.“ Je nach Kontext kann das harmlos (altes Monitoring-Script) oder der erste Schritt eines Scans/Angriffs sein. Entscheidend sind die anschließenden Maßnahmen: Kontext sammeln, Quell-IP einordnen, interne Tools richtig konfigurieren und bei Bedarf WAF/Blocking einsetzen. So bleibt ihr wachsam, ohne jede Kleinigkeit zu überreagieren.