| Oracle® Communications Calendar Server System Administrator's Guide Release 7.0.5 E54935-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Calendar Server System Administrator's Guide Release 7.0.5 E54935-01 |
|
|
PDF · Mobi · ePub |
This chapter describes how to configure and manage virus scanning for Oracle Communications Calendar Server.
Topics:
To enhance security within your deployment, you can use Calendar Server attachments virus scanning. Calendar Server virus scanning can examine calendar attachments in a "real-time" mode to test and optionally reject incoming infected data. You can also choose to scan and optionally delete infected existing data "on-demand."
Virus scanning is not performed by Calendar Server itself. Instead, you configure an Oracle Communications Messaging Server's Message Transfer Agent (MTA) to filter the calendar data. You can configure Calendar Server to share an existing MTA that has already been configured for Messaging Server virus scanning. Or, if you prefer, you can configure a standalone MTA that functions only for Calendar Server virus scanning.
Calendar Server reports all virus scanning activities, as well as detected viruses, in its log file, for both real-time and on-demand scanning.
Figure 7-1 depicts the Calendar Server virus scanning logical architecture.
Figure 7-1 Calendar Server Virus Scanning Architecture
The following information describes how a calendar attachment is scanned for viruses.
A calendar client submits a calendar event and attachment to Calendar Server.
Calendar Server receives the event and attachment then packages the attachment as an email message for the MTA that has been configured to scan calendar attachments.
Calendar Server sends the email message containing the attachment by using the SMTP protocol to the configured MTA.
Calendar Server keeps the connection to the MTA open as it awaits the response from the MTA. During this time, the calendar client is also waiting for the MTA to reply back to Calendar Server with its verdict.
The Calendar Server function responsible for connecting to the MTA keeps the attachment.
Later, after the scan has completed, the function either stores the attachment (and possibly the event) in the Calendar Server document store or aborts if the MTA finds a virus. See step 7 for details.
The MTA receives the package on a specific channel that is configured for a sourcespamfilter, which in turn is linked to an Anti-Virus Scanner (AVS).
You actually define a sourcespamfiltern, where n is an integer in a given range, to define one of the possible sourcespamfilters on the system.
The AVS scans the package.
If the AVS detects a virus, the MTA refuses the message and replies with a virus positive message to Calendar Server over the open connection.
If the AVS does not detect a virus, the MTA uses a Messaging Server rewrite rule to send the package to the bitbucket channel and discard it. Calendar Server logs an error either when it detect a virus or the AVS is not working.
Once it is notified by the MTA, Calendar Server decides if it can continue processing the calendaring request normally or abort. If the davcore.virusscan.onlinevirusaction parameter remains unset (is using the default value) or is set to reject, the submission is rejected. The client receives the reply HttpStatus.FORBIDDEN (Virus Detected in Attachment). Otherwise if davcore.virusscan.onlinevirusaction is set to "keep," the attachment is accepted. The davcore.virusscan.onlinefailureaction parameter works similarly, except that the default action is "keep."
The high-level steps to prepare your deployment to perform virus scanning for Calendar Server include:
(Optional) Installing the Messaging Server MTA
Configuring the Messaging Server MTA
Configuring the MTA for the virus scan filter
Creating the incoming SMTP port and channel for Calendar Server virus scan
Configuring the rewrite rule to discard Calendar Server data after scanning
Configuring Calendar Server virus scanning parameters
The following sections describe configuring Messaging Server and Calendar Server in more detail.
Topics in this section:
It is possible that your deployment has already deployed Messaging Server and an MTA to perform email virus scanning. If so, you can reuse this existing MTA to also scan calendar attachments for viruses. If this is not the case, you can install and configure a stand alone MTA.
Prerequisite: Calendar Server virus scanning requires at least Messaging Server 7 Update 4 patch 23.
When installing a standalone MTA for Calendar Server virus scanning, be sure to use meaningful values for administrator postmaster, mail domain, and other configuration settings. If you use values that are not meaningful to your deployment, errors can result.
The general steps to install an MTA include:
Installing the Messaging Server software
Running the Messaging Server configure script
Disabling the Message Store and Webmail Server
For details, see the topic on installing a Message Transfer Agent in Unified Communications Suite Installation Guide.
When configuring Messaging Server, the "configure" step requires a valid Directory Server host that is used to include configuration data such as the default mail domain and messaging administrator account. The Directory Server host that you specify needs to be available during virus scanning operations. However, due to MTA caching of LDAP data, this host is not heavily utilized.
The MTA itself does not check for viruses. You configure the MTA to communicate with the desired virus scanning software, also referred to as the AVS. For instructions, refer to the topic on integrating spam and virus filtering programs Into Messaging Server in Messaging Server Administration Guide.
The filter should use a Sieve rule to "refuse" the message from Calendar Server if a virus is found by the virus scanning software. The Sieve rule returns FilterVerdictPositive. Calendar Server checks SMTP return values for this exact string, which is defined in the option.dat file. See "Example MTA Configuration for Calendar Server Virus Scanning" for more information.
Note:
You configure the MTA to perform a Sieve refuse action if there is a virus, which returns an SMTP code 5xy plus the MTA-configured string FilterVerdictPositive. Calendar Server responds to the target string, where other errors are considered failures in service.You create a new incoming SMTP port in Messaging Server's dispatcher.cnf file, strictly for Calendar Server virus scanning use. In this way, Calendar Server traffic is tracked. In addition, a separate SMTP port makes it easier to destroy all data being scanned. You associate this incoming SMTP port with a new MTA channel in the imta.cnf file. Finally, you configure the receiving channel to use the sourcespamfiltern that is configured with the desired virus scan software, so that incoming calendar data is tested. For instructions, refer to Messaging Server Administration Guide.
Calendar Server sends the attachment data as an email with a user recipient email address. You configure the MTA to detect the chosen email address. The email address is set up to use the MTA's host name and domain, so that the MTA does not need to perform a lookup for the domain. The user email address itself is not significant since incoming data is not actually delivered. See the topic on rewrite rules and channels in Messaging Server Administration Guide for more information.
You use the davadmin command to configure Calendar Server parameters for virus scanning. Some parameters are required. Others are optional.
Configure the following required parameters:
davcore.virusscan.emailaddress
davcore.virusscan.host
davcore.virusscan.port
davcore.viruscan.onlineenable
davcore.virusscan.onlinevirusaction
The syntax for the davadmin command in this instance is as follows:
davadmin config modify -u adminID -o parameter -v value
For example:
./davadmin config modify -u admin -o davcore.virusscan.emailaddress -v myvirususer@mymachine.example.com
The email address' domain must match the MTA's domain. The user name itself is not significant.
Configure optional parameters.
See "Calendar Server Configuration Parameters" for more information.
This example describes how to configure a Messaging Server MTA for Calendar Server virus scanning.
Install Messaging Server software and configure an MTA.
If necessary, use the "Installation Scenario for Message Transfer Agent" instructions in Unified Communications Suite Installation Guide.
In this example, the following values are used:
The Fully Qualified Host Name is required: mymachine.example.com The LDAP directory server the MTA will use: myldap.example.com The LDAP port: 389 The LDAP Bind user: cn=Directory Manager The LDAP password: mypassword The system user name and group: mailsrv mailsrv The default mail domain: example.com The postmaster email address admin@example.com The password for messaging admin: mypassword
Disable the Message Store and Webmail server.
./configutil -o local.store.enable -v 0 ./configutil -o service.http.enable -v 0
Start the MTA.
./start-msg
Configure the MTA for the virus scan filter.
This example uses ClamAV for the virus scanning software package to work with the MTA.
Create the ClamAV configuration file, clamav.mtaconf, in the /opt/sun/comms/messaging64/lib/ directory.
Make sure that clamav.mtaconf file contains the following information:
HOST=localhost PORT=3310
Edit the clamd.conf file to contain the follow information:
On Solaris: /opt/ClamAV/etc/clamd.conf
On Linux: /etc/clamd.conf
LogFile /tmp/clamd.log LogTime yes LogVerbose yes FixStaleSocket yes TCPSocket 3310 TCPAddr 127.0.0.1
(Solaris only) Set the path to the ClamAV bin directory.
setenv PATH /opt/ClamAV/bin:$PATH
Become root and start ClamAV.
su - cd /opt/ClamAV/sbin/ clamd session
Create a "filter" on the MTA that serves as the connection to the ClamAV server.
Add the following information to the option.dat file in the config directory:
SPAMFILTER1_LIBRARY=/opt/sun/comms/messaging64/lib/libclamav.so SPAMFILTER1_CONFIG_FILE=/opt/sun/comms/messaging64/lib/clamav.mtaconf SPAMFILTER1_NULL_ACTION=data:,require ["reject","ereject","refuse"]; refuse "FilterVerdictPositive";
This example uses filter 1, hence many of the keywords have "1" in them. For example, SPAMFILTER1_LIBRARY is a registered MTA keyword. The MTA needs to know where to locate the ClamAV configuration file. It also needs to know the location for the already existing ClamAV client library that the MTA provides. This is the MTA's specific code that knows how to communicate to ClamAV servers. Finally, an "action" is needed to tell the MTA what to do depending on what is returned by clamAV.
By using this information for spam filter 1, the MTA knows where to find the existing MTA library, where to find the configuration file for communicating to ClamAV, and how to handle the response back from ClamAV. The "action" is a sieve string that explains that if there is a virus detected, then "refuse" the SMTP submission with the FilterVerdictPositive string. This is the string that is sent back to the Calendar server, and must be exact. So far, this configuration does not attach the filter to any incoming data. But now that this spam filter is configured, it can be used in the channel definitions.
Create the incoming SMTP channel which uses the filter.
Create an SMTP port the Calendar Server uses.
A virus scan port and channel called tcp_vscan can be created by adding code to the dispatcher.cnf file:
! ! Virus Scan Port ! [SERVICE=SMTP_VSCAN] PORT=3025 IMAGE=IMTA_BIN:tcp_smtp_server LOGFILE=IMTA_LOG:tcp_vscan_server.log PARAMETER=CHANNEL=tcp_vscan STACKSIZE=2048000 ! Uncomment the following line and set INTERFACE_ADDRESS to an appropriate ! host IP (dotted quad) if the dispatcher needs to listen on a specific ! interface (e.g. in a HA environment). !INTERFACE_ADDRESS=
Create a matching channel definition in the channel definition configuration. Rewrite rules and channel definitions are located in the imta.cnf file. Add this channel in the channel area, paying strict attention to syntax rules described in the MTA documentation in Messaging Server Administration Guide.
! ! tcp_vscan tcp_vscan smtp sourcespamfilter1 missingrecipientpolicy 6 pool SMTP_POOL tcp_vscan-daemon
Note:
This example uses sourcespamfilter1, which is the spam filter already configured. All incoming SMTP submissions on this port and channel are submitted to ClamAV, and if a virus is found, Calendar Server receives the correct message.Configure the rewrite rule to send calendar data to be discarded after scanning.
With the virus scan channel and virus spam filter configured, Calendar Server receives the proper return values from ClamAV. However, the incoming message needs to be handled by the MTA. A rewrite rule is required to send it to be destroyed in the bitbucket channel. Add the following rewrite rule to the imta.cnf file just before the rule "Rules to select local users."
! Avoid all lookups and just force to bitbucket channel for messages ! coming in the tcp_vscan channel: $* $U%$H@bitbucket-daemon$Mtcp_vscan
This rewrite rule checks for email coming in on the tcp_vscan port and sends it to the bitbucket (where it is destroyed).
Configure Calendar Server's virus scan email address to be in the MTA's domain. The user name is not significant.
Set davcore.virusscan.emailaddress to joe@mymachine.example.com.
Recompile the MTA configuration.
./imsimta cnbuild ./imsimta restart
Summary:
Calendar Server sends data to be scanned to the Messaging Server MTA by using an email address of joe@mymachine.example.com.
This is done on the specified port configured in the dispatcher.cnf file.
This email arrives at the MTA on the tcp_vscan channel, and is subjected to sourcespamfilter1, which is tied to ClamAV through the configuration in the option.dat file.
If virus scanning software detects a virus, a refuse action is sent back through SMTP to Calendar Server with the string FilterVerdictPositive.
If the virus scanning software does not detect a virus, the incoming message is subjected to rewrite rules that send it to the bitbucket for deletion.
The MTA communicates to LDAP to look up example.com, but caches LDAP's response so it does not make this call often.
For more information on the virus scanning configuring parameters, see "Calendar Server Configuration Parameters."
To set the MTA host:
davadmin config modify -u admin -o "davcore.virusscan.host" -v "myhost.example.com"
To set the SMTP port:
davadmin config modify -u admin -o "davcore.virusscan.port" -v "3025"
To set the email address:
davadmin config modify -u admin -o "davcore.virusscan.emailaddress" -v "myvirususer@mymachine.example.com"
To set the timeout value:
davadmin config modify -u admin -o "davcore.virusscan.timeout" -v "1000"
To enable scanning on incoming data:
davadmin config modify -u admin -o "davcore.virusscan.onlineenable" -v "true"
To reject viruses discovered in attachments by the MTA:
davadmin config modify -u admin -o "davcore.virusscan.onlinevirusaction" -v "reject"
To reject viruses if the AVS is not functioning or is not responding:
davadmin config modify -u admin -o "davcore.virusscan.onlinefailureaction" -v "reject"
To automatically delete a virus when scanning.
davadmin config modify -u admin -o "davcore.virusscan.clivirusaction" -v "delete"
Use the davadmin vscan command to perform virus scanning operations. The davadmin vscan command must be followed by the scan action. For more information, see "Calendar Server Command-Line Utilities."
Virus scan activity for both online and CLI is logged in the calendar server's "scan" log. Found virus are reported in the log. Actions taken against viruses are reported if any actions are configured. Owning components that are found to reference data that is found to be a virus are reported. The time just before a davadmin scan is started is printed at the end of a scan, in case this time may be useful with the -T option in future scans.
Because the davadmin scan command runs on the GlassFish Server (and not the davadmin client), most useful information is printed in the Calendar Server's "scan" log, not always in the standard output of the davadmin command. This also provides a central repository for all historical virus scan related information and tracking.
See the MTA documentation in Messaging Server Administration Guide for logging information.
To view and test channel traffic, add the keyword logging to the defaults channel in the imta.cnf file. Add LOG_CONNECTION=255 and LOG_FILTER=1 to the option.dat file. Use the MTA documentation to interpret channel operations such as "E" enqueue and "D" dequeue, "O" open connection, "C" close connection. View messages coming in on the tcp_vscan, and dequeue onto the bitbucket channel.
|
 Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
