3
sichere ISDN Punkt zu Punkt-Verbindung?
Absichern von bidirektionalen ISDN-Punkt-zu-Punkt-Verbindungen.
Hallo,
hatte bereits eine Frage in gleicher Angelegenheit hier gestellt (17.2.07), jetzt geht es mir jedoch um etwas anderes.
Kann man eine ISDN-Punkt-zu-Punkt-Verbindung 'absichern'? Ich meine ohne ISDN-VLAN.
Wie seht ihr das Sicherheitsrisiko? Fällt mir irgendwie schwer zu bewerten auch konkte ein Szenario auszumalen, was überhaupt passieren könnte.. unabhängig davon, ob es missbraucht wird - es geht mir um dieTragweite. Aber laut dem Hinweis unten im X1, traue ich fast nix mehr..
Hintergrund: Es müssen sensible Daten bidirektional über eine ISDN-Verbindung ausgetauscht werden. Als Datenschutz wird zur Verschlüssenung der Daten eine in diesem Bereich anerkannte Verschlüsselungs-SW eingesetzt. Potentiell wird eine Gefahr gesehen, dass ein solcher Rechner als Relay missbraucht werden kann, sofern dieser auch im Firmeneigenen Netz steht. Und dass durch die bidirektionale Verbindung der Rechner kompromittiert und somit Zugang zum Firmenetz erreicht werden kann.
Aktuell ist dieses Problem so gelöst, dass dieser Rechner autark ist und die Daten (unverschlüsselt) an einem anderen Speicherort getragen werden. Nachteil: Daten sind auf USB-Stick unverschlüsselt, der Rechner ist so nicht Viren-Pattern-Update, Sicherung gibt es auch keine. Nun besteht der Anspruch, dass die sensiblen Daten unverschlüsselt gesichert via Netz auf bestimme Speicherorte übertragen werden kann. Dazu müsste dieser Rechner in das Firmennetz.
Ich über lege auch, ob es möglich ist, den im Firmen-Netz in ein VLAN zu stellen, die Kommunikation zuzulassen (dafür gibt es aktuell keine andere Wahl). Der Rechner wird im RZ weggesperrt, Zugriff auf diesen Rechner erfolgt via Terminal-Service X1. Die Daten von einem anderen Rechner abzuholen (oneway), dort werden sie auch nach aktuellem Firmenstd. nach Viren gescannt, von diesem Rechner werden die Daten von einer Unix-Maschine abgeholt (auch oneway).
Frage:
1. Unterstützung zur Risokoabschätzung und mögl. Absicherung
2. wäre meine Überlegung diesen Rechner in ein VLAN zu stellen usw. realistisch und umsetzbar. Z.B. auch durch GPOs, darin kenne ich mich leider nicht aus.
Danke,
Gruß Tanja
X1: Der Rechner soll deshalb ins RZ, weil wir nicht die 100% Kontrolle über diesen Rechner haebn. Er hat eine Onboad-NW-Karte und so wir unsere NW-Infrastruktur aufgebaut ist, war es möglich, diesen Rechner ins Firmennetz zu hängen, was auch ohne Erlaubnis passiert ist.. Auf und weg. dieser Aktion muss nur eine andere Lösung gefunden werden.
Hallo,
hatte bereits eine Frage in gleicher Angelegenheit hier gestellt (17.2.07), jetzt geht es mir jedoch um etwas anderes.
Kann man eine ISDN-Punkt-zu-Punkt-Verbindung 'absichern'? Ich meine ohne ISDN-VLAN.
Wie seht ihr das Sicherheitsrisiko? Fällt mir irgendwie schwer zu bewerten auch konkte ein Szenario auszumalen, was überhaupt passieren könnte.. unabhängig davon, ob es missbraucht wird - es geht mir um dieTragweite. Aber laut dem Hinweis unten im X1, traue ich fast nix mehr..
Hintergrund: Es müssen sensible Daten bidirektional über eine ISDN-Verbindung ausgetauscht werden. Als Datenschutz wird zur Verschlüssenung der Daten eine in diesem Bereich anerkannte Verschlüsselungs-SW eingesetzt. Potentiell wird eine Gefahr gesehen, dass ein solcher Rechner als Relay missbraucht werden kann, sofern dieser auch im Firmeneigenen Netz steht. Und dass durch die bidirektionale Verbindung der Rechner kompromittiert und somit Zugang zum Firmenetz erreicht werden kann.
Aktuell ist dieses Problem so gelöst, dass dieser Rechner autark ist und die Daten (unverschlüsselt) an einem anderen Speicherort getragen werden. Nachteil: Daten sind auf USB-Stick unverschlüsselt, der Rechner ist so nicht Viren-Pattern-Update, Sicherung gibt es auch keine. Nun besteht der Anspruch, dass die sensiblen Daten unverschlüsselt gesichert via Netz auf bestimme Speicherorte übertragen werden kann. Dazu müsste dieser Rechner in das Firmennetz.
Ich über lege auch, ob es möglich ist, den im Firmen-Netz in ein VLAN zu stellen, die Kommunikation zuzulassen (dafür gibt es aktuell keine andere Wahl). Der Rechner wird im RZ weggesperrt, Zugriff auf diesen Rechner erfolgt via Terminal-Service X1. Die Daten von einem anderen Rechner abzuholen (oneway), dort werden sie auch nach aktuellem Firmenstd. nach Viren gescannt, von diesem Rechner werden die Daten von einer Unix-Maschine abgeholt (auch oneway).
Frage:
1. Unterstützung zur Risokoabschätzung und mögl. Absicherung
2. wäre meine Überlegung diesen Rechner in ein VLAN zu stellen usw. realistisch und umsetzbar. Z.B. auch durch GPOs, darin kenne ich mich leider nicht aus.
Danke,
Gruß Tanja
X1: Der Rechner soll deshalb ins RZ, weil wir nicht die 100% Kontrolle über diesen Rechner haebn. Er hat eine Onboad-NW-Karte und so wir unsere NW-Infrastruktur aufgebaut ist, war es möglich, diesen Rechner ins Firmennetz zu hängen, was auch ohne Erlaubnis passiert ist.. Auf und weg. dieser Aktion muss nur eine andere Lösung gefunden werden.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 54754
Url: https://administrator.de/contentid/54754
Ausgedruckt am: 23.11.2024 um 14:11 Uhr
3 Kommentare
Neuester Kommentar
Wie wird denn über ISDN kommuniziert?
Ist das für das OS eine TCP/IP Verbindung oder benutzen 2 spezialisierte Programme die ISDN Leitung wie eine serielle Leitung?
Im 2. Fall gibts praktisch keine Gefahr, da man nicht direkt ans OS rankommt. Es könnte natürlich Buffer Overflow Attacken geben, aber das ist so speziell, daß die normalen Malware Szenarien ausgeschlossen werden können.
Wenn es fürs OS eine TCP/IP Leitung darstellt, gelten dieselben Sicherheitsmaßnahmen wie für jede Netzwerkverbindung, also Firewall, nur benötigte Ports öffnen, etc., wobei: Vermutlich darf ja nicht jedes ISDN Modem anrufen und eine Verbindung aufbauen (oder doch?), also kommt es darauf an, wie sicher die absendenden Systeme sind (die ja auch schon die sensiblen Daten haben), weil man über die zu Euch kommen könnte.
Ist das für das OS eine TCP/IP Verbindung oder benutzen 2 spezialisierte Programme die ISDN Leitung wie eine serielle Leitung?
Im 2. Fall gibts praktisch keine Gefahr, da man nicht direkt ans OS rankommt. Es könnte natürlich Buffer Overflow Attacken geben, aber das ist so speziell, daß die normalen Malware Szenarien ausgeschlossen werden können.
Wenn es fürs OS eine TCP/IP Leitung darstellt, gelten dieselben Sicherheitsmaßnahmen wie für jede Netzwerkverbindung, also Firewall, nur benötigte Ports öffnen, etc., wobei: Vermutlich darf ja nicht jedes ISDN Modem anrufen und eine Verbindung aufbauen (oder doch?), also kommt es darauf an, wie sicher die absendenden Systeme sind (die ja auch schon die sensiblen Daten haben), weil man über die zu Euch kommen könnte.
hm.. wie jetzt technisch genau die ISDN-Verbindung aussieht, sprich, ob die Leitung seriell genutzt wird, weiss ich auch nicht so genau.
Ich ackere gerade das Handbuch durch, zu ISDN steht soviel, dass es zwei Karten gibt (aktiv und passiv) und dass man CAPI-Treiber installieren muss.
Bin so weit um zu wissen, dass die Software automatisch eine ISDN-Verbindung aufbauen kann, sobalt bestimmte Daten in einem JobIn-Verzeichnis liegen. Die Verifizierung der Daten findet anhand der Datei-Endungen statt. Die Sicherheits-FKT sind: elektonische Unterschrift, Übertrtagung verschlüsselt, Komprimierung und Zertifizierung der Schlüssel über def. Trustcenter. Diese Sicherheits-FKT sind an-/abschaltbar.
Wie die ISDN-Verbinung jetzt aussehen müsste, entzieht sich meiner Kenntnis über ISDN-Verbindungen überhaupt.. :? Kann man irgendwie darauf schliessen? Gibt es da Voraussetzungen, an denen ich das so erkennen könnte?
Habe bereits techn. Anfragen die nicht im Handbuch oder FAQ ersichtlich sind an den SW-Hersteller gestellt, bisher keine Antwort.. (telefonisch konnte mir der Techniker gerade mal gar nix sagen.. und hat mich auf mail verwiesen)
Danke,
Gruß T.
Ich ackere gerade das Handbuch durch, zu ISDN steht soviel, dass es zwei Karten gibt (aktiv und passiv) und dass man CAPI-Treiber installieren muss.
Bin so weit um zu wissen, dass die Software automatisch eine ISDN-Verbindung aufbauen kann, sobalt bestimmte Daten in einem JobIn-Verzeichnis liegen. Die Verifizierung der Daten findet anhand der Datei-Endungen statt. Die Sicherheits-FKT sind: elektonische Unterschrift, Übertrtagung verschlüsselt, Komprimierung und Zertifizierung der Schlüssel über def. Trustcenter. Diese Sicherheits-FKT sind an-/abschaltbar.
Wie die ISDN-Verbinung jetzt aussehen müsste, entzieht sich meiner Kenntnis über ISDN-Verbindungen überhaupt.. :? Kann man irgendwie darauf schliessen? Gibt es da Voraussetzungen, an denen ich das so erkennen könnte?
Habe bereits techn. Anfragen die nicht im Handbuch oder FAQ ersichtlich sind an den SW-Hersteller gestellt, bisher keine Antwort.. (telefonisch konnte mir der Techniker gerade mal gar nix sagen.. und hat mich auf mail verwiesen)
Danke,
Gruß T.
CAPI klingt schon mal nach serieller Übertragung.
Da dort dann wirklich nur Daten übertragen werden und kein Zugriff auf Protokolle wie RPC, SMB oder so möglich ist, wäre nur noch die Möglichkeit über sowas wie einen Buffer Overflow die Empfangs oder Sendesoftware zu hacken. Dürfte aber recht schwierig werden.
Ich würde diese Konfiguration schon als sicher ansehen.
VLAN sollte funktionieren, sehe eigentlich keinen Grund warum nicht. Wenn man dann die Grenze zwischen VLAN und internes Netz nur die benötigten Ports offenlässt und z.B. SSH zum Dateitransfer benutzt statt Standard SMB Protokoll, dann dürfte nicht mehr viel passieren können.
Da dort dann wirklich nur Daten übertragen werden und kein Zugriff auf Protokolle wie RPC, SMB oder so möglich ist, wäre nur noch die Möglichkeit über sowas wie einen Buffer Overflow die Empfangs oder Sendesoftware zu hacken. Dürfte aber recht schwierig werden.
Ich würde diese Konfiguration schon als sicher ansehen.
VLAN sollte funktionieren, sehe eigentlich keinen Grund warum nicht. Wenn man dann die Grenze zwischen VLAN und internes Netz nur die benötigten Ports offenlässt und z.B. SSH zum Dateitransfer benutzt statt Standard SMB Protokoll, dann dürfte nicht mehr viel passieren können.
