 |
|
|
BorderWare Mail Gateway Table of Contents Introduction Electronic communication is a vital asset to the modern business, even the life blood of some. Therefore, when things go wrong and the mail server is down for hours – or even days – then operational efficiency can take a serious nose dive. Unfortunately, tales of e-mail systems grinding to a halt as a result of users activating simple viruses and Trojan horses in the form of macros or Visual Basic scripts are all too common. So too are the cries of “how did this happen – we have a firewall?” This illustrates the lack of understanding about the role of firewalls. There is a widespread misconception that simply installing a firewall will address all security problems - it will not. Firewalls are defensive and operate by controlling the connections into a protected network. An effective e-mail service requires that those controls are relaxed in order that an internal server can receive messages. These conflicting requirements mean that many firewall products offer very limited facilities for e-mail security. Today, we are so used to receiving attachments to our e-mail messages that we have become susceptible to receiving viruses embedded within otherwise innocent-looking documents. Such transmissions need to be stopped “at the door”, before reaching the user’s mailbox, but the firewall is not the place to do it. In order to provide security, firewalls are designed to place strict limits on connections from an untrusted network to a trusted network and ideally should allow no inbound connections to the trusted network unless the source of those connections can be reliably authenticated. This basic design principle is incompatible with processing e-mail. An effective Internet e-mail service requires bi-directional connections between the protected network and the Internet (outbound connections for sending e-mail, and inbound connections for receiving replies). In nearly all cases it is impossible to predict in advance who will be sending e-mail and where those messages will originate. This means that in order to support an effective e-mail service the firewall must be configured to accept unidentified and unauthenticated inbound connections. Allowing free and open connections to an e-mail server means that a connection made for e-mail delivery can be exploited to either break into the server, render it inoperative through a denial of service attack or effectively hi-jack it and force it to operate as a mail relay. Some firewalls may offer some defence against protocol level denial of service attacks, but many do not, and very few firewall products offer any defence against mail flooding. Firewalls certainly cannot provide a defence against mail relaying, since to the firewall it appears to be a perfectly valid SMTP operation. Mail relaying is used most often these days to send unsolicited e-mail – or “spam” – yet another resource sapper. One multi-national firm estimated the cost of junk e-mail at one dollar per employee per day. Multiply this for an organisation of thousands and the cost of this activity soon becomes significant. At best, spam is an irritation as it floods mail boxes with unwanted messages, and at worst it can fill a user’s mailbox or flood an e-mail server, effectively blocking legitimate mail. Inbound spam can be partially controlled by keyword-searching inbound e-mails and rejecting likely messages. This technique should be used carefully, however, as it can easily lead to incorrectly rejecting valid e-mails. A better solution is to configure the e-mail server to check each incoming message against a database of known sources of spam such as the Mail Abuse Prevention System (MAPS) . For the organisation whose mail server is used to perform the relay of the spam, however, the consequences can be dire. At best, server and Internet bandwidth resources can be consumed for hours or days on end. At worst, the otherwise innocent organisation’s ISP could decide that connectivity should be terminated. Mail relaying works because the SMTP protocol was designed so that any SMTP server would accept a message for any recipient and do its best to try and deliver it. An external entity can thus pass a single message and a large list of recipients (usually thousands of e-mail addresses) to someone else’s SMTP server and rely on that server to carry out the delivery of thousands of messages. Not only does the originator save time and resources by getting some other hapless dupe to deliver his gigabytes of rubbish, but he also manages to obscure his identity by making it appear as though the spam actually comes from the server performing the relay. Unfortunately, most e-mail systems (including Exchange, Lotus Notes, GroupWise and most Unix mailers) will relay any messages sent to them by default. A server that functions in this way is known as an open relay, and it is not always straightforward to correct this behaviour. Some e-mail systems can be configured to check the sender of each inbound message against a database of open relays and reject any messages from that relay. Thus if your own e-mail server finds its way into such a database (like the one operated by ORBS (the Open Relay Behaviour-modification System)) you could find that your own legitimate e-mail is being blocked and will not be transmitted to significant parts of the Internet. Earlier we mentioned the threat of Trojan and virus transmission via innocent-looking e-mail attachments. Once again, the default setting of common software – this time the desktop operating system – is at fault. Out of the box, Windows hides file extensions of file types that it recognises, such as .EXE (program files), .DLL (libraries), .VBS (Visual Basic Scripts), and so on. Thus, it is possible to craft a VB Script with a nefarious payload and call it something like NAKED.JPG.VBS and this script can then be sent as a normal e-mail attachment. Because Windows hides the file extension by default, the file name appears as NAKED.JPG. The user, thinking this is simply an image file, double clicks on it to view and the script is activated. Clearly similar methods can be used to transmit other types of Trojan and virus files. One way around this threat is to discard all e-mail attachments as they enter (or leave, assuming you also wish to stop your own employees from propagating viruses) the corporate network. Unfortunately, whilst this may solve the virus problem to a certain extent, it drastically reduces the usefulness of e-mail. Attachments have become a common and widely accepted method of transmitting information, with the bulk of the data carried within an attached Word document or Excel spreadsheet, and the e-mail itself consisting of a one-liner saying little more than “read this”. All of these threats require only that a normal SMTP connection can be established to the mail server. Since this is a requirement for receiving mail, and since most firewalls do little more that simply pass these connections through to the mail server, that server is vulnerable unless positive action is taken to ensure that it is adequately protected. Managed correctly, e-mail can be a considerable asset to any organisation. It can improve communication between employees, between departments within a company, between geographically dispersed offices, and between customers and business partners. In order to maximise the beneficial effects of e-mail, however, it is necessary to implement it carefully and ensure that your mail system is as secure as it is possible to be. BorderWare Technologies Inc. has made its name as the producer of the BorderWare firewall, and has now decided to use the secure kernel from the firewall as a basis for a new range of secure software “appliances”, one of which is the Mail Gateway, a secure “store and forward” mail relay. The result is an extremely secure platform that has all the security and robustness of the BorderWare firewall, and running only the software that is necessary to perform its dedicated function. In the case of the Mail Gateway, there is an Apache Web Server listening on ports 80 (HTTP) and 443 (SHTTP) and the secure store-and-forward mail relay. Installation is as straightforward as you can get, all the more amazing when you realise that the underlying software is a hardened version of BSD Unix, known as S-Core. The current version of the OS provides much broader hardware support than vanilla BSD Unix, and the Mail Gateway installation performs full auto-detection of the host platform and its peripherals and configures itself accordingly. The software is provided on a bootable CD which boots straight into the installation procedure. The “Automatic” installation option is pretty much exactly that, whilst the “Custom” options provides the means to alter disk layout, network settings and so on. There is also the option to install from CD or across the network from an image stored on a central file server, the latter providing a rapid means of rolling out a number of Gateways across a corporate network. It is important to remember that the hard disk will be wiped and the entire system used as the Gateway – this is meant to be a secure, dedicated system after all. During installation, the administrator is prompted for basic parameters such as an IP address, netmask, host name, default gateway and DNS server. The Mail Gateway is typically installed with two network cards and works best when run in parallel with the firewall. This is not as dangerous as it first sounds, and in fact will actually improve perimeter security. The idea behind this method of deployment is that all SMTP traffic is prohibited through the firewall itself, thus forcing it through the Mail Gateway. The Mail Gateway will not accept any connections other than on port 25 (except for Web connections on port 80/443 for administration and browser-based access to mail), and even then a direct channel is never opened to the protected network. Instead, the Gateway uses the proven technology of the SMTP store-and-forward relay from the BorderWare firewall to ensure that SMTP connections are handled correctly. For those who wish to continue using their firewall as the primary method of enforcing perimeter security, the Mail Gateway can be installed with a single network card and placed either inside or outside the firewall, or on the DMZ subnet. For more advanced deployments, up to four networks cards can be supported, and Mail Gateway can route mail between them. Once the installation is completed and the Gateway has been rebooted it is immediately in secure mode, and minimal functionality is offered at the console. The default screen offers some basic CPU, network and mail delivery statistics along with a real-time activity display showing the most recent actions performed by the Gateway. The administrator can log in at this console in order to perform some very basic diagnostic and maintenance tasks – such as viewing and reconfiguring the network cards, pinging other network devices, displaying disk usage and system processes, or shutting down the system. Note that modifying any of the basic Gateway network parameters – such as changing an IP address – requires a reboot of the system. Unlike a normal Unix system, all S-Core-based appliances have a very tightly secured operating system where the kernel is locked down, the Root partition is made read-only and the configuration files are flagged as immutable. This ensures that no one can break into a running system and reconfigure it on the fly. All the main management tasks are performed via a browser-based interface – and not a single, sluggish Java component in sight! The menus are clear, and the interface is intuitive and easy to use.
The Gateway includes a standard Apache Web server, configured to permit only browser connections for management and access to user mailboxes. The default mode is to allow unencrypted connections between the browser and Gateway, though it is also possible for the Gateway to generate its own digital certificates (or use those generated by a Certification Authority) following which the built-in Web server can be configured to enforce SSL encryption for all browser-based connections. To further improve security, however, we would like to see a configuration option added whereby administrative functions are only made available on a specific Ethernet interface. This would allow admin function to be restricted to the protected network, and disallowed across the Internet, where required. On connecting to the Gateway, the administrator is prompted for a login name and password. A single administrator account is created when the product is first installed, and additional user accounts can be added later. These accounts only define mail users, however, and determine the characteristics of their mailboxes - there is only ever one administrator account on a BorderWare Mail Gateway. Each user can be allocated a disk quota, a forwarding e-mail address, a POP3 mailbox (this is not provided by default, since POP3 is such an insecure protocol), and an account expiry date. A user account also needs to be created here in order to provide remote browser-based access to e-mail via the BorderPost capability.
The bulk of the configuration is handled by the Mail Delivery option from the main menu. Here is where the administrator defines which domains the gateway should accept mail for, and whether that mail is to be stored on local mailboxes or simply relayed (via the secure proxy) to an internal SMTP server. Where more than two network cards are installed, it would be possible to have different SMTP servers on different secure (or public) subnets, and have the Mail Gateway route messages to each as required. For outbound mail, Address Masquerading can rewrite mail headers to ensure that all internal mail appears as though it originated from the Gateway itself if required. Note that BorderWare Mail Gateway is configured not to act as an open relay by default out of the box (which makes a change, since most commercial mail servers behave in exactly the opposite manner by default), but the relay capability can be overridden on an individual basis based on certain fields in the mail header, such as the “From:” address, IP address, HELO string, and so on. There are a number of other features of the Mail Gateway which are configured in the Mail Delivery section of the main menu, and which make the product far more than a simple mail relay. This provides the means to eliminate unsolicited e-mail (spam) at the gateway. The easiest way to achieve this is through checking the source of the mail against a set of known spam-generating sites via DNS lookups against a Real-time Blackhole List (RBL) site.
In addition, the administrator can enforce his own rules based on specific source IP addresses or domains, or by using regular expression matching against the contents of the mail header. This latter option in particular can provide a very powerful and flexible filtering mechanism, allowing the administrator to filter out any e-mail whose subject line contains specific words or phrases, such as “Sex”, “Get Rich Quick” or “XXX”. Anyone familiar with regular expressions will realise that far more complex rules can be created than these, and BorderWare provide additional documentation to help with writing more advanced expressions. Using Mail Mapping, the administrator can hide the complexities of internal mail distribution and changes to the internal network from anyone outside the Mail Gateway. For inbound mail, the Gateway will translate each address in the “To:” mail header into a corresponding internal form that allows the message to find its way to the correct internal mailbox. Similarly, mail originating internally can have an address in its “From:” header modified by Mail Mapping so that all internal mail appears to come from a single address. Clearly this is of limited use when an organisation is making use of digital signatures, since changes will be made to the mail header which will invalidate the signature. For organisations using digital certificates, the Mail gateway provides two alternate methods of distributing e-mail: Virtual Mapping and Mail Routing. As with Mail Mapping, Virtual Mapping can be used to hide the internal workings of a mail system from the outside world. Whereas Mail Mapping affects the userid portion of the mail address, however, Virtual Mapping works on the domain. Virtual Mapping is thus used to redirect mail addressed for one domain to a different one. The Gateway could therefore be used to distribute inbound mail amongst multiple different internal mail servers depending on the “To:” address. This is used to specify that mail for a particular destination should be accepted by the Gateway and then delivered to a specific internal host. This is the easiest way of configuring the Gateway to act as a relay for an internal mail server, and is the only “re-routing” method that will work with digital signatures, since it does not need to rewrite mail headers in order to achieve this. With the current crop of Trojans masquerading as innocent image files this feature is incredibly useful. Mail Attachment Control can be used to identify and quarantine mail messages with suspicious attachments or MIME content types.
Each attachment or MIME content type is compared against an extensive list, which includes all the obvious ones such as DLL, VBS, EXE, and so on. The administrator can also add new attachment or MIME content types easily. Once a suspicious attachment has been detected, the entire mail message is moved to a secure quarantine area and the administrator, sender and all recipients can be notified automatically that the message could not be delivered. The recipient is provided with a unique quarantine ID which can be used to trace the suspicious message. The administrator can then locate the quarantined message via that ID, examine it, and either delete it or send it on its way. Mail in the processing queue can be scanned for virus signatures, and if such signatures are detected, the mail can be simply logged, bounced back to the sender, or quarantined. If quarantined, Mail Gateway can automatically inform the administrator, the sender and the recipients if required.
Mail Gateway uses the Trend AV engine, and the software automatically checks for new pattern signature files at specified intervals, and downloads new ones as they appear. When a user changes e-mail address for some reason or even leaves the company altogether, rather than simply bounce messages for the old address, the Relocated User feature will automatically inform the sender of the change. The Mail Gateway can translate internal mail addresses into alternate mail addresses, or it can translate a single mail address into multiple addresses via the Mail Aliasing facility. The most obvious use for this would be to provide “generic” contact addresses such as “[email protected]” or “[email protected]” which are then routed automatically to the appropriate personnel internally. The final option from the main menu is Maintenance, which provides the means to view the status of the Gateway server, view and modify the contents of the mail queues, process quarantined messages, view the extensive system logs, apply software updates and license keys, and reboot or shutdown the server. BorderPost is an HTML mail client that can provide access to internal mailboxes via the IMAP protocol from anywhere on the Internet or intranet via any standard Web browser.
It has a clean, intuitive user interface, and provides all the features you would expect of a mail client including folders and address book, as well as the ability to process mail messages (read, copy, delete, compose, reply, and forward). Access to the BorderPost facility is controlled by the administrator, and to use it, each user much have a mailbox defined on the Mail Gateway with a user name and password against which the user is authenticated when he logs on. If the administrator has specified that the Gateway Web server will use SSL, then all remote mail sessions are encrypted automatically. Although many mail servers provide remote browser-based access to e-mail, BorderPost provides an additional feature which makes it extremely valuable in larger organisations. Not only can it provide access to mailboxes defined on the Gateway itself, but the administrator can also provide a list of IMAP-compliant mail servers within the organisation to which BorderPost can also provide access. When the user logs on to BorderPost, it is possible to specify from a drop-down menu box which server should be used as the basis for the folders displayed on screen.
Thus, in complex deployments of multiple different mail servers (to which the Mail Gateway can route messages automatically) BorderPost provides a single, integrated inbox that allows users to access all those servers from a single interface. Securing e-mail servers is not the most straightforward of tasks even in the simplest of deployments. Where organisations have deployed multiple mail servers in different offices or departments, securing them all and presenting a common view to the outside world can become extremely complex. BorderWare Mail Gateway provides a dedicated secure store-and-forward mail relay out of the box, one which can run in parallel with the corporate firewall, thus further simplifying the firewall rule set as well as increasing security for SMTP traffic in the process. It offers a store-and-forward relay operating through a secure SMTP proxy that is based on the proven BorderWare firewall technology, and provides a number of additional capabilities – such as attachment control and anti-virus scanning at the Gateway - in order to prevent malicious e-mails from ever entering the internal mail system. Finally, it also provides a unified view of all internal mail servers that can be accessed via a standard Web browser from anywhere on the Internet or intranet through the BorderPost HTML mail client. Remote Web-based access to e-mail can be a boon to any organisation, but the ability to consolidate messages from multiple internal mail servers will make this a must for larger organisations with complex mail deployment strategies. BorderWare Mail Gateway 1.1 is highly recommended, and earns the “NSS Approved” award.
Contact:
BorderWare Technologies Inc |
Security Testing |
Send mail to webmaster
with questions or
|
