iwsva5.0_bestpractices_091112

Securing Your Web World

A Trend Micro TrendEdge SolutionAdvanced Technologies and Techniques to Enhance Your Product

Philip KwanDirector, Product Management 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

Trend Micro™ InterScan™ Web Security VirtualAppliance 5.0

Installation and Configuration Best Practices

November 2009

Trend Micro InterScan Web Security Virtual Appliance Best Practices

A TrendEdge Solution i

Contents Executive Summary ............................................................................................................................. 1 Target Audience and Prerequisites ................................................................................................... 1 Problem Definition ............................................................................................................................... 1 IWSVA Best Practice Overview.......................................................................................................... 2 IWSVA Installation Overview ............................................................................................................. 2 Properly Sizing Your Environment ................................................................................................... 3

Best Practice Suggestions ............................................................................................................. 4 Selecting the Platform ....................................................................................................................... 4

Best Practice Suggestions ............................................................................................................. 5 Selecting Deployment Method and Redundancy ............................................................................. 5

Best Practice Suggestions ............................................................................................................. 6 When Should Server Farms Be Used................................................................................................. 7

Best Practice Considerations ........................................................................................................ 8 Best Practice Suggestions ............................................................................................................. 9

Authenticating and Identifying Your Users .................................................................................... 10 Best Practice Suggestions ............................................................................................................ 10

Authenticating Multiple Users on Shared PCs ................................................................................ 12 Best Practice Suggestions ............................................................................................................ 12

Logging and Reporting Architecture ............................................................................................... 12 Best Practice Suggestions ............................................................................................................ 13

Syslog Servers and Upstream Monitoring Applications ................................................................ 15 Best Practice Suggestions ............................................................................................................ 15

Automated Updates and Email Alerts.............................................................................................. 15 Best Practice Suggestions ............................................................................................................ 16

IWSVA Scanning Policies .................................................................................................................. 16 Best Practice Suggestions ............................................................................................................ 16 White/Black Listing or Bypassing Policies .................................................................................. 16 HTTPS Decryption Policies ........................................................................................................... 17 Working with Multi-Media File Scanning ..................................................................................... 17 URL Filtering Policies .................................................................................................................... 18 FTP Policies .................................................................................................................................... 18

Controlling Access to the Internet................................................................................................... 19 Best Practice Suggestions ........................................................................................................... 20 Supporting Guest Policies............................................................................................................ 20

Scanning Considerations .................................................................................................................. 21 Smart Protection Network – Cloud Based Services ................................................................... 21 Local IWSVA Scan Engines .......................................................................................................... 22 Best Practice Suggestions ........................................................................................................... 23

Protecting Your IWSVA Configuration ........................................................................................... 24 Best Practice Suggestions ........................................................................................................... 24

IWSVA and Third-Party Applications .............................................................................................. 24 Obtaining Additional TrendEdge Documents .................................................................................. 26 Contacting TrendEdge Publications................................................................................................ 27 About the Author .............................................................................................................................. 28

Philip Kwan .................................................................................................................................... 28 About Trend Micro Incorporated..................................................................................................... 29

Copyright© 2009 by Trend Micro Incorporated. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the prior written consent of Trend Micro Incorporated. Trend Micro, the t-ball logo, and InterScan are trademarks or registered trademarks of Trend Micro Incorporated. All other company and/or product names may be trademarks or registered trademarks of their owners. Information contained in this document is provided "as-is" and subject to change without notice. This report is for informational purposes only and is not part of the documentation supporting Trend Micro products. TREND MICRO MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS REPORT. TSS Part No: TE08WSVA50_091112US]


1 A TrendEdge Solution

Executive Summary This document discusses the best practices for installing and configuring Trend Micro’s InterScan Web Security Virtual Appliance (IWSVA) product. The general best practices described in this guide applies to the following Trend Micro products: Trend Micro™ InterScan™ Web Security Virtual Appliance 3.1

Trend Micro™ InterScan™ Web Security Virtual Appliance 5.0

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

Note: Specific commands for some of the features listed in this guide only apply to IWSVA 5.0 and above.

Please refer to your version’s Administrator Guide for more information on the specific features

described.

Trend Micro provides this document "as-is" as a courtesy to interested parties. The accuracy of the

information is solely the author’s responsibility. Neither Trend Micro nor its partners support this

document.

Target Audience and Prerequisites This document is designed for end users and resellers who are responsible for installing and configuring Trend Micro’s IWSVA products. The following professionals benefit most from this document: Systems engineers

Systems administrators

We recommend that you have: Working knowledge of both the VMware ESX application (if installing under VMware) and the underlying

CentOS/Linux operating system used by the IWSVA appliances.

Problem Definition InterScan Web Security Virtual Appliance provides multi-layer, multi-threat protection at the Internet gateway to dynamically defend against Web-based attacks. IWSVA leverages both local and in-the-cloud security components to protect HTTP, HTTPS and FTP traffic, and includes URL filtering, Web Reputation, antivirus, anti-spyware, and Applet Security.

To gain the best performance and highest capacity from IWSVA for your network, the default values may need to be fine-tuned. This best practices guide will highlight key installation and configuration areas for review.



IWSVA Best Practice Overview When installing IWSVA into your networking environment, the following key areas should be reviewed to ensure that IWSVA is properly configured in your environment. Familiarizing yourself with the IWSVA installation and configuration procedure

Sizing your environment

Deciding which platform to install IWSVA

Selecting deployment method and redundancy considerations

When to use IWSVA Server Farms

How to authenticate and identifying users

Logging and reporting architecture considerations

Extending IWSVA’s logging and alerting to external systems

Creating and tuning effective policies

How to best control access to the Internet

Scanning considerations

Backup up your configuration

IWSVA and 3rd party applications

IWSVA Installation Overview This installation overview provides a quick reference on the order and key steps to install and configure IWSVA to function with the core scanning, logging, and reporting features. The detailed sections in this best practices guide will provide the necessary web sites for downloading the necessary material. For complete instructions on installing IWSVA, please refer to the IWSVA Installation Guide. For complete feature and command instructions, refer to the IWSVA Administrator Guide. 1. Obtain the latest IWSVA software and documentation set from the Trend Micro Update Center or by

purchasing the IWSVA installation disks. You can download IWSVA products and updates from:


2. Register the product to obtain the Activation Codes. These will be required to activate IWSVA and its core

modules. Products can be registered at: https://olr.trendmicro.com/registration/us/en-us/product_login.aspx

3. Review the IWSVA Customer Sizing Guide and IWSVA Installation Guide to determine the deployment

topology and the number of IWSVA units required to support your environment.

4. Install the IWSVA application and license the components with the Activation Keys obtained from step 2.

Use the Administration > Product License function to perform this task.

5. Download any service packs and critical patches that are applicable to the IWSVA product you installed.

Service packs and critical patches are version specific and are cumulative with the latest service pack

containing the previous hot fixes and critical patches from the previous service packs. Best practice is to

download and install the latest service pack for your IWSVA version and any newer critical patches to

bring the IWSVA unit up to date.

IWSVA provides operating system updates separately from application service packs. Make sure the latest

operating system patch is also downloaded and applied along with the application service pack. Always

read the patch’s ReadMe file to familiarize yourself with the installation procedure before upgrading your

system.



Use the Administration > System Patch and Administration > Update OS functions to perform these tasks.

6. Configure the system settings. This includes setting the system date and time, configuring optional

network configurations (such as enabling SSH for remote access, PING, optional static routes, etc),

defining optional upstream proxy servers, enabling SNMP, and so forth. Use the Administration function to

perform these tasks.

7. Configure IWSVA to a corporate LDAP server if you need to enforce policies, log events, and report

internet activity based on LDAP users and/or groups. Use the Administration > Network Configuration >

Deployment Mode’s User identification tab to perform this function.

8. Review the default settings for the automatic pattern file and scan engine update intervals. Change to

meet your needs if necessary. You can also perform a manual update for a newly installed IWSVA system

to update the signature files and scan engines. Use the Updates function to perform these tasks.

9. Configure log settings and external syslog servers to set the logging granularity and setup any 3rd party

logging support. Review the default system log retention option and change to meet your needs if

necessary. Use the Logs function to perform these tasks.

10. Create policies to monitor and govern Internet traffic. Policies can be defined for the following protocols

and traffic types: HTTPS, HTTP, Applet & ActiveX, URL Filtering, IntelliTunnel, Access Quota, and FTP. Use

the HTTP and FTP functions to perform these tasks.

11. Define report templates and scheduled reports. Review the default number of scheduled reports to save

for your daily, weekly, and monthly reports. If necessary, change to meet your needs. Use the Reports

function to complete these tasks.

12. Create additional administrator, auditor, or reporter accounts to backup your administrator account and to

grant other users access to administrative and reporting functions. Use the Administration > Management

Console > Account Administration function to complete this task.

13. Backup the IWSVA configuration to keep a copy of the newly created configuration. Use the Administration

> Config Backup/Restore function to complete this task.

14. Optional installation steps may include the following:

Customizing the notification messages

Setting up server farms

Registering IWSVA to the Advanced Reporting & Management (ARM) module

Registering IWSVA to Trend Micro’s Control Manager (TMCM) central management system

Registering IWSVA to Damage Cleanup Services (DCS) server

Properly Sizing Your Environment Before installing IWSVA into your network, you must first determine how many IWSVA servers are required to support your company’s user population and Internet activity. Please refer to the IWSVA Customer Sizing Guide for detailed information on how to calculate the number of IWSVA units needed for your environment.

Things to consider for properly sizing your environment include:



Number of total users in your company that will access the Internet

Number of users accessing the Internet simultaneously

Average number of concurrent sessions used by each active user

Growth in user population and Internet use

The type of server hardware being used

The amount of bandwidth IWSVA needs to scan

Redundancy and failover

Best Practice Suggestions Always size your environment for growth. Trend doesn’t recommend sizing your deployment based on

current maximum peak loads as internet usage will always grow.

Architect redundancy into the IWSVA architecture to prevent against single points of failure and to provide

roll over during a device failure.

Redundant architectures must be designed to support your maximum number of users when it fails over

to the backup unit or secondary. Otherwise, performance and response time expectations will drop when a

unit fails.

Selecting the Platform IWSVA can be installed either as a dedicated security appliance (software appliance) using popular off-the-shelf server hardware or it can be installed as part of a virtual environment using VMware ESX or ESXi. The same installation ISO file is used for both install methods, but the VMware installation requires additional tuning of the virtual machine to maximize performance.



Best Practice Suggestions If maximizing performance and scalability is the primary objective, install IWSVA as a software appliance

on a server platform that can support the maximum number of users in your company. Please refer to the

IWSVA Customer Sizing Guide for detailed information on how to calculate the number of IWSVA units

needed for your environment. This can be found on the TrendEdge web site at:

http://trendedge.trendmicro.com/pr/tm/te/web-security.aspx

If lower operational costs, saving energy, and reducing the number of physical servers is the primary

objective, consider installing IWSVA as a virtual appliance under VMware ESX/i. Please refer to the Trend Micro Software Virtual Appliance Best Practices for VMware Guide for additional information on fine-tuning

virtual machines for IWSVA and ARM.

Purchase the most powerful hardware your budget permits to allow for growth.

Check the CentOS web site for hardware compatibility before purchasing your hardware. Make sure the

hardware purchased is compatible with the CentOS version the Trend product uses. This ensures

compatibility at the OS level. The CentOS web site that lists compatibility issues with various components

can be found at the following web site: http://wiki.centos.org/HardwareList

Check the Trend Micro Software Virtual Appliance page for compatible hardware platforms that have been

tested by Trend Micro. Remember that Trend Micro only tests a few popular hardware platforms to show

compatibility. Most popular off-the-shelf hardware platforms that support the version of CentOS used by

Trend’s software appliances will have no compatibility issue. The Trend Micro tested hardware list can be

found at the following web site:

http://us.trendmicro.com/us/partners/technology-and-platform-provider-partners/certified/certified-server-platforms/index.html

To confirm compatibility, the easiest way to test the hardware platform is to download the same CentOS

64bit operating system that was used to build the Trend product’s base operating system from the CentOS

web site and install the OS onto the hardware platform. If CentOS installs fine, there is an excellent

chance the Trend software appliance will install and operate with little problems.

To download the CentOS operating system, visit http://isoredirect.centos.org/centos/5/isos/x86_64/ (you

can call your Trend sales rep to obtain the information on the CentOS version for the product you’re

planning on installing).

Note: For customers installing under VMware, please reference the Trend Micro Software Virtual Appliance Best Practices for VMware document for additional information on fine tuning IWSVA for VMware

environments. This guide can be found on the TrendEdge document site at:

http://trendedge.trendmicro.com

Selecting Deployment Method and Redundancy IWSVA is one of the most flexible Web gateway security products for deployment options. IWSVA can be deployed in the following topologies: Forward Proxy:

Transparent Bridge

WCCP

ICAP

Reverse Proxy



Each deployment mode has its benefits and services a specific need. You should be aware of the advantages and disadvantages of each deployment mode before deciding on how to install the IWSVA product into your network. Please see the IWSVA Administration Guide for detailed information on each deployment method and what key benefits are offered by each one.

If you are considering redundant architectures, you must review and consider the following points: WCCP – IWSVA supports Cisco’s WCCP protocol to allow you to build load sharing, redundancy, and

scalability into your IWSVA architecture. If your routers and/or switches support Cisco WCCP, this is one

of the most economical ways to add high availability features. One drawback of WCCP is that it can only

redirect popular internet protocols to the scanning devices efficiently. See the IWSVA ReadMe document

for the WCCP versions supported.

ICAP – IWSVA supports ICAP v1.0 devices to allow you to scan content from popular caching servers.

ICAP can also be used to create a scalable architecture through a one-to-many configuration with several

IWSVA servers connected to a single cache server. This is a popular option for customers who need to

cache web content to reduce bandwidth consumption and to lower Internet latency.

SQUID – IWSVA bundles the popular open source caching program, called Squid, to offer customers an

economical way to cache web content without paying additional licensing fees. Squid can be enabled

through IWSVA’s CLI interface and is deployable as a downstream proxy or an upstream proxy in relation

to IWSVA. Squid support is offered through the open source community and is provided by Trend Micro on

its Web Gateway products for convenience.

Proxy Pac File – Simple load sharing can be created through a proxy pac file if you’re deploying in

Forward Proxy mode. Many customers have experienced good results by creating a proxy pac file that

routes traffic to a specific IWSVA device based on source IP address or source network. This allows you to

manually scale your network and to load share users across many IWSVA servers without any added costs

or network complexity. You can also configure the proxy pac file to return multiple proxy servers to build a simple redundancy solution. Be aware that not all browsers may be able to interpret the multiple proxy server response. If they can’t interpret the multiple proxy servers, redundancy will not be possible.

Layer 4 Load Balancing Switches – IWSVA can support external load balancing switches in Forward

Proxy Mode using the “simple transparency” feature. Having an external load balancing switch adds

additional cost and configuration complexity, but delivers the highest performance and flexibility in terms

of redundancy and load sharing. Commercial load balancers that Trend customers have used successfully

include Foundry Networks/Broacade, F5, and Citrix NetScaler. If cost is a consideration, alternative open

source software-based load balancers such as Red Hat Enterprise can also provide good scalability and

redundancy options.

If installing under VMware, consider using VMware’s redundancy and fault tolerant functions to create a

robust and scalable solution. These include:

VMotion

vSphere Fault Tolerance Services

Be aware that at the time of this writing, vSphere’s Fault Tolerance service only permits one virtual CPU.

This allows a full redundant solution to be developed, but offers less performance due to the single CPU

limitation. For more information on setting up a vSphere FT configuration, refer to the Best Practices Guide for Utilizing VMware Fault Tolerance for High Availability document.

Best Practice Suggestions IWSVA uses a hybrid malware scanning architecture that is comprised of cloud based scanning and on box

scan engines. This solution provides one of the industry’s highest detection and prevention rates. Cloud



based scan engines provide proactive detection and blocking services based on reputation services. To

ensure fast performance with low latency, you need to provide IWSVA access to a fast and robust DNS

architecture. ISP provided DNS servers should not be used as frequent DNS requests made by the IWSVA

device may not be adequately supported and may possibly overwhelm the ISP’s DNS server.

IWSVA’s internal clock settings should be synchronized with other servers and devices in your security

architecture. These include LDAP servers, syslog servers, upstream SIEM devices, and Trend Micro’s

Advanced Reporting and Management server. If the date and time are mismatched, you may experience

improper logging and reporting of critical events. For best results, use the same set of NTP servers to sync

the date and time on all devices.

For high volume installations of more than 3000 users, you should consider a dedicating a server to house

the Squid caching function (if enabled). During high workloads, IWSVA and Squid will contend for the

same disk services. This will affect the cache hit performance as well as IWSVA’s reporting performance.

One alternative is to use two physical hard disk adapter cards in the same server with two separate disk

volumes – one for IWSVA and one for Squid.

For redundancy and scalability, consider installing more than one instance of IWSVA and using one of the

scaling options mentioned in this section to eliminate single points of failure and improve system up time.

For installations with an upstream proxy, you must properly configure IWSVA’s upstream proxy settings in

the Forward Proxy settings and the Update Connection Settings to ensure proper Internet access.

If you are planning to use IWSVA to protect external facing web servers that customers can access,

consider installing a separate instance of IWSVA in reverse proxy mode to protect these web servers. Do

not place the external facing web servers behind your corporate IWSVA server that your normal users

would go through as this may affect your ability to enforce both customer facing policies and your normal

corporate user policies.

After installing IWSVA, always check the Trend download site for additional critical patches and/or service

packs to ensure that the latest patches are installed. Patches listed on the IWSVA Download site listed in

chronological order. Always apply the latest application and OS patches to your specific version. IWSVA

service packs are backwardly compatible. That is, the latest service pack will always contain any hot fixes

and patches issued prior to the service pack’s release date. You do not need to install previous patches

before the latest applicable service pack for your product. IWSVA may have the following patch types:

Application Service Pack – a service pack or patch that is used to update the IWVSA application. The

latest service pack will contain all previously released patches.

OS Service Pack – a service pack or patch that is used to update the operating system and driver

files. The latest service pack will contain all previously released patches.

Critical Patch – a patch that is used to fix an urgent application or OS problem and will not contain

previous patches. It is only issued to fix a specific problem.

When Should Server Farms Be Used IWSVA supports a deployment mode called “Server Farm”. The server farm deployment allows two or more IWSVA units to be clustered together to share common policy information between the server farm members. Server farms are best suited in deployments where keeping the scan policies tightly synchronized are critical to daily operations. They are not well suited for implementations where both configuration information and policy information synchronization is required.



Customers who need the ability to synchronize both configuration and policy information between multiple IWSVA units should consider using the Advanced Reporting and Management (ARM) module as it provides more advanced management, logging, and reporting features. Important features to review for deciding if IWSVA server farms are right for your environment include the following best practices considerations.

Best Practice Considerations IWSVA server farms are configured in a parent and child relationship. Only one parent unit can be defined

within the server farm. Multiple child members can be registered with a single parent device.

Child members use the Parent’s policy database and also receive the blocked URL and infected URL lists

from the parent.

Server farms only share specific policy information between farm members. Policy information includes

the IWSVA scanning policies only and not the policy setting information. Policy items shared between all

members of the server farm on the parent unit’s policy database:

HTTPS Policies

HTTP Policies

Applets and ActiveX Policies

URL Filtering Policies

IntelliTunnel Policies

Access Quota Policies

FTP Scan Rules

Server farms do NOT replicate configuration information between the farm members. Configuration

information includes system configuration parameters and the global white and black lists. Server farms

do not share the following configuration information that is stored in each IWSVA server’s configuration

files and database files. These items must be managed separately on each server farm member:

HTTPS scan settings

HTTP scan settings

Applets and ActiveX settings

URL Filtering settings

URL Access Control settings (global white and black lists)

HTTP Configuration settings

Digital Certificate settings

FTP Configuration settings

Report and Log configuration settings

Update configuration settings

Notification configuration settings

Administration configuration settings



Log event information that is shared between all server farm members include:

Access log information

Violation log information

Performance log information

DCS Cleanup log information

Log event information that is NOT shared between all server farm members includes the following. You

must review each log file separately on each farm member to obtain the following information:

HTTP log information

FTP log information

Admin UI log

Audit log

Mail delivery log

Update log

LogtoDB log

Supported policy items (listed in this section) that are changed on either the parent or the child members

will be reflected on all farm members - as they share one database.

The server farm master database is not clustered. Separate database clustering and backup must be

configured for full redundancy. The following web site offer information on clustering PostgreSQL:

http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling

Server farms do not load balance traffic between the farm members. An external load balancing method

or device is still required to balance the traffic between each farm member. Common load balancing

methods can include WCCP, ICAP, Layer 4 load balancing switch, or a simple Proxy.pac file.

Server farms will not provide a single central management console to enable or disable HTTP/s and/or FTP

scanning. Enabling and disabling HTTP/s and FTP scanning must still be performed on each individual farm

member.

Server farms will not provide a central dashboard to view each member’s health, performance metrics, or

utilization metrics. You must log into each farm member to obtain this information.

IWSVA uses TCP port 1444 as its default server farm communication protocol port. If the server farm

members are placed in different areas of the network, make sure each IWSVA unit in the farm is able to

communicate with each other. If there are firewalls between farm members, make sure the required port

is permitted between the farm members.

Best Practice Suggestions Only use server farms when you need instantaneous replication of policy changes throughout farm

members.

Implement database redundancy through database clustering to prevent a single point of failure.

Backup your configuration and policy information with the Configuration Backup/Restore function regularly

to prevent loss of configuration and policy information. Do this on each farm member to fully backup your

IWSVA environment.

For customers who need to replicate both policy information as well as configuration information between

multiple IWSVA units, consider Trend Micro’s Advanced Reporting and Management (ARM) module for

InterScan Web Security Gateways. ARM provides centralized management, logging, reporting, and

synchronization of IWSVA configuration and policy information.



For more information on ARM, please reference the following Trend Micro product web site:

http://us.trendmicro.com/us/products/enterprise/advanced-reporting-management/

Note: Reference the following TrendEdge documents for setting up an IWSVA server farm:

- Maximizing InterScan Web Security Suite 3.1 for Linux Performance using a Centralized PostgreSQL

Database

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

TrendEdge documents can be found at:

http://trendedge.trendmicro.com/pr/tm/te/web-security.aspx

Authenticating and Identifying Your Users IWSVA identification methods include: IP address

Host name (modified HTTP headers)

User/Group name authorization (LDAP)

Best Practice Suggestions The simplest identification method is the IP Address method and requires no additional configuration to

achieve. Policies, logs and reports will use the client’s source IP address as the identification parameter.

For Host Name based identification, a small workstation agent is required to automatically obtain the host

name information from the HTTP header. The agent installation file register_user_agent_header.exe is provided on the IWSVA server and can be obtained one of two methods:

Method One: Go to the InterScan Web Security Virtual Appliance Command Line Interface (CLI)

Login using the root account

Go to /usr/iwss/bin directory

Copy the register_user_agent_header.exe file to /etc/iscan/UserDumps

From a client computer, go to the InterScan Web Security Virtual Appliance Management Console

Go to Administration > Support

Select register_user_agent_header.exe from the Select Core or System File(s) list

Click Download to your computer



Method Two: Download it from the Trend IWSVA Download Site:

http://www.trendmicro.com/download/product.asp?productid=86#patch

When configuring IWSVA to work with an LDAP server for user and group information, the most critical

step is making sure that the IWSVA and LDAP servers’ date and time settings are synchronized. Trend

Micro highly recommends using the same NTP server(s) to synchronize all relevant servers.

IWSVA can support user authentication by using a single domain or using a global catalog server for

multiple domains. To configure IWSVA for use with a global catalog server, use the global catalog port

number (3268) in the LDAP Listening Port Number setup parameter. If there is a firewall between the GC

server and the IWSVA server, make sure the firewall is allowing the GC port number between the devices.

IWSVA uses the Active Directory SAM account ID parameter to authenticate the client to the AD server.

Use the DOMAIN\User_ID format.

Enable LDAP Referral Chasing to provide primary and secondary LDAP support. If you are using the GC

port, referral chasing is NOT required and is not supported.

Starting with IWSVA 5.0, transparent authentication is supported to enable IE clients to automatically

authenticate to the LDAP server. This reduces the number of authentication popup windows the end users

see. You must enable the “Automatic Authentication” feature in the client’s Internet Explorer or Firefox

browser to enable this feature. Refer to the Auto Authentication Support with MS Active Directory

document for detailed information on enabling this feature.

You can leverage the Active Directory GPOs to configure and push out the browser configurations to many

users or hosts simultaneously and to enforce the settings.

If you are using Microsoft Active Directory as your LDAP server, IWSVA uses Active Directory’s Common

Name or “Display Name” in its logs and reports. When filtering for a specific user, use the Active Directory

Display Name value and not the Account ID value. For example, if the account name is “jsmith” and the

display name is “John Smith”, jsmith is used to authenticate to the Active Directory server and John Smith

is displayed in the IWSVA logs and reports. Use the “John Smith” display name as the report filter.

You can fine tune the User ID Cache timeout parameter to meet your requirements. The default user id

cache timeout is 1.5 hours and this value can be extended or shorted to reduce or increase the

authentication interval. See the “ipuser_cache” CLI command in the IWSVA Administrator Guide for more

information.

Do not completely disable the “User ID Caching” function on IWSVA unless instructed by Trend Micro

Technical Support. Disabling the UserID Cache will cause more requests to be directed to the LDAP server.

For servers and other un-manned hosts that need to access the Internet without going through the

authentication process, white list their IP addresses in the Network Configuration > Deployment Mode >

User Identification > LDAP Authentication White List function to allow them to pass through the IWSVA

unit without authenticating.

For applications that need to access the Internet before a browser authentication is performed, (such as

users who bring up Microsoft Office applications before starting their browsers and authenticating to the

IWSVA server) white list the specific URL that the application is trying to access in the global white list

under the HTTP > URL Access Control > Global Trusted URLs list. This will allow the applications to access

to these sites without prior authentication. Be very specific about the site the application is trying to

access. If you define these sites too broad, such as listing the parent domain and not the specific site’s

URL, all users access the parent domain will be granted access. An alternative work around is to instruct

users to open their browsers and authenticate first before using applications that access the Internet.



Authenticating Multiple Users on Shared PCs Supporting multiple users on a single shared PC using Microsoft Active Directory server for authentication can present some challenges to IT managers and users alike. IWSVA provides authentication based on a browser challenge and can support the authentication of multiple users on a shared PC using Microsoft Internet Explorer as the default browser.

Best Practice Suggestions

Leveraging Microsoft ShellRunas Utility For shared PCs, you can leverage the Microsoft ShellRunas utility to force the user to authenticate each

time Microsoft Internet Explorer is started. The AD credentials are used to authenticate the user and

Internet Explorer will leverage the credentials to automatically populate the user ID information in the

HTTP header to allow IWSVA to identify the user for logging, reporting, and policy enforcement purposes.

Download the MS ShellRunas utility from:

http://technet.microsoft.com/en-us/sysinternals/cc300361.aspx

Users must remember to shut down their IE browser sessions when they’re finished using the computer.

This allows Microsoft Internet Explorer to prompt the next user for their credentials. User education is

critical to the success of this tool.

Optionally, you can also modify the IP User Cache parameter to extend or shorten the cache interval for

the authenticated user cache to further fine tune when users should be prompted for their authentication

credentials. The default IWSVA user cache value is 1.5 hours (90 minutes). See the “ipuser_cache” CLI

command for more information.

Note: Reference the following TrendEdge document for more information on setting up IWSVA to operate with the ShellRunas utility: Configuring IWSx to Allow Multiple Users of the Same Windows Account to Access the Web via Internet Explorer.

Logging and Reporting Architecture IWSVA can perform logging and reporting locally on the same IWSVA server, externally to another instance of IWSVA, or to Trend Micro’s Advanced Reporting and Management (ARM) platform. You should take the following best practice suggestions into consideration when determining how to configure the logging and reporting functions.



Best Practice Suggestions If your environment requires fast on-demand reporting without latency impact on malware scanning

operations, you should consider offloading the logging and reporting function to an external reporting

component. Trend recommends the one of the following methods to support off-box reporting:

Install the Advanced Reporting and Management Module (ARM) to take advantage of faster reporting

as well as dynamic dashboards, real-time activity monitoring, drilldown reporting, advanced reports,

custom reporting, automated offloading and grooming, centralized policy and configuration

management, and policy synchronization.

Install a separate instance of IWSVA to perform dedicated logging and reporting functions. The

IWSVA unit performing the scanning operations can be configured to redirect its logs and reports to

the 2nd IWSVA unit.

Offloading logging and reporting functions will allow IWSVA to run more efficiently as the CPU and

memory resources normally used by the complex reporting tasks will be running on a separate server.

Having the reporting functions on a separate server will can significantly improve the logging and

reporting performance as well as the scanning performance.

If you are using an off box reporting solution, make sure you have adequate bandwidth between the

IWSVA scanning server and the reporting server. Gigabit Ethernet cards are highly recommended as well

as fast networking switches to ensure low network latency. Try to keep the number of routing router hops

between the servers to a minimum.

Ensure that all IWSVA and ARM units are setup to the same date and time. Leverage Network Time

Servers (NTP) servers to synchronize time and configure to the same time zones. This is critical for proper

operation.

Fine-tune the logging function to record only what you need. IWSVA can log events in one of three ways:

Detailed Mode – Logs every user visit and all associated objects from the web pages. This is also

commonly referred to as “verbose reporting” as all information is recorded. This method provides the

highest level of log and report detail, but also increases the size of the log and report databases the

most. Use this option if you need to record all information for Internet activity or you need highly

accurate user activity information - such as bytes transmitted or internet surf time used by each user.

With this logging mode, larger environments with over 2000 users may see significant increases in

their log files size. Refer to the IWSVA Customer Sizing Guide for more information on how log and

database sizes are calculated.

To enable the detailed logging mode, select the “Log every user visit along with any associated files”

option from the Log Settings menu.

Summary Mode – Logs only the session start to each web site and any objects larger than a

specified size. The default object size is 1024KB. This mode greatly reduces the detailed information

collected from user Internet activity and offers the best balance of logged events and database size.

Compared with the detailed logging mode, this mode captures about 1/3 of the information. For most

companies, this is the preferred logging mode.

Remember that the summary mode reduces the information logged by about 2/3rd. If you are using

the ARM reporting system, the bytes transmitted and internet surf time recorded will be about 1/3 of

the actual values for each user.

To enable the summary logging mode, select the “Log each user visit as one entry along with any files

that are at least 1024KB” option from the Log Settings menu. You can change the size parameter to

meet your needs. Increasing the size will lower the amount of events logged and decreasing the size

will increase the amount of information logged.



Size Mode – Logs only the objects that are above the specified size. This mode is used to record

large file transfers or objects and do not record the session start information for reach web site

visited. This mode is often used by service providers to log large transfers and is not well suited for

enterprise logging that needs to record the web sites their users go to.

To enable the size logging mode, select the “Log each user visit only with files that are at least

1024KB” option from the Log Settings menu. You can change the size parameter to meet your needs.

If you are using ARM for centralized logging and reporting and want to increase the frequently of

information exchange between IWSVA and ARM to accelerate the data refresh rate on ARM’s dashboard,

reduce the logging intervals for the Performance Data and the HTTP/FTP Access Events to 1 minute. This

is done in the Log Settings menu.

Set the Database Log Update Interval to 30 seconds to speed database cache flushing. This will speed the

database updates to ARM and allow faster refresh rate. This is done in the Log Settings menu.

Consider writing event logs to the “Database Only” to improve performance. Writing to both the database

and the text Log Files will add overhead, but will allow you to export the text based logs for other 3rd party

systems to use. You can also use the text files to perform manual searches outside of the IWSVA server -

using any text based editor. This setting is made through the Log Settings menu.

If you are using ARM for centralized logging and reporting, you may want to lower the interval that IWSVA

uses to send networking data to ARM. By default, network information is sent to ARM once every 10

minutes (600 seconds). To allow ARM to display near real-time networking information, change the default

values from 600 seconds to 60 seconds by modifying the following Metrics-Maintenance parameters in the

IWSVA’s intscan.ini file.

Login to the IWSVA’s OS shell – see the Administration Guide for more details.

Go to the /etc/iscan directory – type: cd /etc/iscan

Edit the intscan.ini file using the vi editor – type: vi intscan.ini

Search for the “metrics-maint” section – type /metrics-maint

Go into the insert edit mode – type i (for more information on vi editor commands, do a Google

search on “vi editor commands”)

Change the following parameters’ interval times from 600 seconds to 60 seconds:

transaction_count_logging_period=60

transaction_timing_logging_period=60

violation_count_logging_period = 60

throughput_logging_period=60

resource_utilization_logging_period=60

Exit vi’s edit mode – press the <esc> key and type semi-colon “:”

Save the file and exit – type wq (this stands for write and quit)

Exit the OS shell and restart the metrics-maint service or simply reboot the IWSVA unit to activate

the changes. You can use the following IWSVA CLI commands to restart the service or restart the

IWSVA server. Not all CLI commands are available with all versions of IWSVA, please refer to the

IWSVA Administrator Guide’s CLI Appendix for more information.

To stop and start the metrics-maint service: service metric_mgmt [stop][start]

To reboot the IWSVA server: reboot



The default number of days IWSVA will retain information in its logs is 30 days. If you need to extend

this for compliance purposes, change this value in the Log Settings > System Logs tab. Data older

than the retention days will deleted automatically from the log and database files. The longer the data

retention period, the more disk space is required on the IWSVA or ARM server.

Syslog Servers and Upstream Monitoring Applications Starting with version 5.0, IWSVA can support up to a maximum of four external syslog servers or upstream monitoring applications. IWSVA sends events to these devices with the syslog protocol (UDP port 514).

Best Practice Suggestions IWSVA allows you to select which events to send to each syslog device in one of two ways:

By event log type – such as virus event, spyware event, performance information, audit or system

event.

By event priority level – such as all emergency classified events, alert events, warning events, and

information events.

You can separate event logs and send specific event types to a particular syslog server. For example, you

may want to configure a syslog server to receive only the auditing, system, and URL blocking event types

for the Network Operations Center (NOC) team. But for the desktop team, you may want to create a

syslog server to receive only the virus and spyware events.

If you would like to extend IWSVA’s email alerting services with other notification capabilities such as

texting, pager notification, SMS messaging, etc, you can leverage any popular network monitoring

application and send the relevant event types to its alerting engine. Popular external monitoring and

alerting solutions include HP OpenView, IBM Tivoli, CA UniCenter, etc.

If your company uses a centralized Security Information and Event Monitoring (SIEM) solution, you can

use IWSVA’s syslog function to send log events to it for centralized logging and monitoring purposes. This

allows you to leverage the SIEM system’s event correlation capabilities for better visibility into Internet

activity.

Automated Updates and Email Alerts IWSVA updates its malware detection signature files and scan engines periodically to ensure that all scanning components are up-to-date with the latest detection capabilities. You can also configure IWSVA to send events and alerts to an email distribution group to ensure critical events are being monitored proactively.



Best Practice Suggestions You can fine tune IWSVA’s update schedule through the Updates > Schedule menu to increase the auto

update frequency or lower it.

If you have an upstream proxy device, make sure the Updates > Connection Settings are configured with

the upstream proxy’s IP address and proxy port. Otherwise, automatic updating will not be possible.

Configure the SMTP server and email distribution group for email alerts in the Notifications > Email

Settings menu screen. If this is not setup properly, you will not receive any IWSVA email events for critical

notifications or reports.

IWSVA Scanning Policies IWSVA policies are based and grouped on its protocol and scanning functions. Policies are created and enforced onto a specific set of IP addresses, LDAP groups, and/or LDAP user accounts. Keep the following best practice suggestions in mind when creating IWSVA policies.

Best Practice Suggestions

Policy Execution Order Policies have a specific execution order. Policies listed in the beginning of the policy list (top) with a lower

priority number are executed first.

IWSVA’s policy execution methodology is from a top down approach – similar to many popular firewalls.

Starting at the top of the policy list, IWSVA will attempt to match on each policy. Once a match is made

for a specific host IP, Group, or User, the policy is executed and all subsequent policies beneath the

matched policy are ignored.

Create and place the specific narrower focusing policies at the top of the list and the more general broad

based policies lower in the list. For example, if you wanted to grant a specific host or user access to a

normally blocked URL category, you would create a policy for that specific host or user granting them

access and place this policy above the general policy that blocked the URL category.

If custom categories are used in the HTTPS Decryption or URL Filtering functions, they take precedence

over the Trend pre-defined categories. This allows you to use custom categories to override Trend’s

supplied URL categories.

White/Black Listing or Bypassing Policies There are a number of different ways to create exceptions or white lists to policies.

You can create custom URL Categories with the white listed domains and sites and place these ahead

of the IWSVA provided URL categories. A maximum of 64 custom categories are supported with

IWSVA v5.0.

You can create Approved URL Lists and/or Approved File Lists and include them in each policy’s

Exception tab. The limit of Approved Lists is based on memory so you can create over 1000 approved

list objects if needed. This is a much more effective way of bypassing or white listing URLs and files.

You can create more focused policies that apply to specific hosts, users, or groups for granting or

denying access and place these polices above the general policies that apply to a more broader

audience.

Custom categories can be used for URL Filtering and HTTPS Decryption. The number of unique IWSVA 5.0

Custom Categories supported is 64. Architect your policy structure to ensure that you will not run out of



custom categories in the future when you scale. See the previous point on other methods to white list

policies.

By default, white listed items in the Exceptions tab of each policy will still be scanned for malware. If you

are confident the white listed items are safe, you can bypass scanning by selecting the “Do not scan the

contents of selected approved lists” checkbox in the policy’s Exceptions tab. This will free up CPU

resources as trusted sites and files will not be scanned.

If you need to bypass a Trend URL rating for its Web Reputation Service or its URL Filtering service, you

can accomplish it in one of several ways:

Add the URL and/or domain to the global white list.

Create an Approved List object for the URL and/or domain and add it to the Exception Tab in the

policy.

Create custom categories and add all exception URLs and domains to an “Allowed” category or a

“Blocked” category and use the URL Filtering rules to allow or block that custom category.

Use the IWSVA’s URL Re-Classification & Lookup feature to request a manual review of the URL or

domain in question. You can use any of the above methods to white list the site until Trend can

respond to your re-classification request.

IWSVA provides blacklisting through a global blacklist using the HTTP > URL Access Control > Global URL

Blocking function. Any domain, site, or URL listed in this black list will be blocked for all users.

HTTPS Decryption Policies HTTPS decryption policies are CPU and memory resource intensive. Select only the URL categories that are

critical for decryption and scanning. You can also use Custom Categories to include the sites that you only

need decrypted and scanned - verses selecting an entire URL category.

If you are deployed in Forward Proxy Mode or WCCP Mode, you can redirect HTTPS traffic to a separate

IWSVA unit to scale performance.

Consider using external load balancers to scale HTTPS scanning if WCCP or other Forward Proxy methods

are not available. If cost is a critical factor, Red Hat Enterprise offers a very cost effective software-based

load balancing solution.

If you are using an upstream proxy and have LDAP authentication enabled, IWSVA will not operate

properly with HTTPS scanning. This is due to the upstream proxy’s limitation on how it can present the

HTTPS traffic back to IWSVA.

In order to bypass the Trend provided certificate message on the Client’s browser, when IWSVA re-

encrypts the traffic to the client, you can install your own trusted certificate into the IWSVA server. You

can generate a trusted certificate from your own certificate server or purchase a certificate from a well

trusted certificate provider – such as VeriSign.

Note: IWSVA 5.0 will support hardware acceleration cards for HTTPS decryption in an upcoming version.

Working with Multi-Media File Scanning The Internet hosts many types of streaming media files and properly configuring IWSVA’s HTTP policies

can improve the user experience for real-time information. By default, IWSVA’s HTTP scan policy’s Virus

Scan Rule is set to “Scan Before Delivery”. This setting will cause all multi-media files using HTTP port 80

to be fully downloaded to the IWSVA unit and scanned before delivering to the user. This will disrupt the

normal flow of multi-media content and cause a dely.

To allow the multi-media files to stream through with minimal latency, change the “Scan Before Delivery”

option to “Deferred Scanning” in your HTTP policy’s Virus Scan Rule. This setting is based on a per-policy



bases so you can create specific policies that use the Deferred Scanning method and others that use the

Scan Before Delivery method. Users that need access to streaming media files should be configured with

Deferred Scanning.

To improve the response times for streaming content, you can also fine tune the Large File Handling

parameters to stop scanning files over a specified size. As viruses and malware are often propagated in

smaller files, setting the “Do not scan files larger than…” parameter to a lower value can help reduce

scanning overhead and improve response times for large multi-media files.

URL Filtering Policies URL Filtering policies are created to block or monitor access to specific domains and web sites. IWSVA

offers over 80 pre-defined URL categories and customers can create up to an additional 64 custom

categories with IWSVA 5.0.

URL Filtering also provides a large number of “Computer/Harmful” based categories that can be used to

proactively block access to sites known to contain malware. Blocking malware before it reaches your

network is the best protection method as it eliminates any chance of infection and it reduces the

bandwidth consumption. If these URL categories are enabled, the URL security blocking will take place

before any local scanning – further reducing the amount of on box scanning IWSVA performs and

eliminating unnecessary traffic loads.

Custom URL categories will always take precedence over Trend pre-defined categories.

You can define up to two sets of “work time” hours. Any time not specified in the work time is

automatically considered leisure time in the policies. The work and leisure times are global settings

and apply to all URL Filtering policies.

For new users, you may want to enable the “monitoring” function on suspect URL categories to

monitor the user activity before turning on the block function. This allows you to fine tune your

URL filtering policies and white / black lists for controlling access.

You can customize the URL Block message that the user sees with the Notifications > URL Blocking

message. Many Trend customers also include a link to an internal feedback web portal to allow

users to submit reclassification requests or suggestions. You can also include the link to Trend

Micro’s URL re-classification site as well.

Administrators can submit URL reclassification requests using the URL Filtering > Settings > URL

Re-Classification & Lookup function.

FTP Policies FTP scanning is performed on a standalone or FTP proxy architecture. If you do not have an upstream FTP

proxy, select “standalone” as your FTP scan configuration.

IWSVA supports one global FTP scanning policy that protects all users and scans in both upstream and

downstream directions. IWSVA defaults to the Passive FTP mode where the client initiates the data

channel to the server. If you are supporting Active FTP, you must configure the FTP policy to Active FTP.

Clients need to proxy to the IWSVA FTP server to scan FTP their sessions. They can do this by setting their

FTP destination host to the IP address or Fully Qualified Domain Name (FQDN) of the IWSVA server and

placing the true FTP server’s destination information into the authentication ID parameter.

For example, a user wants to scan the contents for files downloaded from ftp.abc.com using their FTP

client. Using the graphic below as an illustration, the user would put the IP address or FQDN of the IWSVA

unit in the FTP host name – such as “my-iwsva” in this example is the company’s DNS entry for their

IWSVA server. They would then put their FTP authentication account and the true destination address or

FTP FQDN in the User ID field – such as [email protected].



Figure 1.

You can use the FTP > Access Control Settings function to grant specific hosts access to the FTP protocol

and to limit which FTP servers they can access. These rules are based on IP address and not LDAP objects.

If you limit which hosts can access the FTP protocol using the Access Control Settings, you should also

configure your firewall to block the FTP protocol from all other devices. The firewall should only allow the

IWSVA server to use the FTP protocol. This disables the ability for users to get around the FTP scanning

policy.

Controlling Access to the Internet There are several ways to restrict specific users and/or hosts from accessing the Internet using the HTTP, HTTPS, and FTP protocols. Some of the most popular best practices methods are listed below:



Best Practice Suggestions Enabling LDAP Authentication is one of the easiest ways to ensure that only authenticated users are

granted access through the IWSVA server. Using policies, you can then further grant or deny access rights

to specific URLs or domains.

To prevent unauthorized devices from accessing the Internet using HTTP, you can configure the HTTP >

Configuration > Access Control Settings function to include the IP addresses and IP address ranges of

approved hosts. You can also define the specific HTTP web servers they can access using the Server IP

White List feature.

To limit the TCP ports that can use the HTTP and HTTPS protocols, you can modify the Destination Port

lists for each protocol under the HTTP > Configuration > Access Control Settings function. This will allow

you to restrict applications that use HTTP or HTTPS over non-authorized ports. In Proxy mode, you can

also use your firewall to block all non-authorized HTTP traffic originating from other IP addresses other

than the IWSVA server(s).

To prevent unauthorized FTP transfers that can bypass the IWSVA server’s FTP policy, configure your

firewall to block all non-authorized FTP traffic originating for other IP addresses other than the IWSVA

server(s).

IWSVA’s URL filtering function can block many popular non-business applications – such as proxy

avoidance sites. In order to make this effective, you need to ensure that the users’ HTTP traffic is

redirected to the IWSVA server. The following methods are popular redirection strategies.

If deployed in forward proxy mode, ensure that users cannot change their browser’s proxy settings to

bypass the IWSVA unit. You can use Microsoft GPO’s to enforce the proxy settings in supported

browsers.

Use your firewall to block all non-authorized devices that attempt to use HTTP, HTTPS and FTP

protocols. This forces all Internet traffic through authorized proxies and eliminates the ability for users

to install non-authorized browsers that can bypass your proxy settings.

Deploy IWSVA in Transparent Bridge mode between the internal network and the firewall or border

router. Transparent bridge mode doesn’t require the modification of the browser proxy settings.

If your firewall performs Network Address Translation (NAT), placing the IWSVA unit before the

firewall will allow you to obtain the user information. Placing it after a NAT’d firewall will limit the user

information the IWSVA sees.

Supporting Guest Policies There are several ways you can configure IWSVA to support guest or casual users. The following are a few best practices that many Trend customers have used successfully.



For guests that do not have accounts on your LDAP server, you can give them Internet access through

IWSVA’s Guest Services. Guest services are available when IWSVA is deployed in forward proxy mode and

guest services are enabled through a unique Guest Proxy Port Number. The default Guest Port number is

8081. Guests simply configure their browser’s proxy settings to the IWSVA unit’s IP address or FQDN and

use the guest port number to access the Internet. Guests are not required to authenticate to the IWSVA

server and are governed by the Guest policies that are defined.

Companies that have enterprise class WiFi access points (APs) or managed switches can also

leverage the VLAN capabilities to define a specific Guest SSID and/or VLAN that uses a separate IP

address range. The Guest address range can be defined in a separate Guest policy that is used to

control where Guests can go on the Internet and how their traffic is scanned and enforced.

For guest accounts that do not need authentication services, you can white list the Guest IP

address range(s) using the LDAP Authentication White List found in the Administration > Network

Configuration > Deployment Mode > User Identification tab.

You can also setup a separate IWSVA instance to handle casual users. This will fully isolate the

corporate users from non-corporate users and allow full configuration and policy management for

your guests, contractors, and other interim users. The separate IWSVA server can be configured to

have a completely different set of global settings – such as authentication requirements, global

white lists, global black lists, global FTP settings, and so forth.

Scanning Considerations IWSVA’s malware scanning architecture is a hybrid solution that uses cloud-based malware detection methods such as Trend’s Smart Protection Network (SPN) and local on box scan technologies and signature files.

Smart Protection Network – Cloud Based Services IWSVA’s Smart Protection Network is the industry’s highest performing cloud-based malware protection service. Smart Protection Network has the following malware detection components: Web Reputation Services (WRS) is comprised of several correlated services that provide proactive

detection and blocking against known bad web sites, domains, files and objects, as well as email related

items - including anti-pharming and anti-phishing detection.

Domain reputation

Page reputation

Email reputation

File reputation

URL Filtering Service stores its URL database in the cloud for rapid updates and protects Trend Micro’s

global user base without the need to download and update URL database files on the IWSVA server. This

provides up-to-date URL information to every customer and accelerates the proactive protection

capabilities to reduce the time a bad site is found to the time it is added to the URL database to protect all

customers.

Feedback Loop provides real-time information from all of Trend Micro’s products to update the SPN

cloud-based components and URL filtering databases. Malware detected on customer premise equipment

are fed back into the cloud architecture and used to fine-tune information in real time. This provides fast

proactive protection with low false positives to Trend’s global customer base.



Best Practice Suggestions Smart Protection Network uses cloud-based services and relies on DNS queries for lookups. In order to

ensure fast response and minimum latency, the IWSVA device must be configured with a primary and

secondary DNS server.

The DNS servers must be able to support the volume of DNS requests made by IWSVA. In general, before

IWSVA builds up its local DNS cache, two DNS requests will be made for each URL accessed. Make sure

your DNS server is installed on a server with enough resources and performance to handle the extra DNS

volume.

Your DNS server should have a fast network card and be installed on a fast network switch to reduce

latency.

Trend recommends on site DNS servers verses ISP provided DNS servers that are housed outside of the

company’s network. In general, ISP DNS servers have higher latency and do not support large numbers of

DNS queries from a single IP address. Many ISP DNS servers have throttling mechanisms that limit the

number of DNS requests per second and can affect IWSVA’s WRS performance.

Try to place your DNS server as close to the IWSVA unit(s) as possible to eliminate unnecessary network

hops between the devices to improve network response time and performance.

WRS and URL Filtering requests are made over HTTP port 80. Do not block the IWSVA management IP

Address for these ports on your firewall.

Local IWSVA Scan Engines IWSVA provides local on box scanning to ensure that content downloaded from the Internet is scanned for malware. Smart Protection Network’s Web Reputation Service and URL Filtering services can filter a large percentage of the well-known and newly discovered malware sites and content, but local file scanning ensures that files and objects received are free of embedded viruses, worms, and other malicious code such as Trojans.

IWSVA provides the following local scan engines: WRS Page Analysis provides real-time content scanning with automatic update service to the Smart

Protection Network to ensure that no zero-day threats are found on web sites with good reputation

ratings. Any malware found triggers an automated update to the Smart Protection Network to re-examine

the source of the content and to update its reputation score.

File Type Block provides the ability to identify and block over 60 different file mime types. These can

include popular files such as Java applets, executable files, Microsoft Office documents, and so forth. The

IWSVA Administrator Guide provides a detailed list of the supported file types in the appendix.

IntelliTunnel provides the ability to detect and block popular Instant Messaging applications.

Virus Scan (VSAPI) provides signature based virus and malware scanning.

IntelliScan provides the ability to identify and scan files based on their true file type – preventing users

from trying to bypass the scan engines by changing the file extension or by some other form of file

manipulation.

IntelliTrap provides heuristics scanning to identify and protect against malware that changes or morphs

from one state to another as it navigates through the network.

Compressed File Scanning provides protection against malware that is hidden in highly-compressed

files that are compressed many times over. Malware authors use this common delivery method to try and

evade traditional anti-virus scanning software.

Spyware/Grayware Scanning protects against spyware, dialers, hacking tools, password cracking

applications, adware, joke programs, remote access tools, and other grayware types. This local scan



engine provides protection based on spyware signatures and is used to compliment the Spyware URL

category found in the URL Filtering feature. The local Spyware/Grayware scan engine is used to scan

against files download or uploaded to the Internet that may be infected with spyware or grayware.

Whereas the URL Filtering Spyware category is used to proactively block access to sites known to contain

spyware related files and objects.

Applets and ActiveX Scanning provides protection from malware embedded in Java applets and mobile

code such as ActiveX applications found on many modern web sites.

Large File Scanning provides administrators with a way to bypass scanning for large files that can

consume a lot of system resources. Traditionally, malware authors do not embed viruses in large files

because they want the malware to spread quickly without drawing a lot of attention to the file.

Best Practice Suggestions IWSVA’s local scan services operate in a specific order to reduce the need to scan unnecessarily. IWSVA’s

scanning order for Internet traffic flows in the following order starting with the proactive Smart Protection

Network’s cloud-based services first.

Web Reputation Service (WRS)

URL Filtering Service

IntelliTunnel

File Type Block

Virus Scan

IntelliTrap Heuristics

MacroTrap

IntelliScan True File Type

Applets and ActiveX

The Virus Scan (VSAPI) scan engine consumes the most resources. Enabling web reputation (WRS) and

subscribing to the URL Filtering service and enabling its Computer/Harmful category can greatly reduce

the need to perform traditional VSAPI bases virus scans. This can reduce server resources and provide

additional scalability for your environment.

For trusted white listed sites and files that have a high integrity rating, you can disable malware scanning

to improve performance and reduce server resource use. Use the Global White List, Approved URL and

Approved File white lists in the Exception tabs to bypass scanning for trusted sites and files.

You can configure large file scanning to skip scanning for files over a specific size. This can help reduce

unnecessary scanning for larger files and lower resource use to improve capacity and performance.

To improve user response time for larger file downloads, you can enable the Large File Handling’s

Deferred Scanning feature to “trickle” parts of the scanned file to the requesting host. This will keep the

browser’s file transfer status indicator alive and show progress to the user as the file is being scanned. If

malware is found within the trickled file, IWSVA will block the remainder of the file – resulting in an

incomplete file that cannot be executed. For multi-media files or streaming content that uses HTTP port

80, such as YouTube content, you must enable Deferred Scanning to allow portions of the media to flow

through. Selecting the Scan Before Delivery option will block the streaming content until it’s fully scanned

and cause bad user experiences.

For customers that need to scan the entire file before delivering it to their users, select the Scan Before

Delivery option from the Large File Handling feature. This instructs IWSVA to buffer the file and completely

scan it before delivering any portion to the user. This method is slightly slower in terms of end user

performance perception, but ensures that no portion of the infected file is allowed through.



Keep in mind that entries placed in the Global Trusted URLs white list are not scanned. If you want to scan

white listed items, create an Approved List object and use this in the policy’s Exception tab. The Exception

Tab gives you the option of scanning white listed items in the HTTP and FTP Scan Policies.

Protecting Your IWSVA Configuration IWSVA’s policy and configuration information are stored in two separate files. Configuration information contains the system information, network information, white and black lists, and how the IWSVA is generally configured and setup in your network. Policy information includes the various different policies that are used to enforce access to specific resources – such as the HTTPS Decryption, HTTP Scan, Applets & ActiveX Scan, URL Filtering, IntelliTunnel, and Access Quota policies.

Best Practice Suggestions To protect against policy and configuration information loss, you should perform regular backups of the

IWSVA configuration files. This is done through the Administration > Config Backup/Restore function. A

best practice procedure is to backup the configuration after each time a policy change is made or to

backup the configuration once per day or week.

Leverage Trend’s Advanced Reporting and Management (ARM) module to take advantage of ARM’s

advanced reporting and monitoring capabilities as well as its central management capabilities for multiple

IWSVA units. In addition to the advanced logging, reporting and monitoring features, ARM provides the

ability to synchronize the configuration and policy information between IWSVA units. ARM also provides a

centralized console to manage and backup the configuration files of all registered IWSVA units.

Based on Trend’s licensing scheme, registered customers can install an additional instance of IWSVA in

their labs to parallel their production environments. This allows you to test your policy changes in a

controlled environment before publishing the changes to the production environment. This additional unit

can also serve as a configuration backup to the production unit - allowing its configuration and policy

information to be restored to the production unit if needed.

If Internet access is deemed a critical service, you should consider installing two or more IWSVA units to

provide redundancy and scalability to protect against single points of failure within the Web security

gateway architecture.

IWSVA and Third-Party Applications IWSVA is packaged as a software virtual appliance and can be installed on popular off-the-shelf hardware or within a VMware ESX or ESXi environment. IWSVA provides a hardened and fine tuned operating system that is dedicated to the IWSVA application and does not install on top of a separate operating system – such as Linux, Solaris or Windows. As part of the hardening process, all non-essential operating system utilities and services have been removed or turned off to limit the exposure to possible vulnerabilities – this makes the IWSVA software appliance much more secure.



Best Practice Suggestions IWSVA doesn’t use the default kernels provided by the CentOS distributions. IWSVA has a modified kernel

that provides additional functionality and customers should not attempt to replace the kernel with a

standard distribution kernel downloaded from the Internet. Doing this will break the IWSVA application.

Hardware component drivers are pre-compiled with the IWSVA kernel. Customers should not attempt to

compile 3rd party drivers into the kernel, otherwise, it will disable and break other integrated IWSVA

features that are embedded into the IWSVA operating system kernel.

IWSVA provides a local PostgreSQL database that is tuned to the application. Customers should not

attempt to upgrade the PostgreSQL database as it may disable specific logging and reporting functions.

If 3rd party components are added to the IWSVA server, Trend cannot ensure proper functionality of its

application and operating system. Trend does not recommend any changes or manual updates to the

operating system outside of the IWSVA provided upgrade and update mechanisms.

Trend Micro provides support for the IWSVA operating system and is continuously monitoring the OS

vulnerabilities notices that are released from the CentOS distribution. Trend will provide the necessary

operating system patches through its IWSVA download site. For more information on IWSVA patches and

updates, please visit the IWSVA download site at:




Obtaining Additional TrendEdge Documents Trend Micro publishes many other technical documents to supplement the IWSVA administrator and installation guides. Related documents can be found on the TrendEdge web site at:

http://trendedge.trendmicro.com



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. You can contact us by sending an email to the following address:

[email protected]



About the Author

Philip Kwan Philip is the Director of Product Management for the Web Security product line and has been with Trend Micro since May 2007. Philip has over 20 years of experience in the security and network industries and prior to joining Trend Micro, he worked in many Silicon Valley startups as well as Fortune 1000 companies such as Applied Materials, Foundry Networks, Fortinet, and Incyte Genomics.



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.

Trend Micro’s flexible solutions, available in multiple form factors, are supported 24/7 by threat intelligence experts around the globe. A transnational company, with headquarters in Tokyo, Trend Micro’s trusted security solutions are sold through its business partners worldwide. For more information, please visit www.trendmicro.com.