Vortrag - VCC

Kompetenzzentrum für Videokonferenzdienste (VCC)
Abwehr von SPAM-Anrufen bei VCGeräten mit dem GNUGK V3.8
Zellescher Weg 12
Willers-Bau A217
Tel. +49 351 - 463 - 35653
Sebastian Liebscher ([email protected])
Inhalt
Spam-Anrufe über H.323
– Problemdarstellung
– Alternative Abwehrstrategien ohne GnuGK
GnuGK (GNU Gatekeeper)
– Kurzvorstellung GnuGK
– Neuerungen in der Version 3.8 (3.9)
– Sinnvolle Anpassungen in der Konfiguration
Abwehr der Spam-Anrufe
– Detailbetrachtung der Spam-Anrufe
– Mechanismen zur Abwehr
– Praktische Erfahrungen
– Ausblick auf evtl. zukünftig auftretende Probleme
Zusammenfassung
Sebastian Liebscher
2
Abwehr von SPAM-Anrufen
SPAM-ANRUFE ÜBER H.323
Sebastian Liebscher
3
Problemdarstellung
Verbindungsversuche über H.323 (Port 1720)
Kontaktierung per IP, nicht über GDS
H.323-Name: vornehmlich „cisco“
Evtl. Registrierung
Standort beliebig
GDS-Verbund
(World-GK,
Country-GK etc.)
Evtl. Anbindung
Automatisierte H.323-Netzscans (von speziellem Tool auf Cloud-Servern)
Ziel: Suche von Gateways in das ISDN- / Telefonnetz
Absicht: Telefonnutzung auf fremde Kosten bzw. Verkauf der Zugangsdaten
Vergleich: SIP-Angriffe auf SIP-Server (z.B. VoIP)
Sebastian Liebscher
4
Alternative Abwehrstrategien ohne GnuGK
Blacklist von bekannten Spam-IP-Adressen:
– Nicht alle Spam-IP-Adressen bekannt
– Ständige Aktualisierung der Liste nötig
Erstellung von Positivlisten für IP-Adressen von zulässigen VC-Geräten:
– Nur möglich wenn alle potenziellen Anrufer bekannt sind
– Im wissenschaftlichen Umfeld impraktikabel
Sperren von Port 1720 (TCP/UDP) für eingehende Verbindungen:
– Keine Rufbarkeit von außerhalb der eigenen Institution
– Funktioniert nicht, wenn beide Gesprächspartner diese Lösung wählen
Umzug der VC-Geräte in ein internes geschütztes Netz:
– Keine Erreichbarkeit von außerhalb der eigenen Institution
Kommerzielle Lösung:
– Z.B. Einrichtung eines Firewall-Traversals
Sebastian Liebscher
5
Abwehr von SPAM-Anrufen
GNUGK (GNU GATEKEEPER)
Sebastian Liebscher
6
Kurzvorstellung GnuGK
Sebastian Liebscher
7
Kurzvorstellung GnuGK
Freie Software
Läuft unter Linux, Windows, MacOS X, Solaris, FreeBSD, OpenBSD, NetBSD
Unterstützt H.323 v8, H.323 Annex O, IPv4, IPv6, dual stack
Bietet zahlreiche Methoden für:
– Authentifizierung von Endgeräten
– Authentifizierung von Anrufen
Anbindung an Datenbanken möglich:
– ODBC, MySQL, MariaDB, PostgreSQL, SQLite, Firebird
Unterstützt flexibles Routing von Anrufen, Umschreibung von Rufnummern
Einbettbar in weltweite GDS-Struktur
Nutzbar als H.323-Proxy
Unterstützt NAT-Traversal
Graphisches Nutzerinterface verfügbar
Sebastian Liebscher
7
Neuerungen in der Version 3.8 (3.9)
Allgemeine Neuerungen beim GnuGK in der Version 3.8:
– Kommerzielles Add-On: Neues Webinterface (unter PHP) für
Konfiguration und Überwachung des GnuGK
– CatchAll-Regel ersetzt nun Ziel-Alias entsprechend
– Möglichkeit der Ausfilterung ganzer „Fähigkeitsklassen“ (z.B. H.239)
– Schalter „[Gatekeeper::Main] MinH323Version=“
– Behebung von diversen Problemen und Abstürzen
Neuerungen aufgrund der Spam-Anrufe:
– Verbesserte Nutzung und Erzeugung von Zufallszahlen
– Schalter „[RasSrv::ARQFeatures] CheckSenderIP=“
– Neues Authentifizierungs-Modul: LuaAuth
– Verbesserungen bei anderen Authentifizierungs-Modulen:
• FileIPAuth, AliasAuth, PrefixAuth, SQLAuth
Sebastian Liebscher
8
Neuerungen in der Version 3.8 (3.9) - II
Wichtige Neuerungen beim GnuGK in der Version 3.9:
– Neues Authentifizierungs-Modul: GeoIPAuth:
• Überprüfung anhand der Landeszugehörigkeit
• Liste der Zuordnung von IP-Adressen zu Ländern nötig
– Verbesserung Status-Port:
• Möglichkeit zur Speicherung der letzten n Ereignisse
• Nachträgliche Abrufbarkeit gegeben
• Alternative zu Log-Datei
Sebastian Liebscher
9
Sinnvolle Anpassungen in der Konfiguration
Alte Konfiguration - Auszug:
Neue Konfiguration - Auszug:
[Gatekeeper::Main]
Fourtytwo=42
Name=00493514632
TimeToLive=300
Home=141.30.xxx.yyy
NetworkInterfaces=141.30.xxx.yyy/32
StatusPort=7000
UseBroadcastListener=0
[Gatekeeper::Main]
[RasSrv::LRQFeatures]
CiscoGKCompatible=1
IncludeDestinationInfoInLCF=0
ForwardHopCount=10
AcceptNonNeighborLCF=1
[RasSrv::LRQFeatures]
Name=00493514632
TimeToLive=300
Home=141.30.xxx.yyy
NetworkInterfaces=141.30.xxx.yyy/32
StatusPort=7000
UseBroadcastListener=0
AcceptNonNeighborLCF=1
Sebastian Liebscher
10
Sinnvolle Anpassungen in der Konfiguration - II
Alte Konfiguration - Auszug:
Neue Konfiguration - Auszug:
[RasSrv::Neighbors]
m=141.30.xxx.zzz:1719;00493514631
[RasSrv::Neighbors]
GK1=GnuGk / CiscoGk / ClarentGk /
Glonetgk
[Neighbor::GK1]
GatekeeperIdentifier=GK1
Host=141.30.xxx.zzz:1719
SendPrefixes=00493514631
AcceptPrefixes=*
ForwardHopCount=10
ForwardLRQ=always
[RasSrv::ARQFeatures]
CheckSenderIP=1
Sebastian Liebscher
11
Abwehr von SPAM-Anrufen
ABWEHR DER SPAM-ANRUFE
Sebastian Liebscher
12
Detailbetrachtung der Spam-Anrufe
Verbindungsversuche über H.323 (Port 1720)
Kontaktierung per IP, nicht über GDS
H.323-Name: vornehmlich „cisco“
Standort beliebig
Auszug eines typischen Logeintrags eines Spam-Anrufs (Teil 1):
callType = pointToPoint
destinationInfo = 1 entries {
[0]=dialedDigits „9010441227806181“
}
destCallSignalAddress = ipAddress {
ip = 4 octets {
8d 1e 43 f7
..C.
}
port = 1720
}
Sebastian Liebscher
13
Detailbetrachtung der Spam-Anrufe - II
Verbindungsversuche über H.323 (Port 1720)
Kontaktierung per IP, nicht über GDS
H.323-Name: vornehmlich „cisco“
Standort beliebig
Auszug eines typischen Logeintrags eines Spam-Anrufs (Teil 2):
srcInfo = 1 entries {
[0]=h323_ID 5 characters {
0063 0069 0073 0063 006f
}
}
srcCallSignalAddress = ipAddress {
ip = 4 octets {
d0 46 38 3c
}
port = 43164
}
cisco
.F8<
Sebastian Liebscher
14
Mechanismen zur Abwehr
Für Kontrolle der Anrufe am Gatekeeper Routed Mode erforderlich:
– Standardmäßig nur RAS – Nachrichten (H.225) über Gatekeeper
– 3 Abstufungen beim Routed Mode möglich:
• 1. Stufe: Zusätzlich Rufsignalisierung (Q.931) über Gatekeeper
• 2. Stufe: Zusätzlich Parameteraushandlung (H.245) über Gatekeeper
• 3. Stufe: Alle Pakete über Gatekeeper (Proxy)
– 1. Stufe für Kontrolle der Anrufe ausreichend
Nötige Konfigurationsänderung beim GnuGK:
[RoutedMode]
GKRouted=1
H245Routed=0
CallSignalPort=1720
AcceptUnregisteredCalls=1
Sebastian Liebscher
15
Mechanismen zur Abwehr - II
Ablauf eines typischen Rufes im Routed Mode (1. Stufe): 1. Schritt
Ruf auf Port 1720 (Q.931: CS: setup, CS: status)
Rückantwort: CS: callProceeding
Sebastian Liebscher
16
Mechanismen zur Abwehr - II
Ablauf eines typischen Rufes im Routed Mode (1. Stufe): 1. Schritt
Ruf auf Port 1720 (Q.931: CS: setup, CS: status)
Rückantwort: CS: callProceeding
RAS: admissionReject:
Port 1719: RAS: admissionRequest
Rückantwort: RAS: admissionReject
– Ablehnungsgrund: routeCallToGatekeeper
Sebastian Liebscher
16
Mechanismen zur Abwehr - II
Ablauf eines typischen Rufes im Routed Mode (1. Stufe): 1. Schritt
Ruf auf Port 1720 (Q.931: CS: setup, CS: status)
Rückantwort: CS: callProceeding
Weitere Rückantwort:
CS: facility, CS: releaseComplete
RAS: admissionReject:
Port 1719: RAS: admissionRequest
Rückantwort: RAS: admissionReject
– Ablehnungsgrund: routeCallToGatekeeper
CS: facility:
– Enthält IP-Adresse und Port des Gatekeepers des Ziel-Geräts
(Eintrag: alternativeAddress: ipAddress)
– Enthält Grund für Umleitung: routeCallToGatekeeper
Sebastian Liebscher
16
Mechanismen zur Abwehr - III
Ablauf eines typischen Rufes im Routed Mode (1. Stufe): 2. Schritt (Kurzform)
Port 1719: RAS: admissionRequest
Rückantwort: RAS: admissionConfirm
Ruf auf Port 1720 (Q.931) über Gatekeeper an Ziel-Gerät
Rückantworten (Q.931): ebenfalls über Gatekeeper
Sebastian Liebscher
17
Mechanismen zur Abwehr - III
Ablauf eines typischen Rufes im Routed Mode (1. Stufe): 2. Schritt (Kurzform)
Aufbau des Rufes (H.245, RTP / RTCP)
Port 1719: RAS: admissionRequest
Rückantwort: RAS: admissionConfirm
Ruf auf Port 1720 (Q.931) über Gatekeeper an Ziel-Gerät
Rückantworten (Q.931): ebenfalls über Gatekeeper
Sebastian Liebscher
17
Mechanismen zur Abwehr - III
Ablauf eines typischen Rufes im Routed Mode (1. Stufe): 2. Schritt (Kurzform)
Aufbau des Rufes (H.245, RTP / RTCP)
Feststellung:
Spam-Anrufe werden schon Port 1719: RAS: admissionRequest
Rückantwort: RAS: admissionConfirm
geblockt !
Grund: 2. Verbindung über
Gatekeeper wird nicht initiiert
Ruf auf Port 1720 (Q.931) über Gatekeeper an Ziel-Gerät
Rückantworten (Q.931): ebenfalls über Gatekeeper
Sebastian Liebscher
17
Praktische Erfahrungen
Routed Mode:
– Spam-Anrufe werden zuverlässig geblockt
– Rufe per IP und GDS weiterhin möglich (Rufrichtung egal)
– Einzelne Probleme mit Gegenstellen, die ebenfalls die 2. Verbindung
über den Gatekeeper nicht initiieren:
• Problem tritt nur mit Gegenstellen auf, die nicht rufbar sind (Firewall /
NAT / Internet-Proxy etc.) und per IP rufen
• Nachstellung des Problems im VCC bisher nicht gelungen
• Wechsel der Konfiguration bzw. des Gatekeepers nötig, um
Verbindung aufbauen zu können
AcceptUnregisteredCalls=0:
– Nur Annahme von Rufen von registrierten Endgeräten und über bekannte
Gatekeeper (Nachbar-GK), also auch kein URI-Dialing möglich
– Rufe von nicht registrierten Endgeräten können trotzdem über bekannte
Gatekeeper (mit AcceptUnregisteredCalls=1) eintreffen
Sebastian Liebscher
18
Ausblick auf evtl. zukünftig auftretende Probleme
URI-Dialing in der Form „h323:[email protected]“ kommt
am Endgerät (141.30.67.247) an:
– 2. Verbindung über Gatekeeper wird aufgebaut
– Logeinträge decken sich mit Logeinträgen der Spam-Anrufe
Spam-Anrufe könnten auch Gatekeeper erreichen (Initiierung 2. Verbindung)
Daher evtl. weitere Abwehrmechanismen notwendig:
– Abfrage der Länderzugehörigkeit (GeoIPAuth)
– Nutzung einer SQL-Datenbank für Abfragen (SQLAuth):
• Test von IP-Rufen an Endgeräten auf zusätzliche „dialedDigits“
• Blockierung des H.323-Namens „cisco“
– Beschränkung auf IP-Basis mit Blacklist / Whitelist (FileIPAuth)
Weiterer generell sinnvoller Abwehrmechanismus:
– Kritische Systeme (z.B. ISDN-Gateways) dürfen nur lokal erreichbar sein
Sebastian Liebscher
19
Abwehr von SPAM-Anrufen
ZUSAMMENFASSUNG
Sebastian Liebscher
20
Zusammenfassung
Spam-Anrufe schwer von gewöhnlichen Rufen abzugrenzen
Schadenspotenzial reicht von DoS bis zu Kosten durch Fremdnutzung
Es existiert derzeit keine „beste“ Lösung als Abwehrmechanismus
Sehr gute Abschirmung (z.B. mit Routed Mode und
AcceptUnregisteredCalls=0) nur in kleinen bzw. sehr einheitlichen
Umgebungen (z.B. Firmennetzwerke) zu erreichen
Weitere Entwicklungen bei Spam-Anrufen und Abwehrmechanismen zu
erwarten
Upgrade auf neueste GnuGK-Version lohnenswert
Vielen Dank für Ihre Aufmerksamkeit !
Sebastian Liebscher
21

Download Report