[WinBasti10]

Einen schönen guten Tag liebes Forum,

ich habe ein kleines Problem in meinem selbstkonfigurierten Netzwerk in der Firma.

Zu meiner Ausgangslage:
In der Firma ist ein Server mit Windows 2008 R2 installiert. Zu diesem Server gibt es ca. 5-8 Desktop-PCs. Auf dem Server habe ich einige Server-Applikationen installiert, weshalb ich den Desktop-PCs gestatte über eine Remote-Desktop-Verbindung (RDP) auf den Server zuzugreifen und dort zu arbeiten. Das funktionierte auch schon die letzten beiden Jahre perfekt. Ungefähr vor einem viertel/halben Jahr habe ich 2,3 Mitarbeitern ermöglicht/erlaubt auch manchmal von zu Hause zu arbeiten. Sprich, sie können mittlerweile per RDP von zu Hause auf den Server zugreifen und dort ihrer Arbeit nachgehen. Das funktioniert nun auch problemlos.

Vorhaben
Da der Sicherheitsaspekt heutzutage immer weiter in den Fokus rückt, habe ich mir jetzt vorgenommen, die RDP-Verbindungen weiter zu schützen. Auf der Suche nach Möglichkeiten bin ich auf die folgenden Seite aufmerksam geworden:

RDP - Absicherung

Hier bin ich jetzt mittlerweile bei dem Schritt "Nutzung von IPSec für Verschlüsselung und Integrität". Ich habe die beiden Batch-Dateien heruntergeladen und jeweils angepasst.

Server:
Pre-Shared-Key: xxxxx (beliebigen Schlüssel)

Client
Pre-Shared-Key: xxxxx (beliebigen Schlüssel)

Nach der Erstellung und der Aktivierung der Regel durch die Batch-Datei konnten sofort die internen Desktop-PCs nicht mehr auf den Server zugreifen. Das funktioniert also...Daraufhin habe ich die Batch-Datei für Server und Client erweitert:

Trusted-IPs:
192.168.1.0/24


Nach erneuter Erstellung und Aktivierung hatten die Desktop-PCs wieder Zugriff. Da dachte ich erstmal perfekt!!! Allerdings schaffe ich es jetzt nicht, dass auch die externen PC/Laptops's Zugriff haben. Dort habe ich genau die gleiche Client.bat ausgeführt, womit die Regel und damit der Pre-Shared-key installiert sein sollte.

Weiß jemand woran das liegt oder mache ich grundsätzlich etwas falsch? Wie bekomme ich die Clients von außen über einen Pre-Shared-Key abgesichert?
Diese PCs haben natürlich eine öffentliche IP, aber werden anscheinend nicht zugelassen. Außerdem ist noch zu erwähnen, dass vor dem Firmennetzwerk ein Router hängt (z.B. 176.45.32.209, statische IP), der dann direkt an den Server weiter routet (z.B. 192.168.1.50)
Da es ohne der Regel wunderbar funktioniert denke ich eigentlich, dass ich bzgl. Firewall/Router/etc. nichts weiter konfigurieren muss?


Mit besten Grüßen
WinBasti10

[DanielDuesentrieb]

Mal ganz von vorne angefangen: wie baust Du denn die Verbindung zu dem Server auf? DynDNS? PPTP oder echtes VPN mittels IPsec und geeignetem Router?

Oder öffentliche feste IP-Adresse mit Portweiterleitung 3389 auf den Server? Hilfe ...

VPN mittels IPsec würde ich empfehlen: bintec Router, dort VPN aktivieren und konfigurieren und dann mittels IPsec Software sich zum Router verbinden. Dann brauchst Du da keine RDP-Verbindung absichern oder "verunstalten". Gruppe im AD anlegen, dort die Mitarbeiter rein, die Zugriff auf den Server haben und nur den dort freigeben. Domain-Admin kann natürlich immer alles.

Ist dein 2008 R2 als Fileserver oder RDS-Server (Terminalserver) aufgesetzt?

Dieser Beitrag wurde von DanielDuesentrieb bearbeitet: 10. August 2016 - 17:17

[WinBasti10]

Hi DanielDuesentrieb,

vielen Dank für deine Antwort!
Genau genommen handelt es sich um einen "Windows Server 2008 R2 Foundation - Server", auf dem nachträglich der Terminal-Service hinzugefügt wurde. Ansonsten dient er als Fileserver.

Exakt, das Firmennetz hat eine öffentliche statische IP-Adresse, über die die Heim-Computer zugreifen, und im Router wird über Port 3389 auf den Server weitergeleitet. Der Router und die Weiterleitung war aber bereits konfiguriert, da kann ich eigentlich nichts ändern, da habe ich meine Finger nicht drin. Mit dieser Ausgangsituation würde ich schon gerne weiter arbeiten, anstatt einer komplett neuen VPN-Konfiguration. Wäre das nicht möglich?

Es geht hier auch um keine Firma, die hochsensible Dateien besitzt. An die Daten hätte vermutlich keiner Interesse, nur es soll einem ja nicht zu einfach gemacht werden.

Mit besten Grüßen

[DanielDuesentrieb]

Zitat

Ansonsten dient er als Fileserver.

Äh, läuft da auch das AD drauf? Also am Ende ein All-in-One? Empfiehlt weder Microsoft noch ich. Geht das Ding platt, habt ihr gar nichts mehr. Dann muss man von grundauf neu einrichten - alles: AD, DNS, DHCP, RDS ...

Wie sieht Eure Sicherung aus? Bitte keine externe USB-Festplatte vom MediaMarkt.

Zitat

Wäre das nicht möglich?

Technisch ist immer alles möglich. Ob das nach gewissen Standards auch vertretbar ist, steht auf einem anderen Blatt. Wenn Du das so belässt und versucht da mit irgendwelchen Batches und RDP-Hacks zu arbeiten, löst Du nicht das Sicherheitsproblem, sondern machst es ähnlich wie die EU mit dem Flüchtlingsthema. Anstatt das Problem an der Wurzel zu lösen, werden andere angebliche Lösungen geschaffen.

RDP-Port Weiterleitung ist in meinen Augen eine schwere Katastrophe. Wenn Du es recht einfach haben möchtest, richte zumindest PPTP ein.

Zitat

Es geht hier auch um keine Firma, die hochsensible Dateien besitzt.

Firmendaten sind Firmendaten, egal ob da Patente oder anderes KnowHow hintersteckt. Wenn die Verbindung geknackt ist, erste Daten in 3. Hände gelangen ist das Geschrei am Ende groß!

Mein Tipp: statte die Firma mit einem bintec Router aus (oder ähnlicher Router, Cisco etc.), der echtes VPN macht. Dort legst Du die VPN-Clients an inkl. Preshared-Key und richtest die VPN-Client-Software am PC, Notebook, zu Hause ein. Dann wird über das Internet schon mal ein echter "VPN-Tunnel" bis zur Firma aufgebaut, den niemand so leicht abhören oder mitschneiden kann (im Rahmen der Konfiguration, technisch können Hacker auch hier natürlich alles, wenn sie es drauf anlegen - 100%ige Sicherheit gibt es nicht). Und über den VPN-Tunnel baust Du Dir dann die RDP-Sitzung auf.

Habt ihr Macs? Dann kannst Du dort mit Boardmittels IPsec einrichten (auch jedes iPhone und iPad kann das). So kannst Du mittels RDP-App auch auf mobilen Geräten auf dem Server arbeiten.

[RalphS]

IPSec und RDP sind völlig verschiedene Paar Schuhe.

Man *könnte* RDP spezifisch via IPsec absichern, indem man das über dasselbe Domainkonto erledigen läßt und dazu eine PKI einrichtet.

Haken: Das funktioniert nur in der Firma. Denn extern müßte ja erstmal am Domainkonto authentfiziert werden, um den IPSec-Schlüssel zu kriegen - aber dazu muß man ja erstmal in die Firma.

Daher ist der von Daniel vorgeschlagene Weg nicht nur der bessere, sondern der einzig praktikable.

- Allerdings ist IPSec tatsächlich für den Neuling eher schwieriger zu konfigurieren.

-- Daher, zwei Optionen. Okay, genaugenommen sogar drei:

Ad 1. PPTP nehmen. Davon ist abzuraten, weil unsicher.

Ad 2. SSTP nehmen.

Ad 3. IPSec nehmen und bei MS nach Test Lab Guides schauen. Damit kann man in einer virtuellen Umgebung eine IPsec-Konfiguration geführt zusammenbauen (als Beispiel). Fürs VPN wäre das dann L2TP+IPsec.

Für (2) und (3) empfiehlt sich außerdem die Einrichtung einer PKI.

Oder, Daniels Vorschlag folgend, eine hardwarebasierte Lösung via zB Cisco-Router. "Normal" würd ich sagen, damit dann 802.1x bauen, aber wenn das nur sehr wenig Benutzer sind, ist das natürlich overkill.


PS. Weil das irgendwie nicht recht hervorgehen will aus dem bisher gesagten und ich auf Nummer Sicher gehen möchte, daß das geklärt ist:

- RDP erfordert zusätzliche Zugriffslizenzen (CALs) für die Clients.

[WinBasti10]

Zitat

Äh, läuft da auch das AD drauf? Also am Ende ein All-in-One? Empfiehlt weder Microsoft noch ich. Geht das Ding platt, habt ihr gar nichts mehr. Dann muss man von grundauf neu einrichten - alles: AD, DNS, DHCP, RDS ...

Wie sieht Eure Sicherung aus? Bitte keine externe USB-Festplatte vom MediaMarkt.

Nein, da läuft kein AD, etc. drauf. Und wie gesagt, es handelt sich nur um 2,3 Anwendungen, die auf dem Server laufen. Der Server besitzt ein RAID und zusätzlich wird auch regelmäßig ein BackUp auf eine NAS an einem anderen Standort durchgeführt (hierbei werden aber auch nur die Ordner der Anwendungen gesichert, darauf möchte ich jetzt aber nicht weiter eingehen).

Zitat

Wenn Du das so belässt und versucht da mit irgendwelchen Batches und RDP-Hacks zu arbeiten, löst Du nicht das Sicherheitsproblem, sondern machst es ähnlich wie die EU mit dem Flüchtlingsthema. Anstatt das Problem an der Wurzel zu lösen, werden andere angebliche Lösungen geschaffen.

Iwelche Batches oder RDP-Hacks finde ich jetzt etwas übertrieben, aber ok. Es handelt sich ja letztendlich nur um die automatische Erstellung von Regeln, die auch ohne Probleme manuell über "mmc" erstellt werden können. Das ist ein Dienst von Microsoft.

Zitat

RDP-Port Weiterleitung ist in meinen Augen eine schwere Katastrophe. Wenn Du es recht einfach haben möchtest, richte zumindest PPTP ein.

Wieso ist das eine Katastrophe? Wenn das so ist, dann werde ich gerne Euren Rat folgen und auf jeden Fall etwas anderes realisieren bzw. ansprechen, dass wir das ändern müssen

Zitat

Habt ihr Macs? Dann kannst Du dort mit Boardmittels IPsec einrichten (auch jedes iPhone und iPad kann das). So kannst Du mittels RDP-App auch auf mobilen Geräten auf dem Server arbeiten.

Ne, haben wir nicht, es handelt sich in Moment alles um Windows 7 Clients und evtl. werden die in absehbarer Zeit auf Windows 10 umgerüstet.



Da ich eine hardwareseitige Lösung in Moment nicht sofort realisieren kann, werde ich es aber auf jeden Fall für das nächste halbe Jahr in Betracht ziehen und auf die To-Do Liste aufnehmen.
Für die zeitnahe Umsetzung habe ich die weiteren Möglichkeiten von Ralphs angeschaut.

Zitat

Ad 1. PPTP nehmen. Davon ist abzuraten, weil unsicher.
Ad 2. SSTP nehmen.
Ad 3. IPSec nehmen und bei MS nach Test Lab Guides schauen. Damit kann man in einer virtuellen Umgebung eine IPsec-Konfiguration geführt zusammenbauen (als Beispiel). Fürs VPN wäre das dann L2TP+IPsec.
Für (2) und (3) empfiehlt sich außerdem die Einrichtung einer PKI.

PPTP entfällt dann ja sowieso.
Wie schaut es denn mit SSTP aus, wäre das eine angemessene Lösung? Da habe ich eine Beschreibung hier gefunden SSTP,
welche für mich auch so erscheint, dass ich sie schnell umsetzen kann.


Mit besten Grüßen

[RalphS]

Ich denke, SSTP ist schon recht okay. Es erfordert halt Zertifikate im Backend.

Also ADCS einrichten und konfigurieren und dann per GPO die Zertifikate auf die Clients (genauer: die Benutzer, nicht die Geräte) ausrollen.

Ohne AD wird das allerdings schwierig. In dem Fall müßtest Du zB mit openssl Zertifikate händisch erstellen, den einzelnen Benutzern in die Hand drücken und auch warten (insbesondere: kompromittierte Zertifikate sperren). Fast müßig zu erwähnen, daß das nicht so die gute Idee ist.

- Auf den Firewalls läuft SSTP - wie der Name vermuten läßt -- über 443/tcp eingehend und ausgehend (Secure Sockets Tunneling Protocol => über HTTPs getunnelt). Mehr braucht man da dann nícht.

Dieser Beitrag wurde von RalphS bearbeitet: 12. August 2016 - 10:44

[WinBasti10]

Hast du die Beschreibung von:

https://marcowue.wor...-r2-einrichten/


kurz überflogen? Ich glaub, da ist nicht die Rede von dem AD. Das hört sich für mich dort alle sehr plausible und relativ leicht umzusetzen an.

[RalphS]

Doch ist es: die Zertifikate sind Teil der ADDS, daher der Name: ADCS, wie Active Directory Certficate Services.

Ansonsten, mh via Webinterface geht natürlich auch, aber dann muß halt der besagte Webserver auch erreichbar sein. Zertifikate hängen an Namen; sowas wie DynDNS wäre also unabdingbar.

Außerdem muß man dann zumindest einmal (ganz zu Anfang) Benutzernamen und Paßwort eingeben. Geht, verschiebt den Aufwand vom Rollout zur Einrichtung der CS Webschnittstelle.


Ich persönlich würde sagen, laß die Webschnittstelle weg und sorg dafür, daß jedes Benutzerkonto sein Zertifikat kriegt = praktisch hieße das, jeder der da rankönnen soll muß sich mindestens einmal nach Aktivierung der GPO local in der Domain einbuchen, damit das Zertifikat auf den Schlepptop ins Benutzerkonto kommt.


Eine Schwachstelle hat dieser Ansatz aber auch: Wenn jemand Zugriff auf Laptop und das Benutzerkonto kriegt, zB weil gemopst oder vergessen oder beides und außerdem entweder kein oder ein kompromittiertes Paßwort da ist... kurz, wer Zugriff auf Laptop und Benutzerkonto bekommt, erhält so auch Zugriff aufs Firmennetz.

Dem kann man ggf entgegenwirken, indem man die Privatschlüssel mit Paßwörtern versieht und/oder den Zugriffslevel der Privatschlüssel erhöht. Dann muß beim Aufmachen der VPN-Verbindung dieses Paßwort eingeben bzw der Zugriff per UAC Prompt bestätigt werden (letzteres bringt natürlich nur was, wenn der/die Benutzer zumindest lokale Adminrechte haben).

Schau Dich am Besten mal entweder bei Microsoft in der MSDN oder bei OpenSSL in der Dokumentation um zum Thema PKI. Es gibt sicher noch andere gute Seiten zum Thema; aber leider sind Zertifikate und PKI das vermutlich mißverstandendste Thema der IT und entsprechend fliegt viel, viel Fehlinformation zum Thema durchs Netz.

Dieser Beitrag wurde von RalphS bearbeitet: 12. August 2016 - 11:32

[WinBasti10]

Dann mach ich mich mal an die Arbeit =)

jetzt habe ich nur noch diese Fehlermeldung :-/

"Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war"

Dieser Beitrag wurde von WinBasti10 bearbeitet: 12. August 2016 - 14:10

[WinBasti10]

Schönen guten Abend,

nun funktioniert es auch komplett. Vielen Dank für Eure ganze Hilfe!

Vielleicht hat sich auch jemand die Anleitung angeschaut. Dadurch habe ich aber immer noch einen Fehler bekommen.

Die Lösung war unter:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters

noch einen REG_DWORD (32Bit) mit dem Namen "NoCertRevocationCheck" und dem Wert 1 zu erstellen!


Mit besten Grüßen

Dieser Beitrag wurde von WinBasti10 bearbeitet: 15. August 2016 - 17:44