Internationale SMS-Firewalls sitzen am Interconnect. Sie schützen Traffic, der aus dem Ausland eintrifft. Sie sehen jedoch keinen On-Net-Spam, keine internen SMS-Stürme, keine Grey Routes über lokale SIM-Boxen, keinen Flash-Call-Missbrauch und kein Sender-ID-Spoofing Ihrer Bank- und Behördenmarken. Die Local SMSC Firewall sitzt vor — oder neben — Ihrem Local SMSC und adressiert jedes dieser Probleme.
Betreiber, die ihre internationale Firewall mit einer lokalen Kern-Firewall kombinieren
Inline-Prüfung ohne Inline-Risiko. Jede Regel läuft im Monitoring-Modus, bevor sie jemals blockiert; jede Entscheidung lässt sich eindeutig der Regel zuordnen, die sie ausgelöst hat.
End-to-End-Overhead pro Nachricht, inline.
Jede Regel kann zunächst nur protokollieren, bevor sie jemals blockiert.
Zulassen, Blockieren, Drosseln, Kennzeichnen und Weiterleiten.
Co-Managed, Self-Service oder Fully-Managed.
Die Firewall sitzt zwischen jeder Traffic-Quelle und Ihrem Messaging-Kern — SMPP, HTTP, interne APIs, interne Anwendungen, externe Partner — und prüft jede Nachricht, bevor sie den Local SMSC erreicht.
SMPP, HTTP, interne APIs – sowohl interne Anwendungen als auch externe Partner. Jeder Zugang zum Messaging-Kern wird berücksichtigt.
Erkannter Typ: A2P, P2P, Flash-Anruf, Testverkehr, Systemmeldungen. Kontext wurde vor Auslösung einer Regel markiert.
Inhalts-, Verhaltens- und Kontextregeln werden kombiniert. Pro Route, pro Absender, pro Segment, pro Tageszeit.
Zulassen · Blockieren · Drosseln · Taggen und Weiterleiten. Jede Entscheidung wird mit der zugehörigen Regel protokolliert.
Genehmigter Datenverkehr wird an das lokale SMSC weitergeleitet. Blockierter Datenverkehr wird verworfen, ein Nachweisprotokoll wird jedoch aufbewahrt.
SMPP, HTTP, interne APIs – sowohl interne Anwendungen als auch externe Partner. Jeder Zugang zum Messaging-Kern wird berücksichtigt.
Erkannter Typ: A2P, P2P, Flash-Anruf, Testverkehr, Systemmeldungen. Kontext wurde vor Auslösung einer Regel markiert.
Inhalts-, Verhaltens- und Kontextregeln werden kombiniert. Pro Route, pro Absender, pro Segment, pro Tageszeit.
Zulassen · Blockieren · Drosseln · Taggen und Weiterleiten. Jede Entscheidung wird mit der zugehörigen Regel protokolliert.
Genehmigter Datenverkehr wird an das lokale SMSC weitergeleitet. Blockierter Datenverkehr wird verworfen, ein Nachweisprotokoll wird jedoch aufbewahrt.
Vier Gründe, warum Betreiber eine dedizierte Firewall am Local SMSC einsetzen, obwohl sie bereits eine internationale Firewall am Interconnect betreiben.
Internationale Firewalls schützen eingehendes A2P aus dem Ausland. Interne SMS-Stürme, On-Net-Phishing, Grey Routes über lokale SIM-Boxen und Sender-ID-Spoofing lokaler Banken entstehen im Netzinneren — und brauchen eine Firewall im Inneren.
Inline-Prüfung kommt nicht infrage, wenn sie spürbare Latenz verursacht. Die Firewall ist auf Fast-Path-Entscheidungen im Messaging-Kern ausgelegt und wird kontinuierlich gegen Ihre eigene SMSC-Baseline gemessen.
Keine Regel blockiert Produktions-Traffic, bevor sie nicht zunächst im reinen Protokollmodus gegen echten Traffic gelaufen ist und ihre Falsch-Positiv-Rate nachgewiesen hat. Die Umstellung auf Durchsetzung ist eine einzelne Änderung mit vollständigem Audit-Trail, und jede Blockierung ist umkehrbar.
Klare Trennung zwischen betreiberdefinierten Richtlinien und BroadNet-Empfehlungen. Genehmigungs-Workflows für sensible Regeländerungen. Vollständiger Audit-Trail dazu, wer was wann und warum geändert hat.
Vier Aktionsarten
Die Regel-Engine kombiniert inhaltliche, verhaltensbezogene und kontextuelle Signale, doch die daraus resultierende Aktion ist immer eine von vier. Jede ist prüfbar, umkehrbar und wird zunächst im Monitoring-Modus ausgerollt.
Normale Weiterleitung an den Local SMSC. Keine Einschränkung. Protokolliert mit der Regel, die sie für die Auditierung freigegeben hat.
Nachricht abweisen und den Grund speichern. Beweise werden für RA-, Regulierungs- oder Markenschutzanfragen vorgehalten.
Ratenbegrenzung nach Absender, IP, Account oder Partner anwenden. Die Nachricht wird weitergeleitet, aber der Fluss wird kontrolliert.
Metadaten anhängen oder auf einen alternativen Pfad umleiten — für Sonderbehandlung, Monetarisierung oder zusätzliche Prüfung.
Service-Stufen
Drei Betriebsmodelle. Die meisten Betreiber starten den Pilotbetrieb Co-Managed und wechseln später zu dem Modell, das ihr Team bevorzugt, sobald es mit dem Regelwerk vertraut ist.
Ihr Team verantwortet den Tagesbetrieb: Regeländerungen, Alarm-Triage, Change-Windows. BroadNet unterstützt bei komplexem Tuning, Threat-Intelligence-Updates und der Eskalation von Vorfällen.
Volle Kontrolle über das Richtlinien-Framework. BroadNet stellt Schulungen, Dokumentation, Runbooks und eine Eskalationslinie für Plattformthemen bereit. Ideal für Betreiber mit erfahrenen Security-Teams.
BroadNet übernimmt Regelverwaltung, Monitoring, Tuning und Incident Response. Der Betreiber gibt die Richtlinienrichtung vor und prüft die monatlichen Ergebnisse. Die Option mit dem geringsten Aufwand.
Funktionen
Fehlkonfigurierte interne Systeme erzeugen Schleifen, die einen Local SMSC innerhalb von Minuten lahmlegen können. Quellenbezogene Ratenlimits, Burst-Erkennung und automatische Drosselung stoppen den Sturm, bevor der Kundenservice davon erfährt.
Pflegen Sie Whitelists genehmigter Sender-IDs von Banken, Behörden und OTT-Anbietern in Abstimmung mit der jeweiligen Marke. Blockieren Sie ähnlich aussehende Varianten, Gross-/Kleinschreibungs-Imitationen und nicht registrierte Absender, die geschützte Identitäten beanspruchen.
Wiederholte kurze Anrufe zur OTP-Verifizierung werden mit der SMS-Aktivität korreliert. Kommerzielle Entscheidung: blockieren, mit Monitoring zulassen oder auf einen kostenpflichtigen Pfad leiten. Querverweis zu /operators/flash-call.
A2P-Traffic, der über Consumer-SIM-Karten zugestellt wird, umgeht kommerzielle Vereinbarungen. Musteranalyse erkennt SIM-Box-Verhalten im eigenen Netz; blockierter Traffic liefert Beweise für das RA-Team.
Jede Regel kann zunächst im reinen Protokollmodus laufen, bevor sie jemals blockiert. Validierung gegen echten Produktions-Traffic, Messung der Falsch-Positiv-Rate, anschließend Umstellung auf Durchsetzung mit einem Klick und vollständigem Änderungsprotokoll.
Detaillierte Nachrichtenprotokolle mit der ausgelösten Regel, exportierbar als CSV/JSON/PDF für Partnerstreitigkeiten und behördliche Anfragen. Aufbewahrung gemäß Ihrer IT- und Compliance-Richtlinie konfiguriert.
Bedrohungsabdeckung
| Angriffsvektor | Lokale Firewall-Steuerung | Ergebnis |
|---|---|---|
| Interne SMS Stürme und -Schleifen | Datenratenbegrenzungen pro Quelle, Burst-Erkennung und automatische Drosselung auf dem lokalen Kern. | Der Sturm wird eingedämmt, bevor das lokale SMSC zerstört wird. |
| Netzinternes sender-ID Spoofing lokaler Banken | Markenkoordinierte Whitelists mit Erkennung von ähnlichen URLs, gemischter Groß-/Kleinschreibung und nicht registrierten Absendern. | Die Nachahmung lokaler Marken wurde durch eine vollständige Protokollierung verhindert. |
| On-Net A2P -Graurouten (lokale SIM-Boxen) | A2P -vs- P2P -Musteranalyse und SIM-Box-Fingerprinting im eigenen Netzwerk. | Umgehungsstraße blockiert und dem RA-Team nachgewiesen. |
| Missbrauch von Flash-Anrufen und Sprach- OTP | Korrelation von kurzzeitigen Verifizierungsanrufen mit SMS Aktivität, gemäß den Richtlinien. | Blockieren, überwachen oder auf einen kostenpflichtigen Pfad umleiten – eine unternehmerische Entscheidung, kein blindes Loslassen. |
| Regeländerungen, die das Risiko falsch positiver Ergebnisse bergen | Jede Regel wird zunächst im reinen Protokollierungsmodus gegen den Live-Datenverkehr ausgeführt, bevor sie durchgesetzt wird. | Zuerst wird die Falsch-Positiv-Rate gemessen; die Durchsetzung erfolgt durch einen nachvollziehbaren Klick. |
Herausforderung: Eine fehlkonfigurierte interne Marketingplattform begann, dieselbe Benachrichtigungs-SMS in einer Schleife an die gesamte Teilnehmerbasis zu senden und drohte, den SMSC während der Spitzenzeiten zu überlasten. Ansatz: Eine Ratenbegrenzung für interne Quellen war bereits im Monitoring-Modus aktiv und wurde innerhalb des Change-Windows auf Durchsetzung umgestellt.
Herausforderung: Sender-ID-Spoofing großer lokaler Banken untergrub das Vertrauen der Teilnehmer in SMS als Verifizierungskanal. Ansatz: Genehmigte Sender-ID-Whitelists wurden in Partnerschaft mit den Banken eingebunden, mit Ähnlichkeitserkennung bei nahen Treffern und nicht registrierten Identitäten.
Herausforderung: Flash-Call-OTP-Traffic von OTT-Anbietern verbrauchte Sprachsignalisierungsressourcen, ohne Umsatz zu generieren, und war von legitimen Kurzanrufen nicht zu unterscheiden. Ansatz: Voice-↔-SMS-Korrelationsregeln identifizierten Flash Calls mit wiederkehrendem Muster; die kommerzielle Richtlinie entschied sich, Quellen mit hohem Volumen zu monetarisieren und den Rest zu blockieren.
On-Premise einsetzbar, auditbereit und in jedem von uns bedienten Markt behördlich anerkannt.
Kombinieren mit
Internationale A2P-Firewall am Interconnect. Das Gegenstück zum lokalen Kernschutz — gemeinsam decken sie sowohl Bedrohungen aus dem Ausland als auch On-Net-Bedrohungen ab.
Mehr erfahrenDedizierte Erkennung von OTT-Verifizierungsumgehung am internationalen Sprach-Ingress. Wird von der Local SMSC Firewall für die Voice-↔-SMS-Korrelation genutzt.
Mehr erfahrenMessaging-Kern in Carrier-Qualität. Die Local SMSC Firewall sitzt in den meisten Deployments inline/als Proxy vor diesem Gateway.
Mehr erfahrenInternationale Firewalls schützen Traffic, der aus dem Ausland eintrifft — sie sitzen am Interconnect. Die Local SMSC Firewall sitzt vor oder neben Ihrem Local SMSC und schützt den Messaging-Kern. Sie adressiert Bedrohungen, die im eigenen Netz entstehen oder internationale Schutzmaßnahmen umgehen: fehlkonfigurierte interne Systeme, On-Net-Spam, Grey Routes über lokale SIM-Boxen, Sender-ID-Spoofing lokaler Marken und Flash-Call-Missbrauch. Die beiden Lösungen ergänzen sich, und die meisten Betreiber setzen beide ein.
Typischerweise unter 10 Millisekunden pro Nachricht, End-to-End. Prüfung und Entscheidung laufen in Echtzeit auf optimierten In-Memory-Pfaden. Zum Vergleich: normale Netzschwankungen liegen häufig bei 50–100 ms, sodass die Firewall nur einen Bruchteil davon ausmacht. Wir messen und veröffentlichen die regelbezogene Latenz während des Pilotbetriebs.
Jede Regel kann zunächst im Monitoring-Modus eingesetzt werden — sie protokolliert jeden Treffer, blockiert aber nie. Sie sehen genau, was abgelehnt würde, messen die Falsch-Positiv-Rate und stellen die Regel erst dann auf Durchsetzung um, wenn Sie sich sicher fühlen. Tritt im Durchsetzungsbetrieb dennoch ein Falsch-Positiv auf, zeigt das detaillierte Protokoll genau die auslösende Regel und den auslösenden Inhalt, und die Regel kann innerhalb von Minuten angepasst oder der Absender auf die Whitelist gesetzt werden.
Beides ist möglich. Drei Stufen stehen zur Verfügung: Fully-Managed (BroadNet betreibt die Firewall, Sie legen die Richtlinie fest), Co-Managed (Ihr Team steuert den Tagesbetrieb, BroadNet unterstützt bei komplexem Tuning und Vorfällen) und Self-Service (Sie betreiben alles selbst, BroadNet stellt Schulungen, Dokumentation und Eskalation auf Plattformebene bereit). Die meisten Betreiber starten den Pilotbetrieb Co-Managed und wechseln anschließend zu dem Modell, das ihr Team bevorzugt.
Die Firewall wird typischerweise On-Premise in Ihrem Rechenzentrum eingesetzt. Nachrichteninhalte werden in Echtzeit analysiert und nicht gespeichert — protokolliert werden nur Metadaten und Nachweise zu Regeltreffern. Aufbewahrung der Protokolle und Zugriffskontrollen richten sich nach Ihren internen IT- und Compliance-Richtlinien. Kein Inhalt verlässt Ihr Netz ohne Ihre ausdrückliche Zustimmung.
Ein typisches Projekt beginnt mit einem technischen Workshop zwischen Ihren Netz-, Security- und IT-Teams und den BroadNet-Ingenieuren, gefolgt von einem Pilotbetrieb auf einer Teilmenge von Routen oder Partnern (zunächst laufen alle Regeln nur im Monitoring-Modus) und anschließend einem schrittweisen Rollout der Durchsetzung. Der gesamte Weg — vom Workshop bis zur vollständigen Durchsetzung — dauert bei den meisten Deployments mehrere Monate; der genaue Zeitplan hängt von der Komplexität der Umgebung und dem gewünschten Rhythmus des Regel-Tunings ab.
Detaillierte Nachrichtenprotokolle ordnen jede Entscheidung eindeutig der jeweiligen Regel zu. Blockierte Grey-Route-Versuche, Traffic mit SIM-Box-Mustern und nicht autorisierte A2P-als-P2P-Zustellungen sind als Beweispakete — CSV/JSON/PDF — für Partnerstreitigkeiten und behördliche Anfragen exportierbar. Das RA-Team erhält zuordenbare Nachweise dafür, dass ein zuvor unsichtbarer Verlust quantifiziert und adressiert wurde.
Ja. Die Firewall integriert sich über API und Syslog in gängige Monitoring-Stacks, Ticketing-Systeme und SIEM-Plattformen. Sicherheitsereignisse erscheinen in den operativen Workflows, die Ihre Teams bereits nutzen. Konkrete Integrationen werden während des technischen Workshops festgelegt.
Die Frage ist nicht dabei? Fragen Sie unser Ingenieurteam
Netzwerkinterne SMS und SS7 Firewalls unterbinden Graurouten und Betrug mit Leitungsgeschwindigkeit, während der legitime Datenverkehr unberührt bleibt.
Bringen Sie Ihre Netz-, Security- und IT-Teams mit. Wir grenzen die Integration ab, entwerfen das initiale Regelwerk und fahren die erste Phase im Monitoring-Modus — keine Produktionsblockierung, bis Sie es entscheiden.
