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

Streaming iTunes Radio Stations Through Finjan

Stanislav Michailov — Fri, 12 Sep 2014 02:28:47 GMT

Question

Various iTunes radio stations do not stream when connected through the Finjan proxy.

What are the possible solutions that would allow a stable streaming environment?

Answer

When used on a Windows platform, the iTunes application will inherit IE proxy settings.

The extracts below from the network trace show that radio stations stream content on ports that are different from the standard HTTP port 80:

The Finjan default is to allow HTTP port 80 only. Consequently, additional ports must be allowed so that iTUnes radio stations can stream through Finjan.

According to the KB article provided by Apple - http://support.apple.com/kb/TS1629 - iTunes radio stations are meant to stream traffic on ports, 80, 8000-8999, 42000-42999. Data however, indicates that there may be stations using ports beyond these ranges.

When Finjan is set to allow all HTTP ports iTunes radio stations will stream content smoothly.

Global network security policy may differ between customers, so the decision is whether or not to allow all HTTP ports as shown in the figure below:

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 1920

How to run a tcpdump trace from SWG

Eric Hanson — Fri, 20 Jun 2014 15:52:38 GMT

This article applies to:

SWG 9.x
SWG 10.x
SWG 11.x

Question:

What are the steps for recording a packet capture from SWG?

Procedure:

SWG comes with a number of commands designed to assist administrators with troubleshooting. The tcpdump command can be used to collect a network trace for detailed review.

The article below provides step-by-step instructions on how to run this command and how to copy traces from SWG to a local computer.

This task requires SSH access to SWG - could be All-In-One/Policy Server/Scanning Server.

1. Login to the limited shell interface using an SSH client (PuTTY, a free SSH client for Windows is depicted in the screenshots below).

2. Run the tcpdump command:

3. The limited shell's implementation of tcpdump supports filters to reduce the number of packets to be collected, similar to the filters available on the Linux tcpdump command (e.g., port 8080, host 192.168.1.29, etc.).

To record all traffic without a filter, press Enter to start the process:

4. Press 'Ctrl C' to stop the trace. Please note that the SSH session might time out and close when you stop the trace, depending on the time this command was running.

This however will not affect the output file - it will collect all relevant packets up to the moment when the trace was stopped.

SWG rotates the output file every 100 MB, so if the trace was running for a long period of time multiple files should be expected.

5. Now it is necessary to retrieve the trace file(s) from SWG for further review. This is done using SFTP (a method for transferring files via SSH). The screenshots below depict using FileZilla (a free SFTP client for Windows) for this purpose.

    In addition to specifying the host (the IP or name of the SWG), be sure to indicate the following parameters:
    Port: 22
    Server Type / Protocol: SFTP
    Username: support
    Password: use the same password that is used for the limited shell's admin account

    Once the connection is established, the support home directory will load:

6. Navigate to the /support/tcpdump/ directory to copy the trace file(s) to your local file system:

Notes:

Any other tool supporting SFTP connections could be used for this purpose. SWG has been tested with FileZilla and WinSCP.

Filters (step 3), examples:

not port 22 (to exclude the ssh connection)

host 192.168.16.13 or host 192.168.16.241 and not port 22 (two hosts, no ssh traffic)

host 192.168.16.13 and port 8080 (only http traffic on a specific client)

SWG support for HTTP HEAD requests

ofer Kalef — Tue, 24 Sep 2013 08:33:51 GMT

This article applies to:

SWG 10.x
SWG 11.x

Question:

Will an SWG proxy honor HTTP HEAD requests ?

Information:

An HTTP HEAD request is very similar to an HTTP GET request, the difference being that it asks the Server to return the response headers only, and not the actual resource itself.

This method is useful when the resource needs to be evaluated without actually downloading it, saving bandwidth for example.

SWG supports the HTTP HEAD method without any specific configuration changes, and by default the transactions shown below are allowed:

If needed, a custom rule may be added to the policy to block HTTP HEAD requests, using the HTTP Method condition:

This is how an SWG proxy works when an HTTP HEAD request is blocked by the policy:

Incorrect Policy enforcement for Windows 7 / Windows Vista users due to the NCSI feature

ofer Kalef — Mon, 19 Aug 2013 06:35:52 GMT

This article applies to:

SWG 10.x
SWG 11.x
Users running Microsoft Windows Vista or Microsoft Windows 7

Symptoms:

Symptoms may vary depending on SWG identification implementation.

In some cases, when the user first boots into the Windows OS they get a message from Microsoft Networking with a yellow exclamation icon in the system tray.

The error message that opens is "No Internet Access".

The yellow exclamation icon goes away as soon as the user opens Internet Explorer.

Another variation is that the users are identified as Unknown Users, and as a result the incorrect security policy is enforced for such users.

This can be verified in the Web Logs view showing Authenticated User Names containing '$' signs:

Causes:

This behavior is unique to Window Vista and Windows 7 OS versions after the Network Connectivity Status Indicator (NCSI) feature was introduced in Windows Vista.
NCSI is designed to be responsive to network conditions, so it examines the connectivity of a network in a variety of ways. Once a test fails, NCSI may report an error, even if the network can actually be fully accessed.
For example, NCSI tests connectivity by trying to connect to http://www.msftncsi.com, a simple website that exists only to support the functionality of NCSI.

Try to manually visit the website http://www.msftncsi.com/ncsi.txt. You should see “Microsoft NCSI”:

A proxy server requiring user authentication won't allow it to access the Internet.

Resolution:

There are two ways to resolve this issue:

1. By bypassing *.msftncsi.com/* for Authentication purposes.

2. By modifying registry settings to disable the NCSI functionality:

- Run regedit (administrative permission is required)

- Navigate to the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NlaSvc\Parameters\Internet\

- Locate EnableActiveProbing parameter

- Allowed values: 1 - Enable NCSI, 0 - Disable NCSI

These registry settings can be distributed globally as part of the Group Policy push from the Domain Controller.

Viewing firewall filtering options - Internal

ofer Kalef — Sun, 07 Jul 2013 05:37:15 GMT

Description
When networking problems occur, one may want to review the firewall filters integrated into the Finjan appliances.

Symptoms
Network problems occur such as no response to/from a finjan appliance or while the device is working and communicating with other network resources.

Cause
Finjan appliances are equipped with an integrated fully-capable firewalling mechanism which may be blocking connections due to a malfunction (not so probable as firewall rules seldom change) or due to a manual override.

Solution
To view the firewall filters on a Finjan appliance type:

iptables -L -nvx

NOTE:

The iptables command is also used to change the firewalling rules, DO NOT use the iptables command to perform any other operation other than the one stated above unless approved by PM or R&D.
iptables rules are defined via the GUI->Devices->IP->Acces list tab and limited shell command access_list

Software Version
10.x

11.x

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

This article was previously published as:

Finjan KB 1320

How to bypass Authentication by header

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

This article applies to:

SWG 10.x
SWG 11.x

Question:

Some sites or programs require you to bypass Authentication in order for it to be accessed through the SWG appliance. For example, Google Earth’s update mechanism will not allow the program to run if it cannot contact its host site, and the host site cannot be reached when using Authentication through the SWG.

Procedure:

To bypass authentication in our Google Earth example, we will use the User-Agent header that Google Earth uses to access its host site.

Navigate to Polices > Condition Settings > Header Fields.
Under Exclude by Headers, click Edit and enter the following information:

Header Name:
Condition:
Header Value:

3. Save and Commit changes.

Other programs and hardware are known to need to have authentication bypassed in order to be used. Here are the programs and the Header names used to allow access.

Application	Header	Value	Expression
Google Earth	User-Agent	Regular Expression	^GoogleEarth.*
iPhone	User-Agent	Regular Expression	Apple iPhone.*
iPad	User-Agent	Regular Expression	Apple iPad.*
iTunes	User-Agent	Regular Expression	iTunes/.*
-	-	-	AppleCoreMedia/.*
Microsoft Updates	User-Agent	Equals	Windows-Update-Agent
-	-	Regular Expression	^MicrosoftBITS/.*
Adobe Flash	User-Agent	Regular Expression	^Adobe Flash Update.*

How To Exclude Web Applications From the Authentication Mechanism

Rudolf Kessler — Fri, 31 Aug 2012 07:06:10 GMT

Description
Some web applications (such as Citrix Webmeeting) get stuck due to authentication requests which can not be handled by such applications.
This article describes how to exclude them from authentication mechanism.

Symptoms
Example:
Citrix Webmeeting gets stuck, or the connection setup wizard does not succeed.

Cause
An authentication request is sent to the client in a later session stage, but the application cannot handle it correctly.

Solution
The solution is to exclude this application / site from authentication mechanism.

Drawback: The client is not authenticated or identified anymore and the policy for unknown users is applied.

1. Step: Create a list of URLs you want to exclude (It might be necessary to do a packet trace and analyze the destination URLs)

2. Step: add a condition to your authentication policy (it might be different from this example):

Note: This condition is based on URLs, basically other conditions such as header fields are also possible - it depends on the needs.

Step 3: Commit your changes

Note: This option applies also to other identification policies (IP, Basic)

Software Version
9.x

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

This article was previously published as:

Finjan KB 1810

How do I use the Upstream Proxy Policy?

Rudolf Kessler — Fri, 22 Jun 2012 07:40:32 GMT

This article applies to:

Secure Web Gateway 10.x

Question:

Is it possible to use different upstream proxies based on conditions?
How do I use the upstream proxy policy?

Procedure:

In order to forward requests to different upstream proxies, basically three steps are necessary:

Define conditions
Create an upstream proxy "Object"
Assign this upstream proxy to the scanner(s)

The best practice is to perform the steps in the order that they are listed above. As an example, an administrator might want to use a specific upstream proxy for an individual URL. The administrator would follow the steps below.

1. Create a URL list accordingly:

2. Create a "Upstream Proxy Object":

2.1 Policies > Condition Settings > Upstream Proxy

2.2 In order to add a Upstream Proxy, right click [Upstream Proxy]:

2.3 Define your Upstream Proxy details (IP address, ports, ...):

3. Create the Upstream Proxy policy and assign it to the Scanner(s)

3.1 Under Policies > Upstream Proxy, add a Policy:

3.2 Add a rule to this policy, in order to use the condition(s) defined in step 1:

3.3 Add the condition(s)

3.4 As a last step, assign this Upstream Policy to your scanner(s); the new Upstream Proxy policy can now be found in a dropdown-list in "Scanner Device Policies":

Notes:

Upstream Proxy policies can be defined "per scanner", providing the ability to distinguish between local and cloud scanners!
Security Policies are evaluated regardless of Upstream Proxy Policies; according to your requirements it might be necessary to whitelist client requests accordingly before they are sent to the upstream proxy!
Of course other conditions, such as header fields or IP range can be used.
One Upstream Proxy Policy can point to more than one upstream proxy. This does not automatically include Backup Upstream Proxy functionality.
Important for troubleshooting: When caching is enabled the scanner process connects to the caching server (upstream) and the caching server connects to the "real" configured upstream server. So when looking at traffic captures or logs, this behavior will be seen in the logs/cap files.

WCCP in 9.2 - Technical Brief

Rudolf Kessler — Thu, 24 May 2012 01:09:49 GMT

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

This article was previously published as:

Finjan KB 1909

What is the SWG update server address?

Rudolf Kessler — Mon, 14 May 2012 02:24:49 GMT

This article applies to:

SWG 9.x
SWG 10.x

Question:

I want to restrict Policy Servers' requests, but updates should be allowed. What access do I have to permit through my Firewall?

Reply:

The required access is:

Destination Port 443 / HTTPS
Hosts [1] updateng.finjan.com and [2] mirror.updateng.finjan.com

Notes:

Trustwave strongly recommends that you use DNS. The IP addresses of these servers could change.

How do I change the IP address of a Policy Server / All-in-one?

Rudolf Kessler — Mon, 14 May 2012 01:48:56 GMT

This article applies to:

SWG 9.x
SWG 10.x

Question:

How do I change the IP address of a Policy Server or All-in-one Device?

Procedure:

The most obvious procedure would be to run the command 'config_network' from the limited shell.

However, changing the IP addresses requires more than interface settings to be changed.

Therefore a complete pass of the command 'setup' is required.

Basically, two steps are necessary:

run 'setup'
apply new settings in the GUI

You may also find that firewall settings need to be changed. Firewall settings will differ for each site and are not covered in this article.

Example: old IP 192.168.6.135/24, new IP 192.168.6.131/24

1. Run 'setup'

Note: Although existing settings are not listed in the script´s overview, it is not necessary to re-enter items which will stay the same. Simply press "enter" for these items (such as Role / Time zone / date / interface ...)

When the script comes to "Set IP Address", enter the new address with its netmask:

[...]
(B - go back, Enter - accept default values, Q - exit from setup)
--Set IP Address--
Current IP address: 192.168.6.135/24
Insert new IP address in format IP/[netmask|prefix]
or Enter to accept current settings: 192.168.6.131/24
---Configuration status---
Machine type : Virtual SWG (1 CPU)
Version : 10.1.2.09
------------
Role : All in One
Time Zone : Europe/Berlin
Current date and time : 2012-04-02 14:06
Interface : eth0
IP Address : 192.168.6.131/24
Default gateway : None
Hostname : None
DNS server : None
DNS search : None

(B - go back, Enter - accept default values, Q - exit from setup)
[...]

At the end of the script, save the new configuration.

When you save configuration, the configuration files and the data base will be modified, and services restarted.

2. Apply new settings in the GUI

Log in to the GUI (using the new IP address) as superuser 'admin'. Navigate to M86 Devices under Administration.
Change to Edit mode.
Make sure that the new IP address is selected ('Device IP:'), then save and commit.
After some time (a few minutes) the change will become active:

Notes:

Remember to check firewall settings if necessary.

Skype Blocking - 9.0 Technical Brief

Rudolf Kessler — Tue, 19 Jul 2011 05:52:19 GMT

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

This article was previously published as:

Finjan KB 1740

SWG DNS lookup

Eric Hanson — Fri, 10 Jun 2011 19:34:26 GMT

This article applies to:

SWG 9.x
SWG 10.x

Question:

Does SWG perform DNS lookups for blocked transactions?

Answer:

The Trustwave Secure Web Gateway may perform name resolution for the destination host involved in a blocked transaction, especially when the transaction is blocked during the response phase. In order to block a transaction based content from the target site, SWG must first retrieve the content for scanning purposes. It is normal for SWG to perform a DNS lookup during the course of connecting to a destination site. If a network monitoring tool reports that SWG is performing DNS lookups in relation to transactions that should be blocked, this does not indicate that SWG is allowing malicious content to reach client systems.

How to download files larger than 1 GB through the Finjan

Rudolf Kessler — Tue, 25 Jan 2011 07:41:54 GMT

Description

There is a hard coded limitation of 1 GB filesize.

Symptoms

If a file that is larger than 1 GB is requested by the client through the Finjan, the proxy will return an error:

Error Occurred
HTTP Error Status: 403 Forbidden
Error Reason: Response body too large Please contact your system administrator

Without a reason being given in the web log.

Cause

The largest file-size that is limited to traverse through the Finjan is 1 GB. This limit is hard coded and can not be increased through the GUI.

Solution

In order to circumvent this issue, please follow the steps below:

1. Create a header fields list (please note the correct header name "Content-Length"):

Define a header value of ~ 1 GB (in Bytes, e.g. "1048576000"):

2. Create a rule using the header list as a condition:

NOTE: This will not work if the server does not reply with correct headers, such as in the example below:

Software Version
9.0
9.2

This article applies to:

NG 1000

NG 5000

NG 6000

NG 8000

This article was previously published as:

Finjan KB 1815

ICAP Timeout Error When Browsing Through BlueCoat Proxy

Rudolf Kessler — Fri, 10 Dec 2010 09:07:11 GMT

Description
When browsing through a BlueCoat proxy with a Finjan scanner configured as an ICAP, client timeouts occurs.

Symptoms

The following error is shown when trying to browse to a site:

ICAP Error (icap_error)

An error occurred while performing an ICAP operation: Request timed out: Timed out while waiting for a response from the ICAP server.
There could be a network problem, the ICAP service may be misconfigured, or the ICAP server may have reported an error.

For assistance, contact your network support team.

Cause
This is a result of a misconfigured default connection timeout value in the BlueCoat (That was changed in SGOS ver 5).

Solution

To resolve this please increase the connection timeout for the RESP_MOD service as follows:

Software Version
all SWG versions, but not related to

This article applies to:

SWG 3000

SWG 5000

SWG 7000

This article was previously published as:

Finjan KB 1817

FTP over HTTP: Unauthorized - Error 401

Rudolf Kessler — Sun, 28 Nov 2010 04:34:23 GMT

Description
When trying to access an FTP site, error 401 with error reason: “FTP over HTTP: Unauthorized” is returned.

Symptoms
When browsing to a password protected FTP site through the Vital Security Web Appliance, the browser returns the following error:

When browsing straight to the web-site, a dialog box which requires the user credentials appears:

Cause
The problem is caused because the Secure Web Gateway Appliance is trying to access the FTP server with an anonymous account, which results in a failed login attempt.
This happens generally due to protocol requirements, and not specific to SWG appliance or software!

Solution
In order to resolve this issue, the login credentials must be included in the URL in the following format: ftp://username:password@ftp.adress.com

Software Version
general protocol requirement, not related to any SWG version

This article applies to:: all SWG appliances

This article was previously published as:: Finjan KB 1576

Scanning non-standard ports with SWG

Eric Hanson — Tue, 19 Oct 2010 19:56:52 GMT

This article applies to:

SWG 9.x and 10.x

Question:

Can the Secure Web Gateway (SWG) product be configured to scan HTTP, HTTPS, or FTP transactions over non-standard ports?

Procedure:

SWG scans transactions on the standard ports indicated below, as long as the appropriate modules are activated:

Protocol	Port
HTTP	80
HTTPS	443
FTP	21

In explicit proxy mode, transactions involving other ports are blocked by default. However, it is possible to scan supported protocols on alternate ports or port ranges. This can be accomplished by following the steps below.

Open the settings of the Scanning Server component under the devices tree and highlight the HTTP node.
Navigate to the Allowed Server Ports tab and enable Edit mode.
Click the green plus icon under "Specific Ports for HTTP" to add a row.
Put the desired port numbers in the highlighted fields. The input could be a single port (from 2929 to 2929) or a range (from 2900 to 2929). Alternatively, uncheck a "Specific ports for protocol" box in order to allow connections to all ports over that protocol. Save and Commit the changes.

Notes:

Follow the same logic to allow specific ports for HTTPS or FTP over HTTP transactions that use the SWG appliance’s HTTP proxy service. To allow the HTTPS proxy service to connect to additional ports, configure the Allowed Server Ports under the HTTPS node. To allow the native FTP proxy to connect to additional ports, configure the Allowed Server Ports under the FTP node.
Please note that these settings apply for individual scanning devices. If required, they should be explicitly set on every scanning device in a distributed environment.
It is also possible to configure these settings as system defaults. As such, they will automatically be applied to any new scanning device(s) that are added to the cluster in the future.

SWG service restart due to DNS configuration

Eric Hanson — Tue, 15 Jun 2010 20:23:00 GMT

Question:
Does changing the DNS configuration of a Secure Web Gateway (SWG) appliance restart services?

Answer:
Changing the DNS configuration of an SWG appliance does restart key services. In order to ensure minimal impact to user transactions, it is recommended that all network configuration changes be made off hours, during a scheduled maintenance window.

Software Versions:
all

How can I view real time network statistics (iptraf)?

Peleg Samson — Thu, 21 Jan 2010 11:03:00 GMT

Question
Is it possible to view real time network statistics via the limited shell of the Finjan appliance?

Answer
The iptraf command shows a lot of information about the network traffic through the Finjan appliance.

iptraf is an ncurses-based IP LAN monitor that generates various network statistics including TCP info, UDP counts,
ICMP and OSPF information, Ethernet load info, node stats, IP checksum errors, and others.
The program comes up in interactive mode, with the various facilities accessed through the main menu.

Some of the iptraf options include:

Software Version
8.5.09.09.2

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

This article was previously published as:: Finjan KB 1527

Microsoft Windows Update Fails If User Authentication/Identification Is Used

support finjan — Wed, 29 Jul 2009 00:00:00 GMT

Description
Microsoft Windows Update (although whitelisted) fails if user authentication/identification is used.

Symptoms
In an environment where authentication or identification is defined and a user attempts to use Microsoft/Windows Update site, after selecting the hotfixes to install, the site's control starts running and then reports the installation attempt failed.

Cause
Windows Update site use an ActiveX control to query and manage downloads from Microsoft.

This ActiveX is not a fully functional browser, and so does not handle authentication mechanisms (such as NTLM) correctly.
The reason that the pages are blocked is because whenever the ActiveX is trying to access the web, the authentication fails and the wrong policy is assigned to the user at hand, in such a case the policy that will be used is the one assigned to Unknown Users.
If the policy that is assigned to Unknown Users is to block all access to the internet, the ActiveX component will fail to download updates from the update site.

Solution
Since authentication will not work for the Microsoft/Windows Update site, the following options are availlable::
Grant access to windows update to all machines by assigning a policy with limited access to the Unknown Users group.

Limit access to Windows Update by a combination of Source IP identification and limited access rules .
Both solutions will require setting up a security policy rule to whitelist the Microsoft/Windows update site.

For the following examples, this Security Policy will be referred as “The Restricted SP”.

This can be an existing Security Policy that will be modified or a new Security Policy that will be created specifically for this solution.
TIP: To identify the URLs to whitelist, you can find the currently blocked URLs in the Web Logs screen of the Policy Server admin web GUI.
For more information on how to perform the actions described above, please consult the User Manuals .

Solution 1

Assign The Restricted SP to the Unknown Users.
Solution 2

Limiting access by client IP:

Since we don’t want to lose the identification by username, we will duplicate and change the current Identification Policy and add a rule at the end to identify by client IP.
Create a new user or user group which will be assigned The Restricted SP, enter the IP ranges for this user group, or add individual users with specific IP addresses.
An example is given below, for more information on how to perform these actions, consult the User Manuals.
Go to Users -> Users/User Groups.
Right click on the Users/User Group root and select Add Group.
Name the new group (for example: Windows Update only)
Assign the Restricted SP as the Security Policy.
Assign the Logging Policy and HTTPS Policy according to your organization's requirements.
If an IP range is appropriate, fill the table with the relevant IP address range.
Save the new user group.
Right-Click the new user group and select Add User.
Enter a user name.
Fill the table with the assigned IP addresses for this user.
Save the user.
Repeat steps 8-11 for each user that will use Windows Update.
Commit changes.
Now when you have the Users and Security Policies setup up you will need to create the appropriate Identification Policy.
Perform the following steps from the policy server web admin GUI:
Go to Administration -> System Settings -> Finjan Devices.
Browse to the Devices -> IP -> Scanning Server -> Authentication.
Note the assign Identification Policy.
Now that you know what is the current Identification Policy, go to Policies -> Identification.
Right-click on the relevant identification policy (from step 3) and select Duplicate Policy.
Enter the name for the new policy (for example: Get User Credentials or IP).
Right click on the new policy and select Add Rule.
Enter the name for the new Rule: Identify Users by Source IP.
Check the checkbox Enable Rule.
Select the Action: Identify by source IP.
Save the policy.
Go to Administration -> System Settings -> Finjan Devices.
Browse to the Devices -> IP -> Scanning Server -> Authentication and click Edit.
Change the Identification Policy to the new policy created in steps 5-11.
Save and Commit the changes.
Now you have an identification process that first try to perform an identification/authentication handshake (will work with supported browsers), and if fails will Identify the client using the Source IP (X-Client-IP HTTP Header).
If the user is browsing from an IP address assigned to the user group using the Restricted SP then the user will have access to the Microsoft/Windows Update site.

All other users will be treated as Unknown Users.

Software Version
9.0
9.2

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

Why is SSL traffic blocked in transparent mode when I don't have an SSL license?

support finjan — Mon, 20 Apr 2009 00:00:00 GMT

Question
Why is HTTPS traffic blocked in transparent mode when I don't have an SSL license?

Answer
Starting with version 9.0, when in transperent mode and a service is disabled (even when it's module is not licensed) all traffic on that service port is blocked.

Of course this is not the desireable affect for customers who do not purchase the SSL scanning license.

The solution is to exclude the HTTPS port from being scanned, via the new config_excludes command (avilable since 9.0-M02 and 9.2 onwards).

Run the config_excludes limited shell command, and answer 'y' to change the configuration.
Choose to Add an exclude settings (2).
Leave the Source IP blank, and press Enter.
Leave the Destination IP blank and press Enter.
Enter 433 in the Destination Port.
Chooce to Save the exclude settings (1).

That's it, you're done.

Software Version
9.0-GA
9.0-M02
9.2.0 onwards

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

Delay and/or failure to get Web server by IP address

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

Question
When browsing to some Websites or using HTTP based applications, client may issue requests to reach the server by its IP address.
Under specific conditions, such requests may result in high delays or even failures getting the Web server.

Answer
The below network capture extract shows internal DNS queries sent by the Finjan appliance to find server 198.161.228.200:

The Finjan appliance will try to run a reverse DNS query for this IP in order to understand whether or not there is any URL list entry matching this IP.
This DNS query fails and the transactions time out.

These reverse DNS queries can be disabled by adding this particular IP to the Hosts list on the Finjan appliance.
https://FINJAN-IP:3012 -> Advanced Settings -> Network Settings -> Hosts addresses

Software Version
Applicable for version 8.5.0

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

What kind of cable do I need for the 8040 Serial Console?

support finjan — Fri, 27 Mar 2009 00:00:00 GMT

Question
What kind of cable do I need for the 8040 serial console (loadbalancer switch)?

Answer
The original IBM cable has the part number (P/N) 32R1803.
It has a SubD9 jack (female) on PC side, and a SGI miniDIN jack (male, non-center-pin) on switch side:

SubD9 jack (female)

SGI miniDIN jack (male, non-center-pin)

The wire assignment is as follows:

Software Version
N/A

This article was previously published as:
Finjan KB 1472

Load Balancing Configuration with NG-8040

support finjan — Fri, 27 Mar 2009 00:00:00 GMT

This article applies to:
NG 8000
This article was previously published as:
Finjan KB 1418

How to Change Port Settings on an NG-8000

support finjan — Fri, 27 Mar 2009 00:00:00 GMT

This article applies to:
NG 8000
This article was previously published as:
Finjan KB 1113