Bring your own Device Homeoffice - Sicherheit?
Hallo zusammen,
wie macht ihr das, wenn Mitarbeiter im Homeoffice mit dem eigenen PC eine VPN Verbindung herstellen wollen?
Ich habe es aktuell über die SonicWall so geregelt, dass nur RDP 3389 auf das Netzwerk sowie DNS 53 auf die beiden DCs möglich ist.
Die Mitarbeiter können jetzt auf den Terminalserver und auf ihre privaten PCs mit RDP zugreifen.
Der Terminalserver ist so eingestellt, dass nur Drucker durchgeleitet werden --> Besteht hier Gefahr z.B. wegen des PrintNightmare Bugs? (oder auch andere Gefahren?)
Dateien können nicht kopiert werden.
Bei den Clients ist das aber anders. Hier kann man standardmäßig auch Dateien kopieren.
Ich stell mir gerade die Frage, welche Gefahr für die Firma entsteht, wenn ein Mitarbeiter mit einem verseuchten Rechner über RDP auf einen Computer in der Firma zugreift.
Wir haben ja auf die privaten Rechner überhaupt keinen Einblick.
Wie macht ihr das, was ist hier der Richtige weg?
Danke!
Grüße
Leon
wie macht ihr das, wenn Mitarbeiter im Homeoffice mit dem eigenen PC eine VPN Verbindung herstellen wollen?
Ich habe es aktuell über die SonicWall so geregelt, dass nur RDP 3389 auf das Netzwerk sowie DNS 53 auf die beiden DCs möglich ist.
Die Mitarbeiter können jetzt auf den Terminalserver und auf ihre privaten PCs mit RDP zugreifen.
Der Terminalserver ist so eingestellt, dass nur Drucker durchgeleitet werden --> Besteht hier Gefahr z.B. wegen des PrintNightmare Bugs? (oder auch andere Gefahren?)
Dateien können nicht kopiert werden.
Bei den Clients ist das aber anders. Hier kann man standardmäßig auch Dateien kopieren.
Ich stell mir gerade die Frage, welche Gefahr für die Firma entsteht, wenn ein Mitarbeiter mit einem verseuchten Rechner über RDP auf einen Computer in der Firma zugreift.
Wir haben ja auf die privaten Rechner überhaupt keinen Einblick.
Wie macht ihr das, was ist hier der Richtige weg?
Danke!
Grüße
Leon
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 980189645
Url: https://administrator.de/forum/bring-your-own-device-homeoffice-sicherheit-980189645.html
Ausgedruckt am: 25.12.2024 um 15:12 Uhr
23 Kommentare
Neuester Kommentar
Ehm, also die Homeoffice Pflicht wurde mittlerweile schon wieder gekippt.
Ist die Fragestellung nicht bisschen spät?!
Man könnte Firewall technisch noch einstellen das der User nur RDP zu Terminal Servern und DCs aufbauen darf. Also nicht das ganze Subnetz.
Das Ding mit privaten Geräten im Unternehmens Netzwerk ist halt kritisch, aber ich kann es verstehen das man zB. nicht für x Mitarbeiter Notebooks beschaffen kann.
Ich finde man sollte das mit der GF klären wie sie das im Unternehmen wollen und sie auf die Gefahren deutlich hinweisen.
Ist die Fragestellung nicht bisschen spät?!
Man könnte Firewall technisch noch einstellen das der User nur RDP zu Terminal Servern und DCs aufbauen darf. Also nicht das ganze Subnetz.
Das Ding mit privaten Geräten im Unternehmens Netzwerk ist halt kritisch, aber ich kann es verstehen das man zB. nicht für x Mitarbeiter Notebooks beschaffen kann.
Ich finde man sollte das mit der GF klären wie sie das im Unternehmen wollen und sie auf die Gefahren deutlich hinweisen.
Hi
ein paar weitere Punkte:
Ich würde es grundsätzlich nicht erlauben, das jemand sein privates Endgerät mit der Firma verbindet, sehe das eher als Armutszeugnis des Unternehmen wenn die kein passendes Equipment bereitstellen können, es müssen ja keine HighEnd Geräte sein die man den Kolleginnen und Kollegen für das HO bereitstellt, wenn eh alles über RDP läuft.
Meine Klarte Emfehlung: lasst es sein mit privaten Endgeräten, das macht nur mehr Ärger und verkompliziert die Lage.
Just my 2 Cent
@clSchak
ein paar weitere Punkte:
- wenn der Client kompromittiert wurde, sind die Zugangsdaten ggf. auch als nicht mehr vertrauenswürdig - sofern du überhaupt mitbekommst wenn der PC des MA ein Problem hat
- Compliance Einstellungen & Richtlinien sind nur sehr schwer bzw. gar nicht anwendbar
- DSGVO Konform ist das ggf. auch nicht, da vom lokalen System die Zwischenablage ausgelesen werden kann
- Dateiabfluss ist nur mit sehr viel Aufwand zu unterbinden, alleine schon wegen der geteilten Zwischenablage
- DSGVO Konform wird auch das ausdrucken von ggf. sensiblen Daten im HO nicht sein
Ich würde es grundsätzlich nicht erlauben, das jemand sein privates Endgerät mit der Firma verbindet, sehe das eher als Armutszeugnis des Unternehmen wenn die kein passendes Equipment bereitstellen können, es müssen ja keine HighEnd Geräte sein die man den Kolleginnen und Kollegen für das HO bereitstellt, wenn eh alles über RDP läuft.
Meine Klarte Emfehlung: lasst es sein mit privaten Endgeräten, das macht nur mehr Ärger und verkompliziert die Lage.
Just my 2 Cent
@clSchak
Moin,
Gilt aber nur für die obige Konstellation.
Betreibt man etwas mehr (Software + Kosten)-Aufwand, ist das durchaus umsetzbar.
Wir haben z.B. eine komplette Citrix-Infrastruktur.
Alles, was von außen kommt, darf sich per 2FA über eine PreAuth-Appliance, an den Terminalservern anmelden, aber nichts durchreichen. Nicht mal eine Zwischenblage funktioniert hier.
Der (private) PC ist somit nur ein Ein-/ Ausgabegerät. Gut, wenn dort Keylogger mitlaufen -> am Ar#ch. Aber das Problem kann auch bei bekannten Geräten entstehen (kann !=muss).
Gruß
em-pie
Gilt aber nur für die obige Konstellation.
Betreibt man etwas mehr (Software + Kosten)-Aufwand, ist das durchaus umsetzbar.
Wir haben z.B. eine komplette Citrix-Infrastruktur.
Alles, was von außen kommt, darf sich per 2FA über eine PreAuth-Appliance, an den Terminalservern anmelden, aber nichts durchreichen. Nicht mal eine Zwischenblage funktioniert hier.
Der (private) PC ist somit nur ein Ein-/ Ausgabegerät. Gut, wenn dort Keylogger mitlaufen -> am Ar#ch. Aber das Problem kann auch bei bekannten Geräten entstehen (kann !=muss).
Gruß
em-pie
Ist doch eigentlich nichts anderes, als wenn der sich mit seinem privaten Laptop bei Dir in der Firma anstöselt - ohne "Gast-Wifi" und vlan-Trennung
Da will man das ja üblicherweise auch nicht. Und wenn ich mir so überlege, was für verseuchte PCs mir schon im privaten Umfeld untergekommen sind ...
Da ist doch nen gebrauchter Lenovo (esm) für 300 EUR eigentlich nen Klacks. Den kannste dann zudengeln wie Du möchtest und hast vor allem "Privatdaten" von Firmendaten zuverlässig getrennt.
Da will man das ja üblicherweise auch nicht. Und wenn ich mir so überlege, was für verseuchte PCs mir schon im privaten Umfeld untergekommen sind ...
Da ist doch nen gebrauchter Lenovo (esm) für 300 EUR eigentlich nen Klacks. Den kannste dann zudengeln wie Du möchtest und hast vor allem "Privatdaten" von Firmendaten zuverlässig getrennt.
Ohje,
Daher gehe ich jetzt das Thema an um Sicherheit in das System zu bekommen.
Liebe spät, als nie.
Manche User gehen über RDP auf ihre Rechner die über DHCP angebunden sind. Daher ist das ganze Netz für RDP freigegeben.
DNS NUR auf die DCs.
Ohje, schon Mal beim BSI in das Thema Grundschutz reingeschaut?
Zwar schon etwas älter, aber immer noch ein guter Einstieg.
https://shop.heinemann-verlag.de/sonderhefte/189/it-administrator-sonder ...
Zitat von @leon123:
Ja wir haben das eben so gemacht wegen der Pflicht und wollten das Thema überdenken sobald es "ruhiger" wird. Laptops waren zwischenzeitlich sehr schwer zu bekommen.
Und wenn ein Mitarbeiter, lauter Viren, Trojaner und andere lustige Software auf seinem Rechner hat? Wie ruhig ist dann euer Leben?Ja wir haben das eben so gemacht wegen der Pflicht und wollten das Thema überdenken sobald es "ruhiger" wird. Laptops waren zwischenzeitlich sehr schwer zu bekommen.
Daher gehe ich jetzt das Thema an um Sicherheit in das System zu bekommen.
Manche User gehen über RDP auf ihre Rechner die über DHCP angebunden sind. Daher ist das ganze Netz für RDP freigegeben.
DNS NUR auf die DCs.
Die Mitarbeiter arbeiten halt immer noch lieber auf ihrem eigenen Rechner. Die Performance ist auf einem aktuellem i5 einfach etwas besser als auf dem Terminalserver. Dazu sind Office Lizenzen für den Terminalserver sehr teuer, das bremst den Ausbau hier ein wenig bei der GF.
Irgendwas ist immer. Aber dafür gibt es ja die Risikobewertung.Ich stell mir eben die Frage, welche Gefahr besteht bei RDP ohne Dateiverkehr (nur Drucker) und welche Gefahr besteht bei den Rechnern. Bei den Rechnern müsste man ja den Dateiverkehr über RDP auch über GPOs steuern können, damit wäre die Gefahr gleich wie bei den Terminalserver.
Betrachte bitte deine Infrastruktur im vollem Umfang.Zwar schon etwas älter, aber immer noch ein guter Einstieg.
https://shop.heinemann-verlag.de/sonderhefte/189/it-administrator-sonder ...
Hallo
Dann bekommt er einen Firmenlaptop, der für so etwas konfiguriert ist. Alles andere ist meiner Meinung nach einfach zu unsicher und unkontrollierbar für dich. Unsere Laptops sind entsprechend so konfiguriert, dass sie für den Anwender RDP und VPN erlauben. Damit kann er dann via VPN eine RDP Verbindung zu seinem Arbeitsplatzrechner aufbauen. Mehr nicht. Reicht fürs arbeiten. Sämtlicher Datenaustausch (auch oder grade Drucken) ist unterbunden. Wieso sollen dienstliche Dokumente auf einem privaten Drucker ausgedruckt werden? Das hat da nichts zu suchen.
Gruß
Doskias
Zitat von @leon123:
Hallo zusammen,
wie macht ihr das, wenn Mitarbeiter im Homeoffice mit dem eigenen PC eine VPN Verbindung herstellen wollen?
Hallo zusammen,
wie macht ihr das, wenn Mitarbeiter im Homeoffice mit dem eigenen PC eine VPN Verbindung herstellen wollen?
Dann bekommt er einen Firmenlaptop, der für so etwas konfiguriert ist. Alles andere ist meiner Meinung nach einfach zu unsicher und unkontrollierbar für dich. Unsere Laptops sind entsprechend so konfiguriert, dass sie für den Anwender RDP und VPN erlauben. Damit kann er dann via VPN eine RDP Verbindung zu seinem Arbeitsplatzrechner aufbauen. Mehr nicht. Reicht fürs arbeiten. Sämtlicher Datenaustausch (auch oder grade Drucken) ist unterbunden. Wieso sollen dienstliche Dokumente auf einem privaten Drucker ausgedruckt werden? Das hat da nichts zu suchen.
Ich stell mir gerade die Frage, welche Gefahr für die Firma entsteht, wenn ein Mitarbeiter mit einem verseuchten Rechner über RDP auf einen Computer in der Firma zugreift.
Keine neuen, nur die bekannten, die entstehen wenn der gleiche Computer per LAN bei euch angeschlossen würde. Würdest du deinem Anwender erlauben seinen PC bei euch ins Netzwerk zu hängen? Wieso dann per VPN?Wir haben ja auf die privaten Rechner überhaupt keinen Einblick.
Deswegen haben Sie im Firmennetzwerk nichts verloren.Gruß
Doskias
Moin,
Das hast du nicht wirklich... Lovely Monday, das reicht schon wieder für den Rest vom Monat...
wie macht ihr das, wenn Mitarbeiter im Homeoffice mit dem eigenen PC eine VPN Verbindung herstellen wollen?
Ich habe es aktuell über die SonicWall so geregelt, dass nur RDP 3389 auf das Netzwerk sowie DNS 53 auf die beiden DCs möglich ist.
Ich habe es aktuell über die SonicWall so geregelt, dass nur RDP 3389 auf das Netzwerk sowie DNS 53 auf die beiden DCs möglich ist.
Das hast du nicht wirklich... Lovely Monday, das reicht schon wieder für den Rest vom Monat...
Sers,
privater Rechner oder Laptop ist überhaupt kein Problem. Der Mitarbeiter arbeitet dann allerdings *ausschließlich* über RDSH/Citrix, ohne Austausch von Daten zwischen dem Privatgerät und der Remoteverbindung.
Effektiv werden dann keine Firmendaten auf dem Privatgerät gespeichert oder verarbeitet. Passt.
Anbindung der Privategeräte erfolgt über ein als "unsicher" behandeltes Netz, vergleichbar mit einem Gästenetz für zwielichtige Gäste.
Und nein, wir öffnen dazu selbstverständlich *nicht* den 3389 nackt ins Netz. Warum nicht? Nicht etwa wegen irgendwelchen Best Practices, sondern weil bei solch grobem Unfug die Cyberversicherung beim Befall nicht zahlt.
Grüße,
Philip
privater Rechner oder Laptop ist überhaupt kein Problem. Der Mitarbeiter arbeitet dann allerdings *ausschließlich* über RDSH/Citrix, ohne Austausch von Daten zwischen dem Privatgerät und der Remoteverbindung.
Effektiv werden dann keine Firmendaten auf dem Privatgerät gespeichert oder verarbeitet. Passt.
Anbindung der Privategeräte erfolgt über ein als "unsicher" behandeltes Netz, vergleichbar mit einem Gästenetz für zwielichtige Gäste.
Und nein, wir öffnen dazu selbstverständlich *nicht* den 3389 nackt ins Netz. Warum nicht? Nicht etwa wegen irgendwelchen Best Practices, sondern weil bei solch grobem Unfug die Cyberversicherung beim Befall nicht zahlt.
Grüße,
Philip
Zitat von @aqui:
Gar kein VPN nutzen sondern RDP rein nur per HTTPS im Web Browser machen. So gibts dann erst gar keine Netzwerk Verbindung ins Firmennetz.
Gar kein VPN nutzen sondern RDP rein nur per HTTPS im Web Browser machen. So gibts dann erst gar keine Netzwerk Verbindung ins Firmennetz.
Dito. RDS Gateway oder passendes Citrix Pendant einrichten, optimalerweise noch mit Zertifikat auf dem Clientsystem als 2tem Faktor und gut die Sache läuft.
Beim RDS Gateway nicht vergessen UDP zu aktivieren und es läuft geschmeidig.
Moin...
Ich habe es aktuell über die SonicWall so geregelt, dass nur RDP 3389 auf das Netzwerk sowie DNS 53 auf die beiden DCs möglich ist.
du hast was gemacht... ist jetzt nicht dein ernst oder?
wiso nutzt ihr kein VPN?
Die Mitarbeiter können jetzt auf den Terminalserver und auf ihre privaten PCs mit RDP zugreifen.
ja klar.. aber bitte über VPN
Der Terminalserver ist so eingestellt, dass nur Drucker durchgeleitet werden --> Besteht hier Gefahr z.B. wegen des PrintNightmare Bugs? (oder auch andere Gefahren?)
jo... so wie du dns und RDP ins Netz gestellt hats, bist du die gefahr... dann kommen die anderen....
Wir haben ja auf die privaten Rechner überhaupt keinen Einblick.
vorher gedanken machen...
Wie macht ihr das, was ist hier der Richtige weg?
alles dicht machen, und zugänge über VPN einrichten....
denke mal in ruhe uber deine taten nach....
Danke!
Grüße
Leon
Frank
Zitat von @leon123:
Hallo zusammen,
wie macht ihr das, wenn Mitarbeiter im Homeoffice mit dem eigenen PC eine VPN Verbindung herstellen wollen?
Firmennotebook + VPN + RDPHallo zusammen,
wie macht ihr das, wenn Mitarbeiter im Homeoffice mit dem eigenen PC eine VPN Verbindung herstellen wollen?
Ich habe es aktuell über die SonicWall so geregelt, dass nur RDP 3389 auf das Netzwerk sowie DNS 53 auf die beiden DCs möglich ist.
wiso nutzt ihr kein VPN?
Die Mitarbeiter können jetzt auf den Terminalserver und auf ihre privaten PCs mit RDP zugreifen.
Der Terminalserver ist so eingestellt, dass nur Drucker durchgeleitet werden --> Besteht hier Gefahr z.B. wegen des PrintNightmare Bugs? (oder auch andere Gefahren?)
Dateien können nicht kopiert werden.
Bei den Clients ist das aber anders. Hier kann man standardmäßig auch Dateien kopieren.
Ich stell mir gerade die Frage, welche Gefahr für die Firma entsteht, wenn ein Mitarbeiter mit einem verseuchten Rechner über RDP auf einen Computer in der Firma zugreift.
ich selle mir die frage, was passiert wenn die auf einen verseuchten rdp server zugreifen.... Bei den Clients ist das aber anders. Hier kann man standardmäßig auch Dateien kopieren.
Ich stell mir gerade die Frage, welche Gefahr für die Firma entsteht, wenn ein Mitarbeiter mit einem verseuchten Rechner über RDP auf einen Computer in der Firma zugreift.
Wir haben ja auf die privaten Rechner überhaupt keinen Einblick.
Wie macht ihr das, was ist hier der Richtige weg?
denke mal in ruhe uber deine taten nach....
Danke!
Grüße
Leon
@Vision2015
wer sagt denn, dass er alles "nackt im Netz" stehen hat?
Ich las es so, dass er den VPN-Tunnel an der SonicWall dahingehend angepasst hat, dass aus dem VPN-Netz nur 3389 und 53 als Dienste/ Ports erlaubt sind.
Das wäre hier in sofern OK, als dass er die Quelle des Drecks, der eingeschleust werden könnte, zumindest eingeschränkt hat...
wer sagt denn, dass er alles "nackt im Netz" stehen hat?
Ich las es so, dass er den VPN-Tunnel an der SonicWall dahingehend angepasst hat, dass aus dem VPN-Netz nur 3389 und 53 als Dienste/ Ports erlaubt sind.
Das wäre hier in sofern OK, als dass er die Quelle des Drecks, der eingeschleust werden könnte, zumindest eingeschränkt hat...
Moin...
allerdings wäre in seinem fall wohl besser, wenn ein ordentliches RDS Gateway mit zertifikaten und allem pipapo bestehen würde..
Frank
Zitat von @em-pie:
@Vision2015
wer sagt denn, dass er alles "nackt im Netz" stehen hat?
Ich las es so, dass er den VPN-Tunnel an der SonicWall dahingehend angepasst hat, dass aus dem VPN-Netz nur 3389 und 53 als Dienste/ Ports erlaubt sind.
Das wäre hier in sofern OK, als dass er die Quelle des Drecks, der eingeschleust werden könnte, zumindest eingeschränkt hat...
nun ja... ich lese nix von VPN...@Vision2015
wer sagt denn, dass er alles "nackt im Netz" stehen hat?
Ich las es so, dass er den VPN-Tunnel an der SonicWall dahingehend angepasst hat, dass aus dem VPN-Netz nur 3389 und 53 als Dienste/ Ports erlaubt sind.
Das wäre hier in sofern OK, als dass er die Quelle des Drecks, der eingeschleust werden könnte, zumindest eingeschränkt hat...
Ich habe es aktuell über die SonicWall so geregelt, dass nur RDP 3389 auf das Netzwerk sowie DNS 53 auf die beiden DCs möglich ist.
wenn dort aber doch ein VPN sein sollte, so will ich mich natürlich entschuldigen!allerdings wäre in seinem fall wohl besser, wenn ein ordentliches RDS Gateway mit zertifikaten und allem pipapo bestehen würde..
Frank
Moin,
ich muss jetzt aber doch mal ganz blöd fragen:
Wie willst du denn ein RDS Gateway realisieren für seine beschriebene Umgebung? Du sagst auf der einen Seite, dass er nichts von VPN geschrieben hat und du daher davon ausgingst, dass kein VPN vorhanden ist. Ok, aber: Er hat auch nirgends etwas von Terminalserver geschrieben. Im Gegenteil:
Ich will jetzt gar nicht auf die Details eingehen, dass Office365 zum Beispiel auf dem TS oder Client gleich viel kostet, aber ein RDS-Gateway einzurichten, damit jeder User auf seinen eigenen Client kann? Wir machen das genau so, nämlich ohne RDS-Gateway, weil auch wir keinen Terminalserver haben. Und ich finde mit einem Anständigen VPN Server, der ebenfalls ein Zertifikat benötigt (welches man sich nur aus dem Firmen-Netzwerk herunterladen kann), dazu eine zwei-Faktor Authentifizierung via Domänen-Kennwort in Verbindung mit einer Token-App, halte ich für nicht unsicherer als ein RDS-Gateway. Natürlich gibt es bei der Lösung noch andere Dinge zu beachten. Wir haben die VPN-Verbindung der User zum Beispiel auch so eingeschränkt, dass lediglich RDP auf den Arbeitsrechner des Users funktioniert. Server sind via VPN gar nicht erreichbar und jeder User kann wirklich nur auf seinen eigenen Rechner zugreifen und sich auch nur dort anmelden. Ja das ganze ist deutlich mehr Aufwand als bei einem RDS-Gateway, aber wie gesagt: Es geht hier nicht um Verbindungen von extern auf einen TS sondern es geht um Verbindungen von extern auf die vor Ort stehenden Clients.
Gruß
Doskias
ich muss jetzt aber doch mal ganz blöd fragen:
Zitat von @Vision2015:
allerdings wäre in seinem fall wohl besser, wenn ein ordentliches RDS Gateway mit zertifikaten und allem pipapo bestehen würde..
allerdings wäre in seinem fall wohl besser, wenn ein ordentliches RDS Gateway mit zertifikaten und allem pipapo bestehen würde..
Wie willst du denn ein RDS Gateway realisieren für seine beschriebene Umgebung? Du sagst auf der einen Seite, dass er nichts von VPN geschrieben hat und du daher davon ausgingst, dass kein VPN vorhanden ist. Ok, aber: Er hat auch nirgends etwas von Terminalserver geschrieben. Im Gegenteil:
Zitat von @leon123:
Manche User gehen über RDP auf ihre Rechner die über DHCP angebunden sind. Daher ist das ganze Netz für RDP freigegeben. DNS NUR auf die DCs.
Die Mitarbeiter arbeiten halt immer noch lieber auf ihrem eigenen Rechner. Die Performance ist auf einem aktuellem i5 einfach etwas besser als auf dem Terminalserver. Dazu sind Office Lizenzen für den Terminalserver sehr teuer, das bremst den Ausbau hier ein wenig bei der GF.
Manche User gehen über RDP auf ihre Rechner die über DHCP angebunden sind. Daher ist das ganze Netz für RDP freigegeben. DNS NUR auf die DCs.
Die Mitarbeiter arbeiten halt immer noch lieber auf ihrem eigenen Rechner. Die Performance ist auf einem aktuellem i5 einfach etwas besser als auf dem Terminalserver. Dazu sind Office Lizenzen für den Terminalserver sehr teuer, das bremst den Ausbau hier ein wenig bei der GF.
Ich will jetzt gar nicht auf die Details eingehen, dass Office365 zum Beispiel auf dem TS oder Client gleich viel kostet, aber ein RDS-Gateway einzurichten, damit jeder User auf seinen eigenen Client kann? Wir machen das genau so, nämlich ohne RDS-Gateway, weil auch wir keinen Terminalserver haben. Und ich finde mit einem Anständigen VPN Server, der ebenfalls ein Zertifikat benötigt (welches man sich nur aus dem Firmen-Netzwerk herunterladen kann), dazu eine zwei-Faktor Authentifizierung via Domänen-Kennwort in Verbindung mit einer Token-App, halte ich für nicht unsicherer als ein RDS-Gateway. Natürlich gibt es bei der Lösung noch andere Dinge zu beachten. Wir haben die VPN-Verbindung der User zum Beispiel auch so eingeschränkt, dass lediglich RDP auf den Arbeitsrechner des Users funktioniert. Server sind via VPN gar nicht erreichbar und jeder User kann wirklich nur auf seinen eigenen Rechner zugreifen und sich auch nur dort anmelden. Ja das ganze ist deutlich mehr Aufwand als bei einem RDS-Gateway, aber wie gesagt: Es geht hier nicht um Verbindungen von extern auf einen TS sondern es geht um Verbindungen von extern auf die vor Ort stehenden Clients.
Gruß
Doskias
Sers,
Du kannst ein RDS Gateway auch ohne RDSH/VDI betreiben. Das Gateway dient ja nur als Mittelsmann zwischen dem RDP Server (offensichtlich eure Client Rechner im Büro) und den RDP Clients (was auch immer von daheim darauf zugreift).
Feddisch. In der Simplizität unschön, aber besser als den 3389 nackt im Netz zu haben.
Zitat von @Doskias:
Wie willst du denn ein RDS Gateway realisieren für seine beschriebene Umgebung? Du sagst auf der einen Seite, dass er nichts von VPN geschrieben hat und du daher davon ausgingst, dass kein VPN vorhanden ist. Ok, aber: Er hat auch nirgends etwas von Terminalserver geschrieben. Im Gegenteil:
Wie willst du denn ein RDS Gateway realisieren für seine beschriebene Umgebung? Du sagst auf der einen Seite, dass er nichts von VPN geschrieben hat und du daher davon ausgingst, dass kein VPN vorhanden ist. Ok, aber: Er hat auch nirgends etwas von Terminalserver geschrieben. Im Gegenteil:
Du kannst ein RDS Gateway auch ohne RDSH/VDI betreiben. Das Gateway dient ja nur als Mittelsmann zwischen dem RDP Server (offensichtlich eure Client Rechner im Büro) und den RDP Clients (was auch immer von daheim darauf zugreift).
- Im Remotedesktopgateway-Manager stellst du dann ein, welche Benutzer (Sicherheitsgruppe1) auf welche Rechner (Sicherheitsgruppe2) unter welchen Bedingungen zugreifen dürfen. Die Umleitung von Laufwerken oder der Zwischenablage würde ich beispielsweise verbieten.
- UDP Offload-Traffic solltest du im Gateway erlauben
- Das HTTPS Zertifikat kann dabei ein selbst signiertes sein.
- Auf den RDP Servern legst du per GPO oder lokal fest wer in der lokalen Gruppe "Remotedesktop-Benutzer" steckt, z.b. Sicherheitsgruppe1
- Im AD steckst du alle RDP Server, auf die zugegriffen werden darf in Sicherheitsgruppe2
- Auf den zugreifenden Clients stellst du dann noch ein RDP File mit eingetragenem Rechnernamen und Gateway ein (kann ggf signiert werden) und installierst bei Bedarf das Zertifikat des Gateway, oder besser das Zertifkat eurer Domänenzertifizierungsstelle.
Feddisch. In der Simplizität unschön, aber besser als den 3389 nackt im Netz zu haben.
Moin,
Das ist ja die "Basisfunktion" des RDP-Gateways. Aber es ist ja nicht so, dass die Benutzer sich "frei" auswählen können/sollen an welchem Rechen sie landen. Es ist vielmehr so:
User A -> PC 1
User B -> PC 2
User C -> PC 3
Und genau so schreibt es ja auch @leaon123 in seinem Posting, dass die Leute sich auf ihrem Rechner anmelden möchten. Wenn ich jetzt wie im RDP-Gateway üblich die berechtigten User und die Rechner hinzufüge, dann habe ich aber die Situation, dass es durchaus sein kann dass User A sich auf PC 3 anmeldet. Bei uns zum Beispiel würde das bedeuten (bzw. könnte), dass ein Vertrieblicher sich auf einem Konstrukteurs-Rechner anmeldet. Der Vertriebler wird dann arbeiten können, aber dem Konstrukteur fehlt sein CAD-Programm. Es hat einen Grund warum es keinen Terminalserver, sondern eine 1:1 Zuordnung gibt. Und eine 1:1 Zuordnung lässt sich meines Wissens mittels RDP-Gateway nicht umsetzen.
Davon abgesehen: Wenn ich zwischen den Zeilen lese:
Das ist die Ausgangsfrage. ich lese da raus, dass eine VPN Verbindung gibt und diese lediglich RDP 3389 und DNS 53 erlaubt. Ich gehe nicht davon aus, dass der Port 3389 frei im Internet erreichbar ist, sondern lediglich über VPN auch wenn Leon123 das nicht klar sagt. Warum ich davon ausgehe? Weil er weiter schreibt:
Wir reden hier also von mehreren Mitarbeitern, die von extern auf ihren Rechner zugreifen. Klar kann man das dann auch (theoretisch) ohne VPN machen, aber dann müsste ich jeden Rechner der von extern erreichbar ist einzeln konfigurieren. Wenn ich RPD auf die Sonicwall-Adresse mache, dann kann ich das auf einen Rechner weiterleiten. Wenn ich aber im Netzwerk zwei oder mehr Rechner habe, dann muss ich entweder eine RDP auf die Sonicwall mit unterschiedlichen Ports machen, wodurch die Sonicwall dann eine Portumleitung auf die 3389 auf den Clients macht, oder ich muss für jeden Rechner eine eigene Adresse haben über die von Extern die Sonicwall erreichbar ist. Beides ein riesen Aufwand dafür, dass es damals schnell gehen sollte.
Also auch wenn es nicht eindeutig geschrieben steht: Ich finde die Situation ist eindeutig, dass hier vor der RDP-Verbindung eine VPN-Verbindung zur SonicWall aufgebaut wird und die Ports nur innerhalb der VPNn freigegeben wurden.
Zitat von @psannz:
- Im Remotedesktopgateway-Manager stellst du dann ein, welche Benutzer (Sicherheitsgruppe1) auf welche Rechner (Sicherheitsgruppe2) unter welchen Bedingungen zugreifen dürfen.
Das ist ja die "Basisfunktion" des RDP-Gateways. Aber es ist ja nicht so, dass die Benutzer sich "frei" auswählen können/sollen an welchem Rechen sie landen. Es ist vielmehr so:
User A -> PC 1
User B -> PC 2
User C -> PC 3
Und genau so schreibt es ja auch @leaon123 in seinem Posting, dass die Leute sich auf ihrem Rechner anmelden möchten. Wenn ich jetzt wie im RDP-Gateway üblich die berechtigten User und die Rechner hinzufüge, dann habe ich aber die Situation, dass es durchaus sein kann dass User A sich auf PC 3 anmeldet. Bei uns zum Beispiel würde das bedeuten (bzw. könnte), dass ein Vertrieblicher sich auf einem Konstrukteurs-Rechner anmeldet. Der Vertriebler wird dann arbeiten können, aber dem Konstrukteur fehlt sein CAD-Programm. Es hat einen Grund warum es keinen Terminalserver, sondern eine 1:1 Zuordnung gibt. Und eine 1:1 Zuordnung lässt sich meines Wissens mittels RDP-Gateway nicht umsetzen.
Davon abgesehen: Wenn ich zwischen den Zeilen lese:
wie macht ihr das, wenn Mitarbeiter im Homeoffice mit dem eigenen PC eine VPN Verbindung herstellen wollen?
Ich habe es aktuell über die SonicWall so geregelt, dass nur RDP 3389 auf das Netzwerk sowie DNS 53 auf die beiden DCs möglich ist.
Ich habe es aktuell über die SonicWall so geregelt, dass nur RDP 3389 auf das Netzwerk sowie DNS 53 auf die beiden DCs möglich ist.
Das ist die Ausgangsfrage. ich lese da raus, dass eine VPN Verbindung gibt und diese lediglich RDP 3389 und DNS 53 erlaubt. Ich gehe nicht davon aus, dass der Port 3389 frei im Internet erreichbar ist, sondern lediglich über VPN auch wenn Leon123 das nicht klar sagt. Warum ich davon ausgehe? Weil er weiter schreibt:
Die Mitarbeiter arbeiten halt immer noch lieber auf ihrem eigenen Rechner.
Wir reden hier also von mehreren Mitarbeitern, die von extern auf ihren Rechner zugreifen. Klar kann man das dann auch (theoretisch) ohne VPN machen, aber dann müsste ich jeden Rechner der von extern erreichbar ist einzeln konfigurieren. Wenn ich RPD auf die Sonicwall-Adresse mache, dann kann ich das auf einen Rechner weiterleiten. Wenn ich aber im Netzwerk zwei oder mehr Rechner habe, dann muss ich entweder eine RDP auf die Sonicwall mit unterschiedlichen Ports machen, wodurch die Sonicwall dann eine Portumleitung auf die 3389 auf den Clients macht, oder ich muss für jeden Rechner eine eigene Adresse haben über die von Extern die Sonicwall erreichbar ist. Beides ein riesen Aufwand dafür, dass es damals schnell gehen sollte.
Also auch wenn es nicht eindeutig geschrieben steht: Ich finde die Situation ist eindeutig, dass hier vor der RDP-Verbindung eine VPN-Verbindung zur SonicWall aufgebaut wird und die Ports nur innerhalb der VPNn freigegeben wurden.
Moin,
Na die Frage hast du dir im Prinzip ja schon selbst beantwortet, soweit wir es zumindest können. Im Prinzip ist die Frage ja immer, das was der Rechner kann, dass kann auch die Gefahrenstelle. Kann der Rechner auf Netzwerkfreigaben zugreifen? Wenn nein, dann kann es auch nicht die Schadsoftware. Wichtig ist hier allerdings die Berechtigungen des Rechners im Auge zu behalten und nicht nur die Rechte des Anwenders. Ansonsten hängt es ja auch deutlich davon ab mit was für einer Schadsoftware du es zu tun hast. Wenn der Client via VPN keine Netzwerkfreigaben erreichen kann (egal auf welche Art), dann wird dir ein Verschlüsselungstrojaner wahrscheinlich nichts anhaben können. Gegen Keylogger oder Tools die den Bildschirm abfotografieren bist du aber an der Stelle leider machtlos. Da würde dir aber auch ein RDP-Gateway nicht helfen.
Ich würde an der Stelle dennoch kein eigenes Gerät zulassen. Du hast bei den Geräten keine Kontrolle über die Verwendung, was das ganze unberechenbarer macht. Ein Unternehmensgerät kannst du zum Beispiel so weit begrenzen, dass es lediglich RDP und die VPN Verbindung aufbauen kann. Der User muss damit nicht surfen. Der User muss keine Screenshots machen. Der User muss die Registry nicht öffnen, etc. Ich denke du erkennst worauf ich hinaus möchte.
Gruß
Doskias
Zitat von @leon123:
Daher stellt sich mir eben die Frage welche Gefahr besteht, wenn ein verseuchter Rechner eines Mitarbeiters sich über RDP auf einen Rechner in der Firma einwählt...
Daher stellt sich mir eben die Frage welche Gefahr besteht, wenn ein verseuchter Rechner eines Mitarbeiters sich über RDP auf einen Rechner in der Firma einwählt...
Na die Frage hast du dir im Prinzip ja schon selbst beantwortet, soweit wir es zumindest können. Im Prinzip ist die Frage ja immer, das was der Rechner kann, dass kann auch die Gefahrenstelle. Kann der Rechner auf Netzwerkfreigaben zugreifen? Wenn nein, dann kann es auch nicht die Schadsoftware. Wichtig ist hier allerdings die Berechtigungen des Rechners im Auge zu behalten und nicht nur die Rechte des Anwenders. Ansonsten hängt es ja auch deutlich davon ab mit was für einer Schadsoftware du es zu tun hast. Wenn der Client via VPN keine Netzwerkfreigaben erreichen kann (egal auf welche Art), dann wird dir ein Verschlüsselungstrojaner wahrscheinlich nichts anhaben können. Gegen Keylogger oder Tools die den Bildschirm abfotografieren bist du aber an der Stelle leider machtlos. Da würde dir aber auch ein RDP-Gateway nicht helfen.
Ich würde an der Stelle dennoch kein eigenes Gerät zulassen. Du hast bei den Geräten keine Kontrolle über die Verwendung, was das ganze unberechenbarer macht. Ein Unternehmensgerät kannst du zum Beispiel so weit begrenzen, dass es lediglich RDP und die VPN Verbindung aufbauen kann. Der User muss damit nicht surfen. Der User muss keine Screenshots machen. Der User muss die Registry nicht öffnen, etc. Ich denke du erkennst worauf ich hinaus möchte.
Ich bin gnädig und erlaube FaceID und Fingerabdruck zum Kennwort speichern ;)
Ich hoffe du meinst an der Stelle zur Kennworteingabe. Kennwörter gehören nicht gespeichert, dann kannst du sie auch gleich weglassen und Firmenkennwörter auf privaten Rechnern ja schonmal gar nicht. Gruß
Doskias
Moin Doskias,
Das Problem mit Schadsoftware besteht darin, dass Sie jegliche Schwachstelle ausnutzt um auf ein anderes System zu kommen. Sie macht auch nicht halt, wenn das "Opfer" nur vermeintlich minimale Rechte hat. Irgendwo ist immer etwas offen, da Sicherheitsmassnahmen den User immer mit "Extraklicks" belästigen oder zum Lesen und Verstehen auffordern.
Gruß
C.C.
Das Problem mit Schadsoftware besteht darin, dass Sie jegliche Schwachstelle ausnutzt um auf ein anderes System zu kommen. Sie macht auch nicht halt, wenn das "Opfer" nur vermeintlich minimale Rechte hat. Irgendwo ist immer etwas offen, da Sicherheitsmassnahmen den User immer mit "Extraklicks" belästigen oder zum Lesen und Verstehen auffordern.
Gruß
C.C.