As explained earlier, a denial-of-service attack attempts to crash your computer or at least degrade its performance to an unusable level. There are a variety of denial-of-service exploits. Most try to overload some system resource, such as your available disk space or your Internet connection. Some common attacks and defenses are discussed in the following sections.
Mailbombing is the practice of sending so much e-mail to a particular user or system that the computer's hard drive becomes full. There are several ways to protect yourself from mailbombing. You can use the Procmail e-mail-filtering tool or configure your sendmail daemon.
See Chapter 19 for a more complete description of sendmail.
The Procmail e-mail-filtering tool is installed by default with Red Hat Linux and is tightly integrated with the sendmail e-mail daemon; thus, it can be used to selectively block or filter out specific types of e-mail. You can learn more about Procmail at the Procmail Web site www.procmail.org.
To enable Procmail for your user account, create a .procmailrc file in your home directory. The file should be mode 0600 (readable by you but nobody else). Type the following, replacing evilmailer with the actual e-mail address that is mailbombing you.
# Delete mail from evilmailer :0 * ^From.*evilmailer /dev/null
The Procmail recipe looks for the From line at the start of each e-mail to see if it includes the string evilmailer. If it does, the message is sent to /dev/null (effectively throwing it away).
The Procmail e-mail tool works quite well when only one user is being mailbombed. If, however, the mailbombing affects many users, you should probably configure your sendmail daemon to block all e-mail from the mailbomber. Do this by adding the mailbomber's e-mail address or system name to the access file located in the /etc/mail directory.
Each line of the access file contains an e-mail address, host name, domain, or IP address followed by a tab and then a keyword specifying what action to take when that entity sends you a message. Valid keywords are OK, RELAY, REJECT, DISCARD, and ERROR. Using the REJECT keyword will cause a sender's e-mail to be bounced back with an error message. The keyword DISCARD will cause the message to be silently dropped without sending an error back. You can even return a custom error message by using the ERROR keyword.
Thus, an example /etc/mail/access file may look similar to this:
# Check the /usr/share/doc/sendmail/README.cf file for a description # of the format of this file. (search for access_db in that file) # The /usr/share/doc/sendmail/README.cf is part of the sendmail-doc # package. # # by default we allow relaying from localhost... localhost.localdomain RELAY localhost RELAY 127.0.0.1 RELAY # # Senders we want to Block # firstname.lastname@example.org REJECT stimpy.glaci.com REJECT cyberpromo.com DISCARD 18.104.22.168 ERROR:"550 Die Spammer Scum!" 199.170.177 ERROR:"550 Email Refused"
As with most Linux configuration files, lines that begin with a # pound sign are comments. Our list of blocked spammers is at the end of this example file. Note that the address to block can be a complete e-mail address, a full host name, a domain only, an IP address, or a subnet.
To block a particular e-mail address or host from mailbombing you, log in to your system as root, edit the /etc/mail/access file, and add a line to DISCARD mail from the offending sender.
After saving the file and exiting the editor, you must convert the access file into a hash indexed database called access.db. The database is updated automatically the next time sendmail starts. Or you can convert the database immediately, as follows:
# cd /etc/mail # make
Sendmail should now discard e-mail from the addresses you added.
Another way in which your e-mail services can be abused is by having your system used as a Spam Relay. Spam refers to the unsolicited junk e-mail that has become a common occurrence on the Internet. Spammers often deliver their annoying messages from a normal dial-up Internet account. They need some kind of high-capacity e-mail server to accept and buffer the payload of messages. They deliver the spam to the server all in one huge batch and then log off, letting the server do the work of delivering the messages to the many victims.
Naturally, no self-respecting Internet Service Provider will cooperate with this action, so spammers resort to hijacking servers at another ISP to do the dirty work. Having your mailserver hijacked to act as a spam relay can have a devastating effect on your system and your reputation. Fortunately, mail relaying is deactivated by default on Red Hat Linux installations. This is one security issue that you will not have to attend to.
You can allow specific hosts or domains to relay mail through your system by adding those senders to your /etc/mail/access file with keyword RELAY. By default, relaying is only allowed from the local host. Refer to Chapter 19, as well as the sendmail documentation, for more information.
One package you might consider using to filter out spam on your mail server is Spamassassin. Spamassassin examines the text of incoming mail messages and attempts to filter out messages that are determined to be spam. Spamassassin is described in Chapter 19.
Smurfing refers to a particular type of denial-of-service attack aimed at flooding your Internet connection. It can be a difficult attack to defend against because it is not easy to trace the attack to the attacker. Here is how smurfing works.
The attack makes use of the ICMP protocol, a service intended for checking the speed and availability of network connections. Using the ping command, you can send a network packet from your computer to another computer on the Internet. The remote computer will recognize the packet as an ICMP request and echo a reply packet to your computer. Your computer can then print a message revealing that the remote system is up and telling you how long it took to reply to the ping.
A smurfing attack uses a malformed ICMP request to bury your computer in network traffic. The attacker does this by bouncing a ping request off an unwitting third party in such a way that the reply is duplicated dozens or even hundreds of times. An organization with a fast Internet connection and a large number of computers is used as the relay. The destination address of the ping is set to an entire subnet instead of a single host. The return address is forged to be your machine's address instead of the actual sender. When the ICMP packet arrives at the unwitting relay's network, every host on that subnet replies to the ping! Furthermore, they reply to your computer instead of to the actual sender. If the relay's network has hundreds of computers, your Internet connection can be quickly flooded.
The best fix is to contact the organization being used as a relay and inform them of the abuse. Usually, they need only to reconfigure their Internet router to stop any future attacks. If the organization is uncooperative, you can minimize the effect of the attack by blocking the ICMP protocol on your router. This will at least keep the traffic off your internal network. If you can convince your ISP to block ICMP packets aimed at your network, it will help even more.