Jun 6th, 11
So we have this wonderful application, “Crystal Reports Server 2008 V1″. Property of SAP, fomerly property of “Business Objects”, formerly property of Seagate Software, formerly… nevermind.
CR Server claims to run on IIS, so we had hoped to deploy the new version without needing to add the usual pile of unmaintainable WAMP cruft. Unfortunately, it turns out there are bits of it that out-and-out require a J2EE web server, such as Tomcat. Rather than manage IIS and Tomcat, We are just going to run with the cat. Good decision? Meh…
Here is the quick-and-dirty on some simple security measures we took to protect the app:
- Remove the sample and documentation webapps from the Tomcat server “webapps” directory. Delete jsp-examples, servlet-examples, tomcat-docs. Consider also removing ROOT, balancer, webdav, if not needed by your application.
- Use the java “keytool.exe” to create a java keystore. Create web server key pair in the keystore, then generate a CSR from the pair. Have the CSR signed and import the signed cert back into the same keystore alias. The best doc on CSR generation and import is probably this one:
But note that you may need to specify a “keyAlias” parameter in your Tomcat server.xml , if you did not use the alias “tomcat” when generating your key. This tidbit is not in the documentation.
Also note that you likely will need to add the parameter “-keylength 2048″ to your “genkey” command, if you want to ensure a key length of at least 2048 bits (most modern CAs will not issue a cert less than this length). Additionally, you can add the “-storepass” parameter towards the start of your command string to help with automation of future commands within the same shell session.
- Using the same doc as above, update the stanza in the Tomcat server.xml to use TLS. In the stanza, include the following additional parameter:
ciphers="SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"
This will prevent the use of weak cryptographic ciphers.
- To the Tomcat web.xml config file, add a “security-constraint” stanza, as documented here. (can’t post the code directly to stupid wordpress because it clobbers XML.)This will enforce the use of SSL for all web apps running in tomcat.
- If you want a redirect from standard HTTP port 80 to the secure port, add a second connector stanza to “server.xml”, with the following parameter:
Apr 28th, 11
After many years of saying that we should do it, we have purchased a third-party patch management solution. The good folks at Secunia cut us a great deal, and we are not in the process of deploying Secunia CSI, which will be integrated with our existing WSUS (Windows Server Update Service) instance. Here are some notes on the installation process:
WSUS SSL Configuration:
Secunia CSI uses the “System Center Update Publisher” (SCUP) API to publish third-party update packages into WSUS. SCUP requires that SSL be implemented in WSUS. Unfortunately, we had not done that yet, so there was some work to be done before we could even connect the CSI console to our WSUS server.
- Group Policy for Windows Update needed to be updated point clients to the HTTPS version of our WSUS host.
- The WSUS host had to be reconfigured to require SSL for the “ApiRemoting30″, “ClientWebService”, “DssAuthWebService”, “ServerSyncWebService”, and “SimpleAuthWebService” IIS virtual directories. Also, WSUSUtil needs to be run to signal the update service to use SSL, as documented here:
- After making these changes, we found that the WSUS management console and Secunia WSUS integration utilities were failing to connect to WSUS (fontunately, Windows Update clients were not having this problem). The management utilities were reporting “access denied” messages, which apparently were related to authentication failures. This fix for this was not obvious, not did we find it documented anywhere. Since our WSUS server is using an externally-refereneable “Internet” DNS name, we found that we also needed to set an SPN for the service that was running WSUS (in this case, the Network Service). The command follows:
setspn.exe -A http/[wsusDnsName] [wsusHostName]
(where wsusDnsName is the DNS name on the WSUS server SSL certificate, and wsusHostName is the short computer name of the WSUS server Active Directory account. You can verify that the SPN was added successfully using “setspn -L [wsusHostName]
Secunia CSI Signing Certificate Configuration:
Microsoft’s SCUP API requires that a code signing certificate is present in WSUS for the signing of packages imported into WSUS. The Secunia CSI console will create a self-signed certificate for this purpose, but the cert will have a non-configurable 512-bit key length, and this cert will have to be pushed to the “Trusted Publishers” store of every WSUS client. I prefer to use our AD CA Servers to generate a Code Signing cert. This scenario is supported by Secunia, but it is not well documented. Here is what we needed to do… it was not fun:
- On our CA server, create a new Certificate Template by cloning the “Computer” template, and making the following selections:
- Select “Server 2003″ as the compatibility level for the template. “Server 2008″ templates apparently are not compatible with the SCUP API (or so I have read, and I see no reason to take chances).
- Set the minimum key size to “2048″ or longer.
- Set “Subject Name” to “Supply in the request”. Corresponsingly, you should set “Issuance Requirements” to “CA certificate manager approval”. Under “Extensions”, select “Application Policies”, and add “Code Signing”. Remove all other policies.
- Under “Security”, add the computer account of the WSUS server, with Read and Enroll rights.
- Configure the CA to issue certs from this new template.
- Use the Certificates MMC on the WSUS server to request a code signing cert for the local computer account. Failing this, you can assign rights to the template to a user account, then use the CA web interface to request a certificate. You then can transfer the cert to the local computer account cert store.
- The CSI certificate import tool is pretty fussy about the certificate format, and the requirements of the tool are not documented. We found the following requiments, once met, allowed for successful signing of packages:
- The certificate needs to be exported to a “pfx” file (PKCS #12 format) before import via CSI
- The PFX file must contain only the signing cert, and no other certificates in the signing cert chain.
- The PFX file must not be passphrase protected.
So what are we to do? The certificate management GUI on windows does not allow the export of PFX files with no passphrase! The solution is found in “CertUtil.exe”:
- Use “certutil -store” to list the certs in the system account personal certificates store. Identify the serial number of the code signing certificate.
- Use “certutil -exportpfx My [CertSerialNumber] [exportFileName] NoChain,NoRoot”
- Now import the PFX file that you just created using the CSI Console. It should work, unless I have missed something else important.
CSI Console Configuration on Server 2008:
Server 2008 / 2008 R2 security settings will cause some problems for the CSI console, unless you make the following configuration changes, as documented in the CSI FAQ, here:
- Add https://csi.secunia.com to your “Trusted Sites” intenet security zones (in the Internet Settings control panel).
- In Internet Options → Advanced → Scroll to Security → Uncheck ‘Do not save encrypted pages to disk.
Dec 2nd, 10
NOTE: This article has been updated with a correction to the NetSH commands. Previously I documented the “forwarding” should be enabled on the interfaces, but “weak host receive” and “weak host send” is more accurate, as documented here:
Recently we had a problem with a web applicaiton configured for SSL-offload on our Load Balancers. Our F5 Guru (Ben Coddington) recommended that we swich to a “Layer 4 forwarding” configuration. In this mode, the F5 will forward TCP packets from the client directly to the web server without altering packet content, which is just what we needed.
Making this work on Server 2008 took a bit of extra leg work, though. Here are the bones of it:
- On the F5, create a new Virtual Server using the Type category “Performance (Layer 4)”. Make sure that address translation and port translation are disabled.
- Create a new F5 Pool that uses a simple port 443/ssl health monitor. You could use any of a number of load balancing methods, but I cose “Round Robin” because it is in keeping with the “simpler is better” school of thought.
- On the Server 2008 system, add a “loopback adapter” in the Device Manager. (At the root of the MMC console, right-click the computer and select “Add legacy device”. It will be of type “network adapter”, from manfacturer “Microsoft”, and have a name containing “loopback adapter”).
- Assign the load balanced IP to the loopback adpater with netmask “255.255.255.255″.
- Here is the trick… you must now allow “weak host receive” on all network interfaces involved with load balancing on the Server 2008 system, and “weak host send” on the loopback interface. If this step is skipped, the Windows server will drop all packets destined for the load balancer address:
- Make sure you have a vaild SSL certificate configured on all RDGateway systems in your farm.
That’s about it… The F5 will forward all packets sent to the load balanced IP to the next pool member in the rotation (barring persistence). The Server 2008 host will receive the packet, and forward it to the loopback adapter (following TCP/IP routing logic). The Server 2008 host will reply directly to the client. Amazingly, it all seems to work.
Feb 13th, 09
So, you have a site that needs to to run over SSL-only (shouldn’t they all?)? You don’t trust your clients to type that ever-important “s” after “http” (and why would they?)? You think they will get scared off by those “Secure connection required” error pages (they will!)? You are not running IIS7 (who is?)? Not using ASP.NET?
Codplex to the rescue! The venerable “Ionic URL Rewrite” ISAPI filter has been updated, and published on Codeplex:
IIRF now supports the ability to return URL redirects, in addition to simple rewrites. To use IIRF to redirect a non-SSL URL to a secure version, follow the installation instructions included with IIRF. Then:
- Stop your production IIS site from listening on port 80 and enforce SSL usage.
- Make sure that the production site is not using host headers that would override your port settings.
- Set up a secondary IIS site which listens on port 80 only. Add the IIRF ISAPI filter to this site.
Here is some sample entires you could use in the IsapiRewrite4.ini configration file to accomplish the redirect. Note that [R] instead of [R=301] also works, but this performs a 302 “Temporary” redirect. Conceptually I prefer a 301 (not that it matters because search crawlers are not hitting our Intranet sites):