In part 1 of the series, I covered the reasons why you would want to separate a single server into multiple servers. Now we move on to the nitty-gritty: how do you actually accomplish the task?
Goal: Set up a separate server in the DMZ that handles web serving and external mail transport. This will reduce the number of direct connections from the outside to the inside server. External contributors will still connect directly to the internal mail server to pick up their mail via IMAP.
Ed. Note: You can find this article with a bit more graphic flavor at the author’s website.Network configuration
Create a separate DMZ network segment. This should be fairly easy, as most business-class routers can create a separate DMZ. The idea is that you can control which ports clients can connect to for machines inside the DMZ, and they in turn mediate connections to hosts in the internal zone. An alternative is to use two NAT routers, one from the outside world to the DMZ, and another from the DMZ to the internal zone. The internal zone will remain 192.168.1.0/24. The new DMZ will be 192.168.2.0/24. For now, deny any connections from the outside world to the DMZ, but allow any connections in either direction between the DMZ (192.168.2.0/24) and the internal zone (192.168.1.0/24). We’ll tighten this down later, but it’s easier to start off with it open when you’re troubleshooting.
Internal DNS configuration
You could create a DNS new zone for the dmz but that’s not necessary. On your existing server, make the following changes:
- Add a new machine called “dmzserver”, with IP address 192.168.2.2. Aliases: www
- Remove the www alias from the entry for the original server.
and save all of the changes.
Set up the new DMZ server
The new DMZ server will be at the IP address 192.168.2.2. Be sure to set it to do DNS lookups at the original server at 192.168.1.2. when you go through the Server Setup Assistant be sure to set the server’s Open Directory configuration to Standalone and don’t turn on any services.
Run all of the current system updates and make sure that the server is otherwise ready to go. Using Server Admin and Directory Access, set the DMZ server as being “Connected to a Directory System” and bind it to original server for directory services. Then, using Server Admin and Workgroup Manager, set up Kerberos principals for the new dmzserver.
Set up the Web service
You can use Server Admin to transfer all of the web configuration from the original server to the new server by using Server Admin. Open up Server Admin, select server.example.com, open the Web service, switch to the Settings tab, and drag the settings icon (in the lower-right hand corner of the window, just above the Save button) to the desktop. Switch to dmzserver.example.com, open the Web service, switch to the settings tab, and drag the Web config.plist file from your desktop back into Server Admin. Presto! All of your settings for the Web service from server.example.com have now been copied over to dmzserver.example.com. Furthermore, you now have a backup of the settings for your Web service in the file on your desktop, that you can burn to a CD or put into your backup system, so that if you need to rebuild you server it’s easy to restore the settings.
You now have all of the Web service settings moved over from server.example.com to dmzserver.example.com, but you still need to move over all of the actual web content — html files, gif and jpeg images, etc. The best way to move the content is to use the command line tool tar, which will preserve symbolic links, user and group permissions, and other Unix-level characteristics. Open a Terminal window, and navigate to the directory above your web server’s document root. (If you are using the default location for Mac OS X Server, use the command cd /Library/WebServer.) Next, archive the web content using the command
sudo tar cf WebServerDocuments.tar <i>docroot</i>
where docroot is the name of your contents folder. (If you are using the default location for Mac OS X Server, use the command sudo tar cf WebServerDocuments.tar Documents.) Copy the WebServerDocuments.tar file from server.example.com to dmzserver.example.com in the same relative location, then unarchive the content using the command
sudo tar xf WebServerDocuments.tar
This will preserve the file and folder ownerships and permissions.
Turn on the web service on dmzserver.example.com in Server Admin.
Test the new web server
Use a web browser from the inside zone (192.168.1.0/24) to access the URL http://www.example.com/. Look at the logs for the web service on server.example.com and dmzserver.example.com. You should see the web browser retrieving your web page from dmzserver.example.com, not from server.example.com. (If you had accessed http://www.example.com/ from the same client before the changeover, you may need to reboot the client machine as DNS information may be cached by the lookupd daemon on the client.)
Once you have successfully accessed the web site from an internal client, change the redirect settings on the router so that ports 80 and 443 are sent to 192.168.2.2 instead of 192.168.1.2. Try accessing the web page from an outside location, such as a local coffee shop or from someone’s house. You should get the same result — pages should now be served from dmzserver.example.com instead of server.example.com. You may still want to leave the Web service running on server.example.com so that you can access some of the web-based controls for Mailman mailing lists.
Set up the Mail service
The next piece is to set up and turn on the Mail service on the dmzserver. Some of the configuration can be done from Server Admin, but the rest needs to be done from the command line. In Server Admin, connect to the dmzserver, select the Mail service, and select the Settings tab. Your setup should look like the following:
Save all of the Mail service settings, but do not start the Mail service. Next, edit the postfix configuration files on the dmzserver by using a command line text editor, such as vi. Add the following line at the end of the file /etc/postfix/main.cf:
This make the dmzserver relay all incoming mail to the example.com domain to the server designated by the MX record in DNS. This is why you need to set the dmzserver to use the internal DNS for lookups — that way it’s using the correct information to relay mail.
Next, uncomment the following lines from the file /etc/postfix/master.cf
submission inet n - n - - smtpd -o smtpd_etrn_restrictions=reject -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
This will open up port 587, the authenticated SMTP relay port so that people outside the local network can send mail through your server if they authenticate correctly.
Turn on the Mail service on dmzserver.example.com in Server Admin.
Test the mail service on dmzserver
First, send mail from an internal client to an @example.com address. The mail.log file on server.example.com should show the email being delivered locally. Next, go into the settings in your e-mail client and change the SMTP server to be dmzserver.example.com.
Send another e-mail to an address in the @example.com domain. When you look at mail.log on dmzserver, you should see the e-mail being relayed to server.example.com. When you look at mail.log on server.example.com, you should see the mail being delivered locally.
Keeping the same SMTP settings on your mail client, send an email to an external address (such as @mac.com) and see if it arrives. When you look at the mail.log file on dmzserver.example.com, you should see it going straight out to the mac.com servers. Check your mac.com account to see that the test e-mail actually did arrive.
Change the Mail service settings on server.example.com so that all outgoing email is relayed through dmzserver.example.com. You can do this in Server Admin by selecting server.example.com, selecting the Mail service, clicking on the Settings tab, and selecting the “Relay outgoing mail through host:” option, and entering dmzserver.example.com as the relay server.
On your e-mail client, change your SMTP server setting back to server.example.com, and send a test e-mail to an external address (such as @mac.com). When you look at mail.log on server.example.com, you should see the mail being sent off to dmzserver.example.com. When you look at mail.log on dmzserver.example.com, you should see the e-mail being relayed to the mac.com servers. Check your mac.com account to see that the test e-mail actually did arrive.
Change the redirect settings on the router so that ports 25 and 587 are sent to 192.168.2.2 instead of 192.168.1.2. Send mail from an external account (such as @mac.com) to an account @example.com. When you look at mail.log on dmzserver.example.com, you should see it being relayed to server.example.com. When you look at mail.log on server.example.com, you should see the mail being delivered locally.
Lock down the network
Next, you need to adjust your firewall rules so that the network acts as follows. (Unfortunately, there are so many different ways that different routers can be configured that I can’t give you specific instructions. You may need to get a network administrator to help you here.)
- Allow all connections from the internal zone (192.168.1.0/24) to the outside world, except as noted below.
- Deny all connections from the internal zone (192.168.1.0/24) to any IP address for port 25 tcp, except as noted below.
- Allow connections from the internal server (192.168.1.2) to dmzserver.example.com (192.168.2.2) on port 25 tcp.
- Deny all connections from any IP address to the internal zone (192.168.1.0/24), except as noted below.
- Allow connections from any IP address to the internal server (192.168.1.2) on port 993 tcp.
- Deny all connections from the DMZ (192.168.2.0/24) to any IP address, except as noted below.
- Allow connections from the dmzserver (192.168.2.2) to the internal server on the following ports: 25 tcp (SMTP), 53 udp (DNS), 88 tcp (Kerberos), 389 tcp (LDAP), and 3659 tcp (Password Server).
- Allow connections from the dmzserver (192.168.2.2) to any IP address on port 25 tcp.
- Deny all connections from any IP address to the DMZ (192.168.1.0/24).
- Allow connections from any IP address to the dmzserver (192.168.2.2) on ports 25 tcp, 80 tcp, 443 tcp, and 587 tcp.
- Redirect connections from the external IP address (126.96.36.199) to the dmzserver (192.168.2.2) on ports 25 tcp, 80 tcp, 443 tcp, and 587 tcp.
At this point the network configuration looks like this:
All web serving is now done from dmzserver.pretendco.com.
All incoming SMTP connections go to dmzserver.example.com, which just relays them to server.example.com. External contributors can relay mail through dmzserver.example.com by authenticating, and can use port 587 to get around other networks’ firewall restrictions.
External contributors still connect directly to server.pretendco.com via IMAPS to pick up their mail. This is the only allowed direct connection to the internal server, but it’s as far as we’ll go for stage 1.
In the next stage, we’ll cover how to set up the example.org domain and put external contributors’ IMAP accounts on the dmzserver. This will close off the remaining port and sever any direct connections from the outside to the inside.
If you have worked with Mailman, you may have noticed that the list archives for the [email protected] are no longer accessible to people from the outside. This will be corrected in stage 3.