Firewall blokkeert telefoongesprekken naar Amerikaanse alarmlijn 911
Een probleem met een firewall heeft er afgelopen dinsdag voor gezorgd dat alarmlijn 911 twee uur niet bereikbaar was in de hele Amerikaanse staat Massachusetts. Volgens de leverancier van het alarmsysteem en het Executive Office of Public Safety and Security van de staat zorgde een firewall ervoor dat gesprekken niet naar de 911-alarmcentrale werden doorgezet. Het incident zou niet het geval zijn van een cyberaanval, aldus leverancier Comtech.
De exacte reden waarom de firewall gesprekken blokkeerde wordt nog onderzocht. Comtech heeft een "technische oplossing" toegepast om herhaling in de toekomst te voorkomen. Gouverneur Maura Healey van Massachusetts liet verslaggevers weten dat de firewall "te beschermend" was en daardoor de gesprekken blokkeerde. Tijdens de storing ontvingen inwoners van de staat een bericht op hun telefoon dat ze in het geval van nood direct de politie of brandweer moesten bellen, meldt CBS News.
https://en.wikipedia.org/wiki/Massachusetts#Health
Hoeveel hartaanvallen, beroerten en flauwtes hebben er plaats gevonden gedurende de twee uur van 911-storing?
user error, replace user...
user error, replace user...
Dan heb jij nog nooit een problematische IPS signature op je firewall binnengekregen.
user error, replace user...
Wij hadden zoiets soortgelijks met een Fortigate gedeelte ging goed echter verkeer op UDP (poort 50xxx) werd naar internet gestuurd ipv de server. Hierdoor kregen bellers geen keuzemenu.
user error, replace user...
Dan heb jij nog nooit een problematische IPS signature op je firewall binnengekregen.
Dat is inderdaad een mogelijke oorzaak.
Andere theorie voor 'het stopte opeens met werken' zou een failover naar een standby firewall kunnen zijn waarvan de rulebase niet in sync was.
Nog een mogelijke theorie zou een failover (of wijziging) kunnen zijn van de sources die door de firewall moeten - maar waarvan het nieuwe (cq - standby ) netwerk adres niet in de rulebase zit .
Zeker als de failover helemaal automatisch gemaakt is - normaal kijkt men bij iedere storing "wat is er gewijzigd op het moment dat de storing begon" , en dan was er niemand die iets aan de firewalls deed, en ook niemand die iets op het netwerk of aan de call servers deed. Behalve een storing ergens die leidde tot een failover - en mogelijk eentje met andere source IPs .
Het kan erg complex worden - ik heb rules gezien die er alleen in staan - en in moeten staan - zodat de failover naar het andere datacenter kan werken . Zo'n rule krijgt nooit hits . En is voortdurend at risk voor de 'rule cleanup' projecten, want geen hits , en men streeft er - terecht - naar om geen stale/ongebruikte rules actief te laten.
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Specialiseer je in Forensisch ICT
Online informatieavond 19 november
Wil jij je specialiseren in digitaal forensisch onderzoek? Je kennis verbreden en tech-nische vaardigheden ontwikkelen? Ontdek de cursus- en opleidingsmogelijkheden van Hogeschool Leiden:
- Bachelor Informatica Forensisch ICT (deeltijd)
- Master Digital Forensics (vol- en deeltijd)
- Module Mobile Forensics
- Module Data Analytics
Interesse? Meld je aan!
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
