| Home Prev |  cOS Core 14.00.17 Administration Guide
|
Next |
|---|
The anti-virus scanning feature optionally protects against malicious code carried by any of the following:
Files passing through the firewall between server and client. The transfer could be done using any of the following protocols:
Scripts contained within webpages delivered via HTTP.
URLs contained within webpages delivered via HTTP.
Malicious code in downloads can have different intents ranging from programs that merely cause annoyance to more sinister aims such as sending back passwords, credit card numbers and other sensitive information. The term "Virus" can be used as a generic description for all forms of malicious code carried in files.
Combining with Client Anti-Virus Scanning
Unlike IDP, which is primarily directed at attacks against servers, anti-virus scanning is focused on downloads by clients. cOS Core anti-virus is designed to be a complement to the standard anti-virus scanning normally carried out locally by specialized software installed on client computers. It is not intended as a complete substitute for local scanning but rather as an extra shield to boost client protection. Most importantly, it can act as a backup for when local client anti-virus scanning is not available.The NetEye Anti-Virus Scanning Service
Instead of cOS Core performing anti-virus scanning locally, it is possible to offload scanning to the Clavister NetEye Cloud Service. This service can perform scanning in the cloud for HTTP and HTTPS traffic and provides SSL inspection for HTTPS traffic (SSL inspection is not provided by scanning within cOS Core).For more details on the NetEye service, see the separate NetEye Cloud Getting Started Guide. To begin using NetEye, request a subscription to the product by selecting the option after logging into the relevant MyClavister account.
The NetEye option will not be discussed further in this section.
Methods of Enabling Anti-Virus Scanning in cOS Core
Anti-virus scanning can be enabled in cOS Core using any of the following methods:Using an IP Policy
This is the recommended way to set up scanning. An Anti-Virus Profile object is created and this is associated with an IP Policy that triggers on the target traffic. Note that the Service assigned to the IP policy has to have its Protocol property set to the targeted protocol.
Using and IP Rule
With an IP Rule object, anti-virus scanning is first enabled on the relevant ALG for the targeted traffic. Then, that ALG is associated with a Service object which is in turn associated with an IP rule that triggers on the target traffic.
Configuring anti-virus scanning with either an IP rule or an IP policy is described further in Section 6.4.3, Activating Anti-Virus Scanning.
Streaming
As a data transfer is streamed through the firewall, cOS Core will scan the data for the presence of viruses if anti-virus scanning is enabled. Since data is being streamed and not being read completely into memory, a minimum amount of memory is required and the effect on overall throughput is minimized.Pattern Matching
The inspection process is based on pattern matching against a database of known virus patterns and can determine, with a high degree of certainty, if a virus is in the process of being downloaded to a user behind the firewall. Once a virus is recognized in the contents of a file, the download can be terminated before it completes.Types of Data Scanned
As described above, anti-virus scanning is enabled on a per ALG basis and can scan data downloads associated with the HTTP, FTP, SMTP and POP3 ALGs. More specifically:Any uncompressed file type transferred through these ALGs can be scanned.
If the data file transferred has been compressed, ZIP and GZIP files can be scanned as well as nested compressed files within them (up to 10 levels of nesting).
For the HTTP ALG, webpage scripts and URLs are scanned.
Messages displayed by the HTTP ALG
If enabled through the HTTP ALG, webpage scripts and URLs as well as files can be scanned for malicious code. If a threat is encountered, the connection is dropped and cOS Core will generate a log message for the event. HTTPS traffic cannot be scanned so this does not apply for that protocol.As well as the connection being dropped, cOS Core will try to insert a message into the web browser HTML of the affected user indicating the action taken (in some cases it might not be possible to do this successfully). For malicious files and scripts, the following is an example of an inserted message:
For malicious URLs, the message displayed will be similar to the following:
Simultaneous Scans
There is no fixed limit on how many anti-virus scans can take place simultaneously in a single Clavister firewall. However, the available free memory can place a limit on the number of concurrent scans that can be initiated.Protocol Specific behavior
Since anti-virus scanning is implemented through an Application Level Gateway (ALG), specific protocol specific features are implemented in cOS Core. With FTP, for example, scanning is aware of the dual control and data transfer channels that are opened and can send a request via the control connection to stop a download if a virus in the download is detected. A question that is often posed is the "ordering" of Anti-virus scanning in relation to IDP scanning. In fact, the concept of ordering is not relevant since the two scanning processes can occur simultaneously and operate at different protocol levels.If IDP is enabled, it scans all packets designated by a defined IDP rule and does not take notice of higher level protocols, such as HTTP, that generate the packet streams. However, Anti-virus is aware of the higher level protocol and only looks at the data involved in file transfers. Anti-virus scanning is a function that therefore logically belongs in an ALG, whereas IDP does not belong there.
Subscribing to the Clavister Anti-Virus Service
The Clavister anti-virus feature requires the purchase of a renewable subscription in order for it to function. This includes regular updates of the signature database during the subscription period with signatures for the latest virus threats.Anti-virus subscriptions are discussed further in Appendix A, Subscription Based Features.
The Anti-Virus Signature Database
The cOS Core anti-virus feature is implemented using a scanning engine and virus signature database from BitDefender™, a company that is a world leader in virus detection. The virus signature database is stored locally in the firewall and updated via Clavister servers. The database provides protection against virtually all known virus threats including trojans, worms, backdoor exploits and others. The database is also thoroughly tested to provide near zero false positives.A current listing of all the virus signatures used by the cOS Core scanning engine can be found online at the following link:
https://www.clavister.com/advisories/antivirus
By default 100% of the anti-virus signatures available for the specific model are used, but the administrator can chose to use a lower amount of signatures. See Section 13.10, Miscellaneous Settings for more details.
The anti-virus signature database is updated on a daily basis with new virus signatures. Older signatures are seldom retired but instead are replaced with more generic signatures covering several viruses. The local cOS Core copy of the signature database should therefore be updated regularly and this updating service is enabled as part of a Clavister subscription.Database updating is described further in Appendix A, Subscription Based Features along with a description of anti-virus behavior after subscription expiry.
Auto-update Requires the Correct Time
It is important that cOS Core has the correct system time set so the auto-update feature in the anti-virus module can function correctly. An incorrect time can mean the auto-updating is disabled.The following CLI command will show the current status of the auto-update feature:
Device:/> updatecenter -status
Database Updates in HA Clusters
Updating the anti-virus databases for both the firewalls in an HA Cluster is performed automatically by cOS Core. In a cluster there is always an active unit and an inactive unit.Only the active unit in the cluster will perform regular checking for new database updates. If a new database update becomes available the sequence of events will be as follows:
The active unit determines there is a new update and downloads the required files for the update.
The active unit performs an automatic reconfiguration to update its database.
This reconfiguration causes a failover so the passive unit becomes the active unit.
When the update is completed, the newly active unit also downloads the files for the update and performs a reconfiguration.
This second reconfiguration causes another failover so the passive unit reverts back to being active again.
These steps result in both firewalls in a cluster having updated databases and with the original active/passive roles. For more information about HA clusters refer to Chapter 12, High Availability.
Anti-Virus Setup Using IP Policies
Anti-virus scanning can be enabled using an IP Policy object without using an ALG. This provides a more direct method of activation which can be combined with the other options available in an IP policy such as traffic shaping and file control.When setting up with an IP policy, the anti-virus option can be enabled in one of two ways:
The anti-virus scanning options can be configured directly as properties of the IP policy.
An Anti-Virus Profile object can first be created which defines the properties for anti-virus scanning. A single Anti-Virus Profile object can then be used repeatedly with different IP policies to define the way anti-virus will function.
Anti-Virus Profile Properties
Whether using an Anti-Virus Profile object or configuring anti-virus directly on an IPpolicy, the following scanning properties can be configured:Mode
This can be set to one of the following values:
Certain filetypes may be explicitly excluded from virus-scanning if that is desirable. This can increase overall throughput if an excluded type is commonly encountered in a particular scenario, such as image files in HTTP downloads.
cOS Core performs MIME content checking on all the filetypes listed in Appendix C, Verified MIME filetypes to establish the file's true filetype and then looks for that type in the excluded list. If the type cannot be established from its contents (and this may happen with types not specified in Appendix C, Verified MIME filetypes) then the filetype in the filename is used when the excluded list is checked.
Enable Zone Defense
ZoneDefense can be triggered by scanning.
Block Range
The range to be blocked by ZoneDefense. This is discussed further in Section 6.4.4, Anti-Virus with ZoneDefense.
Max Compression Ratio
The compression ratio at which an action is triggered. The maximum compression ratio setting is a DOS protection mechanism. It protects the system from so called decompression bombs where, for example, a simple text file of a few thousands of bytes can be decompressed into gigabytes of data which can place an excessive load on system resources.
The compression ratio setting allows the administrator to configure a limit on how compressed a file is allowed to be. It should be noted that the configured compression ratio is not comparable with the average compression ratio of a full file since the system performs operations on small data chunks at a time. The compression ratio limit should be seen as an approximate value and triggers when a series of chunks have exceeded this value.
The maximum value allowed by cOS Core for the compression ratio is 500 and the default value is 20.
Action
When the compression ratio value triggers, the action can be one of the following:
In both cases, the event is logged.
Allow Encrypted ZIP files
Allow or block encrypted ZIP files.
Max Archive Depth
Maximum archive depth allowed for scanning. cOS Core can perform virus scanning on compressed files within other compressed files. The level of nesting which is allowed is controlled by this setting. If it is set to zero then any compressed file will always cause a fail condition. If set to a value of one, compressed files will be scanned but any compressed files containing other compressed files will cause a fail condition. A value of two allows a single nesting level of compressed files within compressed files, with both levels being scanned.
The setting has a default value of 5 but can have a maximum value of 10 but increasing the setting should be done with caution. A denial-of-service attack might consist of sending a compressed file with a high level of nesting. If the maximum archive depth specified does not reject the file, large amounts of firewall resources could be consumed to uncompress and scan the hierarchy of files.
If a virus scan fails for any reason then the transfer can be dropped, or allowed with the event being logged. If this option is set to Allow then a condition such as the virus database not being available or the current subscription expiring will not cause files to be dropped. Instead, they will be allowed through and a log message will be generated to indicate a failure has occurred.
The default setting is Allow.
If configuring anti-virus using an IP rule, the above settings have equivalents which can be set on the relevant ALG object.
Example 6.47. Anti-Virus Setup Using an IP Policy
In this example, HTTP connections will be allowed from the internal lan_net network on the lan interface to the Internet via the wan interface. HTTP downloads will be scanned for viruses but only in audit mode so no files will be dropped.
Address translation will use the default automatic setting so that NAT will be automatically selected. An Anti-Virus Profile object will be used to define the virus scanning parameters and this will be associated with the IP policy.
If a configuration was upgraded from a version of cOS Core prior to 11.01, then the http service object could be used if its Protocol property is set to HTTP but the predefined service http-outbound could also be used instead if it is still present. In this example a custom service will be created.
Command-Line Interface
A. Set up an AntiVirusPolicy object:
Device:/> add Policy AntiVirusPolicy av_audit_profile AuditMode=YesB. Create a Service object using the new HTTP ALG:
Device:/> add Service ServiceTCPUDP av_http_service
Type=TCP
DestinationPorts=80
Protocol=HTTPC. define the IP Policy object:
Device:/> add IPPolicy Name=lan_to_wan
SourceInterface=lan
SourceNetwork=lan_net
DestinationInterface=wan
DestinationNetwork=all-nets
Service=av_http_service
Action=Allow
AntiVirus=Yes
AV_Policy=av_audit_profileInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. Set up an Anti-Virus Policy object:
B. Create a Service object using the new HTTP ALG:
C. define the IP Policy object:
Anti-Virus Setup Using IP Rules
The anti-virus feature can also be deployed using an IP Rule object.When used with IP rules, an ALG that allows anti-virus scanning must then be associated with an appropriate service object for the protocol to be scanned. The service object is then associated with a rule in the IP rule set which defines the origin and destination of the traffic to which the ALG is to be applied.
Example 6.48. Anti-Virus Setup Using an IP Rule
This example shows how to set up an anti-virus scanning policy for HTTP traffic from lan_net to all-nets. It is assumed that there is already a NAT rule defined in the IP rule set to NAT this traffic.
Command-Line Interface
First, create an HTTP Application Layer Gateway (ALG) Object with anti-virus scanning enabled:Device:/> set ALG ALG_HTTP anti_virus Antivirus=ProtectDevice:/> add Service ServiceTCPUDP http_anti_virus
Type=TCP
DestinationPorts=80
ALG=anti_virusDevice:/> set IPRule NATHttp Service=http_anti_virusInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. First, create an HTTP ALG Object:
B. Then, create a Service object using the new HTTP ALG:
C. Finally, modify the NAT rule (called NATHttp in this example) to use the new service:
Anti-virus scanning is now activated for all web traffic from lan_net to all-nets.
Anti-virus triggered ZoneDefense is a feature for isolating virus infected hosts and servers on a local network. While the virus scanning firewall takes care of blocking inbound infected files from reaching the local network, ZoneDefense can be used for stopping viruses to spread from an already infected local host to other local hosts. When the cOS Core virus scanning engine has detected a virus, the firewall will upload blocking instructions to the local switches and instruct them to block all traffic from the infected host or server.
Since ZoneDefense blocking state in the switches is a limited resource, the administrator has the possibility to configure which hosts and servers that should be blocked at the switches when a virus has been detected.
For example: A local client downloads an infected file from a remote FTP server over the Internet. cOS Core detects this and stops the file transfer. At this point, cOS Core has blocked the infected file from reaching the internal network. Hence, there would be no use in blocking the remote FTP server at the local switches since cOS Core has already stopped the virus. Blocking the server's IP address would only consume blocking entries in the switches.
For cOS Core to know which hosts and servers to block, the administrator has the ability to specify a network range that should be affected by a ZoneDefense block. All hosts and servers that are within this range will be blocked.
The feature is controlled through the anti-virus configuration in the ALGs. Depending on the protocol used, there exist different scenarios of how the feature can be used.
This topic is discussed further in Section 7.11, ZoneDefense.
