LevelBlue Knowledge Base » Knowledgebase » Legacy Products » Security Reporting Center

What versions of Marshal Security products are currently supported by LevelBlue Technical Support?

Charles Creegan — Sun, 26 Nov 2023 18:02:27 GMT

This article applies to:

MailMarshal (SEG)
MailMarshal ECM/MailMarshal Exchange
MailMarshal SPE
MailMarshal SES
Marshal Reporting Console
WebMarshal
Bitdefender for Marshal
McAfee for Marshal
Sophos for Marshal
Other Products
- MailMarshal Appliance e10000
- MailMarshal Management Pack for MOM
- MailMarshal Management Pack for SCOM
- Marshal EndPoint Security
- Security Reporting Center
- Firewall Suite
- imMarshal for MSN
- Counterspy for Marshal
- Kaspersky for Marshal
- PestPatrol for Marshal

Question:

What versions of Content Security (Marshal) products are currently supported by LevelBlue Technical Support?

Information:

For full details about supported versions of current products, see the articles linked below:

Premises Email Security

Article Q20961 covers the following products:
- MailMarshal (SEG)
- MailMarshal ECM/MailMarshal Exchange
- Secure Email Server (SES)

Web Content Security

Article Q20962 covers WebMarshal.

Service Provider Email Security

Article Q20963 covers MailMarshal SPE.

Anti-Virus and Reporting

Article Q20964 covers the following products:
- Bitdefender for Marshal
- McAfee for Marshal
- Sophos for Marshal
- Marshal Reporting Console

Deprecated and Discontinued Products

e10000 (MailMarshal Node Appliance): End of support: March 31, 2011
EndPoint Security: End of support: May 1, 2013
MailMarshal Management Pack for MOM: End of support: May 1, 2013
MailMarshal Management Pack for SCOM: End of support: May 1, 2013
Security Reporting Center (Windows Version): End of support: December 31, 2009
Security Reporting Center (Solaris Version): Withdrawn
Firewall Suite: Withdrawn
imMarshal for MSN: Withdrawn
Counterspy for Marshal: End of support: January 1, 2014
Kaspersky for Marshal: End of support: November 22, 2023
PestPatrol for Marshal: End of support: January 1, 2014

This article was previously published as:: NETIQKB33882

What is NETSTAT?

Charles Creegan — Wed, 01 Apr 2020 00:00:00 GMT

This article applies to:

MailMarshal (SEG)
WebMarshal

Question:

What is NETSTAT?

Information:

You can use the NETSTAT command to check the operation of local ports to see if they are configured properly and if they are receiving data.

You can access a wealth of helpful information about the NETSTAT utility from the Help utility on your Microsoft Windows workstation or server. This information can be found by clicking START | HELP | INDEX and by entering the keyword netstat.

Port	Protocol	NETSTAT - WinNT	NETSTAT - UNIX
21	FTP	`netstat -an 1 \| findstr 21`	`netstat -an 1 \| grep 21`
25	SMTP	`netstat -an 1 \| findstr 25`	`netstat -an 1 \| grep 25`
53	DNS (Note 1)	`netstat -an 1 \| findstr 53`	`Netstat -an 1 \| grep 53`
80	HTTP	`netstat -an 1 \| findstr 80`	`netstat -an 1 \| grep 80`
99	WebTrends Remote Reporting	`netstat -an 1 \| findstr 99`	`netstat -an 1 \| grep 99`
110	POP3	`netstat -an 1 \| findstr 110`	`netstat -an 1 \| grep 110`
137	WINS (Note 2)	`netstat -an 1 \| findstr 137`	`netstat -an 1 \| grep 137`
514	SYSLOG	`netstat -an 1 \| findstr 514`	`netstat -an 1 \| grep 514`
18184	OPSEC LEA	`netstat -an 1 \| findstr 18184`	`netstat -an 1 \| grep 18184`

Note 1: DNS is the acronym for Domain Name Service, a name resolution scheme that originated with the Berkeley version of Unix. DNS is used throughout the Internet for host-name resolution and is a constantly evolving protocol. Along with host-name resolution, it helps in e-mail routing and other TCP/IP-based application services. The most popular Unix-based implementation of DNS is the Berkeley Internet Name Daemon, or BIND.
- SEG/MailMarshal SMTP uses DNS port 53 TCP and UDP.
Note 2: WINS is the acronym for Windows Internet Naming Service, Microsoft's extension of the NetBIOS name resolution scheme. Computers utilize port 137 for WINS resolution.
- If WINS resolution is enabled, local machine names can be resolved without explicit DNS entries.

Once you type the command, look for a response:

If nothing appears, the port is not being utilized.
- If you are checking the response from a Marshal product, check to see if the appropriate service is running. If it is, you may need to restart the server computer and run NETSTAT again.
If the word "ESTABLISHED" appears, then the port is configured properly and it is receiving data.
If the words "TIME-WAIT" appear, the port is configured properly but it is not receiving data.

This article was previously published as: entries: NETIQKB2609

Where do I send a feature request for a LevelBlue Marshal product?

Charles Creegan — Sun, 01 Mar 2020 00:00:00 GMT

This article applies to:

MailMarshal (SEG)
MailMarshal ECM/MailMarshal Exchange
MailMarshal SPE
WebMarshal

Question:

Where do I send a feature request for a LevelBlue Marshal product?

Procedure:

If you want to request a new feature or you want to suggest an improvement for any product, you can contact Technical Support. You can also enquire through your account manager or reseller.

What is the WELF log file format?

Charles — Wed, 06 Nov 2019 18:24:28 GMT

This article applies to:

WebMarshal 6.X
WebMarshal 7.X
Security Reporting Center 2.X
WebTrends Firewall Suite

Question:

What is the WELF log file format?

Information:

WELF is the WebTrends Enhanced Log file Format.

The WELF Reference defines the WebTrends industry standard log file exchange format. Any firewall or VPN system logging to this format will be compatible with Firewall Suite 2.0 and later, Firewall Reporting Center 1.0 and later, and Security Reporting Center 2.0 and later.

WebMarshal 6.X and WebMarshal 7.X "Traffic Logging" logs can be created in the WELF format.

For full details of the fields logged by WebMarshal, see LevelBlue Knowledgebase article Q21119.

Log File Format

A log file is made up of records. Each record makes up a single line of the file. Records must be in chronological order. The earliest record is the first record in the file; the most recent record is the last record in the file. The WebTrends Enhanced Log Format places no restrictions on log file names or log file rotation policies.

Record Format

A record is terminated by the character sequence carriage return-line feed (0x0D-0x0A). There may be no carriage-returns or line-feeds within a record; this format results in a single record per line.

Each record is made up of fields. The record identifier field (id=) must be the first field in a record. All other fields can appear in any order.

Aside from a few required fields, you can decide which optional fields are included in the record. You may want some fields to appear in only certain records because they are only relevant to certain types of activity (for example, the operation on an HTTP request).

Some optional fields may be left out if the firewall vendor chooses, but doing so typically results in reports that are less complete. Refer to the field descriptions to determine which fields are required for tables.

Sample Record
(In a real log file, the record would reside on one line.)

Note: This sample record should give you a sense of what a record looks like. It does not contain all the fields that are available and described in this document. Additional sample records are fully documented in the HELP Index built into the Firewall Suite product.

id=firewall time="2000-2-4 12:01:01" fw=192.168.0.238 pri=6 rule=3 proto=http src=192.168.0.23 dst 6.1.0.36 rg=www.webtrends.com/index.html op=GET result 0 rcvd=1426

Required Fields	Optional Fields
Record identifier Date/time Firewall IP address or name Priority of the record	Rule Protocol Duration Bytes Transferred Bytes Received Source Source Name Destination Destination Name User Operation URL Accessed Result Code VPN Type Message Referring Site Agent Category Category Action WebMarshal Cache Result WebMarshal Classification

Required Fields (WELF)

Record identifier
The id= field identifies the type of record. For log files conforming to this document, the type will always be firewall. For example,
id=firewall

Date/time
The time= field shows the date and time of the event, in terms of local time. The form of the date/time field is shown below (Note: Since this field contains spaces, it must be enclosed in double quotes):
time="yyyy-mm-dd hh:mm:ss" (where):

yyyy: year (always 4 digits)
mm: number between 1 and 12 (inclusive) to represent the month (1 or 2 digits)
dd: day of the month, 1 based (1 or 2 digits)
hh: hour, based on 24-hour clock (1 or 2 digits)
mm: minute (1 or 2 digits)
ss: second (1 or 2 digits)
For example,
6:00 a.m. on January 1, 2000 would be represented as:
time="2000-1-1 6:0:0"
It could also be represented as:
time="2000-01-01 06:00:00"
6:00 p.m. on the same day would be represented as:
time="2000-01-01 18:00:00"

Firewall IP address or name
The fw= field identifies the firewall that generated the log record. This is most often represented as an IP address or a machine name. Firewall Suite uses this field for licensing. The user's licensing is simplified if the firewall is consistent in logging this field. In other words, a particular firewall should always log its IP address or always log its machine name, but not both. If a firewall is logging its IP address, it should always log the IP address of the internal network interface or always log the IP address of the external network interface, not a mixture of the two.
An example using the IP address of the firewall:
fw=192.168.0.238

An example using the machine name of the firewall:
fw=ACME_FIREWALL

Priority of the record
The pri= field specifies the priority of the event. The following is a list of valid values:

0 - emergency
1 - alert
2 - critical
3 - error
4 - warning
5 - notice
6 - information
7 - debug
Messages are placed in various tables based on the priority. Messages with priorities 0, 1, and 2 are included in the critical errors tables, messages with priorities of 3 and 4 are included in the errors and warnings tables, and messages with priorities of 5, 6, and 7 are included in the informational messages tables. For example:
pri=0 pri=5

Optional Fields (WELF)

The following fields for the WebTrends Enhanced Log File Format are optional:

Rule
The rule= field specifies the rule that triggered the log entry. This field is used to generate tables that help the user understand that the rules they have set up are working properly. Three tables are based on the rule field: internal IP addresses triggering firewall rules, external IP addresses triggering firewall rules, and protocols triggering firewall rules. Most firewalls log this field as an integer identifying a particular rule. However, rules could also be identified by name and logged as such in this field. For example:

rule=4 rule=12

Protocol
The proto= fields specifies the protocol used by the event. A large number of tables and graphs depend on the presence of the protocol field. Although this it is not a required field, without it, reports lack important information. Some firewalls do not log the protocol, but log the service. If this is the case, the service can be logged in this field. For example,
proto=http proto=ftp proto=snmp
Default protocol mapping
Firewall Suite includes a file called wtprotocols.txt that maps protocol fields found in log files to types of traffic that appear in reports (for example, pop3 in the log file is displayed as e-mail in the report).

The following is an extract from the wtprotocols.txt file that ships with WebTrends Firewall Suite:

[web] http https 80/tcp [email] pop3 smtp smap [ftp] ftp ftp-data [telnet] telnet [realaudio] realaudio
Map new protocols
Your log files may contain protocols not included in this file. Map them using the Protocols tab in the Firewall Options dialog in the GUI (a mapping changes file named protocols.txt is created). Or you can create the protocols.txt file and map new protocols. Follow the syntax of the wtprotocols.txt file: use the types of traffic designations enclosed in square brackets and list new protocols for that type of traffic, each on a single line. Note: Unmapped protocols are grouped for reports in a type of traffic designation called "other."

Duration

The duration= field specifies the time that is required to perform the operation, in seconds. For example, for an FTP file transfer, the duration is the amount of time used to perform the transfer. Although Firewall Suite tracks this field, it is not currently shown in any tables or graphs. We recommend that if the this information is available, it should be logged so that it can be used in the future. For example, to indicate that an operation required 3 minutes exactly, the duration field could look like this:

duration=180.00
or like this:

duration=180

Bytes Transferred

The sent= field specifies the number of bytes transferred from the source to the destination. For example,

sent=1426 sent=512

Bytes Received

The rcvd= field specifies the number of bytes transferred from the destination to the source. For example:

rcvd=1426 rcvd=512

Source

The src= field specifies the IP address that generated the event. For example:

src=192.168.0.23 src 6.0.2.1

Source Name

The srcname= fields is a more user-friendly version of the src= field. For example,

srcname=mickm@example.com srcname=www.example.com srcname=JIMS_SYSTEM

Destination

The dst= field specifies the IP address that received the event. For example,

dst=192.168.0.23 dst 6.0.2.1

Destination Name

The dstname= field is a more user-friendly version of the dst= field. For example,

dstname=EXAMPLE_SERVER dstname=www.example.com

User

If users are authenticating through the firewall, then the authenticated user name can be logged in the user= field. For example,

user=JohnB user=MarySmith

Operation

For HTTP and FTP requests, the op= field is the operation such as GET, POST, etc. For example,

op=GET op=POST

URL Accessed

For HTTP and FTP requests, the arg= field is the URL accessed. For example,

arg=/PRODUCTS/GOODIES/GIFS/IWAWARD2.gif arg=/PRODUCTS/GOODIES/download.htm?Product=Standard

Result Code

For HTTP requests, the result= field is the standard result code, such as 200 for success, 304 for returned from cache, etc. For example,

arg 0 arg=304 arg=404

VPN

The vpn= field identifies a particular VPN. This value is used to generate tables showing the most highly used VPNs and tables correlating particular users to particular VPNs. For example,

vpn="NY Branch VPN" vpn=Sales

Type

The firewall vendor can use the type= field to cause records to be placed into the tables relating to VPN events or relating to firewall management events. (Other categories may be defined in the future.)
A record can be put into more than one category by separating values by commas.
The currently defined types are:

· vpn - the record is a VPN event.

· mgmt - the record is a firewall management event. For example,

type=vpn type=mgmt type=vpn,mgmt

Message

The msg= field is the basis for the tables showing detailed Critical Events, Errors and Warnings, VPN events, and Firewall Management events. Firewall Suite generates summary tables showing these types of events. Firewall Suite will also generate detailed tables associating users with these events. To make this happen, the user(s) need to be identified using the Src=, Srcname=, Dst=, Dstname=, or User= fields. For example,

msg="VPN starting" msg="Possible port scan detected" msg="Firewall configuration changed"

Referring Site

For incoming web records, the ref= field contains the referring site. For example,

ref=http://search.yahoo.com/bin/search?p=trends%20internet

Agent

For incoming or outgoing web records, the agent= field contains the agent (usually the browser).

agent="SPRY_Mosaic/v8.32 (Windows 16-bit)" agent="Microsoft Internet Explorer/4.40.308 (Windows 95)" agent="Mozilla/3.0 (WinNT; I)"

Category

The cat= field contains the categories to which the accessed site belongs. It is used only for firewalls or proxies capable of categorizing web sites. For example, www.msnbc.com might be categorized as "General News", "Investment", and "Entertainment". If a site belongs to more than one category, these categories should be given in the same cat= field, with a comma separating each category. Note: If a field contains spaces, it must be enclosed in double quotes.

Use this field should only if dst= (or dstname=) is also present.
For example:

dst=www.msnbc.com cat=News dst=www.msnbc.com cat="General News" dst=www.msnbc.com cat=News,Investment,Entertainment dstname=www.msnbc.com cat=News,Investment,Entertainment

Category Action

The cat_action= field contains the action taken for the category value of the cat= field. For example, access to gambling web sites may be blocked.
This field should only be present if cat= is also present.
Possible values for this field are: block and pass.
For example:

dst=www.gambling.com cat=Gambling cat_action=block dst=www.msnbc.com cat=News cat_action=pass

WebMarshal Cache Result

The wmcache= field contains the result of a WebMarshal cache lookup request.

Cache status is not written for HTTPS or FTP requests. Only HTTP supports caching.

This custom field cannot be reported by Security Reporting Center.
Possible values for this field are: HIT, MISS, REFRESH_HIT or REFRESH_MISS.

wmcache=HIT indicates that the item was served from cache without checking the origin server.

wmcache=MISS indicates that the item was not in cache and had to be retrieved from the origin server.

wmcache=REFRESH_HIT indicates that the cache item required revalidation, and that revalidation was successful.

wmcache=REFRESH_MISS indicates that the cache item required revalidation, and that the origin server sent back new data.

WebMarshal Classification Result

Two fields record the result of WebMarshal classification:

dclass= indicates a WebMarshal Domain Classification
fclass= indicates a WebMarshal File Classification

If WebMarshal records multiple classifications, they are included as a comma separated list within double quotes.

For instance: dclass="Safe Sites,Search Engines"

Sample Records

See the document entitled WebTrends Enhanced Log Format (WELF) For Firewalls & VPNs or the HELP Index built into the Firewall Suite product for examples of records that conform to the WebTrends Enhanced Log File Format. Included among the examples provided are:

Sample Web Records
Sample E-mail Records
Sample Telnet Records
Sample FTP Records
Sample RealAudio Records
Sample Management Records
Sample Error Messages

This article was previously published as:: NETIQKB1301

How to collect support log from SR

Rudolf Kessler — Mon, 23 Apr 2012 08:22:06 GMT

This article applies to:

SR 3.x

Question:

How to collect support log from SR?

Information:

After sign-in to the reporter UI, do following:

Administrator --> System Configuration
Once it opens the reporter configuration window, select "Tools" from "Database" pull down menu.
Then click on "Generate" to create technical support report package.
Once finished, click on the “Download” button from the pop-up window.

linux vulnerabilities

Charles Creegan — Wed, 27 Oct 2010 09:52:20 GMT

This article applies to:

Web Filter (R3000, WF, WFR)
Security Reporter (SR)
Enterprise Reporter (ER)
Threat Analysis Reporter (TAR)

Question:

Please confirm if following vulnerability affects the embedded linux on Trustwave WFR/SR/ER/TAR Appliances.

http://www.us-cert.gov/current/archive/2010/10/25/archive.html#linux_root_access_vulnerabilities

Information:

The Reliable Datagram Sockets (RDS) protocol is not enabled on the named appliances, so they are not vulnerable to this issue.

How to Patch MySQL

Oliver Stanley — Sun, 06 Jul 2008 22:01:00 GMT

This article applies to:

MySQL Community Server 3.23.49 (The version included with SRC)
Security Reporting Center

Question:

How do I ensure MySQL is patched and up to date?

Procedure:

Access the MySQL website to find the required patch for your installation. See: www.mysql.com

NOTE: Review the patches carefully before you use them with your MySQL installation as they are unsupported by Marshal.

Notes:

Before installing any patches it is adviseable to back up your MySQL database.

How do I implement Security Reporting Center so that it uses a secure connection? (SRC 2.0)

Oliver Stanley — Wed, 25 Jun 2008 04:31:00 GMT

This article applies to:

Security Reporting Center 2.0

Question:

How do I implement Security Reporting Center so that it uses a secure connection?
Can Security Reporting Center use an SSL connection?

Procedure:

SSL Overview
Sensitive information is often transmitted between Web clients and Web servers. Protecting this information is typically accomplished by sending the data in an encrypted form and subsequently decrypting the data on the receiving side. The Secure Sockets Layer (SSL) protocol provides several features that enable secure transmission of Web traffic. These features include data encryption, server authentication, and message integrity. To enable secure communication from Web clients to Security Reporting Center using SSL, you must first enable SSL support.

Important!
The steps provided below describe how to enable basic SSL functionality and generate certificates only. Depending on your network configuration and security needs, you may need to consult outside documentation. For advanced configuration concerns, please refer to the SSL resources at the following two sites.

http://www.apache.org/
http://www.modssl.org/

SSL Installation Procedure - Windows

Install Security Reporting Center, using the instructions described in chapter two of the user guide, which can be found on the following Web page.
https://support.levelblue.com/Security-Reporting-Center/documentation.asp
Download the file SRC20_sslupdate.zip from the Article Attachments section below.
Create a directory called sslupdate on your desktop.
Unzip the contents of SRC20_sslupdate.zip into the directory on your desktop.
From this directory, execute SSLUpdate.exe. This enables SSL for Apache and installs a self-signed certificate for testing purposes. You may access the secure interface at https://<hostname>:9443.
* You may opt to install your own certificate at this point, or follow the instructions below.

To create a valid SSL certificate, follow these steps.

Using the openssl command line utility, generate an RSA private key. The openssl utility is included in the Security Reporting Center distribution, and can be found in /common/apache/bin directory of your Security Reporting Center installation.

Type the following at the command line.
cd <Install Directory>/common/apache/bin
Run openssl.exe.
At the openssl> prompt, type the following.
genrsa -des3 -rand ssl.rnd -out server.key 1024
The openssl utility prompts you for a pass-phrase. Save this pass-phrase in a secure location.
Note: If you want a DSA private key, replace genrsa with gendsa. To encrypt your key with DES rather than 3DES, replace -des3 with -des.
Typically, the Apache Web server prompts for your pass phrase when the server is started. If you want to start Security Reporting Center without manual interventions, perform the following steps.
- To copy the server key, type the following at the command line.
  copy server.key server.key.org
- Run openssl.exe
- At the openssl> prompt, type the following.
  rsa -in server.key.org -out server.key
- Copy the private key to your Apache installation by typing the following.
  copy server.key <Install Directory>/common/apache/conf/ssl.key
Create a certificate signing request.
- Run openssl.exe.
- Type the following at the OpenSSL> prompt.
  req -new -config openssl.cnf -key server.key -out server.csr
The openssl utility prompts you for a variety of information. Provide information based on your Security Reporting Center installation. This creates the server.csr file. Send this file to a Certificate Authority for signing.
When you get a response (signed certificate) from the Certificate Authority, copy the response to your Apache installation using the following command.
copy <signed certificate> <Install Directory>/common/apache/conf/ssl.crt/server.crt
Restart the NetIQ - Apache service.

To create a valid SSL certificate, follow these steps.

Using the openssl command-line utility, generate an RSA private key. The openssl command-line utility is included in the Security Reporting Center distribution, and can be found in the following directory.

<Install Directory>/common/apache/bin

At the command line, type the following.
cd <Install Directory>/common/apache/bin ps -ef > ~/.rnd ./openssl genrsa -des3 -rand ssl.rnd -out server.key 1024
The openssl utility prompts you for a pass-phrase. Save this pass-phrase in a secure location.
Note: If you want a DSA private key, replace genrsa with gendsa. To encrypt your key with DES rather than 3DES, replace -des3 with -des.
Typically, the Apache Web server prompts you for your pass phrase when the server is started. If you want to start the DCS without manual interventions, use the following steps.
- Type the following at a command-line.
  cp server.key server.key.org openssl rsa -in server.key.org -out server.key
- To change the mode of the server.key file, type the following.
  chmod 400 server.key
- To copy the private key to your Apache installation, type the following.
  cp server.key <Install Directory>/common/apache/conf/ssl.key
Create a certificate signing request. Using the openssl command-line utility, type the following.
./openssl req -new -config openssl.cnf -key server.key -out server.csr
The openssl utility prompts you for a variety of information. Provide information based on your Security Reporting Center installation. This creates the server.csr file. Send this file to a Certificate Authority for signing.
When you get a response (signed certificate) from the Certificate Authority, copy the response to your Apache installation.
cp <signed cert.> <Install Directory>/common/apache/conf/ssl.crt/server.crt
Restart Apache with SSL enabled by typing this command.
<Install Directory>/common/bin/restartallui.sh
To verify that your SSL-enabled Web server started, type the following.
ps -elf | grep httpd
If Apache has started, you should see several httpd processes running. If not, look at the <Install Directory>/common/apache/logs/error_log file for indications of the problems.

Notes:

With the release of Security Reporting Center 2.1, SSL configuration has changed. For more information about configuring SSL for version 2.1, please see the following knowledge base article:

https://support.levelblue.com/kb/article.aspx?id=10359

This article was previously published as:: NETIQKB18260

What are the release notes for Security Reporting Center 2.0?

Oliver Stanley — Wed, 25 Jun 2008 04:30:00 GMT

This article applies to:

Security Reporting Center 2.0

Question:

What are the release notes for Security Reporting Center 2.0?

Information:

This version of the Security Reporting Center product (Security Reporting Center) provides several new features. This version also improves usability and extends several capabilities. Many of these improvements were made in direct response to suggestions from our customers. We thank you for your time and valuable input. We hope you continue to help us ensure our products meet all your needs.

This document outlines why you should install this version, provides additions to the documentation, and identifies any known issues. We assume you are familiar with previous versions of this product under the name Firewall Reporting Center. For more information about installing Security Reporting Center, see the Security Reporting Center User Guide.

Why Install This Version?

Security Reporting Center provides comprehensive reporting on security and Internet usage in your network. This highly flexible and scalable solution can help you understand security & bandwidth baselines, forecast and plan for firewall and bandwidth requirements, summarize critical and non-critical events on your network, manage employee Internet usage, and assess the activity that passes through your firewall. The following sections outline the key features and functions provided by this version.
Proxy Reporting Module
New in version 2.0, the Proxy Reporting module provides comprehensive, detailed analysis of Web traffic generated by users inside the network. Proxy reports show which pages, sites, and files users in the network accessed most frequently, which users generated the most Web traffic, and what content they viewed. The Proxy Reporting module analyzes log files from a wide variety of firewalls and proxy servers.
Smart URL Categorization
The Proxy Reporting module makes available comprehensive tracking of Web content through smart URL categorization. URL categorization checks the URLs your users visit against third-party SurfControl databases to identify sites with objectionable or time-wasting content. URL categorization also allows custom database creation and custom category mapping for focused reporting on Web usage issues.
Improved Performance Management
Security Reporting Center 2.0 offers a number of new customizations to help maximize performance and facilitate cross-platform installations, including the ability to:
Limit the size of Content database tables
Limit the memory consumed by each report table
Customize FTP and DNS handling
Choose how often to discard out-of-order log records
Decide which computers analyze which log files by creating custom host groups
Support for New Firewalls
With version 2.0, Security Reporting Center adds support for Arkoon Network Security, CimTrak Web Security Edition, Fortinet FortiGate Network Protection Gateways, Lucent VPN Firewall, and CyberWALLPlus.
Usability Enhancements
Sample reports are now created during installation and accessible in a single click. Options have been reorganized for greater clarity. New orientation pages assist new users with reporting tasks. New Help site maps provide an organized list of all Help topics.
MAPI E-mail Support
Report distribution by e-mail now supports MAPI as well as SMTP.
Log Path Macros
New support for custom macros substitutes log paths with operating system-specific variables, enabling cross-platform log path specification.
Local Filters
New local filters enhance security by making custom data filters visible only to authorized users of a specific profile.
Custom Currencies
In addition to 43 preconfigured currencies, Security Reporting Center now supports user-configured currencies in bandwidth cost reporting.

Upgrading from Previous Versions

Please refer to the following knowledge base article for more detailed information.
https://support.levelblue.com/kb/article.aspx?id=10515
Backing up Databases
We recommend backing up your databases before you attempt to upgrade from Firewall Reporting Center version 1.1 to Security Reporting Center version 2.0. Backing up the databases secures your data in case of a system failure during the upgrade. For example, if you lose power during an upgrade, your databases may be corrupted. To secure your data, copy it to a directory outside the installation directory.
Note: The following procedure has not been tested with versions earlier than version 1.1.
Stop all Firewall Reporting Center program services.
Copy the InstallDir/common/mysql/data directory to a location outside the installation directory.
Install Security Reporting Center version 2.0.
Warning: Use the same database user name and password, and the same User Interface login name and password to install version 2.0 that you used to install version 1.1. If you use a new user name and password, the databases will not be accessible.
To restore the databases and upgrade to version 2.0 after a failure during upgrade:
Uninstall Security Reporting Center version 2.0.
Reinstall Firewall Reporting Center version 1.1.
Warning: Use the same user name and password, and the same User Interface login name and password to install version 1.1 that you used to install version 2.0. If you use a new user name and password, the databases will not be accessible.
Stop all Firewall Reporting Center program services.
Delete the InstallDir/common/mysql/data directory.
Copy the saved data folder from the folder where you installed it to the InstallDir/common/mysql directory.
Restart the Firewall Reporting Center program services.
Install Security Reporting Center version 2.0.

Additions to Documentation

Updates for Check Point Firewalls
If you plan to use Security Reporting Center 2.0 with a Check Point firewall, use the instructions in the PDF version of the Firewall Configuration Guide found on the product CD-ROM or on the Marshal website. You should be aware of the following issues found in the print version and the Help files:
When configuring Check Point FW-1 or VPN-1 with OPSEC LEA, use the updated instructions in the PDF version of the Firewall Configuration Guide . These instructions reflect the fact that the NetIQ LEA Service for Security Reporting Center version 2.0 now uses the Check Point NG SDK. The instructions found in the print and Help versions of the Firewall Configuration Guide refer to the Check Point FW-1 SDK, which was used with Firewall Reporting Center 1.1 and Firewall Suite.
In the print version of the Firewall Configuration Guide, the instructions for configuring Check Point NG contain an error. On page 15, Step 27 should read as follows:
Make sure that the lea_server host value is the same as the IP address of the computer where the Check Point Management Server is installed.
Viewing Documentation Files
The installation kit provides some documentation in PDF files. To view these documentation files, you need Adobe Acrobat or Adobe Acrobat Reader installed. You can download Adobe Acrobat Reader from the Adobe Web site (http://www.adobe.com/).

General Notes

Marshal strives to ensure our products provide quality solutions for your firewall security needs. The following issues are currently being researched. If you need further assistance with any issue, please contact Technical Support (support@marshal.com).
Mapped Drives Not Supported for Windows XP
If you have installed Security Reporting Center on Windows XP, and you need to specify a network drive for a log file path or a destination directory, do not use a mapped drive. Use the full UNC path to specify a network drive.
Cisco PIX v6.1/v6.2 DNS Port Logging Issue
Because an issue in Cisco PIX 6.1/6.2 causes it to log the DSN ID instead of the port number when logging the DNS source and destination port, Security Reporting Center sees an invalid value for the protocol and will consume large amounts of memory during log data analysis and export. To fix this problem, either upgrade to Cisco PIX v6.2.2 or use a Security Reporting Center Exclude filter to exclude traffic from your DNS servers.
Check Point NG with OPSEC LEA Requires File Changes
If you plan to collect Check Point NG logs using OPSEC LEA, and you previously used OPSEC LEA with Firewall Suite or Firewall Reporting Center, you must comment out modifications to the fwopsec.conf file. The fwopsec.conf file resides in the winnt\FW1\NG\conf directory. Comment out all the lines in fwopsec.conf.

Configuration Hints

Configuring Distributed Installations
If you plan to install components of Security Reporting Center on multiple computers, then the Database component must be installed before all other components.
You must install the Database Server, the User Interface Server, and the Reporting agents in the same network environment. Each computer where a Security Reporting Center component is installed must be able to connect to the Database server.
For Security Reporting Center to work correctly on multiple computers, you must configure each component with the correct connection information when you install it. Install the Database server before you install any other components. When you install the Database server, you provide the host name, port number, user name, and password information for both the Database server and the User Interface server. Write this information down and provide the same information when you install components on other computers.
Configuring Program Services
If you intend to use network drives to store resources such as log files, or if you have installed Security Reporting Center on multiple computers, you must manually configure Security Reporting Center services to access resources across the network. These services include the NetIQ Scheduler Agent, the NetIQ LEA Service, and the NetIQ Syslog Service.
You need to configure services if you will use a network location for any of the following purposes:
Retrieving log files
Storing the FTP cache
Storing uncompressed files
Storing log files collected using Check Point with OPSEC LEA
Storing log files collected using the NetIQ Syslog Service
Storing static HTML or Word reports
Storing FastTrends databases.
To ensure that product services can access network drives, first configure them to log on under an account with access rights to the drives you want to access. By default, product services are log on using the system account. To access mapped drives, you should typically configure the services to log on under a user account. This involves two steps: selecting an account to use for each service, and giving that account the appropriate rights.
Configuring Services and User Rights
Please refer to the following knowledge base article for further details.
https://support.levelblue.com/kb/article.aspx?id=10289

Notes:

Release notes for version 2.1 of Security Reporting Center can be found in the following knowledge base article:

https://support.levelblue.com/kb/article.aspx?id=10835

This article was previously published as:: NETIQKB13549

What are the release notes for Security Reporting Center 2.1?

Oliver Stanley — Wed, 25 Jun 2008 04:29:00 GMT

This article applies to:

Security Reporting Center 2.1

Question:

What are the release notes for Security Reporting Center 2.1?

Information:

Why Install This Version?

Security Reporting Center provides comprehensive reporting on security and Internet usage in your network. This highly flexible and scalable solution can help you understand security and bandwidth baselines, forecast and plan for firewall and bandwidth requirements, summarize critical and non-critical events on your network, manage employee Internet usage, and assess the activity that passes through your firewall. The following sections outline the key features and functions provided by this version.
Reduction in Memory Usage
Customers with large installations will find in version 2.1, the Proxy Reporting module uses far less memory. This improvement in memory usage should be especially helpful to enterprises experiencing virus attacks and port scans.
Support for New Firewalls
With version 2.1, Security Reporting Center adds support for Clavister Firewall and Neoteris IVE.
Express Interface for Quick Report Access
A new Express interface makes report generation simple for new users. Event status panels now auto-refresh for convenient information updates. Icon legends provide a quick reference for navigating list panels. A unified tri-pane Help system adds a complete online table of contents for the User Guide and Firewall Configuration Guide plus indexing and full-text searching capability.

Upgrading from Previous Versions

To upgrade from previous versions, install the new version over an existing version. You do not need to uninstall your existing version.
If you have profiles that rely on a Check Point LEA connection, the lea.conf file must include an IP address. If the lea.conf file does not contain an IP address, we suggest deleting the LEA connection after upgrading and recreating it manually.
If you used custom images in your reports, upgrading to version 2.1 removes them from your reports. To restore the images, create a custom report style that uses the report images. For more information about report styles, see "Understanding Report Styles" in the User Guide for Security Reporting Center.
Upgrading from Version 2.x
To upgrade from version 2.x to 2.1, install Security Reporting Center over your existing installation.
Upgrading from Version 1.0b
To upgrade from version 1.0b, first upgrade to version 1.1, then to version 2.0c. When you upgrade from version 1.0b to version 1.1, all FastTrends and Content databases are deleted. However, the upgrade preserves all profiles, events, users, teams, and other configuration settings.
You cannot upgrade from a version earlier than version 1.0b. If you are using an earlier version of Firewall Reporting Center, you must uninstall it before installing Security Reporting Center.
Warning!
Use the same database user name and password, and the same User Interface login name and password to install the newer version that you used to install the earlier version. If you use a new user name and password, the databases will not be accessible and a clean installation will need to be performed.
Backing up Databases
We recommend backing up your databases before you attempt to upgrade from Firewall Reporting Center version 1.1 to Security Reporting Center version 2.0. Backing up the databases secures your data in case of a system failure during the upgrade. For example, if you lose power during an upgrade, your databases may be corrupted. To secure your data, copy it to a directory outside the installation directory.
Note: The following procedure has not been tested with versions earlier than version 1.1.
To back up databases before upgrading to version 2.1:
Stop all Firewall or Security Reporting Center program services.
Copy the InstallDir/common/mysql/data directory to a location outside the installation directory.
Install the new version of Security Reporting Center.
Warning!
Use the same database user name and password, and the same User Interface login name and password to install the newer version that you used to install the earlier version. If you use a new user name and password, the databases will not be accessible and a clean installation will need to be performed.
To restore databases and upgrade to version 2.1 after a failure during upgrade:
Uninstall Security Reporting Center 2.1.
Reinstall the earlier version (Firewall Reporting Center 1.1 or Security Reporting Center 2.x).
Warning! Use the same database user name and password, and the same User Interface login name and password to install the newer version that you used to install the earlier version. If you use a new user name and password, the databases will not be accessible and a clean installation will need to be performed.
Stop all Firewall or Security Reporting Center program services.
Delete the InstallDir/common/mysql/data directory.
Copy the saved data folder from the folder where you installed it to the InstallDir/common/mysql directory.
Restart the Firewall or Security Reporting Center program services.
Install Security Reporting Center version 2.1.
Upgrading User-Defined Databases from version 2.0a
If you are upgrading from version 2.0a, and you created a Content Database in the Proxy Reporting module using any location or settings other than the defaults, you need a special script to upgrade your MySQL database.
To upgrade the database, run the following script:
InstallDir/common/sql_scripts/MySQL/Content/PXUpgrade/Update20ato20b.bat
Use the following syntax on the command line:
Upgrade20ato20b.bat username password dbname server
Where:
username is the username for the database
password is the password for the username
dbname is the name of the database
server is the name of the server where the database is saved

Additions to Documentation

Viewing Documentation Files
The installation kit provides some documentation in PDF files. To view these documentation files, you need Adobe Acrobat or Adobe Acrobat Reader installed. You can download Adobe Acrobat Reader from the Adobe Web site (http://www.adobe.com/).

General Notes

Marshal strives to ensure our products provide quality solutions for your firewall security needs. The following issues are currently being researched. If you need further assistance with any issue, please contact Technical Support (support@marshal.com).

Data Strings Truncated After 255 Characters
When data strings are identical up to 255 characters but become unique after 255 characters, Security Reporting Center truncates them before storing them in the Content database. Under these conditions, Proxy reports may contain inaccurate counts if they use data from the following Content database tables: CorePage, Download, FileExtension, GenPage, Page, and SearchKeyword.
Upgrades to LEA Connections
When you upgrade to version 2.1 from 2.0a or earlier, Security Reporting Center runs a script that populates the Check Point LEA Connections panel with your existing connections. If the lea.conf file created for the earlier installation does not contain the IP address of the Check Point Management Server, or if the lea.conf file uses an unfamiliar format, the upgrade substitutes a placeholder connection that does not work. Delete and recreate the connection manually to connect to the Check Point Management Server. This issue primarily affects connections for Check Point 4.x firewalls.
Number of Tasks Reset During Upgrade
When you upgrade to a new version, Security Reporting Center resets the number of concurrent tasks each agent can handle to the default, two tasks. If you used the Agent Settings panel to set the number of concurrent tasks to a value other than two, you must set it again after you upgrade.
Workaround for Gauntlet Date Logging
Because the year is not logged inside a Gauntlet log file, Security Reporting Center parses the year based on the name of the file. By default, Gauntlet uses one of the following date formats to name log files:
messages.mm.dd.yyyy messages.dd.mm.yy
We strongly recommend that you use the default file names for your logs. If you use a file name other than the default, Security Reporting Center determines the year based on the current system date. This can lead to reporting errors.
Two MySQL Services
The current version of MySQL installs two services when you install the Security Reporting Center MySQL database on a Windows computer: the MySQL service and the NetIQ-MySQL service. Only the NetIQ-MySQL service is required to run Security Reporting Center. We recommend using the Services panel to set the Startup Type for the MySQL service to Disabled.
Mapped Drives Not Supported for Windows XP
If you have installed Security Reporting Center on Windows XP, and you need to specify a network drive for a log file path or a destination directory, do not use a mapped drive. Use the full UNC path to specify a network drive.
Cisco PIX 6.1/6.2 DNS Port Logging Issue
Because an issue in Cisco PIX 6.1/6.2 causes it to log the DSN ID instead of the port number when logging the DNS source and destination port, Security Reporting Center sees an invalid value for the protocol and will consume large amounts of memory during log data analysis and export. To fix this problem, either upgrade to Cisco PIX 6.2.2 or use a Security Reporting Center Exclude filter to exclude traffic from your DNS servers.
Check Point NG with OPSEC LEA Requires File Changes
If you plan to collect Check Point NG logs using OPSEC LEA, and you previously used OPSEC LEA with Firewall Suite or Firewall Reporting Center, you must comment out modifications to the fwopsec.conf file. The fwopsec.conf file resides in the winnt\FW1\NG\conf directory. Comment out all lines in fwopsec.conf.

Configuration Hints

Configuring Distributed Installations
If you plan to install components of Security Reporting Center on multiple computers, then the Database component must be installed before all other components.
You must install the Database Server, the User Interface Server, and the Reporting agents in the same network environment. Each computer where a Security Reporting Center component is installed must be able to connect to the Database server.
For Security Reporting Center to work correctly on multiple computers, you must configure each component with the correct connection information when you install it. Install the Database server before you install any other components. When you install the Database server, you provide the host name, port number, user name, and password information for both the Database server and the User Interface server. Write this information down and provide the same information when you install components on other computers.
Configuring Program Services
If you intend to use network drives to store resources such as log files, or if you have installed Security Reporting Center on multiple computers, you must manually configure Security Reporting Center services to access resources across the network. These services include the NetIQ Scheduler Agent, the NetIQ LEA Service, and the NetIQ Syslog Service.
You need to configure services if you will use a network location for any of the following purposes:
Retrieving log files
Storing the FTP cache
Storing uncompressed files
Storing log files collected using Check Point with OPSEC LEA
Storing log files collected using the NetIQ Syslog Service
Storing static HTML or Word reports
Storing FastTrends databases.
To ensure that product services can access network drives, first configure them to log on under an account with access rights to the drives you want to access. By default, product services log on using the system account. To access mapped drives, you should typically configure the services to log on under a user account. This involves two steps: selecting an account to use for each service, and giving that account the appropriate rights.
Configuring Services and User Rights
Please refer to the following knowledge base article for further details.
https://support.levelblue.com/kb/article.aspx?id=10289

Notes:

Information about system requirements can be found in the following knowledge base article:

https://support.levelblue.com/kb/article.aspx?id=10842

This article was previously published as:: NETIQKB38167

How do I upgrade to Security Reporting Center?

Oliver Stanley — Wed, 25 Jun 2008 04:11:00 GMT

This article applies to:

Security Reporting Center 2.0

Question:

How do I upgrade to Security Reporting Center?

Procedure:

The features and functionality of WebTrends Firewall Reporting Center have been incorporated into Security Reporting Center, beginning with release 2.0. If you are currently licensed with WebTrends Firewall Reporting Center and have a current support plan, you are eligible to upgrade to Security Reporting Center.

Important Note:

Upgrades to release 2.0 are only supported if you currently have release 1.1 installed.

Release 1.0 is currently installed
Upgrades to any later release is not supported. Changes have been made to the database schema which prevents clean upgrades, and current upgrade scripts do not account for this version. Release 1.0 must first be uninstalled before a later release can be installed.
Release 1.0b is currently installed
An upgrade to 1.1 is possible, but with a caveat. While all configured profiles, options, events, users, and teams will upgrade successfully, FastTrends and Content databases will be deleted in the upgrade process. This is due to changes in the database schema. The only possible upgrade path from 1.0b is to 1.1.
Release 1.1 is currently installed
An upgrade to release 2.0 is fully supported through database scripting. The only release of any product that can be upgraded to NetIQ Security Reporting Center 2.0 is WebTrends Firewall Reporting Center 1.1.

To see if you are eligible to upgrade, check for an installed subscription.

From within your current installation, click the Help menu, and then click About....
Look for a Subscription expires in... section. If the expiration date has lapsed, you need to renew your support plan. If there is not Subscription expires in... section, then a support plan was not installed.
If a support plan has not been installed, please contact Marshal for purchase information.

Note: If you install an upgrade without an active support plan, the product will install as a trial and will disable in 14 days.

To upgrade to Security Reporting Center, follow these steps.

Back-up your existing installation - Do not skip this step!
When you upgrade your software, the upgrade will offer to save a copy of your existing program directory. If the computer where the product is installed does not have enough disk space for a full back-up, you must make a back-up manually before attempting the upgrade. NetIQ recommends that you store this back-up somewhere on your internal network, so it will be available to you if needed. Be sure to back up the entire program directory!
Check for an installed subscription (instructions provided above).
Download the upgrade product from the following location (Note: A valid customer login is required to access this page):
https://support.levelblue.com/Security-Reporting-Center/Upgrade.asp
Following the installation instructions provided in the following knowledge base article.
- To install on Microsoft Windows:
  https://support.levelblue.com/kb/article.aspx?id=10386

This article was previously published as:: NETIQKB13495

How do I manually uninstall Security Reporting Center?

Oliver Stanley — Wed, 25 Jun 2008 03:27:00 GMT

This article applies to:

Security Reporting Center 2.x

Question:

How do I manually uninstall Security Reporting Center?

Symptoms:

Unable to uninstall Security Reporting Center.

Procedure:

To uninstall from Windows:

Does the program appear in Add/Remove Programs of the Control Panel?
- If yes, then attempt to uninstall using this feature.
- If no, go to step 4.
Go to your system temp directory and delete all files and folders found there.
- Try running Add/Remove Programs again.
From a command line prompt, run the following command, without brackets:
MsiExec.exe /I{InsertProductVersionCodeHere}
[The product version code can be found further below.]
In the application Services, stop any of the following services that are running:
- NetIQ - Apache
- NetIQ - MySQL
- NetIQ - Tomcat
- NetIQ LEA Service
- NetIQ Scheduler Agent
- NetIQ Syslog Service
From a command line prompt, run MsiZap.exe with the following command, without brackets:
MsiZap.exe T {InsertProductVersionCodeHere}
[The product version code and information about MsiZap can be found further below.]
Delete the directory that Security Reporting Center or Firewall Reporting Center is installed to. By default, this is C:\Program Files\NetiQ\Security Reporting Center.
Open the Registry Editor. Delete HKEY_LOCAL_MACHINE\SOFTWARE\WebTrends Corporation\InstalledApps.
In the Registry Editor, delete the following keys:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebTrends LEA Daemon
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebTrends Scheduler Agent
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebTrends Syslog Daemon
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WTApacheService
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WTMySQLService
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WTTomcatService
Open the directory c:\Winnt\Installer. You will probably see multiple *.msi files. Right click one of the files, select Properties, and select the Summary tab. Looking for a .msi file that, in this tab, has "Security Reporting Center" as the value for the Subject. When you find this file, delete it.
Restart the machine.

Notes:

Product Version Codes:

Firewall Reporting Center:

Version 1.0 - {7C5A8DB2-D8BC-472B-B7A2-1347BB9EF935}
Version 1.0b - {06299D71-9A45-4249-9025-FE8E243004E5}
Version 1.1 - {7D5BE4FF-D34D-434C-9241-4ECD46D55AC9}

Security Reporting Center

Version 2.0 - {4C2D3F7F-3ACF-4C8C-8D0C-3C9AB7F7C322}
Version 2.0a - {4353C5AD-F2B3-4C27-B7A0-7F851469992B}
Version 2.0b - {B19C4CA6-40AF-4555-A403-48744D8CD44D}

To obtain MSIZap, see the following Microsoft Knowledge Base article:

http://support.microsoft.com/?scid=kb;en-us;290301: Description of the Windows Installer CleanUp Utility

This article was previously published as:: NETIQKB17366

How do I implement Security Reporting Center so that it uses a secure connection?

Oliver Stanley — Wed, 25 Jun 2008 03:26:00 GMT

This article applies to:

Security Reporting Center 2.1

Question:

How do I implement Security Reporting Center so that it uses a secure connection?
Can Security Reporting Center use an SSL connection?

Procedure:

SSL Overview

Web clients and Web servers often transmit sensitive information. Protecting this information is typically accomplished by sending the data in an encrypted form and subsequently decrypting the data on the receiving side. The Secure Sockets Layer (SSL) protocol provides several features that enable secure transmission of Web traffic. These features include data encryption, server authentication, and message integrity. To enable secure communication from Web clients to Security Reporting Center using SSL, you must first enable SSL support.

Important Note:
The information provided in this document describes how to enable basic SSL functionality and generate certificates. Depending on your network configuration and security needs, you may need to consult outside documentation. For advanced configuration concerns, refer to the SSL resources at:

http://www.apache.org/
http://www.modssl.org/

SSL Installation Instructions

New Installations
Install Security Reporting Center as described in the User Guide. By default, SSL is enabled for Windows installations.
Upgrade Installations
To install Security Reporting Center on top of an existing installation, use the steps described in the Release Notes. When you upgrade to version 2.1 from Security Reporting Center 2.0x, the upgrade process backs up your existing Apache Web server and installs a new instance of Apache.
SSL Enabled Prior to Upgrade
If your original installation had SSL enabled, and you want to continue using SSL, manually copy your existing SSL certificate from your old Apache installation to the new Apache installation. Your original Apache installation now resides in the installation directory\common\Apache version number folder of your Security Reporting Center installation.
To copy your certificate:
1. Copy the SSL .key certificate file from the conf\ssl.key directory of your old Apache installation into the conf\ssl.key directory of your new Apache installation.
2. Open the installation directory\common\apache\conf\httpd.conf file in your new Apache installation, and edit the SSLCertificateKeyFile entry to point to the correct .key file.
  Note: This entry is absent if SSL is disabled.
3. Open the installation directory\common\apache\conf\httpd_with_ssl.conf.template file in your new Apache installation and edit the SSLCertificateKeyFile entry to point to the correct .key file.
SSL Disabled Prior to Upgrade
If SSL was disabled in the original installation and you want to enable it, follow these steps:
1. Obtain an SSL certificate. For more information, see section 4 of the User Guide, "Installing Your own Certificate."
2. Use the SSL options in the Security Reporting Center user interface to enable SSL. For more information, see section 3 of the User Guide, "Enabling and Disabling SSL."

Enabling and Disabling SSL

Security Reporting Center 2.1 provides the ability to enable or disable SSL as a feature of the user interface.

To enable or disable SSL, follow these steps:

Open the Administration module and click Options | SSL.
Click Enable SSL or Disable SSL.
Restart the NetIQ Apache Service and the NetIQ Tomcat Service.

With SSL enabled, the URL for connecting to Security Reporting Center takes the following format:

https://hostname:9000/index.html

With SSL disabled, the URL format is the following:

http://hostname:9000/index.html

When you enable or disable SSL, Security Reporting Center automatically updates any local Windows shortcuts pointing to the old URL.

This article was previously published as:: NETIQKB38143

Error: "java.lang.OutOfMemory"

Oliver Stanley — Wed, 25 Jun 2008 03:23:00 GMT

This article applies to:

Firewall Suite 4.1x
Security Reporting Center 2.X

Symptoms:

Error: "java.lang.OutOfMemory"
Out of memory errors are received when trying to view reports.

Causes:

The Java component does not allocating enough memory for reports with large amounts of data to load successfully.

Information:

For the report to display successfully, allocate more memory to Java. To do this please follow the steps below:

Important Note! Before making any changes, please make a backup of your registry.

Allocating Java memory on Windows:

Open the Registry Editor by running the regedit command.
Navigate to the following entry:
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/NetIQTomcatService/Parameters
Add two new strings:
- JVM Option Number 2
  value: -Xms10M
- JVM Option Number 3
  value: -Xmx500M
Change the "JVM Option Count" parameter from 2 to 4, because we have added two new parameters. Without making this change, the memory will not be affected.
Restart the NetIQ Apache and NetIQ Tomcat services in Service Control Manager.

Warning: Using the Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Trustwave cannot guarantee that problems resulting from the incorrect use of Registry Editor can be resolved. Make sure that you backup your Registry prior to making any changes.

This article was previously published as:: NETIQKB35391

How do I change the database user name and password in Security Reporting Center modules?

Oliver Stanley — Wed, 25 Jun 2008 03:22:00 GMT

This article applies to:

Security Reporting Center 2.0
Security Reporting Center 2.1

Question:

How do I change the database user name and password in Security Reporting Center modules?

Procedure:

When you wish to change the database user name and password in Security Reporting Center, changes to multiple files must be completed so that the User Interface, Scheduler Agent, LEA Service, and Syslog Service can properly log in.

To change the user name and password, please follow these directions for each module. (You must stop and restart each of the services for the changes to take effect. This will also ensure that the new passwords are encrypted.)

NetIQ Scheduler Agent
1. Using any text editor, open the agent.conf file from the \modules\agent directory.
2. Under the [ConfigDB] section, locate the entry for username and an entry for password.
3. Delete the existing encrypted user name and password from each of these entries.
4. Type the new user name and password following the equal sign.
5. Save and close the file.
6. Stop and restart the NetIQ - Scheduler Agent service by clicking Start | Settings | Control Panel | Administrative Tools | Services.
NetIQ LEA Service
1. Using any text editor, open the lea_service.ini file from \modules\leaservice directory.
2. Under the [LEA_Service] section, locate an entry for configDb_UserName and an entry for configDb_UserPassword.
  Note: Do not change the configDb_DSN entry.
3. Delete the existing encrypted user name and password from each of these entries.
4. Type the new user name and password following the equal sign.
5. Save and close the file.
6. Stop and restart the NetIQ - LEA Service service by clicking Start | Settings | Control Panel | Administrative Tools | Services.
NetIQ Syslog Service
1. Using any text editor, open the syslog_service.ini file from the \modules\syslogservice directory.
2. Under the [SYSLOG_Service] section locate an entry for configDb_UserName and an entry for configDb_UserPassword.
  Note: Do not change the configDb_DSN entry.
3. Delete the existing encrypted user name and password from each of these entries.
4. Type the new user name and password following the equal sign.
5. Save and close the file.
6. Stop and restart the NetIQ - Syslog Service service by clicking Start | Settings | Control Panel | Administrative Tools | Services.
User Interface
1. Open the web.xml file from the \common\uiserver\WEB-INF directory.
2. Find the <param-name> entry, WtSchedJdbcUsername.
3. Change the encrypted <param-value> to the new user name.
4. Find the <param-name> entry, WtSchedJdbcPassword.
5. Change the encrypted <param-value> to the new password.
6. Find the <param-name> entry, WtSchedJdbcEncrypted.
7. Change the <param-value> to false.
8. Save and close the file.
9. Stop and restart the NetIQ - Tomcat service by clicking Start | Settings | Control Panel | Administrative Tools | Services.

Notes:

Changing the MySQL database user name and password is not done through Security Reporting Center. Instead, this action should be done via MySQL.

A number of free GUI tools for MySQL administration are available. MySQL can also be administered from the command line.

The tool maintained by MySQL AB is available at the following URL: http://dev.mysql.com/downloads/gui-tools/

Note: SRC uses an older version of MySQL, so you may see a warning about version mismatch.

MySQL-Front, a well-known GUI tool, is no longer available.

This article was previously published as:: NETIQKB14395

How does OPSEC LEA connectivity work in Security Reporting Center?

Oliver Stanley — Wed, 25 Jun 2008 03:20:00 GMT

This article applies to:

Security Reporting Center 2.0

Question:

How does OPSEC LEA connectivity work in Security Reporting Center?

Information:

Checkpoint firewalls maintain two binary log event databases on the firewall or management console, the standard database and the accounting database. These databases record traffic according to the firewall rule set. Marshal provides a method of connecting to this log database and downloading the log files in a format that Security Reporting Center can read.

The database connectivity is provided by a secondary process that uses the Checkpoint-developed OPSEC LEA interface. Security Reporting Center starts a secondary process (lea_service.exe for Windows) upon creation of a profile that is configured to use OPSEC LEA.

Once the LEA process is started, it connects to the firewall on TCP port 18184 and continuously polls the firewall for new log record data. This process is fault tolerant in that it records its last-known position in the database. Because of this, Security Reporting Center is capable of reconnecting to the firewall and resuming transfer of log records in the case of communication failure. If the LEA connection is dropped for any reason, the process will attempt to re-connect every five minutes.

The LEA process writes the contents of the two databases to a location that you specify when the profile is configured.

This article was previously published as:: NETIQKB13427

How do I export Check Point log files?

Oliver Stanley — Wed, 25 Jun 2008 03:19:00 GMT

This article applies to:

Security Reporting Center 2.x
WebTrends Firewall Suite 4.x
Check Point Firewall-1
Check Point NG

Question:

How do I export Check Point log files?

Symptoms:

Unable to analyze Check Point exported log files.

Procedure:

To export Check Point FW-1 log files, follow these steps.

From the machine on which the firewall is installed, access a command prompt.
Change to the directory where the fw.exe file is located.
Enter the following text to export the fw.log log files.
fw logexport -d ; -i fw.log -o[log_path]\fw.log
Enter the following text to export the fw.alog log files.
fw logexport -d ; i fw.alog -o [log_path]\fw.alog

To export Check Point NG log files, follow these steps:

On the computer where the firewall is installed, open a command prompt.
Switch to the \winnt\fw1\NG\bin directory where the fw.exe file is located.
Export the log files using the following command:
fwm logexport -i <input file> -o <output file>
Note: If you do not specify an input file Check Point exports the current log.

Notes:

Check Point NG does not produce an .alog file. This information is now combined into the regular .log file.

This article was previously published as:: NETIQKB5691

Error: 'No such file or directory: getpwuid: couldn't determine user name from uid , you probably need to modify the User directive.'

Oliver Stanley — Wed, 25 Jun 2008 03:09:00 GMT

This article applies to:

Security Reporting Center 2.1

Symptoms:

Error: 'No such file or directory: getpwuid: couldn't determine user name from uid <Value>, you probably need to modify the User directive.'
Cannot start the Apache process.

Information:

To resolve this issue, complete the following steps:

Navigate to the following directory:
<SRCInstallDir>/common/apache/conf
Open the httpd.conf file.
Find the following line:
LoadModule userdir_module modules/mod_userdir.so
Comment out this line by adding a pound (#) sign in front of the line so that it reads:
#LoadModule userdir_module modules/mod_userdir.so
Repeat steps 3 and 4, and modify the following files:
<SRCInstallDir>/common/apache/conf/httpd_with_ssl.conf.template <SRCInstallDir>/common/apache/conf/httpd_without_ssl.conf.template
Restart the Tomcat and Apache processes by running the following commands from the <SRCInstallDir>/common/bin directory:
./stopallui.src ./startallui.src
Launch Security Reporting Center.

If this does not resolve the issue, configure User and Group directives. To do this, please follow the steps below:

Open the httpd.conf file.
At the bottom of the file, add the following lines:
User nobody Group nobody
Save the file.
Repeat step 2, modifying the following files:
<SRCInstallDir>/common/apache/conf/httpd_with_ssl.conf.template <SRCInstallDir>/common/apache/conf/httpd_without_ssl.conf.template
Restart the Tomcat and Apache processes by running the following commands from the <SRCInstallDir>/common/bin directory:
./stopallui.src ./startallui.src
Launch Security Reporting Center.

This article was previously published as:: NETIQKB39030

What are the new features in Security Reporting Center 2.0a?

Oliver Stanley — Wed, 25 Jun 2008 03:01:00 GMT

This article applies to:

Security Reporting Center 2.0a

Question:

What are the new features in Security Reporting Center 2.0a?

Information:

For a complete list of Security Reporting Center features, please see the following knowledge base article, which includes release notes for version 2.0:

Q10834: What are the release notes for Security Reporting Center 2.0?

New features:

Enhanced Performance: Version 2.0a provides several speed and performance improvements for users who analyze large amounts of data. Security Reporting Center now prevents lockups during large-scale analysis by dynamically limiting table size when memory usage reaches 90%.
Support for Cisco PIX 6.2 and Borderware 6.5a log files have been added.

Notes:

To learn more about how to analyze a log file from a Cisco PIX 6.2/6.3 firewall, please refer to the following knowledge base article:

Q10450: How do I run reports for a Cisco Pix 6.2/6.3 log file?

This article was previously published as:: NETIQKB25861

What are the system requirements for Security Reporting Center 2.0?

Oliver Stanley — Wed, 25 Jun 2008 02:52:00 GMT

This article applies to:

Security Reporting Center 2.0

Question:

What are the system requirements for Security Reporting Center 2.0?

Information:

Microsoft Windows Requirements

The following table shows the requirements for Microsoft Windows computers.

Component	Minimum Requirements
Processor	Dual Pentium III 733 MHz or higher
Disk Space	1GB free disk space. SCSI recommended.
RAM	1GB
Operating System	Microsoft Windows NT 4.0 with Service Pack 4.0 or higher
Database Application	MySQL
Browser	Microsoft Internet Explorer 4.x or higher, or Netscape 4.5 or higher Reports rely on Java, which is installed with most browsers. However, Java support is not included by default when installing Netscape 6.0 or Netscape 6.1. If you use either of these browsers, make sure you also install Java.

Notes:

Multiple CPUs are recommended for large numbers of profiles and/or users. More disk space and memory is needed to analyze large log files. Also, it is best to install Security Reporting Center on a separate, dedicated system which has access to all of the log files.

This article was previously published as:: NETIQKB13364

What are the system requirements for Security Reporting Center 2.1?

Oliver Stanley — Wed, 25 Jun 2008 02:51:00 GMT

This article applies to:

Security Reporting Center 2.1

Question:

What are the system requirements for Security Reporting Center 2.1?

Information:

Microsoft Windows Requirements

The following table shows the requirements for Microsoft Windows computers.

Component	Minimum Requirements
Processor	Pentium III 733 MHz or higher Recommended: Dual Pentium IV for typical installations.
Disk Space	1GB free disk space. SCSI recommended.
RAM	1GB
Operating System	Microsoft Windows 2000, Microsoft Windows XP, Microsoft Windows 2003
Database Application	MySQL (installed by default with the application)
Browser	Microsoft Internet Explorer 5.x or higher, or Netscape 6.x or higher. Netscape 6.0 is not supported. Reports rely on Java, which is installed with most browsers. However, Java support is not included by default when installing Netscape 6.1 or in some late versions of Internet Explorer. If you use either of these browsers, make sure you also install Java.

Notes:

Release notes information can be found in the following knowledge base article:

Q10835: What are the release notes for Security Reporting Center 2.1?

This article was previously published as:: NETIQKB38166

What components are installed with Security Reporting Center?

Oliver Stanley — Wed, 25 Jun 2008 02:40:00 GMT

This article applies to:

Security Reporting Center 2.0
Security Reporting Center 2.1

Question:

What components are installed with Security Reporting Center?

Information:

During a complete installation process, six major components are installed on the computer.

Apache
MySQL
Jakarta Tomcat
NetIQ Scheduler Agent
NetIQ LEA Service (Daemon)
NetIQ Syslog Service (Daemon)

The Apache component is a web server used by Security Reporting Center to serve reports and to serve the application interface. Because Apache is a well-known web server, this provides for easy customization of the web hosting capabilities of Security Reporting Center.

As an example, if your installation requires a secure connection, you can simply install Apache's SSL plug-in. As the plug-in has no affect on the pages that are actually served, once it is installed and configured properly for the web server, the reports and main interface can then be accessed via this secure connection.

The Security Reporting Center Apache component appears in the Services Control Panel of Windows as 'NetIQ - Apache'.

MySQL is used to store the report content, scheduled events and tasks, and application option settings. The Security Reporting Center MySQL component shows up in the Services Control Panel of Windows as 'NetIQ - MySQL'.

Jakarta Tomcat is a servlet engine that allows Security Reporting Center to contain the advanced web page functionality it uses for the interface and report generation. The Jakarta Tomcat component appears in the Services Control Panel of Windows as as 'NetIQ - Tomcat'.

The NetIQ Scheduler Agent is the process that decides when it is time to run a scheduled event, breaks the scheduled events down into tasks, and executes those tasks through the NetIQ Security Reporting agent.

The NetIQ Security Reporting agent is the analysis engine that performs the parsing and exporting to the Content Database, among other things. This component of Security Reporting Center appears in the Services Control Panel of Windows as NetIQ Scheduler Agent.

Regardless of which components of Security Reporting Center are installed, the Scheduler Agent is also installed.

To learn more about the NetIQ LEA Service, please refer to the following knowledge base article.

https://support.levelblue.com/kb/article.aspx?id=10550

To learn more about the NetIQ Syslog Service, please refer to the following knowledge base article.

https://support.levelblue.com/kb/article.aspx?id=10555

This article was previously published as:: NETIQKB13583

Is the Check Point Safe@Office device supported?

Oliver Stanley — Mon, 29 Oct 2007 20:40:00 GMT

This article applies to:

Firewall Suite 4.x
Security Reporting Center 2.x

Question:

Is the Check Point Safe@Office device supported?

Reply:

Unfortunately this device has not been quality tested so Marshal cannot support it at this time.

For a list of our supported devices please see the following Trustwave Knowledgebase article:

Q10939: Which firewalls are supported?

This article was previously published as:: NETIQKB40278

NGX does not work with the Lea connection and will not produce reports

Charles Creegan — Sun, 14 Oct 2007 23:29:00 GMT

This article applies to:

Security Reporting Center 2.1

Symptoms:

NGX does not work with the Lea connection and will not produce reports

Causes:

Checkpoint changed the logging format of NGX. An upgrade to Checkpoint NGX can cause the lea connection to fail.

This failure is most likely due to a change in the CheckPoint NGX configuration file.

Reply:

To correct this issue, reconfigure the fwopsec.conf file according to the instructions in the Firewall Configuration guide. For the latest version of this Guide, see the SRC Documentation page.

This article was previously published as:: NETIQKB49956

How do I troubleshoot OPSEC LEA issues with Security Reporting Center?

Oliver Stanley — Tue, 10 Jul 2007 00:09:00 GMT

This article applies to:

Security Reporting Center 2.0
Security Reporting Center 2.1

Question:

How do I troubleshoot OPSEC LEA issues with Security Reporting Center?

Symptoms:

Unable to establish OPSEC LEA connection.

Procedure:

To determine issues with the OPSEC LEA connection, follow these steps:

Open the lea_service.ini file located in the directory <installdir>\modules\leaservice.
Locate DebugOutputOn=0 and change the zero to a one, so that it reads DebugOutputOn=1.
Save and close the lea_service.ini file.
Click Start > Settings > Control Panel > Administrative Tools > Services to stop the NetIQ LEA Service.
Download the freeware application DebugView from http://www.sysinternals.com/ntw2k/freeware/debugview.shtml.
Delete all profiles that are currently using the OPSEC LEA service.
Start DebugView and allow it to run in the background.
Within DebugView, select Options > Clock Time.
Create a profile in Security Reporting Center using the OPSEC LEA service.
Start the NetIQ LEA Service.

If the data does not come across the OPSEC LEA connection, view the DebugView results to determine the cause. Depending on the results shown in DebugView, you can determine which steps are needed to troubleshoot the issue. Here is a list of the most common issues.

Debug Message	Pause Before Result	Solution
COMM_IS_DEAD	Immediate	Configure Security Reporting Center (SRC) to point to Check Point Management Server.
COMM_IS_DEAD	10-15 seconds	Verify IP is correct; verify CP Management Server is configured correctly
COMM_IS_DEAD	Immediate	Follow the instructions in the Security Reporting Center Configuration Guide to configure fwopsec.conf
COMM_IS_DEAD	2-3 minutes	Add/edit ruleset to allow OPSEC LEA traffic to and from Management Server and Security Reporting Center computer
COMM_IS_DEAD	Immediate	Add/edit ruleset to allow OPSEC LEA traffic to and from Management Server and Security Reporting Center computer
END_BY_APPLICATION	5 minutes	Varies - a connection was initiated, but timed out because there was no response from Management Server. Usually indicates no traffic is being directed through the firewall.

Notes:

Usually these messages are the result of firewall misconfiguration. Please ensure you follow exactly all steps in the Security Reporting Center Configuration Guide.

https://support.levelblue.com/Security-Reporting-Center/documentation.asp

This article was previously published as:: NETIQKB18254