Just do I(nformation)T(echnology) : Security

Terminal Services Gateway beveiligen met ISA Server 2006

mpriem — Sat, 09 May 2009 11:13:30 GMT

Met ISA Server 2006 kan je een Terminal Services Gateway voorzien van extra beveiliging door deze te publishen via een Web Listener. Daar TSG gewoon gebruik maakt van RPC over HTTPs zoals Exchange met Outlook Anywhere dat ook doet, gaat het publishen hiervan net zo gemakkelijk.

Om te beginnen moeten we SSL certificaten hebben voor zowel de ISA server als de TSGateway. Aangezien de ISA Server draait op Windows Server 2003 hebben we nog niet de mogelijkheid om vanuit de Certificates Snap-in een Certificate Signing Request (CSR) te maken. Veelal moet er een offline request gemaakt worden, omdat dat bijvoorbeeld naar een Public Certificate Authority zoals Verisign gestuurd moet worden. Op Windows Server 2003 hebben we beperkte mogelijkheden. Zo kunnen we een request maken via IIS, maar een webserver installeren voor een CSR is een beetje overdone. Ook kunnen we gebruik maken van een Microsoft CA via de certificate Server Website, maar ook die is niet altijd voor handen. De laatste mogelijkheid is om een certificaat aan te vragen op een Windows 2008 machine met de mogelijkheid de private key te exporteren en dan vervolgens het complete keypair te exporteren en importeren. Dat is echter minder secure, want als het systeem gecompromitteerd wordt, kan het complete keypair gestolen worden, in plaats van alleen de public key.
Dan blijft er dus eigenlijk alleen CertReq.exe over, wat onderdeel is van de Administration Toolkit http://www.microsoft.com/downloads/details.aspx?familyid=86b71a4f-4122-44af-be79-3f101e533d95&displaylang=en

Hiervoor moet een INF bestand aangemaakt worden volgens de syntax op http://technet.microsoft.com/en-us/library/cc736326.aspx

Nu lijkt dit heel moeilijk, maar als je het even goed doorleest valt het allemaal wel mee. Mijn INF bestand ziet er als volgt uit:

[NewRequest]
Subject = "CN=rdp.home.com"
PrivateKeyArchive = FALSE
KeySpec = 1
KeyLength = 1024
Exportable = FALSE
UserProtected = FALSE
MachineKeySet = TRUE
Silent = TRUE
ProviderName = "Microsoft Enhanced Cryptographic Provider v1.0"
ProviderType = 1
UseExistingKeySet = FALSE
RequestType = PKCS10
KeyUsage = 0x30
EncipherOnly = TRUE
[RequestAttributes]
CertificateTemplate = "WebServer"

Nu sign ik mijn eigen certificaten, maar Internet CAs hebben vaak bepaalde eisen over de opmaak van het CSR (voornamelijk rondom het Subject en usage attributen). Op de internetsites van deze bedrijven is vaak meer informatie te vinden. Zorg dus dat je aan deze voorwaarden voldoet.

Na het aanmaken van de INF, kan ik een CSR creëren met het volgende commando:"

Certreq.exe –new <padnaarinf.inf> <padnaarcsr.req>8

Met het CSR kan je vervolgens het certificaat aanvragen. Wanneer je het certificaat terugkrijgt van de CA (mocht je een Windows 2008 CA hebben zoals ik, kan je via de Certificate Authority MMC snapin het request honoreren, en het certificaat opslaan), dien je het als keypair op te slaan door het volgende commando te draaien:

Certreq.exe –accept <padnaarcertificaat.cer>8

De keypair wordt nu opgeslagen in de Computer > Personal certificate store. Vergeet dit laatste commando niet, want je kunt prima het certificaat opslaan via andere wegen, maar dan wordt het niet gekoppeld aan de private key die gebruikt is bij het vervaardigen van het request. Je hebt dan geen keypair en kan het certificaat dus niet gebruiken voor SSL/TLS doeleinden. Nutteloos dus.

Het tweede CSR is een stuk simpeler. Daar Terminal Services Gateway een Windows Server 2008 service is, kunnen we heel simpel een Custom Request maken vanuit de Certificates MMC snapin.

In het request, kies je voor het Web Server template. Behoudt de default settings, welke automatisch de common name als Subject neemt. Dit is voldoende voor ons scenario, tenzij je dit interne certificaat ook door een publieke CA wilt laten aanmaken, waardoor je weer met bepaalde eisen te maken kan hebben. Voor een interne CA –bijvoorbeeld de Windows 2008 CA – is dit meestal voldoende. Genereer het certificaat bij de CA (voor Windows 2008 CA via de Certificate Authority MMC Snapin > New Request) en importeer het certificaat in de Computer > Personal certificate store.

Na het installeren van de certificaten gaan we een Web Listener aanmaken. Dit doe je vanuit de Network Objects in de ISA Console.

Kies voor New Web Listener.
Geef een naam voor de Web Listener.
Kies er vervolgens voor Secure verbindingen te gebruiken
Geef de netwerken op waar de Listener, moet 'Listenen' J. Ik heb een 3-leg configuratie dus ik kies voor het External Network.
Kies vervolgens het certificaat dat we zojuist hebben aangemaakt.
Authentication moet op basic HTTP staan, met als directory Active Directory of LDAP. Voor meer informative over LDAP authenticatie, zie http://www.isaserver.org/tutorials/LDAP-Pre-authentication-ISA-2006-Firewalls-Part1.html
SSO kan niet met HTTP basic, dus selecteer Next en Finish om af te sluiten.

Vervolgens moet er een Publishing Rule aangemaakt worden. Dit gaat als volgt:

Vanuit de ISA Console ga je naar Firewall Policy > New > Exchange Web Client Access Publishing Rule.
Kies vervolgens voor Exchange 2007, Outlook Anywhere (RPC/HTTPs) en deselecteer Publish additional folders…
Kies voor Publish a single Web site or Load balancer.
Kies voor een SSL connectie richting de backend.
Geef de interne FQDN van de Terminal Services Gateway en de machinenaam of ip adres op:
Kies vervolgens voor This domain name only (type below:) en geef de externe FQDN op die we bij de certificaat aanvraag hebben opgegeven (de CN in het subject, in mijn voorbeeld rdp.home.com).
Selecteer de Web Listener die we zojuist hebben aangemaakt.
Kies voor No Delegation, but client may authenticate directly.
Selecteer een user set en maak de installatie af.

Verder kan het zijn dat het CA certificaat in de Trusted Certificate Root Authorities store van het Computer Account opgeslagen moet worden. Dit moet gebeuren op de server machines, maar ook op de client machines. Ik gebruik een interne CA, dus ik heb het op alle non-domainjoined machines en mijn client machines handmatig moeten toevoegen. Het certificaat is te vinden in de Computer > Personal store van de CA (veelal bevat deze er minimaal twee, dus controleer goed dat je het CA certificaat te pakken hebt, en niet het computer certificaat of enig ander certificaat)

Als Laatste vraag je de properties op van de Rule, en selecteer je Test Rule (vanaf ISA 2006 Service Pack 1). Dit controleert de configuratie. Als er iets mis is met certificaten, zal je dat nu zien.

Nu alles geconfigeerd is, is het tijd om het te testen met een terminal services client. In de advanced properties van de client, geef je de externe FQDN op van de ISA server:

Op de terminal services gateway geef je in je Connection Policy op, welke users connectie kunnen maken met de Gateway. In de Resource Policy geef je de users op die verbinding mogen maken met de resources, en je geeft de machines op die als resource mogen dienen. Als je nu een verbinding maakt, krijg je eerst een prompt voor Connectie, en vervolgens voor de resource. Ik vind het persoonlijk fijn om slechts een enkel account rechten te geven voor de connectie; deze verder geen rechten te geven op enig andere resource, en via AD Auditing te tracken; En vervolgens een ander account te gebruiken voor de connectie naar de resource.

Mocht je tegen problemen aanlopen, check dan de Terminal Services Gateway logs op de TS gateway en de ISA Logs. Verder is er nog enige informatie te vinden op: http://technet.microsoft.com/en-us/library/cc731353.aspx

Office Server 2007 en Windows Server 2008 Advanced Firewall

mpriem — Fri, 12 Dec 2008 21:06:27 GMT

Ook voor Office Server 2007 heb ik maar even een lijstje met porten opgesteld om dit in samenwerking met Windows Server 2008 advance firewall te gebruiken.

Direct Hosted SMB	445 TCP/UDP
Office Web Services	56737, 56738 (SSL) TCP
RPC endpoint mapper	135 TCP
Dynamic Ports SSO	Standaard = 49152 - 65535 TCP/UDP
Non-default Web Sites	Alle sites die niet op 443 en 80 draaien hebben een firewall rule nodig.

MOSS heeft SMB nodig om de index te propageren naar de Query servers, search query results op te halen van de Query servers, en om de crawl data te versturen naar de Index Server. Verder gebruikt Sharepoint Web Services voor administratie van de farm services en dergelijke. Ook gebruikt MOSS, wanneer SSO geconfigureerd is gebruik de SSO service een dynamische port, geregisteerd bij de RPC endpoint mapper.
Tenslotte dien je voor elke website die niet op standaard HTTP porten draait een gaatje te prikken.

Gebruik de MMC snapin of console om de rules aan te maken, waarbij het aanbevolen is gebruik te maken van de meer geadvanceerde features van de advanced firewall. Je kan namelijk filteren op RPC en RPC-EPMAP porten, en deze zelfs koppelen aan programma's of windows Services. Voor de SSO rules zou ik dus een rule aanmaken waarbij alleen de RPC service en de RPC-EPMAP port zijn toegestaan, en een rule waarbij alleen de Microsoft Single Sign-on service gekoppeld wordt aan een bij de endpoint mapper geregistreerde port.
Daarnaast kan je voor het System process (waar http.sys leeft) een rule maken die de toegang tot de non-default web applicaties en tot de Office Web Services toestaat.
Tenslotte is er al een standaard rule voor SMB, genaamd "File and Printer sharing (SMB-In)", welke geactiveerd dient te worden.

De volgende voorbeeld commando's (wederom voor het domain profiel, zonder profile=domain gelden de rules voor elk firewall profiel) kunnen gebruikt worden via admin console:

netsh advfirewall firewall add rule name="SSO Service dynamic RPC" service=entsso action=allow protocol=TCP dir=in localport=rpc profile=domain8

netsh advfirewall firewall add rule name="RPC endpoint mapper" service=rpcss action=allow protocol=TCP dir=in localport=rpc-epmap profile=domain8

netsh advfirewall firewall add rule name="Sharepoint intranet portal" program=System action=allow protocol=TCP dir=in localport=81 profile=domain8

netsh advfirewall firewall add rule name="Sharepoint web services" program=System action=allow protocol=TCP dir=in localport=56737,56738 profile=domain8

netsh advfirewall firewall set rule name="File and Printer sharing (SMB-In)" new enable=yes profile=domain8

Meer over NetSh advfirewall: http://support.microsoft.com/kb/947709

Meer informatie over MOSS hardening: http://technet.microsoft.com/en-us/library/cc262849.aspx

Forefront Threat Management Gateway BETA

mpriem — Wed, 10 Dec 2008 23:25:00 GMT

Zoals voor velen al bekend houdt de merknaam ISA Server op te bestaan. Deze veelzijdige security oplossing gaat verder onder de naam Forefront Threat Management Gateway (TMG), waarvan reeds een publieke beta beschikbaar is op http://www.microsoft.com/forefront/stirling/en/us/default.aspx .

TMG is onderdeel van de suite onder de codenaam 'Stirling', waar onder andere ook een centrale management console onderdeel van is. Met deze console kunnen alle producten onder de Forefront merknaam beheerd worden.

Deze post gaat over de installatie van TMG. TMG heeft alles wat ISA Server 2006 heeft, maar installeert daarentegen WEL op Server 2008 en op 64 bits versies. Sterker nog, de uiteindelijke versie draait alleen op 64 bits versies van 2003 en 2008.

Installatie van TMG is zeer eenvoudig en vereist eigenlijk geen configuratie vooraf, behalve vaste IP addressen voor de NICs die gebruikt gaan worden en de volgende systeemeisen:

1GB RAM
150MB disk ruimte
1 NIC voor elk netwerk dat verbonden wordt met TMG.
64 bits architectuur

De installatie zal verder alle prerequisites installeren. In dit geval zijn dat:

Routing en Remote Access Services voor de NAT, remote access en routing diensten.
Internet Information Services voor de reports.
SQL Express voor de opslag van de configuratie en logs.

Na de ISO gebrand en geladen te hebben start de installatie met de volgende stappen:

Welcome Screen à Next
EULA à Next
Customer Information , je naam en bedrijf à Next
Component Selection à Next
Internal Network, waarbij je de iprange van het interne netwerk moet opegeven. à Next

Op dit moment waarschuwt de installatie dat het services gaat herstarten als IIS, Routing en Remote Access en SNMP service. Echter op een kale server zijn deze nog niet aanwezig J
Wanneer je de waarschuwing hebt geaccepteerd, kan er gekozen worden de installatie te starten.

Setup installeert de software en alle benodigde extra componenten. Schijnbaar installeert het enkele fixes, want ik moest tijdens de installatie de server rebooten door een hotfix installatie. Aangezien ik geen internetverbinding had, kan het dus niet anders dat TMG dat heeft gedaan.
Ik moest de setup dus opnieuw starten en alle stappen nogmaals doorlopen. Erg slordig vind ik.

Na de installatie start de Getting Started Wizard waarmee de initiele configuratie gestart kan worden.

De Configure Network Settings sectie stelt je in staat te kiezen uit een aantal netwerk typologieën zoals deze ook aanwezig zijn in ISA Server 2006.

De Configure System Settings stelt je in staat de domain/workgroup en hostname voor je server te configureren. Deze beta is echter alleen geschikt voor Domain installaties zoals de helpfile mij verteld. Ik heb echter een workgroup installatie gedaan en deze werkte wel voor de basis firewall.

De Define Deployment Options is tenslotte bedoelt om MS Update, Customer Experience Reporting en Telemetric Services te configureren. Deze laatste stuurt informatie over malware dat geblockeerd wordt naar Microsoft om verbeteringen in het product aan te brengen. Ik stel dus voor dit in te stellenJ

Na de wizard doorlopen te hebben kan je aan de slag met TMG, en zal je zien dat het eigenlijk nog ISA 2006 is, met wat extra managebility features.

Ik zou zeggen, aan de slag!

Subject Alternative Names met Microsoft Certificate Authority

mpriem — Wed, 10 Dec 2008 22:35:57 GMT

De Certificate Authority rol in Server 2008 (ook in 2003) geeft standaard geen certificaten uit met subject alternative names (SAN), welke vaak nodig zijn in de nieuwere producten van Microsoft zoals Exchange 2007, System Centre Configuration Manager 2007 en Office Communications Server 2007.

Hier is een oplossing voor. Om SAN te enablen in Server 2008 gebruik je de volgende commando's:

certutil –setreg policy\SubjectAltName enabled8
certutil –setreg policy\SubjectAltName2 enabled8
net stop certsvc8
net start certsvc8

In Server 2003 is het:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME28
net stop certsvc8
net start certsvc8

Hierna zal je zien dat de SANs aanwezig zijn op je certificaten.

Microsoft Security Bulletin MS08-077 - Important

mpriem — Wed, 10 Dec 2008 21:54:00 GMT

***UPDATE*** Servers met October of December rollup hebben de fix niet nodig.

Gisteren is het nieuwe security bulletin verstuurd. Deze maal bevat het een fix voor een Sharepoint lek die uitgebuit kan worden door een lek in een van de administatieve pagina's binnen sharepoint sites.

Het bulletin is hier te vinden: http://www.microsoft.com/technet/security/Bulletin/MS08-077.mspx
De fix details hier: http://support.microsoft.com/kb/956716
En natuurlijk de fix zelf: http://www.microsoft.com/downloads/details.aspx?familyid=a7fda284-273c-42ab-8188-433beaacca86&displaylang=en

Een workarround voor dit lek is de volgende:

Block malicious HTTP requests using a firewall

Configure your firewall, such as Microsoft ISA Server, to block all HTTP requests to your SharePoint site that contain "mode=ssp" in the URL, but do not contain "/ssp/admin/_layouts" in the URL.

Search results worden niet juist weergegeven door limiet op ACL grootte

mpriem — Wed, 22 Oct 2008 21:48:00 GMT

Onlangs ben ik voor de tweede keer een probleem tegen gekomen bij een klant waar de resultaten van Sharepoint Enterprise Search niet juist worden weergegeven door een limitatie van de buffer van de WIN32 API InitializeAcl functie, welke gebruikt wordt door de indexer wanneer deze de wijzingen bepaald voor de index.
Deze buffer is 64KB groot, wat inhoudt dat de ACL's op objecten in sharepoint niet meer entries mogen bevatten dan in de buffer opgeslagen kan worden.

Hoeveel entries zijn dat dan??? … Nou dat hangt er bijvoorbeeld vanaf hoeveel groepen een userobject lid van is, en wat het SIDhistory property op zijn/haar AD object voor waardes bevat. Daarnaast zijn er nog enkele andere eigenschappen van een security object wat de grootte van een enkele ACE bepaald.
Om het makkelijk te maken zou ik zeggen dat +-1000 entries teveel is.

Het maakt hier niets uit of je de gebruikers los hebt toegekent of eerst lid hebt gemaakt van een Sharepoint Group. De enige manier om te zorgen dat de indexer niet tegen het limiet aanloopt, is de gebruikers te organiseren in AD Groups en deze in de ACLs op te nemen.

Dit probleem geldt voor zowel Office Sharepoint Server 2007 als Sharepoint Portal Server 2003

De foutcode die de indexer geeft bij het crawlen van een item is PRTH_E_ACL_TOO_BIG (0x80041211L)

....

Process monitor is the Bomb!!

mpriem — Sat, 18 Oct 2008 14:38:00 GMT

Zojuist was ik bezig met het schrijven van een blogpost om de Microsoft Loopback Adapter te gebruiken in combinatie met Internet Connection Sharing om zo een 'NAT-achtige' structuur te maken voor mijn Virtual PC 2007 VM's. Dit omdat de NAT functionaliteit van VPC, de VM's niet toestaat onderling te communiceren.

Ik had dit al eerder gedaan op XP machines, maar er zit een valkuil in de procedure voor Vista, welke ik documenteren op mijn blog. Echter...toen ik eenmaal zover was om ICS te gaan gebruiken kwam ik het volgende venster tegen:

...CRAP...$%#%$

duidelijk gevalletje Microsoft IT GPO... :)

Nu ben ik administrator op mijn laptop, dus ging dit policietje mij natuurlijk niet tegenhouden. Maar... Wat is precies de locatie van deze policy?? Er zijn honderden policysettings. Waar te beginnen??
Policysettings worden weggeschreven in het register. Voor user settings zijn ze te vinden in HiveKey Current User (HKCU) en voor computer settings in HiveKey Local Machine (HKLM). Bij het opstarten en periodiek worden de policy settings opgehaald vanaf het domain en weggeschreven in het register. Vervolgens worden ze uitgelezen door de applicaties waarvoor ze bedoeld zijn. Dit kan tijdens het opstarten zijn (een groot deel van de policies worden uitgelezen door EXPLORER.EXE (window manager) tijdens het opstarten), maar ook wanneer de functionaliteit die het betreft, gebruikt wordt.

Ik zou domweg door het register kunnen gaan spitten, maar zoals ik al aangaf, zijn er teveel plekken waar de setting zou kunnen staan. Ook zou ik de GPO settings lijst van Vista kunnen downloaden van http://www.microsoft.com/downloads/details.aspx?FamilyID=41dc179b-3328-4350-ade1-c0d9289f09ef&DisplayLang=en en de desbetreffende policy kunnen zoeken tussen de 2495 settings, maar dat is ten eerste niet leuk en ten tweede dacht ik sneller te werken op mijn eigen manier. En die manier is via Process Monitor van SysInternals.

Ik gokte dat de policy setting uitgelezen werd op het moment dat ik het property window opende van mijn netwerk connectie die ik wilde sharen.
Wat ik dus deed was Process Monitor starten in registry mode en het probleem reproduceren.
Vervolgens stopte ik de trace en gebruikte ik de 'Include Process from Window' optie om een filter te zetten op mijn trace.
Met het vizier kan je een window aanklikken, waarop Process Monitor bepaald welk process er bijhoort en het filter op de trace aanpast. Het venster behoorde tot een DDLHOST.EXE process wat het OS gebruikt om out-of-process applicaties zoals COM servers te hosten.
In dit geval was de command line syntax: C:\Windows\system32\DllHost.exe /Processid:{7007ACD1-3202-11D1-AAD2-00805FC1270E}.

Een snelle query in Component Services en het register laat weten dat het om de Network Common Connections Ui DCOM applicatie gaat, welke voornamelijk functies uit de NETSHELL.DLL gebruikt. Gezien de naam zou ik nu al zeggen dat we in de buurt zitten.

De volgende stap was om wat extra filters te zetten op de trace. Policies staan in het register altijd in een path wat de naam policies bevat. Ook moeten de read actie op het register de status SUCCESS hebben gehad om het mogelijk gemaakt te hebben de key uit te lezen. Zoals je in het venster rechts kan zien zijn er nu dus een aantal filters van toepassing.
De PID 5844 filter is gezet door de 'Include Process from Windows' functionaliteit en de Result is SUCCESS en Path contains Policies heb ik zelf gezet, wat mij de volgende resultaten geeft:

Zoals je ziet zijn er een aantal policies die uitgelezen worden. De 3 onderaan de trace hebben mijn aandacht. De NC_ShowSharedAccessUI en NC_AllowNetBridge_NLA zijn na onderzoek degene die ik moet hebben. De volgende stap is om in het register de permissies van de key die de settings bevat af te halen. Ik geef EVERYONE deny READ. In sommige gevallen wordt het je wat lastig gemaakt, maar door de Take OwnerShip priviledges van de Administators Group kunnen we deze permissies eigenlijk altijd zetten. De Deny Read zorgt ervoor dat de policy gezien wordt als NOT CONFIGURED. Het resultaat is dat ik dus de Internet Connection Sharing gewoon aan kan zetten.

Easy does it...

Zoals eerder gezegd kan het ook zijn dat de policies uitgelezen worden gedurende de boot. Gebruik dan de bootlogging optie van Process Monitor om erachter te komen om welke setting het gaat.

Natuurlijk is het niet de bedoeling GPO's te omzeilen, maar dit laat duidelijk zien dat GPO's geen enkele zin hebben als je toestaat dat je gebruikers LOCAL ADMIN zijn op hun laptops en werkstations.

Daarnaast is deze post voornamelijk bedoelt om te laten zien wat Process Monitor en ander tools van SysInternals voor geweldige hulpmiddelen zijn, die niet mogen ontbreken in de toolset van een SysAdmin...