December 2005

One of the strengths of the WatchGuard Firebox series of firewalls is the inclusion of application-layer proxies for protocols such as SMTP, FTP, and HTTP.  Whereas ordinary packet filtering firewalls and stateful inspection firewalls only control traffic based on IP address or TCP/UDP port number, application-layer proxies like those included in the Firebox look deeper into the packet to make decisions on information such as URL or MIME content type (for an HTTP proxy, for example).

However, this advantage also becomes a disadvantage as many application-layer proxies may not understand or be compatible with protocol-specific extensions.  In this particular case, it’s the iDisk service provided by Apple’s .Mac subscription service.  The iDisk service uses WebDAV, an extension of the HTTP/1.1 protocol specification.  It appears that, in general, most WebDAV services operate properly through the Firebox’s HTTP proxy (although some issues with Microsoft Exchange’s Outlook Web Access were reported with earlier versions of the WatchGuard Firebox System software).

The iDisk service, though, apparently uses some non-RFC-compliant headers (note that this was not confirmed with a packet capture).  As a result, the Proxied-HTTP service (which employs, as the name suggests, an application-layer HTTP proxy) prevents these headers from being passed and therefore prevents iDisk from working.

To make iDisk work from behind a WatchGuard Firebox firewall, one of several steps must be taken:

• Use the Filtered-HTTP service, which does not employ an application-layer HTTP proxy and therefore would not interfere with iDisk or other WebDAV-based applications or services.
• Modify the default properties of the Proxied-HTTP service to allow unknown headers.

Since the Proxied-HTTP service also provides for content filtering and reporting, it is generally preferred to use the HTTP proxy instead of an ordinary HTTP packet filter.  The first option is therefore not the ideal solution.

Fortunately, the behavior of the Proxied-HTTP service is somewhat configurable.  In order to make iDisk work with the HTTP proxy, the “Remove unknown headers” option must be unchecked in the configuration for the HTTP proxy.  By unchecking the “Remove unknown headers” option, the Firebox will allow non-RFC-compliant HTTP headers to pass through the firewall, and iDisk will work correctly.

A few days ago I mentioned Kubuntu 5.10.  Kubuntu is the KDE-based variant of Ubuntu.  After having installed and used Kubuntu, I decided to try Ubuntu, the GNOME-based cousin.  I downloaded the ISO image of the install CD last night and installed it today while reviewing HSRP configurations for an upcoming Cisco installation.

I am equally as pleased with Ubuntu as with Kubuntu.  I find that version 2.12 of GNOME, which ships with Ubuntu, is much better than the older versions of GNOME that I had used.  In addition, the overall fit and finish of the distribution is very good, and I continue to enjoy using apt-get to update and upgrade packages on the system.  As a matter of fact, the only downside to either distribution so far is that Kubuntu doesn’t include Firefox by default (note that Firefox is included with Ubuntu).

So, I currently have two older Compaq Armada E500 laptops that I’ve loaded with Linux—one is running Kubuntu, and the other is running Ubuntu.  Both work flawlessly, including full interoperability with my wireless network.

Earlier this year, I had a need in a project to set the password for a large number of Active Directory accounts simultaneously.  Here’s the solution I came up with for this particular need.

To use this technique, you’ll need ldifde (included with Windows Server 2003), grep (included with Mac OS X and most Linux distributions; Win32 versions available on the Internet), a text editor with search and replace functionality (advanced geeks are free to use sed), and dsmod (from the Windows Server 2003 Resource Kit).

First, export the list of user accounts out of Active Directory using ldifde.  The command will look something like this:

ldifde -d “CN=Users,DC=company,DC=com” -r “(objectclass=user)”
-f c:\export-1.ldif

This creates a file called “export-1.ldif”.  Using grep, filter this file down to only the full distinguished names of the users:

less export-1.ldif | grep 'dn: ' > export-2.ldif

Note that you’ll need to use “type” instead of “less” on a Win32 system.  Also, on a Win32 system you’ll need to use double quotes instead of single quotes in the grep command.  This creates a file called “export-2.ldif”.

Load this file into the text editor and make the following changes:

• Remove all occurrences of “dn: ” (there is a space after the colon)
• Add a double quotation mark before CN= at the start of each line
• Add a double quotation mark after =com at the end of each line

Save this modified file as “export-3.ldif”.

Finally, pipe this file through to the dsmod program to set passwords for all the users in the file:

type export-3.ldif | dsmod user -pwd newpass1 -mustchpwd yes

Full help for the dsmod command line syntax is available using “dsmod /?” or “dsmod user /?”.

You can add “ > filename” to the end of the above command to log the output of the dsmod command to a file.  You can then use grep to parse this file to ensure that the command was successful for all users.

A short while back, I posted an article on Cisco PIX VPN and Active Directory integration.  Now, I’d like to follow that article up with a version looking at integration between Active Directory and WatchGuard Firebox VPNs.

As with the PIX-AD integration document, this article assumes that you have some basic knowledge of how to work with the WatchGuard Firebox series of firewalls.  This article was written using version 6.2 of the WatchGuard Firebox System software and Windows Server 2003; other versions of either the firewall software or Windows should be similar.

Configuring the Firebox

First, we’ll need to setup the Firebox.  Use the Firebox software (Policy Manager, specifically) to perform the following configuration tasks:

• Add the server that is running IAS (or will be running IAS; see below) as a RADIUS server in the Authentication Servers dialog box (found on the Setup menu).  Here, you’ll need to specify the server’s IP address, port number (the default of 1645 will be fine), and the shared secret.
• Instruct the firewall to use RADIUS by going to Setup > Firewall Authentication and selecting “RADIUS” as the authentication type.
• Configure the firewall’s Remote User VPN (on the Network menu) to use RADIUS by checking the “Use RADIUS to authenticate remote users” check box.

Once this is done, proceed with configuring PPTP-based remote user VPNs as usual.  Be sure to add a rule allowing traffic to/from the pptp_users group; otherwise, VPN users will be subject to the same traffic restrictions as Internet users.

Configuring Internet Authentication Service

Before doing anything else, create a new global security group in Active Directory.  Call it “pptp_users”, just like the name of the group on the Firebox.  This is an important part of the glue that will bind the Firebox together with Active Directory.

If IAS is not already installed, install IAS using the Add/Remove Programs icon in Control Panel.

Once it has been installed, launch it from the Administrative Tools folder on the Start Menu and we’ll proceed with configuring it for authenticating VPN connections to the Firebox.

First, we need to grant IAS permission to read dial-in properties from user accounts in Active Directory.  To do this, right-click on the “Internet Authentication Service (Local)” and select “Register Server in Active Directory”.  Select Yes (or OK) if prompted to confirm.  Note that if IAS was already installed, it may have already been registered with Active Directory as well.

With that done, we can now configure the Firebox as a RADIUS client.  Right-click on RADIUS Clients and select New RADIUS Client.  In the wizard, specify the IP address (or DNS name) of the Firebox’s trusted interface and the shared secret.  Note that this shared secret is the same secret key specified when configuring the RADIUS server in the Firebox previously.  RADIUS clients use this to authenticate to RADIUS servers, so make it a reasonably strong password.

Now create a new remote access policy.  Right-click on Remote Access Policies and select New Remote Access Policy.  In the wizard, specify a name, select to create a custom policy, and then add the following conditions to the policy:

• NAS-IP-Address:  This will be the IP address of the Firebox’s trusted interface.  This helps to ensure that this policy only applies to VPN requests from this firewall and not from any other RADIUS client.
• Windows-Groups:  This should be the “pptp_users” security group created earlier.  Any user that should be allowed to authenticate on a VPN connection will need to be a member of this group.

Of course, this policy should grant access.  On the next screen, select “Edit Profile” to edit the remote access profile.  This is important because we’ll need to verify that the RADIUS server is passing the correct information to the Firebox.

On the Advanced tab, remove all the attributes listed there (Service-Type and Framed-Protocol are there by default) and then add the Filter-Id attribute.  To this attribute, add the string value “pptp_users”.  Click OK to save these changes to the profile and then finish creating the policy.

Make this policy the first policy (using the Move Up/Move Down commands in the IAS console), add a user to the group created earlier, and then test your connection.  Remote systems attempting to connect via PPTP should now be able to authenticate the VPN connection using their Active Directory usernames and passwords.

UPDATE:  I’ve updated this entry to correct some errors pointed out in the comments.  Thanks for the feedback!

There’s been a few updates to this weblog over the last few days.  Nothing major, just a few minor changes here and there.

First, I’ve moved to showing excerpts only on the index page.  Of course, the archives pages (both category archives as well as monthly archives) were already showing excerpts only.  Note that RSS feeds are still showing the full content.

The full entry page (the “single page,” in WordPress parlance) now shows the sidebar as well.  It seems to me that this makes navigation through the weblog a bit easier.

I’ve already mentioned the link to automatically post an entry’s URL to del.icio.us; this link only shows up when reading the full post.

Outlook Web Access (OWA) is the web-based interface for accessing e-mail and other resources handled by Microsoft Exchange.  Unfortunately, OWA’s popularity also makes it the target of numerous worms and security exploits.  As a result, many organizations seek to deploy OWA behind a reverse proxy that can help shield OWA from web-based attacks and exploits.  In this posting, I’m going to share information to help build a reverse proxy using Apache 2.0.

Here’s a skeleton of an httpd.conf file to support Apache as a reverse proxy in front of OWA:

NameVirtualHost 1.2.3.4:80
NameVirtualHost 1.2.3.4:443
ProxyRequests Off

<VirtualHost 1.2.3.4:443>
ServerAdmin webmaster@domain.com
ServerName webmail.domain.com
DocumentRoot /var/www/webmail
RequestHeader set Front-End-Https “On”
ProxyRequests Off
ProxyPreserveHost On

SSLEngine On
SSLCertificateFile conf/webmail-ssl-cert.pem

<Location /exchange>
ProxyPass http://mail.domain.com/exchange
ProxyPassReverse http://mail.domain.com/exchange
SSLRequireSSL
</Location>

<Location /exchweb>
ProxyPass http://mail.domain.com/exchweb
ProxyPassReverse http://mail.domain.com/exchweb
SSLRequireSSL
</Location>

<Location /public>
ProxyPass http://mail.domain.com/public
ProxyPassReverse http://mail.domain.com/public
SSLRequireSSL
</Location>

</VirtualHost>

The key portions of this configuration are described below, along with some supporting information.

• NameVirtualHost:  The NameVirtualHost directive enables Apache to use name-based virtual hosts on the specified IP addresses and ports.  The parameter to the NameVirtualHost directive must match one of the VirtualHost definitions, as shown in the sample configuration, or else the content will be served from the default virtual host (the first virtual host listed in the configuration).  Note that if the Apache reverse proxy will not be using name-based virtual hosts (instead using IP address-based virtual hosts or running only a single server instance), then this directive is not required.
• RequestHeader:  This directive instructs Apache to add a header “Front-End-Https: On” to requests sent to the internal OWA server.  This header is proprietary to OWA and forces OWA to build URLs using “https://” references instead of ordinary “http://” references.  This directive is required in order to terminate the SSL tunnel at the reverse proxy and use clear-text HTTP between the reverse proxy and the internal OWA server.  This directive requires the mod_headers module.
• ProxyPreserveHost:  This directive configures Apache to pass the original host header, supplied by the client, to the server to which the request is being proxied.  (This is instead of the host name supplied in the ProxyPass directive.)  Again, this facilitates the construction of URLs with the correct hostname when accessing resources inside OWA.
• SSLCertificateFile:  Apache expects the web server’s SSL certificate to be in PEM format.  If the certificate’s key is encrypted, Apache will prompt upon startup for the passphrase to the key (this prevents any form of automated startup).  It is considered a security best practice to keep the key in a separate file (using the SSLCertificateKeyFile directive) in encrypted form and supply the password upon the startup of Apache.

With this configuration in place, the following benefits are realized:

1. Name-based virtual hosts are supported. This allows other URLs to also be proxied through this same reverse proxy server.
2. SSL encryption is offloaded from the Exchange server to the reverse proxy server. Traffic from the reverse proxy server itself to the Exchange server is standard, unencrypted HTTP.
3. When used in conjunction with mod_security (another Apache module), OWA is protected against a very significant majority of all web-based attacks.

Using Apache to serve as a reverse proxy for OWA is a cost-effective way to add another layer of security to an Exchange-based messaging infrastructure.

In my various adventures with replacing Windows-based servers with Linux servers, I have had need on several occasions to take an SSL certificate (generated using Microsoft Certificate Services) and make it available to a Linux-based server.  In some cases, it was to be used by the SSL wrapper Stunnel; in others, it was for Apache.

In either case, the certificate needed to be in the PEM (originally Privacy Enhanced Mail, now a standard for encoding certificates) format.  Windows, on the other hand, typically uses the PFX (PKCS #12) format for storing certificates.  To prepare certificates for use on Linux, the certificates must be converted to PEM format.

In the hopes that this information might be useful to others, here’s a process for converting from PFX to PEM using OpenSSL.  With the exception of only a few items, the process is identical on Linux, Mac OS X, and Windows 2000/2003.  These steps were confirmed using OpenSSL 0.9.7a on Red Hat Linux 9.0, using OpenSSL 0.9.6i on Mac OS X 10.2.8, and OpenSSL 0.9.7c on Windows Server 2003.

1. If the certificate is not already available in PFX format, use the Certificates MMC snap-in to export the certificate and the corresponding private key to a PFX file.  Be sure to note the passphrase used to protect the PFX file; it will be needed later.  If the certificate (and its corresponding private key) is already available in PFX format and the passphrase for the PFX file is known, proceed to step 2.
2. At a terminal prompt, type “openssl pkcs12 –in pfxfilename.pfx –out tempfile.pem”. This will convert the PFX file to a PEM file.  The OpenSSL toolkit will prompt for the import passphrase; this will be the passphrase specified in step 1.  A PEM passphrase will also be needed; make note of the passphrase used here (it will be needed later).
3. Using a text editor (such as vi on a Linux system, or Notepad on a Windows system), split the encrypted RSA private key and the certificate into two separate files.  Remove all extra text, leaving only the text between the lines with the dashes.  Make note of the filenames; they will be needed later.
4. The RSA key is currently encrypted; this will an automated launch for the application using the certificate.  It will be necessary to decrypt the RSA private key.  To decrypt the RSA private key, use the command “openssl rsa –in encryptedkey –out decryptedkey” (where encryptedkey is the file containing the RSA private key, as separated in step 3, and decryptedkey is the file that will contain the decrypted RSA private key).  The OpenSSL toolkit will prompt for the RSA key passphrase; this will be the passphrase specified in step 2.
5. On Linux or Mac OS X:  To concatenate the decrypted RSA private key and the certificate into a single file, use the command “cat decryptedkey certificatefile > finalfile.pem” (where decryptedkey is the decrypted RSA key produced in step 4 and certificatefile is the file containing only the certificate, as produced in step 3).
6. On Windows:  To combine the decrypted RSA private key and the certificate into a single file, use the command “copy /b decryptedkey+certificatefile finalfile.pem” (where decryptedkey is the decrypted RSA key produced in step 4 and certificatefile is the file containing only the certificate, as produced in step 3).
7. Edit the concatenated file (finalfile.pem from step 5) with a text editor to add a blank line between the decrypted RSA private key and the certificate, and a blank line after the end of the certificate.

At this point, the certificate is ready for use.  Be sure to guard the unencrypted private key with extreme caution; loss of this file can result in the compromise of your system.  Note also that most applications require that the certificates be owned by root and readable only by root (“chown root:root” to make them owned by root and “chmod 600” to make them readable only by root).

Kubuntu 5.10, the KDE-based variant of Ubuntu, normally comes with KDE 3.4.3.  With KDE 3.5.0 just recently released, however, I wanted to update Kubuntu to use the latest version of KDE.  Here’s what I had to do to make it work.

First, from this page, I downloaded and added the appropriate GPG key.  Once that was done, I used “apt-get update” to download the latest package information and “apt-get upgrade” to upgrade packages.  That upgraded most of KDE, but there were a few packages that still refused to upgrade (they were reported by apt-get as “held back”).

After poking around with apt-get for a while, I discovered that there was one missing file—libgnokii2—that couldn’t be found in the apt-get sources.  I manually reviewed the apt-get sources and finally found this package in the universe section of the main Ubuntu apt-get source.  I edited /etc/apt/sources.list to enable the other sections, then manually installed the missing file with these commands:

apt-get clean
apt-get update
apt-get install libgnokii2

I then edited /etc/apt/sources.list again to disable the other sources and upgraded the remainder of the KDE packages:

apt-get clean
apt-get update
apt-get upgrade

This last round of apt-get removed a few obsolete packages and then updated the remainder of the KDE packages.

I don’t know if this is the “correct” way of doing things, but it seemed to be the only way to make it work as anticipated.  If anyone has a better way, please let me know.

A few weeks ago, I locked down outbound HTTP traffic from my network.  All outbound HTTP traffic must now pass through a caching HTTP proxy.  (The proxy also performs some content filtering so that the kids don’t access stuff they shouldn’t.)

In my recent experiments with Kubuntu, I needed to download some small files using wget, but couldn’t because of the proxy.  As it turns out, there is a really simple fix.

Simply set an environment variable called http_proxy to the correct URL of the outbound proxy server, e.g., ‘http://proxy.company.com:8080′ or whatever.  In the bash shell, this can be easily accomplished with this command:

export http_proxy=“http://proxy.domain.com:8080”

Once this environment variable was set properly (I messed up a couple of times trying to set it, getting my bash syntax confused with my tcsh syntax), wget and apt-get worked like a charm.  I haven’t yet tried this with yum on Fedora Core 3, but I anticipate that it will work there as well.

After wrestling with installing, configuring, and supporting Fedora Core 3 on an older Compaq Armada E500 laptop, I decided to break with my Red Hat/Fedora legacy and try Kubuntu, the KDE-based Ubuntu variation.  Ubuntu itself is a relative newcomer to the Linux distribution arena, based on (as I understand it) Debian.

In previous stints using Linux as my desktop OS, I’d always been partial to KDE instead of GNOME.  Some would say that it’s because KDE has traditionally been more “Windows-like” than the other Linux graphical environments; perhaps that’s the case.  I’ve typically found KDE easier to work with, and since this laptop would eventually be used by the kids I felt like ease of use was important.

The install went very quickly and very smoothly.  When the install was done, I then proceeded to update KDE to version 3.5.0 (which had just been released a few days before).  Along the way, I learned a handy piece of information about HTTP proxies and command-line utilities (I’ll soon post information on that as well).  Eventually, I managed to get apt-get to download and install the updated KDE 3.5 packages.  I rebooted the system and found that I was now running the updated version of KDE.  (Side note:  There are still some KDE packages that won’t upgrade for some reason; I’m currently working on resolving that issue.)

It’s still too early to tell for certain, but I may just have found a new desktop Linux version.