Basic Vulnerabilities | Maximum Mac OS X Security

All server processes that communicate with the outside world are open to security exploits because of programming errors either in the daemon itself, or in the support code that the server relies on. For the system administrator, these types of exploits are unavoidable, and usually quickly patched within hours of being found. Keeping software current and staying abreast of problems, whether happening on your network, or on the other side of the world, is the responsibility of any good administrator.

Misconfiguration

Mail servers suffer from the same misconfiguration issues as other servers. Inappropriate permissions can allow internal (and sometimes external) users to write to your configuration files, access private data, and compromise your local system security. Maintaining your mail server as a standalone system with as few entry points as possible helps eliminate some of the risks of local mistakes, but in many cases is not a justifiable expense.

Open Relays

MTAs are open to one security risk that is unique, and extremely costly in terms of resources, time, and aspirin: the ability external users have to appropriate MTA services for their own needs. In simpler terms, SPAM. The process of sending mail from machine to machine is called relaying . Each message, as it moves over the network, makes its way from one computer to another, until it reaches the recipient. Most email messages see at least two MTAs along the way: the originating MTA (which most people know as their "mail server") and the destination MTA (the remote server). It is up to each server along the way to determine whether it should deliver the message, reject it, or send it farther downstream for more processing. Relaying itself isn't inherently evil ”in fact it is necessary for email to exist as we know it. The problem, however, occurs when an MTA has been told that it should relay all messages that it receives ”that is, act as an open relay .

Most mail servers are easily configured so that they will relay only messages for users on a certain network, or those who have an account on the server itself. Open relays, on the other hand, process and deliver messages for anyone , regardless of their credentials. The bulk of SPAM mail is transmitted illegitimately through open relays, often without the machine's administrator even knowing it is taking place. Unfortunately, the consequences are numerous , and range from a loss of system performance to legal ramifications .

Open relays "open" themselves to being used by external individuals and organizations. These freeloaders are, in essence, hijacking your system and its resources for their own purposes, without ever actually "breaking in." Spammers often try to offload their outbound mail in extremely high volumes and as quickly as possible. For small server setups, the influx of mail can easily overwhelm available bandwidth and hard disk space as each incoming message is queued for delivery. The result is an effective denial of service attack that requires no special software beyond the ability to send email.

A more serious consequence is in where the responsibility lies if your system is used as the launching point for a SPAM, virus, or other email- borne attack on someone else. Depending on the damage done, the nature of the person or organization under attack, you may find yourself facing charges of negligence if your server was used in the attack. Obviously, this is a worst-case scenario, but with recent world events, computer and network security has moved to the forefront of law enforcement attention. In late 2001, legislation was proposed to classify hackers as terrorists. Although your server may not be the source of the attack, you are responsible for its use and configuration. A mail server is a loaded weapon, and you're responsible for conducting the appropriate background checks before unleashing it on the public.

NOTE

Again, this is a worst-case scenario; it doesn't mean that you can't successfully run a safe and secure mail server (which is the end goal of this chapter), but be aware that there are consequences to running a server without properly configuring it. We've seen incidents of death threats to the President's pets sent through OSU mail servers, only to see the FBI knocking on the door a day later. In the case of the threats to the pets, legitimate email users sent the messages. On an open relay, the same thing could happen, be traced to your server, and your chances of locating the original sender are reduced. Imagine trying to explain this to men (or women) in dark glasses and trench coats.

Testing for Open Relays

You can easily test a mail server to see whether it is an open relay by Telneting into the SMTP port (port 25) on the remote server, then using the SMTP commands to attempt to send a "false" message. Table 13.1 shows the basic commands needed to communicate with an SMTP server, in the order which they are used.

Table 13.1. SMTP Command List

Command	Purpose
`EHLO <machine name >`	Identifies your computer to the remote SMTP server. Some machines use `HELO` instead, but this is largely deprecated.
`MAIL FROM: <originating email>`	Sets the email address from which the message is being sent.
`RCPT TO: <destination email>`	Sets the remote email address to which a message should be delivered.
`DATA`	Used to start the input of the email message to the server. The message is terminated by typing a period ( `.` ) on an empty line.
`QUIT`	Exits and sends the email message.

For example, the following session creates a connection to a remote server ( bezirke.adomaindoesntexist.com ), which is misconfigured and set to be an open relay. The remote server accepts a fake recipient and a fake originating email address and attempts to deliver a message. This is an example of an open relay.

[View full width]

  [View full width] 
 #  telnet bezirke.adomaindoesntexist.com 25  Trying 192.168.0.99... Connected to bezirke.adomaindoesntexist.com. Escape character is '^]'. 220 bezirke.adomaindoesntexist.com ESMTP Sendmail 8.9.3/8.8.7; Sun, 5 May 2002 22:30:15  -0400  EHLO youshouldntrelayme.com  250-bezirke.adomaindoesntexist.com Hello bezirke.adomaindoesntexist.com [192.168.0.132],  pleased to meet you  MAIL FROM: jray@youshouldntrelayme.com  250 jray@youshouldntrelayme.com... Sender ok  RCPT TO: sniffles@aplacethatdoesntexist.com  250 sniffles@aplacethatdoesntexist.com... Recipient ok  DATA  354 Enter mail, end with "." on a line by itself Hello, This is a test. --- John  .   QUIT

On the flip side, a properly protected machine will block the message from being sent:

 #  telnet poisontooth.com 25  Trying 204.210.234.132... Connected to poisontooth.com. Escape character is '^]'.  EHLO client1.shadesofinsanity.com  250-poisontooth.com Hello client1.shadesofinsanity.com, pleased to meet you  MAIL FROM: jray@poisontooth.com  250 jray@poisontooth.com sender accepted  RCPT TO: aspamrecipient@nospamallowed.com  473 aspamrecipient@nospamallowed.com relaying prohibited.

In this example, the server refuses to deliver the message. The connecting client is not authorized to send the message. This is the target behavior for a " healthy " mail server.

Top