| Oracle® Mail Administrator's Guide 10g Release 1 (10.1.2) Part Number B25499-04 |
|
|
View PDF |
| Oracle® Mail Administrator's Guide 10g Release 1 (10.1.2) Part Number B25499-04 |
|
|
View PDF |
This chapter discusses Oracle Mail security issues including antispam and antivirus solutions, Virus Scrubber, and virus management using PL/SQL scripts.
This chapter includes 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 information technology (IT) workers.
Security issues include:
Components of the e-mail system to identify the areas to consider when designing a secure architecture
Elements of security to consider in the design, such as password policies
This section includes the following topics:
Each core component of an e-mail 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.
This section discusses the following e-mail system core components:
The information storage database in an e-mail system consists of a database on which message bodies, message header information, and pointers to messages—for both incoming and outgoing messages—are stored. Oracle Mail employs the Oracle Collaboration Suite Database, an Oracle Database 10g database, to store all messages.
Table 6-1 describes the elements providing security in the message store.
Table 6-1 Security Components of the Information Storage Database
| Message Store Element | Security Feature |
|---|---|
|
Oracle Database 10g |
Traditional database security prevents unauthorized access. |
|
Data access management |
Normal database authentication mechanisms protect e-mail, too, and can be restricted to specific accounts or trusted users. |
|
Signed e-mail and S/MIME support |
Mail clients can provide e-mail security with digital signatures and S/MIME, part of an overall security strategy supported by Oracle to preserve message integrity. |
In the Oracle Collaboration Suite Applications tier, more security vulnerabilities arise because this is the access point for most users. Security concerns and ease of use for end users must be balanced to build a workable implementation.
Because 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 antispam, antirelay, and antivirus controls are configured 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. Secure access to any URL except for the thin client. To protect the security of e-mail data and passwords, enable SSL access only through the thin clients.
Providing adequate security of the Oracle Collaboration Suite Applications 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.
The identity management infrastructure controls and manages all aspects of directory, authentication, and single sign-on operations.
Database security rules protect the underlying Oracle Database 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 single sign-on 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, such as enforcing acceptable password sizes, randomness, and frequency of change, should be maintained.
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.
Simple Authentication and Security Layer (SASL) provides authentication support to connection-based protocols.
Configuring SASL for Oracle Mail includes using the Oracle Internet Directory administration tool and the Application Server Control Console to configure various parameters.
|
See Also:
|
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 one 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 must 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 virtual private network (VPN) or remote access infrastructure.
If you enable access through any of these protocols from the Internet, 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 information storage database should be located behind any firewall implementation, with minimal access through SQL*Net from the middle-tier processes in other parts of the demilitarized zone (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 human deception. Administrators must keep the following factors in mind:
Understand who has access to sensitive information
Understand that database administrators can generally access trusted level information
Implement password policies: minimum lengths, frequent changes
Remove unused accounts
Do not start unused services: run only what you need
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 information over the Internet. SSL works by using a public key to encrypt data that is transferred over the SSL connection from e-mail clients to the e-mail server. SSL secures traffic to the IMAP and SMTP servers, preventing anyone from accessing data on the network, including plain text password exchanges.
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:.
The primary goal of the Transport Layer Security (TLS) protocol is to provide privacy and data integrity between two communicating applications. The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. At the lowest level, layered on top of some reliable transport protocol, such as TCP, is the TLS Record Protocol. The TLS Record Protocol provides connection security that has two basic properties:
The connection is private
The connection is reliable
TLS enables the communication between either client and server, server to server, or both to be secured (more so than traditional SMTP which passes most of its data in clear text over its communication channel).
The security is negotiated between the two sides, so enabling it for a server does not force all other parties to use it, which is important because many mail servers might not support it or require it. Essentially, TLS allows users to use the best available security on their server.
|
See Also: "Securing Oracle Mail" in Chapter 2 of Oracle Collaboration Suite Security Guide for more information about enabling SSL for Oracle Mail |
The NNTP and SMTP servers support a variety of antispam 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.
This section includes the following topics:
A third-party antispam filter agent can be run in front of the SMTP server to check whether incoming messages are spam. After completing the spam check, the agent passes the mail to the SMTP server. Antispam 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 Mail 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 spam mail based on certain criteria.
Setting Up Third-Party Antispam Filters
If the third-party spam filter and SMTP server are running on the same computer, 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 antispam checks, which are more efficient than third-party antispam filters because they eliminate the costs of external agent execution and passing mail. Upon the result of these checks, messages are routed to various destinations, or are rejected, depending upon the configuration of the Oracle Mail installation.
Routing control checks are performed on each input from the sender to identify spam mails at an earlier stage. The checks do not analyze message contents, but all e-mails are checked for the following:
Sender's address
Sender's domain
Recipient's address
Recipient's domain
IP address of the sending computer
Domain of the sending computer
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.
Routing control checks are performed during the following operations:
When the SMTP connection is opened
When the client connects
After each SMTP protocol command, in the following order:
HELO/EHLO, MAIL FROM, RCPT TO
Typically, SMTP servers inside a firewall do not need to have routing control enabled. Outside the firewall, however, servers receiving inbound e-mail messages need antispam protection.
SMTP inbound and NNTP inbound servers have a global Routing Control parameter that is checked by each instance. If this value is set to Disabled, antispam checking does not occur and all other parameters for routing control are disabled.
If Routing Control is enabled, the following occurs:
The Internet Protocol (IP) address and domain name (based upon a DNS lookup of the IP address) of the requester are checked during the connection request to the server. The following parameters are checked:
Accept Connections from IP Addresses: If the IP address is trusted, the process continues.
Reject Connections from IP Addresses: If the IP address is here, the message is rejected and the connection is closed.
Accept Connections from Host Domains: If the domain name of the computer is trusted, the process continues. The domain name is obtained through a reverse DNS lookup of the IP address.
Reject Connections from Host Domains: If the domain name is in this list, the message is rejected and the connection is closed.
Prevent 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 the Spam Maximum Flood Count parameter to determine whether a host is spamming.
Spam Maximum Flood Count: SMTP server signals flooding if the number of messages and connections from a single host exceeds the value of this parameter within the Spam Flood Interval.
The HELO or EHLO command is processed. This is the initial command processed 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 continues.
Accept Connections from Host Domains: If the domain name of the computer, obtained through reverse DNS lookup of the IP address, is trusted, the process continues.
Enable HELO DNS Check: If this parameter is set, the domain name in the HELO/EHLO command is checked for existence in the DNS server. If it does not exist, the connection is rejected.
The information in the MAIL 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 continues.
Accept Connections from Host Domains: If the domain name of the computer, obtained through reverse DNS lookup of the IP address, is trusted, the process continues.
Reject 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 closed.
Reject Connections from Sender: If the sender's e-mail address is in this list, the message is rejected and the connection is closed.
Accept Connections from Sender Domains: If the domain part of the sender's e-mail address is in the list, the process continues.
Accept Connections from Sender: If the sender address is a trusted address, the process continues.
Enable Sender DNS Check: If this is enabled, the domain in the sender's address is checked to determine if it exists in the DNS server.
An additional check for flooding takes place. This is required because a single connection to a message transfer agent (MTA) can send multiple messages. A flood check is performed after each message is accepted.
Prevent 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 Maximum Flood Count to determine whether a host is spamming.
The default values for the preceding two parameters are as follows:
Spam Flood Interval=10 Spam Maximum Flood Count=10000
Spam Maximum Flood Count: SMTP server signals flooding if the number of messages and connections from a single host exceeds the value of this parameter within the Spam Flood Interval.
The RCPT TO command is verified. This command contains the e-mail addresses of the recipients. This check is dependent on several parameters and differs depending on the mail destination. If the sending computer is trusted, the mail continues. Then each recipient is either a local user or the mail message must be relayed to another SMTP server. If the mail is to be delivered to a local user, a check for rejected recipients is made. If the mail is to be relayed, a check is performed to make sure the server is allowed to relay, or allowed to relay conditional upon the domain to which the mail is going, as well as if the connection was initially authenticated.
Accept Connections from IP Addresses: If the IP address is trusted, the process continues.
Accept Connections from Host Domains: If the domain name of the computer or the domain name sent as part of the connection request are trusted, the process continues.
Accept Connections from Sender Domains: If the domain part of the sender's e-mail address is in the list, the process continues.
Accept Connections from Sender: If the sender address is a trusted address, the process continues.
Reject Recipient: This parameter list is only used for local delivery mail messages. If the recipient name is in this list, the 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:
True: The recipient domain is checked to see if it is in the list of domains allowed to relay.
False: Relay messages are not allowed.
Auth: If the sender is authenticated when it first connected to the SMTP server, the delivery continues.
Relay Domains Allowed: This value only reads relay mail messages when the Relay Allowed 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 (*).
|
See Also: "Configuring Routing Control for Incoming Mail" for information about setting up routing control for the SMTP inbound server |
The NNTP server supports antispam checks, based on the following:
Host domain
Host Internet Protocol (IP)
Sender mail address
Configuring routing control for NNTP is similar to configuring routing control for SMTP.
|
See Also: "Configuring Routing Control for Incoming News" for information about setting up routing control for the NNTP inbound server |
NNTP and SMTP wildcard support exists on prefixes for domains and suffixes for IP addresses, to allow subdomains and subnetworks 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 subdomains 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).
|
Note: For SMTP, Reject parameters take precedence over Accept parameters. Exception for parameters such as Accept IPs apply only to subsequent spam checks. For example, ifuser99@foo.com is present in Accept senders, any checks on the rcpt to: command are ignored. However, if the IP address of host1.foo.com is present in Accept IPs and is not present in Reject IPs, all connections from host1.foo.com are accepted and all further spam checks on mails from host1.foo.com are ignored. |
|
See Also:
|
Oracle Mail is packaged with two Symantec filters that can be used with the Symantec AntiVirus Scan Engine (SAVSE). The SAVSE client software can be installed within the network and configured on the Applications tier, or Oracle Mail can be integrated directly over the network with a SAVSE server. Both filters provide additional virus protection for your mail and incoming news.
The difference between the two filters is the communication protocol each uses when communicating with the SAVSE.
The SAVSE can be configured with either the Internet Content Adaptation Protocol (ICAP) or the Native protocol.
|
Note: ICAP configuration only applies to the platforms that Symantec supports: Windows, Solaris, and Linux. For other platforms, use the Native protocol. |
|
See Also: Symantec documentation for details about ICAP and Native communication protocols |
This enables Oracle Mail to use the Symantec virus knowledge base to detect and cleanse infected messages at the SMTP level and the Oracle Collaboration Suite Database.
This section includes the following topics:
Edit the SAVSE filters before applying them.
Open the Oracle WebMail client.
|
See Also: "Oracle Collaboration Suite 10g WebMail Client" for information about how to access the Oracle WebMail client |
Click the Administration tab.
Click the Policy subtab.
Click the name of the filter in the Name column to display the Edit Filter page.
Select Yes or No from the Active drop down list. Yes activates the SAVSE filter).
Select Yes or No from the External Process drop down list. No enables SAVSE filter antivirus protection.
Select Yes or No from the Capable of Message Modification drop down list. YES enables the SAVSE filter to repair messages, based on the FilterFlags string.
The Oracle Collaboration Suite filter architecture must define whether a filter can return a modified or repaired version of a message. This is distinct from any specific behavior of a third party library such as SAVSE, which may also have its own configuration settings for modifying or repairing a messages, such as a policy that includes RepairOnly:1. Messages in Oracle Collaboration Suite will only be repaired if the filter is capable of message modification and the external library is also configured to perform such repair, either through its own configuration or the explicit settings of the FilterFlags field.
In the External Administration URL field, enter the URL to the SAVSE administration page on the local host where the SAVSE client software is installed.
Use FilterFlags to configure the interface to the Symantec side to which is added Server:IP_address:port_number to the list of parameters described in Table 6-2.
Enter one of the following in the Filter Flags field, on a single line:
(config=Server:IP_address:port_number;;;FailRetryTime:60;;;ReadWriteTime:180)(policy=RepairOnly:1)(tmpdir=directory_for_temporary_files)(lib=libsymcsapi.so.4.x.x)
(config=Server:IP_address:port_number;;;FailRetryTime:60;;;ReadWriteTime:180)(policy=ScanOnly:1)(tmpdir=directory_for_temporary_files)(lib=libsymcsapi.so.4.x.x)
(config=Server:IP_address:port_number;;;FailRetryTime:60;;;ReadWriteTime:180)(policy=AlwaysReportDefInfo:1)(tmpdir=directory_for_temporary_files)(lib=libsymcsapi.so.4.x.x)
(config=Server:IP_address:port_number;;;FailRetryTime:60;;;ReadWriteTime:180)(policy=RepairOnly:1;;;AlwaysReportDefInfo:1)(tmpdir=directory_for_temporary_files)(lib=libsymcsapi.so.4.x.x)
(config=Server:IP_address:port_number;;;FailRetryTime:60;;;ReadWriteTime:180)(policy=ScanOnly:1;;;AlwaysReportDefInfo:1)(tmpdir=directory_for_temporary_files)(lib=libsymcsapi.so.4.x.x)
|
See Also: Symantec AntiVirus Scan Engine Software Developer's Guide for more information about theconfig and policy parameters and values |
|
Note: The default settings of the SAVSE will be used, unless overridden by values passed in the Oracle filter. |
In the preceding examples:
Specify a path to a directory in the tmpdir parameter for storage of temporary files while repairing a message
Specify the name of the SAVSE client library file in the lib parameter
Table 6-2 lists the parameters in the preceding filter strings and descriptions for each.
Table 6-2 Symantec Filter String Parameters
| Parameter | Description |
|---|---|
ScanOnly:1 |
Scan for viruses but do not attempt repair. |
RepairOnly:1 |
Attempt to repair infected files but do not delete files that cannot be repaired. |
AlwaysReportDefInfo:1 |
If a clean file is scanned, a Problem Incident is created with only the virus definitions date and revision number. |
FailRetryTime:seconds
|
If the client fails to connect to a Symantec AntiVirus Scan Engine, wait |
ReadWriteTime:seconds
|
If after |
Copy the SAVSE client library file from the Scan_Engine/Scan_Engine_SDK/Lib/platform/dynamic directory on the host where the SAVSE client software is installed to the $ORACLE_HOME/oes/lib directory on the Applications tier.
Choose the directory for the platform on which the SAVSE client software is installed.
Native Configuration:
Use the following format if the SAVSE has the Native protocol installed and configured:
(host=host_name)(port=port_number)(repair=true or false)
In the preceding example, specify the IP address of the host where the SAVSE is running in the host parameter. Specify the port number of the SAVSE in the port parameter.
If repair is set to true, the SAVSE will attempt to repair an infected message. The repaired message is received by the server and inserted into the Oracle Collaboration Suite Database instead of the original infected message.
Click OK to apply any changes.
You can apply the SAVSE filters to act on messages at various stages in the delivery cycle of the message. The filters can be applied to incoming messages, outgoing messages, messages delivered within the local Oracle Mail domain, and all messages stored in the Oracle Collaboration Suite Database.
Open the Oracle WebMail client.
|
See Also: "Oracle Collaboration Suite 10g WebMail Client" for information about how to access the Oracle WebMail client |
Click the Administration tab.
Click the Policy subtab.
Click the Application link.
Click either Incoming, Outgoing, Local, or Collaboration Suite Database to display a list of Oracle Collaboration Suite Applications tier servers associated with that point in the delivery cycle of the message.
Incoming: Filter is applied to all incoming messages.
Outgoing: Filter is applied to all messages delivered outside the local Oracle Mail domain.
Local: Filter is applied to all messages delivered within the local Oracle Mail domain.
Collaboration Suite Database: Filter is applied to all messages stored in the Oracle Collaboration Suite Database.
Click the icon in the Configure Filters column. If you clicked Collaboration Suite Database in the preceding step, go to "Configuring Filters for an Oracle Collaboration Suite Database" for a description of that page.
Click Apply Filter.
Select either SAVSE filter according to whether the SAVSE client software is installed on the Applications tier and configured with ICAP, or Oracle Mail is being integrated with SAVSE over the network where it is installed and configured with the Native protocol. Click the Policy subtab followed by the Definitions link to determine which filter to apply with which configuration.
In the Options section, select Yes from the Allow Message Modification list to enable the filter to modify messages.
In some cases, you may want to override the filter flags associated with one of the filters. To do this, click the icon adjacent to Filter Flags to list the values that will be overridden during filter application. The filter is then applied to all messages.
Otherwise, the values for Filter Flags are inherited from the filter definition and the filter is only applied to messages that meet these criteria.
Click OK to apply the filter and return to the Configure Filters page. Applied filters are displayed.
To disable a filter, select a filter from the list to be unapplied and click Unapply Filter. A confirmation page displays. Click Yes or No.
In the Advanced section, click Remove Instance Level Settings.
If you apply any filters, you must restart the associated servers.
For incoming mail, restart the SMTP inbound, SMTP outbound, and NNTP inbound servers.
For outgoing mail, restart the SMTP outbound server and the List Server.
For local mail, restart the SMTP inbound and SMTP outbound servers and the List Server.
For mail stored on the Oracle Collaboration Suite Database, restart the Virus Scrubber.
The Oracle Mail Virus Scrubber is a server process that scans for and cleans up virus-infected e-mail messages already in the Oracle Collaboration Suite Database. When rapid measures are required to immediately cleanse a system of virus-infected messages, the Virus Scrubber prescans an information storage database to isolate suspect messages contained within based on headers such as subjects or attachment names. Prescanning isolates suspect messages so that users are not able to access them and possibly cause damage. Prescanning never deletes a message. After prescanning, 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 prescanning is a faster way to isolate suspect messages in an information storage database 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 Mail can be configured to send a message to either the mail recipient or sender notifying them that a message 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 Virus Scrubber is a necessary complement to the SMTP virus scanner, because new types of viruses continue to emerge before virus detection software can be updated to detect and repair them. There is 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 information store-based scanner can also be used to scan viruses coming in through a non-SMTP route such as IMAP append.
The Virus Scrubber and SMTP-based virus scanner rely on external virus detection and cleanup software from the Symantec AntiVirus Scan Engine. Oracle Collaboration Suite provides interface libraries for third-party virus tools to integrate with Oracle Mail. The third-party virus software must be installed properly for the Virus Scrubber server to be fully functional.
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 configure the Virus Scrubber using the Application Server Control Console for Collaboration Suite:
Open the Application Server Control Console for Collaboration Suite.
|
See Also: "Oracle Enterprise Manager 10g Application Server Control Console for Collaboration Suite" for information about accessing the Application Server Control Console for Collaboration Suite |
Click the application server instance where Oracle Mail is installed.
Select the server for which the new instance is to be created.
Click Stop to bring down the server.
Click Mail Application in the System Components section to display the Mail Application page.
Click Virus Scrubber.
In the Mail Collaboration Suite Database section, choose an Oracle Collaboration Suite Database from the Mail Collaboration Suite Database list to display the default parameter settings for that particular Oracle Collaboration Suite Database.
In the Thread Parameters section, enter a number in the Number of Threads field to establish the number of connections to the database. The number chosen is dependent upon such factors as how much memory each thread uses and how many connections each thread makes, and whether a connection pool is being used. A large number of threads can affect resource performance.
In the General Parameters section, configure the process parameters listed in Table 6-3.
Table 6-3 Virus Scrubber General Parameters
| Parameter | Option | Description |
|---|---|---|
|
Pre-Scan Mode |
|
|
|
Pre-Scan Filter |
The All IMAP search commands except |
|
|
Scan Interval (Minutes) |
Enter a nonnegative number |
Time interval between two successive scans. |
|
Repair Mode |
|
Determines what action to perform to messages identified as infected. Select |
|
Quarantine Destination E-mail Address |
String |
If the repair mode is set to |
|
Quarantine Destination Folder |
String |
If the repair mode is |
|
Notification Message to Virus Sender |
String |
If a message is infected, the sender will be notified. The text entered in this parameter will be sent embedded in a standard mail. When composing notification message templates to virus senders (or recipients), you can use macros that can be substituted with actual message-specific values when the Virus Scrubber generates and sends the notifications. Supported macros include: %internaldate%: Received date of the message%messagesize%: Message size in bytes%rfc822date%: The Date header value of the message%rfc822from%: The From header value of the message%rfc822subject%: The Subject header value of the message%rfc822to%: The To header value of the message%rfc822cc%: The CC header value of the message%rfc822sender%: The Sender header value of the message%rfc822replyto%: The Reply-To header value of the message%rfc822msgid%: The Message-ID header value of the message%xpriority%: The X-Priority header value of the messageFor example, consider the following notification text: A message you sent on %internaldate% to %rfc822to% with subject %rfc822subject% has been identified as virus-infected. Please run a virus scan on your computer immediately. The actual notification message received by the recipient will have the preceding text with the macros substituted by the actual values from the virus infected message. |
|
Notification Message to Virus Recipient |
String |
If a message is infected, the recipient will be notified. The text entered in this parameter will be sent embedded in a standard mail. See Notification Message to Virus Sender for a list of supported macros. |
|
Process Log Level |
|
Determines the level of detail the server writes to the log file, as follows:
Levels beyond
The default value is |
|
Maximum Log Size (MB) |
Enter a nonnegative number |
Determines how big a log file can grow before the server writes to a new log file. The default value is |
|
Maximum Number of Log Files |
Enter a nonnegative number |
If the number of log files for an IMAP server instance reaches this limit, no new log files will be generated. The existing log files will be written to in rotation. The default value is |
Click Cancel to cancel any changes made, click Revert to set the parameter values back to the default, or click Apply to apply any changes made.
Restart the Virus Scrubber.
|
See Also: "Starting, Stopping, Restarting, or Refreshing All Server Instances" for more information about restarting the process |
E-mail viruses typically have the form of an executable program, such as an e-mail attachment. The program is executed on the client computer when the attachment is opened by an unsuspecting user, causing various forms of damage to the computer or the network. Oracle Mail provides several different tools for virus protection, each of them suited for a different type of administration requirement.
The Oracle Mail 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 e-mail system.
If third-party virus scanning software is not available, Oracle Mail 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.
If there is a virus outbreak before the SMTP server has a chance to upgrade itself to use the latest third-party software, some virus e-mail messages could already be present in a user's Inbox. The Virus Scrubber server can be used to scan the entire Oracle Collaboration Suite Database and repair or remove virus-infected e-mail messages once the third-party software is updated.
Oracle Mail 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, write a SQL*Plus script that uses this package or execute procedures in this package directly from SQL*Plus.
|
See Also: "oesctl and opmnctl" for more information about how to create server-side rules usingoesctl |
The following are summaries and usage examples for the procedures in the MAIL_AV package:
Quarantine
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-infected 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.
|
See Also: Oracle Mail Application Developer's Guide for more information |
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 entire 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;
/
Quarantine II
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-infected messages using an IMAP style search criteria for enhanced searching. All IMAP search commands are supported except new, old, and recent commands. 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 about IMAP search commands |
Use the new form of quarantine procedure. The following script identifies and moves messages with subject snow white from acme.com, that have been 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;
/
Restore
There are two procedures to restore quarantined messages to their original folders:
PROCEDURE restore (p_messageid IN NUMBER); PROCEDURE restoreall;
The restore procedure takes a given message ID and restores it to its original folder. If the message ID does not exist, the procedure does nothing. The restoreall procedure restores all messages quarantined regardless of which designated folders are used to store the messages. These procedures are useful when a message is wrongly identified as a virus-infected message and must be restored to its recipients.
