RDP Connection Errors and TLS/SSL Hardening

A customer was trying to harden its Windows 2008 R2 server, based on findings from SSL Test that recommends he disable any use of SSL 2.0 and TLS 1.0 on IIS server.

The problem is that once you restrict these protocols, you will almost certainly break RDP.

On the server Event Viewer you will see the following event from the Scannel source:

A fatal error occurred while creating an ssl server credential. The internal error state is 10013

By default, Windows 2008 R2 remote desktop host is configured to Negotiate the use of either its internal RDP Security Layer OR the SSL/TLS 1.0.  In this mode both RDP client and server fallback to a protocol they both support.

Please check the setting under: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server\

If Enabled=0 than you have found the source to the problem. But not the reason…

The reason is that the Negotiate settings in Remote Desktop server doesn’t really work… What you need to do is EXPLICITLY select  the “RDP Security Layer” under the Security section of the General Tab of the Remote Desktop Session Host Configuration (see picture)

Masquerade WordPress WP_SITEURL for CloudFlare/Incapsula for Dome9 Integration

Services like CloudFlare and Incapsula are great. Fast, easy and affordable web application protection and acceleration for you hosted sites. However, things can get complicated when you combine them with forcing WordPress administration through SSL and enabling SSL only on demand via Dome9, you would force all & any Login/Authentication/Administration type access to be done through SSL, using https on port 443. Assuming of-course that you haven’t purchased  the SSL options by the services and  use a self-signed certificate on your WordPress server.

When you add support for CloudFlare or Incapsula web application firewall services you need to split the https for the http domains as you wouln’t mind hnadling with the SSL trafic directly as its protected by Dome9 anyway

This means that your main site address in WordPress (WP_HOME) would stay http://WWW.mysite.com and the direct url (WP_SITEURL) configured to http://DIRECT.mysite.com.

Now, when accessing either WWW or DIRECT for /wp-admin we are redirected to an HTTPS connection over the same URL – in the WWW case we will be routed to an https://WWW.mysite.com which is not routed to our machine, but protected by Cloudflare or Incapsula. In the case of DIRECT we will be routed to https://DIRECT.mysite.com which would work when we have the HTTPS port open on our Dome9 account.

Important caveat: as we changed WP_SITEURL to http://DIRECT.mysite.com we need to disguise it so hackers wouldn’t know our direct url so they could bypass CloudFlare/Incapsula filters, for that we need to add the following to our wp-condig.php This would ensure that non https and non direct request would be pointing the protected URL: http://WWW.mysite.com

// Masquerade WP_SITEURL direct URL
if ($_SERVER['HTTPS'] != "on" &&  $_SERVER["SERVER_NAME"] != "DIRECT.mysite.com" ) define('WP_CONTENT_URL', 'http://WWW.mysite.com/wp-content');

Thanks Justin Korn for the insight.

Welcome Cloud Riots

We have been playing with Clouds for quite sometime, trying to secure them as best as we can.

The fun part is that this cloud is sooooo young – taking its baby steps. An immature set of tools with limited interoperability, that the aren’t even as cheap as you may have thought they would be. But that’s why its so fun, right?

So we decided to document the fun parts and share them with the world. Sometime the marketing honchos will try and get their word out, but we will try to limit their brilliant messages with limited success (they claim to have been paying the bills…)

So take a seat, follow us on http://twitter.com/cloudriots and join the conversation!