| Oracle® Email Administrator's Guide Release 2 (9.0.4.1) Part Number B10720-02 |
|
|
View PDF |
| Oracle® Email Administrator's Guide Release 2 (9.0.4.1) Part Number B10720-02 |
|
|
View PDF |
This chapter discusses Oracle Email system security.
This chapter contains the following topics:
E-mail system security has many aspects and implications. Each component of the system has potential vulnerabilities in addition to possible breaches through user error or violation of documented security policies. Examples include careless password management or cooperation with deceptive phone calls purporting to be from IT workers.
Security issues include:
Each core component of an email system has unique security issues and vulnerabilities that you must address in designing your system and security policies. Security decisions must often balance the goals of maximum protection and unlimited access. Most decisions that increase security inevitably reduce the level of access for ordinary users.
The core components are the message store, the middle tier, the identity management infrastructure, and the mail clients.
Table 5-1 describes the elements providing security in the message store.
In the middle tier, more vulnerabilities arise, because this is the access point for most users. Security concerns and ease of use for normal end-users must be balanced based to build a workable implementation.
Since protocol servers, such as IMAP, POP, or SMTP, are potential targets for attack by hackers looking for security weaknesses, you should enable only the protocols you require. Where appropriate, enforce authentication for all client connections, and consider using SSL for the underlying network connection. For SMTP, authentication can prevent inbound mail traffic. In this case, ensure that the anti-spam, anti-relay, and anti-virus controls are setup appropriately to minimize the risks posed by incoming mail traffic.
For HTTP servers, only minimum information should be available through any web servers giving access through web clients. Lock down access to any URL except for the thin client. To protect the security of e-mail date and password, enable SSL access only through the thin clients.
Providing adequate security of the middle tier, particularly the SMTP server, can be problematic because by design, SMTP accepts and routes inbound traffic to its destination. While this design makes mail exchange possible, it also provides possible avenues of attack. Restrictions in the openness of the SMTP server should be weighed against the loss of usability.
SMTP mail is inherently insecure because it enables users to negotiate directly with receiving and relaying SMTP servers. Sophisticated users can create messages that will trick a naive recipient into believing that they came from somewhere else. Constructing such a message so the trickery cannot be detected by an expert is more difficult, but not so much as to deter a determined and knowledgeable hacker.
Consequently, as knowledge of Internet mail increases, so does the knowledge that, at the transport level, SMTP mail inherently cannot be authenticated, nor can integrity checks be provided. Real mail security lies only in end-to-end methods that secure message bodies by using digital signatures, such as PGP or S/MIME.
This infrastructure controls and manages all aspects of directory, authentication, and single sign-on (SSO) operations.
Database security rules protect the underlying Oracle9i instance. Middle tier and storage servers, as well as web clients, must access this information to operate. Access is required though LDAP and possibly HTTP/HTTPS, and access to these protocols should be limited to only those servers truly requiring such access.
If web clients are deployed on the public Internet, the SSO components should be implemented on servers separate from the rest of the infrastructure. This separation makes it possible to provide protection for these components behind firewalls.
Because end user passwords are managed by the infrastructure, password policies should be maintained, such as enforcing acceptable password sizes, randomness, and frequency of change.
Unused or inactive mailboxes should be routinely cleaned or locked to minimize the risk of unauthorized use.
Most mail clients have configuration options enabling support for increased levels of security when connecting to the server. For example, support for connections over SSL and protocol authentication can require special configuration. Ensure that users are aware of risky behaviors, such as storing passwords in ordinary files on PCs, and the configuration options or changes required to minimize those risks.
Security features of the product enable separate components to be configured securely. The more restrictive access to an organization's network is the messaging system's security. Ensuring that the rest of your intranet is secure reduces the chances of unauthorized attempts to access components of the messaging system.
Firewalls play a large role in protecting the security of your implementation. Firewalls must be configured appropriately, with more than firewall in place, and regularly monitored for intrusion. It is important not to assume that everything is safe because you have deployed a firewall.
You have to determine what protocols to enable at the various points in your network. This decision often requires evaluating the trade-off between providing wide access to legitimate users and yet still protecting vulnerabilities from unauthorized use.
At a minimum, sending and receiving e-mail messages from the Internet requires that you enable inbound and outbound connections through port 25, the default SMTP connection socket. For other protocols, such as IMAP and POP, determine whether enabling public Internet access is worth the risks and cost. The risks include unauthorized access, and the costs include extra configuration and administration to maintain this infrastructure. In a typical enterprise, such access is not required, and all protocol tiers can be well protected within an intranet environment. Access for non-office based workers can be managed through a separate VPN or remote access infrastructure.
If you enable access through any of these protocols from the Internet, then security can be improved by using authentication and SSL. Authentication provides some protection to the protocols, and SSL aids data encryption of network traffic.
The storage component of Oracle Email should be located behind any firewall implementation, with minimal access through SQLnet from the middle tier processes in other parts of the DMZ.
You should close down all firewall access other than explicitly required port and host connections. Closely managing and minimizing potential security vulnerabilities is a key part of any secure configuration.
Never assume that implementing a secure configuration means no new vulnerabilities and risks can arise. Watch for security updates from Oracle and security updates affecting Internet protocols to ensure that you maintain a secure environment.
Any security implementation is only as good as its users' awareness of security issues. Many security breaches are the result of simple human factors allowing intruders to gain access to user accounts through simple human deception. Administrators must keep the following factors in mind:
Establish security policies for each level of security that applies to different parts of your system, including who has access to them and how to respond to security breaches.
Secure Sockets Layer (SSL) is a protocol for transmitting private documents over the Internet. SSL works by using a public key to encrypt data that is transferred over the SSL connection. Many Web sites use the protocol to obtain confidential user information, such as credit card numbers. By convention, URLs requiring an SSL connection start with https: instead of http:.
For servers to communicate securely with clients, customers installing Oracle Email must obtain an SSL Server Certificate for each machine and configure its network listener to use that certificate.
| See Also::
Chapter 16 of the Oracle Advanced Security Administrator's Guide, for how to use the Wallet Manager to create a wallet and store SSL certificates |
|
NOTE: You must have a separate certificate for each machine on which the protocol server processes run. A single certificate can support all protocol server processes on one machine. |
In the Oracle environment, you can use the Oracle Wallet Manager for secure creation and storage of certificates and the corresponding private keys.
To obtain a certificate, use the Wallet Manager as described in the Oracle Advanced Security Administrator's Guide. The general steps are as follows:
This creates a cwallet.sso file in addition to the ewallet.p12, that is the actual wallet. The files can be found in the following location:
/etc/ORACLE/WALLETS/userid.
During installation, the listener.ora file is updated with the required SSL and non- SSL listening end points for both the IMAP4 and POP3 servers. Users only need to set the wallet location in the listener.ora and the sqlnet.ora files, along with any optional SSL parameters, for the listener to receive SSL connections. These settings can be done manually or by using the Oracle Network Manager.
Add the following WALLET_LOCATION and SSL_CLIENT_AUTHENTICATION entries in the beginning of the $TNS_ADMIN/listener.ora and $TNS_ADMIN/sqlnet.ora files:
WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = <Directory path containing the cwallet.sso file>) ) ) SSL_CLIENT_AUTHENTICATION = FALSE
A typical directory parameter value looks like the following line:
/etc/ORACLE/WALLETS/<userid>
If the SSL_CLIENT_AUTHENTICATION parameter is not set, the default setting is TRUE and clients are required to present a certificate during the SSL handshake. If the intent is only to secure the communication, not to authenticate the client using the certificate, then this parameter should be set to False.
| See Also:
Chapter 7 of the Oracle Advanced Security Administrator's Guide to set the wallet location using Oracle Network Manager |
IMAP and POP protocol servers can be configured to use SSL for securely communicating with and authenticating clients. To use the SSL client connections, administrators can configure an existing server instance or create a new instance.
Two separate server instances are necessary to use both SSL and non-SSL connections. One server instance cannot manage both types of connections. By default, server instances are configured to manage Internet connections only. The default listening end points for both IMAP and POP protocol servers are created in the listener.ora file during installation.
To configure a SSL server instance, do the following steps:
If you select Custom:
SSL Enabled parameter to TRUE and verify that there is a description entry in the listener.ora file for the presentation name you specified. Verify that protocol is set to TCPS and that the PORT set to the default SSL port number of the protocol.The default SSL port number for IMAP is 993. The default SSL port number for POP is 995.
All server process instances have a description parameter. The following parameter shows a sample set of configuration options:
-sslenable=yes -sslport=3061 -sslwalletloc=file:/directory_ name/oracle/work/genwallt/client -sslwalletpassword=welcome12 -sslmode=3
Where:
sslenable has two possible values: yes or nosslport is the port on which Oracle Internet Directory is listening. Oracle Internet Directory should be configured to listen on both SSL and non-SSL modesslwalletloc is the location of the client wallet in the file system.sslwalletpassword is the password used to access the wallet.sslmode: valid values are
1: SSL without authentication is performed (no PKI certificate exchanges), only channel encryption and data integrity2: One-way authentication is performed. For example: Oracle Internet Directory server authentication3: Both the client protocol servers and Oracle Internet Directory server authentication are performedIf any values are not stored correctly, a non!-ssl mode of auth occurs.
| See Also:
Oracle Internet Directory Administrator's Guide for more information regarding Oracle Internet Directory SSL. |
Perform the following steps to configure SSL for Oracle Webmail:
toolkit.properties file, set the oracle.mail.ldap.connectssl=true/false property to true.oracle.mail.ldap.connectssl=true/false property in the $ORACLE_HOME/oes/admin/oesadmin.properties fileThe NNTP and SMTP servers support a variety of anti-spam methods to prevent users and domains from misusing the e-mail system. Examples include flooding the e-mail system with undesired, unsolicited messages, and using the server as a spam relay for other domains.
A third party anti-spam filter agent can be run in front of the SMTP server to check whether incoming messages are spam. After completing the spam check it passes the mail to the SMTP server. Anti-spam filters are configured to either reject spam mails or to change or add headers to indicate that the mail could be spam.
This release of Oracle Email does not process any specific spam headers. However, because the format and values of the new headers are known, a user can set up server-side or client-side rules to move spam mail out of the INBOX or delete them based on certain criteria.
If the third party spam filter and SMTP server are running on the same machine, the filter should listen to the default SMTP port 25. The SMTP server listens to a different port. When e-mails come into the system, the spam filter filters the mail and takes action on it. If the mail passes the spam check, it is sent to the SMTP server. The communication between the third party spam filter and SMTP server must be done over SMTP protocol.
The SMTP server supports native anti-spam checks, which are more efficient than third party anti-spam filters because they eliminate the costs of external agent execution and passing mail. Checks are performed on each input from the sender to identify spam mails at an earlier stage. Native anti-spam checks do not analyze message contents, but all e-mails are checked for the following:
The server supports two types of settings: an acceptance list and a rejection list. The values in these lists are domains, IP addresses, and senders. The appropriate accept and reject list is checked against the SMTP command being processed.
Anti-spam checks are performed during the following operations:
HELO/EHLO, MAIL FROM, RCPT TO
Typically, SMTP servers inside a firewall do not need to have anti-spam checking enabled. Outside the firewall, however, servers receiving inbound e-mail messages need anti-spam protection.
Oracle Email servers have a global native anti-spamming parameter that is checked by each instance. If this value is set to FALSE, anti-spam checking does not take place and all other parameters for anti-spam are disabled.
If native anti-spam is set to TRUE, the following steps occur:
Accept Connections from IP Addresses: If the IP address is trusted, then the process continuesReject Connections from IP Addresses: If the IP address is here, the message is rejected and the connection is closedAccept Connections from Host Domains: If the domain name of the computer is trusted, then the process continues. The domain name is obtained through a reverse DNS lookup of the IP addressReject Connections from Host Domains: If the domain name is in this list, then reject the message and close the connectionPrevent Service Denial Attack: The number of messages plus the number of connection requests from this host within a time interval that is considered to be floodingSpam Flood Interval: The time interval, in minutes, used in conjunction with Spam Flood Count parameter to determine whether a host spammingHELO or EHLO command is performed. This is the initial command performed before any work can begin on the SMTP server. When this command is entered, a domain name is passed as part of the command. The following parameters are set:
Accept Connections from IP Addresses: If the IP address is trusted, the process is continuedAccept Connections from Host Domains: If the domain name of the computer is obtained through reverse DNS lookup of the IP address are trusted, then the process continuesEnable HELO DNS Check: If this parameter is set then the domain name in the helo/ehlo command is checked for existence in the DNS server. If it does not exist, the connection is rejectedMAIL FROM command is verified. This command contains the e-mail address of the sender. This address can be checked for spam. The following parameters are set:
Accept Connections from IP Addresses: If the IP address is trusted, the process is continuedAccept Connections from Host Domains: If the domain name of the computer is obtained through reverse DNS lookup of the IP address are trusted, then the process continuesReject Connections from Sender Domains: If the domain name part of the sender's e-mail address is in this list, the message is rejected and the connection is closedReject Connections from Sender: If the sender's e-mail address is in this list, the message is rejected and the connection is closedAccept Connections from Sender Domains: If the domain part of the sender's e-mail address is in the list, the process is continuedAccept Connections from Sender: If the sender address is a trusted address, the process is continuedEnable Sender DNS Check: If this is enabled, then the domain in the sender's address is checked to determine if it exists in the DNS serverPrevent Service Denial Attack: The number of messages plus the number of connection requests from this host within a time interval that is considered to be flooding.Spam Flood Interval: The time interval, in minutes, used in conjunction with Spam Flood Count to determine whether a host is spamming.RCPT TO command is verified. This command contains the e-mail address(es) of the recipient(s). This check is dependent on several parameters and differs depending on the mail destination. Again if the sending computer is trusted then the mail continues. Then each recipient is either a local user or the mail message needs to be relayed to another SMTP server. If the mail is going to be delivered to a local user, then a check for rejected recipients is made. If the mail is to be relayed, then we check to make sure the server is allowed to relay, or allowed to relay conditional upon the domain the mail is going to as well as if the connection was initially authenticated.
Accept Connections from IP Addresses: If the IP address is trusted, the process is continued.Accept Connections from Host Domains: If the domain name of the computer or the domain name sent as part of the connect request are trusted, the process is continued.Accept Connections from Sender Domains: If the domain part of the sender's e-mail address is in the list, the process is continued.Accept Connections from Sender: If the sender address is a trusted address, the process is continued.Reject Recipient: This parameter list is only used for local delivery mail messages. If the recipient name is in this list, then message is rejected and the connection is closed. This is useful for temporarily suspended accounts or restricted distribution lists.Relay Allowed: This parameter is only used for relay delivery of mail messages. The possible values are:
Relay Domains Allowed: This value only reads relay mail messages when the Allow Relay parameter is set to True. This parameter provides a list of domains that the SMTP server allows to be relayed. If relaying for all domains is allowed, the parameter must be set to an asterisk (*).The NNTP server supports native anti-spam checks, which are based on the following:
NNTP and SMTP wildcard support exists on prefixes for domains and suffixes for IP addresses, to allow sub-domains and sub networks with a single entry. Entries containing only an asterisk (*) on a line by itself means all domains or IP addresses.
For example:
Valid entries *.foo.com (all sub-domains of foo.com), *.*.foo.com, 99.99.99.* (any host with IP address having a prefix 99.99.99);
Invalid entries: *.foo.*.com (domain), 99.*.99.* (IP).
The following table describes the Oracle Email native anti-spam parameters for NNTP and SMTP:
The Oracle Email SMTP server and message store support plug-ins for third party anti-virus solutions to detect and cleanse, or delete potentially destructive messages. The message store has the capability to re-scan messages already in the store for potential virus. There are two ways to integrate with the virus scanner:
The SMTP server provides a way to integrate external processes to the server. The SMTP server for each mail calls this process for each mail process. Both the message body and envelope are passed through the process. The external process can then apply its own filtering mechanism and pass back a success or a failure message to the SMTP server. If a failure message is received from the external filter, the message is rejected. The external filter can also pass modified mail back to the server and that is delivered to the recipients. If the external process fails, the messages are queued and retried after the queue retry interval.
Configure the following parameters to set up external filter processing:
External Filter: A Boolean that indicates if external filter processing is turned on.External Filter Process: This parameter must be in the following format:
name:path_name when_to_call flags
where:
The call to the external process has the following syntax:
Filter_process host=host mailfrom=mailfrom rcptto=[#_of_recipients] msgsize=[msg_size]
where:
After the filter process has finished processing the mail, it should return the status and the changed message back to the server. This is done by writing the following information to its standard output (stdout)
status_code [version_definition] repaired message
where:
In addition to external process callouts, the SMTP server can call C language procedures. These procedures can be used as an inexpensive and efficient way of filtering mails. The C callouts that are implemented can obtain various message parts, such as envelope, size, and message text, through the API provided by the server. The procedure then filters and returns a reject or success with an optional modified message to the server.
Since these are linked with the server there is no overhead in the calls. But at the same time care must be taken while implementing these since they share the same process and memory space as the server. Any corruption affects the server. Each callout needs to implement a pre-defined set of functions. These functions are called by the server to initialize, send message and receive status and message back from the callout. The callouts can be specified by setting values in the Scanner Interface parameter. Multiple callouts can be specified and are called in sequence.
Each callout is specified as:
name:shared_library_path, when_to_call, [internal | host:port], (init, register_ callback, scan_msg, send_msg, receive_msg, close),scanner_flag,system_flags
where:
The Oracle Email SMTP server and mail store can integrate with the Symantec Anti Virus Scan Engine (SAVSE). This enables Oracle Email to use Symantec's virus knowledge base to detect and cleanse infected messages at the SMTP level and the mail store.
> Anti-Virus.The Oracle Email virus scrubber is a server process that scans for and cleans up virus-infected e-mail messages already in the message store. When rapid measures are required to immediately cleanse a system of virus-infected messages, the virus scrubber pre-scans a message store to isolate suspect messages already there based on headers such as subjects or attachment names. Pre-scanning isolates suspect messages so that users are not able to access them and possibly cause damage. Pre-scanning never deletes a message. After pre-scanning, the virus scrubber uses the external scanner to individually scan the isolated messages. A message that is deemed clean or repaired by the virus detection software is restored to its original folder.
|
Note: Although pre-scanning is a faster way to isolate suspect messages in a message store than scanning all individual messages, it can quarantine clean messages. |
If a message is identified as infected and not repairable, the administrator can either delete the message immediately or quarantine it to a special folder for later processing. For example, an infected message can be quarantined to wait for a future release of virus definitions that may be able to repair the message. Oracle Email can be configured to send a message to either the mail recipient or sender notifying them that it was identified as infected. Such notifications are useful to explain to users why their messages disappeared.
The virus scrubber is different from the SMTP based virus scanner that filters out virus-infected messages before they enter the system. The Oracle Email virus scrubber is a necessary complement to the SMTP virus scanner because new types of viruses continue to pop up before virus detection software can be updated to detect and repair them. There's always a possibility that by the time virus software is updated, some infected messages have already entered the system. The virus scanner can be used to retroactively rid the system of such viruses. This message store-based scanner can also be used to scan viruses coming in through a non-SMTP route such as IMAP append.
The Oracle Email virus scrubber and SMTP-based virus scanner rely on external virus detection and cleanup software such as the Symantec AntiVirus Scan Engine. Oracle Collaboration Suite provides interface libraries for third party virus tools to integrate with Oracle Email. The third party virus software must be installed properly for the virus scrubber server to be fully functional.
The virus scrubber can be run as either a daemon process that runs forever or a standalone process that runs once and exit. A typical process configuration may contain one process configured as a daemon that wakes up and scan the message store monthly and another instance configured as a standalone server that can be run on demand.
The virus scrubber log files are located in the following directories:
On UNIX:
$ORACLE_HOME/oes/log/install_name/vs/pid/pid.log
On Windows:
%ORACLE_HOME\oes\log\install_name\vs\pid\pid.log
To run the virus scrubber, use oesctl startup with a service type of vs.
oesctl startup target | instance
For the virus scrubber, the syntax for target is
hostname:um_system:service_type
where hostname is the name of the server on which the process should run service_type vs
The syntax of instance is target:instance_ID
where instance_id is a number assigned to an instance when it is created. These numbers are selected automatically at instance creation time. Instance numbers cannot be configured by administrators.
To start the virus scrubber for all registered processes for the server named Acme, enter the following command:
oesctl startup acme:um_system:vs
To start the virus scrubber for the process with ID 104750025197124824 on the server named Acme, enter the following command:
oesctrl startup acme:um_system:vs:104750025197124824
| See Also:
Chapter 8, "Command Line Interface" for more information on |
E-mail viruses typically have the form of an executable program, such as an e-mail attachment. The program is executed on the client machine when the attachment is opened by an unsuspecting user, causing various forms of damage to the computer or the network. Oracle Email provides several different tools of virus protection, each of them suited for a different type of administration requirement.
The Oracle Email server SMTP inbound process provides integration with third party virus scanning software to scan each message that passes through the SMTP server. The server rejects the message upon arrival, preventing the virus e-mail from entering the email system.
If third party virus scanning software is not available, Oracle Email server can still reject virus messages using server side rules. Server side rules reject incoming messages based on suspicious subject lines, attachment names or sender information.
| See Also:
Chapter 8, "Command Line Interface" for more information on how to create system wide rules using |
If there is a virus outbreak before the SMTP server has a chance to upgrade itself to use the latest third party software, then some virus e-mail messages are already present in user's mailbox. The Oracle Email virus scrubber process can be used to scan the entire message store, repair or remove virus e-mail messages once the third party software is upgraded to date.
Oracle Email has a simple PL/SQL utility package MAIL_AV that scans the message store based on simple message attributes such as subject line and attachment names. To use this package, one simply writes a SQLPLUS script that uses this package or execute procedures in this package directly from SQLPLUS.
| See Also:
Chapter 8, "Command Line Interface" for more information on how to create system wide rules using |
Usage Examples
The following are summaries and usage examples for the procedures in the MAIL_AV package:
The quarantine procedure has the following syntax:
PROCEDURE quarantine (p_endday IN DATE, p_dayrange IN NUMBER, p_attribute IN NUMBER, p_pattern IN VARCHAR2, p_folder IN VARCHAR2);
The quarantine procedure identifies virus messages using a given pattern and moves them to a designated folder. The caller of the procedure must have write authorization to the folder. Authentication is done by using MAIL_SESSION package.
The p_endday and p_dayrange parameters can be used to narrow down the virus search to within certain time frame. The p_attribute parameters takes one of the following three values:
MAIL_AV.ATTR_SUBJECT MAIL_AV.ATTR_ATTACHMENT MAIL_AV.ATTR_SENDER
The p_pattern parameter is the identifying string for the virus. The p_folder parameter is the designated folder name to which virus-infected messages are moved.
The following example logs in as user SYSADMIN, and scans the whole mail server for messages with an attachment name containing.exe within the last seven days, and moves them to the /infected folder.
declare sessionid number; begin mail_session.login('sysadmin', <password>, <ldaphost>, sessionid); mail_av.quarantine(sysdate, 7, mail_av.attr_attachment, '.exe', '/sysadmin/infected'); end; /
The Quarantine procedure can take on the following format enabling IMAP style search criteria:
PROCEDURE quarantine (p_criteria IN VARCHAR2, p_folder IN VARCHAR2);
This quarantine procedure form identifies virus messages using an IMAP style search criteria for enhanced searching. All IMAP search commands are supported. The advantage of using this procedure not only includes the expanded list of search item, but also the ability to combine search criteria using logical operations such as "and" or "or."
| See Also:
Internet RFC 2060: Internet Message Access Protocol, version 4, rev 1, for more information on IMAP search commands |
Use the new form of quarantine procedure, the following script identifies and moves messages with subject "snow white" and from acme.com, that's also sent since January 2002:
declare sessionid number; begin mail_session.login('sysadmin', <password>, <ldaphost>, sessionid); mail_av.quarantine('SINCE 01-Jan-2002 SUBJECT "snow white" SENDER "aol.com"', '/sysadmin/infected'); end; /
There are two procedures to restore quarantined messages back to their original folders:
PROCEDURE restore (p_messageid IN NUMBER); PROCEDURE restoreall;
The restore procedure takes a given message ID and restore it back to its original folder. If the message ID does not exist, the procedure does nothing. The restoreall procedure restores all messages quarantined regardless which designated folders are used to store the messages. These procedures are useful when a message is wrongly identified as a virus message and must be restored back to its recipients.
