This chapter provides an overview of Oracle Communications Messaging Server security.
The following principles are fundamental to using any application securely:
Keep software up to date. This includes the latest product release and any patches that apply to it.
Limit privileges as much as possible. Users should only be given the necessary access to perform their work. User privileges should be reviewed periodically to determine relevance to current work requirements.
Monitor system activity. Establish who should access which system components, how often they should be accessed, and who should monitor those components.
Install software securely. For example, use firewalls, secure protocols (such as SSL), and secure passwords. See "Performing a Secure Messaging Server Installation" for more information.
Learn about and use Messaging Server security features. See "Implementing Messaging Server Security" for more information.
Use secure development practices. This applies to customers adding plug-ins or custom code to a Messaging Server deployment. For example, take advantage of existing security functionality instead of creating your own application security.
Keep up to date on security information. Oracle regularly issues security-related patch updates and security alerts. You must install all security patches as soon as possible. See Critical Patch Updates and Security Alerts on the Oracle website at:
http://www.oracle.com/technetwork/topics/security/alerts-086861.html
To better understand your security needs, ask yourself the following questions:
Which resources am I protecting? In a Messaging Server production environment, consider which of the following resources you want to protect and what level of security you must provide:
Messaging Server front-end servers
Messaging Server back-end servers
Dependent resources
From whom am I protecting the resources? In general, resources must be protected from everyone on the Internet. But should the Messaging Server deployment be protected from employees on the intranet in your enterprise? Should your employees have access to all resources within the environment? Should the system administrators have access to all resources? Should the system administrators be able to access all data? You might consider giving access to highly confidential data or strategic resources to only a few well trusted system administrators. On the other hand, perhaps it would be best to allow no system administrators access to the data or resources.
What will happen if the protections on strategic resources fail? In some cases, a fault in your security scheme is easily detected and considered nothing more than an inconvenience. In other cases, a fault might cause great damage to companies or individual clients that use Messaging Server. Understanding the security ramifications of each resource helps you protect it properly.
You manage security for a Messaging Server deployment by taking a defense in depth approach. By individually securing the network, hardware platform, operating system, and applications themselves, you make each layer of the architecture secure. Security includes hardening each layer by closing unnecessary network ports and access mechanisms. You also minimize the number of installed software packages so that only those packages required by the system are available. Finally, you secure and insulate the layers from unintended access within the network.
You can implement a Messaging Server proxy server to augment data security. A proxy server placed on the firewall with the Messaging Server behind it prevents attacks on the information on the Messaging Server.
Note:
To ensure a completely secure environment, the deployment needs a time server to synchronize the internal clocks of the hosts being secured.For more information on Messaging Server security, see "Creating a Security Strategy".
This section describes common misconceptions that are counterproductive to the security needs of your deployment.
Hiding Product Names and Versions. At best, hiding product names and versions hinders casual attackers. At worst, it gives a false sense of security that might cause your administrators to become less diligent about tracking real security problems. In fact, removing product information and version numbers makes it more difficult for the vendor support organization to validate software problems because of their software or of other software. Hackers have little reason to be selective, particularly if there is a known vulnerability in SMTP servers, where they may attempt to access any SMTP server.
Hiding names of Internal Machines. Hiding internal IP addresses and machine names will make it more difficult to:
Trace abuse or spam
Diagnose mail system configuration errors
Diagnose DNS configuration errors
A determined attacker will have no problem discovering the machine names and IP addresses of machines once they find a way to compromise a network.
Turning off EHLO on the SMTP Server. Without EHLO you also lose:
NOTARY
TLS negotiation
Preemptive controls on message sizes
With EHLO, the remote SMTP client determines if you have a limit and stops trying to send a message that exceeds the limit as soon as it sees this response. But, if must use HELO (because EHLO is turned off), the sending SMTP server sends the entire message data, then finds out that the message has been rejected because the message size exceeds the limits. Consequently, you are left with wasted processing cycles and disk space.
Network Address Translation. If you use NAT to provide a type of firewall, you do not have an end-to-end connection between your systems. Instead, you have a third node which stands in the middle. This NAT system acts as a middleman, causing a potential security hole.
You can deploy Messaging Server on a single host or on multiple hosts, splitting up the components into multiple front-end Messaging Server hosts and multiple back-end hosts.
The general architectural recommendation is to use the well-known and generally accepted Internet-Firewall-DMZ-Firewall-Intranet architecture. For more information on addressing network infrastructure concerns, see the discussion about determining your network infrastructure in Messaging Server Installation and Configuration Guide.
The following guidelines provide specific recommendations for Messaging Server:
Secure your Messaging Server infrastructure by determining your Firewall/DMZ architecture. The following topics cover securing your Messaging Server infrastructure:
The planning of your network infrastructure layout in Messaging Server Installation and Configuration Guide.
The benefits of separating your network into two tiers: the public (user-facing) network, and the private (data center) network in Messaging Server System Administrator's Guide.
The use of MTAs to protect your Messaging Server deployment and to control the flow of message traffic to and from your site in Messaging Server Installation and Configuration Guide.
The two-tiered messaging architecture design that distributes hardware and software resources optimally for Messaging Server in Messaging Server Installation and Configuration Guide.
Note:
Your firewall/DMZ architecture solution might depend on your anti-spam solution and client capabilities. How you handle firewall and DMZ architecture depends on requirements for a geographically dispersed deployment and whether your deployment is targeted at individual end users or enterprises.Because the Webmail server (mshttpd) supports both unencrypted and encrypted (SSL) communication with mail clients, you might use a firewall between your Messaging Store and your mail clients for added security.
Some guidelines to consider:
If using a firewall, only allow Convergence server to connect to mshttpd (8990, 8991).
If using a firewall (preferably whitelist-based for Messaging Servers), verify internal service protocols are blocked (watcher 49994, job_controller 27442, ENS 7997, third-party authentication server, msadmind 7633, LMTP, Metermaid, and JMS).
The following topics describe how to set up a secure high availability and load balancing Messaging Server deployment:
Designing for service availability in Messaging Server Installation and Configuration Guide.
Configuring Messaging Server for high availability in Messaging Server Installation and Configuration Guide.
Availability planning for Cassandra message store in Messaging Server Installation and Configuration Guide for Cassandra Message Store
This section lists Messaging Server-specific OS security configurations. This section applies to all supported OSs.
In particular, pay attention to:
OS hardening, turning off unused OS services (especially in Linux)
OS minimization, using minimal OS packages
Messaging Server communicates with various components on specific ports. Depending on your deployment and use of a firewall, you might need to ensure that the firewalls are configured to manage traffic for each component.
Table 1-1 shows the default port numbers for various components.
| Component | Default Port Number |
|---|---|
|
SMTP |
25 |
|
POP3 or MMP POP3 Proxy |
110 |
|
IMAP4 or MMP IMAP Proxy |
143 |
|
LMTP |
225 |
|
LDAP |
389 |
|
SMTP SUBMIT |
587 |
|
Event Notification Service (ENS) |
7997 |
|
MSHTTPD |
8990 |
|
Job Controller |
27442 |
|
Watcher |
49994 |
|
SMTP/SUBMIT over SSL |
465 |
|
Event Notification Service (ENS) over SSL |
8997 |
|
LDAP over SSL |
636 |
|
IMAP over SSL or MMP IMAP Proxy over SSL |
993 |
|
POP3 over SSL or MMP POP Proxy over SSL |
995 |
|
MSHTTPD over SSL |
8991 |
|
managesieve |
4190 |
|
MTQP |
1038 |
You might need to specify a port number other than the default if you have, for example, two or more IMAP server instances on a single host machine, or if you are using the same host machine as both an IMAP server and a Messaging Multiplexor server. For more information about the Multiplexor, see the discussion about the Messaging Multiplexor (MMP) for standard mail protocols in Messaging Server System Administrator's Guide.
Keep the following in mind when you specify a port:
Port numbers can be any number from 1 to 65535.
Make sure the port you choose is not already in use or reserved for another service.
Close all unused ports, especially non-SSL ports. Opt for SSL-enabled ports, instead of non-SSL ports, for all communications (for example: HTTPS, IIOPS, t3s).
For more information about securing your OS, see your OS documentation.
Secure connections between applications connected over the Internet can be obtained by using protocols such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS). SSL is often used to refer to either of these protocols or a combination of the two (SSL/TLS). Due to a security problem with SSLv3, Messaging Server recommends the use of only TLS. However, throughout this guide, secure communications may be referred to by the generic term SSL.
In a Messaging Server deployment, you can enable the use of TLS between most components. See "Implementing Messaging Server Security" for more information.
To enhance client security in communicating with Directory Server, use a strong password policy for user authentication. For more information on securing Directory Server, see the discussion about Directory Server security in Oracle Directory Server Enterprise Edition Administration Guide.