SSL over RDP voor Windows Server 2003

[maartena]

Doordat wij ons als bedrijf ons moeten houden aan bepaalde strenge veiligheidsmaatregelen, en RDP verkeer over het LAN in principe niet veilig is, maar onder bepaalde omstandigheden bepaalde informatie kan worden afgevangen, gaan we het RDP verkeer versleutelen met SSL. We hebben een network scanner van Nessus die ons netjes uitlegt waarom normaal RDP verkeer voor server beheer niet geheel waterdicht is. Voor meer informatie, zie ook hier: http://www.securityfocus.com/bid/13818/info - het gaat om een "design error" die nooit gefixt is. Server 2008 en Vista hebben het probleem niet (meer).

Er zijn hiervoor diverse artikelen van Microsoft in Technet die ik hiervoor heb geraadpleegd, maar uiteindelijk kwam ik bij dit artikel uit: http://www.petri.co.il/securing_rdp_communications.htm

Door het volgen van de aanwijzingen op die site ben ik een heel eind op weg. Ik heb een Certificate Authority gecreëerd, en intussen al zo'n 5 servers zo geconfigureerd dat RDP verkeer versleuteld is. Ik wil natuurlijk alle 40 Windows servers aanpakken, maar tijdens tests kwam ik er toch achter dat e.e.a. niet werkt als de server niet in hetzelfde domein zit als de Certificate Authority.

Ik heb pakweg 30 servers in bedrijfsnaam.lan , en 10 Windows servers in de werkgroep dmz, die - de naam zegt het al - in de DMZ staan, op een aparte IP range. Hier staan o.a. FTP servers, Web servers, en de Edge Transport server voor Exchange 2007. (Er staan ook nog een stuk of wat Linux servers, maar dat terzijde).

Het certificaat dat wordt afgegeven door de Certificate Authority werkt dus prima in het domein, maar niet op servers daar buiten, ook niet als ik em handmatig importeer na een export. Het schermpje in de Terminal Server properties blijft leeg, en een certificaat is niet te selecteren.

Nu vraag ik me een aantal zaken af:

1) moet de DMZ server kunnen verbinden met de Certificate Authority, ook al importeren we het certificaat middels een .cer bestand? (Als dit het geval is, moet ik wat gaatjes gaan prikken in de firewall tussen de DMZ en het interne netwerk)

2) Is Microsofts Certificate Auhtority afhankelijk van een domein? Ofwel, als ik em in het domein tot leven roep - in dit geval geinstalleerd op de Secondary Domain Controller omdat deze toch voornamelijk uit zijn neus staat te vreten - kan ik die certificaten dan alleen gebruiken binnen de het domein bedrijfsnaam.lan?

3) Indien geval 2 waar is, kan ik dit oplossen door een tweede Certificate Authority te installeren op 1 van de DMZ servers?

Wie o wie heeft wat meer ervaring hiermee?

[RolandZ]

Heb je het Root CA certificaat al toegevoegd aan de trusted roots op de servers in de DMZ?

[alt-92]

maartena schreef op vrijdag 27 februari 2009 @ 17:03:
Nu vraag ik me een aantal zaken af:

1) moet de DMZ server kunnen verbinden met de Certificate Authority, ook al importeren we het certificaat middels een .cer bestand? (Als dit het geval is, moet ik wat gaatjes gaan prikken in de firewall tussen de DMZ en het interne netwerk)

Je moet in ieder geval de CRL kunnen vinden daarna, en het CArootCert in de trusted store opnemen.

2) Is Microsofts Certificate Auhtority afhankelijk van een domein? Ofwel, als ik em in het domein tot leven roep - in dit geval geinstalleerd op de Secondary Domain Controller omdat deze toch voornamelijk uit zijn neus staat te vreten - kan ik die certificaten dan alleen gebruiken binnen de het domein bedrijfsnaam.lan?

In principe heb je nu een Self Signed Root certificate en de bijbehorende PKI infrastructuur.
Binnen je AD wordt dat door middel van auto-enrollment wel geregeld, maar buiten je eigen contained PKI netwerk moet je jouw root als trusted aangeven voor derden.

offtopic:
Overigens kun je nu die DC niet meer DC-af maken zonder eerst je CA te slopen.
Niet voor niks wordt aangeraden die CA op een standalone machine te doen die je kan archiveren, de subordinates zijn wat dat betreft flexibeler.

3) Indien geval 2 waar is, kan ik dit oplossen door een tweede Certificate Authority te installeren op 1 van de DMZ servers?

wellicht zoals gezegd een subordinate, maar wat in dit verhaal nog niet duidelijk is is welke Windows Server-variant je gebruikt.

Wat meer PKI info en een soortgelijke aanpak:
http://blogs.technet.com/...certificate-concepts.aspx

[ Voor 3% gewijzigd door alt-92 op 27-02-2009 23:39 ]

[crazymonkey87]

Misschien een totale andere blik en het is niet wat je wil maar is IPsec in transport mode misschien wat voor je binnen het lan?

[Turdie]

Je hoeft volgens mij niet per se die artikelen van petri.co.il te volgen. Je kunt op je servers ook door middelIPsec met kerberos of certifcaten secure maken.Voor Kerberos en certificaten is Active Directory een vereiste.

IPsec wordt in Windows omgevingen niet vaak gebruikt, simpelweg omdat het behoorlijk lastig in te regelen is. Vooral in DMZ omgevingen waar het secure moet zijn is het erg geschikt. Ik weet niet wat precies wat voor CA je gebruikt maar hier een overzicht aan welke de verschillende Windows CA's moeten voldoen

• Enterprise CAs are integrated into Active Directory and must be domain controllers
• Stand-alone CAs do not use certificate templates or Active Directory; they store their information locally.Stand-alone CAs are intended for situations in which users outside the enterprise submit requests for certificates.

Dus is denk even de vraag wat voor CA heb je gemaakt?

[ Voor 99% gewijzigd door Turdie op 28-02-2009 00:03 ]

[maartena]

De servers in de DMZ zijn sowieso geen lid van het domain, dus ik denk dat Kerberos en Certificaten met IPSec lastig gaat worden. Sowieso wil ik denk ik niet aan IPSec voor RDP, met name omdat we (nu we als organisatie gegroeid zijn en alleen een LAN en een DMZ niet meer voldoet) het netwerk willen uitsegmenteren in diverse subnets etc, en dat brengt alleen maar meer werk met zich mee

Ik ga eerst eens kijken of ik het type certificaat goed heb gedaan.... We gebruiken trouwens Windows 2003 Standard op vrijwel alle servers, een paar Legacy 2000 bakken nog, en een enkele 2008 die we onlangs voor het eerst in productie hebben gebracht.

Bedankt zover voor het meedenken, zal volgende week eens zien