Schutz vor SMS- und OTP-Bombing

SMS- und OTP-Bombing bezeichnen Angriffe, bei denen ein Bot wiederholt ein OTP- oder Anmeldeformular auf Ihrer Webseite auslöst, um massenhaft SMS zu erzeugen. Typische Motive sind Belästigung Dritter ("SMS-Flood" auf eine Zielnummer), das Aufzehren Ihres Guthabens und vor allem IRSF-Betrug (International Revenue Share Fraud), bei dem Angreifer SMS an hochpreisige internationale Premium-Rufnummern senden, an denen sie selbst mitverdienen.

Gegen diese Angriffsklasse hilft kein einzelnes Feature. Wirksam ist nur ein gestaffelter Schutz: zuerst auf Ihrer Anwendung, dann in Ihrem seven.io-Account.

Wo das eigentliche Loch sitzt

In den meisten Bombing-Fällen ist das OTP-Formular ungeschützt: kein Captcha, kein Rate-Limit, kein Cooldown. Der Angreifer ruft den Send-Endpoint hundert- oder tausendfach pro Minute auf, jeder Aufruf erzeugt eine echte SMS. seven.io kann den Schaden begrenzen, aber den Trigger müssen Sie in Ihrer Anwendung schließen.

Schutzmaßnahmen in Ihrer Anwendung

Diese Punkte gehören in Ihr Frontend und Backend, nicht zu seven.io:

• Captcha vor dem Send-Button. reCAPTCHA, hCaptcha, Cloudflare Turnstile oder vergleichbare Bot-Detection. Das ist die wirkungsvollste Einzelmaßnahme.

• Rate-Limit pro IP, pro Session und pro Empfängernummer. Beispiel: maximal 3 OTPs pro 10 Minuten pro Mobilfunknummer und maximal 10 OTPs pro Stunde pro IP.

• Cooldown zwischen Resend-Klicks. Erster Resend nach 60 Sekunden, danach exponentielles Backoff (2, 4, 8 Minuten).

• Nummern-Vorvalidierung. Prüfen Sie das Format und den Netzbetreiber per Lookup, bevor Sie die SMS auslösen. Damit filtern Sie ungültige Nummern und exotische Premium-Destinationen aus, bevor Kosten entstehen.

• Honeypot-Felder und Verhaltensanalyse. Versteckte Formularfelder, ungewöhnlich schnelle Submits und untypische User-Agents loggen und blocken.

Schutzmaßnahmen in Ihrem seven.io-Account

Diese Maßnahmen kappen den Schaden, falls die Anwendungsschicht doch durchbricht.

Länderbeschränkung aktivieren

Mit Abstand der wichtigste Hebel gegen IRSF. Wenn Ihr OTP-Service nur deutschsprachige Kunden bedient, sperren Sie alles außer DACH. Damit laufen Premium-Nummer-Angriffe ins Leere, weil seven.io die SMS gar nicht erst zustellt.

Konfiguration unter Einstellungen > Nachrichten > Länderbeschränkungen. Details siehe Länderspezifische Einschränkungen.

Request-Signing aktivieren und erzwingen

seven.io unterstützt HMAC-SHA256-Request-Signing für die REST-API. Jeder API-Request kann mit einem separaten Signing-Key signiert werden, der unabhängig vom API-Key vergeben wird. Damit ist ein gestohlener API-Key allein nutzlos, sofern Sie das Erzwingen der Signatur aktivieren.

Funktionsweise:

• Drei Header begleiten den Request: X-Signature, X-Timestamp, X-Nonce.

• Signiert wird über HMAC-SHA256 ein String aus Timestamp, Nonce, HTTP-Methode, vollständiger URL und MD5-Hash des Bodys (zeilengetrennt).

• Der Timestamp darf maximal 30 Sekunden alt sein (Replay-Schutz). Die Nonce ist pro Request einmalig.

• Signing-Key konfigurieren unter Entwickler > Einstellungen. Im selben Bereich aktivieren Sie das Erzwingen der Signatur, damit unsignierte oder ungültig signierte Requests abgelehnt werden.

Vollständige Doku inklusive Bash- und PHP-Beispielen: docs.seven.io/en/rest-api/signing.

Server-IP-Whitelist für die API

Zusätzlich zum Request-Signing schränken Sie den API-Zugriff auf bekannte Quell-IPs ein: nur Anfragen von Ihren App-Server-IPs werden akzeptiert, alle anderen Requests werden mit Fehler 903 abgelehnt. Das fängt auch Angriffe ab, bei denen Signing-Key und API-Key gemeinsam leaken.

Konfiguration unter Entwickler > Einstellungen > REST API. Details siehe Whitelist für Zugriff auf die API.

Eigener API-Key pro Service

Verwenden Sie nicht denselben Key für Marketing-Versand, Transaktions-SMS und OTP. Pro Service ein eigener Key bedeutet, dass ein einzelner geleakter Key sofort deaktiviert werden kann, ohne andere Versandwege zu unterbrechen. Siehe Wo steht mein API-Key und Deaktivierung ungenutzter API-Keys.

Subaccount nur als harter Cap, nicht mit aktivem Auto-Top-up

Ein Subaccount für den OTP-Service trennt Guthaben und Reporting. Als Schadens-Cap funktioniert er aber nur, wenn Auto-Top-up deaktiviert ist und Sie ihn manuell befüllen. Sonst wird bei niedriger Schwelle einfach häufiger nachgeladen, der Gesamtschaden ist derselbe oder höher.

Empfohlener Aufbau:

• eigener Subaccount "OTP" mit eigenem API-Key

• Auto-Top-up deaktiviert

• manuelle Aufladung mit fixem Monatsbudget (z.B. 50 EUR)

• ist der Subaccount leer, stoppt der Versand automatisch

Details zur Einrichtung: Subaccounts.

Guthaben-Warnung an mehrere Empfänger

Eine ungewöhnliche Versandwelle führt zwangsläufig zu schnell sinkendem Guthaben. Hinterlegen Sie eine Schwelle und mindestens zwei Empfänger-Adressen (Tech und Billing), damit der Alarm auch bei Urlaub einer Person ankommt. Siehe Benachrichtigungen bei knappem Guthaben.

Account-Sicherheit

• 2FA für alle Account-Mitglieder erzwingen, damit ein gestohlenes Passwort nicht reicht. Siehe Zwei-Faktor-Authentifizierung (2FA) und 2FA erzwingen.

• IP-Whitelist für den Login zusätzlich zur API-Whitelist, falls Sie aus festen Büro-IPs arbeiten. Siehe IP-Whitelist für den Login.

• Ungenutzte API-Keys deaktivieren, regelmäßig durchgehen.

Wenn ein Angriff bereits läuft

1. API-Key sofort rotieren oder deaktivieren unter Entwickler-Einstellungen. Damit stoppt jeder weitere Versand sofort.

2. Länderbeschränkung verschärfen und alle Nicht-Zielländer sperren.

3. Support kontaktieren unter support@seven.io mit Account-ID und Zeitfenster. Wir helfen bei der Auswertung der Versandmuster und unterstützen, den Angriff einzudämmen. Bitte beachten Sie: Kosten für SMS, die durch eine ungeschützte Anwendung des Kunden ausgelöst wurden, werden grundsätzlich nicht erstattet.

4. Anwendungsseite absichern, bevor Sie den Versand wieder aktivieren. Captcha einbauen, Rate-Limit aktivieren, Logs auswerten.

Bei konkreten Vorfällen unterstützt Sie unser Support gerne.