Securing Your Web World

A Trend Micro TrendEdge Solution

Advanced Technologies and Techniques to Enhance Your Product

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database Run Book
March 2008

Jason Pappalexis
Senior Solutions Architect Trend Micro, Inc.

TREND MICRO INC. 10101 N. De Anza Blvd. Cupertino, CA, 95014 www.trendmicro.com Toll free: +1 800.228.5651 Fax: +1 408.257.2003 Phone: +1 408.257.1500

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Contents
Introduction ........................................................................................................................................1 Topology Definition .............................................................................................................................1 Requirements .....................................................................................................................................2 Impact of a Master/Child Relationship and a Shared Database .............................................................2 Download Locations ...........................................................................................................................3 Before you Begin ................................................................................................................................3 Recommended Steps ..........................................................................................................................5 Step 1: Create the Master IWSS 3.1 Server .....................................................................................5 Step 2: Configure IWSS 3.1 as a Master ..........................................................................................6 Step 3: Configure Central Database to Allow Shared Connections ....................................................7 Step 4: Configure the Child IWSS 3.1 Policies .................................................................................9 Step 5: Convert IWSS 3.1 Standalone Instances to Children ........................................................... 10 Step 6: Direct the Child IWSS 3.1 Server to the Shared Database .................................................. 11 Monitoring and Maintaining the System ............................................................................................. 14 Ensuring the individual Scanner Servers are Consistent ................................................................. 14 Understanding the Data Found in Centralized Database and Log Files ............................................ 15 Monitoring Disk Space Using IWSS 3.1 Notifications ...................................................................... 16 Monitoring Disk Space Utilization Using a Cron Job ....................................................................... 18 Using the IWSS 3.1 GUI to Adjust the Log File Retention Period..................................................... 21 Using a Cron Job to Delete Old Log Files ...................................................................................... 23 Removing the Configuration .............................................................................................................. 25 Master/Child Relationships ........................................................................................................... 25 Shared Databases ........................................................................................................................ 25 Notification Cron Jobs .................................................................................................................. 25 Resources ........................................................................................................................................ 26 Web Sites .................................................................................................................................... 26 Documents ................................................................................................................................... 26 About the Author .............................................................................................................................. 27 About Trend Micro Incorporated ........................................................................................................ 28 Contacting TrendEdge Publications ................................................................................................... 29

Trend Micro, the Trend Micro t-ball logo, and InterScan are trademarks or registered trademarks of Trend Micro, Incorporated. All other product or company names may be trademarks or registered trademarks of their owners. Trend Micro Incorporated reserves the right to make changes to this document and to the product described herein without notice, and the information contained in this document is provided as-is. This document is for informational purposes only, and is not supported by Trend Micro or its partners. TREND MICRO MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. Copyright 2009 Trend Micro Incorporated. All rights reserved. Document Part No. TE03WS31_090205US

A Trend Micro TrendEdge Solution

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Introduction
IWSS 3.1 for Linux environments benefit from a distributed architecture that reduces local resource utilization during scheduled reports and other tasks. In a multi-server deployment, incorporating a centralized database enforces common policies between servers. In addition, creating a single Master server with multiple Child servers ensures that dynamic content is shared among the servers. Together, this combination provides for increased performance, centralized policies, shared configuration, and aggregated reporting. This document supplies the steps required to create a distributed architecture for IWSS 3.1 and ties these deployment steps to specific sizing examples. For additional information on IWSS configuration options, visit Trend Micro on the Web at: http://us.trendmicro.com/us/products/enterprise/interscan-Web-security-suite/ Note: Trend Micro provides this documentas-isas a courtesy to interested parties. The accuracy of the information is solely the authors responsibility. Neither Trend Micro nor its partners support this document.

Topology Definition
This document describes how to migrate several standalone instances of IWSS 3.1 for Linux (each with their own database and a separate set of policies) to a set of Child IWSS 3.1 scanner servers that share a common database. This new, common database will be located on a single Master IWSS 3.1 server that acts as the central access point for setting policies and running reports for all of the connected Child IWSS 3.1 servers. The Master IWSS 3.1 server will not be used to scan HTTP/FTP traffic. A simple diagram of this architecture appears in Figure 1 below:

Figure 1

Example IWSS 3.1 for Linux Master/Child Architecture with Multiple IWSS Child Scanner Servers

A Trend Micro TrendEdge Solution

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

This document includes cron job scripts for issuing email notifications to administrators regarding the amount of available disk space and for removing logs older than a specified retention period from the distributed system.

Requirements
This document is designed for end users and resellers responsible for administering Trend Micro IWSS 3.1 for Linux. The following professionals benefit most from this document: System engineers System administrators

This solution applies to environments running individual servers with either of the following: IWSS 3.1 for Linux IWSS 3.1 for Crossbeam X and C series We recommend that you have: Administrator-level knowledge of the Linux operating system. Familiarity with the Trend Micro InterScan Web Security Suite product. Several existing Trend Micro InterScan Web Security Suite 3.1 for Linux or for Trend Micro InterScan Web Security Suite 3.1 for Crossbeam COS/XOS scanner servers. These servers will be configured in Master/Child relationships and use a single Master IWSS 3.1 server database. A server with a pre-installed Linux operating system that can function as the Master IWSS 3.1 server. This new Master IWSS 3.1 server can be either a virtual machine or a traditional baremetal installation. You can use one of the following OS options for this server: o o Note: Red Hat Enterprise Linux 4 update 5 Red Hat Enterprise Linux 5 and above

A system running SUSE Linux Enterprise Server version 10 with SP1 or SP2 may also work as the Master IWSS 3.1 server, but neither of these versions of SUSE have been tested using the procedure described in this document.

Note:

If a Master IWSS server is used as the shared centralized database, ensure that you have adequate storage space in the /opt directory. This directory must be large enough to store logs for all of the attached Child IWSS 3.1 servers.

Impact of a Master/Child Relationship and a Shared Database

Trend Micro recommends using a single Master IWSS 3.1 server to host the centralized database. In this configuration, the Master IWSS 3.1 should not scan HTTP or FTP traffic as this may negatively impact the servers database and reporting functions. To better understand this configuration: Servers in a Master/Child relationship: Share dynamic data (a list of temporarily blocked URLs and client IP addresses that are infected with spyware).

A Trend Micro TrendEdge Solution

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

The centralized shared database: Allows the sharing of policies (URL filtering, Applets and ActiveX Security, IntelliTunnel, Web Reputation, access quotas, etc.) among all the servers in the group. Allows IWSS 3.1 configuration changes to occur on any of the administrative consoles (Master OR Child) since each IWSS 3.1 instance propagates them to all the other IWSS 3.1 instances. Trend Micro, however, recommends you use the Master IWSS 3.1 server to record and propagate these changes. Allow the reports and logs to show an aggregated view of all IWSS servers in the network group. Is updated by all attached IWSS 3.1 servers. Local IWSS 3.1 Child scanners write all log information to intermediate log files first and then update the IWSS 3.1 Master database at predetermined intervals (by default every 30 seconds). The configuration settings for this feature are discussed later in this document. Becomes a single point of failure for the environment. Creating a database cluster and backing up the entire system is recommended. These topics will be addressed in a separate TrendEdge document. You can find information on backing up the database in the Trend Micro InterScan Web Security Suite 3.1 Administrators Guide.

This configuration will not: Create a comprehensive single centralized administrative system for all environment variables. Only user policies are common with this configuration. o If you make specific configuration changes outside of policies, you must perform a manual synchronization of these changes (IWSS automatically replicates changes to policies). For example, if you turn on or off HTTP and FTP scanning per Child IWSS 3.1 server or set notifications for each Child server, you must replicate these changes manually. These specific configuration changes are outlined in Table 1 on page 14 of this document. You can view the health of an IWSS 3.1 server only by logging into the administrative console of the specific Child server and reviewing the servers dashboard. No aggregate view is available.

Include HTTP load-balancing. You must use a separate Layer 4 switch, DNS round-robin, or third-party load balancing solution for this functionality. Provide multiple redundant, highly-available, fault-tolerant databases. You can create clustered databases separately. These will be addressed in a separate TrendEdge document.

Download Locations
IWSS 3.1 for Linux: http://us.trendmicro.com/us/products/enterprise/interscan-Web-securitysuite/download/index.php?productID=34

Before you Begin

There are several issues you should consider before beginning the implementation process: 1. If you will be using multiple IWSS 3.1 Children, consider adding only one IWSS 3.1 Child at a time to the new Master IWSS 3.1 server and monitor this new server for a minimum of 24 hours to ensure proper sizing and connectivity.

A Trend Micro TrendEdge Solution

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

2. 3. 4.

If you wish, adding IWSS 3.1 Children to the central database can be a separate step. You should always monitor new Child servers carefully to ensure they are functioning correctly. Consider establishing as a best practice using the Master IWSS 3.1 console for all policy changes since it replicates these out to all the Children IWSS 3.1 automatically. You should also consider as a best practice running all reports from the Master IWSS 3.1 server as this will have less of an impact on the individual Child servers.

A Trend Micro TrendEdge Solution

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Recommended Steps
Step 1: Create the Master IWSS 3.1 Server
Consult one or more of the resources below before beginning the installation process. They describe how to install IWSS 3.1 for Linux step-by-step:

Trend Micro InterScan Web Security Suite 3.1 for Linux Installation Guide (for detailed installation instructions and server hardening recommendations): http://www.trendmicro.com/ftp/documentation/guides/ iwss_31_linux_b1027_InstallGd.pdf

Trend Micro InterScan Web Security 3.1 Installation Guide for Crossbeam X-Series Platforms: http://www.trendmicro.com/ftp/documentation/guides/iwss31_xos_ig.pdf

Maximizing InterScan Web Security Suite 3.1 for Linux Performance Using a Centralized PostgreSQL Database (a TrendEdge document): http://trendedge.trendmicro.com/pr/tm/te/document/ Max_IWSS_3_1_w_Cent_PostgreSQL_dB.pdf

The steps below summarize the steps you must follow to install IWSS 3.1 for Linux: 1. Install Linux as a virtual machine or bare-metal server. Ensure there is adequate disk space for existing traffic roughly 1.7 GB of disk space for every 3 million HTTP requests per day 2. Ensure the Swap partition is four (4) times the amount of physical memory (Trend Micro currently recommends that physical memory be a minimum of 2 GB for fewer than 5,000 users and 4 GB for more than 5,000 users). Login to the Trend Micro HTTP server and download the IWSS 3.1 for Linux installer. 4. wget http://www.trendmicro.com/ftp/products/iwss/ iwss_31_linux_b1027.tgz

3.

Extract the installer, place it in a temporary directory, and execute the installation script. tar zxvf iwss_31_linux_b1027.tgz

5.

Follow the prompts in the installation script:

a. b.

Ensure the PostgreSQL database is installed locally. Login to the IWSS 3.1 administrative console:
o o

Use the URL http://<IWSS_IP_Address>:1812 Use the Username admin and the default password adminIWSS85.

c. d.

Add the license keys via Administration > Product License. Change the administrator password via Administration > Login Accounts.

A Trend Micro TrendEdge Solution

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Step 2: Configure IWSS 3.1 as a Master

Follow these steps to configure an IWSS 3.1 server to act as the Master in a Master/Child relationship. 1. First, login to the IWSS 3.1 administrative console on the server that will act as the Master: 2. 3. Use the URL http://<IWSS_IP_Address>:1812 If you have not changed it already, login using the username admin and the default password adminIWSS85.

Go to Administration > IWSS Configuration > IWSS Server Farm. Under Server Configuration, select Enable for use in a multiple IWSS server configuration via the checkbox, ensure the Server role is set to Master Server, and click Save. See Figure 2.

Figure 2

Enabling Master Server Configuration in IWSS 3.1

4.

Next, modify the lifetime of the access quota to ensure that it is accurately measured. Perform the following:
a.

Login to the Master IWSS 3.1 server (typically remotely via SSH2, or directly via the console). Since this server is running Linux, you should either login as root, or use su to obtain root credentials. Edit the /var/iwss/intscan.ini file. Find the key named cache_lifetime Change the value from 3600 to 30 and save the intscan.ini file. Stop and restart the service using /usr/iwss/rcIwss restart.

b. c. d. e.

A Trend Micro TrendEdge Solution

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Step 3: Configure Central Database to Allow Shared Connections

You will use the newly created Master IWSS 3.1 server to house the centralized shared database. You must now configure the new Master server to allow incoming connections to the database over port 5432. Note: You can optionally use a separate PostgreSQL database for the centralized database instead of using the Master IWSS 3.1 Linux server. For details, refer to the following TrendEdge document: http://trendedge.trendmicro.com/pr/tm/te/document/Max_IWSS_3_1_w_Cent_ PostgreSQL_dB.pdf

Modify the pg_hba.conf file to allow remote access from Child IWSS 3.1 servers by performing the following: 1. Login to the Linux operating system (typically via SSH2 remotely, or via the console directly) running on the Master IWSS 3.1 server. Either login directly as root, or use su to obtain root credentials. Edit the /opt/trend/iwss/data/postgres/pg_data/pg_hba.conf file to ensure it appears as shown in Figure 3. Carefully edit the file to ensure local domain socket connections and IPv4 local connections are authenticated with password instead of trust. Note that the network information in your file should reflect the topology used in your environment, not the non-routable IP address and class C subnet used in Figure 3. Save the pg_hba.conf file. Stop and restart the service using /usr/iwss/rcIwss restart. Your environment may require other authentication. You should tune this file to match your security level. Contact your database administrator and IT department to see if the sample pg_hba_conf file meets your needs.

2.

3. 4. Note:

Figure 3

pg_hba.conf File with Changes to Ensure Remote Access with Password Authentication
CIDR-ADDRESS METHOD

# TYPE DATABASE USER

# "local" is for Unix domain socket connections only local all all password # IPv4 local connections: host all all 127.0.0.1/32 password # IPv6 local connections: host all all ::1/128 trust host all all 192.168.1.0 255.255.255.0 password

5.

Ensure the database listens on port 5432 with the proper IP addresses. Perform the following:
a.

Login to the Linux operating system (typically via SSH2 remotely, or via the console directly) running on the Master IWSS 3.1 server. Either login directly as root, or use su to obtain root credentials. Edit the /opt/trend/iwss/data/postgres/pg_data/postgres.conf file. Find the line port = 5432 and confirm that it is not commented out with a #.

b. c.

A Trend Micro TrendEdge Solution

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

d. e.

Save the postgres.conf file. Stop and restart the service using /usr/iwss/rcIwss restart.

A Trend Micro TrendEdge Solution

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Step 4: Configure the Child IWSS 3.1 Policies

You must now login to the Master IWSS 3.1 server and create the policies that will be used by the Child IWSS 3.1 servers. If you do not, the Child IWSS 3.1 servers will connect to the new Master IWSS 3.1 server and access only the default policies that come pre-configured on the Master server. For information on configuring IWSS 3.1 policies, refer to the Trend Micro InterScan Web Security Suite 3.1 for Linux Administrators Guide. Note: Trend Micro does not include any policy migration tools with the IWSS 3.1 application. You must complete this step manually.

A Trend Micro TrendEdge Solution

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Step 5: Convert IWSS 3.1 Standalone Instances to Children

The next step is to convert the existing standalone IWSS 3.1 servers (either running IWSS 3.1 for Linux or IWSS 3.1 for Crossbeam) to Children. 1. Login to the IWSS 3.1 administrative console on the first Child server: Use the URL: http://<IWSS_IP_Address>:1812 Use the username admin. The password will have been configured when you initially installed IWSS 3.1. The default IWSS 3.1 password is adminIWSS85. 2. 3. Go to Administration > IWSS Configuration > IWSS Server Farm. Under Server Configuration, select Enable for use in a multiple IWSS server configuration via checkbox, ensure the Server role is set to Slave server and click Save. See Figure 4.

Figure 4

Enabling Child Server Configuration in IWSS 3.1

Note: 4.

It may take a few minutes for the Child server to register with the Master. Once the Child server finishes registering, logoff and close the IWSS 3.1 administrative console.

At this point, this Child IWSS 3.1 is paired with the new Master IWSS 3.1 server. Repeat this step for each of the IWSS 3.1 Children you planned for the topology. Important Note: Before converting all IWSS 3.1 servers to Children, make sure you have read the Before you Begin section of this document. It contains important production rollout information.

A Trend Micro TrendEdge Solution

10

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Step 6: Direct the Child IWSS 3.1 Server to the Shared Database
Now, configure the Child IWSS 3.1 server to direct its database requests to the new shared database located on the Master IWSS 3.1 server. 1. Open a shell and login to the Linux operating system (typically via SSH2 remotely, or via the console directly) running on the target Child IWSS 3.1 server. Either login directly as root, or use su to obtain root credentials. As shown in Figure 4 below, run the setup-postgres-env.sh script included with the IWSS 3.1 application to change the PostgreSQL database server information. Do not choose to create tables and stored procedures.

2.

Note:

You must know the name of your Master IWSS 3.1 PostgreSQL database, and the name and password of your superuser to complete this step

Note:

The IP address, database name, username and password used in Figure 5 may not be correct for your environment. Make sure to use the login credentials appropriate for your configuration.

Figure 5

Ensuring the Database is Listening for all IP Addresses on Port 5432

[root@IWSS31_Child ~]# [root@IWSS31_Child ~]# cd /opt/trend/iwss/bin/ [root@IWSS31_Child bin]# ./setup-postgres-env.sh Specify PostgreSQL server name or IP address 192.168.1.127 Specify port number of PostgreSQL [ 5432 ] 5432 Specify database name of PostgreSQL [ iwss ] iwss Specify the user name for PostgreSQL [ sa ] sa Specify the password for user "sa" Choose no in sa this step Connection via psql successful Connection via unixODBC successful Modifying intscan.ini Updating ODBC configuration files Do you want to create tables and stored procedures on the designated PostgreSQL server ? ( y/n ) [ n ] -- Notice -All existing data in the IWSS related table will be lost if you select YES

Using CATALINA_BASE: /usr/iwss/AdminUI/tomcat Using CATALINA_HOME: /usr/iwss/AdminUI/tomcat Using CATALINA_TMPDIR: /usr/iwss/AdminUI/tomcat/temp Using JRE_HOME: /usr/iwss/AdminUI/jre Using CATALINA_BASE: /usr/iwss/AdminUI/tomcat Using CATALINA_HOME: /usr/iwss/AdminUI/tomcat Using CATALINA_TMPDIR: /usr/iwss/AdminUI/tomcat/temp Using JRE_HOME: /usr/iwss/AdminUI/jre Stopping database logging daemon... Starting DataBase logging daemon ...

A Trend Micro TrendEdge Solution

11

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Please wait while the InterScan Web Security Suite daemon is being checked...ok Shutting down the InterScan HTTP daemon... The InterScan http 19143 is not responding to shutdown request. Forcing shutdown... The InterScan HTTP daemon is already running. Please wait while the InterScan Web Security Suite daemon is being checked...ok /var/iwss/pids/IWSSFtpMain.pid doesn't exist. All InterScan Web Security Suite FTP has stopped. IWSS PostgreSQL environment set-up finished successfully. [root@IWSS31_Child bin]#

3.

The Scanning Daemons write the log entries into a set of intermediate text log files in the /<IWSS>/data/log directory. If desired, you can modify the database update time in the intscan.ini file using the following steps. However for most installations the default time of 30 seconds is adequate:
a.

Login to the Linux operating system (typically via SSH2 remotely, or via the console directly) running on the Master IWSS 3.1 server. Either login directly as root, or use su to obtain root credentials. Edit the /var/iwss/intscan.ini file. Find the key named log_check_freq=30 (found under [LogToDB]). Change the value from 30 to your desired value. Save the intscan.ini file. Stop and restart the service using /usr/iwss/rcIwss restart.

b. c. d. e. f.

4.

Finally, ensure the local Child IWSS 3.1 server does not attempt to restart the local PostgreSQL database. To do this, perform the following:
a.

Login to the Linux operating system (typically via SSH2 remotely, or via the console directly) running on the Master IWSS 3.1 server. Either login directly as root, or use su to obtain root credentials. Edit the /opt/trend/iwss/bin/S99ISdatabase file. Find the key REMOTE_DB. Change NO to YES. Save the S99ISdatabase file. Stop and restart the service using /usr/iwss/rcIwss restart.

b. c. d. e. f.

You are done. The IWSS 3.1 Child server now uses the Master IWSS 3.1 server database for all logging and policy updates. In addition, all policies previously configured on the Master IWSS 3.1 server will be used by the Child IWSS 3.1 server. You can verify database connectivity using the IWSS 3.1 administrative console on the Child server (not the Master!) as shown in Figure 6:

A Trend Micro TrendEdge Solution

12

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Figure 6

Ensuring Database Connectivity via the Child Administrative Console

In addition, you can use tcpdump to verify incoming traffic to the Master IWSS 3.1 server. 1. Open a shell and login to the Linux operating system (typically via SSH2 remotely, or via the console directly) running on the Master IWSS 3.1 server. You should either login directly as root, or use su to obtain root credentials. If the console opens properly, you can use tcpdump to verify that traffic is going to the new database server while under load. Issue the following command on the new database server while work is being passed through the scanner server and you can see the specific traffic arriving at the IWSS 3.1 database server on port 5432 from the IWSS 3.1 scanner server. Note that the port (listed as eth0 below) and IP addresses should be changed to match your environment. tcpdump i eth0 port 5432 src host IP_ADDRESS_IWSS_SCANNER dst host IP_ADDRESS_DATABASE

2.

A Trend Micro TrendEdge Solution

13

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Monitoring and Maintaining the System

Monitoring and regularly maintaining the servers in an IWSS 3.1 Master/Child deployment can help tremendously in optimizing the performance of this technology. This section of this document contains recommendations for monitoring and maintaining this equipment for most common environments.

Ensuring the Individual Scanner Servers are Consistent

By design, the database contains primarily policy information. While policies are key to consistent handling of workloads, individual configuration changes may still be required. Details such as HTTP scanning, notifications, etc. are not stored in the centralized database and must be monitored and handled manually for all scanners to ensure consistent scanning of HTTP and FTP traffic. Table 1 provides a listing of key functionality that should be monitored on each individual Child server to maintain consistency. In short, the following information is NOT controlled through the Master server:

Table 1

Configuration Settings Independent of Each Child Server Child Administrator Console Location
HTTP >HTTP Scan >Settings HTTP >Applets and ActiveX >Settings HTTP >Applets and ActiveX >Digital Certificates HTTP >URL Filtering >Settings HTTP >URL Access Control >Trusted URLs HTTP >URL Access Control >URL Blocking HTTP >Configuration >Proxy Scan Settings HTTP >Configuration >User Identification HTTP >Configuration >Access Control Settings HTTP >Configuration >Query Method Settings HTTP >Configuration >URL Cache FTP>Configuration >General FTP>Configuration >Access Control Settings Updates >Schedule Updates >Connection Settings Notifications > everything Administration > everything

Configuration Name HTTP Scan settings HTTP Applet and ActiveX settings HTTP Applet and ActiveX Certificates URL filtering settings URL access control

HTTP configuration

FTP configuration Updates Notifications Administrator

Table 2 provides a listing of key functionality shared by Child servers through the centralized database (one change in the Administrative console will be reflected on all Child servers):

A Trend Micro TrendEdge Solution

14

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Table 2

Configuration Settings Shared by Each Child Server Through the Centralized Database Child Administrator Console Location
HTTP >HTTP Scan >Policies HTTP >Applets and ActiveX >Policies HTTP >URL Filtering >Policies HTTP >IntelliTunnel HTTP >Access Quota Policies FTP >Scan Rules

Configuration Name HTTP Scan policies HTTP Applet and ActiveX policies URL filtering policies IntelliTunnel Access quota policies FTP scan rules

Understanding the Data Found in Centralized Database and Log Files

To best understand the data storage location, Table3 provides visibility into what is maintained on the Master server (within the Centralized database) and what is still found on individual Child servers (individual log files). Using this table, you can choose the proper location to view each type of data.

Table 3

Data Storage Location on Master and Child Servers Log file name URL Access Log FTP Get Log FTP Put Log Virus Log URL Blocking Log Spyware/Grayware Log Performance Log Cleanup Log Audit Log HTTP Log FTP Log Scheduled Update Log Mail Delivery Log Update Log Database Import Tool Log DB table name tb_url_usage

Child server data Centralized within the Master server database (results viewable through the Master server log query)

tb_violation

Child Server data found only on individual child servers (manual login to each child server required to view)

tb_performance_value tb_cleanup None None None None None None None

A Trend Micro TrendEdge Solution

15

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Monitoring Disk Space Using IWSS 3.1 Notifications

IWSS 3.1 for Linux provides monitoring with notification when key thresholds are exceeded. Email configuration settings are shown in this example; however, notifications can also be issued via SNMP and the configuration is similar. Note: Notification information is not stored in the centralized database and so must be configured separately on each IWSS 3.1 scanning server.

Follow the steps below to set up IWSS 3.1 disk space monitoring with email notifications on each individual IWSS 3.1 scanning server: 1. 2. Login to the IWSS 3.1 administrative console on the Master IWSS 3.1 server. Go to Notifications > Send Notification to Under Notifications Email Settings, ensure the proper email address, SMTP server name, or IP and SMTP port is shown. You can obtain this information from your sites local email administrator. Click Save to finish. See Figure 7.

Figure 7

Configuring the Email Notification Settings

3.

Next, go to Summary > Threshold Alert Settings to enable the desired threshold types and notification frequency. The Database and Hard Drive thresholds shown in Figure 8 below are the minimum Trend Micro recommends.

A Trend Micro TrendEdge Solution

16

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Figure 8

Setting Threshold Alerts and Frequency

4.

Click Save to incorporate. You can then log off from the administrative console.

A Trend Micro TrendEdge Solution

17

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Monitoring Disk Space Utilization Using a Cron Job

Another method for monitoring disk space utilization is via a Linux cron job. This provides advanced monitoring capabilities, but may be a more complicated solution for some administrators. Most environments should be fine with the existing IWSS 3.1 notification options. Note: Cron job entries are separate from the centralized policy database and so must be set up and maintained separately on each IWSS 3.1 scanning server.

Follow the steps below to set up a cron job that monitors disk space utilization. Complete these steps for each IWSS 3.1 scanning server you want to monitor: 1. Open a shell and login to the Linux operating system (typically via SSH2 remotely, or via the console directly) running on the IWSS 3.1 server (scripts should be placed on each IWSS server). You should either login directly as root, or use su to obtain root credentials. Create a new file in the /opt/trend directory named iwss_disk_notify.sh. The necessary steps appear in Figure 9.

2.

Figure 9

Creating the Disk Notification Script

[root@IWSS31_Master /]# [root@IWSS31_Master /]# cd /opt/trend [root@IWSS31_Master trend]# echo > iwss_disk_notify.sh [root@IWSS31_Master trend]# chmod +x iwss_disk_notify.sh [root@IWSS31_Master trend]# ls -al total 24 drwxr-xr-x 4 root root 4096 Oct 30 09:16 . drwxr-xr-x 3 root root 4096 Oct 29 14:31 .. drwxr-xr-x 4 root root 4096 Oct 16 13:43 iwss -rwxr-xr-x 1 root root 1 Oct 30 09:16 iwss_disk_notify.sh [root@IWSS31_Master trend]#

3.

Open the new file using your favorite text editor and ensure the text in Figure 10 is inside. Make sure to change the contents of the email_address variable to the email address where you want to send the notifications and set the thresholds for free disk space for both your yellow and red alerts.

Figure 10 Script to Email Available Free Space in /opt

#!/bin/sh # # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Disk Notification Script for Linux Servers # Running IWSS 3.1 for Linux # # Script name: # iwss_disk_notify.sh # # Written by: # Solution Architecture and Validation Team @ Trend Micro # # Date: October 2008

A Trend Micro TrendEdge Solution

18

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

# Email: SAV@dl.trendmicro.com # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Variable List # disk_usage_yellow=75 # % of /opt used before sending yellow alert. disk_usage_red=95 # % of /opt used before sending red alert. email_address=you@company.com # Set this to your email address for alerts.

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Disk Utilization Query # disk_usage=$(df -H /opt | grep -vE "^Filesystem|tmpfs|cdrom|none|/dev/mapper" | awk '{print $4}' | cut -d'%' -f1) disk_remain=`expr 100 - $disk_usage`

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # If Statement to determine which email notification to send # if [ $disk_usage -ge $disk_usage_yellow -a $disk_usage -lt $disk_usage_red ]; then # echo "Yellow Alert! $disk_usage% of /opt used on $(hostname) on $(date)" mail -s "Yellow Alert! $disk_usage% of /opt used on $(hostname) on $(date)" $email_address elif [ $disk_usage -ge $disk_usage_red ]; then # echo "Red Alert! $disk_usage% of /opt used on $(hostname) on $(date)" mail -s "Red Alert! $disk_usage% of /opt used on $(hostname) on $(date)" $email_address else # echo "All ok - Only $disk_usage% of /opt used on $(hostname) on $(date)" mail -s "All ok - Only $disk_usage% of /opt used on $(hostname) on $(date)" $email_address fi

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # End of Script #

4.

Ensure the mail application is running and configured properly for your environment. There are many third-party command line mail applications available. This document lists the basic steps you must follow to modify an existing Sendmail application for use with these tools. Your local mail administrator should be consulted to ensure the configuration matches existing policies. It is beyond the scope of this document to provide all options for email configuration. Work with your system administrator to configure your email environment. The below configuration changes are the minimum required using the existing Sendmail utility. Make all changes with caution and on a non-production server first. These instructions assume an existing Sendmail application which is locally installed and that only needs to be configured to send mail to the downstream smart host (mail relay). As shown in Figure 11, the original submit.mc and sendmail.cf files are copied as a backup.

Note:

5.

A Trend Micro TrendEdge Solution

19

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Figure 11 Edit the submit.cf File to Ensure Proper Email Notification

[root@IWSS31_Master [root@IWSS31_Master [root@IWSS31_Master [root@IWSS31_Master trend]# cd /etc/mail mail]# cp submit.mc submit.mc.ORIG mail]# cp submit.cf submit.cf.ORIG mail]# vi submit.mc

divert(-1) # # Copyright (c) 2001-2003 Sendmail, Inc. and its suppliers. # All rights reserved. # # By using this file, you agree to the terms and conditions set # forth in the LICENSE file which can be found at the top level of # the sendmail distribution. # # Details removed FEATURE(`msp', `[127.0.0.1]')dnl . Details removed :wq! [root@IWSS31_Master mail]# m4 /etc/mail/submit.mc > /etc/mail/submit.cf [root@IWSS31_Master mail]# [root@IWSS31_Master mail]# cd /etc/init.d [root@IWSS31_Master init.d]# ./sendmail restart Shutting down sendmail: [ OK ] Shutting down sm-client: [ OK ] Starting sendmail: [ OK ] Starting sm-client: [ OK ] [root@IWSS31_Master init.d]# Modify 127.0.0.1 to the IP of your smart host

6.

If the m4 command does not work, you can either reinstall the sendmail-cf file or manually edit the existing submit.cf file to reflect the smart hosts IP address. Reinstalling the sendmail-cf file is the preferred method. Test the script and mail functionality by running the script from the command line. If successful, you should receive an email with the servers current disk status in your inbox. If you do not receive a mail, ensure that your downstream mail server is available and that you have configured the Master or Child IWSS server correctly. Next, add the script to the existing cron job running at specific intervals. Daily, weekly, and monthly intervals are available. Figure 12 sets the cron job to notify you on a Daily basis. If you require further control (specific time or time of day), set up the script as a specific cron job by editing the crontab file in /etc directory.

7.

8.

Figure 12 Adding the Script to the Daily Cron Job

[root@IWSS31_Master trend]# [root@IWSS31_Master trend]# cp iwss_disk_notify.sh /etc/cron.daily/ [root@IWSS31_Master trend]#

You are done! This server now emails disk status notifications on a daily basis or at the time you have chosen. Repeat this step for all scanning servers in your environment.

A Trend Micro TrendEdge Solution

20

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Using the IWSS 3.1 GUI to Adjust the Log File Retention Period
You can set IWSS 3.1 to:

Write logs only to the Database Write logs to both to the Database and Log files Write logs only to the log files

By default, Trend Micro sets IWSS to write logs only to the Database. Regardless of what you choose, by design IWSS 3.1 writes usage information to text-based log files before writing them to the local database. Note: Log File Retention is not stored in the centralized database and so must be configured separately on each IWSS 3.1 scanning server. If logs are written to the database, set the number of days to store the log information in the database through the Master IWSS 3.1 administrative console. Go to Logs > Settings > Reporting Logs to set the number of days. The area of the Window where you do this appears in Figure 13.

1. 2.

Figure 13 Setting the Number of Days to Store Reporting Log Data within the IWSS 3.1 Database

3.

Click Save to incorporate any changes.

A Trend Micro TrendEdge Solution

21

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

4.

Go to Logs > Settings > System Logs and set the number of days you want to retain the system log information. Depending on your security policies, you may want to configure a shorter retention period for this information since it does not contain any user data. Click Save to incorporate any changes as appears in Figure 14.

Figure 14 Setting the Number of Days to Store System Log Data within the IWSS 3.1 Database

A Trend Micro TrendEdge Solution

22

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Using a Cron Job to Delete Old Log Files

To ensure the text-based log files maintain your required cleanup schedule, use the following cron job on the Master IWSS 3.1 server. After you implement the cron job, the server will email you a summary of work it performed automatically. Note: Cron job entries are separate from the centralized policy database. This means you must set them up and maintain them separately on each IWSS 3.1 scanning server. Login to the Master IWSS 3.1 server via SSH2 and create a new file in the /opt/trend directory named iwss_log_cleanup.sh. The steps you need to follow appear in Figure 15.

1.

Figure 15 Creating the Disk Notification Script

[root@IWSS31_Master /]# [root@IWSS31_Master /]# cd /opt/trend [root@IWSS31_Master trend]# echo > iwss_log_cleanup.sh [root@IWSS31_Master trend]# chmod +x iwss_log_cleanup.sh [root@IWSS31_Master trend]# ls -al total 24 drwxr-xr-x 4 root root 4096 Oct 30 09:16 . drwxr-xr-x 3 root root 4096 Oct 29 14:31 .. drwxr-xr-x 4 root root 4096 Oct 16 13:43 iwss -rwxr-xr-x 1 root root 1 Oct 30 09:16 iwss_log_notify.sh [root@IWSS31_Master trend]#

2.

Open the iwss_log_cleanup.sh file and place the text in Figure 16 inside it:

Figure 16 Script to Delete Logs after a Specific Time Period

# #!/bin/sh # # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Text-based Log Cleanup Script for Linux Servers # Running IWSS 3.1 for Linux # # Script name: # iwss_log_cleanup.sh # # Written by: # Solution Architecture and Validation Team @ Trend Micro # # Date: October 2008 # Email: SAV@dl.trendmicro.com # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # # Variable List # log_retention_period=60 # Number of days to retain existing log files log_directory=/opt/trend/iwss/data/log # Set the log directory email_address=you@company.com # Set this to your email address for alerts.

A Trend Micro TrendEdge Solution

23

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Record the number of logs older than Log_Retention_Period # num_logs_remove=$(find /opt/trend/iwss/data/log -mtime +$log_retention_period > wc l)

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Record the initial disk utilization # disk_initial=$(df -H /opt > grep -vE "^Filesystem>tmpfs>cdrom>none>/dev/mapper" > awk '{print $4}' > cut -d'%' -f1)

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Remove the logs older than Log_Retention_Period # find $log_directory -mtime +$log_retention_period -exec rm {}\; > /dev/null 2>&1

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Record the final disk utilization # disk_final=$(df -H /opt > grep -vE "^Filesystem>tmpfs>cdrom>none>/dev/mapper" > awk '{print $4}' > cut -d'%' -f1) disk_made_available=`expr $disk_initial - $disk_final`

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Email Notification # (remove remark from echo if want to see results on screen) # #echo "iwss_log_cleanup.sh: $num_logs_remove logs removed and $disk_made_available% disk cleaned on $(hostname) on $(date)" mail -s "iwss_log_cleanup.sh: $num_logs_remove logs removed and $disk_made_available% disk cleaned on $(hostname) on $(date)" $email_address

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # End of Script #

3.

Now ensure the mail application is running and configured as described in the previous section. You can also test the application and setup a specific cron job to issue disk usage notifications which is also described in the previous section.

You are done! This server will now mail out disk status notifications at the time you have chosen.

A Trend Micro TrendEdge Solution

24

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Removing the Configuration

Master/Child Relationships
To remove Master/Child relationships: 1. Go to Administration > IWSS Server Farm on the Children and remove the checkbox for Enable for use in a multiple IWSS server configuration. Click Save to incorporate the change. Remove all the Children. After you have removed them, you can then remove the configuration from the Master server.

2.

Shared Databases
To return the Child servers back to a standalone database configuration: 1. Repeat the use of the setup-postgres-env.sh script and specify the local server when the script prompts you. You will need the name of the local Postgres database, and the superusers name and password to complete this step. Modify the S99ISdatabase file in /opt/trend/iwss/bin so that Remote_DB=NO to ensure the local database starts up when you reboot the server.

2.

Notification Cron Jobs

To remove a cron job after you have initiated it: 1. 2. Back up the script file in the /etc/cron/* directory. (Note: this is an optional step in case you would like to use the script at a later date.) Delete the script.

Once you have completed this step, the script will no longer run. To restart the script, add it again to the cron folder of your choice or add a new crontab entry.

A Trend Micro TrendEdge Solution

25

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Resources
Web Sites
http://trendedge.trendmicro.com/ http://www.trendmicro.com/us/ http://www.postgresql.org/ http://www.redhat.com / http://freshmeat.net / http://www.sourceforge.net /

Documents
This document provides more specific installation information as that provided within the IWSS 3.1 Crossbeam Installation Guide found here:

http://www.trendmicro.com/download/product.asp?productid=90

Specific IWSS 3.1 for Linux installation and administration guides can be found here: http://www.trendmicro.com/download/product.asp?productid=34

A Trend Micro TrendEdge Solution

26

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

About the Author

Jason Pappalexis has been employed at Trend Micro for over 5 years and is currently a Senior Solutions Architect. Prior to Trend Micro, he has worked in system administrator and field engineering roles in the government and public sectors. He holds a Bachelors and Masters degree in Mechanical Engineering and wrote his thesis on Computational Fluid Dynamics.

A Trend Micro TrendEdge Solution

27

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

About Trend Micro Incorporated

Trend Micro Incorporated, a global leader in Internet content security, focuses on securing the exchange of digital information for businesses and consumers. A pioneer and industry vanguard, Trend Micro is advancing integrated threat management technology to protect operational continuity, personal information, and property from malware, spam, data leaks and the newest Web threats. Its flexible solutions, available in multiple form factors, are supported 24/7 by threat intelligence experts around the globe. Founded in 1988, Trend Micro provides individuals and organizations of all sizes with award-winning security software, hardware, and services. With headquarters in Tokyo and operations in more than 30 countries, Trend Micro solutions are sold through corporate and value-added resellers and service providers worldwide. For additional information and evaluation copies of Trend Micro products and services, visit our Web site at http://www.trendmicro.com/.

A Trend Micro TrendEdge Solution

28

Using IWSS 3.1 in a Master/Child Relationship with a Shared Central Database

Contacting TrendEdge Publications

The Trend Micro TrendEdge team is always seeking to provide better solutions. Have a question or comment about this document? We would like to hear from you. Contact us at: sav@trendmicro.com

A Trend Micro TrendEdge Solution

29