Apache

You are currently browsing articles tagged Apache.

One of my projects over the Christmas holiday has been to rebuild the home network. You’d think I’d want to avoid that sort of thing since I’ve been on vacation from work for the past two weeks, but working on a home network is a different sort of beast than working on a network for a company. There are different challenges to be addressed.

My primary goals for this “home network rebuild” were the following:

  1. Rebuild the home server with a newer version of Linux, and possibly switch to a different distribution.
  2. Continue to provide DNS, DHCP, HTTP, and HTTP proxying/content filtering services to the home network.
  3. Continue to provide file sharing services via Server Message Block/Common Internet File System (SMB/CIFS) for Windows-based systems on the home network.
  4. Continue to have a shared music library available via Digital Audio Access Protocol (DAAP, aka iTunes) available to all systems on the home network.
  5. Provide file sharing services to Macs on the network via AppleTalk Filing Protocol (AFP) over TCP.

Ideally, I also wanted to enable Time Machine backups from my Mac laptop to the home server.

After doing a fair amount of research, I settled on the use of Ubuntu 8.04 LTS (“Hardy Heron”) for the server build. I didn’t go with Ubuntu 8.10 (“Intrepid Ibex”) simply because a) I already had 8.04.1 downloaded and burned to a CD; and b) Hardy Heron is an LTS release, so I should have better support over the long term.

I won’t bore readers with the details of the rebuild, but it took about a day or two to get a larger hard drive installed, Ubuntu installed and configured, and services running like DHCP (including some static reservations for certain computers, like my laptop and my iPhone), DNS (using MaraDNS, much easier to figure out than BIND), Apache, and Squid with SquidGuard. At this point, I’d completed tasks #1 and #2.

On to task #3. This was pretty simple and straightforward and easily accomplished via Samba, with nothing really unique to document here. The one interesting thing that I did find was a way to map the long usernames that Mac OS X uses (like “Bob Jones”) to a short username (like “bjones”). I used this command in the /etc/samba/smb.conf file:

username map = /etc/samba/usermap.conf

In this file, I simply placed lines that mapped the long usernames to the short usernames. Since Mac OS X defaults to the long username when connecting to the server, this allows me to simply type in a password and connect. I searched for hours trying to find a way to have Mac OS X supply my current password to the Samba server so that I wouldn’t get prompted, but could not find any information. If anyone knows the trick, I’d love to hear about it. After configuring a few shares, setting Linux permissions and the umask, and then testing from both my Mac laptop and a Windows laptop, task #3 was finished.

Task #4, providing an iTunes-compatible music server, was also really straightforward and easy. For this, I again selected Firefly Media Server, formerly mt-daapd, which I’d used before with great success. Again, nothing unusual or unique to document here, except for the potential interaction with Avahi (more on that later).

The final task was installing Netatalk to provide AFP over TCP file sharing services for Macs on the network. Fortunately for me, one of the sites I’d been using to help in my project pointed me to this blog post, which had a prebuilt package for Netatalk that included the necessary SSL support that Mac OS X requires. That saved me the trouble of compiling Netatalk from source. Following the steps in the Kremalicious article as well as information from this guide, I configured Netatalk to present a volume to use for Time Machine backups. It was at this point that I noticed a strange interaction with Avahi.

Avahi is a multicast DNS (what Apple calls Bonjour) server for Linux. It’s responsible for advertising services to multicast DNS-enabled systems, such as other Linux systems running Avahi or Macs. I’d installed Avahi earlier and used some service definitions from this article and this blog post to advertise Samba and HTTP. In addition, after installing Firefly, I’d noticed that Firefly starting advertising its presence automatically through Avahi with no service definition required.

Upon installing Netatalk, I also noticed that Netatalk started advertising automatically via Avahi as well, but using the IP address of the server. In order to be able to control how Netatalk advertises via Avahi, I had to change this line in /etc/avahi/avahi-daemon.conf:

enable-dbus=no

The suggestion for this change came from this thread on the Ubuntu Forums. Upon making the change and restarting Avahi, the odd Netatalk entry went away, but so did Firefly! To advertise both Netatalk and Firefly, I added a couple of files to /etc/avahi/services:

afpd.service:

<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">Intrepid Time Machine</name>
<service>
<type>_afpovertcp._tcp</type>
<port>548</port>
</service>
<service>
<type>_device-info._tcp</type>
<port>0</port>
<txt-record>model=AirPort</txt-record>
</service>
</service-group>

daapd.service:

<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">Home Music Server</name>
<service>
<type>_daap._tcp</type>
<port>3689</port>
</service>
</service-group>

After placing these two files into /etc/avahi/services, the new services starting advertising immediately. By the way, you’ll note the extra “device-info” entry in afpd.service; that sets the icon that will be used by Macs when they discover this service. I made mine look like a Time Capsule by using the setting listed above.

During this work with Avahi, I uncovered a couple of interesting things:

  • I found that restarting the Avahi daemon is actually more problematic than just leaving it alone; in order to make it start advertising services again after a restart, you’ll have to open one of the files in /etc/avahi/services and then close it again. No changes are necessary to the file, but opening it will kickstart Avahi into service advertisement.
  • Advertising SMB/CIFS and AFP together with the same name caused my Mac to ignore the SMB/CIFS services and only use AFP. I had to separate SMB/CIFS and AFP into different entries. Since I was using AFP really only for Time Machine backups and SMB/CIFS for everything else, it wasn’t really a big deal.
  • Advertising SMB/CIFS and RFB (Screen Sharing, as outlined here) works fine together.

At this point, task #5 was pretty much complete. I had originally envisioned providing file sharing services to the same locations via both AFP and SMB/CIFS, but in the end—partially because of the odd issue with AFP and SMB/CIFS being advertised together as described above—settled for using AFP only for Time Machine and SMB/CIFS for everything else.

Along the way, I also configured screen sharing as outlined here, and it seems to work just fine. I have to leave an account logged in to the Ubuntu server, but I can just lock the screen when I’m not logged in remotely.

The last step was to enable Time Machine backups to the Ubuntu server via AFP. First, the hack to enable non-Time Capsule network backups (this should be all on one line):

defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1

I was then able to select the Ubuntu-hosted AFP volume for Time Machine backups. Attempting to run a Time Machine, backup, however, reported an error about being “unable to create the disk image”. Fortunately, a number of different articles pointed to the use of hdiutil to create the disk image, and that seemed to fix the problem. Time Machine is now backing up to the AFP volume, although I suspect I still have a few issues to work through (for example, it looks as though I have to keep the Time Machine AFP volume mounted in order for automatic backups to run).

So, when everything is said and done, I was able to achieve all my stated goals. The only outstanding issue that I haven’t yet figured out yet centers on automatic logins; for both AFP and SMB/CIFS, I get prompted for a password when connecting, even though I keep my password synchronized (manually) between my Mac and the Ubuntu server. Any tips on how to resolve that would certainly be appreciated.

Along the way, I found the following sites to be quite helpful. I’m sure there are others that I used along the way, and I apologize if I’ve failed to extend credit where credit is due.

Limit size of Time Machine backups on Time Capsule
Set up Time Machine on a NAS in three easy steps
Make Ubuntu a Perfect Mac File Server and Time Machine Volume
Five Guides on How to Integrate Ubuntu into a Mac OS X Network
Time Machine Wireless Backups without Time Capsule

Tags: , , , , , , ,

Apple iPhone

In case you’ve been hiding under a rock and haven’t yet heard (is that possible?), Apple today announced the iPhone:

http://www.apple.com/iphone

GSM/EDGE, Wi-Fi, and Bluetooth…runs an embedded form of OS X…super-slick user interface…it’s enough to make a gadget geek like me salivate.

If the iPhone works half as well as claimed, it will be a tremendous device.  If it works as well as claimed, it will be a revolutionary device.

So, yes, I don’t technically need one…but I sure would like to have one.

Tags: , ,

I’ll break the information down according by the article to which the information pertains.  If the information pertains to all the articles equally, it is included in the “All Articles” portion.  Links back to the original articles are included.

All Articles

User Accounts vs. Computer Accounts

One thing in common across all these articles is the need to create special accounts in Active Directory. I originally recommended the use of computer accounts, but over the course of time additional integration tasks with Kerberos have led me to believe that the user of user accounts, not computer accounts, is the best way to handle this.  In a very early Linux-AD integration article, I discussed the use of computer accounts instead of user accounts, and the use of the ktpass.exe command to extract a keytab from a computer account.  At that time, it seemed reasonable to recommend computer accounts—we were only discussing a single service principal (the host itself), and using a computer account made sense.

However, because of the fact that additional accounts will have to be created for additional service principals (for example, if you are interested in using Kerberos-based SSO with Apache) and because you can’t have multiple computer accounts with the same name, it’s just as well to use a user account with a naming convention that describes the purpose of each account.  For example, something like “host-fqdn” for the host/fqdn@REALM service principal (used for scenarios involving pam_krb5 and “native” Kerberos/GSSAPI authentication), and “http-fqdn” for the HTTP/fqdn@REALM service principal (used by mod_auth_kerb for Apache-Kerberos integration).  This provides an easy way to distinguish between these accounts, and allows for the multiple accounts that are required in these kinds of scenarios.

Finally, the use of user accounts will eliminate some spurious error messages that ktpass.exe generates when run against a computer account.  Note that these error messages are not substantive; things will still work with a computer account.  It’s just that ktpass.exe appears to have been intended to run against a user account.

Updated ktpass.exe Command Line

In addition, because of differences in the encryption types supported by Active Directory and many Unix/Linux implementations, I have found that using the “+DesOnly” switch with ktpass.exe seems to help.

An updated ktpass.exe, accounting for the change to a user account and the desire to use DES encryption types, would look something like this:

ktpass.exe -princ host/fqdn@REALM -mapuser DOMAIN\account
-crypto des-cbc-md5 +DesOnly -pass Password123 -ptype KRB5_NT_PRINCIPAL
-out c:\filename.keytab

Please note that this command, particularly the service principal name (as specified by the “-princ” parameter) is CASE SENSITIVE.  For example, the host SPN (i.e., “host/fqdn@REALM”) that is used by pam_krb5 and “native” Kerberos/GSSAPI authentication is lowercase.  However, the HTTP SPN (used by mod_auth_kerb with Apache) needs to be uppercase.  In both cases, the Kerberos realm (which should be equivalent to the Active Directory DNS domain name) must be in uppercase.

Linux-AD Integration (Pre-R2)

The original article is found here.

In addition to the switch from a computer account to a user account as described above, the only real change to this article pertains to the /etc/ldap.conf file that configures the nss_ldap library.  Remember that in almost all of these scenarios, we are using Kerberos for authentication and LDAP for account information, i.e., storing the information that would normally be stored in /etc/passwd.

The original article calls for /etc/ldap.conf to include this line:

nss_base_group dc=mydomain,dc=com

To help optimize LDAP traffic against Active Directory, change the /etc/ldap.conf as follows:

nss_base_group dc=mydomain,dc=com?sub?
&(objectCategory=group)(gidnumber=*)

(This should all be on a single line.)  This will help reduce the query load on Active Directory by limiting the types of objects for which searches will be issued; in addition, the “objectCategory” type is indexed, which also also greatly speed operations.

Speaking of indexing, if the pam_login_attribute is not modified (it defaults to uid), you’ll also need to index the uid attribute in order to avoid heavy CPU utilization and delays in responses from Active Directory.  This was mentioned in the updated Linux-AD R2 instructions.  Alternately, you can change the pam_login_attribute in /etc/ldap.conf to an indexed attribute, like sAMAccountName.

Last, you may find it useful to edit /etc/ldap.conf and change the gecos field mapping from name to cn (i.e., use “nss_map_attribute gecos cn” instead of “nss_map_attribute gecos name”).

Linux-AD Integration (R2)

The latest version of these instructions are found posted here.

Again, other than the change to a user account instead of a computer account (as described above), the changes mentioned in the previous section also apply here:

  • Changing the nss_base_group in /etc/ldap.conf
  • Changing the nss_map_attribute for gecos in /etc/ldap.conf
  • Changing the pam_login_attribute to an indexed attribute in Active Directory (such as sAMAccountName) or indexing the uid attribute

Otherwise, the revised instructions are reasonably accurate and seem to work pretty well.

Kerberos-Based SSO with Apache

This article is found here, and already incorporates most of the changes mentioned in this posting.  No suggested changes are needed at this time.

Solaris 10 and AD Integration

This article can be found posted here.

This one is a pretty recent article (published within the last week or so), and so already incorporates most of the changes suggested here.  The information that I don’t have yet, however, is exactly how to incorporate some of the other suggested changes.  For example, I’m not yet sure how to use the ldapclient command to modify the LDAP client profile (Solaris 10 doesn’t use nss_ldap by default) to include the refined group query.  I suspect that this command would work correctly:

ldapclient mod -a serviceSearchDescriptor=group:dc=example,dc=com?sub
?&(objectCategory=group)(gidNumber=*)

Of course, the ldapclient command syntax would change depending upon if this was an initial setup or a change to an existing setup.

Likewise, I’m not sure which login attribute the Solaris LDAP libraries are looking for—uid, sAMAccountName, or something else entirely?  If anyone with more Solaris 10 experience than me has the answers to these questions, I’d love to know.

As I continue to expand my knowledge of using Kerberos to integrate these various platforms and applications, I’ll post additional information here.  I know that a number of you have been posting questions in the comments for these various articles; keep the questions coming.  I may not know the answer right away, but I’ll sure do my best to find out!

Tags: , , , , , ,

The key to the magic here is the mod_auth_kerb module, which adds Kerberos authentication to Apache. This module not only allows Apache to use Kerberos on the “back-end,” so to speak, but also supports the SPNEGO and GSS-API stuff on the “front-end” that allow it to transparently authenticate users connecting with supported browsers, without ever prompting for a password.

Preparing Active Directory (Each Apache Server)

These steps need to be repeated for each Apache server that will authenticating via Kerberos to Active Directory.

  1. First, create a user account (not a computer account) for each Apache server. I highly suggest using a naming convention that supports a) the service principal(s) involved; and b) the name of the server. Since Apache will use the HTTP service principal, a name like HTTP-lnxservername would be good. The password doesn’t matter, but do be sure to check the “Password never expires” check box, and after the account is created specify a good description so that you’ll remember what this account is for in 6 months.
  2. For each account that was created, run the ktpass.exe command to generate a unique keytab for each account. The command will look something like this (substitute the appropriate values where necessary):
     
    ktpass -princ HTTP/fqdn@REALM -mapuser DOMAIN\account
    -crypto DES-CBC-MD5 +DesOnly -pass password -ptype KRB5_NT_PRINCIPAL
    -out filename

     
    Be sure to specify a unique output filename (so that you don’t overwrite files; each server/account will needs its own unique file). I suggest using the server’s name as the filename, i.e., something like “lnxservername.keytab”.

It would be ideal if we could leverage the existing computer account that may exist for that Linux server for host authentication (I’m assuming you followed my instructions for integrating host authentication into Active Directory, yes?), but for some reason it doesn’t work. We can use the SetSPN utility to add the appropriate SPN to the computer account, but authentication still doesn’t work. If any Kerberos/Active Directory gurus out there have some insight on this, please let me know. (By the way, this may be one reason for using user accounts for all the various SPNs—HOST/fqdn@REALM, HTTP/fqdn@REALM, etc.—as some of the online guides for integrating Linux and Active Directory have suggested.)

Now we’re ready to move on to configuring the Apache servers.

Configuring Apache (Each Server)

Repeat these steps for each Apache server. In case I haven’t already mentioned this, I’m assuming you’re running Apache 2.0 on Linux, and not on some flavor of Windows.

  1. Download and install the mod_auth_kerb Apache module.
  2. Add the following directives to the Apache configuration, either in httpd.conf or in the conf.d directory in its own file (my installation of mod_auth_kerb created an auth_kerb.conf in conf.d):
     
    LoadModule auth_kerb_module modules/mod_auth_kerb.so
     
    <Location /secured>
    AuthType Kerberos
    AuthName "Kerberos Login"
    KrbMethodNegotiate On
    KrbMethodK5Passwd On
    KrbAuthRealms EXAMPLE.COM
    Krb5KeyTab /etc/httpd/conf/httpd.keytab
    require valid-user
    </Location>

     
    Substitute the correct values for the KrbAuthRealms directive (your Kerberos realm name will be your Active Directory domain name in UPPERCASE) and the location and name of the keytab. (We’ll copy the keytab over shortly.)
  3. Securely copy over the keytab for this server from the Windows server where it was generated using ktpass.exe earlier. SFTP or SCP are good candidates. Once the file has been copied over, rename it and place it in the right location, as specified in the configuration entered above.
  4. Change the owner of the keytab to the Apache user (typically “apache” or “web”), and set the permissions to 400 (readable only by the Apache user).
  5. Restart the Apache HTTP daemon for the configuration changes to be read and applied.

Assuming that your Apache server is accessible as web.example.com, you should now be able to fire up a recent version of Internet Explorer (one that supports Integrated Windows Authentication) and navigate to the “http://web.example.com/secured” URL and gain access, without getting prompted for authentication. A quick review of the access logs (typically /var/log/httpd/access_log) shows that you are being authenticated as the user that is currently logged on to Windows. (If the browser you are using doesn’t support the transparent authentication, you’ll get prompted for a username and password, in which case you can enter your Active Directory username and password and gain access to the site.)

If this doesn’t work, go back and double-check your ktpass.exe command (noting that the case of the Kerberos principal specified by the “-princ” option is important, as it is case-sensitive). Also check the permissions on the keytab after it has been copied over to the Linux server; it must be readable by the Apache user (and should not be readable by any other users or groups). Finally, try unchecking the “Enable Integrated Windows Authentication” option in Internet Explorer, restarting IE, re-checking that box, and then restarting IE again. (Don’t ask why, but it does seem to help in some instances.)

Finally, note that a few other browsers also support the transparent authentication. I personally tested Safari and Shiira on Mac OS X, and both worked fine (after I had obtained a Kerberos ticket, either using the Kerberos application or kinit from a shell prompt). Camino didn’t work, which is a bummer. I haven’t tested Firefox yet, but I’m told that Firefox also works, although an extension may be required.

Extensive credit goes to Achim Grolms for his walk-through of using mod_auth_kerb with a Windows KDC.

Tags: , , , , , ,

A while ago, I discussed the use of Apache to protect OWA from web-based attacks.  This configuration placed an Apache HTTP server in front of a server running Microsoft Exchange Server 2003 to protect it against web-based attacks, offload SSL encryption, and enable name-based virtual hosts (for the conservation of public DNS hostnames, especially important for smaller organizations).  While this is a useful configuration, it is not without its drawbacks.

First, let’s review some of the advantages of this type of configuration:

  • You can use the open source mod_security module to protect OWA against virtually all forms of URL-based attacks.  Mod_security is an extremely powerful and useful module that can greatly increase the protection against web-based attacks.  See the mod_security web site for more information.
  • Even without mod_security, deploying Apache in front of OWA can protect the OWA server against many IIS-specific attacks.
  • This configuration can be used in addition to IIS-specific protection such as URLScan.
  • You can terminate the SSL connection at the Apache server instead of on the OWA server, freeing up CPU resources on the OWA server for other tasks (this is especially useful in smaller Exchange deployments where the OWA server may also be a mailbox server).

Now, for some of the disadvantages of this type of configuration:

  • Apache lacks the intelligence of an Exchange server configured as a true front-end, and therefore cannot direct requests to multiple back-end mailbox servers.  In this type of configuration, the Apache reverse proxy always directs requests to the same OWA server and cannot determine which mailbox server the user is homed on.
  • Organizations with expertise in Microsoft products won’t necessarily see any real benefit from this due to the added overhead and learning curve of supporting Linux and Apache.  (Don’t snicker, this is a real concern for organizations.)

I’m sure there are other disadvantages as well.  Anyone care to comment and share their experiences?

Tags: , , ,

Thinking About Open Source

Reading about the “Vulnerability Discovery and Remediation Open Source Hardening Project”—a security audit funded by the Department of Homeland Security to regularly review popular open source software (this article has more information)—got me thinking.

The article that sparked my thinking discussed how a critical flaw had been discovered in the X Window System.  This flaw was described as one of the most serious flaws uncovered to date.  The flaw was corrected quickly, as is typical of most open source projects, but it wasn’t really the flaw itself or the quick response to the flaw that really got to me.  Instead, it was the fact that someone was even able to search for such flaws.

The war-cry for open source proponents has always been, “Our software is more secure because more people have seen the code and reviewed it.”  Until now, I wasn’t so sure about that argument; after all, how many people were like me?  People who loved the projects, supported them in whatever way they could, but aren’t developers?  An ordinary guy like me can’t contribute anything significant to an open source project because I don’t know C, C++, C#, Java, Objective-C, or anything else.  The fact that I could review the code, until now, didn’t really do me any good.  Or so I thought.

Perhaps I’m just coming late to the party.  Perhaps it’s the involvement of the government, using my tax dollars, that has driven the idea home.  Either way, now I see that the very right to review the source code is what makes open source projects so powerful in comparison with closed source software.  As this DHS-sponsored project pores over millions of lines of code to find obscure bugs like the one described above, everyone (even Windows users) benefits.  As security flaws, buffer overflows, etc., are corrected in software packages such as Apache (which runs the majority of web sites on the Internet, last I checked), FreeBSD, the Linux kernel, MySQL, the Internet and our own private networks become more secure, more protected, and less likely to be used in attacks against others.  This is what the open source proponents have been so excited about, and why support for open source software is so strong.

This doesn’t mean that open source projects are automatically “more secure,” nor does it mean that we should all eschew all forms of commercial software in favor of open source equivalents.  But it does mean that we do need to strongly consider open source equivalents, especially the high-profile ones, when developing solutions for customers.  In my opinion, it would be a disservice otherwise.

Tags: , , , ,

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.

Tags: , , ,

With the majority of my Linux servers now authenticating against Active Directory, I’m now able to broaden my integration focus and work on some related tasks:

SASL2/PAM:  I still have one server, running SASL2, that has not been switched over to the standard Kerberos/LDAP configuration.  I’ll need to research the interplay between SASL2 and PAM before I tackle this one.

OpenBSD Authentication:  I haven’t touched any of the OpenBSD servers yet for Kerberos/LDAP authentication.

VPN Authentication via RADIUS:  I’d like to use RADIUS to handle some VPN authentication against Active Directory as well.  I don’t anticipate this should be too terribly difficult, but it is something that is rather new to me.

Apache Authentication via Kerberos to AD:  One of the documents that helped me in getting the pam_krb5 stuff working was for using mod_auth_kerb with Apache (more information also posted here as well).  I’d like to deploy this for some select areas of our intranet and extranet sites, to add an additional layer of security on top of what is already present.

Of course, this is in addition to trying to establish an internal news server running INNd (and then migrating content from Exchange Server 2003 into this news server) and working on Squid log analysis tools.  I’ll probably start investigating Squid authentication options as well, since that would be very helpful to my customers (especially if I can get the authentication to be transparent, or very nearly so).  On top of that I have duties in church, work as a manager overseeing employees, and things to do as a dad.  Whew!  I often wonder if I am just not efficient with managing my time, or if I just have too much to do.

Tags: , , ,

Why I Use a Mac

A fair number of people have asked me why I use an Apple Mac when my business centers primarily around Microsoft products such as Windows Server 2003, Active Directory, and Exchange?  That’s a reasonable question.

My computer is simply a tool to get my job done.  About two years ago, I started to evaluate the tasks that I tackle on a regular basis as part of supporting my customers’ networks.  In reviewing those tasks, it become evident to me that using Windows myself was not a prerequisite for designing, installing, and supporting Windows-based networks.  I could run a different OS—like Linux or Mac OS X—and still be perfectly able to get my job done.  In fact, given that I wanted to increase the amount of work that my company did with open source software such as Linux, Apache, Postfix, and SpamAssassin, something other than Windows might actually make that easier.

I then set out to compare the alternatives.  After comparing Linux and Mac OS X, I found that Mac OS X had the best fit for my particular needs.  I loved the mix of open source technologies (the BSD underpinnings and various other open source projects) and closed software (the ultrasmooth Aqua interface).  I loved the hardware.  And, most importantly, I found that there were applications available for Mac OS X to help me get my job done. (See my blog posting about Preferred Mac OS X Applications.)  The fact that many of the applications I needed for my job were open source applications was a bonus.

Is Mac OS X right for you?  I don’t know; that depends upon what you do at your job.  I believe that Mac OS X is a great fit for more people than Windows, but I also believe that people must use what is most ideally suited for their work.  If that is Windows; so be it.  If that is Linux, then great.  And if, like me, it is Mac OS X, then fantastic.  Each of these operating systems have their own strengths and weaknesses, and it is up to each user to determine which OS is right for them.

Tags: , , , , ,

New del.icio.us Links

I’ve added a couple new links to my del.icio.us bookmarks.  Most notably, I’ve added an entry for a recent article on ONLamp.com, a site hosted by the O’Reilly Network, on mod_security.

The article, Securing Web Services with mod_security, is a great introduction to an Apache module that I’ve known about and used for a while now.  Similar to URLScan for IIS 5.0, mod_security serves to block malicious URLs and invalid requests, even within encrypted HTTPS sessions.  As such, it acts as the perfect complement to firewalls and intrusion detection/prevention systems (both network-based and host-based), which typically operate at lower layers of the networking stack.

If you use Apache, I urge you to evaluate and deploy mod_security to enhance your web server’s security.

Tags: , , ,