Messaging Software Protocols
As with the system security, the messaging software security also has layers of its own, which can be separated into the following components:
Directory
Message Store
MTA
Proxy
Directory
There are several aspects of securing the directory beyond securing the basic server and operating system. These aspects are:
Search limits— how many responses and how much time can be spent searching
Non-standard ports— not using ports 389 or 636 for LDAP or LDAP over SSL
This is not an exhaustive list of directory security issues, but it covers most of the options to secure the Directory Server protocols and access using these protocols.
ACI
Access control instructions (ACIs) are basically permissions. The Directory Server provides a mechanism by which you define access. When the server receives a request, it uses the authentication information provided by the user in the bind operation and the ACIs defined in the server to allow or deny access to directory information. The server can allow or deny permissions such as read, write, search, and compare. The permission level granted to a user may be dependent on the authentication information provided.
Using access control, you can control access to the entire directory, a subtree of the directory, specific entries in the directory (including entries defining configuration tasks), or a specific set of entry attributes. You can set permissions for a specific user, all users belonging to a specific group or role, or all users of the directory. Finally, you can define access for a specific location such as an IP address or a DNS name.
Chapter 6 of the iPlanet Directory Server Administration Guide provides details on configuring and establishing ACIs.
The two or three most common changes or customizations are for customers to change permissions (ACIs) for:
Self
Anonymous
General access
Some customers, for example, do not want anyone to be able to change their own entry information. For this, an ACI can be created to restrict (deny) change privileges to “self.”
Other customers want anonymous (anyone) to see only the person's name, phone number, and email address—nothing else. Again, an ACI can be created for “anyone” to be able to only see the common name, phone number, and email address.
General access can control authenticated users' access to the directory, so even if they successfully log in, they can see more than “anyone” but less than “self,” for example. An ACI modification or creation can do this too.
Other conditions that can be taken into consideration when creating ACIs include time of day, day of week, IP address, and DNS name.
ACIs are a powerful way to control access to the directory, if properly configured, but can also be a problem if poorly done since they can impede other software from working correctly.
Search Limits
One of the newer features of the Directory Server is the ability to limit search limits and time spent searching for different types of users. Previous versions only provided for one overall limit, not multiple limits.
These limit features provide the ability to configure both size limit (number of entries returned) and time limit (maximum amount of real time in seconds the server should spend performing a search request) as not only a system default, but also at a finer-grained level. For example, you can configure the Directory Server so that “anyone” or unauthenticated users can only retrieve five entries and spend 20 seconds searching, while “general access” users (for example, those who have authenticated successfully) can retrieve 50 entries and spend 180 seconds searching.
The Directory Server allows you to specify resource limits, including sizelimit, timelimit, lookthroughlimit, and idletimeout down to the per-user level. This is documented online at:
http://docs.sun.com/source/816-5606-10/password.htm#1085603.
Enabling SSL Support
Enabling SSL support for the Directory Server is the first step in providing secure access using LDAP over SSL for queries and responses. Enabling SSL by itself does not configure the other servers to take advantage of it, however. Additional configuration typically must be done. Enabling SSL simply turns on the Directory Server's ability to encrypt LDAP using SSL over the network, so where LDAP is normally on port 389, LDAP over SSL is typically on port 636 (either of which can be changed).
The caveat on enabling SSL for anything is certificate management. A certificate (key) must be generated and imported into the server. For specific instructions, see Chapter 11 of the Sun ONE Directory Server Administrators Guide. Also, the personal identification number (PIN) or password for the certificate must be entered to start the server. This PIN can be stored within a file, but it is done in cleartext, which provides some security issues and risks that must be assessed prior to doing so.
For details on managing SSL, see Chapter 11 of the Sun ONE Directory Server Administrators Guide.
Enabling SSL on the Directory Server will have some performance impact that must be taken into consideration when sizing. This depends specifically on the number of transactions and usage of the SSL-enabled LDAP ports. For example, if only ten percent of the transactions require SSL, use SSL only for these ten percent if possible. The Directory Server supports hardware acceleration of SSL workload, but this can add some additional configuration requirements and complexity.
Non-standard Ports
The Directory Server and Messaging Server provide the ability to use non-standard ports for LDAP and LDAP over SSL. While this prevents some basic default port scanning, it also means that all the software that access the directory must be configured to use the non-standard port numbers too, so this becomes slightly more difficult to manage and configure.
Message Store
From the Messaging Server software point of view, the security aspects on the message store are limited to the basic email protocols—POP, IMAP, SMTP, and HTTP (web mail), plus the administrative interfaces over HTTP.
SMTP
Configure the SMTP daemon on the mailstore (it is required to deliver mail to mailboxes) to only accept connections from the “official” MTAs. The MTA that on the mailstore is there just to deliver mail to mailboxes and users. The exception to this rule is for smaller configurations that want to have a consolidated or “all-in-one” messaging system where the MTA on the mailstore is the “official” MTA and the only MTA.
MTA
Several things can be done to make the MTA more secure, although this is really more of a configuration issue and depends upon the environment.
The biggest security feature for the MTA is to require authentication prior to sending an email. This is known as SMTP authentication or SMTP AUTH for short. This authentication requires that the sender have a valid login and password (account) on the messaging system, thus preventing users from sending email from anywhere, regardless of whether they are local (on net) or not. This also prevents people from sending thousands of emails out to the Internet using your MTA as a relay, though it does not prevent forged headers (see RDNS).
RDNS
Reverse DNS (RDNS) validates that the domain name from which the mail is purported to have been sent (sender's domain name) is at least registered, that is, valid. The setting within the Messaging Server that provides this capability is called mailfromdnsverify. This lookup only verifies the existence of the domain name in the DNS registry nothing else. Spammers and others can easily forge headers and the domain names can be registered/churned quickly. So, the debate is how useful RDNS really is at this point. In fact, it is only one feature of many that slows down spam and so forth.
Antivirus and Antispam
“Virus Scanning” on page 198 and “Antispam” on page 199 cover antivirus and antispam in more detail. Providing these services at the MTA level greatly enhances the overall security of the messaging environment.
Securing the Message Contents
Securing the message contents is usually the final step along the way in securing the mail system, and naturally the most difficult to implement for many reasons. PGP signing allows for the non-repudiation of a message—that is you can validate who it is from and the contents. SMIME is secure MIME, which actually encrypts the contents of the message.
While adding these options to your messaging system offers additional levels of security, it also adds significant levels of support and administration as well. Extra consideration must be given when implementing digital signing or message encryption.
▾ Implementing PGP Signing
Pretty good protection (PGP) signing (digital signing) is simpler to do than message encryption (sometimes referred to as SMIME) by far, but it does not prevent access to the contents. It does allow you to confirm the identity (signature) of the sender and verify that the contents of the message (but not headers) have not been tampered with (non-repudiation).
The Online help for Mozilla v1.3a states:
digital signature. A code created from both the data to be signed and the private key of the signer. This code is unique for each new piece of data. Even a single comma added to a message changes the digital signature for that message. Successful validation of your digital signature by appropriate software not only provides evidence that you approved the transaction or message, but also provides evidence that the data has not changed since you digitally signed it.
PGP is a public-private key system. That is, there are two keys, one private key that only the user knows and one public key that anyone can find out by looking it up in a directory. By using the combination of these keys, you can encrypt and sign documents meant for either public consumption or just one other individual. PGP signing operates slightly differently for each platform such as Windows, Solaris OE, or Linux and so forth, but overall it operates in a very similar manner.
For an overview of PGP, see:
http://www.pgpi.org/doc/overview/.
To implement PGP signing:
1. | Obtain
PGP
software. |
2. | Install
PGP
utility. |
3. | Generate key pair—your public and private key. |
4. | Create email. |
5. | Cut and paste email into PGP
utility to generate
PGP
signature (checksum). |
6. | Cut and paste
PGP
signature to bottom of email. |
7. | Send email. A good tutorial on the whole process is available at: http://www.haltabuse.org/pgp/index.shtml. |
Some email clients support PGP signing natively, basically calling a PGP utility and performing the operation for the user. Some examples include:
Ximian (http://www.ximian.org), KMail (http://devel-home.kde.org/~kmail/index.html),
Postilion (http://www.postilion.org/) and
These utilities may be slightly out of date. Plug-ins for Mozilla and Netscape 7, such as Enigmail, are also available.
A more complete list is located at:
http://email.about.com/cs/openpgpsoftware/.
The Messaging Server web mail interface can be customized to perform PGP signing automatically, but this takes some effort and requires that the PGP keys be stored inside the Directory Server so they can be accessible for both the web mail client and the public.
PGP or digital signing has little impact on the server itself because the client mainly performs the work. An exception is if the web mail is customized to perform the key calculation, this added workload must be considered when sizing the server. It does add some additional length to each message signed—roughly 512 characters or so. While this is not very much, it can increase the overall storage and throughput requirements if every message is signed.
SMIME
SMIME goes beyond simply computing a checksum based upon the message content and your private key. This includes encrypting the entire message so it cannot be read. Again, this requires encryption software and often a thick client, though the Messaging Server web mail client can be modified to perform SMIME (see also Implementing PGP Signing).
The main issue with SMIME versus signatures is that you must unencrypt the message and attachments to be useful with SMIME, whereas with signatures you may only have to validate the sender if you suspect the message has been tampered with or the source is not genuine.
SMIME has a significant impact on the sizing of the server if the web mail client is customized. If thick clients perform most of the work of encryption and decryption, the impact is typically with the overall increase in the size of the message.
SMIME or encrypted messages are the only methods of ensuring privacy from even system administrators—as much as possible, since no encryption is completely unbreakable given enough time and computing power.
This book refers to PGP or Open PGP, but the message contents can also be secured by using X.509 Certificates.