usercrash
Goto Top

Win2008R2 mit zwei NIC, wie Zugriff auf den Server an einer NIC blockieren

Guten Abend,

ein Win2008R2-Server arbeitet mit zwei aktivierten Netzwerkkarten:
192.168.1.100 für das interne Lan
192.168.2.100 für den VPN-Zugriff auf ein entferntes Lan

Wie kann ich (idealerweise mit Bordmitteln und ohne zusätzliche Hardwarefirewall) einen Zugriff durch Rechner aus dem entfernten Lan 192.168.2.x über die Servernetzwerkkarte 192.168.2.100 auf den Server blockieren (Netbios, RDP, Freigaben usw.)? Nur vom Server initiierter Verkehr (und dessen Antworten) sollen passieren dürfen.

Danke + Gruß, UC

Content-ID: 426816

Url: https://administrator.de/contentid/426816

Ausgedruckt am: 21.11.2024 um 23:11 Uhr

Lochkartenstanzer
Lochkartenstanzer 09.03.2019 um 21:31:09 Uhr
Goto Top
Zitat von @usercrash:

Wie kann ich (idealerweise mit Bordmitteln und ohne zusätzliche Hardwarefirewall) einen Zugriff durch Rechner aus dem entfernten Lan 192.168.2.x über die Servernetzwerkkarte 192.168.2.100 auf den Server blockieren (Netbios, RDP, Freigaben usw.)? Nur vom Server initiierter Verkehr (und dessen Antworten) sollen passieren dürfen.

Stell's in der Windows-Firewall ein.

lks
aqui
aqui 10.03.2019 aktualisiert um 11:01:51 Uhr
Goto Top
einen Zugriff durch Rechner aus dem entfernten Lan 192.168.2.x über die Servernetzwerkkarte 192.168.2.100 auf den Server blockieren
Eigentlich eine sehr peinliche Frage für ein Administrator Forum. Aber egal auch das können wir hier...
Scheinbar scheint dir entgangen zu sein das jeder Winblows Rechner auch eine interne Firewall hat.
Suchfeld klicken und "Firewall mit erweiterter Sicherheit" eingeben. Da werden sie geholfen !
https://www.admin-magazin.de/Das-Heft/2012/06/Die-erweiterte-Sicherheit- ...

RDP Port = TCP 3389, NetBioS = Ports TCP 137, 138 und 445 mit 2 Mausklicks blocken und fertig ist der Lack !
Aufwand: Max. 10 Minuten und da sind die 5 vom Tippen des Threads schon abgezogen. face-wink
usercrash
usercrash 10.03.2019 aktualisiert um 11:38:57 Uhr
Goto Top
Danke, mea culpa...
Die interne Windows Firewall wurde wohl ersetzt/deaktiviert durch Kaspersky Small Office Security KasSOS-5, welches eine eigene Firewall mitbringt.

Konkret geht es darum, dass aufgrund gesetzlicher Vorgaben im Lan eine Blackbox installiert werden soll (KVSafenet + Telematik), in deren Konfig man nicht 'reinsehen' kann. Theoretisch ist ein ungeregelter Zugriff von außen über diese Blackbox auf das hiesige Lan möglich.

Deshalb sollen ausgehende Safenet/TI-Verbindungen vom Server über die separate NIC 192.168.2.100 via VPN-Zugriff auf ein entferntes Lan (=Safenet/TI) möglich sein, Zugriff aus diesem entfernten Lan auf den Server 192.168.1.100 + 192.168.2.100 und auf das hiesige Lan 192.168.1.x müssen unterbunden werden.

Also:
Server/192.168.2.100 > VPN-Blackbox/192.168.2.2 >VPN> KVSafenet/Telematik wird erlaubt.
KVSafenet/Telematik > VPN> VPN-Blackbox/192.168.2.2 > Server/192.168.2.100+192.168.1.100 wird geblockt.

Der Server muss allerdings noch mit Safenet/TI kommunizieren können, die entsprechenden IP-Bereiche werde per route auf dem Server eingetragen.

Reicht dann auf dem Server mit den zwei NICs eine solche Regel? Alle IP-Bereiche von Safenet/TI kennt selbst der PVS-Einrichter nicht ...
screen-2019-03-10_11-30-13
ti-ports-ips1

Infos zur KasSOS-Firewall
aqui
aqui 10.03.2019 um 11:38:47 Uhr
Goto Top
Sinnvoll ist das generell nicht das am Endgerät zu machen. Du solltest besser beide Netze mit einem kleinen Firewall Router oder eine kleinen_Firewall.
Dann hast du einen zentralen Punkt in der Netzwerk Infrastruktur wo du diese Regeln setzt und nicht eine Frickelei an einem Endgerät.
siehe auch hier:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router

Gerade zum Thema KVSafenet + Telematik gibt es hier im Forum diverse Threads die genau dieses leidige Thema beleuchten.
usercrash
usercrash 10.03.2019 aktualisiert um 19:21:54 Uhr
Goto Top
Danke, die anderen Beiträge hatte ich schon durchsucht und dort auch erfolglos angefragt. Das hiesige Szenario wird dort so nicht behandelt, wäre aber nicht nur für uns ein praktikabler Ansatz ohne erneuten Kostenfaktor, um der Datensammelwut der kranken Kassen, der Ti oder wem auch immer etwas Einhalt zu gebieten.

Problem: Das Praxisverwaltungssystem auf dem Server braucht Zugriff auf WWW und Telematik. Das Telematik-VPN 'überspringt' via VPN-Tunnel unsere Firewall, der TI-VPN-Tunnel endet in der Standardinstallation (z.B. wegen der Chipkartenleser) im internen Lan. Man muss sich dann auf die Zusage verlassen, dass ein Zugriff TI > Lan nicht möglich sei, bekommt dies aber trotz Anfragen beim Anbieter oder der KV nicht schriftlich...

Deshalb die Idee, diesen TI-Verkehr auf eine zweite NIC auszulagern und dort zumindestens eingehend zu regeln. Eine 'Firewall-Kaskade' möchte ich aus wartungstechnischen Gründen nicht aufbauen, hier laufen jetzt schon Kabelmodem > Firewall > Switches > TI-Blackbox .
aqui
aqui 11.03.2019 um 00:56:46 Uhr
Goto Top
Das Praxisverwaltungssystem auf dem Server braucht Zugriff auf WWW und Telematik
Genau deshalb ja eine Firewall oder einen Firewall Router der das mit Netzinfrastruktur elegant löst wie es allgemein üblich ist und eben nicht mit Frickelei an irgendwelchen Endgeräten im Netz !
Man muss sich dann auf die Zusage verlassen
Dann eben nicht, sondern du hast Gewissheit da das sicher ist, da DU die Kontrolle darüber hast eben mit einer Firewall in DEINER Hoheit. Genau so sind beide Netze sauber getrennt !
bekommt dies aber trotz Anfragen beim Anbieter oder der KV nicht schriftlich...
Da möchte man dann besser lieber NICHT Patient sein !
Dann nimmst du einen Firewall Router oder du regelst das mit deinem vorhandenen Switch. In der Hoffnung das das kein billiger Dummswitch ist sondern ein Layer 3 (Roting) Switch der auch Access Listen supportet.
So erledigst du alles in einem Gerät.
Und außerdem...wenn du schon eine Fiurewall hast umso besser. Warum realisierst du dann dieses LAN nicht direkt dort ?!
Klingt alles etwas wirr was du da als "Begründung" nennst ?! Normal hat man Kabelemodem eine Firewall die beide Netzwerk Segmente (VLANs) bedient und das wars... Siehe auch hier:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
usercrash
usercrash 12.03.2019 aktualisiert um 13:28:34 Uhr
Goto Top
Hallo,
dann versuche ich mein Problem mal anders zu erklären:

Das Kabelmodem stellt für die Firewall eine fixe externe IP zur Verfügung, nur ein Anschluss zur Firewall.
Die Firewall setzt diese via NAT auf das interne Lan um und filtert gleichzeitig Ein-und Ausgang.
Damit ist derzeit alles kontrolliert, was rein- und rausgeht.

Hinter der Firewall sind das interne Lan und zukünftig auch die TI-Blackbox/Konnektor angeschlossen.
Der Verkehr Extern > TI-Blackbox läuft in einem VPN-Tunnel, den die Firewall ja nur unverändert/ ungefiltert durchleitet.
Die TI-Blackbox muss dann mit dem Server im internen Lan 'sprechen' können, die Standardinstallation des PVS-Anbieters sieht dafür dann eine IP aus dem schon vorhandenen internen Lan auch für die TI-Blackbox (und Chipkartenleser etc.) vor.
Das bedeutet aber, dass jemand mit Zugriff auf das TI-VPN und die TI-Blackbox mitten im internen Lan steht, und dass will ich nicht, da keine Garantien, s.o..

Deshalb möchte ich die Verbindung TI-Blackbox <> Server über eine separate Server-NIC in einem anderen Netzsegment realisieren und diesen Verkehr am Server einschränken.
Eine weitere Hardware-Firewall zwischen TI-Blackbox und Server wäre zwar denkbar, würde neben dem Kostenfaktor aber noch ein weiteres zu wartendes Gerät, weiteren Stromverbrauch usw. nur für diese TI-Verbindung bedeuten.
Hoffentlich wird es jetzt klarer.

Und damit zurück zur Eingangsfrage:
Was konkret muss ich (per Software-Firewall) eingehend blocken, damit der Server auf der TI-NIC keinen Zugriff auf seine Daten oder das über die zweite NIC angeschlossene Lan gewährt?

Danke + Gruß, UC
Lochkartenstanzer
Lochkartenstanzer 12.03.2019 um 13:35:50 Uhr
Goto Top
Zitat von @usercrash:

Eine weitere Hardware-Firewall zwischen TI-Blackbox und Server wäre zwar denkbar, würde neben dem Kostenfaktor aber noch ein weiteres zu wartendes Gerät, weiteren Stromverbrauch usw. nur für diese TI-Verbindung bedeuten.
Hoffentlich wird es jetzt klarer.

Du brsuchst keine weitere Firewall, sondern kannst die virhandene dafür Nutzen. Pack die Box einfach in die DMZ und reguliere mit der vorhandenen Firewall den Zugriff ins LAN.

lks
aqui
aqui 12.03.2019 aktualisiert um 13:51:16 Uhr
Goto Top
Hinter der Firewall sind das interne Lan und zukünftig auch die TI-Blackbox/Konnektor angeschlossen.
Das ist genau der Punkt den der Kollege LKS meint und der dir oben auch schon genannt wurde !
HIER definierst du einfach ein 2tes Segment für die TI-Blackbox statt am Server.
Die gravierende Gefahr ist das du dann das TI-Blackbox Segment direkt am Server mit den Patientendaten hast ein NoGo und gefährlich wenn da was passiert.
Außerdem hast du so das TI-Blackbox Netz mit dem Praxis Netz sauber getrennt so das deren Daten nie im Praxis LAN auftauchen aber dennoch voll erreichbar sind.
Dein Grunddesign Ansatz ist also schon falsch, denn solche Netztrennung gehört nie an einen Server sondern sollte logischerweise immer von der Netzwerk Infrastruktur gemacht werden.
So sähe ein sinnvolles Design für das Netz dann aus:

fw

"Firma 2" wäre dann analog dein Segment mit der TI-Blackbox/Konnektor.
Sollte deine vorhandene Firewall nur einen einzigen physischen LAN Adapter haben dann löst du das schnell und bequem mit einm VLAN wie HIER beschrieben !
usercrash
usercrash 12.03.2019 aktualisiert um 17:45:41 Uhr
Goto Top
Zitat von @aqui:
HIER definierst du einfach ein 2tes Segment für die TI-Blackbox statt am Server.
Die gravierende Gefahr ist das du dann das TI-Blackbox Segment direkt am Server mit den Patientendaten hast ein NoGo und gefährlich wenn da was passiert.
Außerdem hast du so das TI-Blackbox Netz mit dem Praxis Netz sauber getrennt so das deren Daten nie im Praxis LAN auftauchen aber dennoch voll erreichbar sind.

Hallo,
habe mal nachgelesen:
Das als Firewall genutzte Gerät Draytek Vigor 2760 unterstützt VLAN und hängt via Ethernet mit fixer WAN-IP an einem Hitron-Kabelmodem:
PDF: Vigor-2760-Manual ab Seite 140, VLAN-Tag-Insertion Seite 39.

Dann könnte man dort aufspalten in:
VLAN1 = 192.168.1.x internes Lan mit Server + Clients
und
VLAN2 = 192.168.2.x mit der TI-Blackbox/Konnektor + den Chipkartenlesegeräten

Mein Verständnisproblem:
Der WAN-Port der TI-Blackbox hängt dann an VLAN2 (z.B. als 192.168.2.2) und decodiert das TI-VPN. Am Lan-Port der TI-Blackbox hängt dann ein Chipkartenleser.
Wie aber können Server/Clients aus dem VLAN1 mit VLAN2, also der TI-Blackbox und den Chipkartenlesern wechselseitig kommunizieren, also Chipkarten auslesen oder mit Servern der TI über das TI-VPN kommunizieren?

PDF: Daten zum T-Systems-TI-Konnektor, Einbindung ab Seite 32:

Erneut Danke + Gruß, UC
138810
138810 12.03.2019 aktualisiert um 18:08:38 Uhr
Goto Top
Zitat von @usercrash:
Wie aber können Server/Clients aus dem VLAN1 mit VLAN2, also der TI-Blackbox und den Chipkartenlesern wechselseitig kommunizieren, also Chipkarten auslesen oder mit Servern der TI über das TI-VPN kommunizieren?
Ganz einfach, indem man auf der Router Firewall eine Regel erstellt die Traffic von VLAN1 ins VLAN2 zulässt aber eben nicht anders herum. Das SPI System (das heutzutage jede vernünftige Firewall besitzt), stellt mit seiner Session-State-Table sicher das nur der zugehöriger Traffic der Verbindung aus VLAN1 ins VLAN2 auch wieder zurückfließen kann. Dagegen wird von VLAN2 aus initiierter Traffic mit einer Regel komplett geblockt.

Btw. steht übrigens auch folgendes im Handbuch (aber wer vertraut dem rosa Riesen schon face-wink)
Die grundlegende Sicherheitsregel (policy) der T-Systems Konnektor-Firewall besteht da-rin, dass sämtlicher Datenverkehr, der nicht vom Konnektor initiiert wurde oder nicht an Dienste des Netz- und Anwendungskonnektors gerichtet ist, blockiert wird. Ein aktiver Zu-griff auf Ihr Netzwerk über den T-Systems Konnektor ist nicht möglich. Zudem filtert die integrierte Firewall den Datenverkehr dahingehend, dass ausschließlich zulässige Protokol-le und Fachdienste Zugriff auf die jeweiligen Netze erlangen.