Personal tools
Navigation
Log in


Forgot your password?
New user?
 
Document Actions

How to Split a Server, Viruses and Malware, and Server Hostname

April 25, 2006

Folks,

How to Split a Server

I am in the midst of a four-part series being published on afp548.com called "How to Split a Server". You can find the first part at

http://www.afp548.com/article.php?story=2006041917593768

or on my website at

http://www.ps-enable.com/articles/How_to_Split_a_Server_Part_1.html.


Is the Mac Really Becoming More Vulnerable?

There's been a lot of back and forth from anti-virus vendors about how "the Mac is becoming more vulnerable" to malware. When you wade through the actual writing there's a heckuva lot of smoke but not much fire. Yes, Mac OS X has vulnerabilities -- but it's a couple of orders of magnitude less vulnerable than the Windows operating system of any flavor. The transition to Intel chips does not change the underlying security model and does not make it any easier or harder to attack Mac OS X. As a last point, I came across this article on the anti-virus industry and some of the problems it faces. It's well worth reading.

http://www.kaspersky.com/eugenearticle

Setting a Mac OS X Server's Hostname

Just a little perspective from someone who was responsible for finding the bug in the first place and worked with some of the engineers who actually fixed it. I originally found the bug in the 10.4.3 timeframe, and there was actually a fix coded up for it by the 10.4.4 timeframe. However, Apple's engineering department considered this a significant change to functionality, and so insisted on doing heavy duty QA on the fix before it was released in 10.4.6. This was the right thing to do, in my opinion.

The issue goes back to MOSXS 10.3, when the server hostname was hard-coded in the /etc/hostconfig file, based on what the administrator entered in the Server Setup Assistant. The problem is that some relatively high minority of inexperienced administrators would either put in just the hostname instead of the fully-qualified hostname (e.g. "myserver" instead of "myserver.example.com"), or they would have a typo in the hostname. This would then be propagated through the Server Setup Assistant into various config files on the system.

To avoid this, in 10.4 Apple went to retrieving the server's fully qualified hostname from a reverse DNS lookup at boot time. The thinking was that the administrator only had to get the DNS entry right, and not re-enter the same information as a part of the server setup. However, this ran into a few problems as well. It does not work if: 1) the network didn't have full reverse DNS lookup, such as with a low-end SOHO router; 2) The DNS server is a little bit slow with its response (which can happen if the network switch is slow to autonegotiate the connection speed); or 3) the server is hosting its own DNS server, since the hostname lookup happens very early on in the boot process but the named daemon starts up much later. In any of these cases, the server fell back on the mDNS/Bonjour name of the server.

To get around this, there were two fixes -- one technical, one procedural. The technical fix was to let the named daemon signal to the operating system that it had started up, allowing the operating system to re-check the hostname -- this takes care of (3). The procedural one was to hard code the hostname in the /Library/Preferences/SystemConfiguration/preferences.plist file by using the command:

    sudo scutil --set HostName servername.example.com

as documented in the kbase article:

http://docs.info.apple.com/article.html?artnum=302044

This process is automated by the changes in Server Update 10.4.6, referred to in kbase article:

http://docs.info.apple.com/article.html?artnum=303697

In addition, the operating system now checks for a mismatched stored hostname vs. the reverse DNS result, and complains in system.log if there is a problem.

The point of all of this? Don't edit /etc/hostconfig any more, and make ABSOLUTELY SURE that your Mac OS X Server has proper forward and reverse DNS resolution on its primary IP address.

--Paul


Powered by Plone, the Open Source Content Management System