Preventing Spams and Relays
The Internet has been around since the 1970s with people using it mainly for electronic mail (e-mail). This is still true even today as we see increasing numbers of multimedia-based applications on the Internet. People still use e-mail more than web browsers and file transfer programs. The reason is simple—it is a low-cost yet effective method for communicating with others all over the world. More and more people are getting onto the Internet, and the first thing they do is get an e-mail address.
Realizing this, certain individuals and even organizations have taken the opportunity to send unsolicited e-mail to Internet users. Most of this mail is commercial advertising. They send thousands of copies of the same message to a list of e-mail addresses obtained from either Usenet postings or companies' home pages. Such action is called spamming.
The consequence of spam is that the receiver ends up paying for the cost of the e-mail, since the ISP (Internet Service Provider) usually charges on the basis of connect time and downloading mail takes time. At companies where each employee has an e-mail address and the company has a fixed line for e-mail, that line can become quite expensive if it is targeted by spammers.
To hide their identity, spammers usually send from a forged e-mail address and use mail servers that have not been configured to prevent such activities. Relaying, as it is usually called, will cause the targeted e-mail server to send mail on behalf of the spammer to hundreds or even thousands of users. Spamming can seriously affect the performance of the mail server and cause massive bandwidth loss for the company affected. Not only will the mail server's performance be affected, but recipients of the spam will be given the impression that the company is in business with the spammer.
For more information on this, visit the number one anti-spam site on the Internet at http://spam.abuse.net/.
My company was recently the target of a spammer who used our mail server as a relay. The spammer was using an account from a well-known service provider, and my guess is that it was probably a trial account. I had not installed any preventions against such attacks and was thus targeted. When I discovered the attack, I dropped all my current work and began searching for a solution. I started by looking at the Sendmail home page (http://www.sendmail.org/). It had links that led to more tools and tips for spam prevention. I chose to implement the solution based on the smtpd package from Obtuse Systems Corporation for the following reasons:
smptd is a small package with only two executable files to manage and one configuration file to tweak.
It works nicely with my mail server (Sendmail v8.8.8).
The configuration file is very flexible and easy to configure.
As of this writing, the smtpd package is at version 2.0 and can be obtained from ftp://ftp.obtuse.com/pub/smtpd/smtpd-2.0.tar.gz.
smtpd works with other MTAs (Mail Transport Agent), but I have been using only Sendmail. The latest Sendmail can be retrieved from ftp://ftp.sendmail.org/ucb/src/sendmail/sendmail.8.9.1.tar.gz.
Note that you must have a working MTA before installing smtpd. It acts only as a mail proxy, storing and forwarding mail to other MTAs for the actual delivery.
Briefly, here's how smtpd works: the smtpd daemon runs and accepts mail instead of your regular mail server. It accepts mail from the Internet as well as your own domain. smtpd can be configured to reject mail based on several criteria:
IP address of the sender
Host name or domain of sender
E-mail address of sender
E-mail address of receiver
Based on the configuration file, the mail is either rejected or accepted and spooled. The second program, smtpfwdd, will do the actual forwarding of the spooled mail to the MTA (Sendmail in this case).
Once you've obtained the package, unarchive the files to a directory. Assuming the files are to be put in the directory /usr/src/smtpd-2.0, do the following:
cd /usr/src tar xvzf ~/smtpd-2.0.tar.gz cd smtpd-2.0
Now, by typing ls, you'll see many files and subdirectories. Be sure to read README and INSTALL as these files contain valuable information on the installation of the mail proxy.
To compile the package, do the following:
Choose a user and group for running the smtpd daemon. Your choice must be defined as a trusted user in the sendmail.cf file. I chose to use the user daemon. If you are not sure what to use as trusted user, check the /etc/sendmail.cf file for lines like this:
# Trusted users # Troot Tdaemon TuucpIn this example, the trusted users are root, daemon and uucp. Do not use root. smtpd works without any root privileges; thus, it is more secure to run it as some other user.
Create a directory in which smtpd can store spooled mail before smtpfwdd processes it. Change permissions and also the user/group of that directory so only that user has full rights to it. If you put it in the /home/smtpd/spool directory, execute these commands:
mkdir /home/smtpd mkdir /home/smtpd/spool chown -R daemon.daemon /home/smtpd chmod 700 /home/smtpd ls -lad /home/smtpdThe output from ls will look like this:
drwx------ 3 daemon daemon 1024 Mar 26 01:34 /home/smtpd/
Edit the Makefile in the source directory to reflect your choice. The changes we need to make for our example are as follows:
SMTP_USER = daemon SMTP_GROUP = daemon SPOOLDIR = /home/smtpd SPOOLSUBDIR = /spool EHLO_KLUDGE=1 JUNIPER_SUPPORT=0 #LD_LIBS=-lresolv CHECK_IDENT = 0EHLO_KLUDGE is needed to fix a bug in Netscape Communicator. JUNIPER_SUPPORT is set to 0 unless you're using Obtuse's Firewall Kernel. LD_LIBS is commented out, as my Linux distribution does not require the external library libresolv. CHECK_IDENT has been set to 0 to disable IDENT checking. I personally do not believe in IDENT checks—they take time and do not return any useful information.
By default, the Makefile has been configured to be compiled on Linux, so no other changes need to be made.
In the source directory, type make to compile smtpd and smtpfwdd.
Once the compilation is finished, you will find two executable files in the directory. Copy them to another location in your PATH. To copy them to the /usr/local/sbin directory, type:
cp smtpd /usr/local/sbin cp smtpfwdd /usr/local/sbin
Create a few subdirectories under the /home/smtpd/ directory by typing:
cd /home/smtpd mkdir etc usr mkdir usr/lib mkdir usr/lib/zoneinfoBecause smtpd does a chroot to the directory /home/smtpd, we need to copy (or make symbolic links) into this directory some files that are required for the proper execution of smtpd/smtpfwdd. The files and the directory in which each should be located are:
/etc/resolv.conf -> /home/smtpd/etc/resolv.conf
/usr/lib/zoneinfo/localtime -> /home/smtpd/usr/lib/zoneinfo/localtime
The file resolv.conf is needed so that smtpd can do DNS queries (look up IP addresses of hosts). The file localtime has your time zone setting and is required to put the proper time stamp on e-mail. The location of localtime may be different on your system, so you'll have to find the exact path and create a duplicate under the /home/smtpd directory.
Configure smtpd and smtpfwdd to replace the running mail server.
The mail proxy reads its configuration from a file (smtpd_check_rules) in the /etc directory, in our example, /home/smtpd/etc/smtpd_check_rules. Each line in the file beginning with a # is a comment. Blank lines are allowed. Rules have the following format (one line):
where XXX is the error message number. The first rule that matches will be taken and the check ended, so placement of rules should be done carefully.
The first field states the action to either allow an SMTP connection, deny the SMTP connection and close the session or noto which will return an error for the matching rule but will still continue for the session.
The second field is a list of IP addresses and/or host names to match the source SMTP connection. IP addresses may be specified with a netmask to include a whole network. The format of this is XX.XX.XX.XX/bits where bits is the netmask bits for the network. For instance, a network 192.168.0.0 with netmask 255.255.255.0 would be written as 192.168.0.0/24. A few special reserved identifiers that can be used are:
ALL: any IP address and host name
KNOWN: only IP and host names which are DNS resolvable
UNKNOWN: IP and host names which are not DNS resolvable
*: wild-card character
The third and fourth fields are used to match e-mail addresses and have the format user@host. The special word ALL can also be used in these fields.
The fifth field is optional and is used to return error messages from deny and noto to the SMTP client. The following special variables can be used to return information in the error messages:
%F: mail from address
%T: recipient address
%H: connecting host name
%I: connecting IP address
%U: user from the host
All three fields (SourceList, FromList and ToList) must be matched in order for action to be taken.
Listing 1 is an example of a set of rules that assumes the internal network is 10.0.0.0 and a mail hub is at 10.0.0.9. Note that noto_delay will pause for a certain amount of seconds before action is taken. This option was introduced to delay relayers and spammers and the parameters that control this timeout are set in the Makefile:
NOTO_DELAY = 60 DENY_DELAY = 60
A few other configurations can be done that I have not shown here, namely the NS= pattern-check and the use of the IDENT protocol for identifying users. Users who need a more detailed setup of this file should read the file smtpd_address_check.txt in the source directory. Examples for filtering spams and relays can be downloaded from Obtuse's FTP site.
After creating the configuration file, the running mail daemon must be stopped and replaced with smtpd/smtpfwdd. For Sendmail, this can be done by typing:
> ps ax | grep sendmail 24569 ? S 0:00 sendmail: accepting connections on port 25 > kill 24569
This will effectively shutdown the mail daemon. Now, check for queued mail that the daemon has not yet sent out by issuing the command:
/usr/lib/sendmail -bpIf the mail queue is not empty, flush the queue by typing:
/usr/lib/sendmail -qIf mail is still in the queue after awhile, this command can be resent at a later time so the installation of smtpd/smtpfwdd can continue. No new mail will be accepted while the mail daemon is down.
Start the smtpd daemon by issuing the command:
/usr/local/sbin/smtpd -c /home/smtpd -d /spool\ -u daemon -g daemon -D -L
The smtpd daemon will start accepting mail and spool it to the /home/smtpd/spool directory. The parameters on the command line are defined as follows:
-c /home/smtpd: the smtpd home directory
-d /spool: the directory where spooled mail should be stored
-u daemon -g daemon: user/group smtpd
-D: instruction to run as daemon and listen on the SMTP port
-L: instruction to suppress children in daemon mode from making an openlog call
/usr/local/sbin/smtpfwdd -d /home/smtpd/spool -u\ daemon -g daemonOnce it begins running, smtpfwdd will check the spool directory /home/smtpd/spool and starts processing the spooled mail by running the MTA, in this case Sendmail.
A good idea is to run the MTA in such a way that it periodically processes its mail queue and sends out any mail present. Note that we actually have two spool directories here: one used by smtpd and the other by sendmail (usually in /var/spool/mqueue). To run sendmail in non-daemon mode in order to process the queue every 15 minutes, type:
Once everything is running fine, edit your startup files to run smtpd/smtpfwdd by default instead of sendmail.
The Internet is no longer the “friendly global village” we once thought it was. Living among the netizens are unscrupulous individuals and even companies that take advantage of the openness of the Internet for their own benefit while making others bear the cost. We must take preventive measures against these attacks if we want to avoid becoming victims. Proper policy on the e-mail server will help to ensure this. With smtpd in place, you will have more control of your e-mail server.
John Wong can be reached at email@example.com.