Most, if not all, Australian universities have suffered problems due to abuse of e-mail relay security. All of you will have been annoyed by the constant barrage of unsolicited commercial e-mail on the internet. Some of you may have staff who have had network accessible backdoors installed on their computers by abusing buffer overflows in Windows e-mail clients, or trojan-horse style attachments. These are some of the topics addressed by this talk.
Firstly, I will discuss open local e-mail relays and the problems they present. Then I will move on to some common forms of spam prevention, such as blocking by custom list, blocking by external list and blocking by regular expression. Next I will cover the problem of untraceable fake mail, just briefly since it's not really an e-mail problem but more a general security problem if you have labs without good authentication and logging. Finally, I will cover security problems in e-mail clients and with e-mail attachments and some ways the network staff can help with the problems.
By now you've probably all had problems with open mail relays. This is a form of traffic-stealing attack where someone on the internet discovers you have an old or misconfigured mail server, or simply a machine with WinGate or similar software on it, which will permit them to send e-mail through it to arbitrary other addresses. At the mildest, some student's dialed up machine accepts e-mail from anywhere and sends it out through some on-campus host, and the on-campus host ends up in ORBS or RBL (two internet relay blocking lists, explained later). At a more severe level, one open mail relay can result in a number of mail servers choked on the path of the e-mail through your network, heavy international traffic and a significant portion of other internet sites, including local universities who you need to exchange e-mail with, rejecting all e-mail from your site due to the mail outgoing relay host being in both ORBS and RBL.
Fixing the problem is simple in principle but often difficult in practice. The best approach is to build a list of machines which need to be able to accept e-mail from the internet, filter SMTP connections to every other address on your campus at your campus border router and/or the nearest router port to the machines and configure the externally accessible machines to prevent relaying, except to hosts they are the backup MX for. This last bit is essential because if a backup MX denies relaying and the main MX crashes or is attacked with a mail flood, all incoming e-mail falling back to the backup MX will be bounced. By restricting incoming mail connections to a list of known good mail hosts, when new machines with poorly configured mailer daemons are installed there is still no problem, as you can make sure they are properly configured before opening up the filter for them.
An alternative approach is to only filter incoming SMTP for dial-ups (this should always be done, consider filtering outgoing SMTP from dialups too), and to scan the entire campus network for open mail relays and work on closing them. I have been regularly scanning the UWA network for open mail relays and working with the departments to close them. Below is a table of how effective this has been. In the week leading up to the 3rd of March this year we had several major mail relaying problems on different hosts and had no success with asking all departments to close their mail relays. Then came my scanning (using a locally developed fast scanner) and public humiliation (via our tech-contacts e-mail list) of the departments which did not act. This had rapid initial success, with the number of open mail relays decreasing from 255 to 123 in 2 days. Unfortunately, as you can see below, the rate of decline dropped off quite quickly, but this was mainly because my rate of scanning dropped off as the problem became less severe once we had a much reduced number of open relays. Eventually, after 6 months, the number of open hosts was approximately one twentieth of the original figure, or 3.3% of the original host count. Most of the remaining hosts are in departments who are difficult to deal with or running highly obscure software.
Scan Date Open Total % Open % O/OO % O/OT ========= ===== ===== ======= ======= ======= 3/3/98 255 394 64.7% 100.0% 64.7% 4/3/98 224 393 57.0% 87.8% 56.7% 5/3/98 123 309 39.8% 48.2% 31.2% 9/3/98 95 260 36.5% 37.2% 24.1% 17/3/98 63 248 25.4% 24.7% 16.0% 8/4/98 55 240 22.9% 21.6% 14.0% 22/4/98 48 234 20.5% 18.8% 12.2% 1/5/98 40 247 16.2% 15.7% 10.2% 8/5/98 41 240 17.1% 16.1% 10.4% 21/5/98 41 245 16.7% 16.1% 10.4% 9/6/98 28 231 12.1% 11.0% 7.1% 14/7/98 21 239 8.8% 8.2% 5.3% 12/8/98 13 230 5.7% 5.1% 3.3%
The most useful reference for preventing mail relaying with various mail daemons is Paul Vixie's Transport Security Initiative (TSI) web site, part of the Mail Abuse Prevention System (MAPS) web-site at http://maps.vix.com/tsi.
Following on from preventing your mail servers being used as spam relays is preventing your mail servers from accepting spam relayed through open relays. There are two main internet blacklists of such servers, Paul Vixie's Real-time Black-hole List (RBL) at http://maps.vix.com/rbl and the "Dorkslayers" Open Relay Blocking System (ORBS) at http://www.dorkslayers.com/orbs. The easiest way to reduce the amount of spam you receive is to use one or both of these through the DNS with sendmail; sendmail 8.9.x supports them with a simple m4 configuration macro, and sendmail 8.8.x supports them by adding some rules in the ruleset check_mail. Many other mailers also support them with a configuration option called "RBL".
Spam prevention in general is achieved as a combination of using RBL and/or ORBS, blocking mail which "looks like spam" with something like "SPAMCAN" (see http://consult.ml.org/~timb/spamcan) or equivalent (but harder to write) sendmail 8.9.x rulesets, and some localized blacklists. Localized blacklists are becoming less popular as they are hard to maintain and you have to handle any administrative burden inside your institution. However, there can be a need for localized blacklists, sometimes combined with a script to delete a certain message from all inboxes, when a specific site decides to e-mail every single account on one of your machines. Some examples I have seen at UWA are a graduate school seeking students and a certain student union whose bulk mailer managed to keep one of our links at 95% utilization for around 6 hours sending copies of the one message to all student accounts (and only getting to around 50% of students in that 6 hours before we found it and blocked the site, and then proceeded to remove all the messages which had been received).
If you are using either sendmail 8.9.x header rules or "SPAMCAN", one good and highly effective rule is to block any incoming messages with the headers X-PMFLAGS, X-UIDL and X-Advertisement. This can block quite a large amount of spam and very rarely blocks legitimate e-mail. The first two are used by spammers to attempt to give priority to their message (for example, X-UIDL can be used to try to make the e-mail client download the message every session if using POP in "leave mail on server" mode since it prevents the POP server from inserting a valid UIDL value). The third, X-Advertisement, was initially the result of a legal settlement in the US which required certain spam mail senders to include this header, and denied a large US ISP permission to completely block based on this header but permitted them to make it an option in their e-mail client.
Moving on now to briefly cover fake mail. Fake mail is unavoidable. However, untraceable fake mail from on your campus is avoidable. If fake mail from on your campus is possible, it is part of a larger security problem - if people can make connections where neither the ident lookup and hostname pair (for multiuser machines) or the hostname and time pair (for single user machines) can be traced back to a unique person, you have a problem. One use of this problem is untraceable fake mail, another in untraceable hacking attempts.
We had a lab on our campus where it was possible to gain access without authentication, and one where it was possible to gain access with authentication but it was not logged. These were both used to send offensive messages and excessively large messages, such as multiple copies of the netscape binary, to prominent e-mail addresses (email@example.com and so on) forged to come from my e-mail address, using AppleScript to send them over and over again. The real solution is to authenticate and log all lab machine use. The temporary solution was to block port 25 at the border of the lab subnet, but as expected this caused the person to start using hotmail and similar services for non-fake but still untraceable e-mail (and in this case to publish web pages on geocities) - which is why I said at the beginning that a situation which permits untraceable fake mail is a part of a larger security problem. Just briefly, another thing which permits untraceable fake mail is that sshd makes some forwarded connections with an ident of root. Disabling connection forwarding in sshd is generally a good idea. Again, a general security issue which extends to e-mail problems rather than a specific e-mail security problem.
Finally, lets move on to e-mail client security. All kinds of e-mail clients have had buffer overflows permitting arbitrary code execution, including Pine, Eudora, Netscape, Outlook Express, and so on. Even simple Unix mail processing programs such as "filter" and "vacation" have had security vulnerabilities. Protection of e-mail clients is a combination of education - keeping people informed of the need to keep software current and not to trust unknown attachments - and actual protection - attempting to prevent the use of known problems.
Software is around to protect e-mail users. Virus scanner plug-ins for firewalls can check for known bad attachments and virus infected attachments. Sendmail 8.9.1 can protect against some known buffer overflows in mail clients, and using procmail for local delivery can check for even more potential problems. The procmail based filter for security problems can be found in the BUGTRAQ archives which are at http://www.geek-girl.com/bugtraq/index.html.
Even with these measures, it is still important to keep your staff and students aware of current security issues, through whatever communication channels you have with them. You should inform them of current security issues, and in the case of on-campus users try to install or arrange the installation of some protection against the major problems. You may also find for Windows 98 users that the Windows Update web site is quite a useful resource to refer them to, as it often contains updates for security problems in Internet Explorer and Outlook Express. Remember that even if you install a firewall which protects against virus-infected e-mail, virus-infected programs can still be brought in on floppy disk or CD, or downloaded directly off the internet (this last part may also be blocked by some firewalls), so again this is a general security problem which e-mail is only one part of.
Another way to encourage safe e-mail use is to encourage the use of signed e-mail; perhaps having a site policy that you do not open attachments unless the message is signed with something like a PGP ("Pretty Good Privacy") or GPG ("GNU Privacy Guard") key. If this is done properly, then it reduces the risk of fake mail containing viruses or trojan-horse type applications being run. It is possible to use procmail as the mail delivery agent and to have it drop or redirect any messages where the PGP key is known and fails verification, and to have it remove attachments from unsigned messages.
In conclusion, securing e-mail should form a part of an integrated security
policy. Some items which I have covered here, such as user notification of
security problems in client software, untraceable network accesses from labs
and traffic stealing through open relays, are just part of general security
problems. Others, such as blocking incoming spam and using PGP or GPG to sign
messages, are specific to the realm of e-mail. All of them deserve attention
in keeping a site secure.