• 08621 - 9 88 30 88

Kategorien-Archiv Blog

Voncubewerk

KRACK – Kritische Lücke in WLAN-Netzwerken entdeckt – was ist zu tun?

KRACK – Kritische Lücke in WLAN-Netzwerken entdeckt – was ist zu tun?

Sehr geehrte Damen und Herren,

Mathy Vanhoef von der KU Leuven (Belgien) hat am gestrigen Montag eine gravierende Lücke in der aktuell als sicher geglaubten WLAN-Verschlüsselung WPA2 entdeckt. Um Ihnen beim Umgang mit dieser Sicherheitslücke zu helfen, stellen wir Ihnen die wichtigsten Fragen & Antworten bereit.

Bin ich angreifbar?

Mit ziemlicher Sicherheit ja. Diese Lücke basiert auf einem Fehler im eigentlichen Protokollablauf und ist herstellerunabhängig.

Was ist durch die Lücke für Angreifer möglich und wie sieht ein Angriff aus?

Der Angreifer muss sich für einen Angriff in der Nähe eines Endgerätes und WLAN-Senders (Router, Accesspoint, Firewall mit WLAN, Accessport) befinden. Da bereits Angriffstools im Umlauf sind, kann die Lücke ohne großen technischen Aufwand ausgenutzt werden. Hierdurch ist ein Zugriff auf das WLAN-Netzwerk ohne Kenntnis Ihres geheimen Schlüssels möglich. Dadurch können sämtliche Daten mitgeschnitten und Verbindungen (Online-Banking, Bestellungen, E-Mails uvm.) manipuliert werden.

Wie kann ich mich schützen?

Derzeit bereiten viele Hersteller Updates für ihre Endgeräte vor. Diese werden jedoch nur selten automatisch installiert oder gar zur Verfügung gestellt. Leider werden viele ältere Telefone und Tablets nicht mehr mit Updates versorgt. Hier muss im Einzelfall geprüft werden. Auch stehen für die meisten Router/Firewalls nur manuelle Updates zur Verfügung. Viele Geräte sind auch hier bereits EOL (End of Life) und somit außerhalb jeder Wartung.

Welche schnelle Lösung gibt es?

Verzichten Sie auf WLAN. Deaktivieren Sie alle WLAN-Verbindungen. Verwenden Sie eine kabelgebundene Verbindung.

Hilft es das WLAN-Kennwort zu ändern?

Nein. Egal ob Sie ein sicheres oder unsicheres Kennwort verwenden. Der Angriff greift nicht das WLAN-Kennwort selbst an, sondern nutzt eine Lücke in der Aushandlung des Kennwortes aus.

Gibt es weitere Informationen zu dieser Lücke?

Ja. Das CERT listet aktuell alle verwundbaren Hersteller. Die Adresse ist

https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4

Wie sichere ich meine Umgebung gegen diese Angriffe ab?

Die cubewerk GmbH bietet aktuell eine WLAN Sicherheitsanalyse inkl. Vorort-Besprechung zur Eindämmung der Lücke an.

Inhalt:

  • Kontrolle der WLAN-Zugangspunkte auf Verwundbarkeit und Verfügbarkeit von Updates
  • Kontrolle Endgeräte inkl. Prüfung gegen verfügbare Updates
  • Koordinierung der Einspielung und ggf. Bereitstellung von Updates
  • Empfehlung zum Umgang mit Endgeräten ohne verfügbare Updates
  • Abschlussgespräch

Der Preis der IT-Sicherheitsanalyse richtet sich nach der Anzahl der Sender und Endgeräte.

Bis 5 Geräte – 249,- €
Bis 10 Geräte – 349,- €
Bis 50 Geräte – 799,- €
Kunden mit einem gültigen cubewerk Wartungsvertrag erhalten 50 % Nachlass auf den Angebotspreis.
Alle Preise zzgl. MwSt. und Fahrtkosten.

Antworten Sie jetzt einfach auf diese E-Mail und holen sich Ihr Netzwerk zurück!

Mit freundlichen Grüßen

Stefan Bauer

Voncubewerk

cubewerk ist 3CX Silver Partner

Die cubewerk GmbH konnte die Zusammenarbeit mit 3CX weiter ausbauen. Ab sofort sind wir zertifizierter 3CX Silver Partner.

Voncubewerk

A10 Lodbalancer Workshop erfolgreich abgeschlossen

Die cubewerk GmbH schließt mit zwei Technikern den zweitägigen A10 Loadbalancer-Workshop in München ab.

Tolle Eindrücke, tolles Produkt. Besteht bei Ihnen zukünftig Beratungsbedarf im Bereich Loadbalancer, Threat-Protection oder Traffic-Offloading, stehen wir Ihnen gerne mit Rat und Tat aus der Praxis zur Verfügung. 

Voncubewerk

3cx Kennwort auslesen für Verwaltungskonsole

Eintrag folgt nach Verifizierung. Bitte kurz durchklingeln bei uns telefonisch. Passwort kann in wenigen Minuten zurückgesetzt werden.

Voncubewerk

3cx Anklopfen aktivieren für Signalisierungsgruppe

Einerseits muss im Telefon Call Waiting / Anklopfen usw. aktiviert sein. Exemplarisch ein Bild von einem Grandstream Telefon (schlechte Übersetzung):

Zusätzlich muss in der 3CX konfiguriert werden, dass sich die Anlage nicht auf den 3CX-Status eines Telefons verlassen soll (also belegt oder frei) sondern auf den Status des Telefons.

Voncubewerk

Umstieg von Askozia auf 3CX – Lizenzen und Preise

Für Umsteiger von Askozia auf 3CX stellt sich die Frage nach der Lizenzierung. Besitzer einer gültigen Askozia Lizenz erhalten kostenlos eine 8 Kanal Professional Lizenz von 3CX ohne zeitliche Begrenzung.

Sprechen Sie uns an! Was tun bei mehr als 8 benötigten Kanälen? Hierzu gibt es Upgrade-Pakete zur Erweiterung der Kanäle. Alle Preise und Upgrade-Möglichkeiten finden Sie in unserer Preisübersicht.

Voncubewerk

Askozia wird 3CX – das Ende von Askozia – 3CX übernimmt Askozia

Heute wurden die Askozia Partner informiert, dass Askozia mit 3CX fusioniert und das Produkt „Askozia“ stirbt. Partner werden animiert, zukünftig 3CX zu vermarkten. Ab sofort sind keine Askozia Produkte mehr erhältlich.

Zum 31.12.2017 wird der offizielle Askozia-Support eingestellt.

Die cubewerk GmbH setzt an dieser Stelle zukünftig auf die Bereitstellung von 3CX Telefonanlagen. Falls bei Ihnen noch eine Askozia TK-Anlage im Einsatz ist, beraten wir Sie gerne zum Umstieg und übernehmen die Migration der Anlage. Bitte Beachten Sie unsere weitere Seite zum Thema 3CX Versionen und Migrationswege für Askozia.

Voncubewerk

Gründe für die Portierungsablehnung bei Rufnummernportierung

Für jeden Dienstleister oder Anbieter von Telefonielösungen ist die Portierung von Rufnummern von Fremdanbietern ein wichtiger Baustein des Serviceangebotes. Wer will schon auf seine Nummern verzichten beim Wechsel.

Durch die enorme Anzahl unterschiedlicher Anbieter, nicht kompatibler Portierungssysteme und dem Faktor Mensch, hat sich die Bundesnetzagentur als hoheitliche Instanz ein Konzept überlegt, wie der Portierungsprozess ablaufen kann und auch muss.

Hierzu gibt es das Dokument Spezifikation Version 3.0 Ablauf bei der Vorabstimmung (Stand 2012), was die wesentliche Portierung beschreibt.

Wichtig bei der Rufnummernportierung sind häufig die Ablehnungsgründe – also was habe ich falsch ausgefüllt bzw. was fehlt. Hierzu gibt es folgende standardisierte Gründe für die Ablehnung:

RNG = Rufnummer nicht geschaltet (Hinweis: Sofern EKPauf mind. Eine
richtige Rufnummer in der Vorabstimmungsanfrage angegeben
hat, nennt EKPabg in der Ablehnung alle bei EKPabg
bereitgestellten Rufnummern des Kunden. Nennt EKPabg keine
richtige Rufnummer, erfolgt nur die Ablehnung ohne Angabe der
Rufnummern).

ADF = Adresse falsch (je falschem Adresselement ein Code)

AIF = Anschlussinhaber falsch (ist nur der Vorname falsch, erfolgt AIF mit
Zusatz „Vorname falsch“)

WAI = Weitere Anschlussinhaber

KNI = Kunde nicht identifizierbar (anzuwenden, wenn gar keine
Identifizierung eines Kunden anhand eines Merkmals möglich ist)

VAE = Vorabstimmung anderer EKP liegt vor

SON = Sonstiges (immer mit Begründung im Freitext)

Quelle: Bundesnetzagentur

Voncubewerk

Asterisk registertimeout und Anpassung bei mehreren Peers

Grundlagen:

Man nehme eine Asterisk TK-Anlage hinter einer FritzBox. Alle 90 Sekunden registriert sich in der Regel die Anlage beim Provider (z.B. Easybell).

Ist dies dem Anbieter zu häufig, antwortet er auf die Registrierung mit einem

Contact: <sip:nummer@IP:5060>;expires=600

expires=600 ist eine Aufforderung an den Client, zukünftig nur alle 600 Sekunden eine neue Registrierung anzustoßen.

Das tritt auch auf, wenn man z.B. mehrere Rufnummern in Askozia einzeln beim Provider registriert. Das führt dann zu zu häufigen Registrierungen.

Die Probleme:

Damit der Anbieter eingehende Anrufe an die Asterisk signalisieren kann, besteht eine mehr oder weniger dauerhafte Verbindung zwischen Asterisk und dem Provider.  Firewalls vor der Asterisk benötigen regelmäßigen Verkehr, damit die Verbindung auch in der Firewall dauerhaft aufrecht erhalten bleibt.

Wie sieht das konkret aus:

12:16:03.692450 IP askoziapbx.local.5060 > 195.185.37.60.5060: SIP: REGISTER sip:sip.easybell.de SIP/2.0
12:16:03.727299 IP 195.185.37.60.5060 > askoziapbx.local.5060: SIP: SIP/2.0 401 Unauthorized
12:16:03.728225 IP askoziapbx.local.5060 > 195.185.37.60.5060: SIP: REGISTER sip:sip.easybell.de SIP/2.0
12:16:03.771253 IP 195.185.37.60.5060 > askoziapbx.local.5060: SIP: SIP/2.0 200 OK

Nach diesen 4 Paketen ist die Nummer registriert und es besteht eine zeitlich beschränkte Verbindung zwischen Asterisk und Anbieter.

Bug/Problem 1:

Das Easybell-Providertemplate von Askozia (ist Asterisk) nutzt Port 5064 als Port zu Registrierung. Dieser Port wird jedoch im ausgehenden REGISTER ignoriert. Dies scheint ein bekannter Asterisk-Bug zu sein. In obigem TCPDUMP wird 5060 statt 5064 verwendet.

Dies alleine wäre noch nicht so fatal – die Nummer ist ja registriert.

Da jedoch Firewalls nicht jede Verbindung dauerhaft offen halten (FritzBox¹ z.B. max 5 Minuten für UDP-Verbindungen), muss innerhalb von 5 Minuten mindestens einmal Verkehr zum Provider stattfinden, damit die Verbindung dauerhaft besteht und eingehende Anrufe signalisiert werden können.

Entweder man registriert die Rufnummer in einem kurzen Intervall (< 5 Minuten) ständig neu, oder man nutzt Keep-Alive (Ping-Pong) Pakete zwischen Provider und Asterisk.

Diese Pakete sehen wie folgt aus:

12:15:44.082202 IP askoziapbx.local.5060 > 195.185.37.60.5064: SIP: OPTIONS sip:sip.easybell.de SIP/2.0
12:15:44.112037 IP 195.185.37.60.5064 > askoziapbx.local.5060: SIP: SIP/2.0 200 Alive

Problem 2:

Diese Pakete sind jedoch wertlos für die eigentliche Anrufsignalisierung des Providers, da hier die Ports anders sind. Hier verwendet Asterisk den korrekten Port 5064.

Durch obige Keep-Alive-Pakete hat die Firewall in ihrer NAT-Tabelle einen Eintrag in der Form:

askoziapbx.local.5060 > 195.185.37.60.5064

Antworten (genau andersrum) von

195.185.37.60.5064 > askoziapbx.local.5060

werden automatisch weitergeleitet und können einer Verbindung zugeordnet werden.

Eingehende Anrufe werden jedoch vom Anbieter in folgender Form signalisiert:

11:57:14.713468 IP 195.185.37.60.5060 > askoziapbx.local.5060: SIP: INVITE sip:zielnummer@öffentliche-IP:5060 SIP/2.0

Man beachte die Ports. Diese passen nicht zur obigen erwarteten Verbindung Provider:5060 an eigene-IP:5060 und werden deshalb verworfen.

Lösung(en)?

Bug in Asterisk fixen (lassen). Ticket bei Askozia ist offen seit Juni 2017. Alterantiv den Standardport 5060 im Providertemplate nutzen, damit OPTIONS- und REGISTER-Ports zusammen passen.

UDP-Timeout in Firewall erhöhen auf > Registrierdauer bei Provider

Mit Netcat ständig Verbindung zwischen Anlage & Provider aufrecht erhalten

Verkehr generieren, der die UDP-Verbindung in FW aufrecht erhält.

Grausiger Workaround – Dummy-Sip-Nummer in FritzBox registrieren – das hat dazu geführt, dass der Port 5060 irgendwie offen bleibt für Geräte dahinter. Jedoch nur bis zu einer bestimmten Anzahl von SIP-Nummern. Eigentlich keine Lösung.

¹ https://avm.de/service/fritzbox/fritzbox-7360-sl/wissensdatenbank/publication/show/907_Anwendung-z-B-SSH-verliert-gelegentlich-die-Verbindung-zu-Gegenstellen-im-Internet/

Voncubewerk

Askozia Fritzbox und Easybell – eine unglückliche Verkettung

Bei einigen Installationen ist uns aufgefallen, dass eingehenden Anrufe gelegentlich nicht durch die FritzBox weitergeleitet werden an die TK-Anlage dahinter. Nach etwas Diagnose sahen wir in der FritzBox folgendes Paket:

Destination unreachable: Administratively prohibited

Nach längerer Suche war uns klar, die FritzBox blockiert zurecht, da der Provider auf Port 5060 signalisiert – hier läuft jedoch die Telefonie der FritzBox. Laut Easybell besteht auch ein alternativer Port 5064.

In Askozia ist dieser Port jedoch hinterlegt – ausgehende REGISTER Pakete verwenden jedoch Port 5060. Klarer Bug in der Uraltversion von Asterisk in Askozia. Aktuell heißt es auf ein Bugfix zu warten.

Komischerweise haben die OPTIONS-Pakete den richtigen Port 5064.