check point™ lea (log export api) specificationread.pudn.com/downloads142/doc/614417/lea.pdf ·...

OPSEC

Check Point™ LEA (Log Export API) Specification

OPSEC SDK 6.0

May 2006

© 2003-2006 Check Point Software Technologies Ltd.

All rights reserved. This product and related documentation are protected by copyright and distributed under licensing restricting their use, copying, distribution, and decompilation. No part of this product or related documentation may be reproduced in any form or by any means without prior written authorization of Check Point. While every precaution has been taken in the preparation of this book, Check Point assumes no responsibility for errors or omissions. This publication and features described herein are subject to change without notice.

RESTRICTED RIGHTS LEGEND:

Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19.

TRADEMARKS:

©2003-2006 Check Point Software Technologies Ltd. All rights reserved.

Check Point, Application Intelligence, Check Point Express, the Check Point logo, AlertAdvisor, ClusterXL, Cooperative Enforcement, ConnectControl, Connectra, CoSa, Cooperative Security Alliance, Eventia, Eventia Analyzer, FireWall-1, FireWall-1 GX, FireWall-1 SecureServer, FloodGate-1, Hacker ID, IMsecure, INSPECT, INSPECT XL, Integrity, InterSpect, IQ Engine, Open Security Extension, OPSEC, Policy Lifecycle Management, Provider-1, Safe@Home, Safe@Office, SecureClient, SecureKnowledge, SecurePlatform, SecuRemote, SecureXL Turbocard, SecureServer, SecureUpdate, SecureXL, SiteManager-1, SmartCenter, SmartCenter Pro, Smarter Security, SmartDashboard, SmartDefense, SmartLSM, SmartMap, SmartUpdate, SmartView, SmartView Monitor, SmartView Reporter, SmartView Status, SmartViewTracker, SofaWare, SSL Network Extender, Stateful Clustering, TrueVector, Turbocard, UAM, User-to-Address Mapping, UserAuthority, VPN-1, VPN-1 Accelerator Card, VPN-1 Edge, VPN-1 Pro, VPN-1 SecureClient, VPN-1 SecuRemote, VPN-1 SecureServer, VPN-1 VSX, VPN-1 XL, Web Intelligence, ZoneAlarm, ZoneAlarm Pro, Zone Labs, and the Zone Labs logo, are trademarks or registered trademarks of Check Point Software Technologies Ltd. or its affiliates. All other product names mentioned herein are trademarks or registered trademarks of their respective owners. The products described in this document are protected by U.S. Patent No. 5,606,668, 5,835,726, 6,496,935 and 6,850,943 and may be protected by other U.S. Patents, foreign patents, or pending applications.

For third party notices, see “THIRD PARTY TRADEMARKS AND COPYRIGHTS” on page 103.

Table of Contents 5

Contents

Preface Who Should Use This Guide................................................................................ 8TSummary of Contents ....................................................................................... 9What Typographic Variations Mean .................................................................... 10

Chapter 1 Introduction Overview ......................................................................................................... 14Programming Model ......................................................................................... 15

Threads ..................................................................................................... 16Defining a LEA Client.................................................................................. 16LEA API Overview ....................................................................................... 17

Chapter 2 Client API Functions Function Calls ................................................................................................. 46

Managing the Session ................................................................................. 46Managing the Log Files ............................................................................... 52Managing fw.logtrack .................................................................................. 54Collected Log Files...................................................................................... 59Managing Log Field Values .......................................................................... 65Managing the Dictionary Iteration Structure................................................... 70LEA Extended Values .................................................................................. 73LEA Filtering .............................................................................................. 79Local (Client-side) Filtering.................................................................................. 90

Chapter 3 LEA Event Handlers Event Handlers ............................................................................................... 94

Event Handler for the LEA_RECORD event .................................................... 94Event Handler for the LEA_DICT Event ......................................................... 97Event Handler for the LEA_SWITCH Event..................................................... 98Event Handler for the LEA_EOF Event........................................................... 98Event Handler for the LEA_FILTER_QUERY_ACK Event.................................. 99Event Handler for the LEA_COL_LOGS Event............................................... 100Event Handler for the LEA_SUSPEND Event................................................ 101Event Handler for the LEA_RESUME Event ................................................. 101

Index...........................................................................................................109

7

Preface PPreface

In This Chapter

Who Should Use This Guide page 8

TSummary of Contents page 9

What Typographic Variations Mean page 10

Who Should Use This Guide

8

Who Should Use This GuideThis document describes the Log Export API (LEA) Specification.

This API specification is written for developers who write software to enhance the network security provided by VPN-1.

It assumes that you have read the Check Point VPN-1 OPSEC API Specification.

It also assumes that you have a basic understanding and a working knowledge of the following:

• system and network security

• the VPN-1 product

• system and network administration

• the C and/or C++ programming language

• the Unix or Windows operating system

• Internet protocols

TSummary of Contents

Chapter Preface 9

TSummary of ContentsThis guide contains the following chapters:

Table A-1

Chapter Description

Chapter 1, “Introduction” This chapter introduces the LEA (Log Export API) Specification.

Chapter 2, “Client API Functions”

Introduces and explains API Functions.

Chapter 3, “LEA Event Handlers”

Describes the functions that need to be written in order to implement a LEA Client.

What Typographic Variations Mean

10

What Typographic Variations MeanThe following table describes the typographic variations used in this book.

TABLE P-1 Typographic Conventions

Typeface or Symbol Meaning Example

AaBbCc123 The names of commands, files, and directories; on-screen computer output; code

Edit your .login file.Use ls -a to list all files.machine_name% You have mail.session = sam_new_session (client, server);

AaBbCc123 same as above, but with emphasis

session = sam_new_session (client, server);

Save Text that appears on an object in a window

Click on the Save button.

<your text> Replace the angle brackets and the text they contain with your text.

Edit the file <FWDIR>\lib\yourfile.xx

.

.

.

Lines of data or code omitted from example

line 1line 2...line n


Chapter Preface 11

[item] The item is optional.

dir [/o]

[item1] ... [item2] List of optional items

dir [/o] [/w] [/s]

item1 | item2 | item3 Choose one of the items.

copy infile1 | infile1 + infile2 |infile1 + infile2 + infile3 outfile

italic Specific values will be shown in italics

one of addnet | addapp

TABLE P-1 Typographic Conventions(continued)

Typeface or Symbol Meaning Example


12

13

Chapter 1Introduction

In This Chapter

Overview page 14

Programming Model page 15

Defining a LEA Client page 16

LEA API Overview page 17

LEA Client Application Structure page 17

Event Handling page 18

LEA Sessions page 19

Log Files page 20

Log Unification page 21

Log Record Implementation page 24

Collected Log Files page 24

Dictionaries page 32

Overview

14

OverviewCheck Point’s OPSEC (Open Platform for Security) integrates and manages all aspects of network security through an open, extensible management framework. Third party security applications can plug into the OPSEC framework via published application programming interfaces (APIs). Once integrated into the OPSEC framework, all applications can be configured and managed from a central point, utilizing a single Security Policy editor.

This document describes the LEA (Log Export API) Specification, which enables a third party application to securely receive both real-time and historical auditing log data generated by VPN-1.

Programming Model

Chapter 1 Introduction 15

Programming ModelThe LEA (Log Export API) Specification enables VPN-1 log data to be exported to third-party applications. For example, a reporting application might use LEA to get both historical and real-time connection accounting data, allowing a user to track network activity and perform chargebacks on certain types of network traffic. A suspicious activity monitor might use LEA to help detect attempts to access and break through the firewall system.

A log event corresponds to a line, or record, in the VPN-1 SmartView Tracker. Each log record consists of several log fields.

Each log field corresponds to a column in SmartView Tracker. The exception to this is the Info. column, which is used to display additional information not included in other columns. This information may in fact consist of several different fields. The LEA application handles each of these fields separately.

Figure 1-1 shows what happens when a LEA Server, usually a VPN-1 SmartCenter Server, sends a log record to a LEA Client for processing.Figure 1-1 LEA Client/Server Programming Model

When the connection between the LEA Server and the LEA Client is established, the LEA Server sends all the records in the log file to the LEA Client, one after the other. To reduce network traffic, the LEA Client may request that the LEA Server filter these records according to certain criteria.

Communication between a LEA Client and a LEA Server is implemented by the OPSEC Transport Layer.

FireWalledGateway

(NT)

These VPN/FireWall Modules(enforcement points)

send log records and alerts ...

1

ManagementStation

LEA Client

FireWalledGateway

(Unix)

... to this Management Station...

(the LEA Server)

2

... which sends LEA recordsto this LEA Client.

3InternetRouter Router

Threads

16

ThreadsLEA API Multithread level is “reentrant”. This means that:

• Multiple threads may use the LEA API concurrently.

• Multiple threads may not share data generated by LEA API

For more information, see “Multithreaded OPSEC Applications” in the Check Point VPN-1 OPSEC API Specification

Defining a LEA ClientThe steps involved in integrating a LEA Client with VPN-1 fall into two broad categories:

1. Configuring communication between VPN-1 and the LEA Client.

This requires the OPSEC and LEA APIs, and involves the following steps:

a. Creating and/or editing the VPN-1 LEA Server and Client configuration files.

This is described in detail in “Client-Server Configuration” in the OPSEC API.

b. If communication between VPN-1 and the LEA Client is to be authenticated or encrypted, performing a key exchange.

For more information, see “Establishing an Authentication Key” in the OPSEC API Specification.

c. Using the LEA API to write the event handlers required to implement communication between the LEA Server and the LEA Client.

This is described in detail in “LEA API Overview” on page 17.

2. Designing a VPN-1 Security Policy that meticulously logs all events of potential interest to the LEA Client.

A LEA Client can only process logged events—it cannot be aware of events that were not logged. The VPN-1 Security Policy installed on the enforcement points must explicitly specify the events that should be logged.

For detailed instructions for configuring logging, see the VPN-1 Administration Guide.

LEA API Overview


LEA API OverviewThe LEA Client uses the OPSEC and LEA API functions to communicate with and process log events sent by the LEA Server.

LEA Client Application StructureA LEA Client’s main function should proceed as illustrated below:Figure 1-2 LEA Client Application Structure

mainloop

Handler forEvent #1

Handler forEvent #2

EVENT #1 EVENT #2

initialize LEA Server entity

free the OPSEC environment

free the LEA Server entity

initialize OPSEC environment

initialize LEA Client entity

start the OPSEC session

start the main loop

free the LEA Client entity

LEA API Overview

18

Once the OPSEC environment and the LEA session are both initialized, the main loop waits for events to occur and then processes them. Events are handled by the LEA API functions. The main loop is terminated by the underlying OPSEC level. When this happens, the OPSEC entities and environment are freed.

For more information on lea_new_session, see page 46.

Event HandlingThe LEA Client responds to the following events:

• LEA_RECORD: a log record has been received.

The LEA Client responds by determining what action to take based on the contents of the log record.

• LEA_DICT: a change has occurred in one of the dictionaries.

The LEA Client responds by reinitializing any internal data based on the contents of the dictionaries.

• LEA_SWITCH: the log file has been switched. That is, the LEA Server has started a new log file.

• LEA_EOF: the last record in the log file has been sent to the LEA Client.

The LEA Client can expect more records only if lea_new_session was called with mode LEA_ONLINE.

• LEA_FILTER_QUERY_ACK: a LEA filter has been enabled or disabled.

• LEA_COL_LOGS_HANDLER: update to the collected log file list has arrived.

• LEA_SUSPEND: the session has been suspended at the LEA Client’s request.

• LEA_RESUME: the suspended session has been resumed at the LEA Client’s request.

LEA API Overview


The response to each of these events is handled by the event handler (callback) functions set in the call to opsec_init_entity for the Client entity. These callbacks are set using the attributes listed in the table below.L

For more information on opsec_init_entity see Chapter 2 of the OPSEC API Specification.

LEA SessionsOnce an OPSEC session is established between the LEA Client and the LEA Server, the LEA Client may request that the session be suspended, that is, that the LEA Server stop sending log records on the session. The LEA Client may then request that the session be resumed at a later time.

Table 1-1 opsec_init_entity - LEA entity type values

value type meaning

LEA_SUSPEND_HANDLER handler The event handler for the LEA_SUSPEND event (see page 101).

LEA_RESUME_HANDLER handler The event handler for the LEA_RESUME event (see page 101).

LEA_RECORD_HANDLER handler The event handler for the LEA_RECORD event(see page 94).

LEA_DICT_HANDLER handler The event handler for the LEA_DICT event (see page 94).

LEA_SWITCH_HANDLER handler The event handler for the LEA_SWITCH event (see page 98).

LEA_EOF_HANDLER handler The event handler for the LEA_EOF event (see page 98).

LEA_FILTER_QUERY_ACK_HANDLER

handler The event handler for the LEA_FILTER_QUERY_ACK event (see page 99).

LEA_COL_LOGS_HANDLER handler The event handler for the LEA_COL_LOGS_HANDLER event (see page 100).

LEA API Overview

20

The following API functions manage LEA sessions:

Log FilesLogged events are recorded in the VPN-1 Log. That is, each entry in the Log is a record of an event that is to be logged according to the VPN-1 Security Policy or according to the properties specified in the Properties Setup window of SmartDashboard. In addition, every event that caused an alert, as well as certain important system events (such as a Security Policy being installed or uninstalled on a host), are also logged.

In Next Generation the security and account information is stored in a single file. The current log file is always fw.log for both security and account information.

For more information, see the VPN-1 Administration Guide.

The following API functions manage log file information:

Table 1-2 API functions managing the LEA session

function name description See...

lea_new_session starts OPSEC session and specifies the log file to be used

page 46

lea_new_suspended_session starts OPSEC session page 46

lea_session_suspend suspend the LEA session page 51

lea_session_resume resumes the LEA session page 52

Table 1-3 API functions for managing log files


lea_get_logfile_desc retrieves information about the current log file page 53

lea_get_record_pos returns the number of the next record or event in the log file

page 53

LEA API Overview


Log Unification

File Structure

VPN-1 introduced a major change in the internal structure of the log repository, information regarding connections can now be added as time progresses.

Log records are now comprised of fragments. Every log record is a chain of one or more records. Fragments are associated with a chain via their unique ID (also called UID). Every number of fragments containing the same UID are part of the same chain. There is one special constant UID, the Unspecified UID. Fragments containing the Unspecified UID are stand-alone and are not part of any chain.

Unification

Information can be gathered from all the chain’s fragments but the user sees one unified log record. The LEA Server uses a fixed unification scheme for reading log files.

Note - Fragments of the same chain might be spread all over the log file and sometimes even across file boundaries.

LEA API Overview

22

File Read Modes

File read modes are the various ways that LEA reads a file. Log files can be read in various modes, each mode is targeted for a different scenario. Various scenarios are described in Table 1-4. For further implementation information

see lea_new_session.

LEA Support for Log Unification

LEA provides the LEA user with the ability to read logs using the new modes described in Table 1-4. The backwards compatibility and accounting modes are the already known normal and accounting modes that currently exist for LEA logging.

Table 1-4 File read modes

mode description

Unified When a chain is read in a log file, all its fragments are in the output. When a new fragment arrives online, there is no update (e.g. new accounting information).One log record per chain.

Semi-unified When a fragment is reached, it is unified with all the previous fragments of the same chain. When a new fragment arrives online, it is unified with all the previous fragments of the same chain. n log records per chain, where n is the number of the fragments in the chain.

Raw When a log fragment is reached, it is not unified. The user can see it as-is. When a new fragment arrives online it is not unified.n log records per chain where n is the number of fragments in the chain.

Backwards Compatibility

This mode tries to imitate the way that the log file looks on VPN-1/FireWall-1 version 4.1 and earlier. The file is read in semi-unified mode with some modifications

Account Only accounting fragments are read in this mode.

Note - LEA uses the OPSEC UID in order to implement UIDs. For further information see OPSEC Unique ID in the OPSEC API Overview Section of the OPSEC API Specification.

LEA API Overview


Tracking Log Files

The file fw.logtrack maintains a list of log file names and corresponding file IDs. Each entry in fw.logtrack has the following form:

12345 is the Accounting Log File ID. 12346 is the Security Log File ID. xxx is the log file name. In other words, the file ID for xxx.alog is 12345, and the file ID for xxx.log is 12346.

The following API functions retrieve information from fw.logtrack:

Log File Data Structure

Information about a log file is stored in a lea_logdesc data structure. This structure is defined in lea.h and has the following fields:

12345 12346 xxx

Table 1-5 API functions for managing fw.logtrack


lea_get_filename_by_fileid

returns the filename of a file specified by file ID

page 54

lea_get_fileid_by_filename

returns the file ID of file specified by name page 55

lea_get_first_file_info returns information about the first file in fw.logtrack

page 56

lea_get_next_file_info returns information about the next file in fw.logtrack (only after lea_get_first_file_info has been called).

page 57

lea_get_last_file_info returns information about the last file in fw.logtrack

page 58

Table 1-6 fields for lea_locdesc

name type meaning

fileid long This ID uniquely specifies the log file and remains unchanged even after the log file is switched.

filename char * The file name.

LEA API Overview

24

Log Record ImplementationEach log record is represented as a pointer to a lea_record data structure, which in turn points to an array of lea_field structures. Each lea_field structure contains information about a single field in the log record. This is illustrated in Figure 1-3:Figure 1-3 lea_record and lea_field structures

See Table 1-20 on page 38 for a complete list of fields.

The lea_record and lea_field data structures are described in detail below.

Collected Log FilesCollected log files are log files which reside on the VPN-1 SmartCenter Server in the “$FWDIR/log” directory that have been forwarded either by VPN-1 enforcement points or manually imported into this directory (for example from older versions of VPN-1 modules). These log files include the files in the fw.logtrack list. For more

lea_attr_idlea_val_typelea_valuelea_dictionary

lea_field


lea_field


lea_field

rec

lea_record

field name(use lea_attr_nameto convert to string)

value(convert to string using

lea_resolve_field orlea_dictionary_lookup)

relevant dictionary(or LEA_NO_DICT)

data type(LEA_VT_STRINGLEA_VT_INT etc.)

Note - When SmartView Tracker encounters a log field that does not have a corresponding column, it displays the field’s value in the Info column. So what seems to be one log field in the SmartView Tracker may in fact be several different fields. The LEA Server handles each of these fields separately.

LEA API Overview


information refer to the “Forward log files to SmartCenter Server” property in the “Workstation Properties Window — Masters Page” in the “Network Objects Chapter” of the “CP SmartCenter Book”).

Lea Clients can be notified when changes occur in the collected file list of the server to which they connect. The notification can be either a callback handler or a local query to the updated information that the client (automatically) receives (from the server) and holds. See the “Event Handler for the LEA_COL_LOGS Event””.

The information is updated:

• when a log forwarding event occurs or

• during periodic checks (of approximately 30 minutes) of the SmartCenter Server to its $FWDIR/log or

• by invoking the fw lea_notify command manually on SmartCenter Server

For further information, refer to the “Check Point SmartCenter Guide”.

Client notification only occurs upon changes in the file list information.

The list contains the following log file types:

• *.log — regular log files

• *.alog — account log files from versions prior to NG

• *.adtlog — auditing log files

Table 1-7 Collected Log Files Functions


lea_get_first_collected_file_info

returns a handle to the first file in the collected list

page 59

lea_get_next_collected_file_info

returns a handle to the next file in the collected list (only after lea_get_first_collected_file_info has been called)

page 60

lea_get_prev_collected_file_info

returns a handle to the previous file in the collected list

page 61

lea_get_last_collected_file_info

returns a handle to the last file in the collected list

page 62

LEA API Overview

26

lea_record Data Structure

This structure is defined in lea.h and has the following fields:

lea_field Data Structure

This structure is defined in lea.h and has the following fields:

lea_collected_file_info_duplicate

duplicates the info handle for future access

page 63

lea_collected_file_info_destroy destroys the info that is returned from the duplication

page 64

lea_get_collected_file_info_by_field_name

retrieves the various fields from each info handle

page 64

Table 1-7 Collected Log Files Functions


Table 1-8 lea_records fields in lea.h

name type meaning

n_fields int The number of lea_field structures in the fields array that follows.

fields lea_field * A pointer to an array of lea_field structures.

Table 1-9 lea_field fields in lea.h

name type meaning

lea_attr_id int The index to the log field’s name (use lea_attr_name to convert this to a string).

lea_val_type LEA_VT This identifies the data type of the log field, and is used for formatting lea_value (see “lea_value and lea_val_type fields”” below).

lea_value lea_value_t The log field’s value (see “lea_value and lea_val_type fields”” below).

lea_dictionary int This identifies the relevant dictionary. If there is no relevant dictionary (for example, in the case of the time field) then this field’s value is LEA_NO_DICT.

LEA API Overview


lea_value and lea_val_type fields

The lea_value member of the lea_field structure is of a union data type and holds the value of the log field. It is defined in lea.h as follows:

In other words, the value of the log field may be one of several different data types. The lea_value_type field of the lea_field structure indicates the data type of the log field’s value. That is, lea_value_type indicates the data type of the value stored in the lea_value field.

The access to the data in lea_value can be simplified using the field names specified in Table 1-10. These are also defined in lea.h.

typedef union _lea_value{char *string_value;int i_value;unsigned short ush_value;unsigned char uch_value;unsigned long ul_value;opsec_uuid *uuid_value;

} lea_value_t;

Table 1-10 the lea_value and lea_val_type fields

lea_value field

name

lea_val_type C type meaning

lea_int LEA_VT_INT int General purpose integer.

lea_u_short LEA_VT_USHORT unsigned short

General purpose unsigned short.

lea_hex LEA_VT_HEX unsigned long General purpose hexadecimal number.

lea_string LEA_VT_STRING char * General purpose string.

lea_action LEA_VT_ACTION int The action taken in enforcing Security Policy.

lea_alert LEA_VT_ALERT int The type of alert.

lea_interface LEA_VT_INTERFACE int The interface through which the connection is passed.

lea_direction LEA_VT_DIRECTION unsigned char The direction of the connection (e.g. inbound, outbound).

LEA API Overview

28

LEA FilteringA LEA filter specifies certain criteria that log records must meet before they are sent to the LEA Client. The filter is created by the LEA Client and applied to the LEA Server, thereby reducing unnecesasry network traffic.

A LEA filter consists of a Rule Base, which may have any number of rules greater than zero. Within the Filter Rule Base, the first matching rule is applied. A final implied rule drops all log records.

Each rule consists of at least one predicate. A predicate tests whether a log field meets a given criterion. For example, a predicate can test whether a log record originated from a particular subnet. If there is more than one predicate in a rule, they are ANDed. For a list of predicates, see TABLE 3-8 on page 55.

lea_time LEA_VT_TIME unsigned long The time of day in seconds since 1 January, 1970.

lea_duration_time

LEA_VT_DURATION_TIME unsigned long The duration of connection, in seconds.

lea_ip_addr LEA_VT_IP_ADDR unsigned long IP address in network order.

lea_ip_proto LEA_VT_IP_PROTO unsigned char IP protocol.

lea_mask LEA_VT_MASK unsigned long Mask (for UFP categories).

lea_rpc_prog LEA_VT_RPC_PROG unsigned long RPC program number.

lea_rule LEA_VT_RULE int The number of the Security Policy rule applied to the connection.

lea_tcp_port LEA_VT_TCP_PORT unsigned short

TCP port number in network order.

lea_udp_port LEA_VT_UDP_PORT unsigned short

UDP port number in network order.

lea_uuid LEA_VT_UUID opsec_uuid * The record events unique ID.

Table 1-10 the lea_value and lea_val_type fields

lea_value field

name

lea_val_type C type meaning

LEA API Overview


Defining and Implementing a LEA filter

The following API functions define and implement a LEA filter:

To create and implement a LEA filter, follow these steps:

1. Create the Rule Base by calling lea_filter_rulebase_create.

The default rule in any Rule Base drops all log records, so log records must be explicitly selected by the filter in order to be received by the LEA Client.

Within a Rule Base, the first matching rule is applied.

2. For each rule:

• Create the rule by calling lea_filter_rule_create.

• For each predicate:

• Create the predicate by calling lea_filter_predicate_create.

• Add the predicate to the rule by calling lea_filter_rule_add_predicate.

• Destroy the predicate by calling lea_filter_predicate_destroy.

Within a rule, predicates are ANDed.

Table 1-11 API functions for implementing LEA filters


lea_filter_rulebase_create creates an empty filter Rule Base page 51

lea_filter_rulebase_destroy destroys the filter Rule Base page 51

lea_filter_rulebase_add_rule

adds a rule to the filter Rule Base page 51

lea_filter_rulebase_register

sends the filter to the LEA Server page 52

lea_filter_rulebase_unregister

disables the filter page 52

lea_filter_rule_create creates a filter rule page 52

lea_filter_rule_destroy destroys a filter rule page 53

lea_filter_rule_add_predicate

adds a predicate to a filter rule page 54

lea_filter_predicate_create creates a predicate page 55

lea_filter_predicate_destroy

destroys a predicate page 58

LEA API Overview

30

• Add the rule to the Rule Base by calling lea_filter_rulebase_add_rule.

• Destroy the rule by calling lea_filter_rule_destroy.

3. To start filtering log records, send the filter Rule Base to the LEA Server by calling lea_filter_rulebase_register.

Destroy the Rule Base by calling lea_filter_rulebase_destroy.

LEA Client-Side Filtering

LEA filtering is the existing mechanism performed by the LEA Server. LEA client-side filtering is the new mechanism added for NG.

LEA client-side filtering provides the client application with the ability to use the LEA filtering mechanism. The filtering is performed on the client-side rather than on the server-side. LEA client-side filtering emulates the model of LEA Filtering but some differences in the client experience still exist due to the different nature of the two. These difference are outlined in . The similarities are that the rulebase construction and destruction and the same rule-actions are supported in both LEA filtering and LEA client-side filtering.

Table 1-12 Lea filtering vs. LEA client-side filtering

category LEA Filtering (server) LEA Client-Side Filtering

(client)

Functional differences

server-resolved values (values of types LEA_VT_SR_*)

supported not supported

Synchronicity differences

operation mode asynchronous synchronous

filter ID needed in function calls

yes no

filtering starts immediately no yes

LeaFilterQueryAckHandler called

yes no

API differences

rulebase register API lea_filter_rulebase_register (old)

lea_filter_rulebase_register_local (new)

LEA API Overview


Synchronous vs. Asynchronous

In asynchronous mode, the rulebase is sent to the LEA Server and it is only after the LEA Server acknowledges the rulebase to the client (with LeaFilterQueryAckHandler) that the records are actually filtered. When the file is read in LEA_OFFLINE mode, this lag time can constitute some hundreds of log records.

LEA client-side filtering is performed locally, therefore its operation is synchronous, meaning that the filtering actually starts or stops immediately upon the successful return of the register or unregister APIs. This also eliminates the need to register for the LeaFilterQueryAckHandler event or for the use of filter IDs.

Backwards Compatibility

VPN-1 firewalls prior to NG did not support LEA Filtering. However, using filtering on the client-side provides a work around because the filtering is being done at the level of the OPSEC library on the client-side.

LEA Extended ValuesThe LEA filter API functions use LEA extended values. A LEA extended value contains both the data and the LEA Virtual Type corresponding to it, and is implemented using the lea_value_ex_t data structure.

LEA Virtual Types are listed in the lea_val_type column of Table 1-10 on page 27. See also “LEA Extended Values” on page 73.

rulebase unregister API lea_filter_rulebase_unregister (old)

lea_filter_rulebase_unregister_local (new)

Version differences

can be used with older versions of VPN-1

No, support on the server is required.

Yes, support is only needed in teh OPSEC SDK. Using the newest OPSEC SDK with older versions of VPN-1 is possible.

Table 1-12 Lea filtering vs. LEA client-side filtering

category LEA Filtering (server) LEA Client-Side Filtering

(client)

LEA API Overview

32

The following API functions manage LEA extended values:

DictionariesLog fields contain data that must be “translated”—that is, converted into strings—in order to be meaningful. This is done using dictionaries that associate the values of the log fields with strings. For example, the “action” field of a given log record is an integer that must be translated into “accept” or “reject” by looking up the value in the appropriate dictionary.

There are two kinds of log field values:

• values that have meaning outside the context of the session

For example, IP addresses and port numbers.

• values that are meaningful only in the context of the session

For example, the meaning of the values in the “action” log field is likely to change from session to session. 2 might mean “accept” in one session and “reject” in another session due to the different sequence in which log records were generated in each session.

Table 1-13 API functions for managing LEA extended values


lea_value_ex_create creates an empty LEA extended value page 73

lea_value_ex_destroy destroys the LEA extended value page 73

lea_value_ex_duplicate

makes a new copy of a LEA extended value page 73

lea_value_ex_set sets the data value and virtual type of a LEA extended value

page 74

lea_value_ex_get retrieves the contents of the LEA extended value page 76

lea_value_ex_get_type retrieves the virtual type of the LEA extended value

page 78

LEA API Overview


The following API functions are used to translate or resolve log field values:

Dictionary Types

While some log fields, such as time or messages sent by the VPN-1 kernel, can be used as is, most log fields require some sort of translation. In these cases, the lea_dictionary member in the lea_field structure identifies the applicable dictionary. The log field’s untranslated value is stored in the lea_field->lea_value.

Each time a new dictionary is sent to the LEA Client, a LEA_DICT event is generated. During the course of an OPSEC session, the LEA Server may update the dictionaries.

Table 1-14 API functions managing log field values


lea_dictionary_lookup returns the string associated with a given log field value using the specified dictionary

page 65

lea_reverse_dictionary_lookup

returns the log field value associated with a given string using the specified dictionary

page 67

lea_resolve_field returns the value of a log field as an ASCII string

page 68

lea_attr_name returns the string containing the name of the log field

page 69

LEA API Overview

34

Table 1-15 lists the dictionaries that are always available to the LEA Client. The LEA_DICT events for these dictionaries always happen before the first LEA_RECORD event. In addition to these standard dictionaries, the LEA Server may send dictionaries for other fields, depending on the log record.

The Attribute Dictionary is different than the other dictionaries. Its purpose is not to resolve or translate the values of specific log fields, but rather to maintain a general list of field names. This list can then be used to locate the value of a specific field within a log record. For an example of how this is done, see page 72.

The Attribute Dictionary is also unique in that no lea_field structure points to it.

Table 1-15 Available Dictionaries

dictionary ID (defined in lea.h) contents

Attribute Dictionary

LEA_ATTRIB_ID The names of the fields in the log records already sent to the Client, such as: “time”, “orig”, “action”, “src”, “dst”. See below for more information.

IP Address Dictionary

LEA_IP_ID The IP addresses in the VPN-1 objects database (objects.C).

Actions Dictionary

LEA_ACTION_ID The available actions: “accept”, “drop”, “reject”, “encrypt” etc.

UDP Services Dictionary

LEA_UDP_SERVICES_ID The UDP services in objects.C.

TCP Services Dictionary

LEA_TCP_SERVICES_ID The TCP services in objects.C.

Note - IP addresses and services in the dictionaries are drawn from the objects database (the objects.C file). DNS is not used to resolve IP addresses.

LEA API Overview


Dictionary Data Structures

Each entry in the dictionary is represented as a pointer to a lea_dict_entry data structure. This structure is defined in lea.h and has the following fields:

For example, when lea_d_name is “telnet”, lea_d_value is 23 (in network byte ordering).

For a definition of the lea_value_t data type, see “lea_value and lea_val_type fields” on page 27.

The access to the data in lea_d_value can be simplified using the field names specified in Table 1-17. These are also defined in lea.h.

Table 1-16 lea_dict_entry data structure

name type meaning

lea_d_name char * The string representing translated value of the log field.

lea_d_value lea_value_t The untranslated log field value corresponding to lea_d_name.

Table 1-17 the lea_d_value field

lea_d_value field

name

C type meaning

lea_d_int int General purpose integer.

lea_d_u_long unsigned long General purpose unsigned long.

lea_d_u_short unsigned short General purpose unsigned short.

lea_d_u_char unsigned char General purpose unsigned char.

lea_d_hex unsigned long General purpose hexadecimal number.

lea_d_action int The action taken in enforcing Security Policy.

lea_d_alert int The type of alert.

lea_d_attrib int Names of fields in log records.

lea_d_direction unsigned char The direction of the connection (e.g. inbound, outbound).

lea_d_duration_time

unsigned long The duration of connection, in seconds.

lea_d_interface int The OS name of interface through which connection is passed.

LEA API Overview

36

Dictionary Iteration Structure

A dictionary iteration structure is used in order to access all the entries in a dictionary one after the other.

A dictionary iteration structure always corresponds to a specific dictionary.

The values that the dictionary entries hold may vary from LEA session to LEA session.

The following API functions manage the dictionary iteration structure and enable you to step through the entries of a dictionary.

UFP Masks

A dictionary is sent for every UFP (URL Filtering Protocol) Server appearing in the log file.

lea_d_ip_addr unsigned long IP address in network order.

lea_d_ip_proto unsigned char IP protocol.

lea_d_mask unsigned long Mask (for UFP categories).

lea_d_rpc_prog unsigned long RPC program number.

lea_d_rule int The number of the Security Policy rule applied to the connection.

lea_d_tcp_port unsigned short TCP port number in network order.

lea_d_udp_port unsigned short UDP port number in network order.

lea_d_time unsigned long The time of day in seconds since 1 January, 1970.

Table 1-17 the lea_d_value field

lea_d_value field

name

C type meaning

Table 1-18 API functions for managing the iteration structure


lea_dict_iter_create creates an iteration structure for a dictionary page 70

lea_dict_iter_next returns pointer to the next dictionary entry in the associated dictionary

page 71

lea_dict_iter_destroy destroys the specified iteration structure page 72

LEA API Overview


The lea_d_mask value in a lea_d_entry of a UFP dictionary corresponds to the index of the active bit in the UFP mask. In other words, lea_d_mask and the UFP mask are two different representations of the same information. A UFP Server can assign, to a URL, more than one category. The value of a UFP mask (lea_d_mask) in the “category” field of the log file can be calculated as in this manner:

Suppose that a LEA client has received a LEA_VT_MASK dictionary that looks like table Table 1-19 below. Assume that a URL http://some.server.com/ has been found to match the “family” and the “games” categories.

The value of the “category” field in the log file would then be:2(id of “family”) + 2(id of “games”) = 21 + 23 = 2+8=10.

The lea_resolve_field function returns a string with all the applicable URL categories. The lea_dictionary_lookup function returns only one category name.

Dictionaries for different UFP Servers are sent to the LEA Client if there is a log record that refers to these additional UFP Servers.

For more information about UFP Servers and the URL Filtering Protocol see the UFP (URL Filtering Protocol) API Specification.

List of Log Fields

The table below lists the log fields, their meanings, and whether a dictionary is required to access their values.

Table 1-19 LEA_VT_MASK Dictionary Example

id category

name

0 Kids

1 Family

2 Books

3 Games

4 News

Note - Some of the field names end with a “:” character. For example, “reason” and “reason:” are two different fields.Note - Refer to the OPSEC Web page to obtain the most up-to-date version of this table.

LEA API Overview

38

Table 1-20 LEA fields

field data type descriptiondic

tionary

action LEA_VT_ACTION The action taken in enforcing the Security Policy (e.g. “accept”, “reject”).

Yes

agent LEA_VT_STRING The name of the agent used to deliver SMTP mail (e.g. “mailserver”).

No

alert LEA_VT_ALERT The type of alert (e.g. “useralert”).The presence of this field is the only reliable indication that the log entry is an alert type entry.

Yes

bytes LEA_VT_INT The number of bytes transmitted in the connection.

No

cat_server LEA_VT_STRING The name of the UFP Server. No

category LEA_VT_MASK UFP mask (e.g. “drugs”, “alcohol”).Use lea_resolve_field to resolve all relevant categories.Use lea_dictionary_lookup to resolve only one category. For more information see “UFP Masks” on page 36”.

Yes

d_port LEA_VT_UDP_PORT orLEA_VT_TCP_PORT orLEA_VT_USHORT

The destination port number(translation is available for well-known services).

Yes

decryption failure:

LEA_VT_STRING A string describing why the decryption failed (e.g. “failed to generate a shared key”).

No

dst LEA_VT_IP_ADDR IP address of the connection’s destination.

Yes

dstkeyid LEA_VT_STRING The destination’s encryption key ID. For ISAKMP this is the destination SPI.

No

elapsed LEA_VT_DURATION_TIME

The duration of a connection (e.g. “04:12:15”).

No

LEA API Overview


encryption failure:

LEA_VT_STRING A string describing why the encryption failed (e.g. “failed to generate a shared key”).

No

error_notification:

LEA_VT_STRING This specifies that an error occurred when sending mail while Notify Sender

on Error was enabled (e.g. “originally from <someone@somewhere> to <somebody@elsewhere>”).

No

expire LEA_VT_INT The length of time (in seconds) for which connections will be inhibited (e.g. “NEVER_EXPIRE” or “60”). Corresponds to the inhibit_expire argument to the sam_client_request function in the OPSEC SAM API.

No

file LEA_VT_STRING File name (for FTP). No

from LEA_VT_STRING The translated address of the sender (SMTP).

No

h_len LEA_VT_INT IP packet length (unsigned integer). No

has_accounting LEA_VT_INT When 1, this indicates that the log record has a matching record in the accounting log. When receiving records from an accounting log, this field is 0.

No

host: LEA_VT_IP_ADDR The IP address of the unsuccessful connection (e.g. “192.34.45.56”).

Yes

i/f_dir LEA_VT_DIRECTION The direction of the connection (e.g. “inbound”, “outbound”).

Yes

i/f_name LEA_VT_INTERFACE The interface through which this connection passed, “daemon” if generated internally (e.g. “le0”, “E190x2”).

Yes

Table 1-20 LEA fields(continued)

field data type description

dic

tionary

LEA API Overview

40

ip_vers LEA_VT_INT IP protocol version number. No

icmp-type LEA_VT_INT ICMP type (ICMP packets). No

icmp-code LEA_VT_INT ICMP code (ICMP packets). No

ISAKMP Log: LEA_VT_STRING Messages and error text. No

key update for LEA_VT_STRING The name of the host for which a new key was generated (e.g. “ISAKMP Log: FW-1 ISAKMP daemon started”).

No

license violation detected

LEA_VT_IP_ADDR IP address of the source of a VPN-1 license violation.

Yes

len LEA_VT_INT The length of the packet. No

message LEA_VT_STRING The text message generated by SYNDefender, describing why it thinks the network is under a SYN attack.

No

methods: LEA_VT_STRING A string consisting of three tokens separated by commas, as follows:• encryption method used to generate

the session key• encryption algorithm for the session• hashing algorithm for the session(e.g. “FWZ,DES,MD5”)

No

Negotiation Id: LEA_VT_STRING The ID of the negotiation — sent for both ISAKMP Phase One and Phase Two.

No

orig LEA_VT_IP_ADDR IP address of the VPN-1 Module that generated the log entry.

Yes

orig_from LEA_VT_STRING Address of the original sender (SMTP). No

orig_to LEA_VT_STRING Address of the original recipient (SMTP).

No

packets LEA_VT_INT The number of packets in the session. No



tionary

LEA API Overview


port: LEA_VT_UDP_PORT orLEA_VT_TCP_PORT orLEA_VT_STRING orLEA_VT_USHORT

The port number of the unsuccessful connection (e.g. “80”)

Yes

proto LEA_VT_IP_PROTO The connection’s higher level protocol.Use lea_resolve_field to convert these values from “real” IP protocol values to a string (e.g. “tcp”, “udp”).

No

reason LEA_VT_STRING For alerts, a description of why the alert was generated (e.g. “unknown user”).

No

reason: LEA_VT_STRING Messages sent by the VPN-1 kernel (e.g. “TCP packet too short”).

No

res_action LEA_VT_STRING The direction of an FTP file copy operation (e.g. “get”, “put”).

No

request LEA_VT_STRING This specifies the SAM Client’s request (e.g. “inhibit”, “close”).

No

resource LEA_VT_STRING The URL accessed (e.g. “http://194.148.0.21:80/”).

No

rpc_prog LEA_VT_RPC_PROG RPC program number. Yes

rule LEA_VT_RULE If greater than zero, the number of the Security Policy rule applied to the connection.Otherwise, a dictionary is specified, and the rule’s value can be converted into string (e.g. “internal”).

if <0

s_port LEA_VT_UDP_PORT orLEA_VT_TCP_PORT orLEA_VT_USHORT

The source port number. Yes

scheme: LEA_VT_STRING The encryption method used (e.g. “FWZ”).

No



dic

tionary

LEA API Overview

42

service LEA_VT_UDP_PORT orLEA_VT_TCP_PORT orLEA_VT_STRING orLEA_VT_USHORT

The destination port number for well known services (e.g. “http”, “ftp”).For services that are not well known, the field value can be accessed directly. The data type is LEA_VT_USHORT.

Yes

service_id ELA_VT_STRING The Service_id, when found, contains the name of the service. Usually it will be identical to the resolved service field (based on protocol+port) but sometimes it will be different - in cases when multiple versions of the same protocol use the same port (like ssh / ssh v2 / ssh v3).

No

signed by LEA_VT_STRING Certificate Authority associated with a key.

No

SPI: LEA_VT_STRING Security Parameter Index (Manual IPSec).

No

srcname LEA_VT_STRING The resolved IP address for DHCP-allocated addresses.

Yes

src LEA_VT_IP_ADDR IP address of the connection’s source. Yes

srckeyid LEA_VT_STRING The source’s encryption key ID. For ISAKMP this is the source SPI.

No

start_time LEA_VT_TIME The date and time the connection started (e.g. “31Dec1999 23:02:33”). Use the elapsed field to calculate the time the connection ended.

No

success reason: LEA_VT_STRING A string describing why the decryption succeeded (e.g. “gateway connected to both end points”).

No

sys_msgs LEA_VT_STRING The reason for the control log (e.g. “started sending log to localhost”).

Yes



tionary

LEA API Overview


target LEA_VT_IP_ADDR DNS name or IP address in dot notation of the host with which connections are to be inhibited or closed (SAM).

Yes

time LEA_VT_TIME The date and time the log entry was written (e.g. “31Dec1999 23:02:33”).

No

to LEA_VT_STRING The translated address of the recipient (SMTP).

No

user LEA_VT_STRING The user name. No

uuid LEA_VT_UUID The record events unique ID. No

xlatedport LEA_VT_UDP_PORT orLEA_VT_TCP_PORT

The translated destination port (when NAT is performed).For services that are not well known, the field value can be accessed directly. The data type is LEA_VT_USHORT. There is no need to transform to host order.

Yes

xlatedst LEA_VT_IP_ADDR The translated IP address of the destination (when NAT is performed).

Yes

xlatesport LEA_VT_UDP_PORT orLEA_VT_TCP_PORT

The translated source port (when NAT is performed).For services that are not well known, the field value can be accessed directly. The data type is LEA_VT_USHORT. There is no need to transform to host order.

Yes

xlatesrc LEA_VT_IP_ADDR The translated IP address of the source (when NAT is performed).

Yes



dic

tionary

LEA API Overview

44

45

Chapter 2Client API Functions

In This Chapter

Function Calls page 46

Managing the Session page 46

Managing the Log Files page 52

Managing fw.logtrack page 54

Collected Log Files page 59

Managing Log Field Values page 65

Managing the Dictionary Iteration Structure page 70

LEA Extended Values page 73

LEA Filtering page 79

Local (Client-side) Filtering page 90

Function Calls

46

Function CallsThis section describes the functions provided by the OPSEC LEA API. Unless mentioned otherwise, function prototypes are defined in the file lea.h.

Managing the SessionThe following functions start, suspend, and resume the OPSEC session.

lea_new_session

lea_new_suspended_sessionlea_new_session initializes an OPSEC session between the LEA Client and the LEA Server. Once the session is initialized, the LEA Client begins receiving log records from the LEA Server.

lea_new_suspended_session initializes an OPSEC session between the LEA Client and the LEA Server. The session is initialized in suspended mode, meaning that no log records will be sent for the session until the LEA Client calls lea_session_resume. Records will start to be received only after the LEA_RESUME event, which is triggered by the client calling lea_session_resume.

PrototypesOpsecSession * lea_new_session( OpsecEntity *client, OpsecEntity *server, int mode, int logtrack, ... );

OpsecSession * lea_new_suspended_session( OpsecEntity *client, OpsecEntity *server, int mode, int logtrack, ... );

Managing the Session

Chapter 2 Client API Functions 47

Arguments

Table 2-1 lea_new_session and lea_new_suspended_session arguments

argument meaning

client A pointer to Client entity, as returned by opsec_init_entity.

server A pointer to Server entity, as returned by opsec_init_entity.

mode A flag specifying Client behavior at end-of-file, when all the log records have been sent. One of the following values:

value meaning

LEA_ONLINE The Client will receive future log records as they are generated.

LEA_OFFLINE The Client will not receive any more log records after the end of the log file is reached.


48

logtrack A flag indicating which log file(s) to open, and whether the next argument specifies the name or the fileid of a log file, as returned by a call to lea_get_logfile_desc in a previous session.Unless otherwise specified, when EOF is reached in the log file, the LEA Server generates a LEA_EOF event and then opens the next log file listed in the internal database fw.logtrack. The LEA Server then sends all the records from this log file, and so on, until the current log file (fw.log for security logs, fw.alog for accounting logs) is processed. The behavior on reaching the end of the current log file depends on the value of the mode argument.

The file fw.logtrack should never be deleted.

LEA_FILENAMELEA_UNIFIED_SINGLELEA_SEMI_SINGLELEA_RAW_SINGLE

The next argument is the name of a log file, a string of type char *. The session ends when EOF is reached.See also “Event Handler for the LEA_EOF Event” on page 98. These are the only flags that should be used for collected log files.

LEA_NORMAL_FILENAMELEA_UNIFIED_FILENAMELEA_SEMI_FILENAMELEA_RAW_FILENAME

The next argument is the name of a security log file, a string of type char *. The last log file is fw.log.

LEA_ACCOUNT_FILENAME The next argument is the name of an accounting log file, a string of type char *. The last log file is fw.log.

LEA_NORMAL_FILEIDLEA_UNIFIED_FILEIDLEA_SEMI_FILEIDLEA_RAW_FILEID

The next argument is a fileid of a security log file.The last log file is fw.log.

LEA_FIRST_NORMAL_FILEIDLEA_FIRST_UNIFIED_FILEIDLEA_FIRST_SEMI_FILEIDLEA_FIRST_RAW_FILEID

The same as LEA_NORMAL_FILEID, but the first log file listed in fw.logtrack is used. The next argument is startat.


argument meaning



logtrack (cont.)

LEA_CURRENT_NORMAL_FILEIDLEA_CURRENT_UNIFIED_FILEIDLEA_CURRENT_SEMI_FILEIDLEA_CURRENT_RAW_FILEIDLEA_CURRENT_AUDIT_FILEID

The same as LEA_NORMAL_FILEID, but the current log file is opened. The next argument is startat.

LEA_ACCOUNT_FILEID The next argument is a fileid of an accounting log file. The last log file is fw.log

LEA_FIRST_ACCOUNT_FILEID The same as LEA_ACCOUNT_FILEID, but the first accounting log file listed in fw.logtrack is used. The next argument is startat.

LEA_CURRENT_ACCOUNT_FILEID The same as LEA_ACCOUNT_FILEID, but the current accounting log file is opened. The next argument is startat.


argument meaning


50

Return Values

Pointer to new session if successful. NULL if error.

Examples

• lea_new_session(client,server,mode,LEA_FILENAME,filename,LEA_AT_START);

The LEA Server will send log records starting with the first record in the filename log file.

• lea_new_session(client,server,mode,LEA_FILENAME,filename,LEA_AT_POS,5);

The LEA Server will send log records starting with the 5th record in the filename log file.

startat The point in the log file from which to begin receiving records.

value meaning

LEA_AT_START Start with the first record in the log file.

LEA_AT_END Start with the last record in the log file, that is, no records in the log file will be sent at this point in time. However, future log records will be sent as they are generated. If the specified file is not the current log file, then a LEA_EOF event is generated immediately.

LEA_AT_POS Start with the log record whose ordinal is given as the position argument. If position is greater than the number of records in the log file, then a LEA_EOF event is generated immediately, and the next file in fw.logtrack is read.

position The ordinal of the next log record to be received from the log file. This argument is required only if startat is LEA_AT_POS.


argument meaning



• lea_new_session(client,server,mode,LEA_NORMAL_FILEID,fileid,LEA_AT_END);

If mode is LEA_ONLINE, the LEA Server will not send any log records currently in the security log file specified by fileid, but will send any records generated in the future.

If mode is LEA_OFFLINE, the LEA Server will not send any log records currently in the log file specified by fileid, and the session will terminate.

• lea_new_session(client,server,mode,LEA_NORMAL_FILEID,fileid,LEA_AT_POS,239);

The LEA Server will send log records starting with the 239th record in the security log file specified by fileid.

• lea_new_session(client,server,mode,LEA_FIRST_NORMAL_FILEID,LEA_AT_START);

The LEA Server will send log records starting with the first record in the first security log file specified in fw.logtrack. After reading through this file, the LEA Server will send the records from the rest of the security log files listed in fw.logtrack.

• lea_new_session(client,server,LEA_OFFLINE,...,LEA_AT_END);

No log records will be received.

• lea_new_session(client,server,LEA_ONLINE,...,...);

The LEA Server will begin reading log files as specified in the lea_new_session’s argument. When the Server reaches the active log file, the file will be opened and read until EOF. The LEA Server will then continue sending log records as they are generated.

lea_session_suspendlea_session_suspend instructs the LEA Server to stop sending log records on the specified session. This function is asynchronous. The call is acknowledged by the LEA Server with a LEA_SUSPEND event (see page 101).

Prototypeint lea_session_suspend (OpsecSession *session);

Managing the Log Files

52

Arguments

Return Values

OPSEC_SESSION_OK if successful, OPSEC_SESSION_ERR otherwise.

lea_session_resumelea_session_resume instructs the LEA Server to resume sending log records on the specified session. This function is asynchronous. The call is acknowledged by the LEA Server with a LEA_RESUME event (see page 101).

Prototypeint lea_session_resume (OpsecSession *session);

Arguments

Return Values

OPSEC_SESSION_OK if successful, OPSEC_SESSION_ERR otherwise.

Managing the Log FilesThe following functions return information about the log files. Log files are opened as specified in the call to lea_new_session or lea_new_suspended_session (see page 46).

Table 2-2 lea_session_suspend arguments

argument meaning

session A pointer to the session to be suspended, as returned by lea_new_session or lea_new_suspended_session.

Table 2-3 lea_session_resume arguments

argument meaning

session A pointer to the session to be resumed.

Managing the Log Files


lea_get_logfile_desclea_get_logfile_desc returns a structure containing information about the current log file, that is, the log file whose records are currently being sent to the LEA Client. This function is useful if you wish to end and restart it at a later time using the same log file.

Prototypelea_logdesc * lea_get_logfile_desc(OpsecSession *session);

Arguments

Return Values

A pointer to lea_logdesc if successful. NULL otherwise.

For more information about the lea_logdesc data structure, see “Log File Data Structure” on page 23.

lea_get_record_poslea_get_record_pos returns the ordinal number of the next log record to be read in the current log file. This number can be used in lea_new_session to indicate the starting position in the log file.

Prototypeint lea_get_record_pos(OpsecSession *session);

Table 2-4 lea_get_logfile_desc arguments

argument meaning

session A pointer to the OPSEC session, as passed to the handler functions.

Managing fw.logtrack

54

Arguments

Return Values

Ordinal number of the next log record to be read if successful. A negative return value if error.

Managing fw.logtrackThe following functions retrieve information from fw.logtrack and iterate through the information.

lea_get_filename_by_fileidlea_get_filename_by_fileid returns the filename of the file specified by the file ID.

Prototypeint lea_get_filename_by_fileid(OpsecSession *session, char **pszFilename,int nFileId);

Table 2-5 lea_get_record_pos arguments

argument meaning


Note - lea_get_record_pos returns an undefined value if the LEA Client has not received any records from the LEA Server. That is, the LEA_RECORD event handler must be called at least once before lea_get_record_pos returns a valid value. Note - The ordinal number returned is not necessarily the number of the next record that the server sends. The next record might be filtered by the server, yet this is the number of the next record that the server will process.

Note - These functions may only be called after the first LEA_DICT event. Using these functions before the first LEA_DICT event may cause unexpected results.



Arguments

Return Values

One of the following:

lea_get_fileid_by_filenamelea_get_fileid_by_filename returns the security log file ID and accounting log file ID of the file with the specified name.

Prototypeint lea_get_fileid_by_filename(OpsecSession *session, int *pnNormalFID,int *pnAccountFID, char *szFilename);

Table 2-6 lea_get_filename_by_fileid arguments

argument meaning


pszFilename The pointer to be set to the filename. The user should never deallocate this pointer.

nFileId The file ID.

Table 2-7 Return Values for lea_get_filename_by_fileid

value meaning

LEA_SESSION_OK Success.

LEA_SESSION_ERR Failure.

LEA_SESSION_NOT_AVAILABLE Function was called before the first LEA_DICT event — log file information is not yet available.

LEA_SESSION_FILE_PURGED The specified log file has been purged.


56

Arguments

Return Values


lea_get_first_file_infolea_get_first_file_info returns the filename, security log file ID, and accounting log file ID of the first file listed in fw.logtrack.

lea_get_first_file_info also initializes the counter used by lea_get_next_file_info (see page 57) to step through fw.logtrack.

Each call to lea_get_first_file_info resets this counter.

Prototypeint lea_get_first_file_info(OpsecSession *session, char **pszFilename,int *pnNormalFID, int *pnAccountFID);

Table 2-8 lea_get_fileid_by_filename arguments

argument meaning


pnNormalFID A pointer to be set to the security log file ID.

pnAccountFID A pointer to be set to the accounting log file ID.

szFilename The name of the log file.

Table 2-9 Return Values for lea_get_fileid_by_filename

value meaning



LEA_SESSION_NOT_AVAILABLE The function was called before the first LEA_DICT event — log file information is not yet available.



Arguments

Return Values


lea_get_next_file_infolea_get_next_file_info returns the filename, security log file ID, and accounting log file ID of the next file listed in fw.logtrack. When the last file is reached, lea_get_next_file_info returns LEA_SESSION_IT_END.

You must call lea_get_first_file_info (see page 56) before the first call to lea_get_next_file_info.

Prototypeint lea_get_next_file_info(OpsecSession *session, char **pszFilename,int *pnNormalFID, int *pnAccountFID);

Table 2-10 lea_get_first_file_info arguments

argument meaning


pszFilename A pointer to be set to the log file name.



Table 2-11 Return Values for lea_get_first_file_info

value meaning




LEA_SESSION_IT_END Iteration through fw.logtrack has been completed.



58

Arguments

Return Values


lea_get_last_file_infolea_get_last_file_info returns the filename, security log file ID, and accounting log file ID of the last file listed in fw.logtrack. This file is fw.log.

Prototypeint lea_get_last_file_info(OpsecSession *session, char **pszFilename,int *pnNormalFID, int *pnAccountFID);

Table 2-12 lea_get_next_file_info arguments

argument meaning


pszFilename A pointer to be set to the accounting log file ID.

pnNormalFID A pointer to be set to the log file name.

pnAccountFID A pointer to be set to the security log file ID.

Table 2-13 Return Values for lea_get_next_file_info

value meaning




LEA_SESSION_IT_END Iteration through fw.logtrack has been completed.


Collected Log Files


Arguments

Return Values


Collected Log Files

lea_get_first_collected_file_infolea_get_first_collected_file_info returns a handle to the first file in the collected list. The order of the list is by file creation time on the Server’s file system.

Prototypeint lea_get_first_collected_file_info( OpsecSession *session, collected_file_info_t **collected_file_info );

Table 2-14 lea_get_last_file_info arguments

argument meaning


pszFilename A pointer to be set to the log file name.



Table 2-15 Return Values for lea_get_last_file_info

value meaning





Collected Log Files

60

Arguments

Return Values


lea_get_next_collected_file_infolea_get_next_collected_file_info returns a handle to the next file in the collected list. The order of the list is by file creation time on the Server’s file system.

Prototypeint lea_get_next_collected_file_info( OpsecSession *session, collected_file_info_t **collected_file_info );

Table 2-16 lea_get_first_collected_file_info arguments

argument meaning


collected_file_info The address to a pointer to collected_file_info_t structure.

Table 2-17 Return Values for lea_get_first_collected_file_info

value meaning


LEA_SESSION_NOT_AVAILABLE Information is not yet available. The information hasn’t arrived yet.

Collected Log Files


Arguments

Return Values


lea_get_prev_collected_file_infolea_get_prev_collected_file_info returns a handle to the previous file in the collected list. The order of the list is by file creation time on the Server’s file system.

Prototypeint lea_get_prev_collected_file_info( OpsecSession *session, collected_file_info_t **collected_file_info );

Table 2-18 lea_get_next_collected_file_info arguments

argument meaning



Table 2-19 Return Values for lea_get_next_collected_file_info

value meaning


LEA_SESSION_NOT_AVAILABLE Information is not yet available. The information has been updated or hasn’t arrived yet. If the information has been updated, call lea_get_first_collected_file_info or lea_get_last_collected_file_info

Collected Log Files

62

Arguments

Return Values


lea_get_last_collected_file_infolea_get_last_collected_file_info returns a handle to the last file in the collected list. The order of the list is by file creation time on the Server’s file system.

Prototypeint lea_get_last_collected_file_info( OpsecSession *session, collected_file_info_t **collected_file_info );

Table 2-20 lea_get_prev_collected_file_info arguments

argument meaning



Table 2-21 Return Values for lea_get_prev_collected_file_info

value meaning


LEA_SESSION_NOT_AVAILABLE Information is not yet available. The information has been updated or hasn’t arrived yet. If the information has been updated, call lea_get_first_collected_file_info or lea_get_last_collected_file_info

Collected Log Files


Arguments

Return Values


lea_collected_file_info_duplicatelea_collected_file_info_duplicate returns a duplicated info handler. This way the data can be accessed independent to the existance of the connection or future updates.

Prototypecollected_file_info_t *lea_collected_file_info_duplicate ( collected_file_info_t *collected_file_info_t *collected_file_info );

Argument

Return Values

A pointer to collected_file_info_t structure.

Table 2-22 lea_get_last_collected_file_info arguments

argument meaning



Table 2-23 Return Values for lea_get_last_collected_file_info

value meaning


LEA_SESSION_NOT_AVAILABLE Information is not yet available. The information hasn’t arrived yet.

Table 2-24 lea_collected_file_info_duplicate argument

argument meaning


Collected Log Files

64

lea_collected_file_info_destroylea_collected_file_info_destroy destroys the handle obtained by lea_collected_file_info_duplicate.

Prototypevoid lea_collected_file_info_destroy( collected_file_info_t * collected_file_info );

Argument

Return Values

None.

lea_get_collected_file_info_by_field_namelea_get_collected_file_info_by_field_name returns a field value of a specific collected file from the list.

Prototypelea_value_ex_t *lea_get_collected_file_info_by_field_name( collected_file_info_t *collected_file_info, char *fld_name );

Table 2-25 lea_collected_file_info_destroy argument

argument meaning


Managing Log Field Values


Arguments

Return Values

A pointer to a lea_value_ex_t structure containing the field value. The “Num of Records” of the active log file will be (-1).

Managing Log Field ValuesThe following functions translate the values of log fields into strings and vice versa.

lea_dictionary_lookuplea_dictionary_lookup returns the string corresponding to the specified log field value as stored in a dictionary.

This function is a complement of lea_reverse_dictionary_lookup (see page 67).

Table 2-26 lea_get_collected_file_info_by_field_name arguments

argument meaning


fld_name The name of the field. Table 2-27 below contains a list of possible field names and values.

Table 2-27 Description of possible field names and values

Field Name Virtual Type Value

Log Filename LEA_VT_STRING

The log file’s filename.

FileId LEA_VT_INT The log file’s file ID, or -1 if the log file has no file ID.

Version LEA_VT_INT File’s version.

Creation Time LEA_VT_INT The file’s creation time, in time_t format (number of seconds passed since Jan. 1, 1970).

Num of Records

LEA_VT_INT The number of log records in the file.


66

Prototypechar *lea_dictionary_lookup(OpsecSession *session,lea_value_t lea_value, int dict_id);

Arguments

Return Values

The string corresponding to the log field value (lea_value). NULL if there is no dictionary entry for this value.

Notes

• The lea_dictionary_lookup function does not use DNS to resolve IP addresses.

• Use lea_dictionary_lookup if you know the log field value (for example, 2 or 23) and you need the corresponding string (for example, “accept” or “telnet”).

• Use lea_reverse_dictionary_lookup if you know the string (for example, “accept” or “telnet”) and you need the corresponding log field value (for example, 2 or 23).

Example

If the value held in lea_ip_addr is an IP address of a network object in the VPN-1 database, the return value will be the name of that object.

Suppose a log field contains an IP address which cannot be resolved to a name by the LEA Client, but which is known to the LEA Server. For instance, the IP address might be that of an object in the VPN-1 database. lea_dictionary_lookup then enables the LEA Client to resolve the number into a name.

Table 2-28 lea_dictionary_lookup arguments

argument meaning


lea_value The log field value.

dict_id The dictionary identifier. If the log field does not require a dictionary, this is LEA_NO_DICT. This ID can be retrieved from same lea_field structure as lea_value above.For more information, see “lea_field Data Structure” on page 26.



Suppose the following call returns a non-NULL:

If the value held in lea_ip_addr is an IP address (of a network object in the VPN-1 database) then the return value will be the name of that network object.

lea_reverse_dictionary_lookuplea_reverse_dictionary_lookup returns the log field value corresponding to the specified string.

This function is a complement of lea_dictionary_lookup (see page 65).

Prototypeint lea_reverse_dictionary_lookup(OpsecSession *session,int dict_id, char *value, lea_value_t *lea_d_value);

Arguments

Return Values

LEA_FOUND if the dictionary record corresponding to the string has been found. LEA_NOT_FOUND if there is no dictionary record for this string.

Notes

• Use lea_dictionary_lookup if you know the log field value (for example, 2 or 23) and you need the corresponding string (for example, “accept” or “telnet”).

• Use lea_reverse_dictionary_lookup if you know the string (for example, “accept” or “telnet”) and you need the corresponding log field value (for example, 2 or 23).

lea_dictionary_lookup(session,lea_value, LEA_IP_ID);

Table 2-29 lea_reverse_dictionary_lookup arguments

argument meaning


dict_id The dictionary identifier. If the log field does not require a dictionary, this is LEA_NO_DICT. For more information, see “Dictionary Types” on page 33.

value The name of the log field in the dictionary.

lea_d_value If LEA_FOUND, the log field value is returned here.Note: You must allocate the memory for this variable.


68

Example

Suppose the following call returns LEA_FOUND:

If 23 is the value corresponding to “telnet”, then lea_d_u_short would be 23.

See also the example under “Log Record Implementation” on page 24.

lea_resolve_fieldlea_resolve_field returns the value of a log field as an ASCII string, for example“27May97 00:22:35”.

lea_resolve_field is a “convenience” function, and uses only functions and data available to the LEA Client developer.

Prototypechar * lea_resolve_field(OpsecSession *session, lea_field field);

Arguments

Return Values

An ASCII string representing the dictionary value corresponding to field if successful. NULL otherwise.

lea_reverse_dictionary_lookup(session,LEA_TCP_SERVICES_ID, “telnet”, &lea_d_value);

Table 2-30 lea_resolve_field arguments

argument meaning


field A lea_field structure.



Notes

• lea_resolve_field is generally easier to use than lea_dictionary_lookup. The difference between the two functions is illustrated in Table 2-31.

lea_attr_namelea_attr_name returns a string containing the name of the log field, for example “time” or “interface”.

Prototypechar * lea_attr_name(OpsecSession *session,int lea_attr_id);

Table 2-31 lea_resolve_field and lea_dictionary_lookup compared

field value lea_resolve_field

returns

lea_dictionary_lookup returns

IP address

192.23.34.55 If the address is in the dictionary, then lea_resolve_field returns the name from objects.C. Otherwise, it returns the string “192.23.34.55”.

If the address is in the dictionary, then lea_dictionary_lookup returns the name from objects.C. Otherwise, it returns NULL.

action 1 lea_resolve_field returns the dictionary value corresponding to 1.

lea_dictionary_lookup returns the dictionary value corresponding to 1.

Note - lea_resolve_field returns a pointer to a static string. Do not free the pointer.

Managing the Dictionary Iteration Structure

70

Arguments

Return Values

The field name if successful. NULL otherwise.

Managing the Dictionary Iteration StructureThe following functions create, traverse, and destroy the iteration structure for a given dictionary. This structure is used for stepping through the dictionary records.

lea_dict_iter_createlea_dict_iter_create creates an iteration structure for a dictionary and returns a pointer to that structure.

Prototypelea_dict_iter *lea_dict_iter_create(OpsecSession *session,int dict_id, int n_entry);

Table 2-32 lea_attr_name arguments

argument meaning


lea_attr_id The index to the log field’s name, as provided by a lea_field structure.For more information, see “lea_field Data Structure” on page 26.



Arguments

Return Values

Pointer to the iteration structure if successful. NULL if error.

Example

See page 72.

lea_dict_iter_nextlea_dict_iter_next returns a pointer to the next dictionary entry in the specified iteration structure.

Prototypelea_dict_entry *lea_dict_iter_next(lea_dict_iter *iter);

Arguments

Return Value

The next dictionary entry. NULL if there are no more entries in the dictionary.

Example

See example on page 72.

Table 2-33 lea_dict_iter_create arguments

argument meaning


dict_id A dictionary identifier.

n_entry The entry at which the iteration structure should start, ignoring previous entries. (Note that the index of the first record is 0).

Table 2-34 lea_dict_iter_next arguments

argument meaning

iter A pointer to the iteration structure, as returned by lea_dict_iter_create.


72

lea_dict_iter_destroylea_dict_iter_destroy destroys the specified iteration structure.

Prototypevoid lea_dict_iter_destroy(lea_dict_iter *iter);

Arguments

Return Values

None.

Example

See below.

ExampleThe function shown here iterates through and prints all the entries in the given dictionary.

For information about the lea_dict_entry data structure, see “Dictionary Data Structures” on page 35.

Table 2-35 lea_dict_iter_destroy arguments

argument meaning

iter A pointer to the iteration structure, as returned by lea_dict_iter_create.

void lea_print_interface_dictionary(OpsecSession *session, int dict_id){ lea_dict_iter *iter; lea_dict_entry *d_entry; if (dict_id == -1)return;

printf("\n"); iter = lea_dict_iter_create(session, dict_id, 0); while(d_entry= lea_dict_iter_next(iter)) printf("%s %d \n", d_entry->lea_d_name, d_entry->lea_d_interface); printf("\n"); lea_dict_iter_destroy(iter); return ;}

LEA Extended Values


LEA Extended ValuesThe following functions create, destroy, initialize, and retrieve data from LEA extended values. The LEA Extended Values are used in the filtering API.

lea_value_ex_createlea_value_ex_create creates a new empty LEA extended value.

Prototypelea_value_ex_t * lea_value_ex_create();

Arguments

None.

Return Values

A pointer to a new LEA extended value if successful. NULL otherwise.

lea_value_ex_destroylea_value_ex_destroy destroys the specified LEA extended value and frees its memory.

Prototypevoid lea_value_ex_destroy(lea_value_ex_t *val);

Arguments

Return Values

None.

lea_value_ex_duplicatelea_value_ex_duplicate duplicates the specified LEA extended value. The new LEA extended value is distinct from the original. That is, the data contained in the LEA extended value is duplicated as well.

Table 2-36 lea_value_ex_destroy arguments

argument meaning

val A pointer to the LEA extended value to be destroyed.

LEA Extended Values

74

Prototypelea_value_ex_t *lea_value_ex_duplicate(lea_value_ex_t *val);

Arguments

Return Values

A pointer to the copy of the LEA extended value if successful. This pointer is distinct from val. NULL otherwise.

lea_value_ex_setlea_value_ex_set sets the data value and virtual type of the specified LEA extended value. Whenever pointer access is involved, memory is allocated and copied.

Prototypeint lea_value_ex_set(lea_value_ex_t *val, LEA_VT type, ...);

Table 2-37 lea_value_ex_duplicate arguments

argument meaning

val A pointer to the LEA extended value to be duplicated.

LEA Extended Values


Arguments

Return Values

Table 2-38 lea_value_ex_set arguments

argument meaning

val A pointer to the LEA extended value.

type The LEA virtual type corresponding to data.

data The value of the LEA extended value. The C type of this value should correspond to the LEA extended value’s virtual type as follows:

Virtual Type Corresponding C Type

LEA_VT_ACTIONLEA_VT_ALERTLEA_VT_INTERFACELEA_VT_RULELEA_VT_INT

int

LEA_VT_DIRECTIONLEA_VT_IP_PROTO

unsigned char

LEA_VT_RPC_PROGLEA_VT_MASKLEA_VT_HEXLEA_VT_TIMELEA_VT_DURATION_TIMELEA_VT_IP_ADDR

unsigned long

LEA_VT_TCP_PORTLEA_VT_UDP_PORTLEA_VT_USHORT

unsigned short

LEA_VT_STRINGLEA_VT_ISTRINGLEA_VT_SR_HOSTNAMELEA_VT_SR_HOSTGROUPLEA_VT_SR_USERGROUPLEA_VT_SR_SERVICELEA_VT_SR_SERVICEGROUP

char *

LEA_VT_UUID opsec_uuid *

LEA_VT_IPV6 opsec_in6_addr *

LEA Extended Values

76

OPSEC_SESSION_OK is successful, OPSEC_SESSION_ERR otherwise.

lea_value_ex_getlea_value_ex_get retrieves the data stored in the specified LEA extended value. If this data is a string, the string is duplicated. This function is typically used with lea_value_ex_get_type page 78 (see page 78).

Prototypeint lea_value_ex_get(lea_value_ex_t *val, ...);

LEA Extended Values


Arguments

Table 2-39 lea_value_ex_get arguments

argument meaning

val A pointer to the LEA extended value.

data A pointer to be set to the data to be contained by the LEA extended value. The C type of the pointer should correspond to the LEA extended value’s virtual type as follows:


LEA_VT_ACTIONLEA_VT_ALERTLEA_VT_INTERFACELEA_VT_RULELEA_VT_INT

int *

LEA_VT_DIRECTIONLEA_VT_IP_PROTO

unsigned char *

LEA_VT_RPC_PROGLEA_VT_MASKLEA_VT_HEXLEA_VT_TIMELEA_VT_DURATION_TIMELEA_VT_IP_ADDR

unsigned long *

LEA_VT_TCP_PORTLEA_VT_UDP_PORTLEA_VT_USHORT

unsigned short *

LEA_VT_UUID opsec_uuid *

LEA_VT_IPV6 opsec_in6_addr *

LEA Extended Values

78

Return Values

OPSEC_SESSION_OK is successful, OPSEC_SESSION_ERR otherwise.

lea_value_ex_get_typelea_value_ex_get_type retrieves the data stored in the specified LEA extended value.

Prototypeint lea_value_ex_get_type(lea_value_ex_t *val, LEA_VT *type);

data (cont.)

If data corresponds to one of the following virtual types, then it is assumed that data is a pointer to a previously-alloated buffer. In this case, two additional parameters are rrequired:• buf_len - an integer representing the length of the buffer, in

bytes.• act_len - a pointer (int *) to be set to the number of bytes

required (including “\0”)If buf_len is smaller than act_len, then the string is NOT copied into data.


LEA_VT_STRINGLEA_VT_ISTRINGLEA_VT_SR_HOSTNAMELEA_VT_SR_HOSTGROUPLEA_VT_SR_USERGROUPLEA_VT_SR_SERVICELEA_VT_SR_SERVICEGROUP

char *, int, int *

Table 2-39 lea_value_ex_get arguments

argument meaning

LEA Filtering


Arguments

Return Values

OPSEC_SESSION_OK if successful. OPSEC_SESSION_ERR otherwise.

LEA FilteringThis section describes the functions that create, register and unregister the LEA Filtering Rule Base and implement LEA Filtering. Function prototypes are defined in the file lea_filter.h.

lea_filter_rulebase_createlea_filter_rulebase_create creates an empty Rule Base.

PrototypeLeaFilterRuleBase * lea_filter_rulebase_create();

Arguments

None.

Return Values

A pointer to the new LEA Rule Base if successful. NULL otherwise.

lea_filter_rulebase_destroylea_filter_rulebase_destroy destroys a Rule Base and frees its memory.

Prototypevoid lea_filter_rulebase_destroy (LeaFilterRuleBase *filter);

Table 2-40 lea_value_ex_get_type arguments

argument meaning

val A pointer to the value to get its type.

type A pointer to be set the virtual type corresponding to val.

LEA Filtering

80

Arguments

Return Values

None.

lea_filter_rulebase_add_rulelea_filter_rulebase_add_rule adds a rule to the end of the Rule Base. Rules are created using the lea_filter_rule_create (see page 82)

Prototypeint lea_filter_rulebase_add_rule (LeaFilterRuleBase *filter, LeaFilterRule *rule);

Arguments

Return Values

LEA_FILTER_OK if successful. LEA_FILTER_ERR otherwise.

lea_filter_rulebase_registerlea_filter_rulebase_register sends the Rule Base to the LEA Server.

This function is asynchronous. The LEA Server reports whether the Rule Base was successfully registered by generating a LEA_FILTER_QUERY_ACK event (see page 99) on the LEA Client. Only then does the LEA Server begin sending filtered log entries.

Prototypeint lea_filter_rulebase_register (OpsecSession *session, LeaFilterRuleBase *filter, int *filter_id);

Table 2-41 lea_filter_rulebase_destroy arguments

argument meaning

filter A pointer to the Rule Base to be destroyed.

Table 2-42 lea_filter_rulebase_add_rule arguments

argument meaning

filter A pointer to the Rule Base to which to add the rule.

rule A pointer to the rule to be added.

LEA Filtering


Arguments

Return Values


lea_filter_rulebase_unregisterlea_filter_rulebase_unregister disables a previously registered filter. The LEA Server stops implementing the filter and thereafter sends all log entries to the LEA Client.

This function is asynchronous. The LEA Server reports whether the filter was successfully unregistered by generating a LEA_FILTER_QUERY_ACK event (see page 99) on the LEA Client. Only then does the LEA Server begin sending unfiltered log entries.

Prototypeint lea_filter_rulebase_unregister (OpsecSession *session, int filter_id);

Arguments

Return Values


Table 2-43 lea_filter_rulebase_register arguments

argument meaning

session A pointer to the OPSEC session.

filter A pointer to the Rule Base to be registered.

filter_id This will be set to a unique ID (in the scope of the session) assigned to the filter. This parameter cannot be NULL.

Table 2-44 lea_filter_rulebase_unregister arguments

argument meaning


filter_id The ID of the LEA filter to be disabled, as set by lea_filter_rulebase_register.

LEA Filtering

82

lea_filter_rule_createlea_filter_rule_create creates a new filter rule.

PrototypeLeaFilterRule *lea_filter_rule_create(eLeaFilterRuleAction nAction, ...);

Arguments

Return Values

Pointer to new LeaFilterRule structure if successful. NULL if error.

Table 2-45 lea_filter_rule_create arguments

argument meaning Result of the Rule Match

nAction The action associated with this rule.

• LEA_FILTER_ACTION_PASS Pass all log fields.

• LEA_FILTER_ACTION_DROP Drop the log record.

nAction (Cont.)

• LEA_FILTER_ACTION_PASS_FIELDS Drop or pass the fields supplied. Variations on LEA_FILTER_ACTION_PASS.

• LEA_FILTER_ACTION_DROP_FIELDS

... If nAction is LEA_FILTER_ACTION_PASS or LEA_FILTER_ACTION_DROP, then no additional parameters are expected.If nAction is LEA_FILTER_ACTION_PASS_FIELDS or LEA_FILTER_ACTION_DROP_FIELDS, then va_arg holds two parameters, as follows:• an integer (int) specifying the

number of fields in the array pointed to by the next field

• a pointer to an array of strings (char **) where each string contains the name of a field to be passed or dropped (according to the nAction parameter) when the rule is applied

LEA Filtering


lea_filter_rule_destroylea_filter_rule_destroy destroys an existing rule.

Prototypevoid lea_filter_rule_destroy(LeaFilterRule *rule);

Arguments

Return Values

None.

lea_filter_rule_add_predicatelea_filter_rule_add_predicate adds a predicate to a rule. In evaluating a rule, the predicates are ANDed. Predicates are created using lea_filter_predicate_create (see page 84).

Prototypeint lea_filter_rule_add_predicate(LeaFilterRule *rule,LeaFilterPredicate * pred);

Arguments

Return Values


Table 2-46 lea_filter_rule_destroy arguments

argument meaning

rule A pointer to an existing rule (returned by lea_filter_rule_create).

Table 2-47 lea_filter_rule_add_predicate arguments

argument meaning

rule A pointer to a rule (returned by lea_filter_rule_create).

pred A pointer to the predicate (returned by lea_filter_predicate_create).

LEA Filtering

84

lea_filter_predicate_create

lea_filter_predicate_create creates a new LeaFilterPredicate object.

PrototypeLeaFilterPredicate *lea_filter_predicate_create(const char *attr,int dict, int nNegate,eLeaFilterPredicateType pred_type, ...);

LEA Filtering


Arguments

Table 2-48 lea_filter_predicate_create arguments

argument meaning

attr The name of the log field to which this predicate applies (see Table 1-20 on page 38).

dict Always -1. Reserved for future use.

nNegate A value of 1 specifies that the predicate is negated. A value of 0 specifies that the predicate is not negated. All other values are forbidden.The type of predicates (listed below) followed by the the corresponding expected parameters.

Note - For all predicates concerned with order (=,<,<=,>,>=,[]), integers are compared numerically and strings are compared lexicographically.

pred_type

predicate type parameters meaning

LEA_FILTER_PRED_EQUALS One LEA extended value.

True if attr is equal to the given value.

LEA_FILTER_PRED_BELONGS_TO The number of LEA extended values in the set, followed by an array containing those values.

True if attr belongs to the given set.

LEA_FILTER_PRED_EXISTS N/A True if attr exists in the log record.

LEA_FILTER_PRED_GREATER One LEA extended value.

True if attr is greater than the given value.

LEA_FILTER_PRED_GREATER_EQUAL

One LEA extended value.

True if attr is greater or equal to the given value

LEA_FILTER_PRED_SMALLER One LEA extended value.

True if the specified field is smaller than the given value.

LEA Filtering

86

Return Values

A pointer to a new LeaFilterPredicate structure if successful. NULL otherwise.

Server Resolved Virtual Types

At times it may be simpler to define a filter whose rule predicates are resolved by the LEA Server, rather than by the LEA Client. For example, consider the pseudo code in the rule below.

LEA_FILTER_PRED_SMALLER_EQUAL

One LEA extended value.

True if attr is smaller or equal to the given value

LEA_FILTER_PRED_TRUE N/A True always. attr should be NULL with this predicate

LEA_FILTER_PRED_BELONGS_TO_RANGE

Two LEA extended values.

True if attr is greater than or equal to the first given value, and lesser than or equal than the second value.

LEA_FILTER_PRED_BELONGS_TO_MASK

Two integers representing a network address and an IP mask.

True if attr (a LEA IP Field) belongs to the specified subnet.

LEA_FILTER_PRED_CONTAINS_SUBSTRING

A string value. True if attr (a LEA string Field) contains the specified substring.

Table 2-48 lea_filter_predicate_create arguments(continued)

argument meaning

lea_filter_predicate_create(“orig”, -1, 0, LEA_FILTER_PRED_BELONGS_TO, 10, gateways_arr);

LEA Filtering


This predicate passes all of the logs generated by ten VPN-1 gateways to the LEA Server. gateways_arr contains the IP address of each gateway.

It may be more convenient to write the same rule using the following pseudo code notation:

This predicate assumes that the LEA Server will resolve “Gateways” into a list of IP addresses of all VPN-1 gateways, and only then test whether the IP address in the “orig” field of the log record belongs to the group.

In order to meet this this need and maintain a consistent syntax for defining LEA filter predicates, the LEA virtual types in Table 2-49 are available as part of the LEA API. These types signal the LEA Server that their values must be resolved before a predicate is applied.

So, the correct way to write a predicate that passes all of the logs generated by VPN-1 gateways to the LEA Server is as follows:

lea_filter_predicate_create(“orig”, -1, 0, LEA_FILTER_PRED_BELONGS_TO, “Gateways”);

Table 2-49 Server Resolved LEA Virtual Types

Virtual Type Description

LEA_VT_SR_HOSTNAME The object name of a single host.

LEA_VT_SR_HOSTGROUP The object name of a host group.

LEA_VT_SR_USERGROUP The object name of a user group.

LEA_VT_SR_SERVICE (TCP or UDP)

The object name of a service.

LEA_VT_SR_SERVICEGROUP The object name of service group.

Note - All object names are case-sensitive and must be used exactly as they are defined on the VPN-1 SmartCenter Server.

lea_value_ex_t * val = lea_value_ex_create();lea_value_ex_set(val, LEA_VT_SR_HOSTGROUP, "Gateways");lea_filter_predicate_create("orig", -1, 0, LEA_FILTER_PRED_BELONGS_TO, 1,val);

LEA Filtering

88

Examples

Assume that the following values have been” defined and created:

lea_value_ex_t *val1, *val2, *va3, *val4, *val5, *val6, *val7;

lea_value_ex_set(val1, LEA_VT_TCP_PORT, 80);lea_value_ex_set(val2, LEA_VT_SR_SERVICE, “http”);lea_value_ex_set(val3, LEA_VT_SR_HOSTNAME, “bigben”);lea_value_ex_set(val4, LEA_VT_SR_HOSTGROUP, “file_servers”);lea_value_ex_set(val5, LEA_VT_SR_IP_ADDR, inet_addr(“156.14.22.45”));lea_value_ex_set(val6, LEA_VT_SR_SERVICEGROUP, “FireWall1”);lea_value_ex_set(val7, LEA_VT_RULE, 4);lea_value_ex_set(val8, LEA_VT_RULE, 7);

lea_value_ex_t **val_arr = calloc(3, sizeof(lea_value_ex_t*));

val_arr[0] = val[3];val_arr[1] = val[4];val_arr[2] = val[5];

LEA Filtering


Now consider the following examples:

lea_filter_predicate_destroy

lea_filter_predicate_destroy destroys an existing predicate and frees its memory.

lea_filter_predicate_create("src_port", -1, 0, LEA_FILTER_PRED_EQUALS,val1);

lea_filter_predicate_create("src_port", -1, 0,LEA_FILTER_PRED_EQUALS,val2);

lea_filter_predicate_create(“src”, -1, 0, LEA_FILTER_PRED_BELONGS_TO, 3, val_arr);

lea_filter_predicate_create(“s_port”, -1, 0, LEA_FILTER_PRED_BELONGS_TO, 1, &val6);

lea_filter_predicate_create(“request”, -1, 0, LEA_FILTER_PRED_EXISTS);

lea_filter_predicate_create(“src_port”, -1, 0, LEA_FILTER_PRED_GREATER, val7);

lea_filter_predicate_create(“src_port”, -1, 0, LEA_FILTER_PRED_GREATER_EQUAL, val7);

lea_filter_predicate_create(“src_port”, -1, 0, LEA_FILTER_PRED_SMALLER, val8);

lea_filter_predicate_create(“src_port”, -1, 0, LEA_FILTER_PRED_SMALLER_EQUAL, val8);

/* always true */lea_filter_pred_true (NULL, -1, 0, LEA_FILTER_PRED_TRUE);lea_filter_predicate_create(“src_port”, -1, 0, LEA_FILTER_PRED_BELONGS_TO_RANGE, val2, val3);

lea_filter_predicate_create(“src”, -1, 0, LEA_FILTER_PRED_BELONGS_TO_MASK, inetaddr(“192.168.0.0”),inetaddr(“255.255.0.0”));

lea_filter_predicate_create(“reason”, -1, 0, LEA_FILTER_PREDICATE_CONTAINS_SUBSTRING, “user”);

Local (Client-side) Filtering

90

Prototypevoid lea_filter_predicate_destroy(LeaFilterPredicate * pred);

Arguments

Return Values

None.


This section describes the functions register and unregister a locally registered rulebase.

lea_filter_rulebase_register_local

lea_filter_rulebase_register_local registers a rule base locally.

Prototypeint lea_filter_rulebase_register_local (OpsecSession *session,LeaFilterRulebase *filter);

Arguments

Return Values

OPSEC_SESSION_OK upon success, otherwise OPSEC_SESSION_ERR.

lea_filter_rulebase_unregister_local

lea_filter_rulebase_unregister_local unregisters the previously locally registered rule base.

Table 2-50 lea_filter_predicate_destroy arguments

argument meaning

pred A pointer to an existing predicate (returned by lea_filter_predicate_create).

Table 2-51 lea_filter_rulebase_register_local arguments

argument meaning

session A pointer to the session to which the rule base is to be applied.

filter A pointer to the filter rule base.



Prototypeint lea_filter_rulebase_unregister_local (OpsecSession *session);

Arguments

Return Values

OPSEC_SESSION_OK upon success, otherwise OPSEC_SESSION_ERR.

Table 2-52 lea_filter_rulebase_unregister_local arguments

argument meaning

session A pointer to the session to which the rule base is to be removed.


92

93

Chapter 3LEA Event Handlers

In This Chapter

Event Handlers page 94

Event Handler for the LEA_RECORD event page 94

Determining the Index of a Field in a Log Record page 95

Event Handler for the LEA_DICT Event page 97

Event Handler for the LEA_SWITCH Event page 98

Event Handler for the LEA_EOF Event page 98

Event Handler for the LEA_FILTER_QUERY_ACK Event page 99

Event Handler for the LEA_COL_LOGS Event page 100

Event Handler for the LEA_SUSPEND Event page 101

Event Handler for the LEA_RESUME Event page 101

Event Handlers

94

Event HandlersThis section describes the functions that need to be written in order to implement a LEA Client.

All of these functions take a pointer to OpsecSession as an argument.

Note that the memory allocated for function arguments is managed by the OPSEC environment, and that the arguments hold valid data only during the execution of the handler functions. For this reason, you should not, for example, save a static pointer to this data for use after the handler function returns.

All event handlers should return either:

OPSEC_SESSION_OK if the session can continue.

OPSEC_SESSION_END if the session is to be closed.

OPSEC_SESSION_ERR if the session is to be closed due to an error.

Event Handler for the LEA_RECORD eventThis function is called each time the LEA Server sends a log record to the LEA Client. A log record corresponds to a line in SmartView Tracker. For more information the implementation of log records, see “Log Record Implementation” on page 24.

Prototypeint RecordHandler( OpsecSession *session, struct lea_record *rec,int attrib_perm[]);

Note - The name RecordHandler is a placeholder. You can assign any name to this function.

Event Handler for the LEA_RECORD event

Chapter 3 LEA Event Handlers 95

Arguments

Determining the Index of a Field in a Log RecordIn the following example lea_reverse_dictionary_lookup returns an attribute value which is then used to determine the index of a field in a log record by checking the value in attrib_perm.

Suppose the following call returns LEA_FOUND:

Then lea_d_value->i_value might be 3, for example. Because the dictionary used in this call is the Attribute Dictionary, this value is actually an index.

In the RecordHandler function, suppose:

Table 3-1 RecordHandler arguments

argument meaning


rec A pointer to a lea_record structure.

attrib_perm An array of attribute identifiers of the fields in the log record, generally used to determine which fields are present in the log record. The number of integers in this array is one more than the number of records in the Attribute Dictionary. The array contains the following values:

Table 3-2

value of ith integer

in the array

meaning

-2 The end of the array.

LEA_NOT_FOUND The ith field in the Attribute Dictionary is not presethe log record (the rec argument).

Anything other than LEA_NOT_FOUND

The index of the corresponding field in the fields athe lea_record structure pointed to by rec.

lea_reverse_dictionary_lookup(session, LEA_ATTRIB_ID, “action”, lea_d_value)

action_idx = lea_d_value->i_value

idx = attrib_perm[action_idx]

Event Handler for the LEA_RECORD event

96

If idx is LEA_NOT_FOUND, then there is no “action” field in the current log record. Otherwise, idx is the index of the “action” field in the current log record and

rec->fields[idx]

contains the field’s value.

In the code fragment below, the values of the “time” and “src” fields are retrieved from the Attribute Dictionary.

if (dict_id == LEA_ATTRIB_ID){if (time_attrib_idx == LEA_NOT_FOUND) if ((lea_reverse_dictionary_lookup(session,

LEA_ATTRIB_ID,"time",

&d_value)) != LEA_NOT_FOUND)

time_attrib_idx = d_value.i_value;if (src_attrib_idx == LEA_NOT_FOUND) if ((lea_reverse_dictionary_lookup(session,

LEA_ATTRIB_ID, "src",&d_value))

!= LEA_NOT_FOUND)src_attrib_idx = d_value.i_value;

}

Event Handler for the LEA_DICT Event


These fields in the log record can now be accessed directly as follows:

Event Handler for the LEA_DICT EventThis function is called whenever a new dictionary is sent or there is a change in one of the existing dictionaries. If a modified dictionary is sent, the new version retains the dict_id.

Prototypeint DictionaryHandler(OpsecSession *session, int dict_id,LEA_VT val_type, int n_d_entries);

if (time_attrib_idx != LEA_NOT_FOUND){index_in_record = attrib_perm[time_attrib_idx];if (index_in_record != LEA_NOT_FOUND){printf("time = %s\n",

lea_resolve_field(session, rec->fields[index_in_record]));}

}if (src_attrib_idx != LEA_NOT_FOUND)

{index_in_record = attrib_perm[src_attrib_idx];if (index_in_record != LEA_NOT_FOUND){dict_id = rec->fields[index_in_record].lea_dictionary;src = lea_dictionary_lookup(session,

rec->fields[index_in_record].lea_value, dict_id);

if (src)printf("src = %s\n",src);

elseprintf("src = unknown\n");

}}

Note - The name DictionaryHandler is a placeholder. You can assign any name to this function.

Event Handler for the LEA_SWITCH Event

98

Arguments

Event Handler for the LEA_SWITCH EventThis function is called when the log file is switched, but only after all the records in the original log file have been sent to the LEA Client. In other words, this function is called when the LEA Server starts a new log file.

Prototypeint SwitchHandler( OpsecSession *session);

Arguments

Event Handler for the LEA_EOF EventThis function is called after the LEA Server has sent the last log record in the log file to the LEA Client.

If lea_new_session or lea_new_suspended_session (page 46) was called with logtrack set to LEA_FILENAME, the file identifier saved in the OpsecSession structure is that of the current log file.

Table 3-3 DictionaryHandler arguments

argument meaning


dict_id The dictionary identifier.

val_type One of the values for lea_val_type, as listed in Table 1-10 on page 27.

n_d_entries The number of records in the dictionary.

Note - The name SwitchHandler is a placeholder. You can assign any name to this function.

Table 3-4 SwitchHandler arguments

argument meaning


Event Handler for the LEA_FILTER_QUERY_ACK Event


In all other cases, the file identifier saved in the OpsecSession structure is that of the next log file. When the EOF handler is called for the last log file, the file identifier saved is that of the fw.log.

Prototypeint EOFHandler( OpsecSession *session);

Arguments

Event Handler for the LEA_FILTER_QUERY_ACK Event

This function is called when the LEA Server registers (applies) or unregisters (stops applying) a LEA Filter. If the LEA Server was unable to take the specified action, it will continue sending log records according to its previous state. That is, if the LEA Server was unable to apply the filter, it will continue to send unfiltered log records, or, if a filter was previously applied, log records filtered according to that filter.

Prototypeint FilterQueryAckHandler(OpsecSession *session, int filter_id, eLeaFilterAction action, int status);

Note - The name EOFHandler is a placeholder. You can assign any name to this function.

Table 3-5 EOFHandler arguments

argument meaning


Note - The name FilterQueryAckHandler is a placeholder. You can assign any name to this function.

Event Handler for the LEA_COL_LOGS Event

100

Arguments

Event Handler for the LEA_COL_LOGS EventWhen an update to the Server’s collected log file list arrives, this handler will be called.

Prototypeint ColLogsHandler( OPsecSession *session)

Arguments

Table 3-6 FilterQueryAckHandler arguments

parameter meaning


filter_id The ID of the LEA filter.

action The requested action. One of:• LEA_FILTER_REGISTER - register the specified filter.• LEA_FILTER_UNREGISTER - unregister the specified filter.

status The status of the action. One of:• LEA_FILTER_OK - the action was performed successfully.• LEA_FILTER_ERR - the action was unsuccessful.• LEA_FILTER_NOT_SUP - the LEA Server does not support filtering.

Table 3-7 LEA_COL_LOGS arguments

parameter meaning


Event Handler for the LEA_SUSPEND Event


Event Handler for the LEA_SUSPEND EventThis function is called after the LEA Server has suspended the session.

Prototypeint SuspendHandler( OpsecSession *session);

Arguments

Event Handler for the LEA_RESUME EventThis function is called after the LEA Server has resumed the session.

Prototypeint ResumeHandler( OpsecSession *session);

Arguments

Note - The name SuspendHandler is a placeholder. You can assign any name to this function.

Table 3-8 SuspendHandler arguments

argument meaning


Note - The name ResumeHandler is a placeholder. You can assign any name to this function.

Table 3-9 ResumeHandler arguments

argument meaning


Event Handler for the LEA_RESUME Event

102

103

THIRD PARTY TRADEMARKS AND COPYRIGHTS

Entrust is a registered trademark of Entrust Technologies, Inc. in the United States and other countries. Entrust’s logos and Entrust product and service names are also trademarks of Entrust Technologies, Inc. Entrust Technologies Limited is a wholly owned subsidiary of Entrust Technologies, Inc. FireWall-1 and SecuRemote incorporate certificate management technology from Entrust.

Verisign is a trademark of Verisign Inc.

The following statements refer to those portions of the software copyrighted by University of Michigan. Portions of the software copyright © 1992-1996 Regents of the University of Michigan. All rights reserved. Redistribution and use in source and binary forms are permitted provided that this notice is preserved and that due credit is given to the University of Michigan at Ann Arbor. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission. This software is provided “as is” without express or implied warranty. Copyright © Sax Software (terminal emulation only).

The following statements refer to those portions of the software copyrighted by Carnegie Mellon University.

Copyright 1997 by Carnegie Mellon University. All Rights Reserved.

Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of CMU not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission.CMU DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL CMU BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

The following statements refer to those portions of the software copyrighted by The Open Group.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

The following statements refer to those portions of the software copyrighted by The OpenSSL Project. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/).

THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The following statements refer to those portions of the software copyrighted by Eric Young. THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Copyright © 1998 The Open Group.

104

The following statements refer to those portions of the software copyrighted by Jean-loup Gailly and Mark Adler Copyright (C) 1995-2002 Jean-loup Gailly and Mark Adler. This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.

2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.

3. This notice may not be removed or altered from any source distribution.

The following statements refer to those portions of the software copyrighted by the Gnu Public License. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

The following statements refer to those portions of the software copyrighted by Thai Open Source Software Center Ltd and Clark Cooper Copyright (c) 2001, 2002 Expat maintainers. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.GDChart is free for use in your applications and for chart generation. YOU MAY NOT re-distribute or represent the code as your own. Any re-distributions of the code MUST reference the author, and include any and all original documentation. Copyright. Bruce Verderaime. 1998, 1999, 2000, 2001. Portions copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 by Cold Spring Harbor Laboratory. Funded under Grant P41-RR02188 by the National Institutes of Health. Portions copyright 1996, 1997, 1998, 1999, 2000, 2001, 2002 by Boutell.Com, Inc. Portions relating to GD2 format copyright 1999, 2000, 2001, 2002 Philip Warner. Portions relating to PNG copyright 1999, 2000, 2001, 2002 Greg Roelofs. Portions relating to gdttf.c copyright 1999, 2000, 2001, 2002 John Ellson ([email protected]). Portions relating to gdft.c copyright 2001, 2002 John Ellson ([email protected]). Portions relating to JPEG and to color quantization copyright 2000, 2001, 2002, Doug Becker and copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, Thomas G. Lane. This software is based in part on the work of the Independent JPEG Group. See the file README-JPEG.TXT for more information. Portions relating to WBMP copyright 2000, 2001, 2002 Maurice Szmurlo and Johan Van den Brande. Permission has been granted to copy, distribute and modify gd in any context without fee, including a commercial application, provided that this notice is present in user-accessible supporting documentation. This does not affect your ownership of the derived work itself, and the intent is to assure proper credit for the authors of gd, not to interfere with your productive use of gd. If you have questions, ask. "Derived works" includes all programs that utilize the library. Credit must be given in user-accessible documentation. This software is provided "AS IS." The copyright holders disclaim all warranties, either express or implied, including but not limited to implied warranties of merchantability and fitness for a particular purpose, with respect to this code and accompanying documentation. Although their code does not appear in gd 2.0.4, the authors wish to thank David Koblas, David Rowley, and Hutchison Avenue Software Corporation for their prior contributions.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0

The curl license

COPYRIGHT AND PERMISSION NOTICE

Copyright (c) 1996 - 2004, Daniel Stenberg, <[email protected]>.All rights reserved.

Permission to use, copy, modify, and distribute this software for any purpose

with or without fee is hereby granted, provided that the above copyright

notice and this permission notice appear in all copies.

Chapter 105

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder.

The PHP License, version 3.0

Copyright (c) 1999 - 2004 The PHP Group. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, is permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

3. The name "PHP" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [email protected].

4. Products derived from this software may not be called "PHP", nor may "PHP" appear in their name, without prior written permission from [email protected]. You may indicate that your software works in conjunction with PHP by saying "Foo for PHP" instead of calling it "PHP Foo" or "phpfoo"

5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License.

6. Redistributions of any form whatsoever must retain the following acknowledgment:

"This product includes PHP, freely available from <http://www.php.net/>".

THIS SOFTWARE IS PROVIDED BY THE PHP DEVELOPMENT TEAM ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE PHP DEVELOPMENT TEAM OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

This software consists of voluntary contributions made by many individuals on behalf of the PHP Group. The PHP Group can be contacted via Email at [email protected].

For more information on the PHP Group and the PHP project, please see <http://www.php.net>. This product includes the Zend Engine, freely available at <http://www.zend.com>.

This product includes software written by Tim Hudson ([email protected]).

Copyright (c) 2003, Itai Tzur <[email protected]>

All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

Redistribution of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

Neither the name of Itai Tzur nor the names of other contributors may be used to endorse or promote products derived from this software without specific prior written permission.

106

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS

INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Copyright © 2003, 2004 NextHop Technologies, Inc. All rights reserved.

Confidential Copyright Notice

Except as stated herein, none of the material provided as a part of this document may be copied, reproduced, distrib-uted, republished, downloaded, displayed, posted or transmitted in any form or by any means, including, but not lim-ited to, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of NextHop Technologies, Inc. Permission is granted to display, copy, distribute and download the materials in this doc-ument for personal, non-commercial use only, provided you do not modify the materials and that you retain all copy-right and other proprietary notices contained in the materials unless otherwise stated. No material contained in this document may be "mirrored" on any server without written permission of NextHop. Any unauthorized use of any material contained in this document may violate copyright laws, trademark laws, the laws of privacy and publicity, and communications regulations and statutes. Permission terminates automatically if any of these terms or condi-tions are breached. Upon termination, any downloaded and printed materials must be immediately destroyed.

Trademark Notice

The trademarks, service marks, and logos (the "Trademarks") used and displayed in this document are registered and unregistered Trademarks of NextHop in the US and/or other countries. The names of actual companies and products mentioned herein may be Trademarks of their respective owners. Nothing in this document should be construed as granting, by implication, estoppel, or otherwise, any license or right to use any Trademark displayed in the document. The owners aggressively enforce their intellectual property rights to the fullest extent of the law. The Trademarks may not be used in any way, including in advertising or publicity pertaining to distribution of, or access to, materials in

this document, including use, without prior, written permission. Use of Trademarks as a "hot" link to any website is prohibited unless establishment of such a link is approved in advance in writing. Any questions concerning the use of these Trademarks should be referred to NextHop at U.S. +1 734 222 1600.

U.S. Government Restricted Rights

The material in document is provided with "RESTRICTED RIGHTS." Software and accompanying documentation are provided to the U.S. government ("Government") in a transaction subject to the Federal Acquisition Regulations with Restricted Rights. The Government's rights to use, modify, reproduce, release, perform, display or disclose are

restricted by paragraph (b)(3) of the Rights in Noncommercial Computer Software and Noncommercial Computer Soft-ware Documentation clause at DFAR 252.227-7014 (Jun 1995), and the other restrictions and terms in paragraph (g)(3)(i) of Rights in Data-General clause at FAR 52.227-14, Alternative III (Jun 87) and paragraph (c)(2) of the Commer-cial

Computer Software-Restricted Rights clause at FAR 52.227-19 (Jun 1987).

Use of the material in this document by the Government constitutes acknowledgment of NextHop's proprietary rights in them, or that of the original creator. The Contractor/Licensor is NextHop located at 1911 Landings Drive, Mountain View, California 94043. Use, duplication, or disclosure by the Government is subject to restrictions as set forth in applicable laws and regulations.

Chapter 107

Disclaimer Warranty Disclaimer Warranty Disclaimer Warranty Disclaimer Warranty

THE MATERIAL IN THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTIES OF ANY KIND EITHER EXPRESS OR IMPLIED. TO THE FULLEST EXTENT POSSIBLE PURSUANT TO THE APPLICABLE LAW, NEXTHOP DISCLAIMS ALL WARRANTIES,

EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON INFRINGEMENT OR OTHER VIOLATION OF RIGHTS. NEITHER NEXTHOP NOR ANY OTHER PROVIDER OR DEVELOPER OF MATERIAL CONTAINED IN THIS DOCUMENT WARRANTS OR MAKES ANY REPRESEN-TATIONS REGARDING THE USE, VALIDITY, ACCURACY, OR RELIABILITY OF, OR THE RESULTS OF THE USE OF, OR OTHERWISE RESPECTING, THE MATERIAL IN THIS DOCUMENT.

Limitation of Liability

UNDER NO CIRCUMSTANCES SHALL NEXTHOP BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES, INCLUDING, BUT NOT LIMITED TO, LOSS OF DATA OR PROFIT, ARISING OUT OF THE USE, OR THE INABILITY TO USE, THE MATERIAL IN THIS DOCUMENT, EVEN IF NEXTHOP OR A NEXTHOP AUTHORIZED REPRESENTATIVE HAS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IF YOUR USE OF MATERIAL FROM THIS DOCUMENT RESULTS IN THE NEED FOR SERVICING, REPAIR OR CORRECTION OF EQUIPMENT OR DATA, YOU ASSUME ANY COSTS THEREOF. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THE ABOVE LIMITATION OR EXCLUSION MAY NOT FULLY APPLY TO YOU.

Copyright © ComponentOne, LLC 1991-2002. All Rights Reserved.

BIND: ISC Bind (Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC"))

Copyright 1997-2001, Theo de Raadt: the OpenBSD 2.9 Release

PCRE LICENCE

PCRE is a library of functions to support regular expressions whose syntax and semantics are as close as possible to those of the Perl 5 language. Release 5 of PCRE is distributed under the terms of the "BSD" licence, as specified below. The documentation for PCRE, supplied in the "doc" directory, is distributed under the same terms as the software itself.

Written by: Philip Hazel <[email protected]>

University of Cambridge Computing Service, Cambridge, England. Phone:

+44 1223 334714.

Copyright (c) 1997-2004 University of Cambridge All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

* Neither the name of the University of Cambridge nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

June 2006 109

Index

AAttribute Dictionary 34, 95

CCollected Log Files 24collected log files functions

lea_collected_file_info_destroy 26

lea_collected_file_info_duplicate 26

lea_get_collected_file_info_by_field_name 26

lea_get_first_collected_file_info 25

lea_get_last_collected_file_info 25

lea_get_next_collected_file_info 25

lea_get_prev_collected_file_info 25

Ddata structures

for indexing dictionaries 36for log events 24for log files 23lea_dict_entry 35lea_field 26lea_logdesc 23lea_record 26lea_value_ex_t 31lea_value_t 27

dictionaries 32Actions Dictionary 34Attribute Dictionary 34IP Address Dictionary 34pointer to 33TCP Services Dictionary 34types of 33

UDP Services Dictionary 34dictionary field names

lea_d_action 35lea_d_alert 35lea_d_attrib 35lea_d_direction 35lea_d_duration_time 35lea_d_hex 35lea_d_int 35lea_d_interface 35lea_d_ip_addr 36lea_d_ip_proto 36lea_d_mask 36lea_d_rpc_prog 36lea_d_rule 36lea_d_tcp_port 36lea_d_time 36lea_d_u_char 35lea_d_u_long 35lea_d_u_short 35lea_d_udp_port 36

DNS 34

EEvent Handlers

return values 94event handlers

for LEA_DICT event 97for LEA_EOF 98for LEA_RECORD event 94for LEA_RESUME 101for LEA_SUSPEND 101for LEA_SWITCH event 98

eventsLEA_COL_LOGS 100LEA_COL_LOGS_HANDLER

18, 19LEA_DICT 18, 19, 33, 54,

97LEA_EOF 18, 19, 48, 98,

101LEA_FILTER_QUERY_ACK 1

8, 19, 80, 81, 99

LEA_RECORD 18, 19, 34, 94

LEA_RESUME 18, 19LEA_SUSPEND 18, 19LEA_SWITCH 18, 19, 98

extended valuessee LEA extended values

Ffield names

general listing 37lea_d_value 35lea_value 27

fieldsin dictionary. See dictionary

field namesvalues in log. See lea_value

field namesfw.alog 48fw.log 48, 58fw.logtrack file 23, 48, 54

IISAKMP 38iteration data structure 36, 70

LLEA client-side filtering 43LEA extended values

definition 31LEA filtering differences

backwards compatibility 31synchronous vs.

asynchronous 30LEA Virtual Types 31LEA_ACTION_ID dictionary ID 34lea_attr_name 33, 69

110

LEA_ATTRIB_ID dictionary ID 34LEA_COL_LOGS 100LEA_COL_LOGS_HANDLER 19

18lea_collected_file_info_destroy 2

6, 64lea_collected_file_info_duplicate

26, 63lea_d_value field names 35LEA_DICT event 18, 19, 33, 54,

59, 97lea_dict_entry data structure 35LEA_DICT_HANDLER 19lea_dict_iter_create 36, 70lea_dict_iter_destroy 36, 72lea_dict_iter_next 36, 71lea_dictionary_lookup 33, 65

and lea_resolve_field compared 69

UFP masks 37LEA_EOF event 18, 19, 48LEA_EOF_HANDLER 19lea_field data structure 24, 26LEA_FILENAME 48, 98lea_filter.h file 79lea_filter_predicate_create 84lea_filter_predicate_create

Examples 88lea_filter_predicate_destroy 83,

89LEA_FILTER_QUERY_ACK

event 18, 19, 80, 81, 99LEA_FILTER_QUERY_ACK_HAND

LER 19lea_filter_rule_add_predicate 83lea_filter_rule_create 82lea_filter_rulebase_add_rule 80lea_filter_rulebase_create 79lea_filter_rulebase_destroy 79,

90lea_filter_rulebase_register 80lea_filter_rulebase_register_local

90lea_filter_rulebase_unregister 81lea_filter_rulebase_unregister_loc

al 90lea_get_collected_file_info_by_fie

ld_name 26, 64

lea_get_fileid_by_filename 23, 55, 56

lea_get_filename_by_fileid 23, 54

lea_get_first_collected_file_info25, 59, 60, 61, 62, 63

lea_get_first_file_info 23, 57lea_get_last_collected_file_info 2

5lea_get_last_file_info 23, 58, 59lea_get_logfile_desc 20, 53lea_get_next_collected_file_info

25lea_get_next_file_info 23, 56,

57, 58lea_get_prev_collected_file_info

25, 61, 62lea_get_record_pos 20, 53LEA_IP_ID dictionary ID 34lea_logdesc 23lea_new_session 18, 20, 46, 53,

98lea_new_suspended_session 20,

46, 98LEA_NO_DICT return value 66,

67LEA_OFFLINE mode 47LEA_ONLINE mode 18, 47lea_record data structure 24, 26LEA_RECORD event 18, 19, 34,

94LEA_RECORD_HANDLER 19lea_resolve_field 33, 68

and lea_dictionary_lookup compared 69

UFP masks 37LEA_RESUME event 18, 19LEA_RESUME_HANDLER 19lea_reverse_dictionary_lookup 33

, 67, 95lea_session_resume 20lea_session_suspend 20, 51, 52LEA_SUSPEND event 18, 19LEA_SUSPEND_HANDLER 19LEA_SWITCH event 18, 19, 98LEA_SWITCH_HANDLER 19LEA_TCP_SERVICES_ID

dictionary ID 34

LEA_UDP_SERVICES_ID dictionary ID 34

lea_value field names 27lea_action 27lea_alert 27lea_direction 27lea_duration_time 28lea_hex 27lea_int 27lea_interface 27lea_ip_addr 28lea_ip_proto 28lea_mask 28lea_rpc_prog 28lea_rule 28lea_string 27lea_tcp_port 28lea_time 28lea_u_short 27lea_udp_port 28lea_uuid 28

lea_value_ex_t data structure 31lea_value_t data structure 27local client-side filtering 90log data structures 24log events 15log files 20

file IDs 23opening 48

log record field namesaction 38agent field 38alert 38bytes 38cat_server 38category 38d_port 38decryption failure: 38dst 38dstkeyid 38elapsed 38encryption failure: 39error_notification: 39expire 39file 39from 39h_len 39has_accounting 39host: 39i/f name 39icmp-code 40icmp-type 40ip_vers 40

111

ISAKMP Log: 40key update for 40len 40license violation detected 40message 40methods: 40Negotiation Id: 40orig 40orig_from 40orig_to 40packets 40port: 41proto 41reason 41reason: 41request 41res_action 41resource 41rpc_prog 41rule 41s_port 41scheme: 41service 42service_id 42signed by 42SPI 42src 42srckeyid 42srcname 42start_time 42success reason: 42sys_msgs 42target 43time 43to 43user 43uuid 43xlatedport 43xlatedst 43xlatesport 43xlatesrc 43

log unification 21file read modes 22file structure 21LEA support for 22unification definition 21

log valuestranslating into strings 65types of 32

Log ViewerInfo column 15

MMultithread 16

reentrant 16

Oobjects.C 34OPSEC session

initializing 46opsec_destroy_entity 18opsec_init 18opsec_init_entity 18, 19opsec_mainloop 18

Pprogramming model 15

SSAM API 39, 43SmartView Tracker 15, 24SPI 38, 42

Tthreads 16

UUFP mask 36, 38UFP Server 38

check point™ lea (log export api) specificationread.pudn.com/downloads142/doc/614417/lea.pdf ·...

Documents