LevelBlue Knowledge Base » Knowledgebase » Legacy Products » Secure Web Gateway » Logging

How to setup and gather debug logs

ofer Kalef — Sun, 24 Nov 2013 03:51:08 GMT

This article applies to:

SWG 11.x
SWG 10.x

Question:

How do I setup an SWG into debug mode?

Procedure:

When trouble shooting an issue, there might be a need to gather extended logs from the SWG. By default these “debug” logs are not turned on. Follow the instructions below to turn on Debug logs and then reproduce the issue that you are seeing.

Log into the Management console and go to Administration -> System Settings -> Debug log.
Set the debug log level to 1 (full trace). Save and commit.

Now you will want to reproduce the issue by surfing to the site that is exhibiting the issue while going through the SWG proxy.

Once the issue is reproduced, go back into the GUI and set the debug log level back to 6 (fatal errors only), then you will need to immediately save the support logs by going to the limited shell and type the command save_support_logs. To collect the support logs, please see the following KB article.

Note:

*It’s very important that the logs are saved directly after the issue is reproduced. While in debug mode the logging profile is greatly increased so that they will record all data that goes through the system. Since this is the case, the logs on the system will rotate out very fast, if too much time is given between the issue and when the logs are gathered, the log containing the issue could rotate out and the data that is needed will be lost

Filter Entrapper block transactions in the Web Log

ofer Kalef — Sun, 24 Nov 2013 01:52:52 GMT

This article applies to:

SWG 10.x
SWG 11.x

Question:

Is there a filter option to show Entrapper blocks only?

Procedure:

The Malware Entrapment engine, also known as Entrapper, was first introduced with SWG OS 10.1.

1. Go to Logs and Reports > Audit Logs, right-click the selected view and choose View Settings.

2. In the Filter tab, use the settings below to show only Entrapper blocks out of all the log transactions available in the system:

This filter relies on the actual text of the user response action specified for this rule in your policy.

Below is a snapshot of the default End User Message as defined in the Default Security Policy:

And here is the snapshot of the actual text in the message:

If these settings are modified with custom settings make sure to update the suggested filter to reflect the custom settings.

Malware Entrapment Profile levels as shown in the weblogs

ofer Kalef — Sun, 15 Sep 2013 01:17:30 GMT

This article applies to:

SWG v10.1 and above

Question:

Malware Entrapment Profile level is set to Strict, however, transaction shows Basic, Medium and Strict levels. Why?
Malware Entrapment Profile is blocking too much/little content. Can I adjust it?

Information:

As of SWG 10.1, the User Interface allows adjustment of Malware Entrapment Profile (MEP) security level. To do this, highlight the Malware Entrapment Profile condition in the "Block Malicious Content (Malware Entrapment Engine)" Rule and set its level as desired in the right pane, as shown below:

Web content will be blocked by MEP up to and including the specified threshold, e.g. if set to Medium, content is blocked if it breaks Basic or Medium. The transaction log will show what MEP level was reached, so if MEP is set to Strict the transaction logs will show Basic, Medium and Strict entries.

Note that if the Logging Policy is set to log more than Blocked/Corrective actions (e.g. "Log everything except images"), then the logs will show MEP levels for traffic that was not blocked, indicating that the Entrapper engine was called but allowed the traffic, as shown in green below:

Notes:

None.

How to configure ISA server in order to forward client IPs for HTTPS traffic as well

ofer Kalef — Fri, 23 Aug 2013 04:48:56 GMT

Description
In an ISA-Finjan-Internet topology, with the Vital Security ISA Connector properly working with HTTP requests, no client IP addresses are forwarded to the Finjan appliance for HTTPS traffic.

Symptoms

Cause
The option "Add headers to HTTPS CONNECT request" is not selected.

Solution
In ISA Server Management, select the Finjan ISA plugin. In the section "Configuration / Add-ins", mark the option as checked.

Software Version
Vital Security IP/Username Forwarding Plug-in for ISA Server 2004 to Vital Security IP/Username Forwarding Plug-in for ISA Server 2004 and ISA Server 2006
v 2.1

This article applies to:: NG 1000; NG 5000; NG 6000; NG 8000

This article was previously published as:

Finjan KB 1887

Web Logs show IP addresses for requested URL(s)

ofer Kalef — Sun, 28 Jul 2013 04:08:20 GMT

This article applies to:

SWG transparent implementation - WCCP, Bridge, transparent gateway
SWG 10.x
SWG 11.x

Question:

When looking in the Web Logs, why are almost all HTTPS transactions being logged for IP addresses instead of URL(s)?

Information:

With SWG implemented in Transparent Mode, URL resolution is performed by the client issuing a request, and not by the scanner.
As a result, when such a request comes in, SWG has to rely on the information sent by the client.
For HTTP traffic, SWG extracts URL information from the host header present in the HTTP GET request.
This however, is not available for SSL traffic, and as a result SWG presents IP addresses instead of URL addresses.

There is a way to obtain URL/hostname information for a request using the certificate data associated with it.
Navigate to Administration > System Settings > SWG Devices. Then under Scanning Server, go to General > Transparent Proxy Mode tab. Enable the Extract hostname from certificate option, as shown below.
This setting is present on Scanning Server only.

With this setting enabled, the logs show both IP and URL addresses per a request:

How to collect support logs from the SWG

ofer Kalef — Thu, 11 Jul 2013 04:11:45 GMT

SWG 9.x

SWG 10.x
SWG 11.x

Question
Vital Security for Web provides the administrator with the means to collect debug log information that may be important for troubleshooting process.
This article describes what should be the steps to collect this information.

Answer
Requirements:

Collecting support log information requires SSH access to the SWG appliance (All-In-One/Policy Server/Scanning Server) .
Also, an SFTP client is required in order to transfer the files from the SWG appliance to a local machine.

1. Login to the SWG limited shell interface using SSH client.

2. Execute save_support_logs command:

3. This step may take few minutes and present the following screen when complete:

It is possible that SSH session will time out before this message shows up.
Still, the logs are saved in support/info directory.

4. Now as the logs archive is saved in support/info directory open the SFTP client using SFTP to transfer this file to the local machine.
Username: support

Password: (your admin password to the SWG)

5. Successful login will result in the following files view:

6. Open support/info directory and copy support_info.tar.gz file to the local machine :

7. Provide this file to SWG support upon request.

This article was previously published as:

Finjan KB 1851

How to use Health Check options with SWG Proxy - Best Practice

ofer Kalef — Mon, 17 Jun 2013 01:10:44 GMT

This article applies to:

SWG 10.x
SWG 11.x

Question:

What is the best way to health-check an SWG Proxy?

Information:

The Health Check mechanism is usually required to ensure that a device is up and available to process User/Server sessions/requests.

There are multiple ways to achieve that with an SWG proxy; For example, it could be an external URL, assuming that the Web Server hosting it is itself available.

In this case, the source device expects to get a predefined response code from the SWG proxy, which is usually HTTP 403 Forbidden code or HTTP 200 OK code.

SWG health-check functionality provides URL(s) that could be used for that purpose, making it easier for administration:

http://Vital.Security.Health.Check - responding with HTTP 403 Forbidden code

http://Vital.Security.Loadbalancer.Check - responding with HTTP 200 OK code

Both health-check resources operate equally well for the purpose of actual system monitoring.

However, one important detail should be mentioned about the response code returned by these health checks:

If SWG is set to use a custom Block Page template using enhanced HTML components (form, logo, labels), it may result in a larger Block Page that is
sent back by SWG to the source device.
As a result, the TCP session established for such health check may not be closed properly on the SWG side, as shown in the network snippet below:

SWG proxy 172.18.180.151 sends HTTP 403 Forbidden response (packet #82).

Client, 172.18.180.152, does close it from its side (FIN packet #86); However, SWG proxy does not close the session.

The network snapshot above was taken from an SWG proxy that is sending a custom Block Page with multiple graphical components in it.

(Multiple customers do modify the Blocking Page to make it look more user-friendly or business-oriented.)

The network snapshot below was taken from an SWG proxy set to send a default Block Page, with no graphical enhancements in it:

Same SWG proxy sends HTTP 403 Forbidden response (packet #34) and immediately after that sends FIN packet #35 to close the TCP session from its side.

Same client as in previous example then sends FIN, ACK packet #39 to close the TCP session from its side.

When the SWG proxy returns HTTP 200 OK code it does not send a Block Message (custom or default), which in turn prevents the situation where network
sessions are not properly closed.

We used http://Vital.Security.Health.Check URL in this example, returning HTTP 403 Forbidden code.

Based on these results our recommendation is to prefer the second health check URL: http://Vital.Security.Loadbalancer.Check responding with
HTTP 200 OK code.

Notes:

These test results do not provide solid evidence that the network sessions are not closed properly.

However, it may result in some unexpected situations due to continuous inefficient operation mode.

What are all the possible system log messages?

ofer Kalef — Tue, 05 Feb 2013 03:37:53 GMT

This article applies to:

SWG 10.x , 11.x

Question:

Customer needs the template of all system log messages, When using a third party product to match message content to raise automated alerts. For this they want a file detailing all the possible messages.

Reply:

All the system log messages can be found in the attached file.

Note that on the SWG this file can be found at: /var/logserver/msg_table.xml

Note that some messages have variable place holders. E.g. %DEVICE_IP

SWG web logs shows outbound requests from itself (RuSafe Mode)

Rudolf Kessler — Wed, 25 Jul 2012 00:35:06 GMT

This article applies to:

SWG 10.x in RuSafe Mode

Question:

Why does SWG web logs shows outbound requests from itself? (The Client IP in the web logs is the same as the SWG IP address)

Information:

This is caused by the scanning engine's malware entrapment external resources pre-fetching.

Notes:

To turn off external resources pre-fetching, follow these steps in the SWG web admin:

- Navigate to: Administration -> System Settings -> Scanning -> Scanning Engines
- Select Malware Entrapment on the left pane and click on Edit.
- Untick "Enable external resources pre-fetching"
- Save and Commit

Administrators cannot view Web Logs

Charles Creegan — Thu, 08 Mar 2012 03:56:33 GMT

This article applies to:

SWG version 10.x

Question:

Administrators cannot view Web Logs in the administration GUI?

Information:

This occurs when you need to have administrator-level users that are not members of the Super Administrators group.

Create a new administrator group (e.g. "View Web Logs") and add the administrator-level user that you want to have access to the Web Logs to this group:

Web Logs can only display users that are Identified by the system - it will not work for Unknown Users.

One way to identify users is to assign a name in SWG to each user's IP address:

The next step is to give the "View Web Logs" administrator group permission to view the Web Logs of the users above.

Open the "Permissions - Grid View" tab, expand "Users / User Groups" and select Update from the drop-down to the right of the users you wish to be visible to members of the "View Web Logs" administrator group (Default is None):

Members of the "View Web Logs" administrators group should now be able to see the Web Logs of the users that they have been given permission to view. For example:

Notes:

Only NEW web logs will be seen. These changes do not apply to historic traffic or logs.

Long delay in transactions being logged in the web logs

Rudolf Kessler — Mon, 27 Feb 2012 05:24:26 GMT

This article applies to:

SWG 9.x
SWG 10.x

Symptoms:

Transactions in the Web Logs take a long time to show up after the transaction is completed within a browser. Example: a block page is received in the browser, but it takes about 2 hours for the transaction to become visible in the Web Logs.

Causes:

System clocks can drift out of synchronization and become wrong. A web log entry is based on the time that the transaction was done, based on system time. In many cases, if the times of the scanner server and policy server are wrong, transactions do not make it into the Web Logs as they happen on the client machines.

Resolution:

Adjust the system clock time on the scanning server and policy server to the correct time.

Log into the Limited shell of the appliance and type the command config_time.

Notes:

It is also recommended to setup an NTP server on the appliance. This will prevent the system clock from drifting and becoming unsynchronized.

Are SWG Transaction IDs unique?

Eric Hanson — Tue, 15 Jun 2010 19:52:00 GMT

Question:
Are the Transaction IDs in Secure Web Gateway (SWG) log records unique?

Answer:
SWG assigns a Transaction Identifier to each web log entry. No two distinct transactions will ever be identified with the same ID. However, a situation might arise where the same Transaction ID appears more than once in syslog entries and/or log archives within a fairly short period of time. Closer inspection will reveal that these are duplicate records for a single transaction.

Duplicates can occur when a logging service is restarted, as can happen during the application of configuration changes, system shutdown, or unscheduled outages. This happens because a transaction being written to the logs may be in a state where validating its success is impossible due to the shutting down of the service. SWG appliances include built-in precautions which write out the record again upon startup, thus ensuring that that it will not be lost. SWG was designed with the philosophy that it is preferable to create duplicate log messages for the same transaction rather than risk losing log data which could be useful for audits.

Vital Security Reporter appliances automatically factor out any such duplicate transaction records.

Software Versions:
All SWG versions

First page of Web Logs only shows one scanner's transactions

Eric Hanson — Tue, 22 Dec 2009 00:00:00 GMT

Question
Why does the first page of the Web Logs always show transactions from a specific scanning server?

Answer

If a specific scanning server's transactions always appear on the first page of the policy management console's Web Logs, it might seem like the policy server is favoring a particular scanner. Without applying a log filter, it might even appear that the policy server is only retrieving logs from one specific scanning server. In actuality, the most common reason for this symptom is clock synchronization.

Web Logs in the policy management console are sorted by the time at which the log entry was recorded. Since log entries are initially recorded on the scanning servers, their timestamps are determined by each scanning server's clock. If one scanning server's clock is slightly ahead of the others, the policy server will always believe that this particular scanning server's events are the newest. Therefore, log entries from the scanning server with the fastest clock will always be listed first.

It is recommend that the clocks on all Finjan appliances be synchronized as much as possible. Finjan appliances support Network Time Protocol (NTP), which allows them to synchronize with a time server within the organization or on the public Internet. For information on configuring NTP, please see the Setup and Configuration Guide for your version of VSOS.

Software Version

8.5.0
9.0
9.2

This article applies to:: NG 1000; NG 5000; NG 6000; NG 8000

This article was previously published as:: Finjan KB 1941

How does the "Add to URL List" feature work?

support finjan — Sun, 02 Aug 2009 00:00:00 GMT

Question
In the Web log viewer, there is an option to add the URL from the Web log entry to a choice of URL Lists. This allows it to be 'blocked' or 'allowed' according to the Security Policy configured by the end-user.

How does this option work? Not all the customer defined URL lists are displayed in the URL drop-down list, why is this?

Answer
The "Add to URL list" feature works as follows:
The URL lists displayed in the drop-down menu are the URL lists used by the end user's Security Policy.
The logic behind this feature is that if the administrator wishes to block or allow a certain URL entry from the Web Logs, it must be done in accordance with the end user's Security Policy (not according to other URL lists being used by other security policies not related to this specific end user.)
For example:
The Finjan Medium Security Policy was applied to a specific user and the administrator concludes that this URL should be allowed for this security policy.
In order to do so, the administrator must add the URL entry from the Web log to one of this security policy's URL white lists.
In the Finjan Medium Security Policy there are 7 URL lists in use:
Customer Defined Black List and URL Black List (Medium): Used by rule #5, "Block Access to Blacklisted Sites"
Allowed Large Download Sites, Trusted Sites and URL Bypass List (Medium): Used by rule #8, "Allow Trusted Sites"
Customer Defined White List and URL White List (Medium): Used by rule #25, "Allow Access to White Listed Sites"
After clicking on "Add to URL list" these URL lists are indeed listed:
This is the reason that not all URL lists will be displayed in the drop-down menu, but only according to the context of this Web log / URL entry and the security policy of the end user.

Software Version
Versions 9.0 and 9.2

This article applies to:
NG 1000
NG 5000
NG 6000
NG 8000
This article was previously published as:
Finjan KB 1929

How to log HTML Repaired transactions?

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

Question
One of the most valuable services provided by Finjan Vital Security for Web appliances is the ability to track the processed information in the logs.
By default, VSOS 8.5.0 and above provides the following logging policies:
- Log All Protective Actions;
- Log All Protective Actions and Web Pages;
- Logging everything except Image files;
The extended logging policy, logging everything except Image files, provides detailed information. However, it has very important constraint causing huge I/O load to the system.
The HTML Repair feature causes malicious scripts on an HTML page to be automatically detected and repaired, and the HTML page is sent on to the end-user in a transparent manner.
Note: The HTML Repair feature is enabled by default.

Ability to log HTML repaired transcations is one of the reasons users might consider using this logging policy instead of any other alternative.

This article describes how to create new logging policy that combines the flexibility of the data being logged with the minimal load caused to the system.

Answer
1. Browse to the Policies section of the management console of Finjan VSOS 8.5.0 and expand the logging policies node.
2. Highlight the default, Log All Protective Actions, logging policy and click Duplicate button on the top as shown below:
3. Set Log Defaults and HTML Repaired Transactions for this new logging policy:
4. Highlight new logging policy and click New Rule button:
5. Rule editor windows pops up. Set this rule conditions as shown below and click OK.
(Set send to archive/log/report/syslog options according to your preferrences)
5. Decide what should be the place/priority of this rule and move it down with the up/down icons.
Save the policy before you commit these changes.
6. Commit these changes.
7. Browse to the Users section and set this logging policy for specific user(s) or group(s):
8. Apply and commit the changes.

Software Version
8.5.0

This article applies to:
NG 1000
NG 5000
NG 6000
NG 8000
This article was previously published as:
Finjan KB 1742

Wrong Log Viewer Transaction Time

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

Description
The log transaction time is displayed incorrectly on the log viewer display as compared to the Setup Console system and hardware time.

Symptoms
As described, the transaction time on the log viewer is not consistent with the time displayed on the Setup Console:

Cause
On a multiple scanners appliance, one of the scanners' time settings in the Setup Console is incorrect.

Solution
Log in to the Setup Console of each scanning server (https://Scanner_IP:3012) and check the Advanced Settings -> Time Settings.
Verify that the time settings in this screen are correct.
Software Version
8.3.x
8.4.x

This article applies to:
NG 1000
NG 5000
NG 8000
This article was previously published as:
Finjan KB 1259

Configuring Cisco Security MARS with Vital Security Syslog

Eric Hanson — Mon, 23 Mar 2009 00:00:00 GMT

This article applies to:
NG 1000
NG 5000
NG 6000
NG 8000
This article was previously published as:
Finjan KB 1562

Allow Rule / Action does not whitelist an Archive File

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

Description
An "Allow" rule of archive files (by file extension or true content type for example) does not white list an archive file and the rest of the policy's rules below it will be implemented on this archive file.

Symptoms
The following example illustrates the symptoms:

In a customized policy, define an allow rule for archive files (e.g. Zip files) by file extension or true content type for example.
Locate this rule high up (i.e., with high priority) within the security policy.

Try to browse to an archive file containing executable files inside it - the file will be blocked.

Cause
If an item is a container that is not a cab or jar, the file extension rule will apply to the archive itself, but then the whole policy will be applied to each item inside the archive.

Solution
There is a possible workaround for this issue:
Create an Allow rule:
A. In the "Static Content List" field check on the "Malicious Objects List".
B. Check on the "Everything except for the items selected below":

If you don't want to whitelist embedded archive files within this rule:
Select True Content Type and check Embedded Archives.
Next, check the “except for the items selected below.”
NOTE: This workaround will no longer work from 8.4.3 with M08 hot-fix installed and above hot-fixes.

For 8.4.3-M08 and above, please apply the following solution:
Add / move up the "Allow Trusted Sites" rule to the top of your security policy.
This rule should be defined as follows:
User Response Action = Allow.
URL Lists = Trusted Sites.
Add your desired URL to the Lists -> URL Lists -> Trusted Sites.
Apply & commit changes.
Software Version
8.3.x
8.4.x

This article applies to:
NG 1000
NG 5000
NG 8000
This article was previously published as:
Finjan KB 1164

Logging Policy not logging certain traffic

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

Description
A customized logging policy designed to log certain traffic might still not catch that traffic.

Symptoms
When a customized logging policy is created to log certain traffic, in certain situations, there is no logging of the expected traffic.

Cause
The logging policy is dependant on the Conditions (based on Finjan Content Processors) used in the Security Policy.
Like in the Security Policy, the conditions in the Log Policy rules are based on the same Content Processors.
If a specific Content Processor, e.g., "Direction", was not used during the inspection of the request then a Log Policy rule using that specific Content Processor will not be triggered.

For example: you create a Logging Policy to log all FTP traffic, but in the Logs, not all FTP traffic is displayed (see screenshot below).

This is caused by the fact that the Security Policy did not use the "Protocol" Content Processor to inspect the request/response. Therefore, because this Content Processor was not used, the Log Policy using that same Content Processor was not triggered and this traffic was not logged.

Solution
Make sure you that the conditions you use in your logging policy rules are the same as the conditions used in the security policy rules. .
If you would like to log everything (not advised in production environments), you could use a logging policy that has two rules as follows:

Software Version
8.3.x
8.4.x
8.5.0

This article applies to:
NG 1000
NG 5000
NG 8000
This article was previously published as:
Finjan KB 1480

How To Use X-Ray Rules To Troubleshoot The Security Policy

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

Description
How To Use X-Ray Rules to Troubleshoot The Security Policy

Symptoms
Since making changes to a security policy can affect all of your users, blocking an important page in a production environment could bring the "wrath of the people" starting from the office secretaries to the big bosses themselfs.

By understanding the mechanism introduced by X-Ray Rules, you - the system administrator - can fine-tune the policy and test it without affecting the user experience.

Cause

Solution
X-Ray Rules are policy rules that will not affect the way the policy behaves, but will provide data if the rule is matched.
The data that will be provided can be used in two different ways:

Logging according to logging policy. Although not actually blocking or allowing, the logging policy is matched the same as a regular rule.
Directly to the user’s browser, in the form of two HTTP headers:
X-Response-Info: This header will list a sequence of Rule behavior that matched
X-Response-Desc: This header will list the End-User Message selected for the matching rules.
NOTE: Since X-Ray rules do not skip the rest of the policy when matched, it is typical to get more than one Rule Behavior in the X-Response-Info header.
All the values listed in both headers are matched by order.
So whenever you want to check a new Rule, to see if it will behave the way you intend it to, run in X-Ray mode and start checking the logs to see how users would be affected.
Or alternatively,you can test it yourself with an HTTP/LAN traffic analyzer like (for example, Wireshark, HTTPFox addon for Firefox or Fiddler2).
With an HTTP traffic analyzer you can examine the response headers and understand in real-time how the policy is affecting browsing through the page you are currently browsing to.
A simple example using HTTPFox add-on for Firefox
Given a simple policy with 2 X-Ray rules:
Block Known Viruses
X-Ray: Checked
Action: Block
End-User Message: Virus Detected
Condition: Anti-Virus
Virus Detected: Checked
Block All URL Categorization Categories
X-Ray: Checked
Action: Block
End-User Message: Blocked URL Category
Condition: URL Filtering
Everything but… – nothing checked

Example Screenshot
Install HTTPFox in Firefox, restart Firefox and open it (click the small icon on the status bar):
Clear all browser local data: Cache, Cookies, Offline Website Data and Authenticated Sessions. (In FF3 go to Tools -> Clear Private Data… or hit the Ctrl+Shift+Del key combination)
NOTE: Make sure Firefox is browsing through the Finjan Scanner(s).
In HTTPFox click Start to start recording, and now browse to a URL you would like to check the policy’s behavior.
When you check the first HTTP Request (and any other request after that) you’ll see two HTTP headers, which come from the Finjan Scanner.
For each keyword in X-Response-Info you have a phrase taken from the End-User Messages in X-Response-Desc.
In this example www.google.com returned the following:
X-Response-Info: Blocked
X-Response-Desc: Forbidden URL. URL Category is Search Engines. Transaction ID is …..
That’s how it works. But then the obvious question pops up: How can this help you - the security administrator?
X-Ray rules and Troubleshooting Security Policies
A typical troubleshooting scenario that this technique could help you with is whenever you are not sure if a rule is being matched as it should.
Create a duplicate rule for the rule you want to troubleshoot at the top of the rule list, mark it as X-Ray, and assign it to the Blocked behavior.
NOTE: It must be set to the Blocked behavior since, only Block shows an End-User Message.
Now using an HTTP analyzer browse through the scanner and see if the rule is matched, and what is displayed in the End-User Message.
You can also create a customized End-User Message that contains relevant information for your troubleshooting.
In Conclusion
This article introduced you to the power behind X-Ray "magic". A feature that is not only a “dormant” off-line analysis tool, but a real-world real-time troubleshooting accessory that can give you great insight, even while under pressure.

Software Version
8.4.6
8.5.0
9.0
9.2

This article applies to:
NG 1000
NG 5000
NG 6000
NG 8000
This article was previously published as:
Finjan KB 1812

Some transactions specified by Logging Policy are not logged

Eric Hanson — Mon, 23 Mar 2009 00:00:00 GMT

Description
With certain configurations, expected events might not appear in the Logs view section of the Vital Security Management Console. This article describes likely reasons why this might happen, and it also provides information on how to configure Vital Security to display the desired log events.

Symptoms
When viewing the Logs section of the Vital Security Management Console, expected events might not appear. For example, the "Logging everything except Image files" Logging Policy might be applied, but only Blocked and Coached events appear in the Logs.

Cause
The two most likely reasons why some events might be missing from the logs are:
A Log Filter is applied.
A condition used in the active Logging Policy is not used in active Security Policies.

Solution
Each cause of missing log entries has its own unique solution. Below are instructions on how to diagnose and resolve the two most common causes of missing log entries.

Log Filters
Log Filters allow an adminstrator to quickly find and review specific transactions.
For example, an administrator can show all transactions involving a specific destination website or all transactions that were initiated from a specific client IP.
When a Log Filter is activated, it will be applied to all administrators using the Vital Security Management Console.
Therefore, it is recommended to clear any Log Filters after reviewing the pertinent log transactions. Otherwise, another administrator that logs into the console might not realize that a filter is active.
If there is a need to regularly re-use a specific Log Filter, that filter can be saved as a predefined View.

Log Filters are controlled from the Logs section of the Management Console.
Prior to Software Version 8.4.0, the button for configuring Log Filters would always be labeled "Filter", regardless of whether or not a Log Filter was active.
Starting with Software Version 8.4.0, the button will be labeled "Change Filter" when a filter is applied. This is depicted below:

The Filter button, as seen in Software Version 8.4.0 when no filter is applied, (and as seen in previous releases, regardless of whether or not a filter is applied.)

The Change Filter button, as seen in Software Version 8.4.0 when a filter is applied.

To disable a Log Filter, click the Filter or Change Filter button (depending on your VSOS version).
The Filter dialog box will appear. Click the Clear Filter button (shown below) followed by the OK button.

Logging Policy Condition Not Used in Security Policy
Vital Security records summary details about transactions that match the criteria defined in its active Logging Policy. Just like a Security Policy, a Logging Policy is comprised of rules, and each rule specifies one or more Conditions.
If all of the Conditions in a rule match the current transaction, the event will be recorded according to the rule's Logging Action.

Logging Policy conditions are derived from the results of a transaction's security scan.
When Vital Security is analyzing a transaction, it applies the security policy's rules sequentially.
In order to improve performance and minimize system resource consumption, the appliance stops processing rules once it encounters a rule that matches the current transaction.
This means that Conditions that were not evaluated prior to processing the matching rule will not be available for use in the Logging Policy.

One example of this can be seen when using the "Logging everything except Image files" Logging Policy in conjunction with the "Default Basic Security Policy". Blocked and Coached transactions will be logged, but others will not. This is because the "Logging everything except Image files" Logging Policy utilizes a File Extensions condition in order to log unblocked/uncoached events. However, the "Default Basic Security Policy" does not contain any rules that evaluate file extensions.

In order to ensure that a Logging Policy is fully effective, it is important to verify that the Logging Policy relies only on Conditions that have been evaluated by the Security Policies. If it is necessary to build a Logging Policy based on a Condition that is not evaluated by the Security Policies, the Security Policies can be modified so that they scan for the appropriate Condition. One way to accomplish this is to add a rule that simply evaluates the Condition without actually making Allow, Block, or Coach decisions based on the results of the evaluation.

This is done by creating a rule where the Result section of the User Response Action is empty. Simply specify the Condition that should be evaluated, but do not specify an Action. Such rules are non-terminating (rules below them will still be evaluated, regardless of whether or not the current transaction was matched), so they can be placed anywhere in the policy. These rules can be identified by their Status icon, which is a large green checkmark.

Below is a screenshot the illustrates the difference between the Status icons for an actionless rule and an Allow rule. The Allow rule's icon is a green checkmark inside a green circle. The actionless rule's icon is simply a large green checkmark without a circle. Both rules in the screenshot are associated with a URL List condition.

VSOS
8.3.x
8.4.x
8.5.0

This article applies to:
NG 1000
NG 5000
This article was previously published as:
Finjan KB 1345

Why can't I see new log entries after System Time change?

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

Question
I changed the system time from the Setup Console (Webmin) from a later time to an earlier time, but now I cannot find the newly generated logs in the log viewer in the Management Console.
Why is this happening?

Answer
New logs are, in fact, being generated. However, because the previous log entries are still displayed with the old time, the new log entries are considered by the system as being older, and are therefore displayed on a previous page.

VSOS
8.3.x
8.4.x

This article applies to:
NG 1000
NG 5000
NG 8000
This article was previously published as:
Finjan KB 1389

Cannot assign Security Policy to LDAP Group

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

Description
After importing an LDAP group to the Vital Security Appliance NG and assigning a security policy to it, the users under this group are not being assigned to this security policy.

Symptoms
In the example below, the “Users” group is a primary group in the LDAP server and “Support_Finjan” group is a secondary group. The user Earkush is assigned to both groups.

Cause
Most LDAP problems occur when the administrator tries to assign the security policy to the primary group of users. The default primary group is Domain Users but it can be changed. Microsoft Active Directory doesn’t display primary group information in LDAP queries so it can’t be used for assigning security policy.

This article applies to:
NG 1000
NG 5000
NG 8000
This article was previously published as:
Finjan KB 1165

Permissions for Viewing Logs with Users or Groups other than Super Administrators

support finjan — Mon, 23 Mar 2009 00:00:00 GMT

Question
When I create an administrators group in addition to the Super Administrators Group, what are the requirements in order to view all the logs?

Answer
The minimum permissions in order to view the logs for all users are as follows:
Create the new relevant administrator:

Please note that user transactions can be viewd only by the memers of the administrator group which created the users in the first place. For example: Log transactions made by users that were imported from LDAP by 'admin' which belongs to the 'Super Administrators' group can only be viewd by members of the 'Super Administrators' group.

Give the new administrator Write Permissions to all Users or Groups which are meant to be viewed by the new Administrator:

Modify the Logs Permissions for the Administrator (View-Only permissions needed):

Modify the Reports Permissions as well for viewing. (View-Only permissions needed) |* Users who will be creating custom reports will need Write Permissions:

After applying the permissions discussed above, the new administrator should be able to log in and view logs and reports.

Please note that any log entries made prior to the change above will remain with the same permissions they were inserted to the logs. The change of permissions applies to new log entries only.

Software Version
8.3.x
8.4.x

This article applies to:
NG 1000
NG 5000
NG 8000
This article was previously published as:
Finjan KB 1300